[Bug tree-optimization/113962] [14 Regression] ICE: in exact_div, at poly-int.h:2156 with -O -mavx512f

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Most likely a dup of bug 113967

[Bug tree-optimization/113962] New: [14 Regression] ICE: in exact_div, at poly-int.h:2156 with -O -mavx512f

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

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

Bug ID: 113962
   Summary: [14 Regression] ICE: in exact_div, at poly-int.h:2156
with -O -mavx512f
   Product: gcc
   Version: 14.0
Status: WAITING
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: rguenth at gcc dot gnu.org
  Target Milestone: 14.0
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
CC: rguenth at gcc dot gnu.org
  Last reconfirmed: 2024-02-19
Status: WAITING
  Target Milestone: 14.0
Ever confirmed: 1

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx512f testcase.c 
during GIMPLE pass: forwprop
testcase.c: In function 'bar1':
testcase.c:8:6: internal compiler error: in exact_div, at poly-int.h:2156
8 | void bar1() { (v64u8){bar4(bar1_v64u16_0)[3]}; }
  |  ^~~~
0x8f3b3f poly_int<1u, poly_result::is_poly>::type,
poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<1u, unsigned long, unsigned long>(poly_int<1u, unsigned long> const&,
unsigned long)
/repo/gcc-trunk/gcc/poly-int.h:2156
0x8f3b3f poly_int<1u, poly_result::is_poly>::type,
poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<1u, unsigned long, unsigned long>(poly_int<1u, unsigned long> const&,
unsigned long)
/repo/gcc-trunk/gcc/poly-int.h:2150
0x1af5db7 gimple_simplify_BIT_INSERT_EXPR(gimple_match_op*, gimple**,
tree_node* (*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*,
tree_node*)
/repo/build-gcc-trunk-amd64/gcc/gimple-match-5.cc:16981
0x1caa515 gimple_resimplify3
/repo/gcc-trunk/gcc/gimple-match-exports.cc:1107
0x1cabaf7 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/repo/gcc-trunk/gcc/gimple-match-exports.cc:898
0x116ce2c fold_stmt_1
/repo/gcc-trunk/gcc/gimple-fold.cc:6359
0x165e28d execute
/repo/gcc-trunk/gcc/tree-ssa-forwprop.cc:3950
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 -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-9022-20240216094309-gf436a2ab6ad-checking-yes-rtl-df-extra-nobootstrap-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
--disable-bootstrap --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-9022-20240216094309-gf436a2ab6ad-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240216 (experimental) (GCC)

--- Comment #1 from Richard Biener  ---
Where's testcase.c?

[Bug target/113960] std::map with std::vector as input overwrites itself with c++20, on s390x platform

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-02-19
  Known to fail||12.3.0, 13.2.1

--- Comment #2 from Richard Biener  ---
works fine on x86_64-linux.  Confirmed on s390x-linux with

g++-13 (SUSE Linux) 13.2.1 20230912 [revision
b96e66fd4ef3e36983969fb8cdd1956f551a074b]

and

g++-12 (SUSE Linux) 12.3.0

[Bug middle-end/113959] Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to `__builtin_isfinite(x)`

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Confirmed.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

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

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Fangrui Song from comment #1)
> BTW,
> https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/
> uninitialized.cpp has many member initializer list examples

And r12-5391-g0790c8aacdfb4f added one testcase where clang produces a bogus
warning too so it goes both ways really :).

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

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

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

--- Comment #3 from Andrew Pinski  ---
Most likely started with r12-5391-g0790c8aacdfb4f .

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
  Known to fail||12.1.0
 Blocks|24639   |
  Known to work||11.1.0
Summary|Binding a reference to an   |[12/13/14 Regression]
   |uninitialized data member   |Binding a reference to an
   |should not cause|uninitialized data member
   |-Wuninitialized |should not cause
   ||-Wuninitialized

--- Comment #2 from Andrew Pinski  ---
This warning is from the front-end:
  else if (cp_tree_equal (TREE_OPERAND (init, 0), current_class_ref)
   && uninitialized->contains (field))
{
  if (TYPE_REF_P (TREE_TYPE (field)))
warning_at (EXPR_LOCATION (init), OPT_Wuninitialized,
"reference %qD is not yet bound to a value when used "
"here", field);
  else if (!INDIRECT_TYPE_P (type) || is_this_parameter (d->member))
warning_at (EXPR_LOCATION (init), OPT_Wuninitialized,
"member %qD is used uninitialized", field);
  *walk_subtrees = false;
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug target/113986] [14 regression] Build failure on aarch64-linux-musl (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I am 99% sure it was caused by r14-6589-g3fa689f6ed8387 .

It is reproducible with --disable-gnu-indirect-function on the gcc configure
line for a glibc build even without the patch for PR 113971 so confirmed. 


Moving the definition of DONE for N==16 case to be under the `#if HAVE_IFUNC`
case fixes the issue. I don't know if that is the correct fix or not ...

[Bug middle-end/113987] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[i at maskray dot me via Gcc-bugs]

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

--- Comment #1 from Fangrui Song  ---
BTW,
https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/uninitialized.cpp
has many member initializer list examples

[Bug middle-end/113987] New: Binding a reference to an uninitialized data member should not cause -Wuninitialized

[i at maskray dot me via Gcc-bugs]

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

Bug ID: 113987
   Summary: Binding a reference to an uninitialized data member
should not cause -Wuninitialized
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

https://godbolt.org/z/G7ndsTv5c (from
https://github.com/llvm/llvm-project/pull/81179#issuecomment-1937082113)

struct t1 {
t1(int);
};
struct t2 {
t2(int&, int = 0);
};
struct t3 {
t3(int&);
};
struct t4 {};
void f1(int&);
struct t {
t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
t1 v1;
t2 v2;
t3 v3;
t4 v4;
t1 v5;
int i;
int j;
};
int main() { t v1; }

GCC output
```
: In constructor 't::t()':
:13:14: warning: member 't::i' is used uninitialized [-Wuninitialized]
   13 | t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
  |  ^
:13:21: warning: member 't::i' is used uninitialized [-Wuninitialized]
   13 | t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
  | ^
:13:28: warning: member 't::i' is used uninitialized [-Wuninitialized]
   13 | t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
  |^
: In constructor 't::t()':
:13:11: warning: '*this.t::i' is used uninitialized [-Wuninitialized]
   13 | t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
  |   ^
```

Clang output
```
:13:14: warning: field 'i' is uninitialized when used here
[-Wuninitialized]
   13 | t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
  |  ^
:13:54: warning: field 'i' is uninitialized when used here
[-Wuninitialized]
   13 | t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
  |  ^
2 warnings generated.
```

Clang suppresses diagnostics when binding a reference (t2, t3) to an
uninitialized data member.


Smaller example:

  struct D {
int a;
int 
int  = a;
D() : b(a) {} // no warning ?!
D(int x) : b(a), a(x) {}  // warning
  };

[Bug target/113986] [14 regression] Build failure on aarch64-linux-musl (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |14.0

[Bug target/113986] New: [14 regression] Build failure on aarch64-linux-musl (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')

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

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

Bug ID: 113986
   Summary: [14 regression] Build failure on aarch64-linux-musl
(error: 'export_load_16' aliased to undefined symbol
'libat_load_16')
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: csfore at posteo dot net
  Target Milestone: ---

Created attachment 57458
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57458=edit
build.log.xz

This is with the patch from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971#c2 to get past that error.

Reported by Christopher Fore.
```
/bin/sh ./libtool  --tag=CC   --mode=compile
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/build/./gcc/
-B/usr/aarch64-gentoo-linux-musl/bin/ -B/usr/aarch64-gentoo-linux-musl/lib/
-isystem /usr/aarch64-gentoo-linux-musl/include -isystem
/usr/aarch64-gentoo-linux-musl/sys-include   -fchecking=1 -DHAVE_CONFIG_H
-I/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic/config/aarch64
-I/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic/config/linux/aarch64
-I/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic/config/posix
-I/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic
-I.-mno-outline-atomics -Wall   -pthread -g -pipe -O2  -DN=16  -c -o
load_16_.lo
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic/load_n.c
In file included from
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic/load_n.c:25:
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic/libatomic_i.h:288:40:
error: 'export_load_16' aliased to undefined symbol 'libat_load_16'
  288 | extern typeof(C2(libat_,X)) C2(export_,X)   \
  |^~~
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic/libatomic_i.h:40:25:
note: in definition of macro 'C2_'
   40 | #define C2_(X,Y)X ## Y
  | ^
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic/libatomic_i.h:288:37:
note: in expansion of macro 'C2'
  288 | extern typeof(C2(libat_,X)) C2(export_,X)   \
  | ^~
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libatomic/load_n.c:115:1:
note: in expansion of macro 'EXPORT_ALIAS'
  115 | EXPORT_ALIAS (SIZE(load));
  | ^~~~
make[4]: *** [Makefile:900: load_16_.lo] Error 1
make[4]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/build/aarch64-gentoo-linux-musl/libatomic'
make[3]: *** [Makefile:651: all-recursive] Error 1
```

[Bug middle-end/113985] expansion of `*struct = call();` could be improved

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Keywords||internal-improvement
 Ever confirmed|0   |1
  Component|rtl-optimization|middle-end
   Severity|normal  |enhancement
Summary|redundant copy of return|expansion of `*struct =
   |values at O0|call();` could be improved
 Resolution|INVALID |---
   Last reconfirmed||2024-02-19

--- Comment #2 from Andrew Pinski  ---
Just for reference this comes from the expansion of *b = call.

What is happening is it is loading the original variable from *b and then
ioring the new value in. This should be improved but not because of the -O0
case but rather it would be better for expansion reasons and better initial
RTL.

Not we normally don't care about -O0 code size/generation but in this case, it
just that it would help improve compile time slightly.

I have not looked fully into what produces the tmp = (a&0) just yet though.
But the initial RTL (even at -O2) is:
```
(insn 28 27 29 (set (reg:SI 112)
(mem/c:SI (reg/f:DI 110) [1 g_91D.2780+8 S4 A64]))
"/app/example.cpp":27:8 -1
 (nil))

(insn 29 28 30 (parallel [
(set (reg:SI 113)
(and:SI (reg:SI 112)
(const_int 0 [0])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":27:8 -1
 (nil))

(insn 30 29 31 (parallel [
(set (reg:SI 114)
(ior:SI (reg:SI 113)
(reg:SI 111)))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":27:8 -1
 (nil))

```

Which seems like it definitely could be improved.

[Bug rtl-optimization/113985] redundant copy of return values at O0

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
It does not make sense to disable the optimization and complain the code is not
optimized.

[Bug rtl-optimization/113985] New: redundant copy of return values at O0

[absoler at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 113985
   Summary: redundant copy of return values at O0
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: absoler at smail dot nju.edu.cn
  Target Milestone: ---

hi, I found with -O0 flag, there are redundant operations on return values of
structure type.

```
typedef signed char int8_t;
typedef unsigned char uint8_t;
typedef signed short int int16_t;
typedef unsigned short int uint16_t;
typedef signed int int32_t;
typedef unsigned int uint32_t;
typedef signed long int int64_t;
typedef unsigned long int uint64_t;

struct S0 {
   int32_t  f0;
   uint8_t  f1;
   int32_t  f2;
};

struct S0 g_91 = {0x6732C952L,0x6BL,6L};
int64_t g_205[9] =
{0L,0L,0x47DC22DBA5B9078ELL,0L,0L,0x47DC22DBA5B9078ELL,0L,0L,0x47DC22DBA5B9078ELL};

void  func_1(void);
struct S0  func_2();


void func_1() {
  struct S0 a;
  struct S0 *b = _91;
  *b = func_2(0, a, a.f1, g_205[0]);
}
struct S0 func_2() { return g_91;}
```

the disassembly:
```
00401186 :
func_1():
/root/loadtest0/test/output2.c:44
  401186:   push   %rbp
  401187:   mov%rsp,%rbp
  40118a:   sub$0x20,%rsp
/root/loadtest0/test/output2.c:46
  40118e:   movq   $0x404080,-0x8(%rbp)
/root/loadtest0/test/output2.c:47
  401196:   mov0x2f03(%rip),%rsi# 4040a0 
  40119d:   movzbl -0x10(%rbp),%eax
  4011a1:   movzbl %al,%ecx
  4011a4:   mov-0x14(%rbp),%rdx
  4011a8:   mov-0xc(%rbp),%eax
  4011ab:   mov%rsi,%r8
  4011ae:   mov%rdx,%rsi
  4011b1:   mov%eax,%edx
  4011b3:   mov$0x0,%edi
  4011b8:   mov$0x0,%eax
  4011bd:   callq  4011d7 
  4011c2:   mov-0x8(%rbp),%rcx
  4011c6:   mov%rax,(%rcx)
  4011c9:   mov0x8(%rcx),%eax // redundant
  4011cc:   and$0x0,%eax
  4011cf:   or %edx,%eax
  4011d1:   mov%eax,0x8(%rcx)
/root/loadtest0/test/output2.c:48
  4011d4:   nop
  4011d5:   leaveq 
  4011d6:   retq   
```

we can see that it's unnecessary to load `0x8(%rcx)` into %eax, because it will
be cleared in the next instruction

[Bug fortran/109358] Wrong formatting with T-descriptor during stream output

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

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

--- Comment #16 from Jerry DeLisle  ---
I think I was not being very clear when I opened pr113897. nX descriptors are
very similar to TR code and I meeantt to take care of those in the 113897.  The
reason for the separate PR is that the problem is completely different than
this one which is relates to the use of stream I/O.

The consecutive tabs or spaces require looking ahead in the format string and
effectively squashing these before writing the next actual data. This was my
plan for PR113897.

[Bug middle-end/113984] -Wfree-nonheap-object false positive with VLA parameter that has a size which is not a simple decl

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|-Wfree-nonheap-object false |-Wfree-nonheap-object false
   |positive with VLA parameter |positive with VLA parameter
   |that is a derefenced|that has a size which is
   ||not a simple decl

--- Comment #3 from Andrew Pinski  ---
Another testcase:
```
struct a
{
  int n;
};
const char **
add_string(struct a n, const char *strings[restrict n.n])
{
  strings = __builtin_realloc(strings, n.n);
  if (!strings)
return 0;
  return strings;
}
```

[Bug middle-end/113984] -Wfree-nonheap-object false positive with VLA parameter that is a derefenced

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|-Wfree-nonheap-object false |-Wfree-nonheap-object false
   |positive with VLA parameter |positive with VLA parameter
   ||that is a derefenced
   Last reconfirmed||2024-02-19

--- Comment #2 from Andrew Pinski  ---
Confirmed, reduced testcase:
```
const char **
add_string(int *restrict n, const char *strings[restrict *n])
{
  strings = __builtin_realloc(strings, *n);
  if (!strings)
return 0;
  return strings;
}
```

Note if we had `int n` instead of a pointer, then there would be no warning.

[Bug c/113984] -Wfree-nonheap-object false positive with VLA parameter

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #1 from Alejandro Colomar  ---
With -O3, the warning also vanishes, as the function is probably inlined, and
there's no VLA parameter any more.

alx@debian:~/tmp$ gcc-14 -Wall -O3 nonheap.c 
alx@debian:~/tmp$ gcc-13 -Wall -O3 nonheap.c 
alx@debian:~/tmp$

[Bug c/113984] New: -Wfree-nonheap-object false positive with VLA parameter

[alx at kernel dot org via Gcc-bugs]

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

Bug ID: 113984
   Summary: -Wfree-nonheap-object false positive with VLA
parameter
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alx at kernel dot org
  Target Milestone: ---

I can reproduce it with both of these:

$ gcc-13 --version | head -n1
gcc-13 (Debian 13.2.0-13) 13.2.0
$ gcc-14 --version | head -n1
gcc-14 (Debian 14-20240201-3) 14.0.1 20240131 (experimental) [master
r14-8680-g2f14c0dbb78]


See a small reproducer:


```c
#include 
#include 
#include 


static const char **add_string(size_t *restrict n,
const char *strings[restrict *n], const char *restrict string);


int
main(int argc, char *argv[argc + 1])
{
size_t  n = 0;
const char  **strings = NULL;

add_string(, strings, argv[0]);
}


static const char **
add_string(size_t *restrict n, const char *strings[restrict *n],
const char *restrict string)
{
strings = reallocarray(strings, ++*n, sizeof(const char *));
if (strings == NULL)
err(EXIT_FAILURE, "reallocarray(3)");

strings[*n - 1] = string;

return strings;
}
```


alx@debian:~/tmp$ gcc-13 -Wall nonheap.c 
nonheap.c: In function ‘add_string’:
nonheap.c:24:19: warning: ‘reallocarray’ called on unallocated object ‘strings’
[-Wfree-nonheap-object]
   24 | strings = reallocarray(strings, ++*n, sizeof(const char *));
  |   ^
nonheap.c:21:44: note: declared here
   21 | add_string(size_t *restrict n, const char *strings[restrict *n],
  |^~~~
alx@debian:~/tmp$ gcc-14 -Wall nonheap.c 
nonheap.c: In function ‘add_string’:
nonheap.c:24:19: warning: ‘reallocarray’ called on unallocated object ‘strings’
[-Wfree-nonheap-object]
   24 | strings = reallocarray(strings, ++*n, sizeof(const char *));
  |   ^
nonheap.c:21:44: note: declared here
   21 | add_string(size_t *restrict n, const char *strings[restrict *n],
  |^~~~


If I change the function to have the parameter be `const char **restrict
strings`, the warning vanishes.

[Bug analyzer/113983] [14 Regression] ICE: tree check: expected integer_cst, have vector_cst in maybe_undo_optimize_bit_field_compare, at analyzer/region-model-manager.cc:606 with -fanalyzer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-18
 CC||dmalcolm at gcc dot gnu.org
   Assignee|dmalcolm at gcc dot gnu.org|pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Almost definitely introduced by r14-6419-g4eaaf7f5a378e8.

Fix:
[apinski@xeond2 gcc]$ git diff
diff --git a/gcc/analyzer/region-model-manager.cc
b/gcc/analyzer/region-model-manager.cc
index 62f808a81c2..21e13b48025 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -602,6 +602,9 @@ maybe_undo_optimize_bit_field_compare (tree type,
   tree cst,
   const svalue *arg1)
 {
+  if (!INTEGRAL_TYPE_P (type))
+return NULL;
+
   const binding_map  = compound_sval->get_map ();
   unsigned HOST_WIDE_INT mask = TREE_INT_CST_LOW (cst);
   /* If "mask" is a contiguous range of set bits, see if the

[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
We pattern recognize just something like (or r < y):
add_result add_wide_3(unsigned long long x, unsigned long long y) {
auto r = x + y;
return add_result{r, r < x};
}
and not doing the addition uselessly in twice as big mode + shift + comparison
against 0.
The reason for mov edx, 0 is not to clobber flags which are live at that point,
of course one could also move the clearing of edx one insn earlier and then it
could be xor edx, edx.

[Bug analyzer/113983] [14 Regression] ICE: tree check: expected integer_cst, have vector_cst in maybe_undo_optimize_bit_field_compare, at analyzer/region-model-manager.cc:606 with -fanalyzer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
Let me look since I touched maybe_undo_optimize_bit_field_compare last.

[Bug analyzer/113983] New: [14 Regression] ICE: tree check: expected integer_cst, have vector_cst in maybe_undo_optimize_bit_field_compare, at analyzer/region-model-manager.cc:606 with -fanalyzer

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113983
   Summary: [14 Regression] ICE: tree check: expected integer_cst,
have vector_cst in
maybe_undo_optimize_bit_field_compare, at
analyzer/region-model-manager.cc:606 with -fanalyzer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm 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 57457
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57457=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer testcase.c 
during IPA pass: analyzer
testcase.c: In function 'foo':
testcase.c:8:22: internal compiler error: tree check: expected integer_cst,
have vector_cst in maybe_undo_optimize_bit_field_compare, at
analyzer/region-model-manager.cc:606
8 |   return (0, 0) * (i & v);
  |   ~~~^~~~
0x88ddd5 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/repo/gcc-trunk/gcc/tree.cc:8955

testcase.c:8:22: internal compiler error: Segmentation fault
0x151aef2 crash_signal
/repo/gcc-trunk/gcc/toplev.cc:317
0x2aec460 x86_64_fallback_frame_state
./md-unwind-support.h:63
0x2aec460 uw_frame_state_for
/repo/gcc-trunk/libgcc/unwind-dw2.c:1013
0x2aed79d _Unwind_Backtrace
/repo/gcc-trunk/libgcc/unwind.inc:303
0x2a97f89 backtrace_full
/repo/gcc-trunk/libbacktrace/backtrace.c:127
0x29ff2a6 diagnostic_context::action_after_output(diagnostic_t)
/repo/gcc-trunk/gcc/diagnostic.cc:781
0x29ff4bb diagnostic_action_after_output(diagnostic_context*, diagnostic_t)
/repo/gcc-trunk/gcc/diagnostic.h:1002
0x29ff4bb diagnostic_context::report_diagnostic(diagnostic_info*)
/repo/gcc-trunk/gcc/diagnostic.cc:1633
0x29ff838 diagnostic_impl
/repo/gcc-trunk/gcc/diagnostic.cc:1767
0x29fff06 internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic.cc:2225
0x88ddd5 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/repo/gcc-trunk/gcc/tree.cc:8955
x86_64-pc-linux-gnu-gcc: internal compiler error: Segmentation fault signal
terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  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-9043-20240217001708-gd70f155b074-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-9043-20240217001708-gd70f155b074-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240217 (experimental) (GCC)

[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions

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

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

--- Comment #2 from Andrew Pinski  ---
Note some of this is due to return register issues.

If we instead do stores:
```
add_wide_1(unsigned long long, unsigned long long, add_result*):
mov rax, rdi
lea rcx, [rdi+rsi]
xor edi, edi
add rsi, rax
mov QWORD PTR [rdx], rcx
adc rdi, 0
mov BYTE PTR [rdx+8], dil
and BYTE PTR [rdx+8], 1
ret
```

Which is better.

add_wide_2 becomes:
```
add_wide_2(unsigned long long, unsigned long long, add_result*):
add rdi, rsi
setcBYTE PTR [rdx+8]
mov QWORD PTR [rdx], rdi
and BYTE PTR [rdx+8], 1
ret
```

Which is better, the extra and is filed already though I can't seem to find it.

[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |middle-end
   Last reconfirmed||2024-02-18
   Severity|normal  |enhancement
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
aarch64 looks fine (ok there is an one extra mov):
```
add_wide_1(unsigned long long, unsigned long long):
addsx2, x0, x1
mov x0, x2
csetx1, cs
ret
add_wide_2(unsigned long long, unsigned long long):
addsx0, x0, x1
csetx1, cs
ret

```

So we have:
```
  _1 = (__int128 unsigned) x_6(D);
  _2 = (__int128 unsigned) y_7(D);
  r_8 = _1 + _2;
  _3 = x_6(D) + y_7(D);
  D.2566.sum = _3;
  _4 = r_8 >> 64;
  _5 = (bool) _4;
  D.2566.carry = _5;
```

So if we should convert _5 into:
  _t = .ADD_OVERFLOW (x_3(D), y_4(D));
  _t2 = IMAGPART_EXPR <_t>;
  _5 = (bool) _t2;

And then later on see that r_8 is REALPART_EXPR<_t>;
It would just work ...

[Bug c++/113982] New: Poor codegen for 64-bit add with carry widening functions

[janschultke at googlemail dot com via Gcc-bugs]

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

Bug ID: 113982
   Summary: Poor codegen for 64-bit add with carry widening
functions
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janschultke at googlemail dot com
  Target Milestone: ---

I was trying to get optimal codegen for a 64-bit addition with a carry, but
it's tough to do with GCC:

> struct add_result {
> unsigned long long sum;
> bool carry;
> };
> 
> add_result add_wide_1(unsigned long long x, unsigned long long y) {
> auto r = (unsigned __int128) x + y;
> return add_result{static_cast(r), bool(r >> 64)};
> }
> 
> add_result add_wide_2(unsigned long long x, unsigned long long y) {
> unsigned long long r;
> bool carry = __builtin_add_overflow(x, y, );
> return add_result{r, carry};
> }


## Expected output (clang -march=x86-64-v4 -O3)

add_wide_1(unsigned long long, unsigned long long):
mov rax, rdi
add rax, rsi
setbdl
ret
add_wide_2(unsigned long long, unsigned long long):
mov rax, rdi
add rax, rsi
setbdl
ret

## Actual output (GCC -march=x86-64-v4 -O3) (https://godbolt.org/z/qGc9WeEvK)

add_wide_1(unsigned long long, unsigned long long):
mov rcx, rdi
lea rax, [rdi+rsi]
xor edx, edx
xor edi, edi
add rsi, rcx
adc rdi, 0
mov dl, dil
and dl, 1
ret
add_wide_2(unsigned long long, unsigned long long):
add rdi, rsi
mov edx, 0
mov rax, rdi
setcdl
ret


The output for the 128-bit version looks pretty bad.
It looks like GCC isn't aware that we only access the carry bit, so it doesn't
need to do full 128-bit arithmetic so to speak.

The add_wide_2 output also isn't optimal. Why would it output "mov edx, 0"
instead of "xor edx, edx"?

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
That sounds like a FE bug to me, rather than middle-end.

[Bug c++/86761] Code corruption with missing pointer return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Simon.Richter at hogyros dot de

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

[Bug target/113981] risc-v: non-void C++ function with no return statement has no ret

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>but also does not emit a "ret" instruction.

Because it is undefined in C++ to return from a fuction without a value.

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

[Bug target/113980] risc-v: unnecessary sign-extend after lw with volatile, and more

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

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

--- Comment #1 from Andrew Pinski  ---
Basically GCC does not optimize around a volatile memory load/stores which
causes artifacts like this.

[Bug target/113981] New: risc-v: non-void C++ function with no return statement has no ret

[Simon.Richter at hogyros dot de via Gcc-bugs]

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

Bug ID: 113981
   Summary: risc-v: non-void C++ function with no return statement
has no ret
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Simon.Richter at hogyros dot de
  Target Milestone: ---

On RISC-V with -O3, the C++ program

int f() {}

emits a completely empty function.

It correctly warns about the missing return statement, but also does not emit a
"ret" instruction.

[Bug target/113980] New: risc-v: unnecessary sign-extend after lw, and more

[Simon.Richter at hogyros dot de via Gcc-bugs]

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

Bug ID: 113980
   Summary: risc-v: unnecessary sign-extend after lw, and more
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Simon.Richter at hogyros dot de
  Target Milestone: ---

On RISC-V with -O3,

#include 

extern uint32_t volatile d;
extern uint8_t volatile o;

void f()
{
uint32_t t;
while((t = d) & 0x8000)
;
o = t;
}

generates

f:
lui a3,%hi(d)
.L2:
lw  a5,%lo(d)(a3)
sext.w  a4,a5
blt a5,zero,.L2
andia4,a4,0xff
lui a5,%hi(o)
sb  a4,%lo(o)(a5)
ret

The result of the lw instruction is already sign-extended, so the sext.w
instruction is unnecessary in any case. It is extra unnecessary when the value
is subsequently truncated with an and instruction, which itself is unnecessary
for a sb instruction.

To keep this bug report focused, I'd limit the problem description to the
sign-extend -- if the others warrant opening extra bug reports, I can do that
as well.

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jeffrey A. Law from comment #3)
> What does the standard say about changing const objects?

It says it is undefined. Note there is no changing const object in this code;
just the const variable is dynamically initialized which is 100% defined.

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

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

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

--- Comment #3 from Jeffrey A. Law  ---
What does the standard say about changing const objects?

[Bug target/113971] [14 Regression] failure to build on arm64 musl (#error "Unsupported AArch64 platform for heap trampolines")

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-02-18

--- Comment #2 from Iain Sandoe  ---
Created attachment 57456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57456=edit
patch to allow heap trampolines for all aarch64-linux

This has been tested so far on aarch64-linux-gnu and aarch64-darwin; I do not
have access to an aarch64-linux-muscl system to check that.

[Bug target/113912] push2/pop2 generated when stack isn't aligned to 16 bytes

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed.

[Bug target/113912] push2/pop2 generated when stack isn't aligned to 16 bytes

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:853eb57759967335a7ea872e6a0721034db6fabd

commit r14-9058-g853eb57759967335a7ea872e6a0721034db6fabd
Author: H.J. Lu 
Date:   Tue Feb 13 13:32:44 2024 -0800

x86-64: Generate push2/pop2 only if the incoming stack is 16-byte aligned

Since push2/pop2 requires 16-byte stack alignment, don't generate them
if the incoming stack isn't 16-byte aligned.

gcc/

PR target/113912
* config/i386/i386.cc (ix86_can_use_push2pop2): New.
(ix86_pro_and_epilogue_can_use_push2pop2): Use it.
(ix86_emit_save_regs): Don't generate push2 if
ix86_can_use_push2pop2 return false.
(ix86_expand_epilogue): Don't generate pop2 if
ix86_can_use_push2pop2 return false.

gcc/testsuite/

PR target/113912
* gcc.target/i386/apx-push2pop2-2.c: New test.

[Bug ada/113979] New: Allocation of 2D array fails when Dynamic Predicate applied to type

[simon at pushface dot org via Gcc-bugs]

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

Bug ID: 113979
   Summary: Allocation of 2D array fails when Dynamic Predicate
applied to type
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57455
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57455=edit
Reproducer

This error is present in GCC 11/12/13/14 -- can’t tell about GCC 10.

The error doesn’t occur without -gnata.

--

$ /opt/gcc-14.0.1-20240114-x86_64/bin/gnatmake alloc2.adb -gnatwa -gnatl -f
-gnata
gcc -c -gnatwa -gnatl -gnata alloc2.adb

GNAT 14.0.1 20240114 (experimental)
Copyright 1992-2023, Free Software Foundation, Inc.

Compiling: alloc2.adb
Source file time stamp: 2024-02-18 14:27:29
Compiled at: 2024-02-18 14:28:05

 1. procedure Alloc2 is
 2.type Grid is array (Positive range <>, Positive range <>) of Integer
with
 3.   Dynamic_Predicate => Grid'First (1) = 1 and then Grid'First (2) =
1;
 4.
 5.type Grid_Ptr is access Grid;
 6.
 7.Data : Grid_Ptr := new Grid (1 .. 10, 1 .. 20);
  |
>>> error: invalid use of subtype mark in expression or call

 8. begin -- Alloc2
 9.null;
10. end Alloc2;

 10 lines: 1 error
gnatmake: "alloc2.adb" compilation error

[Bug middle-end/113974] Attribute common ignored

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Why do you care?  The behavior is the same whether a static variable is put
into a BSS or LCOMM section.  Common attribute or -fcommon/-fno-common is about
the behavior of public variables without initializers, whether it is allowed to
be defined in multiple TUs or not.  For static variables that is not the case,
the compiler as an optimization should remove unused variables and others will
be defined zero initialized, whether from BSS or LCOMM or any other similar
way.

[Bug middle-end/113974] Attribute common ignored

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

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

--- Comment #3 from Georg-Johann Lay  ---
Then the documentation should make that clear that with -fno-data-sections the
object goes in COMM, but with -fdata-sections it does not and the attribute
"common" is ignored.

Better still, the compiler would behave as documented irrespective of
-f[no]-data-sections.

This is an issue of the compiler, not of the assembler.

Presumably clang just copied gcc behaviour back then?

[Bug c/44854] Improve diagnostic for missing member name or '; ' in a struct

[peter0x44 at disroot dot org via Gcc-bugs]

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

peter0x44 at disroot dot org changed:

   What|Removed |Added

 CC||peter0x44 at disroot dot org

--- Comment #4 from peter0x44 at disroot dot org ---
GCC trunk currently emits:
:1:18: error: expected unqualified-id before '}' token
1 | struct foo { int };
  |  ^
Which seems pretty okay to me.

I still think there is room for improvement and I prefer clang's wording on
this issue:

:1:18: error: expected member name or ';' after declaration specifiers
1 | struct foo { int };
  |  ~~~ ^

I think more people are likely to understand what a "member name" is, rather
than "unqualified-id"

[Bug target/113978] Misoptimize for long vector load operation

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

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #7)
> The psABI doesn't cover that.  It only talks about __m128, __m256 and __m512
> types, and
> as both compilers use the GNU vector_size attribute extension under the hood
> for those types, that is how __attribute__((vector_size ({16,32,64})))
> should behave.
> Smaller vectors (vector_size 2, 4, 8) on x86_64 are in GCC passed like
> __m128 (I think), larger vectors or even __m256/__m512 if AVX/AVX512 isn't
> supported are classified as MEMORY like > 16 byte structures/unions.

And given that vector_size is a GNU extension and GCC behaves that way since
GCC 4.0
(I think since https://gcc.gnu.org/legacy-ml/gcc-patches/2004-07/msg01512.html
,
before that
typedef char V __attribute__((vector_size (128)));
V foo (V* p) { return *p; }
has been rejected, we only supported natively supported vectors in GCC 3.x), so
I think LLVM needs to be fixed to match that.

[Bug middle-end/112344] [14 Regression] Wrong code at -O2 on x86_64-pc-linux-gnu

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Dimitar Dimitrov :

https://gcc.gnu.org/g:3796216bfa49b5ca288afe0760931a4c5b8ea346

commit r14-9055-g3796216bfa49b5ca288afe0760931a4c5b8ea346
Author: Dimitar Dimitrov 
Date:   Thu Feb 15 21:02:37 2024 +0200

testsuite: Mark non-optimized variants as expensive

When not optimized for speed, the test for PR112344 takes several
seconds to execute on native x86_64, and 15 minutes on PRU target
simulator.  Thus mark those variants as expensive.  The -O2 variant
which originally triggered the PR is not expensive, hence it is
still run by default.

PR middle-end/112344

gcc/testsuite/ChangeLog:

* gcc.dg/torture/pr112344.c: Run non-optimized variants only
if expensive tests are allowed.

Signed-off-by: Dimitar Dimitrov 

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[aarnold.gcc at antonarnold dot de via Gcc-bugs]

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

--- Comment #10 from Anton Arnold  ---
I applied the patch to a gcc 13.2 buildroot toolchain for a coldfire cpu with
ISA-A+ instruction set. Everything compiled fine and a linux 4.19 uclinux nommu
build with buildroot and several custom packages runs fine with no
abnormabilities. Great work, thank you for still contributing to this
architecture!

[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe

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

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

--- Comment #12 from Sam James  ---
(In reply to Andrew Pinski from comment #9)
> This should work, I think:
> [...]

I'm going to apply this tonight for our arm builds downstream as we can't do
any testing right now and there's a lot of bugs I'm hitting which look like
they could be dupes of this.

[Bug tree-optimization/51084] bounds checking not optimized to a single comparison

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

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

Paul Eggert  changed:

   What|Removed |Added

 CC||eggert at cs dot ucla.edu

--- Comment #4 from Paul Eggert  ---
I still see the problem with gcc (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6) on
x86-64.

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss

[tamiko at gentoo dot org via Gcc-bugs]

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

--- Comment #2 from Matthias Maier  ---
I have bisected the issue to:

commit 2ec399d8a6c9c26d69b73faf77c694fa3915dcec (HEAD, refs/bisect/bad)
Author: Joerg Sonnenberger 
Date:   Fri Sep 1 10:26:00 2017 -0600

varasm.c (bss_initializer_p): Do not put constants into .bss

* varasm.c (bss_initializer_p): Do not put constants into .bss
(categorize_decl_for_section): Handle bss_initializer_p returning
false when DECL_INITIAL is NULL.

* gcc.target/i386/const-in-bss.c: New test.

From-SVN: r251602


(But I have the feeling that the issue really lies in `mpi_type_id_for_type`
being misidentified as a constant (suitable for .rodata). The above commit
might have merely made the issue visible by turning it into a segfault.)



bisect log:
git bisect start
# good: [883312dc79806f513275b72502231c751c14ff72] Use ucontext_t not struct
ucontext in linux-unwind.h files.
git bisect good 883312dc79806f513275b72502231c751c14ff72
# bad: [406c2abec3f998e9064919b22db62f38a7c0e7b9] * gennews (files): Add files
for GCC 8.
git bisect bad 406c2abec3f998e9064919b22db62f38a7c0e7b9
# bad: [9cf7bfd919f394595c0ac561ed67b333a39ae51e] PR 83070 Fix -Wsign-compare
warning
git bisect bad 9cf7bfd919f394595c0ac561ed67b333a39ae51e
# bad: [01f44e44faf37fc34775b9e28e46d1c9243b247d] i386: Update preferred stack
boundary for leaf functions
git bisect bad 01f44e44faf37fc34775b9e28e46d1c9243b247d
# good: [30af3a2bbd315bf82363c066a335a040dede9901] Boolify some parameters.
git bisect good 30af3a2bbd315bf82363c066a335a040dede9901
# good: [3ca3c6ef7110fb842cf8175a58d91d239c418bbe] re PR sanitizer/81902 (new
-fsanitize=pointer-overflow option undocumented)
git bisect good 3ca3c6ef7110fb842cf8175a58d91d239c418bbe
# bad: [0f99f8e6d63038b68e5e7af950ff9e329bdc40ad] Daily bump.
git bisect bad 0f99f8e6d63038b68e5e7af950ff9e329bdc40ad
# bad: [95edbf5e5fb2c57ceda70cdf277d9b7655c1796e] Minor reformatting.
git bisect bad 95edbf5e5fb2c57ceda70cdf277d9b7655c1796e
# bad: [806fcf7183377c7df062a7fa0bcf9d0ce8ea1fc0] trans.c
(adjust_for_implicit_deref): New function.
git bisect bad 806fcf7183377c7df062a7fa0bcf9d0ce8ea1fc0
# bad: [ca1150f0129abd2b0b52ad0c701a6bd7e0a1fc76] re PR sanitizer/81981
(-fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear)
git bisect bad ca1150f0129abd2b0b52ad0c701a6bd7e0a1fc76
# bad: [0c949f0a1ce9cfa8c48e62628493140d60e65ea7] re PR libquadmath/81848 (Add
PowerPC support to libquadmath)
git bisect bad 0c949f0a1ce9cfa8c48e62628493140d60e65ea7
# bad: [beb8b5c154e57f5c2e3e6f372c2bae9a10f619b4] class.c
(finish_struct_methods): Done clear DECL_IN_AGGR_P here.
git bisect bad beb8b5c154e57f5c2e3e6f372c2bae9a10f619b4
# good: [db6bb1ec036f180584d221cdc66dff7bb7180d7a] S/390: PR82012: Implement
CAN_INLINE_P target hook.
git bisect good db6bb1ec036f180584d221cdc66dff7bb7180d7a
# bad: [e035be33793fa4aef8cff3358c9670a648d5d273] Fix excess precision handling
of compound assignments (PR c/82071).
git bisect bad e035be33793fa4aef8cff3358c9670a648d5d273
# bad: [2ec399d8a6c9c26d69b73faf77c694fa3915dcec] varasm.c (bss_initializer_p):
Do not put constants into .bss
git bisect bad 2ec399d8a6c9c26d69b73faf77c694fa3915dcec
# first bad commit: [2ec399d8a6c9c26d69b73faf77c694fa3915dcec] varasm.c
(bss_initializer_p): Do not put constants into .bss