[Bug c++/104672] New: C++ frontend failing when function pointer argument types contain a parameter pack

[eliphat at sjtu dot edu.cn via Gcc-bugs]

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

Bug ID: 104672
   Summary: C++ frontend failing when function pointer argument
types contain a parameter pack
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eliphat at sjtu dot edu.cn
  Target Milestone: ---

Here are two examples where GCC 11.2 fails but clang and msvc works:
```cpp
void test(int a, int* b) {
*b = a;
}

template
inline void test_template(
void (*func)(argT..., int*)
) {}

int main() {
test_template(test);
}

```

```cpp
void test(int a, int* b) {
*b = a;
}
template
using FuncT = void (*)(argT..., int*);

template
inline void test_template(
FuncT func
) {}

int main() {
FuncT test_func = test;
test_template(test_func);
}

```

[Bug target/104666] [12 Regression] ICE in related_vector_mode, at stor-layout.c:537

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
Same ICE exists for

__builtin_ia32_blendvpd
__builtin_ia32_blendvps
__builtin_ia32_blendvpd256
__builtin_ia32_blendvps256
__builtin_ia32_pblendvb128
__builtin_ia32_pblenddvb256

[Bug target/104666] [12 Regression] ICE in related_vector_mode, at stor-layout.c:537

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> So builtins are registered in the beginning, but isa checking is during
> pass_expand, and gimple folding is between them, maybe we should restrict
> builtin gimple folding under their required target.

I'm testing this.

+ /* Avoid ICE in get_same_size_vectype which assumes real vector
+mode, and it depends on vector_mode_supported_p, E_BLKmode
+means target isa mismatch.  */
+ if (TYPE_MODE (type) == E_BLKmode)
+   break;

[Bug target/104610] memcmp () == 0 can be optimized better for avx512f

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

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

--- Comment #11 from H.J. Lu  ---
Don't worry about vzeroupper.
It's ok to have vzeroupper.

[Bug target/104610] memcmp () == 0 can be optimized better for avx512f

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---
(In reply to H.J. Lu from comment #9)
> ix86_gen_scratch_sse_rtx was added to prevent combine from changing
> store of vector registers with constant value to store of constant
> value.  You can change ix86_gen_scratch_sse_rtx to return a pseudo
> register and watch the regressions in GCC testsuite.  If we can fix
> these regressions, ix86_gen_scratch_sse_rtx isn't needed.

it regresses, i'm thinking of add a peephole2 to split mov mem to mov + movd +
shufd which can prevent regression for pr100865, and for vzeroupper, i don't
have a good way to avoid those regressions.

gcc.target/i386/pr100865-11b.c scan-assembler-times vmovdqa64[\\t ]%xmm[0-9]+, 
16
gcc.target/i386/pr100865-12b.c scan-assembler-times vmovdqa64[\\t ]%xmm[0-9]+, 
16
gcc.target/i386/pr100865-8a.c scan-assembler-times (?:vpbroadcastd|vpshufd)[\\t
]+[^\n]*, %xmm[0-9]+ 1
gcc.target/i386/pr100865-8b.c scan-assembler-times vmovdqa64[\\t ]%xmm[0-9]+, 
16
gcc.target/i386/pr100865-8c.c scan-assembler-times vpshufd[\\t ]+[^\n]*,
%xmm[0-9]+ 1
gcc.target/i386/pr100865-9b.c scan-assembler-times vmovdqa64[\\t ]%xmm[0-9]+, 
16
gcc.target/i386/pr100865-9c.c scan-assembler-times vpshufd[\\t ]+[^\n]*,
%xmm[0-9]+ 1
gcc.target/i386/pr82941-1.c scan-assembler-not vzeroupper
gcc.target/i386/pr82942-1.c scan-assembler-not vzeroupper
gcc.target/i386/pr82990-1.c scan-assembler-not vzeroupper
gcc.target/i386/pr82990-3.c scan-assembler-not vzeroupper
gcc.target/i386/pr82990-5.c scan-assembler-not vzeroupper

[Bug target/104663] [12 Regression] C-ray 1.1 performance is 50% worse at -O2 in GCC 12 than before on alderlake

[aros at gmx dot com via Gcc-bugs]

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

--- Comment #3 from Artem S. Tashkinov  ---
Also -O3 is 50% faster which sounds unreasonable.

-O2 with GCC12 is 75% slower than -O3 for GCC 11.

[Bug target/103353] Indefinite recursion when compiling -mmma requiring testcase w/ -maltivec

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #6 from Arseny Solokha  ---
*** Bug 101323 has been marked as a duplicate of this bug. ***

[Bug target/101323] ICE: Segmentation fault signal terminated program cc1

[asolokha at gmx dot com via Gcc-bugs]

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

Arseny Solokha  changed:

   What|Removed |Added

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

--- Comment #3 from Arseny Solokha  ---
It turns out I've reported it more than once.

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

[Bug target/104666] [12 Regression] ICE in related_vector_mode, at stor-layout.c:537

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
So builtins are registered in the beginning, but isa checking is during
pass_expand, and gimple folding is between them, maybe we should restrict
builtin gimple folding under their required target.

[Bug target/104671] -Wa,-m no longer has any effect

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Nicholas Piggin from comment #1)
> The comment in recent binutils.git commit cebc89b9328 sheds some more light
> on this and possibly provides a workaround in binutils for the errant
> .machine directive.

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=cebc89b9328
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b25f942e18d6

> 
> The referenced gcc bug #101393 looks like it was proposed to remove .machine
> but I'm not entirely sure it was also talking about other things, and that
> hasn't been resolved.

[Bug c/104671] -Wa,-m no longer has any effect

[npiggin at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Nicholas Piggin  ---
The comment in recent binutils.git commit cebc89b9328 sheds some more light on
this and possibly provides a workaround in binutils for the errant .machine
directive.

The referenced gcc bug #101393 looks like it was proposed to remove .machine
but I'm not entirely sure it was also talking about other things, and that
hasn't been resolved.

[Bug c/104671] New: -Wa,-m no longer has any effect

[npiggin at gmail dot com via Gcc-bugs]

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

Bug ID: 104671
   Summary: -Wa,-m no longer has any effect
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npiggin at gmail dot com
CC: amodra at gcc dot gnu.org, bergner at gcc dot gnu.org,
dje at gcc dot gnu.org, meissner at gcc dot gnu.org, pc at 
us dot ibm.com,
segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---

Commit e154242724b084380e3221df7c08fcdbd8460674 ("Don't pass -many to the
assembler") also added a workaround emitting a ".machine" directive to the top
of each generated .s file corresponding to -mcpu= option, to work around buggy
build code which uses incorrect -Wa,-mcpu options:

  This patch also emits .machine assembler directives for ELF targets
  when functions are compiled for different cpus via attributes or
  pragmas.  That's necessary when the initial -m option passed to
  the assembler doesn't enable the superset of all opcodes emitted, as
  seen by a failure of gcc.target/powerpc/clone2.c without .machine
  when building gcc for power8.

This also prevents passing a -m to the assembler which is a strict
superset of the -mcpu= generated code.

This is a valid situation where .c code is built with a baseline architecture
compatibility plus dynamic support for newer instructions with inline asm. The
Linux kernel extensively uses this pattern.

[Bug target/104666] [12 Regression] ICE in related_vector_mode, at stor-layout.c:537

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
Probably caused by my r12-1834

[Bug target/102485] -Wa,-many no longer has any effect

[npiggin at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Nicholas Piggin  ---
And upstream gas still doesn't even warn with -many!!

[Bug target/102485] -Wa,-many no longer has any effect

[npiggin at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Nicholas Piggin  ---
(In reply to Segher Boessenkool from comment #7)
> > GCC already passes -m to the assembler though.
> 
> That mostly is historic.

So? I was pointing out the compiler already tells the assembler what
instruction set to use without the .machine directive.

> 
> > The justification for emitting the .machine directive is given as fixing a
> > build breakage due to a build system that passes an incorrect -m to the
> > assembler.
> 
> Not really, no. 

That is really the justification for emitting the .machine directive as
provided in the changelog of the commit which introduced the change.

> That is just one tiny part of the problem.  It is impossible
> to know what instruction sets we need ahead of time, and -many cannot work
> (and
> *does not* work: there are quite a few mnemonics that encode to different
> insns
> on different architecture versions (or for different CPUs), and we cannot
> know
> which is wanted, or which is preferred, ahead of time.

I understand the problems with -many, but it can and does work for real
software. E.g., Linux kernel as of before this change. It's not -many I'm
wedded to though, it's any ability to fix this sanely because of the .machine
directive.

The kernel should would change to using a specific CPU, e.g., -mcpu=power4
-Wa,-mpower10 and deal with the very rare few clashing mnemonics (e.g., tlbie)
specially with the .machine directive when an older one is required.

> 
> > *That* is the broken code (if any) that should have been fixed. But instead
> > that is hacked around in a way that breaks working code that passes down
> > -Wa,-many option as specified.
> 
> There is no working code that uses -many (accept by accident, if no problem
> has hit you yet).

I'll reword. "Instead that is hacked around in a way that breaks working code
that passes down the -Wa,-m option as specified."

> 
> > The kernel builds with a base compatibility (say -mcpu=power4) and then has
> > certain code paths that are dynamically taken if running on newer CPUs which
> > use newer instructions with inline asm.
> > 
> > This is an important usage and it's pervasive, it seems unreasonable to
> > break it.  Adding .machine directives throughout inline asm for every
> > instruction not in the base compatibility class is pretty horrible.
> 
> It is the only correct thing to do.

It's not. Not passing .machine and passing -mcpu is just as correct. With the
added bonus that it allows software to use a superset of instructions in such
cases. And even the great bonus that existing "broken" code that uses -many
will continue to work.

The correct way to deal with this is not to break this, it is to add a warning
to -many for some period to binutils to give code a chance to migrate. I'm all
for removing -many, and that is the right way to do it. By deprecating -many
and providing warnings. Not by hacking around it in the compiler that breaks
things.

[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris

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

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

--- Comment #8 from Jonathan Wakely  ---
Oh dear, yes, wrong patch. I'll attach the right one in a few hours.

[Bug c++/104642] Add __builtin_trap() for missing return at -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
Confirmed,

[Bug target/103196] [12 regression] gcc.target/powerpc/p9-vec-length-full-7.c

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

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

Kewen Lin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 CC||linkw at gcc dot gnu.org

--- Comment #2 from Kewen Lin  ---
I'll have a look.

[Bug preprocessor/104640] incomplete unicode support for User-defined literals

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug c++/98202] C++ cannot parse F128 suffix for float128 literals

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Isn't this a dup of bug 87274 ?

[Bug analyzer/104434] Analyzer doesn't know about "pure" and "const" functions

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by the above commit for GCC 12.

[Bug analyzer/104434] Analyzer doesn't know about "pure" and "const" functions

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-7364-gaee1adf2cdc1cf4e116e5c05b6e7c92b0fbb264b
Author: David Malcolm 
Date:   Wed Feb 23 09:14:58 2022 -0500

analyzer: handle __attribute__((const)) [PR104434]

When testing -fanalyzer on openblas-0.3, I noticed slightly over 2000
false positives from -Wanalyzer-malloc-leak on code like this:

if( LAPACKE_lsame( vect, 'b' ) || LAPACKE_lsame( vect, 'p' ) ) {
pt_t = (lapack_complex_float*)
LAPACKE_malloc( sizeof(lapack_complex_float) *
ldpt_t * MAX(1,n) );
[...snip...]
}

[...snip lots of code...]

if( LAPACKE_lsame( vect, 'b' ) || LAPACKE_lsame( vect, 'q' ) ) {
LAPACKE_free( pt_t );
}

where LAPACKE_lsame is a char-comparison function implemented in a
different TU.
The analyzer naively considers the execution path where:
  LAPACKE_lsame( vect, 'b' ) || LAPACKE_lsame( vect, 'p' )
is true at the malloc guard, but then false at the free guard, which
is thus a memory leak.

This patch makes -fanalyer respect __attribute__((const)), so that the
analyzer treats such functions as returning the same value when given
the same inputs.

I've filed https://github.com/xianyi/OpenBLAS/issues/3543 suggesting that
LAPACKE_lsame be annotated with __attribute__((const)); with that, and
with this patch, the false positives seem to be fixed.

gcc/analyzer/ChangeLog:
PR analyzer/104434
* analyzer.h (class const_fn_result_svalue): New decl.
* region-model-impl-calls.cc (call_details::get_manager): New.
* region-model-manager.cc
(region_model_manager::get_or_create_const_fn_result_svalue): New.
(region_model_manager::log_stats): Log
m_const_fn_result_values_map.
* region-model.cc (const_fn_p): New.
(maybe_get_const_fn_result): New.
(region_model::on_call_pre): Handle fndecls with
__attribute__((const)) by calling the above rather than making
a conjured_svalue.
* region-model.h (visitor::visit_const_fn_result_svalue): New.
(region_model_manager::get_or_create_const_fn_result_svalue): New
decl.
(region_model_manager::const_fn_result_values_map_t): New typedef.
(region_model_manager::m_const_fn_result_values_map): New field.
(call_details::get_manager): New decl.
* svalue.cc (svalue::cmp_ptr): Handle SK_CONST_FN_RESULT.
(const_fn_result_svalue::dump_to_pp): New.
(const_fn_result_svalue::dump_input): New.
(const_fn_result_svalue::accept): New.
* svalue.h (enum svalue_kind): Add SK_CONST_FN_RESULT.
(svalue::dyn_cast_const_fn_result_svalue): New.
(class const_fn_result_svalue): New.
(is_a_helper ::test): New.
(template <> struct
default_hash_traits):
New.

gcc/testsuite/ChangeLog:
PR analyzer/104434
* gcc.dg/analyzer/attr-const-1.c: New test.
* gcc.dg/analyzer/attr-const-2.c: New test.
* gcc.dg/analyzer/attr-const-3.c: New test.
* gcc.dg/analyzer/pr104434-const.c: New test.
* gcc.dg/analyzer/pr104434-nonconst.c: New test.
* gcc.dg/analyzer/pr104434.h: New test.

Signed-off-by: David Malcolm 

[Bug target/104663] [12 Regression] C-ray 1.1 performance is 50% worse at -O2 in GCC 12 than before on alderlake

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-02-23
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Andrew Pinski  ---
Someone is going to need to anlysis this. I suspect -fno-tree-vectorize gets
the performance back. This would mean most likely a cost model issue.

[Bug target/104663] A 50% C-Ray regression in GCC 12.0 for ADL at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
   Keywords||missed-optimization
   Target Milestone|--- |12.0

[Bug target/104335] [12 regression] build failure if go is included in languages after r12-6747

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

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

Michael Meissner  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #10 from Michael Meissner  ---
*** Bug 104256 has been marked as a duplicate of this bug. ***

[Bug target/104256] ICE in validate_condition_mode, at config/rs6000/rs6000.cc:11354

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

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

Michael Meissner  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Michael Meissner  ---
The fix for 104335 also fixes PR target/104256.

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

[Bug testsuite/102719] [12 regression] several failures after r12-4337

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

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

pc at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from pc at gcc dot gnu.org ---
Fixed with noted commits.

[Bug c++/104661] [C++17+] Catching exception by const value when exception-object has lvalue-reference constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103048
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-23

--- Comment #2 from Andrew Pinski  ---
Confirmed, related to PR 103048.

[Bug c++/104661] [C++17+] Catching exception by const value when exception-object has lvalue-reference constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Catching exception by const |[C++17+] Catching exception
   |value when exception-object |by const value when
   |has lvalue-reference|exception-object has
   |constructor |lvalue-reference
   ||constructor

--- Comment #1 from Andrew Pinski  ---
Note clang accepts the code only with -std=c++17 and -std=c++20 as you didn't
mention in the bug report as you passing. C++17 changed some rules and all.

[Bug target/104664] ICE: in extract_constrain_insn, at recog.cc:2670 (insn does not satisfy its constraints) with -Og -ffinite-math-only

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/104665] Failure to recognize memcpy

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-23
   Severity|normal  |enhancement
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
A couple of reasons.
First is store merging happens too late.
Second reason is store merging does not work in the loop case.

Take:
#if 1
enum b : unsigned char{};
#else
typedef unsigned char b;
#endif

void serialize_le(b* __restrict dst, const unsigned* __restrict src)
{
   // for (int i = 0; i < 128; ++i, ++src)
{
unsigned t = *src;
*dst++ = static_cast((t >>  0) & 0xff);
*dst++ = static_cast((t >>  8) & 0xff);
*dst++ = static_cast((t >> 16) & 0xff);
*dst++ = static_cast((t >> 24) & 0xff);
}
}

This gets optimized to one load followed by one store. But once you add the
loop, and use -fno-tree-vectorize (because GCC's vectorizer gets kicked in
which causes other issues), the stores are not merged into one.

Also store merging happens way after loop distrubution happens so ...

[Bug tree-optimization/104657] array subscript 0 is outside array bounds

[christophm30 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Christoph Müllner  ---
Creating hard-wired object references might be a solution, but there is a lot
of existing code out there, that would need to be patched (including all the
hassle with support for old and new compilers).

One example is the bootloader U-Boot, which does the following for ARM ([1]):
#define __arch_putl(v,a)(*(volatile unsigned int *)(a) = (v))

Another example is Linux, where read*()/write*() and friends do the following
([2]):
# define __iomem
void foo_linux(unsigned long v)
{
void __iomem *p = (void __iomem *)MEM_ADDR;
*(volatile unsigned long *)p = v;
}

FWIW, the __iomem expands in Linux as follows ([3]), if the sources are passed
to the semantic parser "sparse" ([4]):
# define __iomem__attribute__((noderef, address_space(__iomem)))
That's similar to the AVR solution but allows to create user-defined distinct
types.

[1]
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/include/asm/io.h#L50
[2]
https://elixir.bootlin.com/linux/latest/source/include/asm-generic/io.h#L125
[3]
https://elixir.bootlin.com/linux/latest/source/include/linux/compiler_types.h#L11
[4]
https://git.kernel.org/pub/scm/devel/sparse/sparse.git/tree/Documentation/annotations.rst

[Bug fortran/84519] [F2018] STOP and ERROR STOP statements with QUIET specifier

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Patch submitted:
https://gcc.gnu.org/pipermail/fortran/2022-February/057588.html

[Bug tree-optimization/104657] array subscript 0 is outside array bounds

[christophm30 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Christoph Müllner  ---
Thanks for mentioning the volatile pointer method.
However, the pragma-solution results in better code (fewer instructions and
does not require a valid stack pointer).

I've used the code below to see what happens on AArch64 and RISC-V 64-bit:
#define MEM_ADDR 0x8000
void foo_warning(unsigned long v)
{
volatile unsigned long * p;
p = (void*)MEM_ADDR;
*p = v;
}

void foo_warningfree(unsigned long v)
{
volatile unsigned long * p;
p = (void*)MEM_ADDR;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Warray-bounds"
*p = v;
#pragma GCC diagnostic pop
}

void foo_volatile(unsigned long v)
{
volatile unsigned long * volatile p;
p = (void*)MEM_ADDR;
*p = v;
}

AArch64:
foo_warning:
mov x1, 4294934528
str x0, [x1]
ret
foo_warningfree:
mov x1, 4294934528
str x0, [x1]
ret
foo_volatile:
sub sp, sp, #16
mov x1, 4294934528
str x1, [sp, 8]
ldr x1, [sp, 8]
str x0, [x1]
add sp, sp, 16
ret

RISC-V 64-bit:
foo_warning:
li  a5,536866816
sllia5,a5,3
sd  a0,0(a5)
ret
foo_warningfree:
li  a5,536866816
sllia5,a5,3
sd  a0,0(a5)
ret
foo_volatile:
li  a5,536866816
addisp,sp,-16
sllia5,a5,3
sd  a5,8(sp)
ld  a5,8(sp)
sd  a0,0(a5)
addisp,sp,16
jr  ra

[Bug c++/104669] [11/12 Regression] ICE in is_function_default_version, at attribs.cc:1219

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code,
   ||ice-on-valid-code

--- Comment #2 from Andrew Pinski  ---
Note here is the valid C++ code:
void bar()
{
  int foo(void);
  int foo(void) __attribute__((target("sse")));
  int foo(void) __attribute__((target("default")));
  int (*p)(void) = 
  return;
}

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

[barry.revzin at gmail dot com via Gcc-bugs]

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #8 from Barry Revzin  ---
Here's an example:

struct A { int i; };
struct B { int i{}; };

Both are trivially copyable, A is additionally trivially default constructible
while B is not. This distinction is irrelevant in this case - we're copying,
and that does not involve default constructing an A or B (trivial or
otherwise).

But this means that __is_trivial(B) is false, so we don't go into std::copy, so
these do different things:

#include 

struct A { int i; };
struct B { int i{}; };

void copy_a(A* f, A* l, A* out) {
std::uninitialized_copy(f, l, out);
}

void copy_b(B* f, B* l, B* out) {
std::uninitialized_copy(f, l, out);
}

emits (with g++ 11.2, -std=c++20 -O3, https://godbolt.org/z/eG9hsbcTE):

copy_a(A*, A*, A*):
mov r8, rdi
mov rdi, rdx
cmp r8, rsi
je  .L1
mov rdx, rsi
mov rsi, r8
sub rdx, r8
jmp memmove
.L1:
ret
copy_b(B*, B*, B*):
cmp rdi, rsi
je  .L4
sub rsi, rdi
xor eax, eax
.L6:
mov ecx, DWORD PTR [rdi+rax]
mov DWORD PTR [rdx+rax], ecx
add rax, 4
cmp rax, rsi
jne .L6
.L4:
ret

Whereas the copy_b case could also use memmove.

[Bug tree-optimization/102232] Missed arithmetic fold

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0
 CC||roger at nextmovesoftware dot 
com

--- Comment #9 from Roger Sayle  ---
This is fixed on mainline; the godbolt link in comment #1 shows that GCC now
generates the same code for all three functions.

[Bug c++/104670] ICE when using decltype of a lambda returning a struct inside of a struct

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=39751
   Keywords||error-recovery,
   ||ice-checking,
   ||ice-on-invalid-code

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

[Bug analyzer/104434] Analyzer doesn't know about "pure" and "const" functions

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

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

--- Comment #3 from David Malcolm  ---
OpenBLAS issue filed as https://github.com/xianyi/OpenBLAS/issues/3543
suggesting the use of __attribute__((const)) on LAPACKE_lsame.

[Bug target/104610] memcmp () == 0 can be optimized better for avx512f

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #9 from H.J. Lu  ---
ix86_gen_scratch_sse_rtx was added to prevent combine from changing
store of vector registers with constant value to store of constant
value.  You can change ix86_gen_scratch_sse_rtx to return a pseudo
register and watch the regressions in GCC testsuite.  If we can fix
these regressions, ix86_gen_scratch_sse_rtx isn't needed.

[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris

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

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

--- Comment #7 from Rainer Orth  ---
EWRONGPATCH?  I'll give it a whirl on both 11.3 and 11.4 then.

[Bug target/102953] Improvements to CET-IBT and ENDBR generation

[andrew.cooper3 at citrix dot com via Gcc-bugs]

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

--- Comment #25 from Andrew Cooper  ---
(In reply to H.J. Lu from comment #24)
> (In reply to Andrew Cooper from comment #23)
> > Apologies for the delay, but I do now have a working prototype of Xen with
> > CET-IBT active, using the current version of these patches.
> > 
> > The result actually builds back to older versions of GCCs, but the lack of
> > cf_check-ness typechecking makes this a fragile activity.
> 
> Should I polish my patches and submit them now?

Sorry - I missed this request.  Yes please.  These changes have been used for a
while now with no issues identified.

[Bug c++/104670] ICE when using decltype of a lambda returning a struct inside of a struct

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

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

--- Comment #1 from Andrew Pinski  ---
(In reply to krzysio.kurek from comment #0)
> Compiled with `-std=c++20`
> Past stable releases of GCC report "confused by earlier errors, bailing out"
> without crashing instead.

Right. That means it was an internal compiler error after an error message.
That happens with released gcc where gcc is configured by default to
--enable-checking=release .
So this is not a regression.

[Bug target/95082] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

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

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

Bill Schmidt  changed:

   What|Removed |Added

  Known to fail|11.0|
Summary|[11] LE implementations of  |LE implementations of
   |vec_cnttz_lsbb and  |vec_cnttz_lsbb and
   |vec_cntlz_lsbb are wrong|vec_cntlz_lsbb are wrong

--- Comment #10 from Bill Schmidt  ---
>From some private discussion today, this goes back quite some ways, and we're
simply going to document this as a change in behavior.  The old behavior was
wrong and usage of these built-ins is not very prevalent.  We'll make a point
of this change in the release notes, rather than do any backports.

[Bug c++/104670] New: ICE when using decltype of a lambda returning a struct inside of a struct

[krzysio.kurek at wp dot pl via Gcc-bugs]

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

Bug ID: 104670
   Summary: ICE when using decltype of a lambda returning a struct
inside of a struct
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krzysio.kurek at wp dot pl
  Target Milestone: ---

Created attachment 52502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52502=edit
-freport-bug output

GCC ICEs when compiling the following piece of code:

struct foo {
decltype([] { return (struct {
int fn() {}
}){}; }) bar;
};

Compiled with `-std=c++20`
Past stable releases of GCC report "confused by earlier errors, bailing out"
without crashing instead.

[Bug c++/104669] [11/12 Regression] ICE in is_function_default_version, at attribs.cc:1219

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |11.3
   Last reconfirmed||2022-02-23
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Started with r11-7693.

commit 1c7bec8bfbc5457c1b57d0e3b67f5d6bc8812e57
Author: Martin Liska 
Date:   Wed Mar 3 09:38:55 2021 +0100

c++: support target attr for DECL_LOCAL_DECL_P fns [PR99108]

We crash when target attribute get_function_versions_dispatcher is called
for a function that is not registered in call graph.  This was happening
because we were calling it for the function-local decls that aren't in the
symbol table, instead of the corresponding namespace-scope decls that are.

gcc/cp/ChangeLog:

PR c++/99108
* call.c (get_function_version_dispatcher): Handle
DECL_LOCAL_DECL_P.
* decl.c (maybe_version_functions): Likewise.
(maybe_mark_function_versioned): New.
* name-lookup.c (push_local_extern_decl_alias): No longer static.
* name-lookup.h (push_local_extern_decl_alias): Adjust.

gcc/testsuite/ChangeLog:

PR c++/99108
* g++.target/i386/pr99108.C: New test.

Co-authored-by: Jason Merrill 

[Bug c++/104668] [12 Regression] ICE in lookup_attribute_spec, at attribs.cc:425

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
   Priority|P3  |P2
   Last reconfirmed||2022-02-23

--- Comment #1 from Marek Polacek  ---
Started with r12-6904.

[Bug c/89408] No constant folding when dereferencing string literals

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #6 from joseph at codesourcery dot com  ---
Case labels are required to be integer constant expressions.  In most 
cases where an integer constant expression is required, something that 
isn't an integer constant expression but folds to an integer constant is 
accepted with a pedwarn-if-pedantic (see c-typeck.cc:do_case for this in 
the case of case labels, where the diagnostic is "case label is not an 
integer constant expression").  *But* note that this is mainly for 
compatibility with pre-GCC-4.5 code depending on folding that occurred 
before GCC 4.5; as I said in 
, it's not any 
sort of designed, documented extension with stable semantics that it would 
be a good idea to use.

[Bug fortran/104619] [10/11/12 Regression] ICE on list comprehension with default derived type constructor

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12 and on affected branches.  Closing.

Thanks for the report!

[Bug fortran/104619] [10/11/12 Regression] ICE on list comprehension with default derived type constructor

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:251061b82852bdebc6f13510b415ecb73a2f80ae

commit r10-10474-g251061b82852bdebc6f13510b415ecb73a2f80ae
Author: Harald Anlauf 
Date:   Mon Feb 21 22:49:05 2022 +0100

Fortran: skip compile-time shape check if constructor shape is not known

gcc/fortran/ChangeLog:

PR fortran/104619
* resolve.c (resolve_structure_cons): Skip shape check if shape
of constructor cannot be determined at compile time.

gcc/testsuite/ChangeLog:

PR fortran/104619
* gfortran.dg/derived_constructor_comps_7.f90: New test.

(cherry picked from commit bc66b471d16ef2fd8cb66fd1131b41f80ecb9961)

[Bug fortran/104619] [10/11/12 Regression] ICE on list comprehension with default derived type constructor

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-9618-gd86949f5f55dbe0eb6f3044366101605882cd58e
Author: Harald Anlauf 
Date:   Mon Feb 21 22:49:05 2022 +0100

Fortran: skip compile-time shape check if constructor shape is not known

gcc/fortran/ChangeLog:

PR fortran/104619
* resolve.c (resolve_structure_cons): Skip shape check if shape
of constructor cannot be determined at compile time.

gcc/testsuite/ChangeLog:

PR fortran/104619
* gfortran.dg/derived_constructor_comps_7.f90: New test.

(cherry picked from commit bc66b471d16ef2fd8cb66fd1131b41f80ecb9961)

[Bug tree-optimization/104515] [11/12 Regression] trivially-destructible destructors interfere with loop optimization - maybe related to lifetime-dse.

[gcc at rabensky dot com via Gcc-bugs]

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

--- Comment #4 from GBE  ---
The commit that make this issue affect "basic types" as well:

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=e443d821386

[Bug tree-optimization/104657] array subscript 0 is outside array bounds

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
An alternate way of avoiding the warning in cases when the code is safe is to
make the pointer itself volatile, e.g., as below.  The codegen impact should be
negligible (an extra instruction on x86_.

static volatile unsigned long * const volatile p0x8 = (void*)8;

void bar(unsigned long v)
{
*p0x8 = v;
}

As I mentioned in bug  99578 comment 25, on the AVR target GCC supports
attribute address which can be used to pin a declared object to a hardwired
address like so:

void bar(unsigned long v)
{
extern volatile unsigned long x0x8 __attribute__ ((address (0x8)));

x0x8 = v;
}

This avoids the warning and emits object code that's equivalent to the
original.

[Bug target/102976] MMA test case emits wrong code when building a vector pair

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #5 from Peter Bergner  ---
Fixed everywhere.

[Bug target/104663] A 50% C-Ray regression in GCC 12.0 for ADL at -O2

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

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

--- Comment #1 from Andrew Pinski  ---
My bet is this is because the vectorizer is enabled now at -O2.

[Bug c++/104667] [10/11/12 Regression] ICE in is_late_template_attribute, at cp/decl2.cc:1299

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Priority|P3  |P2
   Keywords||ice-on-valid-code
 Status|NEW |ASSIGNED

--- Comment #2 from Marek Polacek  ---
I think I have a fix.

[Bug c++/104667] [10/11/12 Regression] ICE in is_late_template_attribute, at cp/decl2.cc:1299

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-23
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |10.4
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed, started with r10-4929-g54aa6b58fe2fe73bbe67e0485777e0c410a18673

[Bug c++/104669] New: [11/12 Regression] ICE in is_function_default_version, at attribs.cc:1219

[gscfq--- via Gcc-bugs]

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

Bug ID: 104669
   Summary: [11/12 Regression] ICE in is_function_default_version,
at attribs.cc:1219
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210314 and 20210328 :


$ cat z1.cc
void bar()
{
  int foo();
  int foo() __attribute__((target("sse")));
  int foo() __attribute__((target("avx")));
  int (*p)() = 
  return;
}


$ g++-12-20220220 -c z1.cc
z1.cc: In function 'void bar()':
z1.cc:3:10: warning: empty parentheses were disambiguated as a function
declaration [-Wvexing-parse]
3 |   int foo();
  |  ^~
z1.cc:3:10: note: remove parentheses to default-initialize a variable
3 |   int foo();
  |  ^~
  |  --
z1.cc:3:10: note: or replace parentheses with braces to value-initialize a
variable
z1.cc:4:10: warning: empty parentheses were disambiguated as a function
declaration [-Wvexing-parse]
4 |   int foo() __attribute__((target("sse")));
  |  ^~
z1.cc:4:10: note: remove parentheses to default-initialize a variable
4 |   int foo() __attribute__((target("sse")));
  |  ^~
  |  --
z1.cc:4:10: note: or replace parentheses with braces to value-initialize a
variable
z1.cc:5:10: warning: empty parentheses were disambiguated as a function
declaration [-Wvexing-parse]
5 |   int foo() __attribute__((target("avx")));
  |  ^~
z1.cc:5:10: note: remove parentheses to default-initialize a variable
5 |   int foo() __attribute__((target("avx")));
  |  ^~
  |  --
z1.cc:5:10: note: or replace parentheses with braces to value-initialize a
variable
z1.cc:6:17: internal compiler error: in is_function_default_version, at
attribs.cc:1219
6 |   int (*p)() = 
  | ^~~
0x89edb3 is_function_default_version(tree_node*)
../../gcc/attribs.cc:1219
0x115c284 ix86_get_function_versions_dispatcher(void*)
../../gcc/config/i386/i386-features.cc:2770
0x6ce48b get_function_version_dispatcher(tree_node*)
../../gcc/cp/call.cc:8836
0x6e7057 resolve_address_of_overloaded_function
../../gcc/cp/class.cc:8607
0x6cfa8d standard_conversion
../../gcc/cp/call.cc:1227
0x6d1d4d implicit_conversion_1
../../gcc/cp/call.cc:2031
0x6d1d4d implicit_conversion
../../gcc/cp/call.cc:2132
0x6d6b9c can_convert_arg_bad(tree_node*, tree_node*, tree_node*, int, int)
../../gcc/cp/call.cc:12625
0x893291 convert_for_assignment
../../gcc/cp/typeck.cc:9831
0x893acb convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
../../gcc/cp/typeck.cc:10062
0x899ffd digest_init_r
../../gcc/cp/typeck2.cc:1357
0x89b7e0 digest_init_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/typeck2.cc:1370
0x89b7e0 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.cc:842
0x74ad20 check_initializer
../../gcc/cp/decl.cc:7279
0x74c201 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.cc:8247
0x80ecdf cp_parser_init_declarator
../../gcc/cp/parser.cc:22823
0x7ecec2 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15286
0x7ee769 cp_parser_declaration_statement
../../gcc/cp/parser.cc:14367
0x7eed6b cp_parser_statement
../../gcc/cp/parser.cc:12452
0x7efcb4 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12856

[Bug c++/104668] New: [12 Regression] ICE in lookup_attribute_spec, at attribs.cc:425

[gscfq--- via Gcc-bugs]

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

Bug ID: 104668
   Summary: [12 Regression] ICE in lookup_attribute_spec, at
attribs.cc:425
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220123 and 20220130 :
(derived from g++.dg/cpp0x/lambda/lambda-variadic15.C)


$ cat z1.cc
template 
void sink(Ts...);
template 
void f(Ts...) {
  sink([] { struct alignas:Ts) S {}; }...); }
}
int main() {
  f(0);
}


$ g++-12-20220220 -c z1.cc
z1.cc: In lambda function:
z1.cc:5:20: internal compiler error: Segmentation fault
5 |   sink([] { struct alignas:Ts) S {}; }...); }
  |^~~
0xda25ef crash_signal
../../gcc/toplev.cc:322
0x89f4f1 lookup_attribute_spec(tree_node const*)
../../gcc/attribs.cc:425
0x75217e is_late_template_attribute
../../gcc/cp/decl2.cc:1243
0x75217e splice_template_attributes(tree_node**, tree_node*)
../../gcc/cp/decl2.cc:1340
0x752b1e cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/cp/decl2.cc:1662
0x7eabc8 cp_parser_class_head
../../gcc/cp/parser.cc:26646
0x7eabc8 cp_parser_class_specifier_1
../../gcc/cp/parser.cc:25824
0x7eb670 cp_parser_class_specifier
../../gcc/cp/parser.cc:26204
0x7eb670 cp_parser_type_specifier
../../gcc/cp/parser.cc:19348
0x7ec1a6 cp_parser_decl_specifier_seq
../../gcc/cp/parser.cc:15911
0x7ecd61 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15159
0x7ee769 cp_parser_declaration_statement
../../gcc/cp/parser.cc:14367
0x7eed6b cp_parser_statement
../../gcc/cp/parser.cc:12452
0x7efcb4 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12856
0x7efd6f cp_parser_compound_statement
../../gcc/cp/parser.cc:12808
0x7f0778 cp_parser_function_body
../../gcc/cp/parser.cc:25062
0x7f0778 cp_parser_lambda_body
../../gcc/cp/parser.cc:11799
0x7f0778 cp_parser_lambda_expression
../../gcc/cp/parser.cc:8
0x7f0778 cp_parser_primary_expression
../../gcc/cp/parser.cc:5700
0x7f3725 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7652

[Bug c++/104667] New: [10/11/12 Regression] ICE in is_late_template_attribute, at cp/decl2.cc:1299

[gscfq--- via Gcc-bugs]

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

Bug ID: 104667
   Summary: [10/11/12 Regression] ICE in
is_late_template_attribute, at cp/decl2.cc:1299
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20191117 and 20191124 :


$ cat z1.cc
template  class A
{ enum { e __attribute__ ((access)) }; };


$ g++-12-20220220 -c z1.cc
z1.cc:2:35: internal compiler error: Segmentation fault
2 | { enum { e __attribute__ ((access)) }; };
  |   ^
0xda25ef crash_signal
../../gcc/toplev.cc:322
0x7522cc is_late_template_attribute
../../gcc/cp/decl2.cc:1299
0x7522cc splice_template_attributes(tree_node**, tree_node*)
../../gcc/cp/decl2.cc:1340
0x752b1e cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/cp/decl2.cc:1662
0x74312e build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/cp/decl.cc:16590
0x7ebcb3 cp_parser_enumerator_definition
../../gcc/cp/parser.cc:21162
0x7ebcb3 cp_parser_enumerator_list
../../gcc/cp/parser.cc:21082
0x7ebcb3 cp_parser_enum_specifier
../../gcc/cp/parser.cc:21012
0x7ebcb3 cp_parser_type_specifier
../../gcc/cp/parser.cc:19318
0x7ec1a6 cp_parser_decl_specifier_seq
../../gcc/cp/parser.cc:15911
0x81304a cp_parser_member_declaration
../../gcc/cp/parser.cc:26965
0x7e968e cp_parser_member_specification_opt
../../gcc/cp/parser.cc:26821
0x7e968e cp_parser_class_specifier_1
../../gcc/cp/parser.cc:25887
0x7eb670 cp_parser_class_specifier
../../gcc/cp/parser.cc:26204
0x7eb670 cp_parser_type_specifier
../../gcc/cp/parser.cc:19348
0x7ec1a6 cp_parser_decl_specifier_seq
../../gcc/cp/parser.cc:15911
0x811d2b cp_parser_single_declaration
../../gcc/cp/parser.cc:31648
0x812165 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.cc:31311
0x81293b cp_parser_explicit_template_declaration
../../gcc/cp/parser.cc:31577
0x81293b cp_parser_template_declaration_after_export
../../gcc/cp/parser.cc:31596

[Bug c/104666] New: [12 Regression] ICE in related_vector_mode, at stor-layout.c:537

[gscfq--- via Gcc-bugs]

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

Bug ID: 104666
   Summary: [12 Regression] ICE in related_vector_mode, at
stor-layout.c:537
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210627 and 20210704 :


$ cat z1.c
typedef double __m128d __attribute__((__vector_size__(16), __may_alias__));
__m128d sse4_1_blendvpd (__m128d a, __m128d b, __m128d c)
__attribute__((__target__("sse4.1")));

__m128d
generic_blendvpd (__m128d a, __m128d b, __m128d c)
{
  return __builtin_ia32_blendvpd (a, b, c);
}


$ gcc-12-20220220 -c z1.c -mno-sse
z1.c: In function 'generic_blendvpd':
z1.c:5:1: error: SSE register return with SSE disabled
5 | generic_blendvpd (__m128d a, __m128d b, __m128d c)
  | ^~~~
during GIMPLE pass: lower
z1.c:5:1: internal compiler error: in related_vector_mode, at stor-layout.c:537
0xdb93ce related_vector_mode(machine_mode, scalar_mode, poly_int<1u, unsigned
long>)
../../gcc/stor-layout.c:537
0x1077b42 get_related_vectype_for_scalar_type(machine_mode, tree_node*,
poly_int<1u, unsigned long>)
../../gcc/tree-vect-stmts.c:11138
0x11e0cba ix86_gimple_fold_builtin(gimple_stmt_iterator*)
../../gcc/config/i386/i386.c:18005
0xa95391 gimple_fold_call
../../gcc/gimple-fold.c:5568
0xa96eab fold_stmt_1
../../gcc/gimple-fold.c:6265
0x1829ad7 lower_stmt
../../gcc/gimple-low.c:388
0x1829ad7 lower_sequence
../../gcc/gimple-low.c:217
0x1829759 lower_gimple_bind
../../gcc/gimple-low.c:473
0x182ab78 lower_function_body
../../gcc/gimple-low.c:110
0x182ab78 execute
../../gcc/gimple-low.c:195

[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

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

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

--- Comment #27 from Martin Sebor  ---
*** Bug 104655 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/104655] [12 Regression] array subscript 0 is outside array bounds of

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||msebor at gcc dot gnu.org
 Status|WAITING |RESOLVED

--- Comment #8 from Martin Sebor  ---
The warning in the test case in comment #6 is intentional: it triggers because
the hardcoded address (0xfee0) doesn't refer to a known object, same as in
the test case in bug 99578 comment 0.  The bug is still open because there's a
lack of consensus as to whether or how GCC should be enhanced to accept such
code without a warning.  -Warray-bounds and -Wstringop-overflow/-overread
depend on optimizations some of which tend to expose new instances of warnings
as optimizers improve from one release to another.

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

[Bug c++/79493] Bad diagnostic when referring to inner type that does not exist

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Test added.

[Bug c++/79493] Bad diagnostic when referring to inner type that does not exist

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r12-7363-gcdcea7c1ef6586bb1eb0144b741969748cbd780b
Author: Marek Polacek 
Date:   Wed Feb 23 12:46:21 2022 -0500

c++: Add new test [PR79493]

A nice side effect of r12-1822 was improving the diagnostic
we emit for the following test.

PR c++/79493

gcc/testsuite/ChangeLog:

* g++.dg/diagnostic/undeclared1.C: New test.

[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Added.

[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

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

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

--- Comment #9 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:9675ecf7f9b340f93c68cf22280f5975a902

commit r12-7362-g9675ecf7f9b340f93c68cf22280f5975a902
Author: Marek Polacek 
Date:   Wed Feb 23 12:37:43 2022 -0500

c++: Add fixed test [PR70077]

Fixed with r10-1280.

PR c++/70077

gcc/testsuite/ChangeLog:

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

[Bug target/102485] -Wa,-many no longer has any effect

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #7 from Segher Boessenkool  ---
> GCC already passes -m to the assembler though.

That mostly is historic.

> The justification for emitting the .machine directive is given as fixing a
> build breakage due to a build system that passes an incorrect -m to the
> assembler.

Not really, no.  That is just one tiny part of the problem.  It is impossible
to know what instruction sets we need ahead of time, and -many cannot work (and
*does not* work: there are quite a few mnemonics that encode to different insns
on different architecture versions (or for different CPUs), and we cannot know
which is wanted, or which is preferred, ahead of time.

> *That* is the broken code (if any) that should have been fixed. But instead
> that is hacked around in a way that breaks working code that passes down
> -Wa,-many option as specified.

There is no working code that uses -many (accept by accident, if no problem
has hit you yet).

> The kernel builds with a base compatibility (say -mcpu=power4) and then has
> certain code paths that are dynamically taken if running on newer CPUs which
> use newer instructions with inline asm.
> 
> This is an important usage and it's pervasive, it seems unreasonable to
> break it.  Adding .machine directives throughout inline asm for every
> instruction not in the base compatibility class is pretty horrible.

It is the only correct thing to do.

[Bug c/89408] No constant folding when dereferencing string literals

[srk31 at srcf dot ucam.org via Gcc-bugs]

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

Stephen Kell  changed:

   What|Removed |Added

 CC||srk31 at srcf dot ucam.org

--- Comment #5 from Stephen Kell  ---
I just ran into this issue myself. Even though GCC is within the C language
spec in not supporting this case, there are at least the following reasons to
consider the reported behaviour a bug.

- GCC doesn't need to reject this code. C11 6.6 pt 10 says "An implementation
may accept other forms of constant expressions."

- The error message suggests that the omission is not intentional. If it really
was about language-lawyering, it should explicitly the C-language concept of
"integer constant expressions". Currently, what it says is actually false and
confusing, because the expression clearly *does* reduce to an integer constant.
It just isn't an "integer constant expression". To me it looks like the
compiler just happens not to be doing the necessary folding in that particular
case (no pun intended).

- GCC accepts these kinds of expressions in initializers, even though the C
language also does not require this to work (because they're not in the classes
of expression listed in C11 6.6 pt 7). Test case: int x = "C"[0];

- It makes the compiler more useful, has no apparent downside, Clang supports
it, etc etc. :-)

[Bug target/102485] -Wa,-many no longer has any effect

[npiggin at gmail dot com via Gcc-bugs]

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

Nicholas Piggin  changed:

   What|Removed |Added

 CC||npiggin at gmail dot com

--- Comment #6 from Nicholas Piggin  ---
(In reply to Peter Bergner from comment #1)
> I agree it is GCC's job to emit a ".machine CPU" directive that allows the
> assembler to correctly assemble the code GCC generates.

GCC already passes -m to the assembler though.

The justification for emitting the .machine directive is given as fixing a
build breakage due to a build system that passes an incorrect -m to the
assembler.

*That* is the broken code (if any) that should have been fixed. But instead
that is hacked around in a way that breaks working code that passes down
-Wa,-many option as specified.

>  Your test case
> however uses inline asm and GCC does not know that you are using the mfppr32
> mnemonic.  The assembler code you write in an inline asm is basically a
> black box to the compiler.  It is therefor up to the programmer to ensure
> that either the -mcpu=CPU GCC option that is being used (which
> emits".machine CPU" directive) is enough to assemble the mnemonics in the
> inline asm or you have to emit them in your inline asm.

The kernel builds with a base compatibility (say -mcpu=power4) and then has
certain code paths that are dynamically taken if running on newer CPUs which
use newer instructions with inline asm.

This is an important usage and it's pervasive, it seems unreasonable to break
it.  Adding .machine directives throughout inline asm for every instruction not
in the base compatibility class is pretty horrible.

[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

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

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

--- Comment #26 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #25)
> In my opinion, code that deliberately uses invalid pointers (e.g., hardwired
> addresses) should be explicitly annotated, e.g., by some attribute.  This
> approach has at least two advantages: 1) it makes the intent clear to the
> reader, and 2) by declaring the object it lets GCC enforce type safety as
> well as check for out-of-bounds access to it.  GCC already provides two such
> attributes: the AVR address and io attributes.  Rather than relying on
> heuristics I would suggest to make the address attribute (or one like it)
> available on all targets and use it for this purpose.  (I started working on
> it last November but didn't finish it.)

That is nonsense.  The amount of code in the wild that relies on (type
*)CONSTANT
working is insane, you can't annotate it all.  And it has worked fine for
decades.  The pointers aren't invalid, they point to valid objects in the
address space.
POSIX supports MAP_FIXED for a reason (and in many embedded cases one doesn't
even have an MMU and I/O or other special areas are mapped directly).

[Bug go/101246] gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Lance Fredrickson  ---
So this is the patch I'm using to build gccgo for uclibc arm.

https://raw.githubusercontent.com/lancethepants/tomatoware/master/patches/gcc/0006-fix-libgo-uclibc-ng.patch

In a seperate discussion you mentioned excluding the struct from generation,
and this seems to work fine. It'd be nice to see this upstreamed but submitting
for gcc looks like a high barrier to entry.

[Bug tree-optimization/104665] Failure to recognize memcpy

[monad at posteo dot net via Gcc-bugs]

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

--- Comment #2 from monad at posteo dot net ---
The full code including headers is:

#include 
#include 
#include 


void serialize_le(std::byte* __restrict dst, const std::uint32_t* __restrict
src)
{
for (int i = 0; i < 32; ++i, ++src)
{
*dst++ = static_cast((*src >> 24) & 0xff);
*dst++ = static_cast((*src >> 16) & 0xff);
*dst++ = static_cast((*src >>  8) & 0xff);
*dst++ = static_cast((*src >>  0) & 0xff);
}
}

[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris

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

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

--- Comment #6 from Jonathan Wakely  ---
This fixes the abi check FAIL on Solaris 11.3, I don't have access to 11.4 to
try it.

[Bug tree-optimization/104665] Failure to recognize memcpy

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

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

--- Comment #1 from Jonathan Wakely  ---
Please include the full code here, including the #include directives. Not just
a link to godbolt.org.

[Bug tree-optimization/104665] New: Failure to recognize memcpy

[monad at posteo dot net via Gcc-bugs]

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

Bug ID: 104665
   Summary: Failure to recognize memcpy
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: monad at posteo dot net
  Target Milestone: ---

The following serialization code:

void serialize_le(std::byte* __restrict dst, const std::uint32_t* __restrict
src)
{
for (int i = 0; i < 32; ++i, ++src)
{
*dst++ = static_cast((*src >>  0) & 0xff);
*dst++ = static_cast((*src >>  8) & 0xff);
*dst++ = static_cast((*src >> 16) & 0xff);
*dst++ = static_cast((*src >> 24) & 0xff);
}
}

is not recognized as just copying memory.
Both clang and gcc fail to optimize it properly, however gcc creates an
"interesting" mess.
Flags used are `-std=c++17 -O3 -march=haswell`

[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

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

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

--- Comment #25 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #24)
> (In reply to Martin Sebor from comment #1)
> > The warning is by design.
> 
> That just means the design is bad.  Especially in the embedded world, using
> memory mapped IO at fixed addresses is very common and we really shouldn't
> force
> people to pessimize their code by adding volatile on the pointers etc.

No, the design is perfectly fine: it enforces the constraint in the standard
that require pointers to point to live objects when they're used. 
Implementations can impose less restrictive constraints and implement behavior
the standard leaves undefined by providing extensions.  But to distinguish the
two kinds of behavior they need to document the extensions.  Failing to do that
only leads to confusion and bugs (this code worked just fine in version X of
GCC but version Y broke it!)

Following this simple approach not only improves the quality of the
implementation but also helps guide decisions about what's helpful to diagnose
and what should be silently accepted.

> >  Its purpose is to detect invalid accesses at
> > non-zero offsets to null pointers, like in the memset call below:
> > 
> >   struct S { int a, b[4]; };
> > 
> >   void f (struct S *p)
> >   {
> > if (p) return;
> > memset (p->b, 0, 4 * sizeof p->b);
> >   }
> > 
> > For now, I recommend suppressing the warning either by #pragma GCC
> > diagnostic or by making the pointer volatile.  In the future, providing an
> > attribute to annotate constant addresses with (or extending the io()
> > attribute supported by some targets to all targets) might be another way to
> > avoid it.
> 
> Then perhaps just add some flag on the INTEGER_CSTs created from folding
> >member into constant (seems currently that happens during {,e}vrp and
> dom) and only in the spots you warn if the INTEGER_CST has that flag set?

In my opinion, code that deliberately uses invalid pointers (e.g., hardwired
addresses) should be explicitly annotated, e.g., by some attribute.  This
approach has at least two advantages: 1) it makes the intent clear to the
reader, and 2) by declaring the object it lets GCC enforce type safety as well
as check for out-of-bounds access to it.  GCC already provides two such
attributes: the AVR address and io attributes.  Rather than relying on
heuristics I would suggest to make the address attribute (or one like it)
available on all targets and use it for this purpose.  (I started working on it
last November but didn't finish it.)

[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris

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

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

--- Comment #5 from Jonathan Wakely  ---
Created attachment 52501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52501=edit
Patch to fix abi-check on Solaris 11.3

This patch changes the version of the std::from_chars symbols from 
GLIBCXX_3.4.29 to GLIBCXX_3.4.30 for targets where they were absent in gcc-11
and are present in gcc-12 (such as Solaris 11.3).

It also adds aliases for Solaris 11.4 (and later) so that they are present with
both symbol versions, to support executables linked on Solaris 11.3 and
expecting the symbols to have the new version.

[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

--- Comment #13 from Chengnian Sun  ---
(In reply to Jakub Jelinek from comment #10)
> Because -fcompare-debug tells the driver to compile the TU twice, once
> without and once with -gtoggle, and compare the result.
> So, if there is a difference in the generated IL e.g. for -flto
> -ffat-lto-objects, it will detect it.
> Just watch
> gcc -flto -O1 pr104237.c  -o pr104237 -g -fcompare-debug -v 2>&1 | grep
> 'cc1\|lto1'
> to see that, cc1 is invoked twice, once without -gtoggle, once with it, but
> lto1 is invoked just twice, once for wpa and once for ltrans.
> Even if you convince the linker plugin to pass -fcompare-debug even to the
> driver that invokes lto1, that would again compare lto1 with and without -g
> but only
> on a single input (depending on whether the original command line has -g
> with or without debug stmts in it).
> To reproduce this bug, one needs to do a "manual -fcompare-debug", which is
> gcc -flto -O1 pr104237.c  -o pr104237 -g // + force lto1 to pass
> -fdump-final-insns=1
> gcc -flto -O1 pr104237.c  -o pr104237 // + force lto1 to pass
> -fdump-final-insns=2
> diff -up 1 2
> Now, in theory the driver could arrange that, but it would only handle the
> trivial case when the compilation and linking are from the same command.
> Typically with LTO, compilation is done separately and linking is done
> separately, and I don't see how the driver could arrange for that to work,
> we need in that case two sets of *.o files with the IL, one with -g0 and one
> with -g, link twice and compare the result at the end.

Thank you so much for the detailed explanation.

[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris

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

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

--- Comment #4 from Jonathan Wakely  ---
Rainer, is an executable linked against libstdc++.so.6.0.29 on Solaris 11.3
expected to work on an 11.4 machine with libstdc++.so.6.0.30?

With a #ifdef kluge in config/abi/pre/gnu.ver we can make the new from_chars
symbols get version GLIBCXX_3.4.30 on 11.3 and keep them at version 3.4.29 for
11.4. But that would mean a program linked on 11.3 and looking for
_ZSt10from_charsPKcS0_RdSt12chars_format@GLIBCXX_3.4.30 would not find it on
11.4. We can fix that with some symbol aliases for Solaris 11.4 to make it
available for both symbol versions if needed.

[Bug tree-optimization/104601] [11/12 Regression] Invalid branch elimination at -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 52500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52500=edit
gcc12-pr104601.patch

Full untested patch.

[Bug target/104664] New: ICE: in extract_constrain_insn, at recog.cc:2670 (insn does not satisfy its constraints) with -Og -ffinite-math-only

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104664
   Summary: ICE: in extract_constrain_insn, at recog.cc:2670 (insn
does not satisfy its constraints) with -Og
-ffinite-math-only
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og -ffinite-math-only testcase.c 
testcase.c: In function 'foo':
testcase.c:13:1: error: insn does not satisfy its constraints:
   13 | }
  | ^
(insn 180 179 186 2 (set (reg:V8HF 27 xmm7 [220])
(reg:V8HF 0 ax)) "testcase.c":12:5 1706 {movv8hf_internal}
 (nil))
during RTL pass: reload
testcase.c:13:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2670
0x768521 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x7685a7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x7574d0 extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2670
0x11aaec4 check_rtl
/repo/gcc-trunk/gcc/lra.cc:2095
0x11afd0b lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.cc:2513
0x115fdd9 do_reload
/repo/gcc-trunk/gcc/ira.cc:5940
0x115fdd9 execute
/repo/gcc-trunk/gcc/ira.cc:6126
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


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

[Bug tree-optimization/103037] [11/12 Regression] Wrong code with -O2 since r11-6100-gd41b097350d3c5d0

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

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

--- Comment #8 from Richard Biener  ---
More reduced testcase - the min() obfuscation is to avoid recognizing a
MIN_EXPR before jump threading gets the chance to disrupt it.  A GIMPLE unit
testcase for
PRE is difficult since we are not supporting SSA annotations (ranges) at the
moment.

static inline const unsigned short *
min(unsigned short *d, const unsigned short *e)
{
  return *e < *d ? e : d;
}

unsigned short __attribute__((noipa))
test(unsigned short arr, unsigned short val)
{
  unsigned short tem = 1;
  unsigned short tem2 = *min(, );
  return tem2 / (arr ? arr : val);
}

int
main()
{
  if (test (2, 2) != 0)
__builtin_abort();
  return 0;
}

The IL for the reduced testcase before PRE is

   [local count: 1073741824]:
  if (arr_6(D) > 1)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  # RANGE [0, 1] NONZERO 1
  _1 = (int) arr_6(D); // (A)
  if (arr_6(D) != 0)
goto ; [20.00%]
  else
goto ; [80.00%]

   [local count: 536870913]:
  # RANGE [0, 1] NONZERO 1
  # _17 = PHI <_1(3), 1(2)>
  # RANGE [1, 65535] NONZERO 65535
  iftmp.0_9 = (int) arr_6(D);  // (B) 
  goto ; [100.00%]

   [local count: 536870913]:
  # RANGE [0, 65535] NONZERO 65535
  iftmp.0_8 = (int) val_7(D);

   [local count: 1073741824]:
  # RANGE [0, 65535] NONZERO 65535
  # iftmp.0_3 = PHI 
  # RANGE [0, 1] NONZERO 1
  # _18 = PHI <_17(4), 0(5)>
  # RANGE [0, 1] NONZERO 1
  _2 = _18 / iftmp.0_3;
  # RANGE [0, 1] NONZERO 1
  _10 = (short unsigned int) _2;
  return _10;

and the problematic value-numbering is

iftmp.0_9 = _1 (0001)

at (A) and (B).  By design we may only use _available_ expressions during
simplification but _1 is not available on the 4 -> 6 edge.  That's working
OK for the translation from 4 -> 6 but then we record a valueized
expression into the ANTIC set of 4 which when further translated and
simplified has the wrong representative inside.

[Bug tree-optimization/104601] [11/12 Regression] Invalid branch elimination at -O2

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

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

--- Comment #10 from Jakub Jelinek  ---
But:
--- gcc/tree-ssa-sccvn.cc.jj2022-02-11 00:19:22.432063254 +0100
+++ gcc/tree-ssa-sccvn.cc   2022-02-23 16:16:25.873557626 +0100
@@ -5218,7 +5218,11 @@ visit_reference_op_call (tree lhs, gcall

   if (vnresult)
 {
-  if (vnresult->result_vdef && vdef)
+  /* If stmt has non-SSA_NAME lhs, don't value number the vdef,
+as the call still acts as a lhs store.  */
+  if (!lhs && vdef && gimple_call_lhs (stmt))
+   changed |= set_ssa_val_to (vdef, vdef);
+  else if (vnresult->result_vdef && vdef)
changed |= set_ssa_val_to (vdef, vnresult->result_vdef);
   else if (vdef)
/* If the call was discovered to be pure or const reflect
@@ -5248,7 +5252,10 @@ visit_reference_op_call (tree lhs, gcall
  if (TREE_CODE (fn) == ADDR_EXPR
  && TREE_CODE (TREE_OPERAND (fn, 0)) == FUNCTION_DECL
  && (flags_from_decl_or_type (TREE_OPERAND (fn, 0))
- & (ECF_CONST | ECF_PURE)))
+ & (ECF_CONST | ECF_PURE))
+ /* If stmt has non-SSA_NAME lhs, don't value number the
+vdef, as the call still acts as a lhs store.  */
+ && (lhs || gimple_call_lhs (stmt) == NULL_TREE))
vdef_val = vuse_ssa_val (gimple_vuse (stmt));
}
  changed |= set_ssa_val_to (vdef, vdef_val);
works for the testcase.

[Bug tree-optimization/104601] [11/12 Regression] Invalid branch elimination at -O2

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

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

--- Comment #9 from Jakub Jelinek  ---
But
--- gcc/tree-ssa-sccvn.cc.jj2022-02-11 00:19:22.432063254 +0100
+++ gcc/tree-ssa-sccvn.cc   2022-02-23 16:07:36.697893998 +0100
@@ -5218,7 +5218,11 @@ visit_reference_op_call (tree lhs, gcall

   if (vnresult)
 {
-  if (vnresult->result_vdef && vdef)
+  /* If stmt has non-SSA_NAME lhs, don't value number the vdef,
+as the call still acts as a lhs store.  */
+  if (!lhs && gimple_call_lhs (stmt))
+   ;
+  else if (vnresult->result_vdef && vdef)
changed |= set_ssa_val_to (vdef, vnresult->result_vdef);
   else if (vdef)
/* If the call was discovered to be pure or const reflect
@@ -5248,7 +5252,10 @@ visit_reference_op_call (tree lhs, gcall
  if (TREE_CODE (fn) == ADDR_EXPR
  && TREE_CODE (TREE_OPERAND (fn, 0)) == FUNCTION_DECL
  && (flags_from_decl_or_type (TREE_OPERAND (fn, 0))
- & (ECF_CONST | ECF_PURE)))
+ & (ECF_CONST | ECF_PURE))
+ /* If stmt has non-SSA_NAME lhs, don't value number the
+vdef, as the call still acts as a lhs store.  */
+ && (lhs || gimple_call_lhs (stmt) == NULL_TREE))
vdef_val = vuse_ssa_val (gimple_vuse (stmt));
}
  changed |= set_ssa_val_to (vdef, vdef_val);
results in ICEs later on - the
  gcc_assert (x != VN_TOP);
assert in vuse_ssa_val.

[Bug tree-optimization/104601] [11/12 Regression] Invalid branch elimination at -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
I believe the bug is in visit_reference_op_call:
5241  /* If we value numbered an indirect functions function to
5242 one not clobbering memory value number its VDEF to its
5243 VUSE.  */
5244  tree fn = gimple_call_fn (stmt);
5245  if (fn && TREE_CODE (fn) == SSA_NAME)
5246{
5247  fn = SSA_VAL (fn);
5248  if (TREE_CODE (fn) == ADDR_EXPR
5249  && TREE_CODE (TREE_OPERAND (fn, 0)) == FUNCTION_DECL
5250  && (flags_from_decl_or_type (TREE_OPERAND (fn, 0))
5251  & (ECF_CONST | ECF_PURE)))
5252vdef_val = vuse_ssa_val (gimple_vuse (stmt));
5253}
5254  changed |= set_ssa_val_to (vdef, vdef_val);

stmt in this case is:

# .MEM_140 = VDEF <.MEM_96>
*__pred$__d_43 = _50 (_49);

and _50 value numbers to  where f is a const function.
I think we can value number the vdef to vuse_ssa_val (gimple_vuse (stmt))
only if the lhs of the call is not present or is an SSA_NAME, when the call
(const or pure) acts as a store, we shouldn't do that.
A few lines before this there is also:
  if (vnresult->result_vdef && vdef)
changed |= set_ssa_val_to (vdef, vnresult->result_vdef);
  else if (vdef)
/* If the call was discovered to be pure or const reflect
   that as far as possible.  */
changed |= set_ssa_val_to (vdef, vuse_ssa_val (gimple_vuse (stmt)));
I wonder if that doesn't suffer from the same problem.

[Bug target/103926] "wQ" broken

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

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

Segher Boessenkool  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #5 from Segher Boessenkool  ---
Well, there are a few things going on here.

Firstly, perhaps we should document wQ, if there is no better way to provide
this functionality.  (That last part is not clear, atomic types should work
fine!)

Secondly, the testcase is just broken.  wQ is a memory constraint, so giving
non-memory as the operand cannot work (it has identity, copying to temporary
memory would be even more wrong!)  But our error is not so friendly.

Correcting the testcase to

===
void f(void)
{
__int128 *ptr;
__int128 v;
asm volatile("lq %0,%1" : "=r" (v) : "wQ" (*ptr));
}
===

(ignoring the uninitialised variable), and passing -mcpu=power8 (without
which (or power9 etc.) wQ is never satisfiable by anything) works.  Not
having the -mcpu= gives "error: unrecognizable insn" which is a bit
misleading, or at least not helpful.

It *is* normal for GCC to ICE on certain problems with inline asm, but the
error message should not be so baffling.

Anyway, confirmed.

[Bug middle-end/81889] [7 Regression] bogus warnings with -Wmaybe-uninitialized -O3

[jasonadamses at protonmail dot com via Gcc-bugs]

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

Jason Adams  changed:

   What|Removed |Added

 CC||jasonadamses at protonmail dot 
com

--- Comment #16 from Jason Adams  ---
Thanks, it was useful for my project best antivirus apps for android:
https://celltrackingapps.com/best-antivirus-for-ios/

[Bug rtl-optimization/104663] New: A 50% C-Ray regression in GCC 12.0 for ADL at -O2

[aros at gmx dot com via Gcc-bugs]

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

Bug ID: 104663
   Summary: A 50% C-Ray regression in GCC 12.0 for ADL at -O2
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aros at gmx dot com
  Target Milestone: ---

Check the first graph at
https://www.phoronix.com/scan.php?page=article=gcc12-feb-alderlake=3

[Bug analyzer/104434] Analyzer doesn't know about "pure" and "const" functions

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

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

--- Comment #2 from David Malcolm  ---
On rereading
  https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
I think that "pure" isn't strong enough for the above example: the result of a
pure function is allowed to change between invocations with the same inputs.  I
think the function needs to be "const".

[Bug go/104660] Makefile.in has embedded dependencies of libatomic and libbacktrace for libgo, causing GNU/Hurd build to fail.

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ian at airs dot com
 Status|UNCONFIRMED |NEW
 CC||cmang at google dot com,
   ||iant at google dot com
   Last reconfirmed||2022-02-23
 Ever confirmed|0   |1
   Keywords||build
  Component|bootstrap   |go

--- Comment #1 from Richard Biener  ---
Well, that's because of

dependencies = { module=all-target-libgo; on=all-target-libbacktrace; };
dependencies = { module=all-target-libgo; on=all-target-libffi; };
dependencies = { module=all-target-libgo; on=all-target-libatomic; };

the reason the dependency is conditional is that libgo is not bootstrapped
(and so is libffi) but libbacktrace and libatomic are.

There might be an error in Makefile.tpl but maybe you can elaborate on the
exact issue that prevents you to build on GNU/Hurd?  How do you configure
there?  When I configure with --disable-bootstrap I do have all required
dependencies in the toplevel Makefile.  When I configure with bootstrapping
the the toplevel Makefile will not build libgo during stage1 but indeed
the all-target-libgo target seems to miss a dependency on
maybe-all-stage3-target-libbacktrace.

IIRC the "usual" workaround is to build a non-bootstrapped target library
as well here.

I guess I've never run into this because when I'm building go I'm also
building other bootstrapped target libs that build libbacktrace and libatomic.

[Bug tree-optimization/104644] [12 Regression] ICE: SIGSEGV (infinite recursion in fold_binary_loc / fold_build2_loc / generic_simplify_NE_EXPR)

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/104644] [12 Regression] ICE: SIGSEGV (infinite recursion in fold_binary_loc / fold_build2_loc / generic_simplify_NE_EXPR)

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

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

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

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

commit r12-7361-gfdc46830f1b793dc791099acfadc3f0f8cc24c0e
Author: Richard Biener 
Date:   Wed Feb 23 13:47:01 2022 +0100

middle-end/104644 - recursion with bswap match.pd pattern

The following patch avoids infinite recursion during generic folding.
The (cmp (bswap @0) INTEGER_CST@1) simplification relies on
(bswap @1) actually being simplified, if it is not simplified, we just
move the bswap from one operand to the other and if @0 is also INTEGER_CST,
we apply the same rule next.

The reason why bswap @1 isn't folded to INTEGER_CST is that the INTEGER_CST
has TREE_OVERFLOW set on it and fold-const-call.cc predicate punts in
such cases:
static inline bool
integer_cst_p (tree t)
{
  return TREE_CODE (t) == INTEGER_CST && !TREE_OVERFLOW (t);
}
The patch uses ! modifier to ensure the bswap is simplified and
extends support to GENERIC by means of requiring !EXPR_P which
is not perfect but a conservative approximation.

2022-02-22  Richard Biener  

PR tree-optimization/104644
* doc/match-and-simplify.texi: Amend ! documentation.
* genmatch.cc (expr::gen_transform): Code-generate ! support
for GENERIC.
(parser::parse_expr): Allow ! for GENERIC.
* match.pd (cmp (bswap @0) INTEGER_CST@1): Use ! modifier on
bswap.

* gcc.dg/pr104644.c: New test.

Co-Authored-by: Jakub Jelinek 

[Bug target/104662] New: arm: ice in simd_valid_immediate

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 104662
   Summary: arm: ice in simd_valid_immediate
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For testsuite file ./gcc.dg/rtl/arm/mve-vxbi.c, compiled
with a recent arm cross compiler, hosted on x86, does this:

$ /home/dcb/raspberrypi/results/bin/arm-linux-gnueabihf-gcc -c
./gcc.dg/rtl/arm/mve-vxbi.c
during RTL pass: ira
./gcc.dg/rtl/arm/mve-vxbi.c: In function ‘foo’:
./gcc.dg/rtl/arm/mve-vxbi.c:27:1: internal compiler error: in
simd_valid_immedia
te, at config/arm/arm.cc:12866
   27 | }
  | ^
0x7a67f1 simd_valid_immediate
/home/dcb/gcc/trunk.git/gcc/config/arm/arm.cc:12866
0x1375f59 simd_immediate_valid_for_move(rtx_def*, machine_mode, rtx_def**,
int*)
/home/dcb/gcc/trunk.git/gcc/config/arm/arm.cc:12974

[Bug target/104656] [12 Regression] trunk 20220222 ftbfs for bpf

[jose.marchesi at oracle dot com via Gcc-bugs]

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

Jose E. Marchesi  changed:

   What|Removed |Added

 CC||jose.marchesi at oracle dot com

--- Comment #5 from Jose E. Marchesi  ---
Yes that would require changing the kernel ABI.  Also, there is the kernel
verifier to deal with: stack accesses are tracked at load-time and they should
be done using certain registers and following certain rules.

For the time being, --disabling-gcov when building for BPF seems like a
reasonable thing to do.  Will write and send a patch in that effect.

[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #24 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #1)
> The warning is by design.

That just means the design is bad.  Especially in the embedded world, using
memory mapped IO at fixed addresses is very common and we really shouldn't
force
people to pessimize their code by adding volatile on the pointers etc.

>  Its purpose is to detect invalid accesses at
> non-zero offsets to null pointers, like in the memset call below:
> 
>   struct S { int a, b[4]; };
> 
>   void f (struct S *p)
>   {
> if (p) return;
> memset (p->b, 0, 4 * sizeof p->b);
>   }
> 
> For now, I recommend suppressing the warning either by #pragma GCC
> diagnostic or by making the pointer volatile.  In the future, providing an
> attribute to annotate constant addresses with (or extending the io()
> attribute supported by some targets to all targets) might be another way to
> avoid it.

Then perhaps just add some flag on the INTEGER_CSTs created from folding
>member into constant (seems currently that happens during {,e}vrp and
dom) and only in the spots you warn if the INTEGER_CST has that flag set?

[Bug c++/104661] New: Catching exception by const value when exception-object has lvalue-reference constructor

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 104661
   Summary: Catching exception by const value when
exception-object has lvalue-reference constructor
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program
```
struct A {
A() {}
A(A&) {}
};

int main() {
try {
throw A{};
}
catch ( const A ) {
}
}
```
is presumably valid and accepted by Clang and MSVC, but GCC complains:
```
error: binding reference of type 'A&' to 'const A' discards qualifiers
   10 | catch ( const A ) {
  |   ^
:3:7: note:   initializing argument 1 of 'A::A(A&)'
3 | A(A&) {}
  |   ^~
```
Demo: https://gcc.godbolt.org/z/as671TGqs

[Bug tree-optimization/104655] [12 Regression] array subscript 0 is outside array bounds of

[pmenzel+gcc at molgen dot mpg.de via Gcc-bugs]

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

--- Comment #7 from Paul Menzel  ---
Thank you for the analysis. Excuse my ignorance, but the referenced bug
(possible dup) says it’s a regression in GCC 11, but it does not show up here
with GCC 11. Are more issues tracked in bug 99578?

[Bug tree-optimization/104655] [12 Regression] array subscript 0 is outside array bounds of

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Paul Menzel from comment #5)
> Created attachment 52498 [details]
> Preprocessed file `build/bootblock/cpu/x86/lapic/lapic.i` with `-save-temps`
> 
> Sorry for not sharing the file in the first place. First for the coreboot
> case:

This case is a dup of bug 99578.
lapicid:
 uint32_t lapicid = lapic_read(0x020);

static inline __attribute__((always_inline)) uint32_t lapic_read(unsigned int
reg)
{
 if (is_x2apic_mode())
  return x2apic_read(reg);
 else
  return xapic_read(reg);
}

static inline __attribute__((always_inline)) uint32_t xapic_read(unsigned int
reg)
{
 return read32((volatile void *)(uintptr_t)(0xfee0 + reg));
}

static inline __attribute__((always_inline)) uint32_t read32(const volatile
void *addr)
{
 return *((volatile uint32_t *)(addr));
}

[Bug c/104633] [12 Regression] -Winfinite-recursion diagnoses fortify wrappers

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.