[Bug target/100799] Stackoverflow in optimized code on PPC

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #23 from Jakub Jelinek  ---
Note, given that in PR90329 a workaround has been introduced for such buggy
cases (that time to disallow functions with the DECL_HIDDEN_STRING_LENGTH
arguments from making certain tail-calls and call them normally instead), if
the PowerPC backend maintainers wanted, there could be a similar workaround on
the rs6000 backend side,
in the decisions whether the callee can use the parameter save area or not
ignore counting DECL_HIDDEN_STRING_LENGTH PARM_DECLs, so if e.g. 9 arguments
are passed but one of them is DECL_HIDDEN_STRING_LENGTH, assume parameter save
area is not there.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #11 from Jakub Jelinek  ---
But what about following:
#include 
#include 

auto f = static_cast(::nexttoward);

This doesn't call std::nexttoward(std::float128_t, long double), just checks if
it is defined.

[Bug tree-optimization/109804] [11/12/13/14 Regression] internal compiler error in gimple-ssa-warn-access.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #9)
> Right.  Local unnamed enums are of the DEMANGLE_COMPONENT_UNNAMED_TYPE type,
> but those don't have their subtrees filed as per
> cplus_demangle_fill_component.  So I think we can't do *newc.u.s_binary.left
> when the type is DEMANGLE_COMPONENT_UNNAMED_TYPE.  Maybe they need a new
> case in new_delete_mismatch_p.

  ret->type = DEMANGLE_COMPONENT_UNNAMED_TYPE;
  ret->u.s_number.number = num;


Yes and we just need to compare the number.
Let me add that and test it.

[Bug middle-end/110316] [11/12/13/14 Regression] g++.dg/ext/timevar1.C and timevar2.C fail erratically

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|11.5|14.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug target/80491] [11/12/13/14 Regression] Compiler regression for long-add case.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #26 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #25)
> Hmm, I thought Jakub's recent work on PR 79173 would have fixed this but no
> it didn't.

But it does now, we get at -O2/-O3:
```
_Z3addR4pairS0_:
.LFB0:
.cfi_startproc
movq(%rsi), %rax
addq(%rdi), %rax
movq%rax, %rdx
movq8(%rsi), %rax
adcq8(%rdi), %rax
xchgq   %rdx, %rax
ret
```
Which is definitely better.

[Bug tree-optimization/102705] [12/13/14 Regression] Dead Code Elimination Regression at -O3 since r12-2637-g145bc41dae7c7bfa093d61e77346f98e6a595a0e

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

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

--- Comment #6 from Andrew Pinski  ---
Hmm:
  iftmp.0_10 = (char) _2;
  _4 = iftmp.0_10 ^ 1;
  _18 = (int) _4;


We have this pattern:
 /* In GIMPLE, getting rid of 2 conversions for one new results
in smaller IL.  */
 (simplify
  (convert (bitop:cs@2 (nop_convert:s @0) @1))
  (if (GIMPLE
   && TREE_CODE (@1) != INTEGER_CST
   && tree_nop_conversion_p (type, TREE_TYPE (@2))
   && types_match (type, @0)
   && !POINTER_TYPE_P (TREE_TYPE (@0))
   && TREE_CODE (TREE_TYPE (@0)) != OFFSET_TYPE)
   (bitop @0 (convert @1)


Except here @1 is CST and the we don't exactly have a nop_conversion, though it
is a "nop" due to the nonzero-bitranges to be less than the inner type.

Maybe we could expand or create a new pattern for this ...

[Bug target/104049] [12/13/14 Regression] vec_select to subreg lowering causes superfluous moves

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2022-01-17 00:00:00 |2024-2-20
 CC||pinskia at gcc dot gnu.org

--- Comment #20 from Andrew Pinski  ---
Testcase in comment #9 is still an issue on the trunk.

[Bug target/108803] [11/12/13/14 Regression] wrong code for 128bit rotate on aarch64-unknown-linux-gnu with -Og

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

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

--- Comment #9 from Andrew Pinski  ---
This looks to be to fixed on the trunk. Maybe r14-4647-gabf5ae4594 fixed
it?

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

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

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

--- Comment #14 from Andrew Pinski  ---
I think the rest are handled correctly but I have not audited everyone yet.

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

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

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

--- Comment #13 from Andrew Pinski  ---
And __builtin_aarch64_jcvtzs:


```
int
m ()
{
  __builtin_aarch64_jcvtzs(1.0);
}
```

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

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

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

--- Comment #12 from Andrew Pinski  ---
Likewise for the __builtin_aarch64_fcmla_laneq* builtins:

```
#define vect64 __attribute__((vector_size(8)))
#define vect128 __attribute__((vector_size(16)))
int
m ()
{
  unsigned long v;
  vect64 float t;
  vect128 float t1;
  __builtin_aarch64_fcmla_laneq0v2sf(t,t,t1,0);
}
```

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

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

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

--- Comment #11 from Andrew Pinski  ---
The CRC functions need a similar handling, e.g.:
```
int
f ()
{
  unsigned long v;
  return __builtin_aarch64_crc32b (v, v);
}
```

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

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

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 57476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57476=edit
Current patch

The error message needs some tweaking but this is basically the patch. Will
also add a few testcases too.

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
I have a (simple) fix.
Just need to tweak the exact error message.

[Bug target/90204] [11/12/13/14 Regression] C code is optimized worse than C++

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

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

Sam James  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #22 from Sam James  ---
r12-5390-gd3152981f71eef (Reduce cost of aligned sse register store.) seems to
be the fix.

[Bug sanitizer/99476] 'PATH_MAX' was not declared in this scope

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
This has to do with the way you are doing the cross compiling. Either use a
sysroot (with --with-sysroot=DIR) or use includedir as directed below.

[Bug sanitizer/106998] [11/12/13/14 Regression] libsanitizer PATH_MAX not defined for linux new targets

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Andrew Pinski  ---
I looked upstream (both llvm and google/sanitizers) and don't see any bug
filed.
I looked into the musl sources, limits.h has the following line:
e8b8f3c90 (Rich Felker 2011-06-25 15:38:00 -0400  47) #define PATH_MAX 4096

So this bug is invalid because musl's limits.h defines it and has had it
defined since 2011 :).

[Bug target/105513] [11/12/13/14 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|11.5|13.0

--- Comment #13 from Andrew Pinski  ---
Fixed for GCC 13.

[Bug tree-optimization/99078] [11/12/13/14 Regression] Optimizer moves struct initialization into loop

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

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

--- Comment #7 from Andrew Pinski  ---
Created attachment 57475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57475=edit
testcase

Just making it easier to access the testcase.

[Bug tree-optimization/98563] [11/12/13/14 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

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

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

--- Comment #13 from Andrew Pinski  ---
Looking at this, I see in PRE:
  REALPART_EXPR  = _25;
  IMAGPART_EXPR  = _26;
  _19 = REALPART_EXPR  [(const struct complex
&)][_8]._M_value>;

Should _19 be the same as _25 ?

I suspect if this is done, then the vectorizer would kick in and do the right
thing.

[Bug target/93930] [11/12/13/14 Regression] Unnecessary broadcast instructions for AVX512

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

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

--- Comment #9 from Andrew Pinski  ---
Looks to be fixed in GCC 11+.

[Bug target/90204] [11/12/13/14 Regression] C code is optimized worse than C++

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.1.0
  Known to work||12.1.0
   Keywords||needs-bisection

--- Comment #21 from Andrew Pinski  ---
Looks like compiling with the C front-end was fixed in GCC 12.

[Bug c++/89224] [11/12/13/14 Regression] subscript of const vector has the wrong type

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

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

--- Comment #16 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646115.html

[Bug target/114028] [14] RISC-V rv64gcv_zvl256b: miscompile at -O3

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

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

--- Comment #1 from Andrew Pinski  ---
Works fine on aarch64 with SVE:
```
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O3
t6.c -static -march=armv9-a+sve2 -fno-vect-cost-model
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out
;echo $?
0

```

[Bug target/114027] [14] RISC-V vector: miscompile at -O3

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

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

--- Comment #2 from Andrew Pinski  ---
Works fine on aarch64 with SVE:
```
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O3
t6.c -static -march=armv9-a+sve2
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out
;echo $?
0
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O3
t6.c -static -march=armv9-a+sve2 -fno-vect-cost-model
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out
;echo $?
0
```

[Bug target/114028] New: [14] RISC-V rv64gcv_zvl256b: miscompile at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114028
   Summary: [14] RISC-V rv64gcv_zvl256b: miscompile at -O3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int a, d = 55003;
long c, h;
long e = 1;
char g;
short i;

int main() {
  g = 0;
  for (; g < 16; g += 1) {
d |= c;
short l = d;
i = l < 0 || a >> 4 ? d : a;
h = i - 8L;
e &= h;
  }

  if (e == 1)
return 0;
  else
return 1;
}


Commands:
> /scratch/tc-testing/tc-feb-20/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv_zvl256b -O3 red.c -o red.out
> QEMU_CPU=rv64,vlen=256,v=true,vext_spec=v1.0,zve32f=true,zve64f=true 
> /scratch/tc-testing/tc-feb-20-llvm/build/bin/qemu-riscv64 user-config.out
> echo $?
1

> /scratch/tc-testing/tc-feb-20/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv_zvl256b -O2 red.c -o red.out
> QEMU_CPU=rv64,vlen=256,v=true,vext_spec=v1.0,zve32f=true,zve64f=true 
> /scratch/tc-testing/tc-feb-20-llvm/build/bin/qemu-riscv64 red.out
> echo $?
0

Discovered/tested using 61ab046a327 (not bisected)
Found using fuzzer

[Bug target/114027] [14] RISC-V vector: miscompile at -O3

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

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

--- Comment #1 from Sam James  ---
When this is fixed, this is probably worth putting in the general torture test
suite, not just for riscv.

[Bug target/114027] New: [14] RISC-V vector: miscompile at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114027
   Summary: [14] RISC-V vector: miscompile at -O3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
long a;
int b[10][7] = {{},
{},
{},
{},
{},
{},
{0, 0, 0, 0, 0, 1},
{1, 1, 1, 1, 1, 1},
{1, 1, 1, 1, 1, 1}};
int c;
int main() {
  int d;
  c = 0x;
  for (; a < 6; a++) {
d = 0;
for (; d < 6; d++) {
  c ^= -3L;
  if (b[a + 3][d])
continue;
  c = 0;
}
  }

  if (c == -3) {
return 0;
  } else {
return 1;
  }
}


Commands:
> /scratch/tc-testing/tc-feb-20/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O3 red.c -o red.out
> /scratch/tc-testing/tc-feb-20-llvm/build/bin/qemu-riscv64 red.out
> echo $?
1
> /scratch/tc-testing/tc-feb-20/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> red.c -o red.out
> /scratch/tc-testing/tc-feb-20-llvm/build/bin/qemu-riscv64 red.out
> echo $?
0

Discovered/tested using g61ab046a327 (not bisected)
Found using fuzzer

[Bug modula2/114026] incorrect location during for loop type check

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 57474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57474=edit
Proposed fix

Here is the proposed fix.

$ gm2 forloop.mod 
forloop.mod:10:8: error: In procedure ‘init’: type expression incompatibility
between ‘INTEGER’ and ‘CARDINAL’ detected when comparing the designator ‘i’
against the second expression ‘c’ in the FOR loop
   10 |FOR i := 0 TO c DO   (* INTEGER CARDINAL expression incompatible. 
*)
  |^~~

[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #2 from kargl at gcc dot gnu.org ---
This is ugly.  Essentially, the translation of an allocate statement is
mot prepared to have a complex-part-ref as the source expression.  For this
code

program foo
   implicit none
   complex :: cmp(3)
   real, allocatable :: xx(:), yy(:), zz(:)
   cmp = (3.45,6.78)
   allocate (xx, source = cmp%re)   ! ICE
   allocate (yy, source = cmp(1:3)%re)  ! ICE
   allocate (zz, source = (cmp%re))
   print *, xx
   print *, yy
   print *, zz
end

The lines marked with ICE will cause gfortran to, well, ICE.  The
following patch cures the issues by impose a set of parentheses 
about the source expression.  There is likely a better way.

diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 5247d3d39d7..6ff3f12d7ed 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6355,8 +6355,24 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist
*omp_allocate)
vtab_needed = (al->expr->ts.type == BT_CLASS);

   gfc_init_se (, NULL);
-  /* When expr3 is a variable, i.e., a very simple expression,
-then convert it once here.  */
+
+  /* When expr3 is a variable, i.e., a very simple expression, then
+convert it once here.  Note, if one has source = z%re or z%im, 
+then things can go sideways with the complex-part-ref, so wrap
+the entity in parentheses to force evaluation of an expression.
+That is, the else-branch of the ensuing if-else-stmt is entered.  */
+
+  if (code->expr3->ref
+ && ((code->expr3->ref->u.i == INQUIRY_RE
+  || code->expr3->ref->u.i == INQUIRY_IM)
+ || (code->expr3->ref->type == REF_ARRAY
+ && code->expr3->ref->u.ar.type == AR_SECTION)))
+   {
+ gfc_expr *etmp = gfc_get_parentheses (code->expr3);
+ code->expr3 = gfc_copy_expr (etmp);
+ gfc_free_expr (etmp);
+   }
+
   if (code->expr3->expr_type == EXPR_VARIABLE
  || code->expr3->expr_type == EXPR_ARRAY
  || code->expr3->expr_type == EXPR_CONSTANT)

[Bug analyzer/113999] [14 Regression] ICE: in string_cst_has_null_terminator, at analyzer/region-model.cc:3651 with -fanalyzer on gcc.dg/tree-ssa/strncpy-2.c

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above patch; marking as resolved.

[Bug target/94972] Function multi-versioning binary may crash dynamic linker

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=20019
 Resolution|--- |MOVED
 Status|WAITING |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Looks like it was fixed in dynamic linker.

Anyways no feedback in almost 4 years so closing as moved.

[Bug analyzer/113998] [14 Regression] ICE: in get_last_byte_offset, at analyzer/ranges.cc:171 with -fanalyzer and __builtin_strncpy()

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by the above patch; marking as resolved.

[Bug analyzer/113999] [14 Regression] ICE: in string_cst_has_null_terminator, at analyzer/region-model.cc:3651 with -fanalyzer on gcc.dg/tree-ssa/strncpy-2.c

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:0a6a5f8656ccf9a60ac516c68cd4eb40ff4630c4

commit r14-9091-g0a6a5f8656ccf9a60ac516c68cd4eb40ff4630c4
Author: David Malcolm 
Date:   Tue Feb 20 19:44:51 2024 -0500

analyzer: handle array-initialization from a string_cst [PR113999]

gcc/analyzer/ChangeLog:
PR analyzer/113999
* analyzer.h (get_string_cst_size): New decl.
* region-model-manager.cc (get_string_cst_size): New.
(region_model_manager::maybe_get_char_from_string_cst): Treat
single-byte accesses within string_cst but beyond
TREE_STRING_LENGTH as being 0.
* region-model.cc (string_cst_has_null_terminator): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/113999
* c-c++-common/analyzer/strlen-pr113999.c: New test.
* gcc.dg/analyzer/strlen-1.c: More test coverage.

Signed-off-by: David Malcolm 

[Bug analyzer/113998] [14 Regression] ICE: in get_last_byte_offset, at analyzer/ranges.cc:171 with -fanalyzer and __builtin_strncpy()

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:79d4c7ddc83e000adc8174b179dff44a88d5a41b

commit r14-9090-g79d4c7ddc83e000adc8174b179dff44a88d5a41b
Author: David Malcolm 
Date:   Tue Feb 20 19:44:50 2024 -0500

analyzer: handle empty ranges in symbolic_byte_range::intersection
[PR113998]

gcc/analyzer/ChangeLog:
PR analyzer/113998
* ranges.cc (symbolic_byte_range::intersection): Handle empty
ranges.
(selftest::test_intersects): Add test coverage for empty ranges.

gcc/testsuite/ChangeLog:
PR analyzer/113998
* c-c++-common/analyzer/overlapping-buffers-pr113998.c: New test.

Signed-off-by: David Malcolm 

[Bug other/91139] Attempts, fails to rebuild doc/gcc.info in tarball release build

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #4 from Andrew Pinski  ---
No feedback in over 4 years so closing as invalid.

[Bug libgcc/109245] aarch64 gcc defaults to -moutline-atomics but symbol ‘__aarch64_swp4_sync’ is hidden in libgcc.a

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
No feedback in almost 11 months on the command line which is failing and about
how the shared libraries were linked so closing as invalid.

[Bug tree-optimization/105134] tree-vectorize produces error code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Component|c   |tree-optimization
 Resolution|--- |INVALID

--- Comment #12 from Andrew Pinski  ---
So reading the change that was done for powerpc:
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/purgatory/arch/ppc64/Makefile?id=d40badaa2553c44d0585df335ad7e1c465f8ced1

"Some investigation revealed that gcc is generating hardware FPU instructions.
I have been told we can't use it at this point of time and as kernel"

x86_64 should use -mgeneral-regs-only or -mno-sse  for building this source.

I wonder arm64 should use -mgeneral-regs-only too.

[Bug libgcc/81199] fallback definition of count_leading_zeros references hidden symbol

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #5 from Andrew Pinski  ---
No feedback in over 6 months on the exact command line which is failing,
assuming a bug in the build system of cmake.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

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

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

Bug 110051 Summary: error: writing 1 byte into a region of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110051

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug tree-optimization/110051] error: writing 1 byte into a region of size 0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #4 from Andrew Pinski  ---
No testcase in over 6 months so closing as invalid.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #8)
> So, do we need to define those and std::unreachable (); in their bodies or
> something similar?

No, it needs to be ill-formed to call them, which is already the case as the
godbolt example in comment 0 shows:

:13:28: error: no matching function for call to 'nexttoward(const T&,
const T&)'

I think there's nothing to do here.

[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.

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

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

--- Comment #3 from Andrew Pinski  ---
The first example (of assembly here) in comment #0 is extra moves due to the RA
not handling subreg that decent for the load/store lane. There are other bug
reports dealing with that. Why the SSA_NAMES being monotonically help is just
by an accident really. 



Also:
> This mostly affects all the bitmaps that use SSA_NAME_VERSION as a key.

Most use sparse bitmaps there so it is not a big deal.

I think this should be split up in a few different bug reports really.
One for each case where better optimizations happen.

Also:
>I have seen two similar source files generating the exact same GIMPLE code up 
>to some optimization pass but then completely diverging due to different 
>freelists.

The only case where I have seen this happen is expand will have different pesdu
# really. Yes I noticed this effect while I did r14-569-g21e2ef2dc25de3 really.

[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.

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

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

--- Comment #2 from Andrew Pinski  ---
Note what I had found in the past it is not exactly SSA_NAMEs that cause the
difference but rather the RTL register pesdu # causes differences in register
allocation which was exposed from the different in operands canonicalization.

[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||53947

--- Comment #1 from Andrew Pinski  ---
>The most important case I have observed is that the vectorizer can fail or 
>create inferior code with more shuffles/moves when the SSA names aren't 
>monotonically increasing.

That should not be true.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/114009] [11/12/13/14 Regression] Missed optimization: (!a) * a => 0 when a=(a/2)*2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

What is happening is:
`(a/2)*2 == 0` gets optimized to `((unsigned)a) + 1 <= 2` and then we don't
handle:
`((unsigned)a) + 1 <= 2 ? (a/2) : 0` which is just 0. as a has the range of
[-1,1] for the truth side and divide that by 2 is always 0.

[Bug tree-optimization/114009] [11/12/13/14 Regression] Missed optimization: (!a) * a => 0 when a=(a/2)*2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
  Known to work||9.5.0
  Known to fail||10.2.0
   Severity|enhancement |normal
Summary|Missed optimization: (!a) * |[11/12/13/14 Regression]
   |a => 0 when a=(a/2)*2   |Missed optimization: (!a) *
   ||a => 0 when a=(a/2)*2

[Bug tree-optimization/114009] Missed optimization: (!a) * a => 0 when a=(a/2)*2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug c/114011] Feature request: __goto__

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

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

--- Comment #2 from Andrew Pinski  ---
Note a patch for this is one line added to the c_common_reswords array that is
defined in c-common.cc but would definitely need many testcases to test it.

[Bug c/114011] Feature request: __goto__

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
GCC has the following even:
  { "__asm",RID_ASM,0 },
  { "__asm__",  RID_ASM,0 },

  { "__const",  RID_CONST,  0 },
  { "__const__",RID_CONST,  0 },
  { "__inline", RID_INLINE, 0 },
  { "__inline__",   RID_INLINE, 0 },


  { "__restrict",   RID_RESTRICT,   0 },
  { "__restrict__", RID_RESTRICT,   0 },
  { "__signed", RID_SIGNED, 0 },
  { "__signed__",   RID_SIGNED, 0 },


So confirmed.

I also not sure why there is no __unsigned/__unsigned__ either.

[Bug c/114011] Feature request: __goto__

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug debug/111749] Kk

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
No feedback in over 5 months so closing. The bug report is blank otherwise.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #8)
> So, do we need to define those and std::unreachable (); in their bodies or
> something similar?

Though, cmath probably can't #include , so
#ifdef _GLIBCXX_DEBUG
std::__glibcxx_assert_fail(nullptr, 0, "std::nexttoward with extended
floating point type", nullptr);
#elif defined _GLIBCXX_ASSERTIONS
__builtin_trap();
#else
__builtin_unreachable();
#endif
or something similar.
Jon, I can try to write it tomorrow if you tell me what you prefer.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #8 from Jakub Jelinek  ---
So, do we need to define those and std::unreachable (); in their bodies or
something similar?

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Yeah, it is hidden at the end of the page: https://eel.is/c++draft/cmath.syn#4
https://cplusplus.github.io/LWG/issue3790

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #6 from Andrew Pinski  ---
I know cppreference is not the standard exactly but it does have the following
about nexttoward:
However, an invocation of std::nexttoward is ill-formed if the argument
corresponding to from has extended floating-point type

https://en.cppreference.com/w/cpp/numeric/math/nextafter


So maybe this is invalid after all.

[Bug c++/89224] [11/12/13/14 Regression] subscript of const vector has the wrong type

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #14)
> Causes a few regressions though:
> FAIL: g++.dg/cpp0x/constexpr-53094-1.C  -std=c++14 (internal compiler error:
> in cxx_eval_array_reference, at cp/constexpr.cc:4458)

But the fix is simple, instead of just comparing the type itself, need to
compare TYPE_MAIN_VARIANT of those types.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #5 from Jakub Jelinek  ---
If you want a function with 2 arguments of the same type, that is
std::nextafter.
In C, nexttoward{f,,l} has first argument of float, double and long double, so
the last one is always long double.
Now, https://eel.is/c++draft/cmath.syn lists
constexpr floating-point-type nextafter(floating-point-type x,
floating-point-type y);
constexpr float nextafterf(float x, float y);
constexpr long double nextafterl(long double x, long double y);
which is correct and
constexpr floating-point-type nexttoward(floating-point-type x, long double y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
which I believe is a bug in the standard, finding next representable number in
direction of long double which might have smaller or uncomparable precision or
range doesn't make much sense.
See
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602667.html
for more details.  At that point it was
constexpr floating-point-type nexttoward(floating-point-type x,
floating-point-type y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
which was also backwards incompatible change because before the C++23 changes
it was
constexpr double nexttoward(double x, long double y);
constexpr float nexttoward(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
What is in the standard now looks wrong to me as well, e.g. if long double is
IBM extended format and floating-point-type is std::float128_t, C++23 doesn't
even allow comparison between those two types:
error: invalid operands to binary > (have ‘_Float128’ and ‘long double’)
4 |   return x > y;
  |  ~~^~~
and very difficult to implement, both because of that because having to handle
all possible long double representations vs. all extended floating point types.
As Joseph said in the above thread, C23 has
_FloatN nextafterfN(_FloatN x, _FloatN y);
_FloatNx nextafterfNx(_FloatNx x, _FloatNx y);
_FloatN nextupfN(_FloatN x);
_FloatNx nextupfNx(_FloatNx x);
_FloatN nextdownfN(_FloatN x);
_FloatNx nextdownfNx(_FloatNx x);
but nexttoward remains double, float and long double only.
Because nexttoward is only meaningful if long double is a superset of the other
floating point type, which is the case for float/double.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #4 from Joseph S. Myers  ---
I don't know what's expected for C++, but for C, TS 18661-3 and C23 don't have
versions of nexttoward for _FloatN or _FloatNx (recall that the second argument
of nexttoward has type long double independent of the first argument, which is
using long double as a common superset type for all the standard floating types
- but no such common superset type is guaranteed to exist for all the _FloatN
and _FloatNx types, and long double certainly need not be such a type, so
nexttoward doesn't make sense for _FloatN or _FloatNx). Instead, those types
have nextafter, nextup and nextdown functions.

[Bug c++/89224] [11/12/13/14 Regression] subscript of const vector has the wrong type

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

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

--- Comment #14 from Andrew Pinski  ---
Causes a few regressions though:
FAIL: g++.dg/cpp0x/constexpr-53094-1.C  -std=c++14 (internal compiler error: in
cxx_eval_array_reference, at cp/constexpr.cc:4458)

[Bug modula2/114026] incorrect location during for loop type check

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-02-20

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug modula2/114026] New: incorrect location during for loop type check

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

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

Bug ID: 114026
   Summary: incorrect location during for loop type check
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

If a for loop has a type expression incompatibility it uses an incorrect
location (0).  For example:

$ cat forloop.mod
MODULE forloop ;


PROCEDURE init ;
VAR
   i: INTEGER ;
   c: CARDINAL ;
BEGIN
   c := 10 ;
   FOR i := 0 TO c DO   (* INTEGER CARDINAL expression incompatible.  *)
   END
END init ;


BEGIN
   init
END forloop.

$ gm2 forloop.mod 
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.1/m2/m2pim/Indexing.mod: In
function ‘init’:
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.1/m2/m2pim/Indexing.mod:346:1:
error: In procedure ‘init’: type incompatibility between ‘INTEGER’ and
‘CARDINAL’

[Bug tree-optimization/114025] New: Seeming missing frange based optimizations

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

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

Bug ID: 114025
   Summary: Seeming missing frange based optimizations
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
#include 
#include 

#if 1
#define AINLINE
#else
#define AINLINE [[gnu::always_inline]] inline
#endif

class TestClass
{
public:
AINLINE void SetValue(float value);

private:
float m_Value;
};

AINLINE
void TestClass::SetValue(float value)
{
if (value >= 0.0f && value <= 100.0f) {
m_Value = value;
}
else {
throw std::out_of_range("Value must be [0, 100].");
}
}

void TestFunc(TestClass& t, float value)
{
value = std::clamp(value, 30.0f, 50.0f);
// When TestClass::SetValue is inlined, the exception throwing code is not
eliminated.
// Given that at this point we can prove that 'value' lies in the range
[30.0f, 50.0f] well within the range required by the setter function, we can
rid the not taken paths of code.
t.SetValue(value);
}


```

at `-O3 -ffinite-math-only` when AINLINE is declared as nothing, TestFunc is
not always to just the clamp, but if we define it to be `inline` with
always_inline, then it is optimized to clamp. as far as I can tell the IR in
VRP1 is not able to handle correctly put the frange in for some of the SSA_NAME
and so `value >= 0.0f && value <= 100.0f` is not optimized away.

[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #1 from Steve Kargl  ---
On Tue, Feb 20, 2024 at 09:42:21PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
> 
> allocate (xx, source = cmp%re)
> 
> 
>  gfcx -c 0093/0093_0130.f90
> 0093/0093_0130.f90:10:36:
> 
>10 |  allocate (xx, source = cmp(1:3)%re)
>   |1

Whoops. Wrong backtrace.  Nonetheless, I  still has an
issue with cmp%re.  Note, inserting parentheses allows
the code to compile, i.e, 'source = (cmp%re))'.

[Bug fortran/114024] New: ICE allocate statement with source=cmp%re and z an array

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

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

Bug ID: 114024
   Summary: ICE allocate statement with source=cmp%re and z an
array
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Found with the Fujitsu testsuite.
The complex part%ref is a rank-1 array with dimension=3.
xx should be allocated and assigned [3.45,3.45, 3.45]

!
! https://github.com/fujitsu/compiler-test-suite
! Modified from Fortran/0093/0093_0130.f90
!
implicit none
complex:: cmp(3)
real, allocatable::xx(:)
cmp = (3.45,6.78)

allocate (xx, source = cmp%re)

end

 gfcx -c 0093/0093_0130.f90
0093/0093_0130.f90:10:36:

   10 |  allocate (xx, source = cmp(1:3)%re)
  |1
internal compiler error: in retrieve_last_ref, at fortran/trans-array.cc:6197
0x6e889a retrieve_last_ref(gfc_ref**, gfc_ref**)
../../gccx/gcc/fortran/trans-array.cc:6197
0xa34c20 gfc_array_allocate(gfc_se*, gfc_expr*, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, gfc_expr*, tree_node*, bool,
gfc_omp_namelist*)
../../gccx/gcc/fortran/trans-array.cc:6290
0xacce0b gfc_trans_allocate(gfc_code*, gfc_omp_namelist*)
../../gccx/gcc/fortran/trans-stmt.cc:6850
0xa25b49 trans_code
../../gccx/gcc/fortran/trans.cc:2535
0xa5ca15 gfc_generate_function_code(gfc_namespace*)
../../gccx/gcc/fortran/trans-decl.cc:7875
0x9cc496 translate_all_program_units
../../gccx/gcc/fortran/parse.cc:7073
0x9cc496 gfc_parse_file()

[Bug c++/89224] [11/12/13/14 Regression] subscript of const vector has the wrong type

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Ok, I have a simple fix:
```
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index e15eff698df..9d0e1ae574d 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -8949,9 +8949,10 @@ convert_vector_to_array_for_subscript (location_t loc,
  to not run into the gimplifiers premature setting of
DECL_GIMPLE_REG_P
 for function parameters.  */
   c_common_mark_addressable_vec (*vecp);
+  tree newinnertype = build_qualified_type (TREE_TYPE (type), TYPE_QUALS
(type));

   *vecp = build1 (VIEW_CONVERT_EXPR,
- build_array_type_nelts (TREE_TYPE (type),
+ build_array_type_nelts (newinnertype,
  TYPE_VECTOR_SUBPARTS (type)),
  *vecp);
 }
```

[Bug fortran/114023] New: complex part%ref of complex named constant array cannot be used in an initialization expression.

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

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

Bug ID: 114023
   Summary: complex part%ref of complex named constant array
cannot be used in an initialization expression.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Found with the Fujitsu testsuite.  The original code led to
an ICE, but the modified version here compiles and executes.
It is however wrong-code as the testcase stops at STOP 1.

!
! https://github.com/fujitsu/compiler-test-suite
! Modified from Fortran/0093/0093_0025.f90
!
   complex(kind=8),  parameter :: cmp1(3) = [(1,2),(3,4),(5,6)]
   complex(kind=16), parameter :: cmp2(3) = [(1,2),(3,4),(5,6)]

   real(8)  :: rr(3) = cmp1%re
   real(8)  :: qq(3) = cmp1%im
   real(16) :: rr2(3) = cmp2%re
   real(16) :: qq2(3) = cmp2%im

   if (any(int(rr)  /= [1,3,5])) stop 1
   if (any(int(qq)  /= [2,4,6])) stop 2
   if (any(int(rr2) /= [1,3,5])) stop 3
   if (any(int(qq2) /= [2,4,6])) stop 4

end

Modifying the code to output rr shows
% gfcx -o z 0093/0093_0036.f90 && ./z
   1.2.0.

[Bug c++/89224] [11/12/13/14 Regression] subscript of const vector has the wrong type

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

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

--- Comment #12 from Andrew Pinski  ---
>-  type = build_qualified_type (TREE_TYPE (type), TYPE_QUALS (type));

That part is missing it seems.
Let me see if I can fix this.

[Bug fortran/114022] New: ICE with a complex part%ref and nested structure constructor of complex array.

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

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

Bug ID: 114022
   Summary: ICE with a complex part%ref and nested structure
constructor of complex array.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Found with the Fujitsu testsuite.  The complex part%ref in
the first if-stmt leads to an ICE.  Likely, the nested structure
constructor is not setting the value of zz correctly.

!
! https://github.com/fujitsu/compiler-test-suite
! Reduced from Fortran/0093/0093_0025.f90
!
module m1

   type ty
  complex :: cmp1(2)
   end type ty

   type tt
  type(ty) :: obj
   end type tt

   type(tt), parameter :: obj2 = tt(ty([(2,3),(3,5)]))

end module m1

   use m1, only : obj2

   real :: rr(2) = obj2%obj%cmp1%re

   if (rr(1) .ne. 2) stop 1
   if (rr(2) .ne. 3) stop 2

end

% gfcx -c 0093/0093_0025.f90
0093/0093_0025.f90:15:22:

   15 |use m1, only : obj2
  |  1
internal compiler error: Segmentation fault
0x109b292 crash_signal
../../gccx/gcc/toplev.cc:317
0x248c5f37f handle_signal
/usr/src/lib/libthr/thread/thr_sig.c:301
0x248c5e9b7 thr_sighandler
/usr/src/lib/libthr/thread/thr_sig.c:244
0xa74904 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gccx/gcc/fortran/trans-expr.cc:9634
0xa45a6d gfc_conv_array_initializer(tree_node*, gfc_expr*)
../../gccx/gcc/fortran/trans-array.cc:6546
0xa745ab gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)

[Bug fortran/114001] is_contiguous considers unlimited polymorphic dummy always as contiguous

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #1 from anlauf at gcc dot gnu.org ---
gfc_is_simply_contiguous has the following code:

  if (expr->ts.type != BT_CLASS
  && ((part_ref
   && !part_ref->u.c.component->attr.contiguous
   && part_ref->u.c.component->attr.pointer)
  || (!part_ref
  && !sym->attr.contiguous
  && (sym->attr.pointer
  || (sym->as && sym->as->type == AS_ASSUMED_RANK)
  || (sym->as && sym->as->type == AS_ASSUMED_SHAPE)
return false;

This obviously ignores the CLASS case.

[Bug fortran/114021] New: ICE with allocation of scalar pointer entity where SOURCE=f() with f() returning a pointer

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

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

Bug ID: 114021
   Summary: ICE with allocation of scalar pointer entity where
SOURCE=f() with f() returning a pointer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Note sure if this is legal Fortran, but it leads to an ICE.
Reduced testcase from Fujitsu testsuite.

!
! https://github.com/fujitsu/compiler-test-suite
! Reduced from 0077/0077_0005.f90
!
module m1
   type y
  integer, allocatable:: x1(:)
   end type

   type(y), target :: w
   integer :: c = 0

   contains

  function f()
 type(y), pointer :: f
 f => w
 c = c + 1
  end function
end

subroutine s2
   use m1
!   type(y), allocate :: x  ! This ICEs as well
   type(y), pointer :: x
   allocate(x, source = f())
end

   use m1
   call s2
   if (c /= 1) stop
end


% gfcx -o z 0077/0077_0005.f90
0077/0077_0005.f90:21:28:

   21 |allocate(x, source = f())
  |1
internal compiler error: Segmentation fault
0x109b292 crash_signal
../../gccx/gcc/toplev.cc:317
0x2470c137f handle_signal
/usr/src/lib/libthr/thread/thr_sig.c:301
0x2470c09b7 thr_sighandler
/usr/src/lib/libthr/thread/thr_sig.c:244
0xacea7d tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gccx/gcc/tree.h:3611
0xacea7d gfc_trans_allocate(gfc_code*, gfc_omp_namelist*)
../../gccx/gcc/fortran/trans-stmt.cc:6672

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug fortran/114020] New: ENTRY and procedure pointer leads to ICE

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

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

Bug ID: 114020
   Summary: ENTRY and procedure pointer leads to ICE
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Found with the Fujitsu testsuite.  Reduced testcase.
Note, if the use of ENTRY is replace with an actual 
function, ie., 'function kmr_fixfun() result(zz)" the
code compiles and executes correctly.

!
! https://github.com/fujitsu/compiler-test-suite
! Reduced from Fortran/0071/0071_0018.f90
!
module xxxf

   contains

   subroutine sub
   end subroutine

   function kmr_fixfun2() result(zz)
  entry kmr_fixfun() result(zz)
  procedure(sub), pointer :: zz
  zz => null()
   end function 

   integer function foo() result(zz)
  procedure(sub), pointer :: fp
  fp => kmr_fixfun()
  zz = 0
end function foo

end module xxxf

   use xxxf
   if (foo() /= 0) stop
end

% gfcx -o z 0071/0071_0018.f90
0071/0071_0018.f90:8:3:

8 |function kmr_fixfun2() result(zz)
  |   ^
internal compiler error: in fold_convert_loc, at fold-const.cc:2633
0x741511 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gccx/gcc/fold-const.cc:2633
0xd650c9 gimplify_modify_expr
../../gccx/gcc/gimplify.cc:6356
0xd4e52c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)

[Bug fortran/114019] New: allocation with source of deferred character length entity

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

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

Bug ID: 114019
   Summary: allocation with source of deferred character length
entity
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Found this issues with the Fujitsu testsuite.  The code 
is reduced to the minimum required.  If I had to guess,
gfc_charlen for source= is not set correctly.

!
! https://github.com/fujitsu/compiler-test-suite
! Reduced from Fortran/0069/0069_0037.f90
!
  implicit none
  character(:), pointer :: chr_pointer00
  character(5), pointer :: chr_pointer01
  character(1) :: w_character01 = "4"
  allocate(chr_pointer00, source="123"//w_character01//"56")
  allocate(chr_pointer01, source="123"//w_character01//"5")
  print *,'pass'
end

% gfcx -c 0069/0069_0037.f90
0069/0069_0037.f90:9:60:

9 |   allocate(chr_pointer00, source="123"//w_character01//"56")
  |^
Error: size of variable 'source.2' is too large
0069/0069_0037.f90:10:59:

   10 |   allocate(chr_pointer01, source="123"//w_character01//"5")
  |   ^
Error: size of variable 'source.5' is too large
during RTL pass: expand
0069/0069_0037.f90:9:60:

9 |   allocate(chr_pointer00, source="123"//w_character01//"56")
  |^
internal compiler error: in lhd_incomplete_type_error, at langhooks.cc:208
0x77ff6f lhd_incomplete_type_error(unsigned int, tree_node const*, tree_node
const
../../gccx/gcc/langhooks.cc:208
0x13c00aa size_in_bytes_loc(unsigned int, tree_node const*)
../../gccx/gcc/tree.cc:3601
0x13c00aa size_in_bytes_loc(unsigned int, tree_node const*)
../../gccx/gcc/tree.cc:3589

[Bug fortran/114012] overloaded unary operator called twice

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Ever confirmed|0   |1
   Last reconfirmed||2024-02-20
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
The dump-tree shows for the assignment i = -i :

  {
struct __class__STAR_t val.7;

val.7._data = (void *) neg ()._data;
val.7._vptr = (struct __vtype__STAR * {ref-all}) neg ()._vptr;
val.7._len = 0;
i = {CLOBBER};
assign (, );
  }

We should evaluate neg () only once.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
I don't think that's right, we don't have any std::nexttoward for those types
at all, irrespective of what glibc has. IIRC this was noted as missing when
Jakub implemented the types.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #2 from Andrew Pinski  ---
So if godbolt uses an older version of glibc for x86_64 then report it to them
not us.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #1 from Andrew Pinski  ---
This depends on the version of glibc to include the c version of these
functions.  So this is most likely just an artifact of not having a new enough
glibc.

[Bug fortran/105658] Passing array component to unlimited polymorphic routine passes wrong slice

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-02-20
 Status|UNCONFIRMED |NEW

--- Comment #2 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14 so far.

[Bug target/112103] [14 regression] gcc.target/powerpc/rlwinm-0.c fails after r14-4941-gd1bb9569d70304

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

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

Peter Bergner  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=114004
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Peter Bergner  ---
Fixed.


(In reply to Peter Bergner from comment #5)
> We still want to remove the superfluous instruction, but that should be
> covered in a separate bug.

The fixing of the superfluous insn is being tracked in PR114004.

[Bug fortran/105658] Passing array component to unlimited polymorphic routine passes wrong slice

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2

commit r14-9086-g14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2
Author: Peter Hill 
Date:   Tue Feb 20 20:42:53 2024 +0100

Fortran: fix passing array component ref to polymorphic procedures

PR fortran/105658

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_intrinsic_to_class): When passing an
array component reference of intrinsic type to a procedure
with an unlimited polymorphic dummy argument, a temporary
should be created.

gcc/testsuite/ChangeLog:

* gfortran.dg/PR105658.f90: New test.

Signed-off-by: Peter Hill 

[Bug target/112103] [14 regression] gcc.target/powerpc/rlwinm-0.c fails after r14-4941-gd1bb9569d70304

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Peter Bergner :

https://gcc.gnu.org/g:81e5f276c59897077ffe38202849c93e9c580c41

commit r14-9085-g81e5f276c59897077ffe38202849c93e9c580c41
Author: Peter Bergner 
Date:   Tue Feb 20 13:44:43 2024 -0600

rs6000: Update instruction counts due to combine changes [PR112103]

The PR91865 combine fix changed instruction counts slightly for rlwinm-0.c.
Adjust expected instruction counts accordingly.

2024-02-20  Peter Bergner  

gcc/testsuite/
PR target/112103
* gcc.target/powerpc/rlwinm-0.c: Adjust expected instruction
counts.

[Bug libstdc++/114018] New: std::nexttoward is not implemented for C++23-FP-Types

[g.peterhoff--- via Gcc-bugs]

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

Bug ID: 114018
   Summary: std::nexttoward is not implemented for C++23-FP-Types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g.peterh...@t-online.de
  Target Milestone: ---

please see https://godbolt.org/z/EoKnEE8eT

thx
Gero

[Bug target/114017] New: RISC-V: wrong __riscv_v_intrinsic predefined macro value (14.x)

[maksim.shabunin at gmail dot com via Gcc-bugs]

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

Bug ID: 114017
   Summary: RISC-V: wrong __riscv_v_intrinsic predefined macro
value (14.x)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maksim.shabunin at gmail dot com
  Target Milestone: ---

Recent master branch version defines wrong RVV intrinsics version macro.

### GCC version and predefined value

./riscv-gcc-master/bin/riscv64-unknown-linux-gnu-g++ --version  
riscv64-unknown-linux-gnu-g++ (g61ab046a327) 14.0.1 20240220 (experimental)

./riscv-gcc-master/bin/riscv64-unknown-linux-gnu-g++ -dM -E -march=rv64gcv - <
/dev/null | grep riscv_v_intrin
#define __riscv_v_intrinsic 11000


### Description

Predefined value must be at least v0.12 (12000) because this is what is
actually supported by the compiler. Following snippet demonstrates the problem
by calling intrinsic which has been modified in v0.12. Without workaround the
first block will be used and will fail to compile because actual builtin
intrinsic requires `vxrm` argument.


### Example of code

#include 

int main()
{

vuint16m1_t val;
size_t shift = 1;
size_t vl = 8;
vuint8mf2_t res;

#define GCC_WORKAROUND (__GNUC__ == 14 && __riscv_v_intrinsic==11000)

#if __riscv_v_intrinsic==11000 && !GCC_WORKAROUND
#warning "RVV Intrinsics v0.11"
res = __riscv_vnclipu(val, shift, vl);
#endif

#if __riscv_v_intrinsic==12000 || GCC_WORKAROUND
#warning "RVV Intrinsics v0.12"
const unsigned int vxrm = 0;
res = __riscv_vnclipu(val, shift, vxrm, vl);
#endif

return 0;
}


### Error shown without workaround

rvv_snippet.cpp:16:26: error: no matching function for call to
'__riscv_vnclipu(vuint16m1_t&, size_t&, size_t&)'
   16 | res = __riscv_vnclipu(val, shift, vl);
  |   ~~~^~~~
In file included from rvv_snippet.cpp:1:
/work/chains/riscv-gcc-master/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/include/riscv_vector.h:43:25:
note: candidate: 'vuint8mf8_t __riscv_vnclipu(vuint16mf4_t, vuint8mf8_t,
unsigned int, long unsigned int)'
   43 | #pragma riscv intrinsic "vector"
  | ^~~~
/work/chains/riscv-gcc-master/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/include/riscv_vector.h:43:25:
note:   candidate expects 4 arguments, 3 provided
<...long list of candidates...>

[Bug target/114016] New: ICE: in AT_unsigned, at dwarf2out.cc:4592 with -march=armv9-a -gbtf or -gctf

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114016
   Summary: ICE: in AT_unsigned, at dwarf2out.cc:4592 with
-march=armv9-a -gbtf or -gctf
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 57473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57473=edit
reduced testcase

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -march=armv9-a -gbtf testcase.c 
testcase.c:2:1: internal compiler error: in AT_unsigned, at dwarf2out.cc:4592
2 | void fn_f64x4(svfloat64x4_t) {}
  | ^~~~
0x7a2627 AT_unsigned(dw_attr_struct*)
/repo/gcc-trunk/gcc/dwarf2out.cc:4592
0x7a433d AT_unsigned(dw_attr_struct*)
/repo/gcc-trunk/gcc/dwarf2out.cc:4591
0xe43aee ctf_die_bitsize
/repo/gcc-trunk/gcc/dwarf2ctf.cc:211
0xe4463e gen_ctf_sou_type
/repo/gcc-trunk/gcc/dwarf2ctf.cc:526
0xe43f07 gen_ctf_type
/repo/gcc-trunk/gcc/dwarf2ctf.cc:892
0xe43cc7 gen_ctf_function_type
/repo/gcc-trunk/gcc/dwarf2ctf.cc:718
0xe44b53 gen_ctf_function
/repo/gcc-trunk/gcc/dwarf2ctf.cc:853
0xe44b53 ctf_do_die(die_struct*)
/repo/gcc-trunk/gcc/dwarf2ctf.cc:974
0xe99183 ctf_debug_do_cu
/repo/gcc-trunk/gcc/dwarf2out.cc:33018
0xe99183 ctf_debug_do_cu
/repo/gcc-trunk/gcc/dwarf2out.cc:33011
0xe99183 dwarf2out_early_finish
/repo/gcc-trunk/gcc/dwarf2out.cc:33147
0xdf680f symbol_table::finalize_compilation_unit()
/repo/gcc-trunk/gcc/cgraphunit.cc:2580
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9077-20240220001758-g52490278466-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9077-20240220001758-g52490278466-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240220 (experimental) (GCC)

[Bug target/112922] [14 Regression] 465.tonto from SPECFP 2006 fails train run on Aarch64-linux with -O2 and -flto

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

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

--- Comment #2 from Richard Sandiford  ---
I don't remember there being a deliberate bug fix in that patch,
but there were some others later.  I suppose the optimistic case
is that this first went latent and then was fixed “properly”
afterwards.  But it could just be latent.

[Bug debug/114015] New: ICE: in build_abbrev_table, at dwarf2out.cc:9266 with -g -fvar-tracking-assignments -fdebug-types-section

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114015
   Summary: ICE: in build_abbrev_table, at dwarf2out.cc:9266 with
-g -fvar-tracking-assignments -fdebug-types-section
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57472=edit
reduced testcase (from gcc.dg/pr99122-3.c)

Compiler output:
$ x86_64-pc-linux-gnu-gcc -g -fvar-tracking-assignments -fdebug-types-section
testcase.c -w
testcase.c:1:35: internal compiler error: in build_abbrev_table, at
dwarf2out.cc:9266
1 | int barfoo(_BitInt(236) n, struct {char a[n];}) {}
  |   ^
0x7463b2 build_abbrev_table
/repo/gcc-trunk/gcc/dwarf2out.cc:9266
0x1046418 build_abbrev_table
/repo/gcc-trunk/gcc/dwarf2out.cc:9323
0x1046418 build_abbrev_table
/repo/gcc-trunk/gcc/dwarf2out.cc:9323
0x1046871 output_comdat_type_unit
/repo/gcc-trunk/gcc/dwarf2out.cc:11473
0x1070e1a dwarf2out_finish
/repo/gcc-trunk/gcc/dwarf2out.cc:32565
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9077-20240220001758-g52490278466-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9077-20240220001758-g52490278466-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240220 (experimental) (GCC)

[Bug libcc1/113977] debug info for alignment of structure is unspecified

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Resolution|MOVED   |---
   Last reconfirmed||2024-02-20
 Status|RESOLVED|NEW

--- Comment #10 from Andrew Pinski  ---
Confirmed for the libcc1 part that needs to be improved.

[Bug libcc1/113977] debug info for alignment of structure is unspecified

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

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

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #9 from Tom Tromey  ---
I think this should be reopened -- some of the fix has
to happen in libcc1.

When this code was written, there was no way to find
the alignment in DWARF.  That's since been fixed but
the protocol wasn't updated.  There are some comments
about this, see libcc1/libcc1plugin.cc:

  // FIXME there's no way to get this from DWARF,
  // or even, it seems, a particularly good way to deduce it.
  SET_TYPE_ALIGN (record_or_union_type,
  TYPE_PRECISION (pointer_sized_int_node));

[Bug debug/114014] New: ICE: 'verify_type' failed: 'TYPE_CANONICAL' is not compatible with -gbtf or -gctf on gcc.dg/gnu23-tag-1.c

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114014
   Summary: ICE: 'verify_type' failed: 'TYPE_CANONICAL' is not
compatible with -gbtf or -gctf on gcc.dg/gnu23-tag-1.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57471=edit
reduced, valid testcase (from gcc.dg/gnu23-tag-1.c)

Compiler output:
$ x86_64-pc-linux-gnu-gcc -std=gnu23 testcase.c -gbtf
testcase.c:8:1: error: 'TYPE_CANONICAL' is not compatible
8 | };
  | ^
 >
testcase.c:8:1: internal compiler error: 'verify_type' failed
0x185477e verify_type(tree_node const*)
/repo/gcc-trunk/gcc/tree.cc:14394
0x1053f24 gen_type_die_with_usage
/repo/gcc-trunk/gcc/dwarf2out.cc:26266
0x1050c38 gen_type_die
/repo/gcc-trunk/gcc/dwarf2out.cc:26497
0x1050c38 gen_decl_die
/repo/gcc-trunk/gcc/dwarf2out.cc:27137
0x1051f6b dwarf2out_decl
/repo/gcc-trunk/gcc/dwarf2out.cc:27695
0x10521c8 dwarf2out_type_decl
/repo/gcc-trunk/gcc/dwarf2out.cc:27413
0x10521c8 dwarf2out_type_decl
/repo/gcc-trunk/gcc/dwarf2out.cc:27408
0x13d07c4 rest_of_type_compilation(tree_node*, int)
/repo/gcc-trunk/gcc/passes.cc:339
0xe0e7e2 finish_struct(unsigned int, tree_node*, tree_node*, tree_node*,
c_struct_parse_info*, tree_node**)
/repo/gcc-trunk/gcc/c/c-decl.cc:9733
0xe6919d c_parser_struct_or_union_specifier
/repo/gcc-trunk/gcc/c/c-parser.cc:4090
0xe6919d c_parser_declspecs(c_parser*, c_declspecs*, bool, bool, bool, bool,
bool, bool, bool, c_lookahead_kind)
/repo/gcc-trunk/gcc/c/c-parser.cc:3494
0xe7871c c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.cc:2306
0xe848eb c_parser_external_declaration
/repo/gcc-trunk/gcc/c/c-parser.cc:2046
0xe852d5 c_parser_translation_unit
/repo/gcc-trunk/gcc/c/c-parser.cc:1900
0xe852d5 c_parse_file()
/repo/gcc-trunk/gcc/c/c-parser.cc:26816
0xefcaf1 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1311
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -std=gnu23 testcase.c -gctf
testcase.c:8:1: error: 'TYPE_CANONICAL' is not compatible
8 | };
  | ^
 

[Bug c++/114013] [14 Regression] Specializations of var templates no longer emitted since r14-8987

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

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

--- Comment #2 from Jakub Jelinek  ---
And it behaves the same way even if there is
template 
constexpr inline struct S var[8] = {};
instead.

[Bug c++/114013] [14 Regression] Specializations of var templates no longer emitted since r14-8987

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

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

--- Comment #1 from Jakub Jelinek  ---
s/16/8/, sorry for the leftover from earlier larger version.

[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to Sebastian "spaetz" Spaeth from comment #5)
> > I fully understand that nobody wants to invest time into fixing this. What
> > would be nice though, is if this were really just a missed optimization and
> > not rejecting to compile valid code.
> > 
> > powerpc could ignore the constexpr in this case, rather than failing to
> > build?
> 
> It will be an violation of the standard (at least in some cases).

Yeah, the suggestion doesn't really make sense in general. If you don't care
whether the initialization is constexpr ... don't use constexpr. It's not about
optimization, it's about guaranteeing compile-time calculations.

I suppose it might be possible to implicitly change the variable to const
instead of constexpr, which would then give errors if you tried to use that in
any constant expressions. I would guess that won't help much real code, because
if you didn't want to use it in constant expressions, you wouldn't usually
declare it constexpr anyway.

In the specific case of
https://github.com/google/s2geometry/blob/2ff824474f0c4dfb157a0d056e4a6bb76bfa690f/src/s2/s2edge_crossings.cc#L115
it would compile, because constexpr apparently is being used as an
optimization, it doesn't need to be done at compile time.

But again, somebody needs to spend time to do that work. The people who require
this to work on their hardware should be the ones to do (or fund) the work on
it. The people unaffected by it probably aren't going to do anything about it.

It might be simpler to implement a "this is powerpc double double and we know
we can't do some arithmetic at compile time so treat this is const not
constexpr and see if that allows us to continue" feature than to implement full
compile-time arithmetic for double double.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #32 from Jonathan Wakely  ---
[basic.stc.general] says global ==  is implementation-defined if global is an
invalid pointer value, not just unspecified. GCC could define it to be
unspecified, or UB, and even say "it's UB just in this one case where the
address was a temporary created under the permission granted by
[class.temporary] p3" (although I don't think we do define it that way, we just
compare the bits).

[Bug c++/114013] [14 Regression] Specializations of var templates no longer emitted since r14-8987

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-02-20
   Target Milestone|--- |14.0
   Priority|P3  |P1
 CC||jason at gcc dot gnu.org,
   ||nshead at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug c++/114013] New: [14 Regression] Specializations of var templates no longer emitted since r14-8987

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

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

Bug ID: 114013
   Summary: [14 Regression] Specializations of var templates no
longer emitted since r14-8987
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

struct S { int a, b; };

template 
constexpr struct S var[16] = {};

template <>
constexpr inline struct S var<6>[8] = {
  { 1, 1 }, { 2, 0 }, { 3, 1 }, { 4, 0 },
  { 5, 1 }, { 6, 0 }, { 7, 1 }, { 8, 0 }
};

[[gnu::noipa]] void
foo (S)
{
}

template 
void
bar (int x)
{
  foo (var[x]);
}

volatile int x;

int
main ()
{
  bar <6> (x);
}

extracted from mesa no longer links starting with
r14-8987-gdd9d14f7d53de07beff06004922a2bff20ece671 (-O0 or -O2, doesn't
matter).
/usr/bin/ld: /tmp/cc4Mqq20.o: in function `void bar<6>(int)':
mesa.C:(.text._Z3barILi6EEvi[_Z3barILi6EEvi]+0x14): undefined reference to
`var<6>'
collect2: error: ld returned 1 exit status

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from Jakub Jelinek  ---
> Or convince Oracle to change it (again, an ABI break).

I can try, but don't hold your breath.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Jonathan Wakely  ---
> It's technically an ABI break, since void f(int8_t) would mangle differently.
> It probably wouldn't affect much in practice, but would still be a break.

Still, given how serious Sun/Oracle is about ABI compatibility (and
always has been), I'm doubtful they would be amenable to the idea.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Jonathan Wakely  ---
> (In reply to Jonathan Wakely from comment #1)
>> I assume that int8_t is char on Solaris, rather than signed char?
>
> This actually violates the C and C++ standards, which require that intN_t is a
> signed integer type, and C 6.2.5 says "There are five standard signed integer
> types, designated as signed char, short int, int, long int, and long long 
> int."
> So char isn't allowed, it should be signed char.

I've done some digging now: / were
introduced into Solaris 2.6 (the file dates from Jul 16 1997), way
before the C99 standard was finalized.

I've looked around the WG14 archive, and some drafts after that date
(N737 (1997-06-26), N788 (1997-11-17), N851 (1998-09-22)) do have the
`signed integer type' wording.  Unfortunately, all of the previous ones
(which would have been the basis of the Solaris implementation) are no
longer available.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #31 from Arthur O'Dwyer  ---
Oops, I guess my reading did disagree with jwakely's in one small point:
jwakely writes--
> But since one of the pointers is an invalid pointer,
> you can't do anything with its value anyway, including
> comparing it to 

In my interpretation, it was fine to compare `global == `; but the boolean
value of that comparison would be unspecified (because `*global` was
out-of-lifetime), and even if it *did* happen to come out to `true`, it would
still be UB to execute `global->i = 42` (because `*global` would still be a
different object from `w`, and `*global` is out-of-lifetime). I think this
makes no difference to the ultimate conclusion, i.e. something here ends up
being UB either way.