[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

[kkylheku at gmail dot com via Gcc-bugs]

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

--- Comment #19 from Kaz Kylheku  ---
(In reply to Harald van Dijk from comment #18)
> (In reply to Kaz Kylheku from comment #17)
> > The standrad does not define the conversion at the *type* level.
> > ...
> > The program is strictly conforming because it has no problem with type.
> 
> The DRs I referenced include ones where type errors have explicitly been
> stated not to render behaviour undefined.
> 
> DR 132 (C90):
> 
>   /* No headers included */
>   int checkup()
>   {
>   /* Case 1 */
>   if (0)
>   printf("Printing.\n");
>   /* Case 2 */
>   return 2 || 1 / 0;
>   } 
> 
>   Response: "The Response to Defect Report #109 addresses this issue. The
> translation unit must be successfully translated."

Note that this report response does not say that the translation
unit must also be successfully linked, in a hosted implementation, to
produce a program.

> This, despite the fact that it implicitly declares as int(*)(), which is
> incompatible with the type it is meant to be declared as.

A mismatch, in linkage, can only occur when a reference is of a
different type from the definition.

In this translation unit alone, there is no type mismatch, because
the unit contains only a reference to printf, and no definition.

The translation unit can be part of a program where it makes sense.
E.g. in a freestanding implementation, where there isn't a library
with a printf, another translation unit can supply a compatible
definition of printf. Then, if (0) can be flipped to if (1) and
checkup() can be called, even.

There is no type problem here whatsoever that is comparable to
an operator being given operands whose type combination is not
defined for the operator. That's a problem entirely confined in
translation phase 7; it cannot be rescued by adding a suitable
secondary translation unit.

A call to an implicitly declared printf is translatable. There are
requirements about every aspect of it. There are no requiremnts
about how to translate (void *) 

[Bug c/114361] ICE with c23 related to completion of incomplete structure types

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||uecker at gcc dot gnu.org
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #6 from uecker at gcc dot gnu.org ---
Fixed for 14

[Bug c/46116] Allow passing of anonymous aggregates when signature matches

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #5 from uecker at gcc dot gnu.org ---

It requires a tag though as WG14 did not want to allow this for anonymous
structs.

[Bug target/69693] Wrong mode is used to load spilled register

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #9 from Andrew Pinski  ---
Fixed by r10-2665-gf386ca41386215 which uses `(vec_merge (vec_duplicate..))`
instead of paradoxical subregs.

[Bug sanitizer/114494] false-positive with -O2 -Wstringop-overflow=2 -fsanitize=address

[akihiko.odaki at daynix dot com via Gcc-bugs]

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

--- Comment #6 from Akihiko Odaki  ---
(In reply to Hans-Peter Nilsson from comment #5)
> (In reply to Akihiko Odaki from comment #0)
> > if (hlen < sizeof(struct ip_header)) {
> 
> Is this a typo for "if (hlen > sizeof(struct ip_header)) {" which makes a
> bot more sense to me?
> 
> (I can't find it in Linux/drivers, so can't check "upstream" status.)

It is not Linux but QEMU. Please look at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494#c0

[Bug middle-end/66630] Missing ubsan/ftrapv error

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #2)
> That's one thing.  But there also something else going on.  I hope it's just
> missing TYPE_OVERFLOW_SANITIZED in some match.pd patterns.

```
  /* ~A + A -> -1 */
  (simplify
   (plus:c (convert? (bit_not @0)) (convert? @0))
   (if (!TYPE_OVERFLOW_TRAPS (type))
(convert { build_all_ones_cst (TREE_TYPE (@0)); })))

  /* ~A + 1 -> -A */
  (simplify
   (plus (convert? (bit_not @0)) integer_each_onep)
   (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
(negate (convert @0

  /* -A - 1 -> ~A */
  (simplify
   (minus (convert? (negate @0)) integer_each_onep)
   (if (!TYPE_OVERFLOW_TRAPS (type)
&& TREE_CODE (type) != COMPLEX_TYPE
&& tree_nop_conversion_p (type, TREE_TYPE (@0)))
(bit_not (convert @0

  /* -1 - A -> ~A */
  (simplify
   (minus integer_all_onesp @0)
   (if (TREE_CODE (type) != COMPLEX_TYPE)
(bit_not @0)))

```

I am not sure which one of these patterns need the check for
TYPE_OVERFLOW_SANITIZED though.

[Bug target/64662] [SH] QImode/HImode atomics should return sign extended SImode values

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug target/114560] Compilation error when using _mm512_maskz_expandloadu_epi16 with only -mavx512vbmi2

[meirav.grimberg at redis dot com via Gcc-bugs]

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

Meirav Grimberg  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Meirav Grimberg  ---
Thank you!

[Bug ipa/64565] [5 Regression] ICE: in inline_small_functions, at ipa-inline.c:1664

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mikulas at artax dot 
karlin.mff.cu
   ||ni.cz

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

[Bug ipa/64545] failed gcc build: internal compiler error: in inline_small_functions, at ipa-inline.c:1693

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #9 from Andrew Pinski  ---
Dup. been fixed a long time ago.

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

[Bug demangler/54254] libiberty: demangling for global constructor is broken since r167781

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jg at jguk dot org

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

[Bug demangler/90039] libiberty demangling _GLOBAL__sub_I__Z11print_tracev

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug demangler/59518] C++ demangler does not handle some global constructor & LTO names

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||54254
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-03
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
_GLOBAL__sub_ issue is PR 54254


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54254
[Bug 54254] libiberty: demangling for global constructor is broken since
r167781

[Bug demangler/56755] Global symbol demangling fails for _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Dup.

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

[Bug demangler/54254] libiberty: demangling for global constructor is broken since r167781

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dungtq1387 at gmail dot com

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

[Bug demangler/54254] libiberty: demangling for global constructor is broken since r167781

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
URL|http://gcc.gnu.org/viewcvs? |
   |root=gcc=rev=16778 |
   |1   |
   Last reconfirmed||2024-04-03

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

[Bug target/55634] ARM: gcc vector extensions: storing vector to unaligned memory location does not use VST1.8 NEON instruction

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102125
   Target Milestone|--- |12.0
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Fixed for GCC 12.1.0 via the patches which fixed PR 102125 .

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

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

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

--- Comment #37 from Jerry DeLisle  ---
Created attachment 57855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57855=edit
Preliminary patch to address some incorrect behavior

This attached patch, gives some better results for the testcase in the previous
commenr.

$ ./a.out 
comma, isreal = F, testinput =  ; n= 42 ios=0
point, isreal = F, testinput =  ; n= 42 ios=0
comma, isreal = F, testinput =  , n= 42 ios= 5010
point, isreal = F, testinput =  , n= 42 ios=0
comma, isreal = F, testinput =  . n= 42 ios= 5010
point, isreal = F, testinput =  . n= 42 ios= 5010
comma, isreal = F, testinput = 5. n= 42 ios= 5010
point, isreal = F, testinput = 5. n= 42 ios= 5010
comma, isreal = F, testinput = 5, n= 42 ios= 5010
point, isreal = F, testinput = 5, n=  5 ios=0
comma, isreal = F, testinput = 5; n=  5 ios=0
point, isreal = F, testinput = 5; n=  5 ios=0
comma, isreal = F, testinput =7 . n=  7 ios=0
point, isreal = F, testinput =7 . n=  7 ios=0
comma, isreal = F, testinput =7 , n=  7 ios=0
point, isreal = F, testinput =7 , n=  7 ios=0
comma, isreal = F, testinput =7 ; n=  7 ios=0
point, isreal = F, testinput =7 ; n=  7 ios=0
comma, isreal = T, testinput = 8. r=  42.00 ios= 5010
point, isreal = T, testinput = 8. r=   8.00 ios=0
comma, isreal = T, testinput = 8, r=   8.00 ios=0
point, isreal = T, testinput = 8, r=   8.00 ios=0
comma, isreal = T, testinput = 8; r=   8.00 ios=0
point, isreal = T, testinput = 8; r=   8.00 ios=0
comma, isreal = T, testinput =9 . r=   9.00 ios=0
point, isreal = T, testinput =9 . r=   9.00 ios=0
comma, isreal = T, testinput =9 , r=   9.00 ios=0
point, isreal = T, testinput =9 , r=   9.00 ios=0
comma, isreal = T, testinput =9 ; r=   9.00 ios=0
point, isreal = T, testinput =9 ; r=   9.00 ios=0
comma, isreal = T, testinput =   3,3. r=  42.00 ios= 5010
point, isreal = T, testinput =   3.3. r=  42.00 ios= 5010
comma, isreal = T, testinput =   3,3, r=  42.00 ios= 5010
comma, isreal = T, testinput =   3,3; r=   3.30 ios=0
point, isreal = T, testinput =   3.3; r=   3.30 ios=0
comma, isreal = T, testinput =  4,4 . r=   4.40 ios=0
point, isreal = T, testinput =  4.4 . r=   4.40 ios=0
comma, isreal = T, testinput =  4,4 , r=   4.40 ios=0
point, isreal = T, testinput =  4.4 , r=   4.40 ios=0
comma, isreal = T, testinput =  4,4 ; r=   4.40 ios=0
point, isreal = T, testinput =  4.4 ; r=   4.40 ios=0

[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944

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

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

--- Comment #5 from Andrew Pinski  ---
Found potential split point: if (f.12_35 <= _25)
 { 3 + I*-1 } le_expr 2147483647 - _2
Applying pattern match.pd:6064, generic-match-4.cc:1699

[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
Note you can remove continue/[[unlikely]]` and reproduce it with `-O3
-fdisable-tree-lim2`.

Also note disabling VRP2, `-fdisable-tree-vrp2` allows the code to pass which
gets me the feeling like maybe lsplit is not rewriting the check to be overflow
safe.

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

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

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

--- Comment #36 from Jerry DeLisle  ---
Created attachment 57854
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57854=edit
Modified extended test case

I modified the extended test case so I could review this and summarize.
Currently this is what we get with my comments at the end of each line. I
marked some that I think are clearly incorrect.  Maybe OK depends on on
strictly one chooses to interpret what the standard says.  If we assume that
one or more spaces is an acceptable separator if followed by a non-value I
indicate those with the word space.

comma, isreal = F, testinput =  ; n= 42 ios=0  OK, null read
point, isreal = F, testinput =  ; n= 42 ios=0  maybe OK
comma, isreal = F, testinput =  , n= 42 ios= 5010  OK, error
point, isreal = F, testinput =  , n= 42 ios=0  OK, null read
comma, isreal = F, testinput =  . n= 42 ios= 5010  OK, error
point, isreal = F, testinput =  . n= 42 ios= 5010  OK, error
comma, isreal = F, testinput = 5. n= 42 ios= 5010  OK, error
point, isreal = F, testinput = 5. n= 42 ios= 5010  OK, error
comma, isreal = F, testinput = 5, n= 42 ios= 5010  OK, error
point, isreal = F, testinput = 5, n=  5 ios=0  OK, good read
comma, isreal = F, testinput = 5; n=  5 ios=0  OK, good read
point, isreal = F, testinput = 5; n=  5 ios=0  maybe OK
comma, isreal = F, testinput =7 . n=  7 ios=0  OK, good read space
point, isreal = F, testinput =7 . n=  7 ios=0  OK, good read space
comma, isreal = F, testinput =7 , n= 42 ios= 5010  Incorrect
point, isreal = F, testinput =7 , n=  7 ios=0  OK, good read
comma, isreal = F, testinput =7 ; n=  7 ios=0  OK, good read space
point, isreal = F, testinput =7 ; n=  7 ios=0  OK, good read space
comma, isreal = T, testinput = 8. r=  42.00 ios= 5010  OK, error
point, isreal = T, testinput = 8. r=   8.00 ios=0  OK, good read
comma, isreal = T, testinput = 8, r=   8.00 ios=0  OK, good read
point, isreal = T, testinput = 8, r=   8.00 ios=0  OK, good read
comma, isreal = T, testinput = 8; r=   8.00 ios=0  OK, good read
point, isreal = T, testinput = 8; r=   8.00 ios=0  maybe OK
comma, isreal = T, testinput =9 . r=   9.00 ios=0  OK, good read space
point, isreal = T, testinput =9 . r=   9.00 ios=0  OK, good read space
comma, isreal = T, testinput =9 , r=   9.00 ios= 5010  Incorrect, space?
point, isreal = T, testinput =9 , r=   9.00 ios=0  OK, good read
comma, isreal = T, testinput =9 ; r=   9.00 ios=0  OK, good read
point, isreal = T, testinput =9 ; r=   9.00 ios=0  maybe OK
comma, isreal = T, testinput =   3,3. r=  42.00 ios= 5010  OK, error
point, isreal = T, testinput =   3.3. r=  42.00 ios= 5010  OK, error
comma, isreal = T, testinput =   3,3, r=  42.00 ios= 5010  OK, error
comma, isreal = T, testinput =   3,3; r=   3.30 ios=0  OK, good read
point, isreal = T, testinput =   3.3; r=   3.30 ios=0  maybe OK
comma, isreal = T, testinput =  4,4 . r=   4.40 ios=0  OK, good read space
point, isreal = T, testinput =  4.4 . r=   4.40 ios=0  OK, goor read space
comma, isreal = T, testinput =  4,4 , r=   4.40 ios= 5010  Incorrect, space?
point, isreal = T, testinput =  4.4 , r=   4.40 ios=0  OK, good read
comma, isreal = T, testinput =  4,4 ; r=   4.40 ios=0  OK, good read
point, isreal = T, testinput =  4.4 ; r=   4.40 ios=0  OK, good read space

I have a followup comment on this.

[Bug testsuite/114568] New: [14 regression] g++.dg/vect/pr84556.cc fails to produce executable since r14-9706-gb8e7aaaf350a45

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

Bug ID: 114568
   Summary: [14 regression] g++.dg/vect/pr84556.cc fails to
produce executable since r14-9706-gb8e7aaaf350a45
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago.bauermann at linaro dot org
CC: mkuvyrkov at gcc dot gnu.org
  Target Milestone: ---

After g:b8e7aaaf350a4584d9b76e8dd69daa2203bac339, r14-9706-gb8e7aaaf350a45 we
have noticed a regression on our "thumb_m3_eabi" and "thumb_m55_hard_eabi"
(more details about them later):


Running g++:g++.dg/vect/vect.exp ...
FAIL: g++.dg/vect/pr84556.cc -std=c++14 (test for excess errors)
UNRESOLVED: g++.dg/vect/pr84556.cc -std=c++14 compilation failed to produce
executable
FAIL: g++.dg/vect/pr84556.cc -std=c++17 (test for excess errors)
UNRESOLVED: g++.dg/vect/pr84556.cc -std=c++17 compilation failed to produce
executable
FAIL: g++.dg/vect/pr84556.cc -std=c++20 (test for excess errors)
UNRESOLVED: g++.dg/vect/pr84556.cc -std=c++20 compilation failed to produce
executable

commit b8e7aaaf350a4584d9b76e8dd69daa2203bac339
Author: Maxim Kuvyrkov 
CommitDate: Thu Mar 28 13:38:59 2024 +

[testsuite] Fixup dg-options in {gcc,g++,gfortran}.dg/vect.exp tests

This is the part of g++.log showing the problem:

spawn -ignore SIGHUP
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-g++
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/vect/pr84556.cc
-mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard
-mfpu=auto -fdiagnostics-plain-output -nostdinc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/libsupc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/include/backward
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=c++20 -O2 -ftree-vectorize -fno-vect-cost-model
-mfpu=neon -mfloat-abi=softfp -march=armv7-a -ffast-math
-fdump-tree-vect-details -O2 -fopenmp-simd -specs=rdimon.specs
-L/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/./libstdc++-v3/src/.libs
-B/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/./libstdc++-v3/src/.libs
-L/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/./libstdc++-v3/src/experimental/.libs
-lm -o ./pr84556.exe
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/14.0.1/../../../../arm-eabi/bin/ld:
error: ./pr84556.exe uses VFP register arguments, /tmp/cce7HucW.o does not
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/14.0.1/../../../../arm-eabi/bin/ld:
error: /tmp/cce7HucW.o: conflicting architecture profiles A/M
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/14.0.1/../../../../arm-eabi/bin/ld:
failed to merge target specific data of file /tmp/cce7HucW.o
collect2: error: ld returned 1 exit status
compiler exited with status 1

I selected "testsuite" as the problematic component because the commit above
only made testsuite changes, but I'm not sure if this is a symptom of a problem
somewhere else.

In the "thumb_m3_eabi" configuration, GCC was configured with:

/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/configure
\
SHELL=/bin/bash \
   
--with-mpc=/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu
\
   
--with-mpfr=/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu
\
   
--with-gmp=/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu
\
--with-gnu-as \
--with-gnu-ld \
--disable-libmudflap \
--enable-lto \
--enable-shared \
--without-included-gettext \
--enable-nls \
--with-system-zlib \
--disable-sjlj-exceptions \
--enable-gnu-unique-object \
--enable-linker-build-id \
--disable-libstdcxx-pch \
--enable-c99 \
--enable-clocale=gnu \
--enable-libstdcxx-debug \
--enable-long-long \
--with-cloog=no \
--with-ppl=no \
--with-isl=no \
--enable-threads=no \
--disable-multiarch \
--disable-multilib \
--with-mode=thumb \

[Bug target/114567] rs6000: explicit _Float128 doesn't generate optimal code

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

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

Kewen Lin  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||missed-optimization
 Target||powerpc64*-linux-gnu
   Last reconfirmed||2024-04-03
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org

[Bug target/114567] New: rs6000: explicit _Float128 doesn't generate optimal code

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

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

Bug ID: 114567
   Summary: rs6000: explicit _Float128 doesn't generate optimal
code
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

This is an issue which I happened to spot when I have been working on patches
for PR112993.

=== test case ===

#define TYPE _Float128

#ifdef LD
#undef TYPE
#define TYPE long double
#endif

int sbm (TYPE *a) { return __builtin_signbit (*a); }

==

/opt/gcc-nightly/trunk/bin/gcc -mcpu=power8 -mvsx -O2 -mabi=ieeelongdouble
-Wno-psabi test.c -DLD -S -o ref.s
/opt/gcc-nightly/trunk/bin/gcc -mcpu=power8 -mvsx -O2 -mabi=ibmlongdouble
-Wno-psabi test.c -S -o float128.s

diff -Nur ref.s float128.s
--- ref.s   2024-03-18 05:41:00.302208975 -0400
+++ float128.s  2024-03-18 05:41:00.392205513 -0400
@@ -9,7 +9,10 @@
 sbm:
 .LFB0:
.cfi_startproc
-   ld 3,8(3)
+   rldicr 3,3,0,59
+   lxvd2x 0,0,3
+   xxpermdi 0,0,0,2
+   mfvsrd 3,0
srdi 3,3,63
blr
.long 0

[Bug tree-optimization/114476] [13/14 Regression] wrong code with -fwrapv -O3 -fno-vect-cost-model (and -march=armv9-a+sve2 on aarch64 and -march=rv64gcv on riscv)

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #7 from JuzheZhong  ---
Hi, Robin.

Will you fix this bug ?

[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org

--- Comment #6 from Kewen Lin  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Kewen Lin from comment #4)
> > Hi Andrew, thanks for digging into this!  William has not worked on GCC
> > project any more, will you make a patch for this?
> 
> I don't have time to test it really.

No problem, I'll work on this.

[Bug c++/107945] static constexpr incomplete (depedent) data member of a class template and in-member initialized incorrectly accepted

[bbi5291 at gmail dot com via Gcc-bugs]

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

Brian Bi  changed:

   What|Removed |Added

 CC||bbi5291 at gmail dot com

--- Comment #5 from Brian Bi  ---
In the first case, I think GCC's behaviour can be argued to be correct.
[temp.inst]/3.1 says that when you implicitly instantiate a class template, you
only instantiate the declarations of static data members, not their
definitions. Which means that until you do something that provokes the
instantiation of the *definition* of `C::t`, the compiler must
treat it as a variable of type `const incomplete` that is
declared-but-not-defined, which means that you haven't yet actually attempted
to define a variable with incomplete type, which means the program is
well-formed.

In the most recent example given by Jason Liam we can reduce it to:

template 
struct S {
constexpr static S s = {};
};
int main() {
auto s = S::s;
}

This may be related to bug 70820, which was closed as INVALID. I think perhaps
that decision should be revisited; while I can see the argument for the above
code being well-formed, I think the interpretation of the standard being taken
in this case is wrong.

[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle  ---
(In reply to anlauf from comment #4)
> Seems to ICE no longer at r14-9759, but 13-branch and older still fail.
> Adjusting summary.
> 
> But is it really invalid code?  Intel and NAG accept it.

I am not getting an ICE here. Until sub is defined or further definitions on
components to t or t2, I do not see a basis to reject anything or give a
diagnostic.

[Bug middle-end/114556] weird loop unrolling when there's attribute aligned inside the loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-03

--- Comment #2 from Andrew Pinski  ---
without the align:

Inserting a partition copy on edge BB2->BB3 : PART.0 = PART.3
Inserting a value copy on edge BB2->BB3 : PART.1 = 2048


vs with:

Inserting a partition copy on edge BB3->BB3 : PART.7 = PART.0
Inserting a partition copy on edge BB2->BB3 : PART.7 = PART.3
Inserting a value copy on edge BB2->BB3 : PART.1 = 2048


Basically out of ssa is doing an extra move because it could not "merge" the
loop induction variable for the (vector) addition due to the different
alignment requirements ... 

And then things go down hill from there.

[Bug middle-end/114556] weird loop unrolling when there's attribute aligned inside the loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end

--- Comment #1 from Andrew Pinski  ---
The first difference (with/without aligned) comes from expand so moving this to
the middle-end ...

[Bug tree-optimization/114559] [11/12/13/14 Regression] After function inlining some optimizations missing

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||8.5.0
 CC||pinskia at gcc dot gnu.org
  Known to fail||9.1.0
   Target Milestone|--- |11.5
Summary|After function inlining |[11/12/13/14 Regression]
   |some optimizations missing  |After function inlining
   ||some optimizations missing

--- Comment #2 from Andrew Pinski  ---
Note the original testcase worked in GCC 8.5.0 and before and the reduced
testcase with the C++ front-end too. Due to not creating MIN/MAX expression
early.
So I am going to make this as a regression because the user would not
understand the difference really.

[Bug middle-end/114559] After function inlining some optimizations missing

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110199
   Last reconfirmed||2024-04-03
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. Reduced testcase without the need of inlining nor atomics:
```
int g(int);
int h(int);

int f(int a, int b)
{
  while (true)
   {
  int t = a < b ? a : b; // MIN
  if (b <= a)
return a; 
  { a = g(a); if (h(t)) return t; }
// t here should be old a before the assignment from `g(a);`
   }
}
```

As far as I can tell this is basically slightly more complex version of PR
110199 really wehre the MIN (MAX) has 2 usages. Note if we the usage of t in
`h(t)` the trunk (due to  PR 110199) is able to optimize it correctly to
`return a`.

[Bug c++/114558] GCC 13.2.1 encountered a segmentation fault error when compiling PyTorch.

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Also since you are using a redhat provided compiler you should be reporting
> it to them.

>From the pytorch issue even:
See  for instructions.

[Bug c++/114558] GCC 13.2.1 encountered a segmentation fault error when compiling PyTorch.

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

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

--- Comment #2 from Andrew Pinski  ---
Also since you are using a redhat provided compiler you should be reporting it
to them.

[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944

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

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

--- Comment #3 from Andrew Pinski  ---
The first major difference with/without continue is the moving of `f >
(2147483647 - a)` checkout of the loop via lim2 in the case of not having the
continue.

You can replace the inner most loop with:
```
for (; c < 4; c++) {
  [[unlikely]];
  d = f && a > 0 && f > (2147483647 - a) ? 0 : b[f];
}
```

Also so yes it is the continue predictor that is coming into play.

[Bug c++/55581] [C++11] Too-eager instantiation with decltype

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=49118
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
clang starting in 4.0 has much worse behavior than GCC in that it crashes.

[Bug modula2/114565] progress trace would be useful to isolate ICE for users

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Gaius Mulley  ---
Closing.

[Bug modula2/114565] progress trace would be useful to isolate ICE for users

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

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

--- Comment #5 from Gaius Mulley  ---
Closing now the patch has been bootstrapped, compared and applied.

[Bug modula2/114565] progress trace would be useful to isolate ICE for users

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:1bafa6a3fdbb53651ffa5d854c2341c487bf3269

commit r14-9764-g1bafa6a3fdbb53651ffa5d854c2341c487bf3269
Author: Gaius Mulley 
Date:   Tue Apr 2 23:47:42 2024 +0100

PR modula2/114565 progress trace would be useful to isolate ICE for users

This patch introduces the internal option -fm2-debug-trace= which can
be given a comma separated list of filter terms.  Currently it allows:
all,line,token,quad.  The patch allows users to trace the progress of
cc1gm2 so that source which causes an ICE can be reduced.  Once
PR113836 is complete it is expected that the trace information will be
written to file.

gcc/m2/ChangeLog:

PR modula2/114565
* gm2-compiler/M2GenGCC.mod (CodeStatement): Test
GetDebugTraceQuad before calling DisplayQuad.
* gm2-compiler/M2LexBuf.mod (NumberIO): Import CardToStr.
(GetToken): Test GetDebugTraceToken before writing the
token number or token line.
* gm2-compiler/M2Options.def (SetDebugTraceQuad): Rename to
(SetM2DebugTraceFilter): ...this.
(SetDebugTraceAPI): Remove.
(GetDebugTraceQuad): New procedure function.
(GetDebugTraceTree): Ditto.
(GetDebugTraceToken): Ditto.
(GetDebugTraceLine): Ditto.
(GetDebugFunctionLineNumbers): Ditto.
* gm2-compiler/M2Options.mod (DebugFunctionLineNumbers): New
boolean variable.
(DebugTraceQuad): Ditto.
(DebugTraceTree): Ditto.
(DebugTraceLine): Ditto.
(DebugTraceToken): Ditto.
(errors1): New procedure.
(SetDebugTraceQuad): Remove.
(SetM2DebugTraceFilter): New procedure implemented.
(SetM2DebugTrace): Ditto.
(GetDebugTraceQuad): Ditto.
(GetDebugTraceToken ): Ditto.
(GetDebugTraceLine): Ditto.
(SetDebugTraceLine): Remove.
* gm2-compiler/M2Quads.mod (GenQuadOTrash): Test
GetDebugTraceQuad and call DisplayQuad.
(GenQuadOTypetok): Ditto.
* gm2-compiler/SymbolTable.mod: Replace
DebugFunctionLineNumbers with GetDebugFunctionLineNumbers.
* gm2-gcc/init.cc (_M2_M2LangDump_init): Add prototype.
(init_PerCompilationInit): Add call.
* gm2-gcc/m2misc.cc (m2misc_cerror): New function.
(m2misc_error): Ditto.
* gm2-gcc/m2misc.def (error): New procedure.
(cerror): Ditto.
* gm2-gcc/m2misc.h (m2misc_cerror): New prototype.
(m2misc_error): Ditto.
* gm2-gcc/m2options.h (M2Options_SetDebugTraceQuad): New
prototype.
(M2Options_SetDebugTraceAPI): Remove.
(M2Options_GetDebugTraceToken): New prototype.
(M2Options_GetDebugTraceLine): Ditto.
(M2Options_SetDebugFunctionLineNumbers): Ditto.
(M2Options_GetDebugFunctionLineNumbers): Ditto.
(M2Options_SetM2DebugTraceFilter): Ditto.
* gm2-lang.cc (gm2_langhook_init_options): Remove
OPT_fdebug_trace_quad case.
Remove OPT_fdebug_trace_api case.
Add OPT_fm2_debug_trace_ case.
* lang.opt (fm2-debug-trace): New option.
(fdebug-trace-api): Remove.
(fdebug-trace-quad): Remove.
* m2.flex (m2flex_M2Error): Check s for NULL.
(skipnewline): New function.
(consumeLine): Call traceline.

Signed-off-by: Gaius Mulley 

[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

--- Comment #12 from Jason Merrill  ---
(In reply to Iain Sandoe from comment #11)
> SO I suppose the question is do we want to figure out why the opt is failing
> (knowing that if it succeeds that is a secondary issue) - or just
> dg-xfail-run-if for Darwin?

I think we can just disable icf1 on darwin, and not try to merge i and j.

It would be nice for icf[23] to work, since those don't involve
externally-visible symbols (or even names at all).  It would be good to
understand what is preventing the optimization in that case.

[Bug c/53593] #pragma prefetch

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

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

--- Comment #4 from Andrew Pinski  ---
here is the latest link:
https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2024-1/prefetch-noprefetch.html

So reading the page, it is only can be used when AVX512 is enabled now.

Before back in 2012 it was just for IA64 and then MiC was added and both have
been removed the documentation (as both are long gone).

[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Jason Merrill from comment #10)
> (In reply to Jonathan Wakely from comment #8)
> > (In reply to Iain Sandoe from comment #7)
> > > So I am actually asking if the extension actually has any useful meaning?
> > 
> > For non-darwin, yes, it requests the storage of two initializer lists to be
> > merged (see the commit msg for r14-1500-g4d935f52b0d5c0).
> 
> Though that doesn't involve the attribute, and promoting init-lists to
> static should work fine on darwin.

I think that is working we end up with two constant text arrays (no copy via
automatic storage as mentioned in the paper)

> (In reply to Jonathan Wakely from comment #6)
> > The question then is whether the attribute is supposed to be a non-binding
> > request or not.
> > 
> > If it's a non-binding request then the test should be adjusted/unsupported
> > for this target.
> 
> It is a non-binding request. And yes, if this optimization is problematic on
> darwin, we should adjust the test.

Actually, the optimisation is failing on Darwin - we produce two distinct
arrays.

(although, if it succeeds then technically that's breaking the ABI since we
then have two external symbols with the same addresss).

SO I suppose the question is do we want to figure out why the opt is failing
(knowing that if it succeeds that is a secondary issue) - or just
dg-xfail-run-if for Darwin?

This is what we generate now:
.const
.align 3
_i:
.long   1
.long   2
.long   3
.globl _j
.align 3
_j:
.long   1
.long   2
.long   3

and we do access i and j directly (i.e. not via the GOT).

[Bug middle-end/46679] fold_binary changes types in divisionm breaking configure -enable-checking

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Already fixed; dup.

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

[Bug middle-end/66984] ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary

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

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

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

[Bug middle-end/66984] ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |6.0

[Bug c/46635] c-family/c-common.c uses BITS_PER_UNIT in lieu of TYPE_PRECISION (char_type_node)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

in fold_offsetof, we still have:
```
case COMPONENT_REF:
...
  off = size_binop_loc (input_location, PLUS_EXPR, DECL_FIELD_OFFSET (t),
size_int (tree_to_uhwi (DECL_FIELD_BIT_OFFSET (t))
  / BITS_PER_UNIT));

```

and:
```
case ARRAY_REF:
...
  off = size_binop (MULT_EXPR, TYPE_SIZE_UNIT (TREE_TYPE (expr)), t);
```

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #5 from kargls at comcast dot net ---
(In reply to anlauf from comment #4)
> (In reply to kargls from comment #3)
> > Created attachment 57109 [details]
> > patch
> > 
> > The attached patch has been regtested.  There were no regression.
> 
> Steve,
> 
> I just tried your patch.  While it fixes comment#0, it misses:
> 
>   print *, atan(1.d0,1.0)
> end
> 

Ugh.  I forgot literal constants don't have symtrees or names. :(


gfc_error ("%qs argument of %qs intrinsic at %L must be the same type "
"and kind as %qs", (*ap)->next->expr->symtree->name, name,
&(*ap)->next->expr->where, (*ap)->expr->symtree->name);


The pointers to expr->symtree is NULL.  This new patch catches your example.

diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index c35f2bdd183..a8a92874583 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4371,7 +4371,19 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
 goto do_sort;

 whoops:
-  gfc_error ("Too many arguments in call to %qs at %L", name, where);
+  if ((gfc_option.allow_std & GFC_STD_F2008) != 0
+  && strcmp(name, "atan") == 0)
+{
+  if ((*ap)->expr->symtree == NULL || (*ap)->next->expr->symtree == NULL)
+   gfc_error ("Arguments of %qs intrinsic at %L must have the same "
+  "type and kind", name, &(*ap)->expr->where);
+  else
+   gfc_error ("%qs argument of %qs intrinsic at %L must be the same "
+  "type and kind as %qs", (*ap)->next->expr->symtree->name,
+  name, &(*ap)->next->expr->where,
(*ap)->expr->symtree->name);
+}
+  else
+gfc_error ("Too many arguments in call to %qs at %L", name, where);
   return false;

 keywords:

[Bug c/46116] Allow passing of anonymous aggregates when signature matches

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
Fixed for GCC 14 with C23 work.

[Bug c/114361] ICE with c23 related to completion of incomplete structure types

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:871bb5ad2dd56343d80b6a6d269e85efdce5

commit r14-9763-g871bb5ad2dd56343d80b6a6d269e85efdce5
Author: Martin Uecker 
Date:   Thu Mar 28 19:15:40 2024 +0100

Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

We did not copy TYPE_CANONICAL to the incomplete variants when
completing a structure.

PR c/114361

gcc/c/
* c-decl.cc (finish_struct): Set TYPE_CANONICAL when completing
strucute types.

gcc/testsuite/
* gcc.dg/pr114361.c: New test.
* gcc.dg/c23-tag-incomplete-1.c: New test.
* gcc.dg/c23-tag-incomplete-2.c: New test.

[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

--- Comment #10 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > So I am actually asking if the extension actually has any useful meaning?
> 
> For non-darwin, yes, it requests the storage of two initializer lists to be
> merged (see the commit msg for r14-1500-g4d935f52b0d5c0).

Though that doesn't involve the attribute, and promoting init-lists to static
should work fine on darwin.

(In reply to Jonathan Wakely from comment #6)
> The question then is whether the attribute is supposed to be a non-binding
> request or not.
> 
> If it's a non-binding request then the test should be adjusted/unsupported
> for this target.

It is a non-binding request. And yes, if this optimization is problematic on
darwin, we should adjust the test.

[Bug middle-end/41088] "TYPE_UNSIGNED (type) = 1;" in fixup_unsigned_type may be deleted

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
The opposite happened, that is the change for TYPE_UNSIGNED was removed from
layout_type by r0-125924-gc0e081a968c78d so I think we can close this as fixed.


https://gcc.gnu.org/pipermail/gcc-patches/2013-October/372486.html

[Bug preprocessor/36320] Required diagnosis of syntax error missed

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

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

Bug 36453 Summary: [DR 412] PR36320 breaks boost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mueller at gcc dot gnu.org

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

[Bug preprocessor/36453] [DR 412] PR36320 breaks boost

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #17 from Andrew Pinski  ---
Dup.

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

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

[harald at gigawatt dot nl via Gcc-bugs]

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

--- Comment #18 from Harald van Dijk  ---
(In reply to Kaz Kylheku from comment #17)
> The standrad does not define the conversion at the *type* level.
> ...
> The program is strictly conforming because it has no problem with type.

The DRs I referenced include ones where type errors have explicitly been stated
not to render behaviour undefined.

DR 132 (C90):

  /* No headers included */
  int checkup()
  {
  /* Case 1 */
  if (0)
  printf("Printing.\n");
  /* Case 2 */
  return 2 || 1 / 0;
  } 

  Response: "The Response to Defect Report #109 addresses this issue. The
translation unit must be successfully translated."

This, despite the fact that it implicitly declares as int(*)(), which is
incompatible with the type it is meant to be declared as.

The distinction you see between type errors and non-type errors is not one that
I believe is supported by previous DR responses.

> We wouldn't say that
> 
>   void f(void) { "abc" / "def"; }
> 
> is strictly conforming because f is not called in the program. There is a
> type problem. Now in this case there is a constraint violation: it requires
> a diagnostic.

My position is that it is *only* because this violates a constraint that this
cannot be part of a strictly conforming program, even if never called, as far
as standard C is concerned. That is why implementations are allowed to reject
it without program flow analysis.

> Anyway, this is all moot because this bugzilla is about GNU C, which has the
> extension. The behavior is locally defined.

Sure, I'm happy to put that aside if it becomes irrelevant to the bug.

> We would like NOT to have a diagnostic under -Wpedantic, so we are on the
> same page.
> 
> Whether your program is strictly conforming or not, we would like not to
> have it diagnosed under the -Wpedantic umbrella, and even if it is changed
> to a program which calls f.
> 
> There is nothing wrong with the diagnostic, but it should be uncoupled from
> -Wpedantic and available under its own option.   Possibly, an umbrella
> option could exist for this kind of "super pedantic" errors, like
> -Wconforming-extensions (warn about the use of GNU extensions that are
> conforming, and thus require no diagnostic by ISO C).

Agreed that having the warning is useful. If 'gcc -std=c99 -pedantic-errors'
emits a warning for this, regardless of whether it is enabled by default, that
is fine, and that does not prevent it from being a valid implementation of the
'c99' utility.

[Bug target/91298] $ at the beginging causing Error: junk `(%rip)' after expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
  Known to work||10.1.0, 8.4.0, 8.5.0, 9.3.0
  Known to fail||7.1.0, 7.5.0, 8.3.0, 9.1.0,
   ||9.2.0

[Bug target/91298] $ at the beginging causing Error: junk `(%rip)' after expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

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

[Bug target/31782] Invalid assembly code on initial dollar signs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #15 from Andrew Pinski  ---
Dup of bug 91298 .

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

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

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

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

--- Comment #9 from Jeffrey A. Law  ---
Thanks for that info Edwin -- my tester flagged them too and mentally I'd
figured it was most likely the combiner change.

[Bug target/114566] Misaligned vmovaps when compiling with stack-protector-strong for znver4

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Yuxuan Shui from comment #7)
> Looks similar to Bug 110027, but ASAN is not involved here.

Right, someone will need to debug it but I looked at the patch for PR 110027
and it is ASAN specific though.

[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Iain Sandoe from comment #7)
> So I am actually asking 
>  - if the extension actually has any useful meaning?

YES it does. Especially when it comes to the ability to reduce space used.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2752r2.html is the
link to the paper that is referenced as the notion for the extension.

I think this is a minor issue from the point of view of the testcase can just
be xfailed on darwin really.

Though I suspect the backend will/should be fixed to mark the alias as being
the same symbols really.

[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Iain Sandoe from comment #7)
> So I am actually asking 
>  - if the extension actually has any useful meaning?

For non-darwin, yes, it requests the storage of two initializer lists to be
merged (see the commit msg for r14-1500-g4d935f52b0d5c0).

>  - if it is an extension it probably should be only available in gnu:: ?

It's a standard attribute. The extension is allowing it to be placed on
variables that aren't non-static data members. If you spell it
gnu::no_unique_address then it's a completely different attribute (and in that
case I'd suggest an alternative name, because we don't want to recreate the
msvc::no_unique_address debacle, or even give the impression of doing so!)

[Bug tree-optimization/110498] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector::reserve

[michael.ragazzon at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Michael Ragazzon  ---
(In reply to Andrew Pinski from comment #2)
> std::vector is a different issue and filed as PR 18.

Thanks for pointing me in the right direction. I believe the warnings in the
description points to vector being used here as well. Perhaps they are
duplicates?

[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4

[yshuiv7 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Yuxuan Shui  ---
Looks similar to Bug 110027, but ASAN is not involved here.

[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110621
 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #6 from Andrew Pinski  ---
(In reply to Yuxuan Shui from comment #5)
> And -fstack-protector-strong is needed.

Oh ...

[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[12/13 Regression] ICE in   |[12 Regression] ICE in
   |gfc_get_array_span, at  |gfc_get_array_span, at
   |fortran/trans-array.c:865   |fortran/trans-array.c:865
   |since   |since
   |r12-1233-gd514626ee2566c68  |r12-1233-gd514626ee2566c68

--- Comment #8 from anlauf at gcc dot gnu.org ---
I get the same behavior at r13-8559 as 14-mainline.  There seems to be
another commit that fixed it independently.

Removing 13-branch from the regression list.

[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4

[yshuiv7 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Yuxuan Shui  ---
And -fstack-protector-strong is needed.

[Bug tree-optimization/110498] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector::reserve

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Michael Ragazzon from comment #1)
> I seem to also have encountered this issue while using `std::vector`.
> Here is a relatively small reproducer.

std::vector is a different issue and filed as PR 18.

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[ewlu at rivosinc dot com via Gcc-bugs]

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

--- Comment #8 from Edwin Lu  ---
(In reply to Robin Dapp from comment #7)
> There is some riscv fallout as well.  Edwin has the details.

I haven't done an in depth analysis but the full list of new riscv scan-dump
failures can be found here:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/694

[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4

[yshuiv7 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Yuxuan Shui  ---
Reduced a bit further:

void setup_tone_curves(float binHz, float center_decay_rate) {
  float workc[8][56];
  memset(workc, 0, sizeof(workc));

  for (int j = 0; j < 8; j++) {
for (int k = 0; k < 56; k++) {
  float adj =  k * center_decay_rate;
  if (adj < 0.)
adj = 0.;
  if (adj > 0.)
adj = 0.;
  workc[j][k] += adj;
}
  }

  int lo_curve = log(binHz);
}

Some observations:

1. lo_curve, although dead code, triggers the bug.
2. the 2 if's in the loop are also required for this bug.
3. workc has to be initialized with memset, aggregate initializer doesn't
trigger the bug.

[Bug tree-optimization/110498] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector::reserve

[michael.ragazzon at gmail dot com via Gcc-bugs]

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

Michael Ragazzon  changed:

   What|Removed |Added

 CC||michael.ragazzon at gmail dot 
com

--- Comment #1 from Michael Ragazzon  ---
I seem to also have encountered this issue while using `std::vector`.
Here is a relatively small reproducer.

Compile with: -O3 -std=c++17 -Wall -Werror

---

#include 
#include 

class Testing {
public:
Testing();

private:
std::vector elements;
};

Testing::Testing()
{
// Warning emitted when set to any number in the range [1,64].
constexpr size_t reserve_size = 30;

elements.reserve(reserve_size);
elements.push_back(0);
}

int main() {
Testing testing;
}

---

https://godbolt.org/z/eG66sjsPq

This issue seems to have started with GCC 13.1, and exists also on current
trunk (tested on Compiler Explorer).

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #3)
> Created attachment 57109 [details]
> patch
> 
> The attached patch has been regtested.  There were no regression.

Steve,

I just tried your patch.  While it fixes comment#0, it misses:

  print *, atan(1.d0,1.0)
end

I get as traceback:

f951: internal compiler error: Segmentation fault
0x1121b3f crash_signal
../../gcc-trunk/gcc/toplev.cc:319
0x9cde02 sort_actual
../../gcc-trunk/gcc/fortran/intrinsic.cc:4381
0x9ceac2 check_specific
../../gcc-trunk/gcc/fortran/intrinsic.cc:4795
0x9cf2f0 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc-trunk/gcc/fortran/intrinsic.cc:5067
0xa350b1 resolve_unknown_f
../../gcc-trunk/gcc/fortran/resolve.cc:3039
0xa47ff0 resolve_function
../../gcc-trunk/gcc/fortran/resolve.cc:3396
0xa46df9 gfc_resolve_expr(gfc_expr*)
../../gcc-trunk/gcc/fortran/resolve.cc:7526
0xa5bc46 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.cc:12619
0xa5d0b2 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.cc:11432
0xa5bbfe gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.cc:12609
0xa5ec88 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.cc:18463
0xa4080b gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.cc:18498
0xa26806 resolve_all_program_units
../../gcc-trunk/gcc/fortran/parse.cc:7034
0xa26ffd gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.cc:7290
0xa8f6df gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.cc:241

[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

--- Comment #7 from Iain Sandoe  ---
however:

 1) it is not in the gnu:: namespace the tests just have it as [[ ]].
 2) I do not think that the standard has anything to say about how entities at
file scope are ordered in memory (many/most impls. probably use the same order
as the file - but I do not think they are obliged to).
3) it is an ABI break for Darwin (where two global entities are not allowed to
have the same address - although it _is_ possible to tell the linker that one
is an alias for another - that support is not (yet) available in the FE).

So I am actually asking 
 - if the extension actually has any useful meaning?
 - if it is an extension it probably should be only available in gnu:: ?

[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4

[yshuiv7 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Yuxuan Shui  ---
Roughly reduced example:

#include 
#include 

#define toOC(n) (log(n)*1.442695f-5.965784f)

float *setup_tone_curves(float binHz,
 float center_decay_rate) {
  float workc[8][56];
  float *ret = NULL;

  memset(workc, 0, sizeof(workc));

  for (int j = 0; j < 8; j++) {
for (int k = 0; k < 56; k++) {
  float adj =  k * center_decay_rate;
  if (adj < 0.)
adj = 0.;
  if (adj > 0.)
adj = 0.;
  workc[j][k] += adj;
}
  }

  int lo_curve, bin = 0;
  lo_curve = ceil(toOC(bin * binHz + 1) * 2);

  return (ret);
}

int main() {
  setup_tone_curves(86.1328125, 0.625001);
  return 0;
}

[Bug libstdc++/114519] [14 Regression] GCC 14 trunk fails to compile chrono with -fno-char8_t -std=gnu++20

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||13.2.0
  Known to fail||14.0
Summary|GCC 14 trunk fails to   |[14 Regression] GCC 14
   |compile chrono with |trunk fails to compile
   |-fno-char8_t -std=gnu++20   |chrono with -fno-char8_t
   ||-std=gnu++20

--- Comment #4 from Jonathan Wakely  ---
Fixed, thanks for the report.

[Bug libstdc++/114519] GCC 14 trunk fails to compile chrono with -fno-char8_t -std=gnu++20

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:21aa57e73b820395b7b01843d61ef5b84cd20d02

commit r14-9761-g21aa57e73b820395b7b01843d61ef5b84cd20d02
Author: Jonathan Wakely 
Date:   Thu Mar 28 21:29:17 2024 +

libstdc++: Guard uses of char8_t with __cpp_char8_t [PR114519]

libstdc++-v3/ChangeLog:

PR libstdc++/114519
* include/bits/unicode.h (_Utf8_view): Guard with check for
char8_t being enabled.
(__literal_encoding_is_unicode): Guard use of char8_t with check
for it being enabled.
* testsuite/std/format/functions/114519.cc: New test.

[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

--- Comment #6 from Jonathan Wakely  ---
Yes, I think it's an extension, added by r14-1500-g4d935f52b0d5c0

The question then is whether the attribute is supposed to be a non-binding
request or not.

If it's a non-binding request then the test should be adjusted/unsupported for
this target. If the latter, then that use of the attribute should be ill-formed
for this target and give an error.

[Bug fortran/31580] Better error message for not-found operator

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Tom Tromey :

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

commit r14-9760-gca2f7c84927f85b95f0f48f82b93f1460c372db4
Author: Tom Tromey 
Date:   Sat Mar 30 13:48:30 2024 -0600

libiberty: Invoke D demangler when --format=auto

Investigating GDB PR d/31580 showed that the libiberty demangler
doesn't automatically demangle D mangled names.  However, I think it
should -- like C++ and Rust (new-style), D mangled names are readily
distinguished by the leading "_D", and so the likelihood of confusion
is low.  The other non-"auto" cases in this code are Ada (where the
encoded form could more easily be confused by ordinary programs) and
Java (which is long gone, but which also shared the C++ mangling and
thus was just an output style preference).

This patch also fixed another GDB bug, though of course that part
won't apply to the GCC repository.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276

libiberty
* cplus-dem.c (cplus_demangle): Try the D demangler with
"auto" format.
* testsuite/d-demangle-expected: Add --format=auto test.

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

[kkylheku at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Kaz Kylheku  ---
(In reply to Harald van Dijk from comment #14)
> (In reply to Joseph S. Myers from comment #11)
> > I think that simply failing to say whether a value of type X may be
> > converted to type Y is clearly enough for it at least to be unspecified
> > whether or when such conversions are possible in a cast at all (which is
> > enough for rejecting the translation unit).
> 
> I disagree. You're reading something into the standard that it does not say
> anywhere. It would make sense if it did say that, but it doesn't.

The standrad does not define the conversion at the *type* level.

> 
> > And since no requirements are
> > imposed relating to such conversions at either translation time or runtime,
> > the definition of undefined behavior is met.
> 
> The behaviour at runtime is implicitly unspecified. The behaviour at
> translation time is not, as my program does not attempt to convert between
> any function and object pointer. Performing that conversion is undefined by
> omission. Writing code that *would* perform that conversion, if executed, is
> not undefined, because the standard defines the behaviour of code that is
> not executed: it does nothing.
> 
> I am assuming, at least, that there is no dispute that
> 
>   #include 
>   int main(void) {
> if (0) puts("Hello, world!");
> return 0;
>   }
> 
> has never been permitted to print "Hello, world!".
> 
> (In reply to Kaz Kylheku from comment #12)
> > It does not. You're relying on the implementation (1) glossing over the
> > undefined conversion at translation time (or supporting it as an extension)
> 
> I'm not.
> 
> > Undefined behavior means that the implementation is permitted to stop, at
> > translation or execution time, with or without the issuance of a diagnostic
> > message.
> 
> My program has no undefined behaviour. It is in the same category as
> 
>   void f(void) { 1/0; }
>   int main(void) { return 0; }
> 
> which is strictly confirming despite the division by zero in an uncalled
> function, despite division taking constant operands.

The program is strictly conforming because it has no problem with type. The
language defines a division operator for the types int x int -> int. There can
be divisions written x / y where we don't know that y is zero until a run-time
input is supplied.

The expression 1/0 has a meaning and is translatable; just the operand values
are bad.

Compilers have to be careful when doing constant folding not to blow up on bad
expressions that are not actually called.
Something like this could occur:

   switch (sizeof (T)) {
   case 4:
  ...  1 / (8 - sizeof (T));
   case 8
  ...  1 / (16 - sizeof (T));

   }

where if the size is 8, then case 4: never taken in that case, has a constant
division by zero.  Evaluation of constants is required for dead-code
elimination, so dead code elimination cannot be counted on to remove bad
expressions.

But:

  (void *) 

has no meaning at all due to a type problem. Because it's a type problem, it is
a static problem which speaks to the ability to translate the expression. That
ability is not required.

The standard is mum about converting a function pointer type to void * type,
regardless of the specific run-time values involved.

We wouldn't say that

  void f(void) { "abc" / "def"; }

is strictly conforming because f is not called in the program. There is a type
problem. Now in this case there is a constraint violation: it requires a
diagnostic.

(void *)  has a problem in the same category: operator not defined for
the given types. The only difference is that there is no requirement for a
diagnostic.

The implementation is justified in aborting the translation. Possibly with a
diagnostic (which could say "conversion of function pointers to data pointers
is not supported, goodbye!").

In summary,   (void *)   is a type mismatch error, which is not caught
by the C type system due to there being no constraint violation. It's a hole in
the type system.

When an implementation hits a situation that triggers a hole in the type
system, it is allowed to diagnose it and reject the program.

Anyway, this is all moot because this bugzilla is about GNU C, which has the
extension. The behavior is locally defined.

We would like NOT to have a diagnostic under -Wpedantic, so we are on the same
page.

Whether your program is strictly conforming or not, we would like not to have
it diagnosed under the -Wpedantic umbrella, and even if it is changed to a
program which calls f.

There is nothing wrong with the diagnostic, but it should be uncoupled from
-Wpedantic and available under its own option.   Possibly, an umbrella option
could exist for this kind of "super pedantic" errors, like
-Wconforming-extensions (warn about the use of GNU extensions that are
conforming, and thus require no diagnostic by ISO C).

[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||14.0
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
   |ICE in gimplify_expr, at|in gimplify_expr, at
   |gimplify.c:15668 since  |gimplify.c:15668 since
   |r12-4464-g017665f63047ce47  |r12-4464-g017665f63047ce47

--- Comment #4 from anlauf at gcc dot gnu.org ---
Seems to ICE no longer at r14-9759, but 13-branch and older still fail.
Adjusting summary.

But is it really invalid code?  Intel and NAG accept it.

[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine

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

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

Mikael Morin  changed:

   What|Removed |Added

   Assignee|mikael at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #23 from Mikael Morin  ---
(In reply to anlauf from comment #22)
> Mikael,
> 
> since you did the essential work and commit, I am reassigning to you.

Well, I'm not working on this any more.
As far as I know, comment #0 is fixed, but comment #14 remains unfixed.

[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4

[yshuiv7 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Yuxuan Shui  ---
/nix/store/qp3k692bxjhlzvsdqpq7mdylfyr7i1ln-gcc-wrapper-13.2.0/bin/gcc 
-I/tmp/vorbis/include -I/tmp/vorbis/lib -O3 -march=znver4 -mtune=znver4 -g -o
psy.c.o -c /tmp/vorbis/lib/psy.c -v
Using built-in specs.
COLLECT_GCC=/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/bin/gcc
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-13.2.0/configure
--prefix=/nix/store/-gcc-13.2.0
--with-gmp-include=/nix/store/-gmp-6.3.0-dev/include
--with-gmp-lib=/nix/store/-gmp-6.3.0/lib
--with-mpfr-include=/nix/store/-mpfr-4.2.1-dev/include
--with-mpfr-lib=/nix/store/-mpfr-4.2.1/lib
--with-mpc=/nix/store/-libmpc-1.3.1
--with-native-system-header-dir=/nix/store/-glibc-2.38-44-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/nix/store/-gcc-13.2.0/include/c++/13.2.0/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-static
--enable-languages=c,c++ --disable-multilib --enable-plugin --disable-libcc1
--with-isl=/nix/store/-isl-0.20
--disable-bootstrap --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
COLLECT_GCC_OPTIONS='-fPIC' '-O2' '-U' '_FORTIFY_SOURCE' '-Wformat=1'
'-Wformat-security' '-Werror=format-security' '-fstack-protector-strong'
'--param=ssp-buffer-size=4' '-fno-strict-overflow' '-I' '/tmp/vorbis/include'
'-I' '/tmp/vorbis/lib' '-O3' '-march=znver4' '-mtune=znver4' '-g' '-o'
'psy.c.o' '-c' '-v' '-U' '_FORTIFY_SOURCE' '-D' '_FORTIFY_SOURCE=3' '-B'
'/nix/store/bzjyfnr8g585gvxjgiabn28qdm32b02n-glibc-2.38-44/lib/' '-idirafter'
'/nix/store/j79rphhc2vmb7rrxvx0aymhkw8bpkckf-glibc-2.38-44-dev/include'
'-idirafter'
'/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed'
'-B' '/nix/store/7ngrcd0a7q460gyg8grx6pipwzpgy0vq-gcc-13.2.0-lib/lib' '-B'
'/nix/store/qp3k692bxjhlzvsdqpq7mdylfyr7i1ln-gcc-wrapper-13.2.0/bin/'
'-frandom-seed=wbmyj7xk8s' '-isystem'
'/nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include'
'-isystem'
'/nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include'

/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/libexec/gcc/x86_64-unknown-linux-gnu/13.2.0/cc1
-quiet -v -I /tmp/vorbis/include -I /tmp/vorbis/lib -U _FORTIFY_SOURCE -U
_FORTIFY_SOURCE -D _FORTIFY_SOURCE=3 -idirafter
/nix/store/j79rphhc2vmb7rrxvx0aymhkw8bpkckf-glibc-2.38-44-dev/include
-idirafter
/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed
-isystem /nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include
-isystem /nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include
/tmp/vorbis/lib/psy.c -quiet -dumpbase psy.c.c -dumpbase-ext .c -march=znver4
-mtune=znver4 -g -O2 -O3 -Wformat=1 -Wformat-security -Werror=format-security
-version -fPIC -fstack-protector-strong -fno-strict-overflow
-frandom-seed=wbmyj7xk8s --param=ssp-buffer-size=4 -o
/tmp/nix-shell.Yn7YW0/ccu1mT2u.s
GNU C17 (GCC) version 13.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"/nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include"
ignoring nonexistent directory
"/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/nix/store/j79rphhc2vmb7rrxvx0aymhkw8bpkckf-glibc-2.38-44-dev/include"
ignoring duplicate directory
"/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed"
#include "..." search starts here:
#include <...> search starts here:
 /tmp/vorbis/include
 /tmp/vorbis/lib
 /nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include

/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include
 /nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/include

/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed
 /nix/store/j79rphhc2vmb7rrxvx0aymhkw8bpkckf-glibc-2.38-44-dev/include
End of search list.
Compiler executable checksum: b33e0c81578694d9e35e19d87dacd083
COLLECT_GCC_OPTIONS='-fPIC' '-O2' '-U' '_FORTIFY_SOURCE' '-Wformat=1'
'-Wformat-security' '-Werror=format-security' '-fstack-protector-strong'
'--param=ssp-buffer-size=4' 

[Bug fortran/113956] [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> (In reply to Paul Thomas from comment #3)
> > I can see why the assert is there but it is manifestly wrong for both the
> > assumed length target and a constant length.
> 
> That's why I wanted to pass this on to you.  I am not sure what the precise
> logic should be.
> 
> > I was thrown a bit by the
> > distros nulling out the asserts so that it compiled just fine with the
> > system gfortran.
> 
> If the system gfortran is based on 13.2 *release* then the bug is not yet
> there ;-)  It entered 13-branch through backport r13-7986.
> 
> > Your patch is perfect :- This compiles and runs correctly:

Paul, if you want to commit the patch, consider it preapproved  :-)

Otherwise I would take it, but I fear possible subtleties in the logic
involved that I do not see...

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

[harald at gigawatt dot nl via Gcc-bugs]

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

--- Comment #16 from Harald van Dijk  ---
(In reply to Joseph S. Myers from comment #15)
> In the cases where there is no statement either way, the behavior is
> undefined as a property of the translation unit (not just of the execution):
> it is not defined whether such a conversion may occur in a translation unit,

This is still not stated anywhere in the standard though.

> Being undefined
> through omission of definition has, as per clause 4, not difference in
> meaning or emphasis from being explicitly undefined.

Of course, but if the standard had explicitly stated that conversion between
function pointers and object pointers was undefined, it might be phrased in a
way that applies even to dead code. If you are relying on being undefined by
omission, you have to be really sure the behaviour is not defined *anywhere*,
including by general rules about dead code.

I will grant that the standard never explicitly says dead code is not executed
and has no effect, but if this is in dispute, we have a bigger problem.

> I'd suggest working with the Undefined Behavior Study Group on making it
> more explicit for each instance of undefined behavior whether it is a
> property of the program or of an execution thereof, but if any case seems
> particularly unclear, filing an issue once the new C standard issue tracker
> is up and running would probably be reasonable (but it seems likely that
> such issues would be referred to the UB study group to recommend a
> resolution just as floating-point issues would likely be referred to the CFP
> group).

Considering my stance is that WG14 have repeatedly and consistently stated what
the rules are, I see this as a waste of their time.

> It's *not* the case that the same rules apply everywhere, because there are
> two different kinds of UB depending on whether what's undefined is a
> property of the program or an execution thereof. Division by zero is
> obviously UB as a property of an execution, because whether a value is zero
> is a property of the execution.

Considering this example of 1/0 has been the subject of two separate DRs that I
referenced, I have to say it is not obvious from the standard itself. Keeping
in mind that the operands are constants and implementations are required to be
capable of constant expression evaluation in some contexts, a hypothetical
standard that permitted, or even required, this to be evaluated at translation
time (with undefined behaviour) even in otherwise dead code would make perfect
sense. But that is not the C standard we have, at least not the official
interpretation of it.

> Different types for the same identifier with
> external linkage in different translation units is obviously UB as a
> property of the program (and not widely diagnosed without LTO), as the whole
> concept of an identifier corresponding to an object with a particular value
> depends on a globally consistent notion of its type and the UB is about
> presence of declarations rather than a particular path of execution.

Yes, because a program that does not reference these identifiers still violates
the rule that specifies they must have compatible type. This means that there
is no execution of the program that avoids UB.

But in my program, there is no rule that is violated. Perhaps the rule that you
describe in your comment, that no program may contain any unsupported
conversion anywhere, regardless of whether the conversion is ever performed,
should exist, but it is simply not the case that there is such a rule to be
found anywhere in the standard.

One additional comment, though:

The fact that conversions between function pointers and object pointers are
rejected under -pedantic-errors mean that 'gcc -std=c99 -pedantic-errors'
cannot  be used as the implementation for POSIX's c99 utility, as POSIX's c99
utility is required to conform to the C99 standard, and simultaneously, permit
conversions between function pointers and object pointers (at least in some
cases). (Adjust for later versions as needed.) This is unfortunate, and
regardless of whether the C standard allows such programs to be rejected, can
we agree that the C standard also allows them to be accepted, and POSIX
requires them to be accepted? Is that not already sufficient reason to
reconsider?

[Bug testsuite/111066] g++.dg/special/initpri3.C fails on darwin

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

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

commit r13-8564-gf650cfccc61f0352f9c3a0993457e1cb7845bc7a
Author: Francois-Xavier Coudert 
Date:   Sat Aug 19 22:37:33 2023 +0200

Testsuite: fix contructor priority test

Fix the expected warning wording for targets without constructor
priority, like Darwin, making the test pass.

gcc/testsuite/ChangeLog:

PR testsuite/111066
* g++.dg/special/initpri3.C: Fix wording.

(cherry picked from commit 78f636d979530c8a649262dbd44914bdfb6f7290)

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

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

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

Robin Dapp  changed:

   What|Removed |Added

 CC||ewlu at rivosinc dot com,
   ||rdapp at gcc dot gnu.org

--- Comment #7 from Robin Dapp  ---
There is some riscv fallout as well.  Edwin has the details.

[Bug middle-end/114547] comparison than less than 0 (or greater or equal to than 0) after a subtraction does not use the flags regster

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ubizjak at gmail dot com
   Last reconfirmed||2024-04-02
 Status|UNCONFIRMED |NEW

--- Comment #3 from Uroš Bizjak  ---
The similar testcase with comparison to zero:

int z(int *v, int n) {
*v -= n;
return *v == 0;
}

int nz(int *v, int n) {
*v -= n;
return *v != 0;
}

generates expected code:

z:
xorl%eax, %eax
subl%esi, (%rdi)
sete%al
ret

nz:
xorl%eax, %eax
subl%esi, (%rdi)
setne   %al
ret

The middle end expands via standard sequence:

(insn 10 9 11 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 83 [ _2 ])
(const_int 0 [0]))) "s.c":3:12 -1
 (nil))

(insn 11 10 12 (set (reg:QI 91)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "s.c":3:12 -1
 (nil))

(insn 12 11 13 (set (reg:SI 90)
(zero_extend:SI (reg:QI 91))) "s.c":3:12 -1
 (nil))

(insn 13 12 14 (set (reg:SI 85 [  ])
(reg:SI 90)) "s.c":3:12 -1
 (nil))

OTOH, the sign compare is expanded via:

(insn 12 9 13 (parallel [
(set (reg:SI 90)
(lshiftrt:SI (reg:SI 83 [ _2 ])
(const_int 31 [0x1f])))
(clobber (reg:CC 17 flags))
]) "pr114547.c":4:12 -1
 (nil))

(insn 13 12 14 (set (reg:SI 85 [  ])
(reg:SI 90)) "pr114547.c":4:12 -1
 (nil))

(The above shift also interferes with RMW creation, resulting in unoptimal asm
sequence with two extra moves, and additional NEG insn in "ns" case.)

Middle-end expansion should avoid premature optimization in this case, at least
for targets that can merge sign comparison with the arith instruction.

[Bug c++/114479] [14 Regression] std::is_array_v changed from false to true in GCC 14

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c++/114479] [14 Regression] std::is_array_v changed from false to true in GCC 14

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:2f2924078ce51c2a0da3ad8f958f2d1de533969a

commit r14-9759-g2f2924078ce51c2a0da3ad8f958f2d1de533969a
Author: Marek Polacek 
Date:   Mon Apr 1 12:55:46 2024 -0400

c++: make __is_array return false for T[0] [PR114479]

When we switched to using the __is_array built-in trait to implement
std::is_array in r14-6623-g7fd9c349e45534, we started saying that
T[0] is an array.  There are various opinions as to whether that is
the best answer, but it seems prudent to keep the GCC 13 result.

PR c++/114479

gcc/cp/ChangeLog:

* semantics.cc (trait_expr_value) : Return
false
for zero-sized arrays.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_array.C: Extend.

[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-04-02
 Target|x86_64-linux-gnu|x86_64
 Ever confirmed|0   |1
   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
Can you provide a few more information? Like the preprocessed source for psy.c
and the exact command line that is invoked for GCC?

Also provide the full output of `gcc -v`?

This is all that is requested by https://gcc.gnu.org/bugs/

[Bug c++/103825] ICE on switch on enum class in bitfield

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Marek Polacek  ---
Fixed for 14/13.

[Bug c++/103825] ICE on switch on enum class in bitfield

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:22510e4a68aa9ca850db34ae62c21c58442d8ab3

commit r13-8560-g22510e4a68aa9ca850db34ae62c21c58442d8ab3
Author: Marek Polacek 
Date:   Fri Mar 29 16:59:37 2024 -0400

c++: ICE with scoped enum in switch condition [PR103825]

Here we ICE when gimplifying

  enum class Type { Pawn };
  struct Piece {
Type type : 4;
  };
  void foo() {
switch (Piece().type)
  case Type::Pawn:;
  }

because we ended up with TYPE_PRECISION (cond) < TYPE_PRECISION (case).
That's because the case expr type here is the unlowered type Type,
whereas the conditional's type is the lowered .  This
is not supposed to happen: see the comment in pop_switch around the
is_bitfield_expr_with_lowered_type check.

But here we did not revert to the lowered SWITCH_STMT_TYPE, because
the conditional contains a TARGET_EXPR, which has side-effects, which
means that finish_switch_cond -> maybe_cleanup_point_expr wraps it
in a CLEANUP_POINT_EXPR.  And is_bitfield_expr_with_lowered_type does
not see through those.

PR c++/103825

gcc/cp/ChangeLog:

* typeck.cc (is_bitfield_expr_with_lowered_type): Handle
CLEANUP_POINT_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/enum44.C: New test.

(cherry picked from commit daa2e7c7ffe49b788357f7f2c9ef1c9b125c1f8c)

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

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

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

--- Comment #11 from Matthias Klose  ---
while not a test case, that was seen when running autopkg tests of the evolver
package against glibc 2.39 packages.

https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2052929

the failing evolver test is:

echo "g 5; v; r ; g 10; v;" | evolver-nox-q cube

[Bug c++/103825] ICE on switch on enum class in bitfield

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r14-9758-gdaa2e7c7ffe49b788357f7f2c9ef1c9b125c1f8c
Author: Marek Polacek 
Date:   Fri Mar 29 16:59:37 2024 -0400

c++: ICE with scoped enum in switch condition [PR103825]

Here we ICE when gimplifying

  enum class Type { Pawn };
  struct Piece {
Type type : 4;
  };
  void foo() {
switch (Piece().type)
  case Type::Pawn:;
  }

because we ended up with TYPE_PRECISION (cond) < TYPE_PRECISION (case).
That's because the case expr type here is the unlowered type Type,
whereas the conditional's type is the lowered .  This
is not supposed to happen: see the comment in pop_switch around the
is_bitfield_expr_with_lowered_type check.

But here we did not revert to the lowered SWITCH_STMT_TYPE, because
the conditional contains a TARGET_EXPR, which has side-effects, which
means that finish_switch_cond -> maybe_cleanup_point_expr wraps it
in a CLEANUP_POINT_EXPR.  And is_bitfield_expr_with_lowered_type does
not see through those.

PR c++/103825

gcc/cp/ChangeLog:

* typeck.cc (is_bitfield_expr_with_lowered_type): Handle
CLEANUP_POINT_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/enum44.C: New test.

[Bug c/114566] New: Misaligned vmovaps when compiling libvorbis for znver4

[yshuiv7 at gmail dot com via Gcc-bugs]

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

Bug ID: 114566
   Summary: Misaligned vmovaps when compiling libvorbis for znver4
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yshuiv7 at gmail dot com
  Target Milestone: ---

Haven't tried to minimize it yet, but here is how to reproduce it:

1. Download libvorbis 1.3.7 source: https://github.com/xiph/vorbis/tree/v1.3.7
2. Configure it: 
   cmake -B build -DCMAKE_C_FLAGS="-march=znver4 -mtune=znver4"
-DCMAKE_CXX_FLAGS="-march=znver4 -mtune=znver4" -DCMAKE_BUILD_TYPE=Release .
3. Run tests: 
   make -C build test

Stack trace:
#0  0x00410d2e in setup_tone_curves
(curveatt_dB=curveatt_dB@entry=0x4e1834, binHz=binHz@entry=86.1328125,
n=n@entry=256, center_boost=-1.0203, center_decay_rate=)
at /tmp/vorbis/lib/psy.c:129
#1  0x00413b24 in _vp_psy_init (p=0x4fe8c0, vi=,
gi=gi@entry=0x4e0be0, n=256,
rate=) at /tmp/vorbis/lib/psy.c:326
#2  0x0040a7b5 in _vds_shared_init (v=v@entry=0x7fffb370,
vi=vi@entry=0x7fffb330, encp=encp@entry=1)
at /tmp/vorbis/lib/block.c:225
#3  0x0040a93f in vorbis_analysis_init (v=v@entry=0x7fffb370,
vi=vi@entry=0x7fffb330)
at /tmp/vorbis/lib/block.c:298
#4  0x00404ad2 in write_vorbis_data_or_die (
filename=filename@entry=0x7fffb700 "vorbis_1ch_q-0.5_44100.ogg",
srate=srate@entry=44100,
q=q@entry=-0.050007, data=data@entry=0x4dc080 ,
count=count@entry=2048, ch=ch@entry=1)
at /tmp/vorbis/test/write_read.c:61
#5  0x0040456d in main () at /tmp/vorbis/test/test.c:58

Relevant part of the code:

   0x00410cee <+1854>:  add$0xe0,%rdx
   0x00410cf5 <+1861>:  vmovups %zmm17,-0xe0(%rdx)
   0x00410cff <+1871>:  vaddps -0xa0(%rdx),%zmm7,%zmm17
   0x00410d09 <+1881>:  vmovups %zmm17,-0xa0(%rdx)
   0x00410d13 <+1891>:  vaddps -0x60(%rdx),%zmm6,%zmm17
   0x00410d1d <+1901>:  vmovups %zmm17,-0x60(%rdx)
   0x00410d27 <+1911>:  vaddps -0x20(%rdx),%ymm0,%ymm17
=> 0x00410d2e <+1918>:  vmovaps %ymm17,-0x20(%rdx)

$rdx is 0x7fff3a10

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

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

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

--- Comment #15 from Joseph S. Myers  ---
There are several statements such as "Any pointer type may be converted to an
integer type." and "A pointer to an object type may be converted to a pointer
to a different object type.", that allow certain conversions to occur in a
translation unit and are associated with some properties of those conversions
if they are executed. There are also statements disallowing certain conversions
from occurring in a translation unit (for example, conversions between pointer
and floating types are constraint violations). In the cases where there is no
statement either way, the behavior is undefined as a property of the
translation unit (not just of the execution): it is not defined whether such a
conversion may occur in a translation unit, and not defined what the semantics
would be on execution if an implementation permits the translation of such a
conversion. Being undefined through omission of definition has, as per clause
4, not difference in meaning or emphasis from being explicitly undefined.

I'd suggest working with the Undefined Behavior Study Group on making it more
explicit for each instance of undefined behavior whether it is a property of
the program or of an execution thereof, but if any case seems particularly
unclear, filing an issue once the new C standard issue tracker is up and
running would probably be reasonable (but it seems likely that such issues
would be referred to the UB study group to recommend a resolution just as
floating-point issues would likely be referred to the CFP group).

It's *not* the case that the same rules apply everywhere, because there are two
different kinds of UB depending on whether what's undefined is a property of
the program or an execution thereof. Division by zero is obviously UB as a
property of an execution, because whether a value is zero is a property of the
execution. Different types for the same identifier with external linkage in
different translation units is obviously UB as a property of the program (and
not widely diagnosed without LTO), as the whole concept of an identifier
corresponding to an object with a particular value depends on a globally
consistent notion of its type and the UB is about presence of declarations
rather than a particular path of execution. In some cases, as here, it may be
less obvious how to read the wording as referring to properties of an execution
or of a program.

[Bug c++/114562] [11/12/13/14 Regression] ICE when trying to bind rvalue reference to lvalue with comma operator and forwarding reference to pointer since r10-7410

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:5d7e9a35024f065b25f61747859c7cb7a770c92b

commit r14-9757-g5d7e9a35024f065b25f61747859c7cb7a770c92b
Author: Jason Merrill 
Date:   Tue Apr 2 10:52:28 2024 -0400

c++: binding reference to comma expr [PR114561]

We represent a reference binding where the referent type is more qualified
by a ck_ref_bind around a ck_qual.  We performed the ck_qual and then tried
to undo it with STRIP_NOPS, but that doesn't work if the conversion is
buried in COMPOUND_EXPR.  So instead let's avoid performing that fake
conversion in the first place.

PR c++/114561
PR c++/114562

gcc/cp/ChangeLog:

* call.cc (convert_like_internal): Avoid adding qualification
conversion in direct reference binding.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref10.C: New test.
* g++.dg/conversion/ref11.C: New test.

[Bug c++/114561] [11/12/13/14 Regression] Comma operator with forwarding reference to pointer raises invalid lvalue required error since r10-7410

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:5d7e9a35024f065b25f61747859c7cb7a770c92b

commit r14-9757-g5d7e9a35024f065b25f61747859c7cb7a770c92b
Author: Jason Merrill 
Date:   Tue Apr 2 10:52:28 2024 -0400

c++: binding reference to comma expr [PR114561]

We represent a reference binding where the referent type is more qualified
by a ck_ref_bind around a ck_qual.  We performed the ck_qual and then tried
to undo it with STRIP_NOPS, but that doesn't work if the conversion is
buried in COMPOUND_EXPR.  So instead let's avoid performing that fake
conversion in the first place.

PR c++/114561
PR c++/114562

gcc/cp/ChangeLog:

* call.cc (convert_like_internal): Avoid adding qualification
conversion in direct reference binding.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref10.C: New test.
* g++.dg/conversion/ref11.C: New test.

[Bug rtl-optimization/113682] Branches in branchless binary search rather than cmov/csel/csinc

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=112402

--- Comment #8 from Andrew Pinski  ---
This might be the path splitting running on the gimple level causing issues
too; see PR 112402 .

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

[harald at gigawatt dot nl via Gcc-bugs]

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

--- Comment #14 from Harald van Dijk  ---
(In reply to Joseph S. Myers from comment #11)
> I think that simply failing to say whether a value of type X may be
> converted to type Y is clearly enough for it at least to be unspecified
> whether or when such conversions are possible in a cast at all (which is
> enough for rejecting the translation unit).

I disagree. You're reading something into the standard that it does not say
anywhere. It would make sense if it did say that, but it doesn't.

> And since no requirements are
> imposed relating to such conversions at either translation time or runtime,
> the definition of undefined behavior is met.

The behaviour at runtime is implicitly unspecified. The behaviour at
translation time is not, as my program does not attempt to convert between any
function and object pointer. Performing that conversion is undefined by
omission. Writing code that *would* perform that conversion, if executed, is
not undefined, because the standard defines the behaviour of code that is not
executed: it does nothing.

I am assuming, at least, that there is no dispute that

  #include 
  int main(void) {
if (0) puts("Hello, world!");
return 0;
  }

has never been permitted to print "Hello, world!".

(In reply to Kaz Kylheku from comment #12)
> It does not. You're relying on the implementation (1) glossing over the
> undefined conversion at translation time (or supporting it as an extension)

I'm not.

> Undefined behavior means that the implementation is permitted to stop, at
> translation or execution time, with or without the issuance of a diagnostic
> message.

My program has no undefined behaviour. It is in the same category as

  void f(void) { 1/0; }
  int main(void) { return 0; }

which is strictly confirming despite the division by zero in an uncalled
function, despite division taking constant operands. The implementation is not
at liberty to treat this as translation-time undefined behaviour, because the
program does not divide by zero. Even though constant expressions could
otherwise be optimised. And GCC rightly accepts this with -pedantic-errors.

It is in the same category as

  void f(x) void *x; { f(f); }
  int main(void) { return 0; }

which is strictly conforming despite the unevaluated function call to an
unprototyped function with a wrong argument type where the compiler knows the
type of the parameter. And GCC rightly accepts this too with -pedantic-errors.
It does not even warn by default.

There have been DRs that explicitly address this for various forms of undefined
behaviour (#109, #132, #317). Is it really necessary for WG14 to receive a
separate DR for every category of undefined behaviour to clarify that the same
rules for undefined behaviour apply everywhere?