[Bug rtl-optimization/110867] [14 Regression] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867

Xi Ruoyao  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #12 from Xi Ruoyao  ---
Mistakenly marked it as dup.

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869

Xi Ruoyao  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||xry111 at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #20 from Xi Ruoyao  ---
Marking as fixed as the patch is already pushed.

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
Bug 110869 depends on bug 110867, which changed state.

Bug 110867 Summary: [14 Regression] ICE in combine after 
7cdd0860949c6c3232e6cff1d7ca37bb5234074c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug rtl-optimization/110939] [14 Regression] 14.0 ICE at rtl.h:2297 while bootstrapping on loongarch64

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939

Xi Ruoyao  changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #16 from Xi Ruoyao  ---
*** Bug 110867 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/110864] [14 Regression] ICE in combine.cc causes stage2 build failure on RISCV

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110864
Bug 110864 depends on bug 110867, which changed state.

Bug 110867 Summary: [14 Regression] ICE in combine after 
7cdd0860949c6c3232e6cff1d7ca37bb5234074c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug rtl-optimization/110867] [14 Regression] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867

Xi Ruoyao  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #11 from Xi Ruoyao  ---
The patch is pushed at r14-4355.

*** This bug has been marked as a duplicate of bug 110939 ***

[Bug rtl-optimization/110939] [14 Regression] 14.0 ICE at rtl.h:2297 while bootstrapping on loongarch64

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939

Xi Ruoyao  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #15 from Xi Ruoyao  ---
*** Bug 71 has been marked as a duplicate of this bug. ***

[Bug target/111171] [14 Regression] ICE: in decompose, at rtl.h:2297 at -O1 on riscv64-unknown-linux-gnu

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71

Xi Ruoyao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Xi Ruoyao  ---
The patch is pushed, marking this as a dup of PR110939.

*** This bug has been marked as a duplicate of bug 110939 ***

[Bug rtl-optimization/110939] [14 Regression] 14.0 ICE at rtl.h:2297 while bootstrapping on loongarch64

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939

Xi Ruoyao  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Xi Ruoyao  ---
Fixed at r14-4355:

commit 86b2ffc0b8334c86ed13974f7d986821040474a4
Author: Stefan Schulze Frielinghaus 
Date:   Sun Oct 1 16:11:32 2023 +0200

rtl-optimization/110939 Really fix narrow comparison of memory and constant

In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
completely missed the fact that the normal form of a CONST_INT for a
mode with fewer bits than in HOST_WIDE_INT is a sign extended version of
the actual constant.  This even holds true for unsigned constants.

Fixed by masking out the upper bits for the incoming constant and sign
extending the resulting unsigned constant.

gcc/ChangeLog:

* combine.cc (simplify_compare_const): Properly handle unsigned
constants while narrowing comparison of memory and constants.

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

[tanksherman27 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #8 from Julian Waters  ---
I have a patch ready for the noreturn warning at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654, is anyone willing to help
review and push it?

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

Xi Ruoyao  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #16 from Xi Ruoyao  ---
Marking it P1 as it's breaking bootstrap on various conditions.

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #15 from Xi Ruoyao  ---
(In reply to Richard Sandiford from comment #13)
> Created attachment 56023 [details]
> Tentative fix
> 
> Sorry for the radio silence, had a network outage.  I'm testing the
> attached, which if it works would avoid resorting to the preprocessor.

Works for me too.  I ran into this issue when I tried to build GCC on a dev
workstation where host GCC was configured with --enable-checking=yes,extra.

[Bug rtl-optimization/110939] [14 Regression] 14.0 ICE at rtl.h:2297 while bootstrapping on loongarch64

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939

--- Comment #13 from Xi Ruoyao  ---
The patch is pushed.  I'm running a bootstrap and I'll close this PR after it
successes.

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

[slyfox at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

--- Comment #14 from Sergei Trofimovich  ---
(In reply to Richard Sandiford from comment #13)
> Created attachment 56023 [details]
> Tentative fix

Re " That now triggers a warning
in some configurations, since the NUM_POLY_INT_COEFFS>1 tests
used the global poly_int64, whose definition does not depend
on the template parameter."

Minor note: it's a type error for clang++ and g++ -fchecking=2, not just a
warning. I think both gcc and clang do reject the code as they see a type
mismatch in `poly_int64<1, T>(1,1)` call.

Otherwise the fix works for me and passes `make bootstrap4`. Thank you!

[Bug c++/111660] [14 Regression] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[envia at envia dot pe.kr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

--- Comment #10 from Hwang Joonhyung  ---
(In reply to Andrew Pinski from comment #5)
> Note for non-C++11 constexpr, using switch here would most likely be better .

Thank you for the comment. It helped me to solve my problem.

[Bug c++/111660] [14 Regression] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[envia at envia dot pe.kr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

--- Comment #9 from Hwang Joonhyung  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Hwang Joonhyung from comment #0)
> > It took more than 30 minutes when I compiled testcase.cc with g++ 14.0.0
> > 20231001 on Debian GNU/Linux 12 with -std=gnu++2a (or gnu++20, c++2a, 
> > c++20).
> > I guess it is a regression because it finishes within 0.1 second with g++
> > 13.2.0 or 12.3.0.
> > The testcase is based on GetOneCharToken() of V8.
> 
> Does -fno-checking solve the performance issue?

No. It took almost the same time. I used -std=gnu++2a -fno-checking.

[Bug c++/111660] [14 Regression] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-02
   Target Milestone|--- |14.0
Summary|Compilation of constexpr|[14 Regression] Compilation
   |function returning enum |of constexpr function
   |takes exponential time with |returning enum takes
   |-std=c++2a  |exponential time with
   ||-std=c++2a

--- Comment #8 from Andrew Pinski  ---
I suspect r14-4140-g6851e3423c2b5e introduced the compile time slowness.

[Bug c++/111660] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

--- Comment #7 from Andrew Pinski  ---
  38.25%  cc1plus  cc1plus   [.] walk_tree_1
  34.60%  cc1plus  cc1plus   [.] cp_fold_immediate_r
  20.08%  cc1plus  cc1plus   [.] cp_walk_subtrees

[Bug c++/111660] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

--- Comment #6 from Andrew Pinski  ---
(In reply to Hwang Joonhyung from comment #0)
> It took more than 30 minutes when I compiled testcase.cc with g++ 14.0.0
> 20231001 on Debian GNU/Linux 12 with -std=gnu++2a (or gnu++20, c++2a, c++20).
> I guess it is a regression because it finishes within 0.1 second with g++
> 13.2.0 or 12.3.0.
> The testcase is based on GetOneCharToken() of V8.

Does -fno-checking solve the performance issue?

[Bug c++/111660] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

--- Comment #5 from Andrew Pinski  ---
Note for non-C++11 constexpr, using switch here would most likely be better .

[Bug c++/111660] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[envia at envia dot pe.kr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

--- Comment #4 from Hwang Joonhyung  ---
I can see the time spent changes exponentially when I change the number of
ternary operators in the constexpr function.

[Bug c++/111660] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[envia at envia dot pe.kr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

--- Comment #3 from Hwang Joonhyung  ---
Created attachment 56027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56027=edit
It took 36 seconds.

[Bug c++/111660] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[envia at envia dot pe.kr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

--- Comment #2 from Hwang Joonhyung  ---
Created attachment 56026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56026=edit
It took 70 seconds.

[Bug c++/111660] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[envia at envia dot pe.kr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

--- Comment #1 from Hwang Joonhyung  ---
Created attachment 56025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56025=edit
It took 138 seconds.

[Bug c++/111660] New: Compilation of constexpr function returning enum takes exponential time with -std=c++2a

[envia at envia dot pe.kr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660

Bug ID: 111660
   Summary: Compilation of constexpr function returning enum takes
exponential time with -std=c++2a
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: envia at envia dot pe.kr
  Target Milestone: ---

Created attachment 56024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56024=edit
It took more than 30 minutes.

It took more than 30 minutes when I compiled testcase.cc with g++ 14.0.0
20231001 on Debian GNU/Linux 12 with -std=gnu++2a (or gnu++20, c++2a, c++20).
I guess it is a regression because it finishes within 0.1 second with g++
13.2.0 or 12.3.0.
The testcase is based on GetOneCharToken() of V8.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[eggert at cs dot ucla.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #20 from Paul Eggert  ---
(In reply to jos...@codesourcery.com from comment #14)
> This is just the same as other unspecified things like converting an 
> out-of-range value from floating-point to integer.
No, because when GCC's constant folding disagrees with machine arithmetic, GCC
can generate code that violates the relevant standards.

Here's an example taken from Bug 111655:

  int
  main ()
  {
double x = 0.0 / 0.0;
return !__builtin_signbit (x) == !__builtin_signbit (-x);
  }

'main' must return 0 no matter what x's sign happens to be, because "-x" must
flip x's sign bit, so __builtin_signbit(-x) must yield the opposite result from
__builtin_signbit(x). However, this code returns 1 with gcc (GCC) 13.2.1
20230728 (Red Hat 13.2.1-1) on x86-64, compiled with -O2.

The bug occurs because the evaluation of __builtin_signbit (x) is
constant-folded to 0 (under the assumption that 0.0/0.0 yields +NaN), whereas
the evaluation of __builtin_signbit (-x) iuses machine arithmetic to first
calculate 0.0/0.0 (i.e., -NaN), then negate that to +NaN, and then calculate
its sign bit to be 0.

At least for this particular example, GCC is generating the wrong code so this
bug report should be decorated with a "wrong-code" keyword.

[Bug c++/111651] Specific syntax with C++ 20 designated initializers and coroutines breaks

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111651

--- Comment #3 from Andrew Pinski  ---
Reducing ...

[Bug middle-end/111659] document that -Wstrict-flex-arrays depends on -ftree-vrp

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111659

--- Comment #2 from Andrew Pinski  ---
That is:
It is more effective when -ftree-vrp is active (the default for -O2 and above)
but a subset of instances are issued even without optimization.

[Bug middle-end/111659] document that -Wstrict-flex-arrays depends on -ftree-vrp

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111659

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-10-02
 Status|UNCONFIRMED |NEW
  Component|other   |middle-end

--- Comment #1 from Andrew Pinski  ---
Should be a similar wording as -Warray-bounds :
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Warray-bounds

[Bug middle-end/64928] [11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[lucier at math dot purdue.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928

--- Comment #45 from lucier at math dot purdue.edu ---
I confirm that I no longer have this problem with

> gcc-12 -v
Using built-in specs.
COLLECT_GCC=gcc-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04) 

A different example procedure still took > 45 minutes and > 3.5 GB to compile
with -ftest-coverage -fprofile-arcs (it had finished when I came back from
lunch) but it was quite large (even by my standards!).

If this is a "won't fix" for earlier versions of gcc, then I'm OK with closing
this PR.

[Bug other/111659] New: document that -Wstrict-flex-arrays depends on -ftree-vrp

[crrodriguez at opensuse dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111659

Bug ID: 111659
   Summary: document that -Wstrict-flex-arrays depends on
-ftree-vrp
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crrodriguez at opensuse dot org
  Target Milestone: ---

For -Wstrict-flex-arrays to be useful -ftree-vrp must be on..which is not the
case when building with -Og or -O1 .

It will be nice for this to be documented everywhere this option is mentioned
so people do not bang their heads against the table like me wondering why Im
getting no warnings on obvious code.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

Andrew Pinski  changed:

   What|Removed |Added

 CC||eggert at cs dot ucla.edu

--- Comment #19 from Andrew Pinski  ---
*** Bug 111655 has been marked as a duplicate of this bug. ***

[Bug testsuite/111658] New: test-function-bodies fails to find functions with single-letter names

[amylaar at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111658

Bug ID: 111658
   Summary: test-function-bodies fails to find functions with
single-letter names
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amylaar at gcc dot gnu.org
  Target Milestone: ---

When you use check-function-bodies with a function that has a single-letter
name, the start regexp set by configure_check-function-bodies and used by
parse_function_bodies to find function starts fails to match, making the
test always fail.
There is no mention about such a restriction in sourcebuild.texi

[Bug target/111655] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #8 from Andrew Pinski  ---
Oh this is a dup of bug 51446 , with -fno-trapping-math GCC produces the NaN as
a constant folding.

*** This bug has been marked as a duplicate of bug 51446 ***

[Bug target/111655] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

--- Comment #7 from Andrew Pinski  ---
What I am trying to say in comment #3 is both GCC and clang's constant folding
is different from what the instruction divsd does in the end.

[Bug target/111655] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

--- Comment #6 from Andrew Pinski  ---
(In reply to Paul Eggert from comment #5)
> > The match pattern which causes the issue:
> > (simplify
> >  /* signbit(x) -> 0 if x is nonnegative.  */
> >  (SIGNBIT tree_expr_nonnegative_p@0)
> >  { integer_zero_node; })
> I don't see anything wrong with that match pattern.
> 
> I speculate that what's wrong is that GCC incorrectly thinks that 0.0/0.0 is
> nonnegative. Although it's tempting to say that the sign bit of a division
> is the exclusive OR of the sign bits of its operands, evidently this is not
> true on x86-64 when NaNs are involved.

tree_expr_nonnegative_p for divide does:
case RDIV_EXPR:
case TRUNC_DIV_EXPR:
case CEIL_DIV_EXPR:
case FLOOR_DIV_EXPR:
case ROUND_DIV_EXPR:
  return RECURSE (op0) && RECURSE (op1);

Since 0.0 and 0.0 both don't have their sign bits set, GCC assumes diving them
won't produce a value with the sign bit set ...

I really think x86_64 div instruction is broken for IEEE really.

[Bug target/111657] Memory copy with structure assignment from named address space should be improved

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #3 from Andrew Pinski  ---
The easiest way to improve this is to have decide_alg select loop for the
have_as case if !TARGET_SSE && !TARGET_AVX...
Which means this is a target issue.

[Bug middle-end/111657] Memory copy with structure assignment from named address space is not working

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Depends on|79649   |
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-01
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
This is unrelated to PR 79649 as IV-OPTS does nothing here.

if we do `-mstringop-strategy=loop`, it works fine but
`-mstringop-strategy=libcall` is broken.

Seems like the middle-end expansion for the copy for the libcall case does
worse than the target specific loop.
Now the backend could select the target specific loop for this rather than the
libcall case 


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79649
[Bug 79649] Memset pattern in named address space crashes compiler or generates
wrong code

[Bug target/111655] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2

[eggert at cs dot ucla.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

--- Comment #5 from Paul Eggert  ---
> I am thinking this is all under specified really ...
Although it is indeed unspecified whether 0.0/0.0 yields -NaN or +NaN, it is
well understood that negating a floating point value flips its sign bit. The
original test case demonstrates that gcc -O2 currently mishandles this, as that
test case negates a floating point value but the sign bit remains unchanged.

Old GCC and Clang handle this correctly, as do the other non-GCC compilers that
I checked. As far as I know, only recentish gcc gets this wrong, and even then
only when optimization is enabled.

Here is a sharper example of the bug:

  int
  main ()
  {
double x = 0.0 / 0.0;
return !__builtin_signbit (x) == !__builtin_signbit(-x);
  }

This should return 0 no matter what X's value is, but it returns 1 with recent
gcc -O2 on x86-64.


> The match pattern which causes the issue:
> (simplify
>  /* signbit(x) -> 0 if x is nonnegative.  */
>  (SIGNBIT tree_expr_nonnegative_p@0)
>  { integer_zero_node; })
I don't see anything wrong with that match pattern.

I speculate that what's wrong is that GCC incorrectly thinks that 0.0/0.0 is
nonnegative. Although it's tempting to say that the sign bit of a division is
the exclusive OR of the sign bits of its operands, evidently this is not true
on x86-64 when NaNs are involved.

[Bug middle-end/111657] Memory copy with structure assignment from named address space is not working

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657

Uroš Bizjak  changed:

   What|Removed |Added

 Depends on||79649

--- Comment #1 from Uroš Bizjak  ---
Looks like another issue with IVopts (PR79649).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79649
[Bug 79649] Memset pattern in named address space crashes compiler or generates
wrong code

[Bug middle-end/111657] New: Memory copy with structure assignment from named address space is not working

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657

Bug ID: 111657
   Summary: Memory copy with structure assignment from named
address space is not working
   Product: gcc
   Version: 12.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Taken from [1]. Compile the following testcase with -O2 -mno-sse:

--cut here--
struct a
{
  long arr[30];
};

__seg_gs struct a m;

void
foo (struct a *dst)
{
  *dst = m;
}
--cut here--

the produced assembly:

foo:
.LFB0:
xorl%eax, %eax
cmpq$240, %rax
jnb .L5
.L2:
movzbl  %gs:m(%rax), %edx
movb%dl, (%rdi,%rax)
addq$1, %rax
cmpq$240, %rax
jb  .L2
.L5:
ret

As rightfully said in [1]:

"...and look at the end result. It's complete and utter sh*t:

<...>

to the point that I can only go "WTF"?

I mean, it's not just that it does the copy one byte at a time. It
literally compares %rax to $240 just after it has cleared it. I look
at that code, and I go "a five-year old with a crayon could have done
better".

[1]
https://lore.kernel.org/lkml/CAHk-=wh+cfn58xxmlng6dh+eb9-2dyfabxjf2ftsz+vfqvv...@mail.gmail.com/

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

Richard Sandiford  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #13 from Richard Sandiford  ---
Created attachment 56023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56023=edit
Tentative fix

Sorry for the radio silence, had a network outage.  I'm testing the attached,
which if it works would avoid resorting to the preprocessor.

[Bug c++/110913] internal compiler error when I pass temporary vector of string to co_await target function

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110913

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |---

--- Comment #2 from Andrew Pinski  ---
Reopen as PR 105574  seems fixed.

[Bug c++/111651] Specific syntax with C++ 20 designated initializers and coroutines breaks

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111651

--- Comment #2 from Andrew Pinski  ---
/workspaces/booxy/main.cpp: In function ‘boost::asio::awaitable
make(boost::asio::any_io_executor)’:
/workspaces/booxy/main.cpp:19:1: internal compiler error: tree check: expected
record_type or union_type or qual_union_type, have array_type in
build_special_member_call, at cp/call.cc:11052
0x96ac48 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:8956
0x771727 tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.h:3637
0x771727 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/call.cc:11052
0xaca46c maybe_promote_temps
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:3146
0xaca46c await_statement_walker
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:3757
0x16120ac walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11400
0xac9c28 await_statement_walker
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:3428
0x16120ac walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11400
0xaca0c8 await_statement_walker
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:3417
0x16120ac walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11400
0xac9c28 await_statement_walker
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:3428
0x16120ac walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11400
0x1612204 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11634
0xac9c28 await_statement_walker
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:3428
0x16120ac walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11400
0xaca0c8 await_statement_walker
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:3417
0x16120ac walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11400
0xacb94f morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:4508
0xb20f6b finish_function(bool)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/decl.cc:18168
0xc252d7 cp_parser_function_definition_after_declarator
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:32302
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/111331] [11/12 Regression] Wrong code at -O1 on x86_64-linux-gnu since

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111331

Andrew Pinski  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] Wrong |[11/12 Regression] Wrong
   |code at -O1 on  |code at -O1 on
   |x86_64-linux-gnu since  |x86_64-linux-gnu since
  Known to fail|14.0|
  Known to work||13.2.1, 14.0

--- Comment #16 from Andrew Pinski  ---
Fixed on the GCC 13 branch too.

[Bug tree-optimization/111331] [11/12/13 Regression] Wrong code at -O1 on x86_64-linux-gnu since

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111331

--- Comment #15 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:cda1992a56779e5c60a70f251542a6f662fdfa60

commit r13-7928-gcda1992a56779e5c60a70f251542a6f662fdfa60
Author: Andrew Pinski 
Date:   Thu Sep 7 22:13:31 2023 -0700

Fix PR 111331: wrong code for `a > 28 ? MIN : 29`

The problem here is after r6-7425-ga9fee7cdc3c62d0e51730,
the comparison to see if the transformation could be done was using the
wrong value. Instead of see if the inner was LE (for MIN and GE for MAX)
the outer value, it was comparing the inner to the value used in the
comparison
which was wrong.

Committed to GCC 13 branch after bootstrapped and tested on
x86_64-linux-gnu.

gcc/ChangeLog:

PR tree-optimization/111331
* tree-ssa-phiopt.cc (minmax_replacement):
Fix the LE/GE comparison for the
`(a CMP CST1) ? max : a` optimization.

gcc/testsuite/ChangeLog:

PR tree-optimization/111331
* gcc.c-torture/execute/pr111331-1.c: New test.
* gcc.c-torture/execute/pr111331-2.c: New test.
* gcc.c-torture/execute/pr111331-3.c: New test.

(cherry picked from commit 30e6ee074588bacefd2dfe745b188bb20c81fe5e)

[Bug target/111645] Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128

[munroesj at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645

--- Comment #4 from Steven Munroe  ---
Actually shift/rotate intrinsic: ,vec_rl, vec_rlmi, vec_rlnm, vec_sl, vec_sr,
vec_sra

Support vector __int128 as required for the PowerISA 3.1 POWER vector
shift/rotate quadword instructions 

But: vec_sld, vec_sldb, vec_sldw, vec_sll, vec_slo, vec_srdb, vec_srl, vec_sro

Do not. 

There is no obvious reason for this inconstancy as the target instructions are
effectively 128/256-bit operations returning a 128-bit result.The type of the
inputs is incidental to the operation.

Any restrictions imposed by the original Altivec.h PIM was broken long ago by
VSX and PowerISA 2.07.

Net: the Power Vector Intrinsic Programming Reference and the compilers should
support the vector __int128 type for any instruction where it makes sense as a
input or result.

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

Andrew Pinski  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #12 from Andrew Pinski  ---
*** Bug 111656 has been marked as a duplicate of this bug. ***

[Bug c/111656] Recent build failure with clang

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111656

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup of bug 111642.

*** This bug has been marked as a duplicate of bug 111642 ***

[Bug c/111656] New: Recent build failure with clang

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111656

Bug ID: 111656
   Summary: Recent build failure with clang
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I normally build trunk gcc with clang. However, today it didn't work.
clang said:

../../trunk.year/gcc/poly-int.h:453:14: error: excess elements in array
initializer

Source code is

template
template
inline constexpr
poly_int::poly_int (poly_int_full, const Cs &... cs)
  : coeffs { (typename poly_coeff_traits::
  template init_cast::type (cs))... } {}

It build fine with gcc, so I have a temporary workaround.

git blame says:

eaa41a6dc12 (Richard Sandiford 2023-09-29 17:55:12 +0100  449)
template
eaa41a6dc12 (Richard Sandiford 2023-09-29 17:55:12 +0100  450)
template
eaa41a6dc12 (Richard Sandiford 2023-09-29 17:55:12 +0100  451) inline constexpr
eaa41a6dc12 (Richard Sandiford 2023-09-29 17:55:12 +0100  452) poly_int::poly_int (poly_int_full, const Cs &... cs)
eaa41a6dc12 (Richard Sandiford 2023-09-29 17:55:12 +0100  453)   : coeffs {
(typename poly_coeff_traits::
eaa41a6dc12 (Richard Sandiford 2023-09-29 17:55:12 +0100  454)template
init_cast::type (cs))... } {}

[Bug d/111650] ICE in build_deref, at d/d-codegen.cc:1650

[ibuclaw at gdcproject dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650

--- Comment #1 from Iain Buclaw  ---
Reduced a bit more.

---
module object;

ref V require(K, V)(ref V[K] aa, K key, lazy V value);

struct Root
{
ulong[3] f;
}

Root[ulong] roots;

Root getRoot(int fd, ulong rootID)
{
return roots.require(rootID,
{   
Root result;
inoLookup(fd, () => result);
return result;
}());
}

void inoLookup(int, scope Root delegate()) { }

[Bug tree-optimization/110386] [11/12/13 Regression] ICE with ABSU in backprop

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110386

--- Comment #10 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:b5fa95a3569f6ee66697876a3a380fef1b333f3d

commit r13-7927-gb5fa95a3569f6ee66697876a3a380fef1b333f3d
Author: Andrew Pinski 
Date:   Sat Sep 23 21:53:09 2023 -0700

Fix PR 110386: backprop vs ABSU_EXPR

The issue here is that when backprop tries to go
and strip sign ops, it skips over ABSU_EXPR but
ABSU_EXPR not only does an ABS, it also changes the
type to unsigned.
Since strip_sign_op_1 is only supposed to strip off
sign changing operands and not ones that change types,
removing ABSU_EXPR here is correct. We don't handle
nop conversions so this does cause any missed optimizations either.

Committed to the GCC 13 branch after bootstrapped and
tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/110386

gcc/ChangeLog:

* gimple-ssa-backprop.cc (strip_sign_op_1): Remove ABSU_EXPR.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr110386-1.c: New test.
* gcc.c-torture/compile/pr110386-2.c: New test.

(cherry picked from commit 2bbac12ea7bd8a3eef5382e1b13f6019df4ec03f)

[Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639

--- Comment #8 from Jonathan Wakely  ---
Anything that doesn't work on avr should be considered a bug, like any other
target.

[Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639

--- Comment #7 from Jonathan Wakely  ---
Not particularly, I just want to be able to bootstrap on avr with
--enable-libstdcxx

It works pretty well already, especially with the -ffreestanding changes in gcc
13.

[Bug tree-optimization/111648] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-3243-ga7dba4a1c05

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-01
Summary|Wrong code at -O2/3 on  |[14 Regression] Wrong code
   |x86_64-linux-gnu since  |at -O2/3 on
   |r14-3243-ga7dba4a1c05   |x86_64-linux-gnu since
   ||r14-3243-ga7dba4a1c05

--- Comment #2 from Andrew Pinski  ---
.

[Bug tree-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485

--- Comment #29 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630011.html

[Bug tree-optimization/55923] tree passes pessimize complex load/store operations

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55923

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630011.html

[Bug target/111655] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> 
> Note GCC and clang even disagree on the first testcase but agree with the
> second one.

Oh and the C and C++ front-end even disagree with each other.

[Bug middle-end/111429] NO_COLOR env should disable color

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111429

Eric Gallager  changed:

   What|Removed |Added

URL||https://no-color.org/
   Last reconfirmed||2023-10-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Confirmed. https://no-color.org/ currently has GCC under its "Disabling color
in software not supporting `NO_COLOR`" section.

[Bug target/111655] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

--- Comment #3 from Andrew Pinski  ---
Another testcase which shows a related issue:
```
double t = 0.0/0.0;


  int
  main ()
  {
double x = 0.0/0.0;
return __builtin_signbit (x) != __builtin_signbit (t);
  }
```

And another one:
```
double t = 0.0/0.0;


  int
  main ()
  {
  //  double x = 0.0/0.0;
volatile double tt = 0.0;

return __builtin_signbit (tt/tt) != __builtin_signbit (t);
  }

```

Note GCC and clang even disagree on the first testcase but agree with the
second one.

I am thinking this is all under specified really ...

[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114

--- Comment #7 from Eric Gallager  ---
(In reply to simon from comment #6)
> (In reply to simon from comment #1)
> > Further:
> > 
> > $ GNAT_FILE_NAME_CASE_SENSITIVE=1 gnatmake -c p*.ads
> > gcc -c páck3.ads
> > páck3.ads:1:10: warning: file name does not match unit name, should be
> > "páck3.ads"
> > 
> > The reason for this apparently-bizarre message is[1] that macOS takes 
> > the composed form (lowercase a acute) and converts it under the hood 
> > to what HFS+ insists on, the fully decomposed form (lowercase a, combining 
> > acute); thus the names are actually different even though they _look_ 
> > the same.
> 
> This behaviour (I think it was an error) was fixed by darwin 19. Opening by
> a name with the composed form now correctly finds the file named with the
> fully decomposed form.

OK, so do we still want to fix it for older darwin versions, or...?

[Bug target/111655] wrong code generated for __builtin_signbit on x86-64 -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

--- Comment #2 from Andrew Pinski  ---
The match pattern which causes the issue:
(simplify
 /* signbit(x) -> 0 if x is nonnegative.  */
 (SIGNBIT tree_expr_nonnegative_p@0)
 { integer_zero_node; })

[Bug target/111655] wrong code generated for __builtin_signbit on x86-64 -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |target
 Target||x86_64-linux-gnu

--- Comment #1 from Andrew Pinski  ---
I think this is unspecified if this is supposed to be set or not ...

[Bug tree-optimization/111655] New: wrong code generated for __builtin_signbit on x86-64 -O2

[eggert at cs dot ucla.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

Bug ID: 111655
   Summary: wrong code generated for __builtin_signbit on x86-64
-O2
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

I ran into this bug when testing Gnulib code on Fedora 38 x86-64, which uses
gcc (GCC) 13.2.1 20230728 (Red Hat 13.2.1-1). The problem is a regression from
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), which does the right thing.

Here is a stripped-down version of the bug. Compile and run the following code
with "gcc -O2 t.i; ./a.out".

  int
  main ()
  {
double x = 0.0 / 0.0;
if (!__builtin_signbit (x))
  x = -x;
return !__builtin_signbit (x);
  }

Although a.out's exit status should be 0, it is 1. If I compile without -O2 the
bug goes away.

Here's the key part of the generated assembly language:

  main:
pxor%xmm0, %xmm0
divsd   %xmm0, %xmm0
xorpd   .LC1(%rip), %xmm0
movmskpd%xmm0, %eax
testb   $1, %al
sete%al
movzbl  %al, %eax
ret

  .LC1:
.long   0
.long   -2147483648

On the x86-64, the "divsd %xmm0, %xmm0" instruction that implements 0.0 / 0.0
generates a NaN with the sign bit set. I determined this by testing on a Xeon
W-1350, although I don't see where the NaN's sign bit is documented by Intel in
this situation.

It appears that GCC's optimization incorrectly assumes that 0.0 / 0.0 generates
a NaN with the sign bit clear, which causes the "if (!__builtin_signbit (x)) x
= -x;" to be compiled as if it were merely "x = -x;", which is obviously
incorrect.

[Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr

[gjl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639

--- Comment #6 from Georg-Johann Lay  ---
May I ask, are you working on getting libstdc++ to work for avr?

[Bug tree-optimization/111652] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111652

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Last reconfirmed||2023-10-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

The first difference between GCC 13 and the trunk's IR is in lsplit.
I have not looked if that is causing the issue here or not.

[Bug tree-optimization/111652] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111652

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||wrong-code
Summary|wrong code at -O3 on|[14 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu

[Bug driver/111654] New: Introduce clang's invalid-noreturn warning

[tanksherman27 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654

Bug ID: 111654
   Summary: Introduce clang's invalid-noreturn warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tanksherman27 at gmail dot com
  Target Milestone: ---

Created attachment 56022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56022=edit
Patch to add invalid-noreturn to gcc

clang has a toggleable warning flag named invalid-noreturn for noreturn
functions that return either implicitly or explicitly, while gcc has different
warnings for both explicit and implicit cases. We should add this warning (with
an extra level of tuneability since unlike clang gcc has different warnings for
each) for compatibility with clang, and for utility purposes since code may
desire to mark functions as noreturn even though it may (in the compiler's
point of view) return

[Bug bootstrap/111653] New: make bootstrap4 fails for -fchecking=2 code generation changes

[slyfox at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111653

Bug ID: 111653
   Summary: make bootstrap4 fails for -fchecking=2 code generation
changes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Reproducer on current gcc master from r14-4353-gf416a3fdbee32a:

$ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++
CC='gcc -O2' CXX='g++ -O2'
$ make bootstrap4
...
Comparing stages 3 and 4
Bootstrap comparison failure!
x86_64-pc-linux-gnu/libstdc++-v3/src/filesystem/dir.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/filesystem/cow-dir.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++20/tzdb.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++17/cow-fs_path.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++17/fs_path.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++17/cow-fs_dir.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++17/fs_dir.o differs

The failure happens due to the difference between stage3 and stage4 flags:
- stage3: -fchecking=1
- stage4: no flag (debug version implies -fchecking=2 due to
`ac_checking_flags=yes,extra` non-release defaults)

Som thoughts:
1. gcc manual says it's fine to see minor code geneation changes on
-fchecking=2.
2. there are only 7 files with code generation difference
3. -fchecking=2 detects real bugs like PR111647

It feels like depending on [1.] being a bug or a feature there are a few
possible solutions:
a) fix -fchecking=2 instability and change manual to always guarantee that
-fchecking=2 does not change code
b) if a) is infeasible then stop using -fchecking=2 for stage compares, say to
disable do-compare3 entirely
c) declate 4-stage bootstrap incompatible with `extra` checking flags
d) something else?

WDYT?

Minimal example with -fchecking= instability:

$ cat fs_dir.cc.cc
namespace std {

struct type_info {
  void operator==(const type_info &) const;
};
struct _Sp_counted_base {
  virtual void _M_get_deleter(const type_info &);
};
struct _Sp_make_shared_tag {};
template  struct _Sp_counted_ptr_inplace : _Sp_counted_base {
  struct _Impl {
_Impl(int);
  };
  _Sp_counted_ptr_inplace(int __a) : _M_impl(__a) {}
  void _M_get_deleter(const type_info &__ti) {
__ti == typeid(_Sp_make_shared_tag);
  }
  _Impl _M_impl;
};
struct __shared_count {
  __shared_count() { _Sp_counted_ptr_inplace(0); }
} _M_refcount;
} // namespace std


$ g++ -frandom-seed=fs_dir.lo -c fs_dir.cc.cc -fchecking=2 -o bug.o
$ sha1sum bug.o
92d676d60ee6e26e9b242fb64bffe9e47a92052a  bug.o

$ /g++ -frandom-seed=fs_dir.lo -c fs_dir.cc.cc -fchecking=2 -o bug.o
-fchecking=1
$ sha1sum bug.o
748b578657a335c212872b012b2afaf0be3ecbc4  bug.o

Note: hashes are different.

$ stage4-gcc/xgcc -Bstage4-gcc -v
Reading specs from stage4-gcc/specs
COLLECT_GCC=stage4-gcc/xgcc
COLLECT_LTO_WRAPPER=stage4-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--enable-languages=c,c++ CC='gcc -O2' CXX='g++ -O2'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230929 (experimental) (GCC)

[Bug testsuite/110951] [13/14] RISCV: rv32 newlib gcc.c-torture testsuite fails with xgcc: fatal error: Cannot find suitable multilib set for '-march=rv32imafdc_zicsr_zifencei'/'-mabi=ilp32d'

[amylaar at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110951

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #3 from Jorn Wolfgang Rennecke  ---
I see something like this come up randomly (i.e. not strictly reproducible)
with gcc14 about one to three times per million tests, in parts like gcc.dg.
I wonder if it could be related?  What was your testing environment problem?

[Bug tree-optimization/111652] New: wrong code at -O3 on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111652

Bug ID: 111652
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

Compiler Explorer: https://godbolt.org/z/89h8W1Pvs

[505] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231001 (experimental) (GCC) 
[506] % 
[506] % gcctk -O2 small.c; ./a.out
[507] % 
[507] % gcctk -O3 small.c
[508] % ./a.out
Aborted
[509] % 
[509] % cat small.c
volatile int a;
int b;
int main() {
  for (; b < 5; b += 3) {
b && a;
if (b < 4)
  a--;
  }
  if (b != 6)
__builtin_abort();
  return 0;
}

[Bug c++/111651] Specific syntax with C++ 20 designated initializers and coroutines breaks

[yunus at ayar dot eu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111651

--- Comment #1 from Yunus Ayar  ---
Created attachment 56021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56021=edit
Output of g++ -save-temps; I compressed it because it is 7.5 MB big and would
exceed the file size limit

I have uploaded the uncompressed version but I think it was rejected because
it's too large (7.5 MB)

[Bug c++/111651] New: Specific syntax with C++ 20 designated initializers and coroutines breaks

[yunus at ayar dot eu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111651

Bug ID: 111651
   Summary: Specific syntax with C++ 20 designated initializers
and coroutines breaks
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunus at ayar dot eu
  Target Milestone: ---

The error 'internal compiler error: in build_special_member_call, at
cp/call.cc:11093' occurs in this code:

```cpp
awaitable make(boost::asio::any_io_executor executor)
{
  co_await wdlite::async_new_session(executor, "http://localhost:9515;,

wdlite::capabilities::make(wdlite::capabilities::Capabilities{
   .browser_specific =
 wdlite::capabilities::ChromeOptions{
   // The next line is not ok.
   .arguments = { std::to_string(0) },
   // The next line is ok.
   // .arguments = { "ok" },
 },
 }),
 use_awaitable);
  co_return;
}
```

If I substitute `.arguments = { std::to_string(0) },` with `.arguments = { "ok"
},` the code compiles just fine. `.arguments = { std::to_string(0) },` is not a
problem if I remove the `co_await` keyword. My Boost version is 1.80 and the
Boost.ASIO is 1.24.

The output of `g++ -v`:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230728 (Red Hat 13.2.1-1) (GCC)

I compiled the attached file (main.cpp.ii) like so:
g++ main.cpp.ii -std=gnu++20

[Bug middle-end/111646] cos function giving different result for the same input value

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646

--- Comment #5 from Xi Ruoyao  ---
(In reply to vishwambhar.rathi from comment #4)
> I am not using any optimization flag in compiling. Where should I post about
> this bug? Thanks.

I don't know because maybe this is a Glibc issue or a QEMU issue.

You can try changing Glibc version of QEMU version to figure out.

[Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639

--- Comment #5 from Jonathan Wakely  ---
So then we do need to fix the autoconf macros.

[Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr

[gjl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639

--- Comment #4 from Georg-Johann Lay  ---
(In reply to Jonathan Wakely from comment #3)
> Which versions of avr-libc are supported with gcc?

The versions are only very loosely coupled.  Anything from AVR-LibC v1.8 on (or
maybe even older) should be fine with avr-gcc v5+.