Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #94820 > unrolled thread

Substantive Comments Please: GCC vs. LLMV

Back to article view | Back to comp.os.linux.misc

Contents

  Substantive Comments Please: GCC vs. LLMV Leroy H <lh@somewhere.net> - 2026-10-31 03:11 +0000
    Re: Substantive Comments Please: GCC vs. LLMV Computer Nerd Kev <not@telling.you.invalid> - 2026-10-31 17:28 +1000
      Re: Substantive Comments Please: GCC vs. LLMV Leroy H <lh@somewhere.net> - 2026-10-31 13:25 +0000
    Re: Substantive Comments Please: GCC vs. LLMV jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-10-31 10:30 -0400
      Re: Substantive Comments Please: GCC vs. LLMV Leroy H <lh@somewhere.net> - 2026-10-31 15:12 +0000
      Re: Substantive Comments Please: GCC vs. LLMV rbowman <bowman@montana.com> - 2026-10-31 19:21 +0000
      Re: GCC vs. LLVM Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-31 21:06 +0000
        Re: GCC vs. LLVM Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-01 00:39 +0000
          Re: GCC vs. LLVM rbowman <bowman@montana.com> - 2026-11-01 01:45 +0000
            Re: GCC vs. LLVM Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-01 09:05 +0000
        Re: GCC vs. LLVM c186282 <c186282@nnada.net> - 2026-11-01 03:51 -0500
          Re: GCC vs. LLVM Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-11-01 02:16 -0800
            Re: GCC vs. LLVM c186282 <c186282@nnada.net> - 2026-11-01 18:01 -0500
              Re: GCC vs. LLVM Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-11-01 20:25 -0800
                Re: GCC vs. LLVM c186282 <c186282@nnada.net> - 2026-11-02 01:52 -0500
                  Re: GCC vs. LLVM Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-11-01 23:06 -0800
                    Re: GCC vs. LLVM The Natural Philosopher <tnp@invalid.invalid> - 2026-11-02 10:39 +0000
                    Re: GCC vs. LLVM c186282 <c186282@nnada.net> - 2026-11-02 11:37 -0500
                      Re: GCC vs. LLVM Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-02 16:54 +0000
                    Re: GCC vs. LLVM c186282 <c186282@nnada.net> - 2026-11-02 11:57 -0500
                    Re: GCC vs. LLVM Rich <rich@example.invalid> - 2026-11-04 03:58 +0000
                  Re: GCC vs. LLVM "Carlos E. R." <robin_listas@es.invalid> - 2026-11-02 23:16 +0100
                    Re: GCC vs. LLVM c186282 <c186282@nnada.net> - 2026-11-02 20:47 -0500
                Re: GCC vs. LLVM Leroy H <lh@somewhere.net> - 2026-11-02 23:01 +0000
                  Re: GCC vs. LLVM c186282 <c186282@nnada.net> - 2026-11-02 21:03 -0500
                    Re: GCC vs. LLVM Leroy H <lh@somewhere.net> - 2026-11-03 02:44 +0000
    Re: Substantive Comments Please: GCC vs. LLMV Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-11-01 10:07 -0500
      Re: Substantive Comments Please: GCC vs. LLMV Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-01 18:31 +0000
        Re: Substantive Comments Please: GCC vs. LLMV Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-11-02 11:54 -0500
          Re: Substantive Comments Please: GCC vs. LLMV Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-11-02 14:18 -0500
            Re: Substantive Comments Please: GCC vs. LLMV rbowman <bowman@montana.com> - 2026-11-02 20:17 +0000
              Re: Substantive Comments Please: GCC vs. LLMV Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-11-03 08:22 -0500
                Re: Substantive Comments Please: GCC vs. LLMV Richard Kettlewell <invalid@invalid.invalid> - 2026-11-03 18:44 +0000
                  Re: Substantive Comments Please: GCC vs. LLMV Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-11-04 06:39 -0500
                    Re: Substantive Comments Please: GCC vs. LLMV The Natural Philosopher <tnp@invalid.invalid> - 2026-11-04 11:53 +0000

Page 2 of 2 — ← Prev page 1 [2]

#95077 — Re: GCC vs. LLVM

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> c186282 <c186282@nnada.net> writes:
>> Correct.  As per the 'tiny' bit, it's "cut down".  Has MOST of what 
>> you'll need, good enough for a lot of stuff, but if you're doing 
>> "cutting edge" then go with the bigger compilers and their libs.
> 
> You seem to be ignoring the fact that compilers (gcc, clang, tcc) are 
> compilers, and do not include most libraries.

SOL (Speed of Light) nym is our local human hallucinator.  It 
hallucinates more wrong stuff than all the best LLM's put together, 
except unlike the AI's it "sticks to it's hallucinations" when called 
out.

> Perhaps you have an example of a library that you can use with gcc
> and clang but can't use with tcc.

It will not be able to do so, because whatever point it is trying to make is very likely a 
hallucination.

[toc] | [prev] | [next] | [standalone]

#94956 — Re: GCC vs. LLVM

On 2026-11-02 07:52, c186282 wrote:
> On 11/1/26 23:25, Keith Thompson wrote:


>> (Why do you indent your original text in your posts?  I find it
>> distracting.)
> 
> That's "MY STYLE". Live with it. Keeps it more plain what others
> say, what I say. Also like 'random' capitalization and odd
> punctuation to kind-of emulate 'natural speaking'. You do it your
> way, I'll do it mine, and we'll all get there together.

Done. :-)




-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#94969 — Re: GCC vs. LLVM

On 11/2/26 17:16, Carlos E. R. wrote:
> On 2026-11-02 07:52, c186282 wrote:
>> On 11/1/26 23:25, Keith Thompson wrote:
> 
> 
>>> (Why do you indent your original text in your posts?  I find it
>>> distracting.)
>>
>> That's "MY STYLE". Live with it. Keeps it more plain what others
>> say, what I say. Also like 'random' capitalization and odd
>> punctuation to kind-of emulate 'natural speaking'. You do it your
>> way, I'll do it mine, and we'll all get there together.
> 
> Done. :-)

   Sounds good - I'm not out to troll/trash, just
   add my little bits to the overall equation.
   Know I'm not "superior", just have MY odd base
   of experience. Put everybody's "odd bases"
   together and ........

   Just think of it as "PYTHON Style" ... indents ! :-)

[toc] | [prev] | [next] | [standalone]

#94961 — Re: GCC vs. LLVM

On Sun, 01 Nov 2026 20:25:35 -0800, Keith Thompson wrote:

> 
> (Why do you indent your original text in your posts?  I find it
> distracting.)
> 

Ha, ha, ha, ha, ha, ha!  What a fucking fuddy-duddy!

If this were an actual public, and not virtual, meeting
place, people would be putting itching powder on your
stuffy skin.

<https://en.wikipedia.org/wiki/Itching_powder>

You are an unbelievable, tasteless throwback.

Ha, ha, ha, ha, ha, ha, ha, ha!

[toc] | [prev] | [next] | [standalone]

#94973 — Re: GCC vs. LLVM

On 11/2/26 18:01, Leroy H wrote:
> On Sun, 01 Nov 2026 20:25:35 -0800, Keith Thompson wrote:
> 
>>
>> (Why do you indent your original text in your posts?  I find it
>> distracting.)
>>
> 
> Ha, ha, ha, ha, ha, ha!  What a fucking fuddy-duddy!
> 
> If this were an actual public, and not virtual, meeting
> place, people would be putting itching powder on your
> stuffy skin.
> 
> <https://en.wikipedia.org/wiki/Itching_powder>
> 
> You are an unbelievable, tasteless throwback.
> 
> Ha, ha, ha, ha, ha, ha, ha, ha!

   Aww ... give him a break. The style - though old -
   is a bit odd. I think of it now as "Python Style",
   indents. DOES help make you/me stuff more obvious
   to the eye however.

   As said, we ALL have our quirks AND encyclopedia
   of experiences. Some ARE generally 'better' than
   others - but only a few of those are Superior
   Assholes dedicated to pissing on everyone else.

   If we all add our base of experiences - often
   stretching back 40-50 years - together more
   than one good fix for any particular issue
   can be found. SEEMS like the purpose of
   these groups.

[toc] | [prev] | [next] | [standalone]

#94981 — Re: GCC vs. LLVM

On Mon, 2 Nov 2026 21:03:28 -0500, c186282 wrote:

> On 11/2/26 18:01, Leroy H wrote:
>> On Sun, 01 Nov 2026 20:25:35 -0800, Keith Thompson wrote:
>> 
>>>
>>> (Why do you indent your original text in your posts?  I find it
>>> distracting.)
>>>
>> 
>> You are an unbelievable, tasteless throwback.
>> 
> 
>    Aww ... give him a break. 
>

No, no no, no. no, no.

Anyone who actually is more impressed with meaningless formatting
rather than message content is an inexcusable and infinite jerk.

This jerk deserves to be forever ridiculed and ostracized for his
idiotic attitude.

His momma obviously made him tuck his bed sheets upon rising in
the morning.

The term "dickhead" was invented specifically for his pedantic type.

 

[toc] | [prev] | [next] | [standalone]

#94891

Leroy H wrote this screed in ALL-CAPS (fixed):

> I should have, but I have never seriously researched the differences
> and advantages/disadvantages of the GNU Compiler Collection (GCC)
> versus the LLVM/Clang compiler (only the C compiler interests me).
>
> All of my GNU/Linux systems are built using GCC.  It has good
> hardware optimization options, Link Time Optimization (LTO), and
> even, if desired, Profile Guided Optimization (PGO).
>
> But LLVM/Clang has been around for a long while as an alternative
> C compiler.  I have never used LLVM/Clang but others will claim
> benefits and advantages.
>
> To me, LLVM/Clang seems limited compared to GCC, especially in terms
> of SIMD hardware support, but that assessment is based on incomplete
> knowledge.
>
> Can anyone offer more insight into this issue?
>
> Basically, which compiler is truly "better?"

My recent projects are set up to use either one. Clang seems to be
the "native" compiler on FreeBSD. GCC and Clang seem to me to be
comparable and somewhat supporting the same options. Clang seems
to increment versions more frequently.  It finds some issues that
g++ does not find, and g++ finds some issues that clang++ does
not. They're roughly comparable in speed if cache is dropped
between builds.

As far as hardware support and C go, I have nothing to add.
So sue me.

-- 
I wasn't kissing her, I was whispering in her mouth.
		-- Chico Marx

[toc] | [prev] | [next] | [standalone]

#94896

On 2026-11-01, Chris Ahlstrom wrote:

> Leroy H wrote this screed in ALL-CAPS (fixed):
>
>> I should have, but I have never seriously researched the differences
>> and advantages/disadvantages of the GNU Compiler Collection (GCC)
>> versus the LLVM/Clang compiler (only the C compiler interests me).
>>
>> All of my GNU/Linux systems are built using GCC.  It has good
>> hardware optimization options, Link Time Optimization (LTO), and
>> even, if desired, Profile Guided Optimization (PGO).
>>
>> But LLVM/Clang has been around for a long while as an alternative
>> C compiler.  I have never used LLVM/Clang but others will claim
>> benefits and advantages.
>>
>> To me, LLVM/Clang seems limited compared to GCC, especially in terms
>> of SIMD hardware support, but that assessment is based on incomplete
>> knowledge.
>>
>> Can anyone offer more insight into this issue?
>>
>> Basically, which compiler is truly "better?"
>
> My recent projects are set up to use either one. Clang seems to be
> the "native" compiler on FreeBSD. GCC and Clang seem to me to be
> comparable and somewhat supporting the same options. Clang seems
> to increment versions more frequently.  It finds some issues that
> g++ does not find, and g++ finds some issues that clang++ does
> not. They're roughly comparable in speed if cache is dropped
> between builds.

When you say "find issues" you mean merely in warning outputs or in
differences owing to UB, or are you using their static analyzers?

> As far as hardware support and C go, I have nothing to add.
> So sue me.

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#94942

Nuno Silva wrote this screed in ALL-CAPS (fixed):

> On 2026-11-01, Chris Ahlstrom wrote:
>
>> Leroy H wrote this screed in ALL-CAPS (fixed):
>>
>>> I should have, but I have never seriously researched the differences
>>> and advantages/disadvantages of the GNU Compiler Collection (GCC)
>>> versus the LLVM/Clang compiler (only the C compiler interests me).
>>>
>>> All of my GNU/Linux systems are built using GCC.  It has good
>>> hardware optimization options, Link Time Optimization (LTO), and
>>> even, if desired, Profile Guided Optimization (PGO).
>>>
>>> But LLVM/Clang has been around for a long while as an alternative
>>> C compiler.  I have never used LLVM/Clang but others will claim
>>> benefits and advantages.
>>>
>>> To me, LLVM/Clang seems limited compared to GCC, especially in terms
>>> of SIMD hardware support, but that assessment is based on incomplete
>>> knowledge.
>>>
>>> Can anyone offer more insight into this issue?
>>>
>>> Basically, which compiler is truly "better?"
>>
>> My recent projects are set up to use either one. Clang seems to be
>> the "native" compiler on FreeBSD. GCC and Clang seem to me to be
>> comparable and somewhat supporting the same options. Clang seems
>> to increment versions more frequently.  It finds some issues that
>> g++ does not find, and g++ finds some issues that clang++ does
>> not. They're roughly comparable in speed if cache is dropped
>> between builds.
>
> When you say "find issues" you mean merely in warning outputs or in
> differences owing to UB, or are you using their static analyzers?

Just looking at warnings.

Using "ninja scan-build" just now to see what happens.

-- 
BOFH excuse #62:
 
Need to wrap system in aluminum foil to fix problem

[toc] | [prev] | [next] | [standalone]

#94947

Chris Ahlstrom wrote this screed in ALL-CAPS (fixed):

> Nuno Silva wrote this screed in ALL-CAPS (fixed):
>
>> On 2026-11-01, Chris Ahlstrom wrote:
>>
>>> <snip>
>>>
>> When you say "find issues" you mean merely in warning outputs or in
>> differences owing to UB, or are you using their static analyzers?
>
> Just looking at warnings.
>
> Using "ninja scan-build" just now to see what happens.

It found a few issues in a couple of my projects, a few issues
important. There is one that I don't get

   subprojects/libcfg66/src/util/filefunctions.cpp:1138:33:
   warning: Memory allocated by 'new[]' should be deallocated by 'delete[]',
   not 'getline()' [unix.MismatchedDeallocator] 

 1138 |   ssize_t count { getline(&destination, &maxim, input) };
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I guess I need to use malloc() instead.

-- 
Mummy dust to make me old;
To shroud my clothes, the black of night;
To age my voice, an old hag's cackle;
To whiten my hair, a scream of fright;
A blast of wind to fan my hate;
A thunderbolt to mix it well --
Now begin thy magic spell!
		-- Walter Disney, "Snow White"

[toc] | [prev] | [next] | [standalone]

#94952

On Mon, 2 Nov 2026 14:18:27 -0500, Chris Ahlstrom wrote:

> It found a few issues in a couple of my projects, a few issues
> important.
> There is one that I don't get
> 
>    subprojects/libcfg66/src/util/filefunctions.cpp:1138:33: warning:
>    Memory allocated by 'new[]' should be deallocated by 'delete[]',
>    not 'getline()' [unix.MismatchedDeallocator]
> 
>  1138 |   ssize_t count { getline(&destination, &maxim, input) };
>       |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> I guess I need to use malloc() instead.

Did you allocate destination with new? getline will malloc a buffer if you 
pass in NULL. 

[toc] | [prev] | [next] | [standalone]

#95009

rbowman wrote this screed in ALL-CAPS (fixed):

> On Mon, 2 Nov 2026 14:18:27 -0500, Chris Ahlstrom wrote:
>
>> It found a few issues in a couple of my projects, a few issues
>> important.
>> There is one that I don't get
>> 
>>    subprojects/libcfg66/src/util/filefunctions.cpp:1138:33: warning:
>>    Memory allocated by 'new[]' should be deallocated by 'delete[]',
>>    not 'getline()' [unix.MismatchedDeallocator]
>> 
>>  1138 |   ssize_t count { getline(&destination, &maxim, input) };
>>       |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> I guess I need to use malloc() instead.
>
> Did you allocate destination with new? getline will malloc a buffer if you 
> pass in NULL. 

Yes, and I know that from the man page.

The point is scan-build complaining about something getline() will
not do in the given use case.

A limitation of static analysis, perhaps.

-- 
<Stealth> How do I bind a computer to an NIS server?
<Joey> Use a rope?
		-- Seen on #Debian

[toc] | [prev] | [next] | [standalone]

#95025

Chris Ahlstrom <OFeem1987@teleworm.us> writes:
> rbowman wrote this screed in ALL-CAPS (fixed):
>> On Mon, 2 Nov 2026 14:18:27 -0500, Chris Ahlstrom wrote:
>>> It found a few issues in a couple of my projects, a few issues
>>> important.
>>> There is one that I don't get
>>> 
>>>    subprojects/libcfg66/src/util/filefunctions.cpp:1138:33: warning:
>>>    Memory allocated by 'new[]' should be deallocated by 'delete[]',
>>>    not 'getline()' [unix.MismatchedDeallocator]
>>> 
>>>  1138 |   ssize_t count { getline(&destination, &maxim, input) };
>>>       |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> 
>>> I guess I need to use malloc() instead.
>>
>> Did you allocate destination with new? getline will malloc a buffer
>> if you pass in NULL.
>
> Yes, and I know that from the man page.
>
> The point is scan-build complaining about something getline() will
> not do in the given use case.
>
> A limitation of static analysis, perhaps.

There’s not enough context to give a completely definitive answer, but:

1) Heap memory can be managed with new/delete, or with
   malloc/realloc/free, but not both. The consequences of playing
   mix-and-match vary between platform, so you might get away with it in
   some cases, by luck, but static analysis tools will consider it a
   bug, if they’re smart enough to notice.

2) In getline(), if *lineptr!=NULL then it will call realloc() on it if
   the line from stream needs more than *n bytes (using argument names
   from [1]). So passing a pointer allocated with new to it is a bug,
   for the reasons given in (1) above.

3) The diagnostic referring to deallocation reather than realloc is
   probably a (trivial) bug in the tool - for example it may model
   realloc as malloc+free, which isn’t unreasonable as such, but leads
   to an opaque diagnostic.

The only case where it would not be a bug is if the line read by
getline() can never possibly exceed the initial allocation. Whether this
is true in your use case I don’t know, but your static analysis tool
either couldn’t prove that it was or more likely, isn’t equipped to do
so.

[1] https://man7.org/linux/man-pages/man3/getline.3.html

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#95098

Richard Kettlewell wrote this screed in ALL-CAPS (fixed):

> Chris Ahlstrom <OFeem1987@teleworm.us> writes:
>> rbowman wrote this screed in ALL-CAPS (fixed):
>>> On Mon, 2 Nov 2026 14:18:27 -0500, Chris Ahlstrom wrote:
>>>> It found a few issues in a couple of my projects, a few issues
>>>> important.
>>>> There is one that I don't get
>>>> 
>>>>    subprojects/libcfg66/src/util/filefunctions.cpp:1138:33: warning:
>>>>    Memory allocated by 'new[]' should be deallocated by 'delete[]',
>>>>    not 'getline()' [unix.MismatchedDeallocator]
>>>> 
>>>>  1138 |   ssize_t count { getline(&destination, &maxim, input) };
>>>>       |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> 
>>>> I guess I need to use malloc() instead.
>>>
>>> Did you allocate destination with new? getline will malloc a buffer
>>> if you pass in NULL.
>>
>> Yes, and I know that from the man page.
>>
>> The point is scan-build complaining about something getline() will
>> not do in the given use case.
>>
>> A limitation of static analysis, perhaps.
>
> There’s not enough context to give a completely definitive answer, but:
>
> 1) Heap memory can be managed with new/delete, or with
>    malloc/realloc/free, but not both. The consequences of playing
>    mix-and-match vary between platform, so you might get away with it in
>    some cases, by luck, but static analysis tools will consider it a
>    bug, if they’re smart enough to notice.

The tool is clang's scan-build. Fortunately, meson automatically
sets a build to use it if it is installed. Otherwise I'd be too
damned lazy to use it :-D

> 2) In getline(), if *lineptr!=NULL then it will call realloc() on it if
>    the line from stream needs more than *n bytes (using argument names
>    from [1]). So passing a pointer allocated with new to it is a bug,
>    for the reasons given in (1) above.
>
> 3) The diagnostic referring to deallocation reather than realloc is
>    probably a (trivial) bug in the tool - for example it may model
>    realloc as malloc+free, which isn’t unreasonable as such, but leads
>    to an opaque diagnostic.
>
> The only case where it would not be a bug is if the line read by
> getline() can never possibly exceed the initial allocation. Whether this
> is true in your use case I don’t know, but your static analysis tool
> either couldn’t prove that it was or more likely, isn’t equipped to do
> so.
>
> [1] https://man7.org/linux/man-pages/man3/getline.3.html

I bit the bullet and went to malloc()/free().

Now I got a couple of "Method called on moved-from object"
warnings to fix. (A needless test of movement in a test app.)

-- 
I will not play at tug o' war.  I'd rather play at hug o' war,
Where everyone hugs Instead of tugs,
Where everyone giggles And rolls on the rug,
Where everyone kisses, And everyone grins,
And everyone cuddles, And everyone wins.
		-- Shel Silverstein, "Hug o' War"

[toc] | [prev] | [next] | [standalone]

#95099

On 04/11/2026 11:39, Chris Ahlstrom wrote:
> I will not play at tug o' war.  I'd rather play at hug o' war,
> Where everyone hugs Instead of tugs,
> Where everyone giggles And rolls on the rug,
> Where everyone kisses, And everyone grins,
> And everyone cuddles, And everyone wins.
> 		-- Shel Silverstein, "Hug o' War"

Penicillin Penny, she's the queen of the Sunset Strip
If she ever gives you any then you better see your doctor real quick, 
gettin' bizarre
 From the back seat of Cadillac cars, to the floor of men's room bars
She's Penicillin Penny and her future's written in the stars

She's Penicillin Penny and ever since the day she came, came
They say she's had so many, she gives 'em all numbers not names, bitch
I always call her Hun' (honey), but she calls me one thousand and one
And Penicillin Penny starts to boogie when the day is done

Bring on the claps

She's Penicillin Penny and if you ever see her passin' through
Better run into your house before she stops and lays a little on you
If you ever let her in your door, it takes 20 million units
Or more to cure the love that Penicillin Penny's gonna lay on you

	-- Shel Silverstein, "Penicillin Penny"
-- 
Civilization exists by geological consent, subject to change without notice.
  – Will Durant

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.misc

csiph-web