[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #23 from Rama Malladi  ---
(In reply to Rama Malladi from comment #22)
> I will close this issue as we were unable to reproduce the perf drop going
> from gcc-7 to gcc-8 on a Graviton2 based instance. The performance of
> 519.lbm_r built with gcc-7.4 was same as that with gcc-8.5.

Can someone from the GCC dev/ regression team close this issue as I am unable
to find an option for the same? Thanks

[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #22 from Rama Malladi  ---
I will close this issue as we were unable to reproduce the perf drop going from
gcc-7 to gcc-8 on a Graviton2 based instance. The performance of 519.lbm_r
built with gcc-7.4 was same as that with gcc-8.5.

[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d

[yinyuefengyi at gmail dot com via Gcc-bugs]

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

Xionghu Luo (luoxhu at gcc dot gnu.org)  changed:

   What|Removed |Added

 CC||yinyuefengyi at gmail dot com

--- Comment #5 from Xionghu Luo (luoxhu at gcc dot gnu.org)  ---
For case c#1:
g__r_1 is a global variable changed in function hh, but ipa-prop think it is
only loaded by reference without change then removed references in
gcc/ipa-prop.cc:propagate_controlled_uses.


.wpa.081i.cp:

g__r_1/6 (g__r_1)
  Type: variable definition analyzed
  Visibility: semantic_interposition prevailing_def_ironly
  References:
  Referring: main/7 (addr) kk.constprop.0/16 (addr) kk.part.0.constprop.0/17
(read)
  Read from file: /tmp/cc3peQfe.o
  Availability: available
  Varpool flags: initialized


.wpa.085i.inline:
ipa-prop: Address IPA constant will reach a load so adding LOAD reference from
main/7 to g__r_1/6.
ipa-prop: Removed a reference from main/7 to g__r_1/6.
ipa-prop: Removing cloning-created reference from kk.constprop/16 to g__r_1/6.
...
g__r_1/6 (g__r_1)
  Type: variable definition analyzed
  Visibility: semantic_interposition prevailing_def_ironly
  References:
  Referring: main/7 (read) main/7 (read) kk.part.0.constprop.0/17 (read)
  Read from file: /tmp/cc3peQfe.o
  Availability: available
  Varpool flags: initialized


It seems a bug exposed by r12-2887-ga6da2cddcf0e959d, but maybe actually caused
by r12-2523-g13586172d0b70c since it fail to identify globals not read-only...

[Bug libgcc/109282] Libgcc references sh and not $(SHELL) in Makefile.in

[chrisj at rtems dot org via Gcc-bugs]

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

--- Comment #5 from Chris Johns  ---
(In reply to Andrew Pinski from comment #4)
> My bet if you do /bin/sh you would also get into trouble too ...

I do not think it is /bin/sh but you are right with the link bring MacOS
blocking an exe that should not run and it was related to my path and my
mistake. Using make's $(SHELL) with an absolute path made the build ignore my
broken set up and more robust. Make uses:

build/libcc1/config.log:SHELL='/bin/sh'

I think the path as a clean up is a good things to have.

[Bug c++/105452] [10/11/12/13 Regression] static_assert inside anonymous union inside a templated struct causes invalid "inaccessible within this context" error

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
If v is dependent, the testcase last worked in 4.5.

template 
struct C {
  union {
T v;
static_assert(sizeof(v) == sizeof(char), "");
  };
};

int main() {
  C x;
}

[Bug middle-end/109326] Sub-optimal assembler code generation for valid C on x86-64

[susurrus.of.qualia at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Steve Thompson  ---
(In reply to Steve Thompson from comment #5)
>   18   16   32
> 64B code:
> 
> 1.2K code:

Sorry, my touchpad glitched and sent prematurely.

For the overlarge vectorized version I hate:
[28]  nr_ops=1  nr_samples=100(0)   min=1   avg=5   max=12248
[28]  nr_ops=8  nr_samples=100(0)   min=1   avg=6   max=13022
[28]  nr_ops=16 nr_samples=100(0)   min=8   avg=11  max=9548 
[28]  nr_ops=32 nr_samples=100(0)   min=26  avg=33  max=8126 
[28]  nr_ops=64 nr_samples=100(0)   min=62  avg=73  max=11186
[28]  nr_ops=128nr_samples=100(0)   min=134 avg=153 max=14426
[28]  nr_ops=256nr_samples=100(0)   min=296 avg=312 max=12608
[28]  nr_ops=1024   nr_samples=100(0)   min=1250avg=1269max=23858

And the compact, esthetically pleasing version I like:
[28]  nr_ops=1  nr_samples=100(0)   min=1   avg=5   max=7910 
[28]  nr_ops=8  nr_samples=100(0)   min=1   avg=7   max=20150
[28]  nr_ops=16 nr_samples=100(0)   min=8   avg=24  max=11402
[28]  nr_ops=32 nr_samples=100(0)   min=62  avg=74  max=20582
[28]  nr_ops=64 nr_samples=100(0)   min=152 avg=153 max=12482
[28]  nr_ops=128nr_samples=100(0)   min=296 avg=313 max=33884
[28]  nr_ops=256nr_samples=100(0)   min=620 avg=632 max=22940
[28]  nr_ops=1024   nr_samples=100(0)   min=2528avg=2546max=25064

(System is an AMD Ryzen 5700U laptop; the [28] is the measured cycle latency of
the RDTSCP operation; ()'ed number shows bad samples occasionally).  


As it turns out, there are no advantages to the vectorized version until arrays
of 16; after that it is approximately twice as fast.  Some will be happy to pay
that cost for the extra performance I suppose, but it still seems wasteful.

Again, sorry for being an idiot.

[Bug middle-end/109326] Sub-optimal assembler code generation for valid C on x86-64

[susurrus.of.qualia at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Steve Thompson  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Steve Thompson from comment #3)
> > However I don't understand why olock_reset_op() is so large.  It's
> > a trivial initializer for a descriptor with an array of olock_op_element
> > structures appended.  There's no way it should look like what I quoted.  I'd
> > be happy if I am experiencing a fever-dream over nothing due to ignorance,
> > but I am not convinced that that is the case.  If I am wrong I will be very
> > disappointed.
> 
> GCC unrolled the loop via vectorizing it.

OMG did it ever.  It seems that I'm an idiot and must apologise for wasting
everyone's time.

I fixed up some remaining support code and dug into it with gdb and determined
that it does, in fact work.   There appear to be distinct paths for particular
array ranges and logic to take care odd numbers, sort of like memcopy handling
large blocks.  

But I have to say that i really don't like it, and obviously I can work around
it by making the while() block similar to what is done in olock_init_op(). 
That gives me two functions with a combined text of 64 bytes if there is no
padding.  Compare this to the 1.2KB  of the original disassembly for a generous
factor of 20 code expansion.  That seems like a great way to bloat code.

I realize that -Os is available, but it eliminates a bunch of supposed inline
functions leading to linker errors for the missing symbols.  I'm not about to
try finding out why for the time being as I don't really need it.

For fun I built a short test program and measured the latency across
olock_reset_op for various array lengths:

  18   16   32
64B code:

1.2K code:

[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #15 from chenglulu  ---
(In reply to Andrew Macleod from comment #14)
> The upcoming patch for 109274 should resolve this.

The problem has been solved. Thanks!

[Bug bootstrap/109051] Configure takes long time for multibuild of run-time libraries

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

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

--- Comment #5 from Andrew Pinski  ---
aprofile is 10 multilibs and rmprofile is 21 multilibs.
so 31 multilibs in total (if I counted correctly).

that is a lot of building in general.

[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |12.3

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk by commit r13-6934-g31a909712014b75fc6ae2ca5eaa425f218bb5f32

I'll backport to gcc-12 too.

[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-6937-gee122a2eeaea2ffec0e32577c7372bd4e2289e11
Author: Jonathan Wakely 
Date:   Thu Mar 30 00:42:11 2023 +0100

libstdc++: Fix filename of new test [PR109242]

libstdc++-v3/ChangeLog:

PR libstdc++/109242
* testsuite/20_util/optional/monadic/pr109340.cc: Moved to...
* testsuite/20_util/optional/monadic/pr109242.cc: ...here.

[Bug c++/109340] Inconsistent diagnostics for invalid member types in union

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

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

--- Comment #2 from Jonathan Wakely  ---
Gah, wrong ID in that commit message.

[Bug c++/109340] Inconsistent diagnostics for invalid member types in union

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:31a909712014b75fc6ae2ca5eaa425f218bb5f32

commit r13-6934-g31a909712014b75fc6ae2ca5eaa425f218bb5f32
Author: Jonathan Wakely 
Date:   Wed Mar 29 22:16:55 2023 +0100

libstdc++: Use std::remove_cv_t in std::optional::transform [PR109340]

We need to strip cv-qualifiers from the result of the callable passed to
std::optional::transform.

For std::expected::transform and std::expected::transform_error I
noticed we were stripping cv-qualifiers but were also incorrectly
stripping references.

libstdc++-v3/ChangeLog:

PR libstdc++/109340
* include/std/expected (expected::transform): Use
std::remove_cv_t instead of std::remove_cvref_t.
(expected::transform_error): Likewise.
(expected::transform): Likewise.
(expected::transform_error): Likewise.
* include/std/optional (transform): Use std::remove_cv_t.
* testsuite/20_util/optional/monadic/pr109340.cc: New test.

[Bug analyzer/105273] -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #9 from David Malcolm  ---
Unfortunately this turned out to be nontrivial to backport to gcc 12 e.g. due
to r13-575-g2c05a2d1a8e469 changing the representation of enums in the C
frontend from gcc 12 to 12.

gcc 13 has the fix; closing this out.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #40 from Andrew Macleod  ---

> There is no problem with adding --params, and those are always better than
> magic numbers.
> 
> Btw, I originally wondered why we don't re-compute zone1_12 because it's
> in the imports of the successor (OK, the empty successors single successor
> block) and expected those to trigger re-computes.

Yeah, I don't like magic number either.  I vaguely recall that it changed the
footprint of something and caused linking issues with something else requiring
complete rebuilds which annoyed some people.. but I  have lost the context.


Recomputes have nothing to do with imports, its all about exports.  Exports
drive the range engine... they are the things that change on exit to block
based on the edge taken.  Imports are things which can affect an export. So in
some iterative/analytical world, if the imports to a block do not change, the
exports will not change either.

Recomputes are about having an export from a block in your definition chain.
This means you are only indirectly related to the export.   If the export
changes, then your value may also change if you can be recalculated using the
export.

This issue is fundamentally about how much effort we make into looking if you
can be recomputed.  Its turns out the underlying engine is more efficient than
I realized, and once we indicate it can be calculated, the calculation itself
is actually linear. 

If we stick to single ssa-names dependencies, then even though the lookup is
currently quadratic, for smallish numbers, its pretty minimal impact.

Most cases I've seen that are of impact seem to be a sequence involving a few
casts.  The current patchset with a depth of 5 catches the vast majority of
things, and is not that expensive.

[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5

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

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

--- Comment #5 from Martin Jambor  ---
(In reply to Jakub Jelinek from comment #4)
> --- gcc/ipa-cp.cc.jj  2023-03-14 19:12:19.949553036 +0100
> +++ gcc/ipa-cp.cc 2023-03-29 18:32:34.14423 +0200
> @@ -3117,7 +3117,9 @@ propagate_aggs_across_jump_function (str
>   {
> HOST_WIDE_INT val_size;
>  
> -   if (item->offset < 0 || item->jftype == IPA_JF_UNKNOWN)
> +   if (item->offset < 0
> +   || item->jftype == IPA_JF_UNKNOWN
> +   || item->offset >= (HOST_WIDE_INT) UINT_MAX * BITS_PER_UNIT)
>   continue;
> val_size = tree_to_shwi (TYPE_SIZE (item->type));
>  
> fixes the ICE and is then similar to the PR108605 fix.  Dunno if the code
> can overflow also offset + size computations or something protects against
> that.
> Anyway, I think it would be worth it to switch all those unsigned int byte
> offsets to
> unsigned HOST_WIDE_INTs for GCC 14.

Actually, I am in the process of doing the reverse in order to try and
keep the memory footprint of the structures small.  (The reason why
the HOST_WIDE_BITs are signed is what get_ref_base_and_extent used to
return).  Unfortunately what I wanted to do but forgot is the
following (only lightly tested so far, it has the benefit that
uselessly large offsets are not even streamed):

diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index de45dbccf16..edc1f469914 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -1735,6 +1735,8 @@ build_agg_jump_func_from_list (struct
ipa_known_agg_contents_list *list,

   item.offset = list->offset - arg_offset;
   gcc_assert ((item.offset % BITS_PER_UNIT) == 0);
+  if (item.offset + list->size >= (HOST_WIDE_INT) UINT_MAX *
BITS_PER_UNIT)
+   continue;

   jfunc->agg.items->quick_push (item);
 }

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Steve Kargl from comment #7)
> On Wed, Mar 29, 2023 at 09:28:38PM +, pinskia at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
> > 
> > --- Comment #5 from Andrew Pinski  ---
> > There is a bug with -m32 and fc-prototypes though, it should be long long
> > rather than long long. Let me provide a patch for that.
> > 
> 
> This replaces '_' by ' ', but would certainly break if int_t
> is in type_name.

Right which is why my patch in comment #6 is reasonable. I am going to commit
it as obvious after my bootstrap/test is finished.

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

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

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

--- Comment #7 from Steve Kargl  ---
On Wed, Mar 29, 2023 at 09:28:38PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
> 
> --- Comment #5 from Andrew Pinski  ---
> There is a bug with -m32 and fc-prototypes though, it should be long long
> rather than long long. Let me provide a patch for that.
> 

This replaces '_' by ' ', but would certainly break if int_t
is in type_name.

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 3b24bdc1a6c..3921adfbe01 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -3807,6 +3807,7 @@ write_decl (gfc_typespec *ts, gfc_array_spec *as, const
char *sym_name,
bool func_ret, locus *where, bool bind_c)
 {
   const char *pre, *type_name, *post;
+  char *bp, buf[81];
   bool asterisk;
   enum type_return rok;

@@ -3819,7 +3820,15 @@ write_decl (gfc_typespec *ts, gfc_array_spec *as, const
char *sym_name,
   gfc_typename (ts));
   return;
 }
-  fputs (type_name, dumpfile);
+
+#if 1
+  bp = [0];
+  strncpy(bp, type_name, 80);
+  for (; *bp != '\0'; bp++)
+if (*bp == '_') *bp = ' ';
+#endif
+
+  fputs (buf, dumpfile);
   fputs (pre, dumpfile);
   if (asterisk)
 fputs ("*", dumpfile);

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

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

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

--- Comment #6 from Andrew Pinski  ---
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 3b24bdc1a6c..7869130ac2b 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -3697,6 +3697,8 @@ get_c_type_name (gfc_typespec *ts, gfc_array_spec *as,
const char **pre,
  && c_interop_kinds_table[i].value == ts->kind)
{
  *type_name = c_interop_kinds_table[i].name + 2;
+ if (strcmp (*type_name, "long_long") == 0)
+   *type_name = "long long";
  if (strcmp (*type_name, "signed_char") == 0)
*type_name = "signed char";
  else if (strcmp (*type_name, "size_t") == 0)

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

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

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

--- Comment #5 from Andrew Pinski  ---
There is a bug with -m32 and fc-prototypes though, it should be long long
rather than long long. Let me provide a patch for that.

[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Jonathan Wakely  ---
(In reply to Peter Kasting from comment #2)
> struct S {
>   int& i() const;
> };
> 
> void foo() {
>   std::optional().transform(::i);

The U type is a reference here, which isn't allowed.


This shows the bug:

struct A { };
const A f(int);
std::optional o;
A&& p = *o.transform(f);

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-03-29
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
(In reply to Eric Reischer from comment #2)
> However, if you are, say, creating an
> API that has autogenerated files redistributed (e.g., a base Fortran package
> and then autogenerated and distributed C/C++ header files), the types
> generated using -fc-prototypes are not safely transportable to another
> compiler with the requested variable sizes.

Yes you should use this option this wayt; you can always post process the
generated headers.
For -m32 vs -m64, you could generate two headers and have a master header that
includes one or another.
There is no way to store these headers in a repo unless you post process them.

[Bug rtl-optimization/108713] ICE during RTL pass: into_cfglayout for x86_64-pc-linux-gnu '-m32', C++ 'libgomp.c-c++-common/for-11.c'

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

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

--- Comment #3 from Thomas Schwinge  ---
(Possibly?) similarly now with GCC sources based on 2023-03-28 commit
b3c5933ee726004e4e47291d422dfe7ac3345062, with a bunch of local OMP changes on
top (but those shouldn't be touching the relevant area of code), standard
bootstrap build, I've observed an ICE as follows on our x86_64-pc-linux-gnu
testing system amd_ryzen3, in routine libgomp testing for '-m32':

[...]
spawn -ignore SIGHUP gcc -x c++
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-5.c
-m32 -foffload-options=amdgcn-amdhsa=-march=gfx906
-I../source-gcc/libgomp/testsuite/../../include
-I../source-gcc/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -O2 -lstdc++ -lm
-o ./for-5.exe
during RTL pass: reload
In file included from
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-1.h:18,
 from
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-5.c:50:
   
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-2.h: In
function 'f8_tpf_simd_guided32() [clone ._omp_fn.1]':
   
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-2.h:127:29:
internal compiler error: Segmentation fault
0x16a1b7f crash_signal
[...]/source-gcc/gcc/toplev.cc:314
0x129c1eb base_pool_allocator::remove(void*)
[...]/source-gcc/gcc/alloc-pool.h:445
0x129c1eb object_allocator::remove(et_node*)
[...]/source-gcc/gcc/alloc-pool.h:524
0x129c1eb et_free_tree_force
[...]/source-gcc/gcc/et-forest.cc:502
0x1214868 free_dominance_info(function*, cdi_direction)
[...]/source-gcc/gcc/dominance.cc:812
0x1484b08 do_reload
[...]/source-gcc/gcc/ira.cc:5955
0x1484b08 execute
[...]/source-gcc/gcc/ira.cc:6149
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.
compiler exited with status 1
FAIL: libgomp.c++/../libgomp.c-c++-common/for-5.c (internal compiler error:
Segmentation fault)
[...]


(In reply to Thomas Schwinge from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > If you can reproduce it with vanilla trunk, it is worth it, sure, but
> > without a reliable reproducer there isn't much to do.
> 
> I'll attempt to reproduce with clean sources, and Valgrind enabled.

Have not yet gotten to that.

[Bug c++/109340] New: Inconsistent diagnostics for invalid member types in union

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

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

Bug ID: 109340
   Summary: Inconsistent diagnostics for invalid member types in
union
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template
union U
{
  U();

  T t;
};

U ref;
U arr;
U func;

G++ correctly rejects this, but has three very different errors for basically
the same problem:

union.cc: In instantiation of ‘union U’:
union.cc:9:9:   required from here
union.cc:6:5: error: non-static data member ‘U::t’ in a union may not
have reference type ‘int&’
6 |   T t;
  | ^
union.cc: In instantiation of ‘union U’:
union.cc:10:10:   required from here
union.cc:6:5: error: flexible array member ‘U::t’ in union
union.cc: In instantiation of ‘union U’:
union.cc:11:10:   required from here
union.cc:6:5: error: data member ‘U::t’ invalidly declared function type


Specifically:

error: non-static data member ‘U::t’ in a union may not have reference
type ‘int&’

error: flexible array member ‘U::t’ in union

error: data member ‘U::t’ invalidly declared function type

Could we use the same phrasing for all three?

The first one seems the best, and the third one seems the worst.

For comparison, Clang says:

union.cc:6:5: error: union member 't' has reference type 'int &'
  T t;
^
union.cc:9:9: note: in instantiation of template class 'U' requested
here
U ref;
^
union.cc:6:5: error: data member instantiated with function type 'int ()'
  T t;
^
union.cc:11:10: note: in instantiation of template class 'U' requested
here
U func;
 ^
2 errors generated.


Not very good either.

EDG says:

"union.cc", line 6: error: incomplete type is not allowed
T t;
  ^
  detected during instantiation of union "U [with T=int []]" at line
10

"union.cc", line 6: error: a function type is not allowed here
T t;
  ^
  detected during instantiation of union "U [with T=int ()]" at line
11

2 errors detected in the compilation of "union.cc".

[Bug c++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||11.3.1
 CC||rguenth at gcc dot gnu.org
  Known to fail||12.1.0, 13.0
Summary|stop_token compiled with|[12/13 Regression]
   |-Og yields  |stop_token compiled with
   |maybe-uninitialized |-Og yields
   ||maybe-uninitialized

--- Comment #1 from Jonathan Wakely  ---
The warning started with r12-6677

ipa/103989 - avoid IPA inlining of small functions with -Og

The following change avoids doing IPA inlining of small functions
into functions compiled with -Og - those functions will see almost no
followup scalar cleanups so that the benefit anticipated by the
inliner will not be realized and instead the late diagnostic code
will be confused by dead code that is left around.

[Bug c++/109339] stop_token compiled with -Og yields maybe-uninitialized

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-29
   Keywords||diagnostic
 Ever confirmed|0   |1

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

[richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #6 from Richard Smith  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Christopher Di Bella from comment #3)
> > This is apparently a Clang bug: the RHS of `R42c` isn't evaluated because of
> > short-circuiting. Apologies for the noise and thanks for helping me work
> > through it.
> 
> No, clang and GCC disagree even on:
> ```
> template  concept A42b = true;
> template  concept R42c = A42b;
> 
> static_assert (R42c);
> ```
> 
> There is no short-circuting here.

No substitution is performed into 'Tc&' here, because normalization of R42c
produces the atomic constraint 'true' with an empty parameter mapping. So the
type 'void&' is never formed.

[Bug c++/109339] New: stop_token compiled with -Og yields maybe-uninitialized

[gcc at heine dot tech via Gcc-bugs]

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

Bug ID: 109339
   Summary: stop_token compiled with -Og yields
maybe-uninitialized
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at heine dot tech
  Target Milestone: ---

This happens since gcc 12.

This snippet compiled with -std=c++20 -Og -Wmaybe-uninitialized

```
#include 

int main() {
std::stop_source ss;
}
```

yields this warning

```
In constructor 'std::stop_source::stop_source()',
inlined from 'int main()' at :4:22:
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/stop_token:480:21:
warning: 'ss' may be used uninitialized [-Wmaybe-uninitialized]
  480 | stop_source() : _M_state(*this)
  | ^~~
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/stop_token: In function
'int main()':
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/stop_token:397:7: note: by
argument 2 of type 'const std::stop_source&' to
'std::stop_token::_Stop_state_ref::_Stop_state_ref(const std::stop_source&)'
declared here
  397 |   _Stop_state_ref(const stop_source&)
  |   ^~~
:4:22: note: 'ss' declared here
4 | std::stop_source ss;
  |  ^~
```

Godbolt: https://godbolt.org/z/KofErdEzY

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

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

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

--- Comment #3 from Steve Kargl  ---
On Wed, Mar 29, 2023 at 05:50:05PM +, emr-gnu at hev dot psu.edu wrote:
> 
> 
> Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
> E", you get the following output:
> 
> > gfortran -m32 -fc-prototypes -fsyntax-only foo.f90
> 
>  long a;
>  {...}
>  long_long e;
> } bar;

The companion C processor is gcc.  It is generating
prototypes for that C processor.  If one is manipulating
the environment with a command line option such as -m32
or -m64, then one likely needs to use the same option 
with gcc.  Does 'gcc -m32' support "long_long"?  If it
doesn't, then you'll need to hack on 

gcc/fortran/dump-parse-tree.cc
gcc/fortran/iso-c-binding.def
gcc/fortran/trans-types.cc

[Bug analyzer/108733] -Wanalyzer-use-of-uninitialized-value false positives seen with __attribute__((cleanup))

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed on gcc 12 branch by the above (for the eventual gcc 12.3
release); marking as resolved.

[Bug analyzer/108704] Many -Wanalyzer-use-of-uninitialized-value false positives seen in qemu's softfloat.c

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed on gcc 12 branch by the above (for the eventual gcc 12.3
release); marking as resolved.

[Bug analyzer/106325] -Wanalyzer-null-dereference false positive due to analyzer not making assumptions for `__attribute__((nonnull))`

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

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

--- Comment #10 from David Malcolm  ---
Should be fixed on gcc 12 branch by the above (for the eventual gcc 12.3
release).

Still affects GCC 11 and GCC 10.

[Bug analyzer/107582] - -Wanalyzer-use-of-uninitialized-value false positive with while loop in pthread_cleanup_push

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #12 from David Malcolm  ---
Should be fixed on gcc 12 branch by the above (for the eventual gcc 12.3
release); marking as resolved.

[Bug analyzer/107345] -Wanalyzer-null-dereference false positive with giving weird path infomation

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Should be fixed on gcc 12 branch by the above (for the eventual gcc 12.3
release);  marking as resolved.

[Bug analyzer/108562] [meta-bug] tracker bug for issues with -Wanalyzer-null-dereference

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

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

Bug 107345 Summary: -Wanalyzer-null-dereference false positive with  giving 
weird path infomation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345

   What|Removed |Added

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

[Bug analyzer/105784] -Wanalyzer-use-of-uninitialized-value false positive on partly initialized array

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed on gcc 12 branch by the above; marking as resolved.

[Bug analyzer/109094] Uninit false positive from -fanalyzer when longjmp unwinds frames with return stmts

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #12 from David Malcolm  ---
Fixed for gcc 12 by the above commit; marking as resolved.

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #5 from Andrew Pinski  ---
(In reply to Christopher Di Bella from comment #3)
> This is apparently a Clang bug: the RHS of `R42c` isn't evaluated because of
> short-circuiting. Apologies for the noise and thanks for helping me work
> through it.

No, clang and GCC disagree even on:
```
template  concept A42b = true;
template  concept R42c = A42b;

static_assert (R42c);
```

There is no short-circuting here.

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Pinski  ---
invalid as noticed.

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

[cjdb.ns at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Christopher Di Bella  ---
This is apparently a Clang bug: the RHS of `R42c` isn't evaluated because of
short-circuiting. Apologies for the noise and thanks for helping me work
through it.

[Bug c++/109338] `S auto>` isn't valid C++20

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

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

--- Comment #1 from Andrew Pinski  ---
Testcase:
```
template 
concept C = true;

template 
struct A {};

void f(A auto >) {}

```
Please place the testcase in the comment or attach it; don't just link to
godbolt.

[Bug c++/100248] ICE with global "default" keyword

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

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #3 from Arthur O'Dwyer  ---
Bug 107321 and bug 105202 are duplicates.
In bug 107321, Martin Liška writes: "Started with r10-4397-gb7689b962dd6536b."

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
```
template  concept A42b = true;
template  concept R42c = A42b;

static_assert (R42c);
```


GCC does the right thing for too:
```
template  bool A42b = true;
template  concept R42c = A42b;

static_assert (!R42c);
```

[Bug c++/109338] New: `S auto>` isn't valid C++20

[cjdb.ns at gmail dot com via Gcc-bugs]

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

Bug ID: 109338
   Summary: `S auto>` isn't valid C++20
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

Clang and GCC disagree on whether or not this code is valid. This **may** be a
relic from the Concepts TS, which Clang doesn't implement.

https://godbolt.org/z/c7rGWE9s6

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-29
 Ever confirmed|0   |1

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

Changing R42c to be a bool rather than a concept causes GCC to catch the
failure ...

That is:
```
template  struct A { static const int x = 42; };

template  concept A42 = A::x == 42;
template  concept Void = __is_same_as(Tv, void);
template  concept A42b = Void || A42;
template  bool R42c = A42b;

static_assert (R42c);
```

[Bug c++/109337] New: c++2a test concepts4.C passes when it should fail

[cjdb.ns at gmail dot com via Gcc-bugs]

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

Bug ID: 109337
   Summary: c++2a test concepts4.C passes when it should fail
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

Clang and GCC disagree on the validity of concepts4.C. I think Clang is correct
here, because forming a reference to `void` should be ill-formed.

https://godbolt.org/z/es5GxYhzd

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
The HW sqrt certainly handles NAN input by returning NAN output, the question
is if it is required to set some errno in that case as well or not.  One would
need to check what different libcs do in that case.

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #6 from Jeremy R.  ---
Thanks!

[Bug target/109328] [13 Regression] Build fail in RISC-V port

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|Build fail in RISC-V port   |[13 Regression] Build fail
   ||in RISC-V port
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-29

--- Comment #2 from Andrew Pinski  ---
Confirmed there are a few missing dependencies.

[Bug analyzer/109094] Uninit false positive from -fanalyzer when longjmp unwinds frames with return stmts

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:7903e0bca003840751c109cfa41e5a1528ece12a

commit r12-9367-g7903e0bca003840751c109cfa41e5a1528ece12a
Author: David Malcolm 
Date:   Wed Mar 29 14:16:49 2023 -0400

analyzer: fix ICE on certain longjmp calls [PR109094]

PR analyzer/109094 reports an ICE in the analyzer seen on qemu's
target/i386/tcg/translate.c

The issue turned out to be that when handling a longjmp, the code
to pop the frames was generating an svalue for the result_decl of any
popped frame that had a non-void return type (and discarding it) leading
to "uninit" poisoned_svalue_diagnostic instances being saved since the
result_decl is only set by the greturn stmt.  Later, when checking the
feasibility of the path to these diagnostics, m_check_expr was evaluated
in the context of the frame of the longjmp, leading to an attempt to
evaluate the result_decl of each intervening frames whilst in the
context of the topmost frame, leading to an assertion failure in
frame_region::get_region_for_local here:

919 case RESULT_DECL:
920   gcc_assert (DECL_CONTEXT (expr) == m_fun->decl);
921   break;

This patch updates the analyzer's longjmp implementation so that it
doesn't attempt to generate svalues for the result_decls when popping
frames, fixing the assertion failure (and presumably fixing "uninit"
false positives in a release build).

Cherrypicked from r13-6749-g430d7d88c1a123.

gcc/analyzer/ChangeLog:
PR analyzer/109094
* region-model.cc (region_model::on_longjmp): Pass false for
new "eval_return_svalue" param of pop_frame.
(region_model::pop_frame): Add new "eval_return_svalue" param and
use it to suppress the call to get_rvalue on the result when
needed by on_longjmp.
* region-model.h (region_model::pop_frame): Add new
"eval_return_svalue" param.

gcc/testsuite/ChangeLog:
PR analyzer/109094
* gcc.dg/analyzer/setjmp-pr109094.c: New test.

Signed-off-by: David Malcolm 

[Bug target/109328] [13 Regression] Build fail in RISC-V port

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 54788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54788=edit
Patch which improves the depedencies

Note I am not 100% sure this is all the way. But you should get the idea and
take it over from there.

[Bug analyzer/108733] -Wanalyzer-use-of-uninitialized-value false positives seen with __attribute__((cleanup))

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:98558117ba870d47398927f2066e469e47f39c16

commit r12-9365-g98558117ba870d47398927f2066e469e47f39c16
Author: David Malcolm 
Date:   Wed Mar 29 14:16:49 2023 -0400

analyzer: fix further overzealous state purging [PR108733]

PR analyzer/108733 reports various false positives in qemu from
-Wanalyzer-use-of-uninitialized-value with __attribute__((cleanup))
at -O1 and above.

Root cause is that the state-purging code was failing to treat:
   _25 = MEM[(void * *)];
as a usage of "val", leading to it erroneously purging the
initialization of "val" along an execution path that didn't otherwise
use "val", apart from the  __attribute__((cleanup)).

Fixed thusly.

Integration testing on the patch show this change in the number of
diagnostics:
  -Wanalyzer-use-of-uninitialized-value
   coreutils-9.1: 18 -> 16 (-2)
  qemu-7.2.0: 87 -> 80 (-7)
where all that I investigated appear to have been false positives, hence
an improvement.

Cherrypicked from r13-5745-g77bb54b1b07add.

gcc/analyzer/ChangeLog:
PR analyzer/108733
* state-purge.cc (get_candidate_for_purging): Add ADDR_EXPR
and MEM_REF.

gcc/testsuite/ChangeLog:
PR analyzer/108733
* gcc.dg/analyzer/torture/uninit-pr108733.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/106325] -Wanalyzer-null-dereference false positive due to analyzer not making assumptions for `__attribute__((nonnull))`

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:02fbda165b74179469d9eae436fed613aa6a6ebb

commit r12-9362-g02fbda165b74179469d9eae436fed613aa6a6ebb
Author: David Malcolm 
Date:   Wed Mar 29 14:16:48 2023 -0400

analyzer: use __attribute__((nonnull)) at top level of analysis [PR106325]

PR analyzer/106325 reports false postives from
-Wanalyzer-null-dereference on code like this:

__attribute__((nonnull))
void foo_a (Foo *p)
{
  foo_b (p);

  switch (p->type)
{
  /* ... */
}
}

where foo_b (p) has a:

  g_return_if_fail (p);

that expands to:

  if (!p)
{
  return;
}

The analyzer "sees" the comparison against NULL in foo_b, and splits the
analysis into the NULL and not-NULL cases; later, back in foo_a,  at
  switch (p->type)
it complains that p is NULL.

Previously we were only using __attribute__((nonnull)) as something to
complain about when it was violated; we weren't using it as a source of
knowledge.

This patch fixes things by making the analyzer respect
__attribute__((nonnull)) at the top-level of the analysis: any such
params are now assumed to be non-NULL, so that the analyzer assumes the
g_return_if_fail inside foo_b doesn't fail when called from foo_a

Doing so fixes the false positives.

Backported from r13-4520-gdcfc7ac94dbcf6.

gcc/analyzer/ChangeLog:
PR analyzer/106325
* region-model-manager.cc
(region_model_manager::get_or_create_null_ptr): New.
* region-model.cc (region_model::on_top_level_param): Add
"nonnull" param and make use of it.
(region_model::push_frame): When handling a top-level entrypoint
to the analysis, determine which params __attribute__((nonnull))
applies to, and pass to on_top_level_param.
* region-model.h (region_model_manager::get_or_create_null_ptr):
New decl.
(region_model::on_top_level_param): Add "nonnull" param.

gcc/testsuite/ChangeLog:
PR analyzer/106325
* gcc.dg/analyzer/attr-nonnull-pr106325.c: New test.
* gcc.dg/analyzer/attribute-nonnull.c (test_6): New.
(test_7): New.

Signed-off-by: David Malcolm 

[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer

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

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:833d822ff0e83478a4fe536d55dfb22cde8ddc40

commit r12-9366-g833d822ff0e83478a4fe536d55dfb22cde8ddc40
Author: David Malcolm 
Date:   Wed Mar 29 14:16:49 2023 -0400

analyzer: fix uninit false +ves reading from DECL_HARD_REGISTER [PR108968]

Cherrypicked from r13-6749-g430d7d88c1a123.

gcc/analyzer/ChangeLog:
PR analyzer/108968
* region-model.cc (region_model::get_rvalue_1): Handle VAR_DECLs
with a DECL_HARD_REGISTER by returning UNKNOWN.

gcc/testsuite/ChangeLog:
PR analyzer/108968
* gcc.dg/analyzer/uninit-pr108968-register.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/107948] GCC Static Analyzer doesn't realize `0 - width <= 0` is always true when `width > 0` and `width is int` type，

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

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

commit r12-9360-ga7cc8ecefb72f06368b055fa60f5a2ff2eb6dfdb
Author: David Malcolm 
Date:   Wed Mar 29 14:16:48 2023 -0400

analyzer: handle comparisons against negated symbolic values [PR107948]

Cherrypicked from r13-4456-g0b737090a69624.

gcc/analyzer/ChangeLog:
PR analyzer/107948
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): Fold (0 - VAL) to -VAL.
* region-model.cc (region_model::eval_condition): Handle e.g.
"-X <= 0" as equivalent to X >= 0".

gcc/testsuite/ChangeLog:
PR analyzer/107948
* gcc.dg/analyzer/feasibility-pr107948.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/108704] Many -Wanalyzer-use-of-uninitialized-value false positives seen in qemu's softfloat.c

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

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

commit r12-9364-g5da2126c4df8d83c2b2f9de7bb393ab4f5832840
Author: David Malcolm 
Date:   Wed Mar 29 14:16:48 2023 -0400

analyzer: fix overzealous state purging with on-stack structs [PR108704]

PR analyzer/108704 reports many false positives seen from
-Wanalyzer-use-of-uninitialized-value on qemu's softfloat.c on code like
the following:

   struct st s;
   s = foo ();
   s = bar (s); // bogusly reports that s is uninitialized here

where e.g. "struct st" is "floatx80" in the qemu examples.

The root cause is overzealous purging of on-stack structs in the code I
added in r12-7718-gfaacafd2306ad7, where at:

s = bar (s);

state_purge_per_decl::process_point_backwards "sees" the assignment to 's'
and stops processing, effectively treating 's' as unneeded before this
stmt, not noticing the use of 's' in the argument.

Fixed thusly.

The patch greatly reduces the number of
-Wanalyzer-use-of-uninitialized-value warnings from my integration tests:
  ImageMagick-7.1.0-57:  10 ->  6   (-4)
  qemu-7.2: 858 -> 87 (-771)
 haproxy-2.7.1:   1 ->  0   (-1)
All of the above that I've examined appear to be false positives.

Cherrypicked from r13-5745-g77bb54b1b07add.

gcc/analyzer/ChangeLog:
PR analyzer/108704
* state-purge.cc (state_purge_per_decl::process_point_backwards):
Don't stop processing the decl if it's fully overwritten by
this stmt if it's also used by this stmt.

gcc/testsuite/ChangeLog:
PR analyzer/108704
* gcc.dg/analyzer/uninit-7.c: New test.
* gcc.dg/analyzer/uninit-pr108704.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105784] -Wanalyzer-use-of-uninitialized-value false positive on partly initialized array

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

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

commit r12-9359-g1c66f1c6d69dbe0a855f7adb61df8d92ca523899
Author: David Malcolm 
Date:   Wed Mar 29 14:16:47 2023 -0400

analyzer: fix folding of '(PTR + 0) => PTR' [PR105784]

Cherrypicked from r13-4398-g3a32fb2eaa761a.

gcc/analyzer/ChangeLog:
PR analyzer/105784
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): For POINTER_PLUS_EXPR,
PLUS_EXPR and MINUS_EXPR, eliminate requirement that the final
type matches that of arg0 in favor of a cast.

gcc/testsuite/ChangeLog:
PR analyzer/105784
* gcc.dg/analyzer/torture/fold-ptr-arith-pr105784.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/107582] - -Wanalyzer-use-of-uninitialized-value false positive with while loop in pthread_cleanup_push

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

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

commit r12-9358-ge7f7483d50069fede8450091449714d122c58fca
Author: David Malcolm 
Date:   Wed Mar 29 14:16:47 2023 -0400

analyzer: fix feasibility false +ve on jumps through function ptrs
[PR107582]

PR analyzer/107582 reports a false +ve from
-Wanalyzer-use-of-uninitialized-value where
the analyzer's feasibility checker erroneously decides
that point (B) in the code below is reachable, with "x" being
uninitialized there:

pthread_cleanup_push(func, NULL);

while (ret != ETIMEDOUT)
ret = rand() % 1000;

/* (A): after the while loop  */

if (ret != ETIMEDOUT)
  x = 

pthread_cleanup_pop(1);

if (ret == ETIMEDOUT)
  return 0;

/* (B): after not bailing out  */

due to these contradictionary conditions somehow both holding:
  * (ret == ETIMEDOUT), at (A) (skipping the initialization of x), and
  * (ret != ETIMEDOUT), at (B)

The root cause is that after the while loop, state merger puts ret in
the exploded graph in an UNKNOWN state, and saves the diagnostic at (B).

Later, as we explore the feasibilty of reaching the enode for (B),
dynamic_call_info_t::update_model is called to push/pop the
frames for handling the call to "func" in pthread_cleanup_pop.
The "ret" at these nodes in the feasible_graph has a conjured_svalue for
"ret", and a constraint on it being either == *or* != ETIMEDOUT.

However dynamic_call_info_t::update_model blithely clobbers the
model with a copy from the exploded_graph, in which "ret" is UNKNOWN.

This patch fixes dynamic_call_info_t::update_model so that it
simulates pushing/popping a frame on the model we're working with,
preserving knowledge of the constraint on "ret", and enabling the
analyzer to "know" that the bail-out must happen.

Doing so fixes the false positive.

Cherrypicked from r13-4158-ga7aef0a5a2b7e2.

gcc/analyzer/ChangeLog:
PR analyzer/107582
* engine.cc (dynamic_call_info_t::update_model): Update the model
by pushing or pop a frame, rather than by clobbering it with the
model from the exploded_node's state.

gcc/testsuite/ChangeLog:
PR analyzer/107582
* gcc.dg/analyzer/feasibility-4.c: New test.
* gcc.dg/analyzer/feasibility-pr107582-1.c: New test.
* gcc.dg/analyzer/feasibility-pr107582-2.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/107345] -Wanalyzer-null-dereference false positive with giving weird path infomation

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:111fb5d3cafd0f7f2a0d01aa9e1213013fa0cc83

commit r12-9357-g111fb5d3cafd0f7f2a0d01aa9e1213013fa0cc83
Author: David Malcolm 
Date:   Wed Mar 29 14:16:47 2023 -0400

analyzer: handle (NULL == ) [PR107345]

Cherrypicked from r13-3468-g18faaeb3af42f3.

gcc/analyzer/ChangeLog:
PR analyzer/107345
* region-model.cc (region_model::eval_condition_without_cm):
Ensure that constants are on the right-hand side before checking
for them.

gcc/testsuite/ChangeLog:
PR analyzer/107345
* gcc.dg/analyzer/pr107345.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/106573] Missing -Wanalyzer-use-of-uninitialized-value on calls handled by state machines

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

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

commit r12-9355-gc63e5a234d0193e1f41024cf0eee840998e04c7f
Author: David Malcolm 
Date:   Wed Mar 29 14:16:46 2023 -0400

analyzer: better fix for -Wanalyzer-use-of-uninitialized-value [PR106573]

Cherrypicked from r13-2053-gca123e019bb92f.

gcc/analyzer/ChangeLog:
PR analyzer/106573
* region-model.cc (region_model::on_call_pre): Use check_call_args
when ensuring that we call get_arg_svalue on all args.  Remove
redundant call from handling for stdio builtins.

Signed-off-by: David Malcolm 

[Bug analyzer/106573] Missing -Wanalyzer-use-of-uninitialized-value on calls handled by state machines

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:62a565e56763c65ec9e134735aa780cf2b1c3cfa

commit r12-9354-g62a565e56763c65ec9e134735aa780cf2b1c3cfa
Author: David Malcolm 
Date:   Wed Mar 29 14:16:46 2023 -0400

analyzer: fix missing -Wanalyzer-use-of-uninitialized-value on
special-cased functions [PR106573]

We were missing checks for uninitialized params on calls to functions
that the analyzer has hardcoded knowledge of - both for those that are
handled just by state machines, and for those that are handled in
region-model-impl-calls.cc (for those arguments for which the svalue
wasn't accessed in handling the call).

Fixed thusly.

Backported from r13-2007-gbddd8d86e3036e, dropping the test case
fd-uninit-1.c.

gcc/analyzer/ChangeLog:
PR analyzer/106573
* region-model.cc (region_model::on_call_pre): Ensure that we call
get_arg_svalue on all arguments.

gcc/testsuite/ChangeLog:
PR analyzer/106573
* gcc.dg/analyzer/error-uninit.c: New test.
* gcc.dg/analyzer/file-uninit-1.c: New test.

Signed-off-by: David Malcolm 

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[emr-gnu at hev dot psu.edu via Gcc-bugs]

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

--- Comment #2 from Eric Reischer  ---
I can't point to a specific standard that says, "thou shalt generate output
with these types..."; it's more of a "we probably should be doing this"-type
thing.  If you are compiling Fortran and C on the same system with the same
compiler suite, this is a non-issue.  However, if you are, say, creating an API
that has autogenerated files redistributed (e.g., a base Fortran package and
then autogenerated and distributed C/C++ header files), the types generated
using -fc-prototypes are not safely transportable to another compiler with the
requested variable sizes.

This is probably better demonstrated with another example:

Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
E", you get the following output:

> gfortran -m32 -fc-prototypes -fsyntax-only foo.f90

 long a;
 {...}
 long_long e;
} bar;

---

In the above, "long_long" is nonstandard and not recognized by most compilers
(it was apparently implemented in some locations as a workaround to a problem
on Windows with gcc compatibility).

What's worse, is if you run the above in 64-bit mode on x86 Linux, you get:

> gfortran -m64 -fc-prototypes -fsyntax-only foo.f90
 long a;
 {...}
 long e;
} bar;

---

This is most definitely wrong -- "long" will be 64 bits on Linux, but only 32
bits on Windows, so the size type emitted is ambiguous.  Additionally, the
structures will no longer be interoperable, because (again, on Windows) in
C/C++ you'll get a variable "E" that will only store 32 bits, whereas in
Fortran the corresponding variable will be 64 bits, thus offsetting every
variable that comes after it. Probably better to be safe (and definitely more
portable) to leave translation of the types to when the C/C++ files are
actually compiled (which may not be with gcc) by using the stdint.h types.

I will stipulate that, yes, int64_t is not *guaranteed* to be exactly 64 bits,
and size_t is not *guaranteed* to be 32 or 64 bits (based on what architecture
you're running).  But preserving the explicitly-specified data types across the
language translation is the point here.  An entirely separate argument could be
had for INTEGER*4, INTEGER*8, etc., but in this case, since you're explicitly
requesting C_INTxx_T, you're getting something else entirely out of the
prototype-generation subsystem.

[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||llvm at rifkin dot dev

--- Comment #10 from Aldy Hernandez  ---
*** Bug 103559 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
 CC||aldyh at gcc dot gnu.org

--- Comment #5 from Aldy Hernandez  ---
(In reply to Jeremy R. from comment #0)
> For a simple invocation of sqrt, gcc inserts a < 0 check to set math errno
> if needed. E.g.
> 
> float f(float x) {
> return sqrt(x);
> }
> 
> Is generated as
> 
> f(float):
> vxorps  xmm1, xmm1, xmm1
> vucomissxmm1, xmm0
> ja  .L10
> vsqrtss xmm0, xmm0, xmm0
> ret
> .L10:
> jmp sqrtf
> 
> 
> Unfortunately, this check is still present when the GCC is able to prove
> that x is non-negative:
> 
> float f(float x) {
> if(x < 0) [[unlikely]] {
> __builtin_unreachable();
> } else {
> return sqrt(x);
> }
> }

x could also be a NAN which I *think* the hardware sqrt won't handle, so a
better test would be:

if (x < 0.0 || __builtin_isnan(x)) [[unlikely]]
  __builtin_unreachable ();

or perhaps:

if (!__builtin_isgreater(x, 0.0))

Either way, this is a subset of PR91645 so I'm closing it as a duplicate.

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

[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)

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

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

--- Comment #9 from Aldy Hernandez  ---
It looks like what we want for this test is actually !isgreaterequal() not
isless(), since we want to exclude the possibility of a NAN.  Like this:

float test (float x)
{
  if (!__builtin_isgreaterequal (x, 0.0))
__builtin_unreachable();
  return sqrtf (x);
}

After VRP1 removes the unreachable, the range for x_1 is correctly exported as
>= -0.0 without a NAN:

Global Exported (via unreachable): x_1(D) = [frange] float [-0.0 (-0x0.0p+0),
+Inf]

We end up with this:

float test (float x)
{
  float _4;

   [local count: 1073741824]:
  _4 = sqrtf (x_1(D));
  return _4;

}

which then CDCE expands with the unnecessary checking code:

   [local count: 1073741824]:
  DCE_COND_LB.2_5 = x_1(D);
  DCE_COND_LB_TEST.3_6 = DCE_COND_LB.2_5 u>= 0.0;
  if (DCE_COND_LB_TEST.3_6 != 0)
goto ; [99.95%]
  else
goto ; [0.05%]

   [local count: 1073204960]:
  _4 = .SQRT (x_1(D));
  goto ; [100.00%]

   [local count: 536864]:
  _7 = sqrtf (x_1(D));

So the CDCE pass needs to be enhanced to use the ranger, instead of heuristics,
to determine that the argument to sqrtf is neither negative nor NAN.

In this particular case, we could use global ranges for free, but there's no
reason we can't use an actual on-demand ranger for more complex scenarios.

Just a guess here, but use_internal_fn() in CDCE shrink wraps the call to sqrt
into a check with appropriate dispatch.  We could emit the .SQRT call directly
if the range of x_1 is not NAN and not negative.

[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
I think the difference is
https://sourceware.org/git/?p=glibc.git;a=commit;h=c1760eaf3b575ad174fd88b252fd16bd525fa818
which added __attribute__((malloc)) to fdopen among other things.
It is strange that it is reported just for fwrite and not for fgetc in the
other function though, both access potentially NULL stream.
Probably because {fwrite,putc,fputc,fputs}{,_unlocked} and printf family are
builtins and have nonnull attribute for the FILE * argument, but fgetc or fread
is not and glibc
doesn't use nonnull for those.

Shall we than use
2023-03-29  Jakub Jelinek  

PR analyzer/107396
* gcc.dg/analyzer/pipe-glibc.c (read_from_pie, write_to_pipe): Exit
if fdopen returns NULL.

--- gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c.jj   2022-10-25
10:37:28.106531709 +0200
+++ gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c  2023-03-29 19:14:48.789766475
+0200
@@ -13,6 +13,8 @@ read_from_pipe (int file)
   FILE *stream;
   int c;
   stream = fdopen (file, "r");
+  if (stream == NULL)
+exit (EXIT_FAILURE);
   while ((c = fgetc (stream)) != EOF)
 putchar (c);
   fclose (stream);
@@ -25,6 +27,8 @@ write_to_pipe (int file)
 {
   FILE *stream;
   stream = fdopen (file, "w");
+  if (stream == NULL)
+exit (EXIT_FAILURE);
   fprintf (stream, "hello, world!\n");
   fprintf (stream, "goodbye, world!\n");
   fclose (stream);
because this warning is not what the test wants to verify?

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Priority|P3  |P5
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
You stated what you think gfortran ought to produce, but you
did not articulate a "why?"  What problem are you trying to fix?
The prototype generated by -fc-prototypes correspond to the C
companion processor, and may not be portable to other C processors
such as tinyC or bcc.

Also note, C_SIZE_T etc are simply named constants for kind
type parameters.   All of INTEGER, INTEGER(4), INTEGER(C_INT),
and INTEGER(C_INT32_t) have the same value of 4 for the default
integer kind on 32-bit architectures in the absence of any
command line option (such as -finteger-4-integer-8).

[Bug c++/59498] [DR 1430][10/11/12/13 Regression] Pack expansion error in template alias

[ncm at cantrip dot org via Gcc-bugs]

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

--- Comment #22 from ncm at cantrip dot org ---
CWG 1430 seems to be about disallowing a construct that requires capturing an
alias declaration into a name mangling. This bug and at least some of those
referred to it do not ask for any such action.

[Bug modula2/109336] The -fmod= and -fdef= options do not work.

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #2 from Gaius Mulley  ---
Closing as a patch has been applied.

[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5

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

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

--- Comment #4 from Jakub Jelinek  ---
--- gcc/ipa-cp.cc.jj2023-03-14 19:12:19.949553036 +0100
+++ gcc/ipa-cp.cc   2023-03-29 18:32:34.14423 +0200
@@ -3117,7 +3117,9 @@ propagate_aggs_across_jump_function (str
{
  HOST_WIDE_INT val_size;

- if (item->offset < 0 || item->jftype == IPA_JF_UNKNOWN)
+ if (item->offset < 0
+ || item->jftype == IPA_JF_UNKNOWN
+ || item->offset >= (HOST_WIDE_INT) UINT_MAX * BITS_PER_UNIT)
continue;
  val_size = tree_to_shwi (TYPE_SIZE (item->type));

fixes the ICE and is then similar to the PR108605 fix.  Dunno if the code can
overflow also offset + size computations or something protects against that.
Anyway, I think it would be worth it to switch all those unsigned int byte
offsets to
unsigned HOST_WIDE_INTs for GCC 14.

[Bug modula2/109315] typo: inconsistant

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #3 from Gaius Mulley  ---
Closing as a patch has been applied.

[Bug modula2/109315] typo: inconsistant

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:3be4e43a6a0f429648ea188c8e110b74268fed27

commit r13-6931-g3be4e43a6a0f429648ea188c8e110b74268fed27
Author: Gaius Mulley 
Date:   Wed Mar 29 17:38:22 2023 +0100

PR modula2/109336 - The -fmod= and -fdef= options do not work

The -fmod= and -fdef= options do not work.  After the linking
re-implementation and subsequent restructuring the -fmod= amd -fdef= are
now broken.  This patch adds -fmod= and -fdef= processing into gm2spec.cc.
It also reduces the complexity of extension handling within M2Search
by storing the preceeding "." in the extension.

gcc/m2/ChangeLog:

PR modula2/109336
PR modula2/109315
* gm2-compiler/M2FileName.mod (CalculateFileName): Simplified by
ensuring the extension contains the ".".
(CalculateStemName): Re-formatted.
(ExtractExtension): Re-formatted.
(ExtractModule): Re-formatted.
* gm2-compiler/M2Options.def (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Options.mod (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Search.mod (FindSourceDefFile): Use
DefaultDefExt.
(DefaultDefExt): New constant.
(DefaultModExt): New constant.
(FindSourceModFile): Use DefaultModExt.
* gm2-gcc/m2decl.cc (m2decl_DeclareKnownVariable): Correct
spelling.
* gm2spec.cc (M2SOURCE): New constant.
(LANGSPEC): New value.
(MATHLIB): New value.
(WITHLIBC): New value.
(SKIPOPT): New value.
(lang_specific_driver): Replace seen_module_extension bool with
module_extension char *.  Detect -fmod= and remember extension.
Use the extension to detect modula-2 source and mark it as such.

gcc/testsuite/ChangeLog:

PR modula2/109336
* gm2/link/nondefaultext/pass/hello.md: New test.
* gm2/link/nondefaultext/pass/liba.dm: New test.
* gm2/link/nondefaultext/pass/liba.md: New test.
* gm2/link/nondefaultext/pass/link-nondefaultext-pass.exp: New
test.

Signed-off-by: Gaius Mulley 

[Bug modula2/109336] The -fmod= and -fdef= options do not work.

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:3be4e43a6a0f429648ea188c8e110b74268fed27

commit r13-6931-g3be4e43a6a0f429648ea188c8e110b74268fed27
Author: Gaius Mulley 
Date:   Wed Mar 29 17:38:22 2023 +0100

PR modula2/109336 - The -fmod= and -fdef= options do not work

The -fmod= and -fdef= options do not work.  After the linking
re-implementation and subsequent restructuring the -fmod= amd -fdef= are
now broken.  This patch adds -fmod= and -fdef= processing into gm2spec.cc.
It also reduces the complexity of extension handling within M2Search
by storing the preceeding "." in the extension.

gcc/m2/ChangeLog:

PR modula2/109336
PR modula2/109315
* gm2-compiler/M2FileName.mod (CalculateFileName): Simplified by
ensuring the extension contains the ".".
(CalculateStemName): Re-formatted.
(ExtractExtension): Re-formatted.
(ExtractModule): Re-formatted.
* gm2-compiler/M2Options.def (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Options.mod (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Search.mod (FindSourceDefFile): Use
DefaultDefExt.
(DefaultDefExt): New constant.
(DefaultModExt): New constant.
(FindSourceModFile): Use DefaultModExt.
* gm2-gcc/m2decl.cc (m2decl_DeclareKnownVariable): Correct
spelling.
* gm2spec.cc (M2SOURCE): New constant.
(LANGSPEC): New value.
(MATHLIB): New value.
(WITHLIBC): New value.
(SKIPOPT): New value.
(lang_specific_driver): Replace seen_module_extension bool with
module_extension char *.  Detect -fmod= and remember extension.
Use the extension to detect modula-2 source and mark it as such.

gcc/testsuite/ChangeLog:

PR modula2/109336
* gm2/link/nondefaultext/pass/hello.md: New test.
* gm2/link/nondefaultext/pass/liba.dm: New test.
* gm2/link/nondefaultext/pass/liba.md: New test.
* gm2/link/nondefaultext/pass/link-nondefaultext-pass.exp: New
test.

Signed-off-by: Gaius Mulley 

[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5

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

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

--- Comment #3 from Jakub Jelinek  ---
And the problem is similar to PR108605, most of IPA uses unsigned int as type
for byte offsets and while some spots check for offsets while bit offsets are
typically using HOST_WIDE_INT.  So, some larger bit offsets can't be
represented in unsigned int byte offset.

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #34 from Martin Uecker  ---
Created attachment 54787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54787=edit
patch for C FE to add size expressions to VM types in structs


Here is a preliminary patch for C FE just to see how this could work
look like VM-types in structs.

struct foo {
  int n;
  int (*buf)[.n];
};

It works with UBSan, but it isn't clear how this could pass the
information to the object size pass. This also does not work for
parameters: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334

So it seems for an attribute it might make sense to implement
it differently.

[Bug tree-optimization/109331] [13 Regression] ice: definition in block 7 does not dominate use in block 8

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |13.0
Summary|ice: definition in block 7  |[13 Regression] ice:
   |does not dominate use in|definition in block 7 does
   |block 8 |not dominate use in block 8

[Bug c++/109283] Destructor of co_yield conditional argument called twice

[ncm at cantrip dot org via Gcc-bugs]

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

--- Comment #2 from ncm at cantrip dot org ---
Betting this one is fixed by deleting code.

[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Slightly adjusted testcase:

struct __attribute__((packed)) A { char c1; short a1[__INT_MAX__]; };
struct __attribute__((packed)) B { char c2; short a2[100]; };
struct S { struct A p1; struct B p2[4]; };
void bar (short int);

static void
foo (struct S *q)
{
  for (int i = 0; i < q->p1.c1; i++)
for (int j = 0; j < q->p2[i].c2; j++)
  bar (q->p2[i].a2[j]);
}

int
main ()
{
  struct S q = {};
  q.p2[0].c2 = q.p2[1].c2 = 3;
  foo ();
}

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #27 from Jakub Jelinek  ---
Thanks.  It is a mystery so far :(.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #25 from Jakub Jelinek  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #24)
>> > --- Comment #23 from Jakub Jelinek  ---
>> [...]
>> So far, I've tried both variants and in each case, the comparison
>> failure is gone.
>
> Given that the reproducers weren't reliable, I'm afraid it would take at least
> 2-3
> runs to get something that says something.

indeed, even though so far following the exact same procedure has always
failed (or succeeded) in the same way.

> Anyway, as I said for the second version, it would be nice to also try
> subvariants:
[...]
> so see if the comparison failure is fixed by the result relayout, or by
> argument
> relayout or by the aggregate_value_p call actually having some side-effects
> other than return value.

I certainly plan to do so once the machine is idle again, probably tomorrow.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #25 from Jakub Jelinek  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #24)
> > --- Comment #23 from Jakub Jelinek  ---
> [...]
> > Perhaps try to undo my patch in a different way, like
> > --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> > +++ gcc/tree-inline.cc  2023-03-29 12:47:21.546947442 +0200
> > @@ -2785,7 +2785,7 @@ initialize_cfun (tree new_fndecl, tree c
> >gimple_register_cfg_hooks ();
> >
> >/* Get clean struct function.  */
> > -  push_struct_function (new_fndecl, true);
> > +  push_struct_function (new_fndecl, false);
> >targetm.target_option.relayout_function (new_fndecl);
> >
> >/* We will rebuild these, so just sanity check that they are empty.  */
> > or
> > --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> > +++ gcc/tree-inline.cc  2023-03-29 12:49:16.580255668 +0200
> > @@ -2786,7 +2786,11 @@ initialize_cfun (tree new_fndecl, tree c
> >
> >/* Get clean struct function.  */
> >push_struct_function (new_fndecl, true);
> > +  relayout_decl (DECL_RESULT (new_fndecl));
> > +  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
> > (parm))
> > +relayout_decl (parm);
> >targetm.target_option.relayout_function (new_fndecl);
> > +  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
> >
> >/* We will rebuild these, so just sanity check that they are empty.  */
> >gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
> > and see if that changes anything?  Of course both of those patches break the
> > PR105554
> > again.  Or if the latter helps, try to comment out the different parts of it
> > too.
> 
> So far, I've tried both variants and in each case, the comparison
> failure is gone.

Given that the reproducers weren't reliable, I'm afraid it would take at least
2-3
runs to get something that says something.
Anyway, as I said for the second version, it would be nice to also try
subvariants:
//  relayout_decl (DECL_RESULT (new_fndecl));
  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN (parm))
relayout_decl (parm);
  targetm.target_option.relayout_function (new_fndecl);
//  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
and
  relayout_decl (DECL_RESULT (new_fndecl));
//  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
(parm))
//relayout_decl (parm);
  targetm.target_option.relayout_function (new_fndecl);
//  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
and
//  relayout_decl (DECL_RESULT (new_fndecl));
//  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
(parm))
//relayout_decl (parm);
  targetm.target_option.relayout_function (new_fndecl);
  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
so see if the comparison failure is fixed by the result relayout, or by
argument
relayout or by the aggregate_value_p call actually having some side-effects
other than return value.

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723

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

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

--- Comment #8 from Jan Hubicka  ---
We have large-stack-frame-growth that is relative, so yes, increasing stack
size of caller makes gcc to think that it is heavy and making it event heavier
will not hurt that much.

We originally ran into stack size growth issues after implementing logic to
inline functions called once. In things like glibc printf where we ended up
inlining some exotic formater (as called once) that made the stack too large
for multithreaded apps.  Also sometimes we inlined some heavy function that is
off the hot path. While relative growth cap may not be best possible for all
cases, I can't think of reasonable way doing this better.

With the new code to determine basic blocks that are executed at every
execution of the function I plan to relax stack size limits a bit by bypassing
them when the call is known to be always allocated (and thus the stack will be
always taken)

This is also relatively common problem in Fortran where fortran IO (typically
done somewhere in debug code) tends to crate large on-stack structures
preventing inlining.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #23 from Jakub Jelinek  ---
[...]
> Perhaps try to undo my patch in a different way, like
> --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> +++ gcc/tree-inline.cc  2023-03-29 12:47:21.546947442 +0200
> @@ -2785,7 +2785,7 @@ initialize_cfun (tree new_fndecl, tree c
>gimple_register_cfg_hooks ();
>
>/* Get clean struct function.  */
> -  push_struct_function (new_fndecl, true);
> +  push_struct_function (new_fndecl, false);
>targetm.target_option.relayout_function (new_fndecl);
>
>/* We will rebuild these, so just sanity check that they are empty.  */
> or
> --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> +++ gcc/tree-inline.cc  2023-03-29 12:49:16.580255668 +0200
> @@ -2786,7 +2786,11 @@ initialize_cfun (tree new_fndecl, tree c
>
>/* Get clean struct function.  */
>push_struct_function (new_fndecl, true);
> +  relayout_decl (DECL_RESULT (new_fndecl));
> +  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
> (parm))
> +relayout_decl (parm);
>targetm.target_option.relayout_function (new_fndecl);
> +  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
>
>/* We will rebuild these, so just sanity check that they are empty.  */
>gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
> and see if that changes anything?  Of course both of those patches break the
> PR105554
> again.  Or if the latter helps, try to comment out the different parts of it
> too.

So far, I've tried both variants and in each case, the comparison
failure is gone.

> Seems there was some valgrind for SPARC Solaris out of tree, but can't find it
> anymore...

There was one back in the 2014-2017 timeframe, but the sources lived on
bitbucket and are gone, apparently.  The author (Ivo Raisr) since left
Oracle and works for RedHat/Prague AFAICT.  However, reviving that port
even if the sources were available would be a major feat.

[Bug modula2/109336] The -fmod= and -fdef= options do not work.

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-03-29

[Bug modula2/109336] New: The -fmod= and -fdef= options do not work.

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

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

Bug ID: 109336
   Summary: The -fmod= and -fdef= options do not work.
   Product: gcc
   Version: 13.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: ---

The -fmod= and -fdef= options do not work.  After the linking re-implementation
and subsequent restructuring the -fmod= amd -fdef= are now broken.

[Bug analyzer/109335] New: -Wanalyzer-malloc-leak false positives and false negatives

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

Bug ID: 109335
   Summary: -Wanalyzer-malloc-leak false positives and false
negatives
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: colomar.6.4.3 at gmail dot com
  Target Milestone: ---

Created attachment 54786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54786=edit
Preprocessed reproducer

Link:


With both GCC 12.2.0 (Debian), and GCC 13.0.1 20230315 (built from source),
I can reproduce these false positives.  I'm on Debian Sid with
libbsd-dev 0.11.7-4, and libc-dev 2.36-8.

The reproducer program is a small program that checks a password against a
hardcoded string, and conditionally prints "validated".  I wrote it
precisely to demonstrate how [[gnu::malloc(deallocator)]] can be used to
ensure that passwords are not leaked in memory, but I found out that it
fails to detect some conditions.

Here's the program (it uses agetpass(), as defined in the shadow project):

$ cat pass.c 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#define PASS_MAX  BUFSIZ - 1


#define MALLOCARRAY(n, type)   ((type *) mallocarray(n, sizeof(type)))


[[gnu::malloc, gnu::malloc(free)]] void *mallocarray(size_t nmemb, size_t
size);
void erase_pass(char *pass);
[[gnu::malloc(erase_pass)]] char *agetpass(const char *prompt);


void
do_work(void)
{
char  *pass;

pass = agetpass("Enter your password: ");
if (pass == NULL)
err(EXIT_FAILURE, "agetpass");

if (strcmp(pass, "secret") == 0)
puts("validated");

/* erase_pass() zeroes the memory (think of memset(3), or bzero(3))
   and then releases the memory to the system (think of free(3)).
   If you only call free(pass), then you release the memory to the
   system without zeroing it.  Remember it contains a password!
   We would be leaking a password into the system memory, which can
   later be assigned to a different process.

   So, we should call erase_pass() as soon as possible, but let's
   say we forgot, and just call free():
*/
#if defined(BUG_1)
// We forgot to zero the memory.
free(pass);
// GCC correctly catches this as -Wmismatched-dealloc
#elif defined(BUG_2)
// We zeroed, but forgot to free(3).
bzero(pass, PASS_MAX + 2);
// GCC misses this.
#elif defined(BUG_3)
// We forgot both of them.
// GCC also misses this.
#else
erase_pass(pass);  // OK, but 2 false positives.
#endif
}


int
main(void)
{
do_work();

for (;;)
sleep(1);
}


void *
mallocarray(size_t nmemb, size_t size)
{
return reallocarray(NULL, nmemb, size);
}


char *
agetpass(const char *prompt)
{
char*pass;
size_t  len;

pass = MALLOCARRAY(PASS_MAX + 2, char);
if (pass == NULL)
return NULL;

if (readpassphrase(prompt, pass, PASS_MAX + 2, RPP_REQUIRE_TTY) ==
NULL)
goto fail;

len = strlen(pass);
if (len == PASS_MAX + 1) {
errno = ENOBUFS;
goto fail;
}

return pass;

fail:
freezero(pass, PASS_MAX + 2);
return NULL;
}


void
erase_pass(char *pass)
{
freezero(pass, PASS_MAX + 2);
}



This shows the false positives:


$ cc -Wall -Wextra pass.c $(pkgconf --cflags --libs libbsd-overlay) -fanalyzer
-O3
pass.c: In function ‘agetpass’:
pass.c:84:12: warning: leak of ‘pass’ [CWE-401] [-Wanalyzer-malloc-leak]
   84 | if (pass == NULL)
  |^
  ‘do_work’: events 1-3
|
|   22 | do_work(void)
|  | ^~~
|  | |
|  | (1) entry to ‘do_work’
|..
|   26 | pass = agetpass("Enter your password: ");
|  |~
|  ||
|  |(2) allocated here
|  |(3) calling ‘agetpass’ from ‘do_work’
|
+--> ‘agetpass’: events 4-5
   |
   |   78 | agetpass(const char *prompt)
   |  | ^~~~
   |  | |
   |  | (4) entry to ‘agetpass’
   |..
   |   84 | if (pass == NULL)
   |  |~
   |  ||
   |  |(5) ‘pass’ leaks here; was allocated at (2)
   |
pass.c:91:12: warning: leak of ‘pass’ [CWE-401] [-Wanalyzer-malloc-leak]
   91 | if (len == PASS_MAX + 1) {
  |^
  ‘do_work’: events 1-3
|
|   22 | do_work(void)
|  | ^~~
|  | |
|  | (1) entry to ‘do_work’

[Bug target/109324] Genrecog reports "source missing a mode?" for H8

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
They can be muted by fixing the h8300/*.md...

[Bug c++/109319] [12/13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793 since r12-5510

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 54785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54785=edit
gcc13-pr109319.patch

Untested fix.

[Bug middle-end/106008] [11/12/13 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords|missed-optimization,|
   |needs-reduction |
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> # VUSE <.MEM_699>
> _109 = MEM[(struct loadcmd *)_106 + -56B].mapend;
> 
> my only suspicion is that we somehow isolate (and not optimize as
> unreachable)
> the nloadcmds < 1 case in the preceeding case.

Nope the statement we are diagnosing is guarded by nloadcmds > 1.

A reduced testcase looks like the following, needs -Os -fno-ivopts to
reproduce the diagnostics.  It is somewhat of a fundamental limit of
the analysis since when walking the virtual use-def chain we look for
aliases but q[-1] doesn't alias q[0] but when walking the backedge
we simply arrive at the very same stmt again and interpret it as if
it were within the same context.  That might also be a problem for
passes using walk_aliased_vdefs for other purposes than diagnostics.
I think that when walking a backedge walk_aliased_vdefs would need to
be more careful with interpreting the defs it runs into.

int foo (int n)
{
  int *p = __builtin_malloc (n);
  int nloadcmds = 0;
  int found = 0;
  do
{
  int *q = [nloadcmds++];
  *q = n;
  if (nloadcmds > 1
  && q[-1] != 7)
found = 1;
}
  while (nloadcmds < n);
  return found;
}

[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.2.0

--- Comment #4 from Richard Biener  ---
Earlier GCC were confused enough to not diagnose this, they have the same
missed-optimization.

[Bug bootstrap/109310] --enable-link-mutex is quite duplicate to --enable-link-serialization

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:8b2766e87dbf0d20808bc92d8e6ee7f876d19ab2

commit r13-6929-g8b2766e87dbf0d20808bc92d8e6ee7f876d19ab2
Author: Martin Liska 
Date:   Wed Mar 29 14:52:42 2023 +0200

configure: deprecate --enable-link-mutex option

PR bootstrap/109310

gcc/ChangeLog:

* configure.ac: Emit a warning for deprecated option
--enable-link-mutex.
* configure: Regenerate.

[Bug bootstrap/109310] --enable-link-mutex is quite duplicate to --enable-link-serialization

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-03-29
   Keywords||patch

--- Comment #2 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #1)
> So perhaps for GCC13 emit some kind of deprecation message for it and
> suggest using --enable-link-serialization instead and delete later?

Yes, I've just sent a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614841.html

[Bug sanitizer/109330] ASAN since GCC-9 missed a stack-use-after-scope at -O3

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
We completely eliminate usage of 'f' with -O3 and thus there's no ASAN report.
Note, clang does not emit an error even with -O2.

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #33 from Costas Argyris  ---
It should be noted that with the current implementation, windres (part of
binutils) is mandatory when building for the mingw (Windows) hosts, both 32 and
64-bit versions.

That is, a build failure will occur if windres is not found for the mingw
hosts.

This means that for these hosts, gcc will *always* be built with UTF-8 as its
active code page on Windows, thereby eliminating the need to have a way to
query the active code page as a user.

If for example, it could be built either with or without windres, then the
active code page would also be conditional on that, so users would need a way
to tell what is the active code page being used by a given gcc.exe or g++.exe
executable.By having windres be a mandatory build tool for the mingw hosts,
this is not a requirement because the answer will always be UTF-8 (otherwise
the build would have failed).

This is all relevant for gcc 13 or later (as per Target Milestone above) and a
minimum Windows Version 1903 (May 2019 Update).If gcc is 13 or later but
Windows version is earlier than the minimum target version, gcc will not be
using UTF-8 as its active code page on its own - it will still be possible to
make it though by applying the UTF-8 manifest with mt.exe manually, or by
checking the Windows checkbox that sets UTF-8 globally.

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #32 from Costas Argyris  ---
Followed by:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e70e36cbef4f01e7d32bafe17698c3bf3e4624b8

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #31 from Costas Argyris  ---
This was initially done only for the 64-bit mingw Windows host
(x86_64-*-mingw*).

This is the patch that extended it to the 32-bit version as well
(i[34567]86-*-mingw32*):

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=304c7d44a2212e6fd618587331cea2c266dc10bf

[Bug tree-optimization/109331] ice: definition in block 7 does not dominate use in block 8

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/109331] ice: definition in block 7 does not dominate use in block 8

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:86efc490ab86bfa00720479b4714da23cd7df797

commit r13-6928-g86efc490ab86bfa00720479b4714da23cd7df797
Author: Richard Biener 
Date:   Wed Mar 29 11:59:16 2023 +0200

tree-optimization/109331 - make sure to clean up the CFG after forwprop

When forwprop discovers unreachable code or makes decisions based
on unreachable edges make sure to cleanup the CFG since otherwise
SSA form can become invalid.

PR tree-optimization/109331
* tree-ssa-forwprop.cc (pass_forwprop::execute): When we
discover a taken edge make sure to cleanup the CFG.

* gcc.dg/torture/pr109331.c: New testcase.

[Bug c++/109319] [12/13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793 since r12-5510

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[13 Regression] ICE in  |[12/13 Regression] ICE in
   |build_min_non_dep_op_overlo |build_min_non_dep_op_overlo
   |ad, at cp/tree.cc:3793  |ad, at cp/tree.cc:3793
   ||since r12-5510

--- Comment #3 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #2)
> With release checking I see

Those are two separate testcases which just differ in 0,1 vs. 1,0.

Anyway, adjusted testcase so that it isn't so invalid:
struct S
{
  static int [] (int x) { static int a[2]; return a[x]; }
};

template 
int
foo ()
{
  S s;
  ++s[0, 1];
  return 0;
}
and without the template  line is accepted with a pedwarn.
And, if it is changed to:
struct S
{
  int [] (int x) { static int a[2]; return a[x]; }
};

template 
int
foo ()
{
  S s;
  ++s[0, 1];
  return 0;
}
then it is also accepted with pedwarn without the template  line and
otherwise ICEs already starting with r12-5510-gb38c9cf6d570f6.

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

--- Comment #24 from Richard Biener  ---
Created attachment 54784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54784=edit
another hack