GCC 11.4 Released

[Jakub Jelinek via Gcc]

The GNU Compiler Collection version 11.4 has been released.

GCC 11.4 is the first bug-fix release from the GCC 11 branch containing
important fixes for regressions and serious bugs in GCC 11.3 with more
than 110 bugs fixed since the previous release.

This release is available from the WWW servers listed here:

 https://sourceware.org/pub/gcc/releases/gcc-11.4.0/
 https://gcc.gnu.org/mirrors.html

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!

Testing a patch

[Benjamin Priour via Gcc]

Hi,

Regstrapping finally done for PR109439 - Spurious
-Wanalyzer-use-of-uninitialized-value tagging along
-Wanalyzer-out-of-bounds.
Now only a OOB warning is reported when necessary instead of OOB + Use
of uninitialized value.

Some tests in analyzer (out-of-bounds-*, realloc-5, pr101962) were
checking for the now removed use-of-uninitialized-value warning, and
therefore I fixed that.

But now I'm confused since the documentation reads that to perform
regtesting, one should use make -k check,
and that's what I always use too, but because I fixed the above test
files, contrib/compare_tests obviously complains about them having
disappeared.
Does it mean regtesting failed ? Can I submit the patch in its current
state or should I do something else before doing so ?
Guess I would get feedback anyway if something's wrong.

I figured I would send it here rather than to gcc-patches, as it's
more general than a discussion over a single patch.

Thanks,
Benjamin

GCC 11.4 documentation 404's

[Felix LeClair via Gcc]

Hi everyone, 

Quick note that it seems like the freshly updated docs for GCC 11.4 seem to be 
hitting a 404 error when attempting to access them. 

Links that 404 for me: 

https://gcc.gnu.org/onlinedocs/gcc-11.4.0/gcc/
https://gcc.gnu.org/onlinedocs/gcc-11.4.0/libquadmath/

quick way to get there: 

https://gcc.gnu.org/gcc-11/ 
followed by 
https://gcc.gnu.org/onlinedocs/11.4.0/
at which point tabbing/clicking over any of the docs will return a 404

Cheers and happy Monday, 

Felix LeClair 
(mastodon: https://mast.hpc.social/@fclc)

Re: GCC 11.4 documentation 404's

[Jakub Jelinek via Gcc]

On Mon, May 29, 2023 at 02:50:06PM +, Felix LeClair via Gcc wrote:
> Hi everyone, 
> 
> Quick note that it seems like the freshly updated docs for GCC 11.4 seem to 
> be hitting a 404 error when attempting to access them. 
> 
> Links that 404 for me: 
> 
> https://gcc.gnu.org/onlinedocs/gcc-11.4.0/gcc/
> https://gcc.gnu.org/onlinedocs/gcc-11.4.0/libquadmath/
> 
> quick way to get there: 
> 
> https://gcc.gnu.org/gcc-11/ 
> followed by 
> https://gcc.gnu.org/onlinedocs/11.4.0/
> at which point tabbing/clicking over any of the docs will return a 404

Sorry, the command to generate those I've run earlier today must have then
failed, possibly because of the incorrect permissions temporary directory
issue in the repo we had since Saturday.
I've rerun it now and it worked.
Note, libstdc++ documentation isn't there yet, that will need to wait till
tomorrow because UK has public holiday today.

Jakub

Who cares about size? (was: Who cares about performance (or Intel's CPU errata)?)

[Stefan Kanthak]

"Andrew Pinski"  wrote:

> On Sat, May 27, 2023 at 3:54 PM Stefan Kanthak  
> wrote:

>> Nevertheless GCC fails to optimise code properly:
>>
>> --- .c ---
>> int ispowerof2(unsigned long long argument) {
>> return __builtin_popcountll(argument) == 1;
>> }
>> --- EOF ---
>>
>> GCC 13.3gcc -m32 -mpopcnt -O3
>>
>> https://godbolt.org/z/fT7a7jP4e
>> ispowerof2(unsigned long long):
>> xor eax, eax
>> xor edx, edx
>> popcnt  eax, [esp+4]
>> popcnt  edx, [esp+8]
>> add eax, edx # eax is less than 64!
>> cmp eax, 1->dec eax  # 2 bytes shorter
   seteal
   movzx   eax, al
   ret
>
> dec eax is done for -Os already.
> -O2 means performance, it does not mean decrease size.

But -Os is supposed to optimise for size? REALITY CHECK:

GCC 13.3gcc -m32 -mpopcnt -Os

https://godbolt.org/z/41Ed6rr6r
ispowerof2(unsigned long long):
pushebp
mov ebp, esp
sub esp, 16
push[ebp+12]
push[ebp+8]
call__popcountdi2
add esp, 16# superfluous!
leave
dec eax
seteal
movzx   eax, al
ret

While -O3 generates 9 instructions in a total of 24 bytes,
-Os[lowmotion] but generates 12 instructions in 29 bytes,
PLUS the uncounted instructions/bytes of __popcountdi2()!

This is what I call an EPIC FAILURE!

Stefan

Re: Another epic optimiser failure

[Dave Blanchard]

On Sun, 28 May 2023 15:50:41 +0800
Julian Waters via Gcc  wrote:

> Man, these clang fanboys sure are getting out of hand

Strange reasoning you've used here. Is this sort of like how if I'm against 
Donald Trump, then I must be for Hillary Clinton, or vice versa?

That's called a "false dichotomy" FYI.

> I feel like all this garbage can be easily resolved by y'all showing this
> idiot

There's your first mistake. Hint: people who are able to hand deconstruct the 
output of a compiler's code generator and point out exactly how instructions 
are wasted are never correctly referred to as an "idiot", in the context of 
computer programming at least.

He's certainly got a few things wrong from time to time in his zeal, but his 
overall point seems to stand. Do you have any rebuttals of his argument to 
present yourself? Or do you prefer to just sit back and wait on "y'all" to do 
the heavy lifting?

> the exact proper options required 

You mean the ones which are unclear and uncertain, because the GCC 
documentation is inaccurate or simply lies?

> and attaching the resulting compiled assembly exactly as he wants it

And what if GCC is unable to produce anything like that, because the code 
generator is at the very least questionable, as his postings seems to prove?

> or if gcc doesn't compile the exact assembly he wants, explaining why gcc 
> chose a different
> route than the quote on quote "Perfect assembly" that he expects it to spit
> out

What version of GCC can we expect to generate efficient and correct code for 
this brand new, just-released "x86" instruction set? Maybe GCC 97 will finally 
get it right...which at the current rate of major version number increase, 
should be some time next year I guess.

Or rather more accurately, when will GCC's code generator stop regressing as it 
seemingly has done for many versions now, and finally Make Compiling Great 
Again?

> And Stefan? Ever heard of the saying that "the loudest man in the room is
> always the weakest"?

Ever heard the saying "if you can't run with the big dogs, stay under the 
porch"?

Are the GCC developers *trying* to subtly push everyone toward Clang, by slowly 
degrading GCC over time in hopes that people will eventually give up and leave 
in frustration? Serious question. 

Dave

gcc-14-20230529 is now available

[GCC Administrator via Gcc]

Snapshot gcc-14-20230529 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/14-20230529/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision a1806f0918c0d3612c99b6193b9703d4b4c82c21

You'll find:

 gcc-14-20230529.tar.xz   Complete GCC

  SHA256=720147b489002b5da8d12a47085485dfec24f62ab5d4f7b443ccedfdc094492e
  SHA1=80c4af6ce595a5ad287783eee7e133cca02b4884

Diffs from 14-20230521 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-14
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: LSP based on GCC

[Alexandre Oliva via Gcc]

On May 17, 2023, Arsen Arsenović  wrote:

> ISTR Alexandre Oliva (CC added) mentioning leveraging GDB to implement
> various bits of LSP functionality, such as handling multiple TUs.  This
> sounds like a good idea to me (at least at a high level), as it could
> lead to the hypothetical GNU toolchain LSP implementation being
> partially language-agnostic (naturally, some things like candidate lists
> would still need language support, as well as documentation parsing,
> ...), which would be quite handy.

> Do you happen to have any memory of that?

I recall advancing that suggestion, reasoning that GDB was capable of
combining information from multiple translation units and of reloading
debug information, which GCC doesn't.  But that was mainly a hunch that
it could work, not something based on extensive knowledge of GDB or LSP.
Details were all yet to be figured out.  I expected there'd be a need
for additional debug information to be emitted.  I wasn't sure how to
approach the issue of translation units that wouldn't compile or link
successfully yet.  There are many thorny issues to be sorted out.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: Another epic optimiser failure

[Nicholas Vinson via Gcc]

On 5/29/23 15:01, Dave Blanchard wrote:


He's certainly got a few things wrong from time to time in his zeal, but his overall 
point seems to stand. Do you have any rebuttals of his argument to present yourself? Or 
do you prefer to just sit back and wait on "y'all" to do the heavy lifting?


He's gotten many details wrong including the proper flags to set for gcc 
(and the "bad documentation" does not justify all the errors he's made), 
his hand-generated assembly (I've personally pointed out logic errors in 
his assembly on more than on occasion), and has failed to provide 
evidence that his solutions are better.


In almost all of his examples, he uses -O3 which is basically the "speed 
above all else" optimization level. I pointed this out before; I also 
pointed out that the smallest code (in bytes) with the fewest 
instructions is not always the fastest. He has not provided any data 
showing that his solutions result in faster executing code than what gcc 
produces. He has also raised questions that show a distinct lack of 
understanding when it comes to storage hierarchy; something I feel one 
would need to know to properly write fast assembly. Finally, I will 
admit some of the examples of gcc produced code are a bit suspicious, 
and probably should be reviewed.


In short Stefan is not being taken seriously because he is not 
presenting himself, or his arguments, in a manner that would convince 
people to take him seriously. As long as Stefan continues to communicate 
in such a manner, we're going to see similar such responses from (some 
of) the gcc devs (unfortunately).


The best next steps for Stefan, would be to review the constructive 
criticism, expand on his examples by providing explanation and proof as 
to why they're better, and then present these updated findings in the 
proper manner.


Using his first example as my own, take the C code:

int ispowerof2(unsigned long long argument)
{
return (argument & argument - 1) == 0;
}

when compiled produces:

% gcc -m32 -O3 -c ispowerof2.c && objdump -d -Mintel ispowerof2.o

ispowerof2.o: file format elf32-i386

Disassembly of section .text:

 :
   0:   f3 0f 7e 4c 24 04   movq   xmm1,QWORD PTR [esp+0x4]
   6:   66 0f 76 c0 pcmpeqd xmm0,xmm0
   a:   66 0f d4 c1 paddq  xmm0,xmm1
   e:   66 0f db c1 pand   xmm0,xmm1
  12:   66 0f 7e c2 movd   edx,xmm0
  16:   66 0f 73 d0 20  psrlq  xmm0,0x20
  1b:   66 0f 7e c0 movd   eax,xmm0
  1f:   09 c2   or edx,eax
  21:   0f 94 c0    sete   al
  24:   0f b6 c0    movzx  eax,al
  27:   c3  ret

Whereas he claims the following is better:

movq    xmm1, [esp+4]
pcmpeqd xmm0, xmm0
paddq   xmm0, xmm1
pand    xmm0, xmm1
pxor    xmm1, xmm1
pcmpeqb xmm0, xmm1
pmovmskb eax, xmm0
cmp al, 255
sete    al
ret

because it has 10 instructions and is 36 bytes long vs the 11 
instructions and 40 bytes. However, the rebuttals are 1. his code is 
wrong (can return values other than 0 or 1) and 2. -O3 doesn't optimize 
on instruction count or  byte size (as an aside: clang's output uses 14 
instructions but is only 32 bytes in size -- is it better or worse than 
gcc's?).


Therefore, while he's 1 instruction less and 4 bytes fewer (1 byte fewer 
if you add the needed correction), he presents no evidence that his 
solution is actually faster. What he would need to do instead is show 
proof that his solution is indeed faster than what gcc produces.


Afterwards, he would be in a position to represent this data in a proper 
manner.

Re: Another epic optimiser failure

[Julian Waters via Gcc]

"There's your first mistake. Hint: people who are able to hand deconstruct
the output of a compiler's code generator and point out exactly how
instructions are wasted are never correctly referred to as an "idiot", in
the context of computer programming at least."

gdb -batch -ex 'set disassembly-flavor intel' -ex 'file /bin/ls' -ex
'disassemble method'


Being able to run a disassembler does not make you intelligent or hot shit ;)

"Strange reasoning you've used here. Is this sort of like how if I'm
against Donald Trump, then I must be for Hillary Clinton, or vice
versa?


That's called a "false dichotomy" FYI."


Literally a few sentences later:


"Are the GCC developers *trying* to subtly push everyone toward Clang,
by slowly degrading GCC over time in hopes that people will eventually
give up and leave in frustration? Serious question."


"You mean the ones which are unclear and uncertain, because the GCC
documentation is inaccurate or simply lies?"


I will concede that gcc's documentation is pretty horrible, but that's
the exact reason I asked the gcc developers

and maintainers to list the options out here instead. Maybe you need
to brush up on your comprehension skills?

"Do you have any rebuttals of his argument to present yourself? Or do
you prefer to just sit back and wait on "y'all" to do the heavy
lifting?"

I would, if he hadn't already been absolutely schooled in more recent
replies pointing out why gcc produces certain code sequences.

At least he had the maturity to apologize and make his leave once he
found out he had made several mistakes, unlike

a certain someone I'm speaking to right now. And the few corner cases
he mentions that are valid he didn't even bother

filing a bug report, but instead resorted to endlessly screaming on a
mailing list without letting anyone talk to

him properly.


"What version of GCC can we expect to generate efficient and correct
code for this brand new, just-released "x86" instruction set? Maybe
GCC 97 will finally get it right...which at the current rate of major
version number increase, should be some time next year I guess.

Or rather more accurately, when will GCC's code generator stop
regressing as it seemingly has done for many versions now, and finally
Make Compiling Great Again?"

Again, you may want to look at the more recent code snippets posted
after the main argument got sidetracked, I don't

even have to do anything, hilariously enough.


It's also amazing how you managed to overpoliticize the rest of your
post after using that criticism against me

initially, how ironic.


"Ever heard the saying "if you can't run with the big dogs, stay under
the porch"?"

You think you're one of the big dogs? Pffft, that's cute.


I have no interest in getting into a compiler pissing match past this
point, so be on your way. Go annoy other people instead with

your garbage.


On Tue, May 30, 2023 at 2:59 AM Dave Blanchard  wrote:

> On Sun, 28 May 2023 15:50:41 +0800
> Julian Waters via Gcc  wrote:
>
> > Man, these clang fanboys sure are getting out of hand
>
> Strange reasoning you've used here. Is this sort of like how if I'm
> against Donald Trump, then I must be for Hillary Clinton, or vice versa?
>
> That's called a "false dichotomy" FYI.
>
> > I feel like all this garbage can be easily resolved by y'all showing this
> > idiot
>
> There's your first mistake. Hint: people who are able to hand deconstruct
> the output of a compiler's code generator and point out exactly how
> instructions are wasted are never correctly referred to as an "idiot", in
> the context of computer programming at least.
>
> He's certainly got a few things wrong from time to time in his zeal, but
> his overall point seems to stand. Do you have any rebuttals of his argument
> to present yourself? Or do you prefer to just sit back and wait on "y'all"
> to do the heavy lifting?
>
> > the exact proper options required
>
> You mean the ones which are unclear and uncertain, because the GCC
> documentation is inaccurate or simply lies?
>
> > and attaching the resulting compiled assembly exactly as he wants it
>
> And what if GCC is unable to produce anything like that, because the code
> generator is at the very least questionable, as his postings seems to prove?
>
> > or if gcc doesn't compile the exact assembly he wants, explaining why
> gcc chose a different
> > route than the quote on quote "Perfect assembly" that he expects it to
> spit
> > out
>
> What version of GCC can we expect to generate efficient and correct code
> for this brand new, just-released "x86" instruction set? Maybe GCC 97 will
> finally get it right...which at the current rate of major version number
> increase, should be some time next year I guess.
>
> Or rather more accurately, when will GCC's code generator stop regressing
> as it seemingly has done for many versions now, and finally Make Compiling
> Great Again?
>
> > And Stefan? Ever heard of the saying that "the loudest man in the room is
> > always the wea