[Bug target/101007] ICE: in extract_insn, at recog.c:2770 (unrecognizable insn) with -mno-sse2

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-10
 Ever confirmed|0   |1
 CC||uros at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.  It's odd that V4SI seems to be available for permutes (to
veclower),
but then I guess -msse provides some float shuffles.

[Bug tree-optimization/101003] [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1329

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-10
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu
   ||aarch64
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/101001] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|wrong code at -O3 on|[9/10/11/12 Regression]
   |x86_64-linux-gnu|wrong code at -O3 on
   ||x86_64-linux-gnu
   Target Milestone|--- |9.5
Version|unknown |12.0
   Keywords||needs-bisection, wrong-code
  Known to work||7.5.0

[Bug tree-optimization/97770] [ICELAKE]suboptimal vectorization for vpopcntw/b/q

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #18 from rguenther at suse dot de  ---
On Thu, 10 Jun 2021, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770
> 
> --- Comment #17 from Hongtao.liu  ---
> (In reply to Richard Biener from comment #16)
> > Changing the signature will not help given we don't want to regress other
> > cases.
> > Instead we have to somehow remove the pro- and demotions with the help of
> > patterns.  I think using .POPCOUNT should work there.
> 
> I'm thinking of reimplementing _mm_popcnt_u64 with a backend builtin like
> __builtin_ia32_popcountll which is defined as ULONGLONG_FTYPE_ULONGLONG, and
> handle that in TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION.

That's going to work I guess but it will pessimize general optimization
which no longer know this is computing popcount (not sure if the old
version exposed that fact).

[Bug c/100993] ICE with -O2: Segmentation fault, cgraph_update_edges_for_call_stmt(gimple*, tree_node*, gimple*)

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Version|tree-ssa|12.0
   Keywords||accepts-invalid,
   ||ice-on-invalid-code

--- Comment #1 from Richard Biener  ---
I suppose we should reject definitions in the __builtin_* namespace?  Joseph,
can we?  It's fine to define 'memcpy', but it should not valid to define (or
even declare?) __builtin_memcpy.

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #19 from rguenther at suse dot de  ---
On Wed, 9 Jun 2021, public at timruffing dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
> 
> Tim Ruffing  changed:
> 
>What|Removed |Added
> 
>  CC||public at timruffing dot de
> 
> --- Comment #18 from Tim Ruffing  ---
> Is there still interest in fixing this? This still leads to spurious Valgrind
> warnings in the real world.

I don't think this is ever going to be "fixed" on the GCC side, instead
maybe valgrind should be at least given an option to ignore those cases.

[Bug rtl-optimization/101008] New: ICE: in native_encode_rtx, at simplify-rtx.c:6594 with -O -g

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 101008
   Summary: ICE: in native_encode_rtx, at simplify-rtx.c:6594 with
-O -g
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  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 50975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50975&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -g testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: in native_encode_rtx, at
simplify-rtx.c:6594
9 | foo(void)
  | ^~~
0x723dc0 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
/repo/gcc-trunk/gcc/simplify-rtx.c:6594
0x1065220 simplify_immed_subreg
/repo/gcc-trunk/gcc/simplify-rtx.c:7034
0x1065220 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.c:7110
0x1066499 simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.c:7334
0xba5f1a simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
/repo/gcc-trunk/gcc/rtl.h:3519
0xba5f1a expand_debug_expr
/repo/gcc-trunk/gcc/cfgexpand.c:4823
0xba3d49 expand_debug_expr
/repo/gcc-trunk/gcc/cfgexpand.c:5279
0xba3a54 expand_debug_expr
/repo/gcc-trunk/gcc/cfgexpand.c:5238
0xba75f9 expand_debug_locations
/repo/gcc-trunk/gcc/cfgexpand.c:5616
0xbafbdc execute
/repo/gcc-trunk/gcc/cfgexpand.c:6785
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


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

[Bug target/101007] New: ICE: in extract_insn, at recog.c:2770 (unrecognizable insn) with -mno-sse2

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 101007
   Summary: ICE: in extract_insn, at recog.c:2770 (unrecognizable
insn) with -mno-sse2
   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 50974
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50974&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mno-sse2 testcase.c
testcase.c: In function 'foo':
testcase.c:10:1: error: unrecognizable insn:
   10 | }
  | ^
(insn 14 7 9 2 (set (reg:V4SI 89)
(vec_concat:V4SI (mem/c:V2SI (symbol_ref:DI ("v") [flags 0x2] ) [1 v+0 S8 A128])
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
]))) "testcase.c":9:12 -1
 (nil))
during RTL pass: ira
testcase.c:10:1: internal compiler error: in extract_insn, at recog.c:2770
0x71519c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0x71521f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:116
0x70394a extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2770
0xe75c70 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
/repo/gcc-trunk/gcc/ira.c:5238
0xe789e5 remove_scratches
/repo/gcc-trunk/gcc/ira.c:5282
0xe789e5 ira
/repo/gcc-trunk/gcc/ira.c:5606
0xe789e5 execute
/repo/gcc-trunk/gcc/ira.c:5965
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

[Bug driver/100937] configure: Add --enable-default-semantic-interposition

[i at maskray dot me via Gcc-bugs]

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

--- Comment #6 from Fangrui Song  ---
Then can you add a -fvisibility=protected variant which only applies to
non-weak defined functions?

Two issues need to be fixed:

(1): https://sourceware.org/bugzilla/show_bug.cgi?id=27973

__attribute__((visibility("protected"))) void *foo () {
  return (void *)foo;
}
% gcc -fpic -shared -fuse-ld=bfd a.s
/usr/bin/ld.bfd: /tmp/ccWPJCLw.o: relocation R_X86_64_PC32 against protected
symbol `foo' can not be used when making a shared object
/usr/bin/ld.bfd: final link failed: bad value
collect2: error: ld returned 1 exit status

(2): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
[ELF] -fno-pic: Use GOT to take address of an external default visibility
function 


Distributions want fast C++ non-vague-linkage functions can enable this option.

[Bug c/100939] Missing warning with misplaced attribute declaration in struct, enum, or union definition

[johnfbennett at protonmail dot com via Gcc-bugs]

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

--- Comment #1 from johnfbennett at protonmail dot com ---
G++ does have a good warning for this scenario:

$ g++ -Wall misplacedattribute.c
misplacedattribute.c: In function ‘int main()’:
misplacedattribute.c:7:37: warning: attributes ignored on
elaborated-type-specifier that is not a forward declaration [-Wattributes]
7 |  struct __attribute__((__unused__)) samplestruct samplestruct;
  | ^~~~
misplacedattribute.c:7:50: warning: unused variable ‘samplestruct’
[-Wunused-variable]
7 |  struct __attribute__((__unused__)) samplestruct samplestruct;
  |  ^~~~

[Bug tree-optimization/97770] [ICELAKE]Missing vectorization for vpopcnt

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Hongtao.liu  ---
(In reply to Richard Biener from comment #16)
> Changing the signature will not help given we don't want to regress other
> cases.
> Instead we have to somehow remove the pro- and demotions with the help of
> patterns.  I think using .POPCOUNT should work there.

I'm thinking of reimplementing _mm_popcnt_u64 with a backend builtin like
__builtin_ia32_popcountll which is defined as ULONGLONG_FTYPE_ULONGLONG, and
handle that in TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION.

[Bug c++/101006] New: Request diagnostic for likely concept syntax errors

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

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

Bug ID: 101006
   Summary: Request diagnostic for likely concept syntax errors
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider the following:

template 
concept Thing = true;

template 
concept MemberThing = requires (T t) {
t.member() -> Thing;// #1
!requires { t.member(); };  // #2
};

These are likely intended to be (obviously not at the same time, this is just
an example):

template 
concept MemberThing = requires (T t) {
{ t.member() } -> Thing;

requires !requires { t.member(); };
};

But #1 is very likely to be a bug, and #2 is completely pointless as a
requirement since it's tautologically true. It would be nice if gcc could
produce warnings in such cases.

#2 is a similar case to the P2092 fixup of:

template 
concept MemberThing = requires (T t) {
requires { t.member(); };
};

which is now ill-formed. However, gcc's diagnostic here could be more helpful
too (perhaps including a fixup for an extra requires?)

:6:14: error: expected primary-expression before '{' token
6 | requires { t.member(); };
  |  ^

#1 might be harder to warn about since that could *theoretically* be intended,
but if unqualified lookup for Thing actually finds a concept, seems like a good
bet for a diagnostic maybe?

[Bug bootstrap/101005] [12 regression] bootstrap failure after r12-1342

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
It has been fixed by r12-1346.

[Bug bootstrap/101005] New: [12 regression] bootstrap failure after r12-1342

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

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

Bug ID: 101005
   Summary: [12 regression] bootstrap failure after r12-1342
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:4a0c4eaea320a418400afc4d63359ed6c4af5548, r12-1342 

make[3]: Entering directory
'/home/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc'
gawk -f /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/opt-functions.awk -f
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/opt-read.awk \
   -f /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/optc-save-gen.awk \
   -v header_name="config.h system.h coretypes.h tm.h" < optionlist >
options-save.c
gawk -f /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/opt-functions.awk -f
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/opt-read.awk \
   -f /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/optc-gen.awk \
   -v header_name="config.h system.h coretypes.h options.h tm.h" <
optionlist > options.c
echo timestamp > gcc.pod
perl /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../contrib/texi2pod.pl
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/doc/invoke.texi > gcc.pod
gawk -f /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/opt-functions.awk -f
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/opt-read.awk \
   -f /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/opth-gen.awk \
   < optionlist > tmp-options.h
build/genhooks -d \
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/doc/tm.texi.in >
tmp-tm.texi
case `echo X|tr X '\101'` in \
  A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \
  *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \
esac
mv tmp2-tm.texi tmp-tm.texi
/bin/sh /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../move-if-change
tmp-tm.texi tm.texi

Verify that you have permission to grant a GFDL license for all
new text in /home/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/tm.texi, then
copy it to /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/doc/tm.texi.
make[3]: *** [Makefile:2629: s-tm-texi] Error 1




commit 4a0c4eaea320a418400afc4d63359ed6c4af5548 (HEAD)
Author: Paul Eggert 
Date:   Wed Jun 9 12:25:26 2021 -0400

Document that -fno-trampolines is for Ada only [PR100735]

gcc/
PR other/100735
* doc/invoke.texi (Code Gen Options); Document that
-fno-trampolines
and -ftrampolines work only with Ada.
* doc/tm.texi.in (Trampolines): Likewise.
* doc/tm.texi: Regenerated.

[Bug preprocessor/100904] [9/10/11/12 Regression] Wrong line location #include error "No such file or directory" – line + 1 [traditional mode as used by gfortran]

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

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

--- Comment #3 from David Malcolm  ---
FWIW the following hackish workaround seems to fix it, though am still
investigating why this is happening.

diff --git a/libcpp/directives.c b/libcpp/directives.c
index f4aa17d1156..b5bdd443a5a 100644
--- a/libcpp/directives.c
+++ b/libcpp/directives.c
@@ -850,6 +850,9 @@ do_include_common (cpp_reader *pfile, enum include_type
type)
   pfile->directive->name, fname, angle_brackets,
   buf);

+  if (CPP_OPTION (pfile, traditional))
+   location = pfile->directive_line;
+
   _cpp_stack_include (pfile, fname, angle_brackets, type, location);
 }

[Bug target/100085] Bad code for union transfer from __float128 to vector types

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

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

--- Comment #12 from Segher Boessenkool  ---
We want to use plain TImode instead of V1TImode on newer cpus.  It probably is
a good idea (for performance) on p9 already, but this will need testing. That's
only sideways related to this issue though (but so is -mvsx-timode :-) )

[Bug c++/101004] New: SFINAE constrained conversion operator of class template parameter type does not work with built-in arithmetic operators

[namark at disroot dot org via Gcc-bugs]

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

Bug ID: 101004
   Summary: SFINAE constrained conversion operator of class
template parameter type does not work with built-in
arithmetic operators
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: namark at disroot dot org
  Target Milestone: ---

I believe the following code should be valid, but gcc rejects it (version
10.2.0 on my machine, but also all versions I could try on godbolt.org)

#include 

template 
class One
{
public:
template * = nullptr>
operator T() const { return 1; }
};

int main()
{
return 1 - One{}; // no match for operator-
}

The implicit conversion seems to work fine in general with initialization,
assignment or user defined operators/functions, but not with the built-in
arithmetic or comparison operators. Removing the SFINAE constraint fixes it.
Changing the conversion operator type from T to int also fixes it. That is,
either of those is fine on its own, but together they cause this strange
behavior.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

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 #10 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-June/056146.html

[Bug target/100085] Bad code for union transfer from __float128 to vector types

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

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

--- Comment #11 from Peter Bergner  ---
(In reply to luoxhu from comment #9)
> But for __float128 to __int128 mentioned in #c4, need hack
> rs6000_modes_tieable_p
> to remove the stack operation in dse1. But I am not sure this is *LEGAL*
> since TImode is allocated to GPR, It seems not true to access TImode from
> ALTIVEC or VSX without copying?

We used to have a -mvsx-timode option which allowed TImode pseudos into the VSX
registers.  We deprecated the option a while back and basically always allow
TImode in the VSX registers now.  I would say we even prefer them in VSX
registers over GOR registers.  The only "issue" is that our ABIs define
parameter passing and return values for TImode values go through the GPRs. :-(

[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||suochenyao at 163 dot com

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

[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
Dup of bug 100453 then.

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

[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"

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

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

--- Comment #8 from Eric Botcazou  ---
> The
>   MEM[(struct a *)&l].c = l$c_24;
> in the function to be inlined is there since esra.  Arguably it is strange
> that esra stores back into the parameter when it is const.

Right, it's a duplicate of PR optimization/100453; SRA should not generate
writes  into TREE_READONLY objects.

[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"

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

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

--- Comment #7 from Eric Botcazou  ---
> Perhaps the tree-inline.c change is fine for Ada, but it doesn't seem to be
> safe for C/C++.

You're casting away the const qualifier though, how can this valid C++?

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #50967|0   |1
is obsolete||

--- Comment #9 from anlauf at gcc dot gnu.org ---
Created attachment 50973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50973&action=edit
Corrected patch

[Bug tree-optimization/101003] New: [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1329

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

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

Bug ID: 101003
   Summary: [12 regression] ICE compiling gcc.dg/pr86179.c after
r12-1329
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:ce670e4faafb296d1f1a7828d20f8c8ba4686797, r12-1329
make  -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr86179.c"
FAIL: gcc.dg/pr86179.c (internal compiler error)
FAIL: gcc.dg/pr86179.c (test for excess errors)
# of unexpected failures2

Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled2894053.cc   
-fdiagnostics-plain-output  -S -o exceptions_enabled2894053.s(timeout =
300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled2894053.cc
-fdiagnostics-plain-output -S -o exceptions_enabled2894053.s
FAIL: gcc.dg/pr86179.c (test for excess errors)
Excess errors:
during GIMPLE pass: vect
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr86179.c:7:6: internal
compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.c:
0x10f87c13 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4442
0x10f872af vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4385
0x10f872af vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4385
0x10f872af vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4385
0x10f872af vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4385
0x10f8a4fb vect_slp_analyze_operations(vec_info*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4592
0x10f5b443 vect_analyze_loop_2
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:2396
0x10f5d9db vect_analyze_loop(loop*, vec_info_shared*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:2986
0x10f9dd6b try_vectorize_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1009
0x10f9ec6f vectorize_loops()
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1243
0x10ddf39f execute
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop.c:414


commit ce670e4faafb296d1f1a7828d20f8c8ba4686797 (HEAD, refs/bisect/bad)
Author: Richard Biener 
Date:   Wed Nov 18 14:17:34 2020 +0100

tree-optimization/97832 - handle associatable chains in SLP discovery

[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #9 from Peter Bergner  ---
(In reply to Peter Bergner from comment #7)
> Talking with Aaron offline, he pointed me at his
> 52e130652a76ff3d14c0f572fcd79fa53637ce2c fix which is already upstream. 
> Checking my sources, I don't have that, so I will retry with an updated
> compiler.

Ok, it's confirmed with a new build using Aaron's fallow-on fix the issue goes
away, so I'll close this as ALREADY_FIXED.  Thanks for your help Andrew!

[Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64

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

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

Bug ID: 101002
   Summary: Some powerpc tests fail with -mlong-double-64
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I now build GCC with all 3 long double variants (IEEE 128-bit, IBM 128-bit, and
64-bit).  The following C test fail when when you configure the compiler to use
64-bit long doubles:

gcc.dg/float128-align.c
gcc.dg/float64x-align.c
gcc.dg/tree-ssa/builtin-sprintf.c
gcc.target/powerpc/convert-fp-64.c
gcc.target/powerpc/float128-hw.c
gcc.target/powerpc/float128-hw4.c
gcc.target/powerpc/gnuattr2.c
gcc.target/powerpc/gnuattr3.c
gcc.target/powerpc/pr60203.c
gcc.target/powerpc/pr79004.c
gcc.target/powerpc/pr82748-1.c
gcc.target/powerpc/pr85657-3.c
gcc.target/powerpc/signbit-1.c

[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Peter Bergner from comment #7)
> (In reply to Peter Bergner from comment #6)
> > And you guessed well!  I built a mainline compiler for Gordon with Aaron's
> > commit reverted and the issue goes away.  Assigning this to Aaron to debug.
> 
> Talking with Aaron offline, he pointed me at his
> 52e130652a76ff3d14c0f572fcd79fa53637ce2c fix which is already upstream. 
> Checking my sources, I don't have that, so I will retry with an updated
> compiler.

Yes that looks like it could be in this case, since we are getting 0 - 2 rather
2 - 0

That is for:
  _3 = _2 & _9;
  _4 = _3 - _1;
before that patch, it would be doing basically _1 - _3 instead of the above.

[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

--- Comment #7 from Peter Bergner  ---
(In reply to Peter Bergner from comment #6)
> And you guessed well!  I built a mainline compiler for Gordon with Aaron's
> commit reverted and the issue goes away.  Assigning this to Aaron to debug.

Talking with Aaron offline, he pointed me at his
52e130652a76ff3d14c0f572fcd79fa53637ce2c fix which is already upstream. 
Checking my sources, I don't have that, so I will retry with an updated
compiler.

[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
The test cases in comment #4 and comment #5 aren't valid, either in C++ or in
C: it's undefined to modify const-qualified object.

[Bug tree-optimization/101001] New: wrong code at -O3 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

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

Bug ID: 101001
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It affects gcc-8 to the trunk. Gcc-7 works fine.



$ gcc-trunk -v
gcc version 12.0.0 20210609 (experimental) [master revision
174e75a2107:3b61ba37fe1:5bfcfe3087eb05b76395c9efbfc1abbf3f9e1a03] (GCC)


$ gcc-trunk abc.c ; ./a.out
0


$ gcc-trunk -O3 abc.c ; ./a.out
Segmentation fault


$ cat abc.c
int a;
volatile char b;
int main() {
  char c;
  int d, f = 5;
  short e;
  e = 0;
  for (; e != -15; e--) {
d = 0;
for (; d > -16; d = d - 4) {
  f || b;
  c = 0;
  for (; c != 2; c = c - 3)
f = 0;
}
  }
  printf("%X\n", a);
}

[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

Peter Bergner  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |acsawdey at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #6 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #5)
> It is just a guess based on understanding what the RTL would look like and
> what changes were going on in the powerpc backend and the reporter is from
> IBM and you work on the powerpc backend.  Also the code looks correct on
> both aarch64 and x86_64 so I figured it is most likely a target issue.

And you guessed well!  I built a mainline compiler for Gordon with Aaron's
commit reverted and the issue goes away.  Assigning this to Aaron to debug.

[Bug c++/101000] ICE when trying to import the absl/container/flat_hash_map.h as a header module

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
With trunk I see a different ICE:

$ xg++ -std=c++20 -fmodules-ts -xc++-system-header
absl/container/flat_hash_map.h
/usr/include/absl/container/flat_hash_map.h: internal compiler error: in
insert, at cp/module.cc:4797
0xc0c58e trees_out::insert(tree_node*, walk_kind)
/home/mpolacek/src/gcc/gcc/cp/module.cc:4797
0xc172c9 trees_out::decl_value(tree_node*, depset*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:7548
0xc1aecd trees_out::decl_node(tree_node*, walk_kind)
/home/mpolacek/src/gcc/gcc/cp/module.cc:8246
0xc1ef87 trees_out::tree_node(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:9084
0xc3821a module_state::write_cluster(elf_out*, depset**, unsigned int,
depset::hash&, unsigned int*, unsigned int*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:14632
0xc40f2f module_state::write(elf_out*, cpp_reader*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:17735
0xc4738a finish_module_processing(cpp_reader*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:19858
0xb823cb c_parse_final_cleanups()
/home/mpolacek/src/gcc/gcc/cp/decl2.c:5179
0xeb3840 c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.c:1241

[Bug tree-optimization/100925] [12 Regression] tree check fail in make_range_step with -O1 in reassoc

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/100925] [12 Regression] tree check fail in make_range_step with -O1 in reassoc

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Andrew Pinski :

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

commit r12-1349-gd4faa36e7540c573c5dc17850bcd938d0900b2e9
Author: Andrew Pinski 
Date:   Sat Jun 5 21:25:58 2021 -0700

Fix PR 100925: Limit some a?CST1:CST2 optimizations to intergal types only

The problem here is with offset (and pointer) types is we produce
a negative expression when this optimization hits.
It is easier to disable this optimization for all non-integeral types
instead of finding an integer type which is the same precission as the
type to do the negative expression on it.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

PR tree-optimization/100925
* match.pd (a ? CST1 : CST2): Limit transformations
that would produce a negative to integeral types only.
Change !POINTER_TYPE_P to INTEGRAL_TYPE_P also.

gcc/testsuite/ChangeLog:

* g++.dg/torture/pr100925.C: New test.

[Bug c++/101000] New: ICE when trying to import the absl/container/flat_hash_map.h as a header module

[boris.staletic at gmail dot com via Gcc-bugs]

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

Bug ID: 101000
   Summary: ICE when trying to import the
absl/container/flat_hash_map.h as a header module
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris.staletic at gmail dot com
  Target Milestone: ---

Steps to repro:

0. Install Abseil from https://github.com/abseil/abseil-cpp
1. g++ -std=c++20 -fmodules-ts -xc++-system-header
absl/container/flat_hash_map.h
2. g++ -std=c++20 -fmodules-ts main.cpp

Output:

In file included from /usr/include/c++/11.1.0/functional:54,
 from /usr/include/c++/11.1.0/pstl/glue_algorithm_defs.h:13,
 from /usr/include/c++/11.1.0/algorithm:74,
 from /usr/include/absl/algorithm/container.h:43,
 from /usr/include/absl/container/flat_hash_map.h:38,
of module /usr/include/absl/container/flat_hash_map.h, imported at main.cpp:1:
/usr/include/c++/11.1.0/tuple: In instantiation of ‘constexpr std::pair<_T1,
_T2>::pair(std::piecewise_construct_t, std::tuple<_Args1 ...>,
std::tuple<_Args2 ...>) [with _Args1 = {const int&}; _Args2 = {const int&}; _T1
= std::tuple; _T2 = std::tuple]’:
/usr/include/absl/container/internal/container_memory.h:182:52:   required from
‘std::pair, std::tuple >
absl::container_internal::PairArgs(F&&, S&&) [with F = const int&; S = const
int&]’
/usr/include/absl/container/internal/container_memory.h:187:18:   required from
‘std::pair, std::tuple >
absl::container_internal::PairArgs(const std::pair<_T1, _T2>&) [with F = int; S
= int]’
/usr/include/absl/container/internal/container_memory.h:207:35:   required from
‘decltype
(absl::container_internal::memory_internal::DecomposePairImpl(forward(f),
absl::container_internal::PairArgs((forward)(absl::container_internal::DecomposePair::args)...)))
absl::container_internal::DecomposePair(F&&, Args&& ...) [with F =
absl::container_internal::raw_hash_set, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::EmplaceDecomposable; Args =
{const std::pair&}; decltype
(absl::container_internal::memory_internal::DecomposePairImpl(forward(f),
absl::container_internal::PairArgs((forward)(absl::container_internal::DecomposePair::args)...)))
=
std::pair, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::iterator, bool>]’
/usr/include/absl/container/flat_hash_map.h:580:51:   required from ‘static
decltype (absl::container_internal::DecomposePair(declval(),
(declval)()...)) absl::container_internal::FlatHashMapPolicy::apply(F&&, Args&& ...) [with F =
absl::container_internal::raw_hash_set, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::EmplaceDecomposable; Args =
{const std::pair&}; K = int; V = int; decltype
(absl::container_internal::DecomposePair(declval(), (declval)()...)) =
std::pair, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::iterator, bool>]’
/usr/include/absl/container/internal/hash_policy_traits.h:170:20:   required
from ‘static decltype (P::apply(forward(f),
(forward)(absl::container_internal::hash_policy_traits >::apply::ts)...))
absl::container_internal::hash_policy_traits
>::apply(F&&, Ts&& ...) [with F =
absl::container_internal::raw_hash_set, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::EmplaceDecomposable; Ts = {const
std::pair&}; P = absl::container_internal::FlatHashMapPolicy; Policy = absl::container_internal::FlatHashMapPolicy;
 = void; decltype (P::apply(forward(f),
(forward)(absl::container_internal::hash_policy_traits >::apply::ts)...)) =
std::pair, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::iterator, bool>]’
/usr/include/absl/container/internal/raw_hash_set.h:1129:31:   required from
‘std::pair::iterator, bool> absl::container_internal::raw_hash_set::emplace(Args&& ...) [with Args = {const std::pair&};
typename std::enable_if, Hash, Eq, Ts ...>::value,
int>::type  = 0; Policy =
absl::container_internal::FlatHashMapPolicy; Hash =
absl::hash_internal::Hash; Eq = std::equal_to; Alloc =
std::allocator >]’
/usr/include/absl/container/internal/raw_hash_set.h:1085:43:   required from
‘void absl::container_internal::raw_hash_set::insert(InputIt, InputIt) [with InputIt = const std::pair*;
Policy = absl::container_internal::FlatHashMapPolicy; Hash =
absl::hash_internal::Hash; Eq = std::equal_to; Alloc =
std::allocator >]’
/usr/include/absl/container/internal/raw_hash_set.h:817:11:   required from
‘absl::container_internal::raw_hash_set::raw_hash_set(InputIter, InputIter, size_t, const hasher&, const
key_equal&, const allocator_type&) [with InputIter = const std::pair*; Policy = absl::container_internal::FlatHashMapPolicy; Hash =
absl::hash_internal::Hash; Eq = std::equal_to; Alloc =
std::allocator >; size_t = long unsigned int;
absl::container_internal::raw_hash_set::hasher =
absl::hash_internal:

[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Peter Bergner from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > If this is powerpc and on power10, then it is most likely caused by 
> > r12-1020.
> 
> Not arguing with you, but how did you pinpoint this commit?

It is just a guess based on understanding what the RTL would look like and what
changes were going on in the powerpc backend and the reporter is from IBM and
you work on the powerpc backend.  Also the code looks correct on both aarch64
and x86_64 so I figured it is most likely a target issue.

[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"

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

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

--- Comment #5 from Jakub Jelinek  ---
Consider with the same -O2 -fno-early-inlining -fno-tree-sra -fno-tree-fre
flags:

const struct S { unsigned b : 4; unsigned c : 9; } d;
__attribute__((noipa)) void foo (void) {}
static int bar (const struct S l) {
  ((struct S *)&l)->b += 2;
  ((struct S *)&l)->c += 4;
  foo ();
  return l.b + l.c;
}
__attribute__((noipa)) int baz (void) { return 2; }
int main () { const struct S d = { 1, baz () }; bar (d); return d.b - 1; }

This used to exit with 0 in r12-433 but exits with 2 in r12-434.

[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

--- Comment #4 from Peter Bergner  ---
FYI, I'll give Gordon a build without that patch to test with and see if his
issue goes away with that.

[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"

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

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

--- Comment #4 from Jakub Jelinek  ---
Though, SRA isn't really needed, consider following testcase with
-O2 -fno-early-inlining -fno-tree-sra -fno-tree-fre

struct S { unsigned b : 4; unsigned c : 9; } const d;
__attribute__((noipa)) void foo (void) {}
static int bar (const struct S l) {
  ((struct S *)&l)->b += 2;
  ((struct S *)&l)->c += 4;
  foo ();
  return l.b + l.c;
}
int main () { bar (d); return 0; }

This also worked fine with r12-433 and segfaults with r12-434 because it will
store to d.b and d.c (instead of modifying an automatic variable).
But even if it doesn't bind to a static .rodata variable where stores will
segfault, but binds to caller's automatic variable, this binding might change
the caller's variable.

Perhaps the tree-inline.c change is fine for Ada, but it doesn't seem to be
safe for C/C++.

[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.

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

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

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

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

commit r12-1346-g8f0d7f322172d411d271aa02024a342c72534465
Author: H.J. Lu 
Date:   Wed Jun 9 11:56:15 2021 -0700

Update doc/tm.texi.in to fix commit 4a0c4eaea32

PR other/100735
* doc/tm.texi.in (Trampolines): Add a missing blank line.

[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||acsawdey at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #3 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #2)
> If this is powerpc and on power10, then it is most likely caused by r12-1020.

Not arguing with you, but how did you pinpoint this commit?

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[public at timruffing dot de via Gcc-bugs]

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

Tim Ruffing  changed:

   What|Removed |Added

 CC||public at timruffing dot de

--- Comment #18 from Tim Ruffing  ---
Is there still interest in fixing this? This still leads to spurious Valgrind
warnings in the real world.

[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The
  MEM[(struct a *)&l].c = l$c_24;
in the function to be inlined is there since esra.  Arguably it is strange that
esra stores back into the parameter when it is const.
In C/C++ one can cast away the const, but if the parm isn't addressable and
there are no stores to it it shouldn't be modified.

[Bug middle-end/100998] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED
 Target||powerpc

--- Comment #2 from Andrew Pinski  ---
If this is powerpc and on power10, then it is most likely caused by r12-1020.

[Bug middle-end/100998] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||wrong-code
   Last reconfirmed||2021-06-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
So the tree level looks fine for me:

  _1 = (unsigned int) i_5(D);
  _2 = -_1;
  _9 = (unsigned int) m_6(D);
  _3 = _2 & _9;
  _4 = _3 - _1;
  _7 = (int) _4;

 CUT 
This is for:
int f (long int m, long int i)
{
  return ((m & ~(i - 1)) - i);
}

 CUT 
The assembly produced for both x86_64 and aarch64 looks correct.
What target is this on?

[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"

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

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

--- Comment #2 from Jakub Jelinek  ---
The difference after IPA between r12-433 and r12-434 is:
--- pr100994.c.092t.fixup_cfg3_ 2021-06-09 14:26:08.0 -0400
+++ pr100994.c.092t.fixup_cfg3  2021-06-09 14:26:28.0 -0400
@@ -3,7 +3,6 @@

 int main ()
 {
-  const struct a l;
   const  l$c;
   int g.0_4;
   int f.3_5;
@@ -14,8 +13,7 @@ int main ()
   int e.5_10;

[local count: 1073741824]:
-  l = d;
-  l$c_3 = l.c;
+  l$c_3 = 0;

[local count: 9761289362]:
   g.0_4 = g;
@@ -37,8 +35,8 @@ int main ()
 goto ; [50.00%]

[local count: 4343773769]:
-  l.c = l$c_3;
-  _6 = BIT_FIELD_REF ;
+  d.c = l$c_3;
+  _6 = 0;
   _7 = _6 & 15;
   if (_7 != 0)
 goto ; [50.00%]

Note, d is a TREE_STATIC const variable where both members are 0,
so I guess l$c_3 = 0; is ok, but the l.c = l$c_3 to d.c = l$c_3; change is not,
that is what segfaults there.

[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|wrong code with "-O1|[12 Regression] wrong code
   |-finline-small-functions|with "-O1
   |-fipa-cp"   |-finline-small-functions
   ||-fipa-cp"
 CC||ebotcazou at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-09

--- Comment #1 from Jakub Jelinek  ---
That void main should have been int main.
Anyway, started with
r12-434-g93f8cb4965cebee125f96376367f05e18ee5749b

[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||law at gcc dot gnu.org

--- Comment #5 from Jeffrey A. Law  ---
Fixed with Paul's documentation change on the trunk.

[Bug d/100999] New: d: foreach over a tuple doesn't work on 16-bit targets

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 100999
   Summary: d: foreach over a tuple doesn't work on 16-bit targets
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

There is an error if the index type isn't an int or long type.  This triggers
on 16-bit targets where the index would be size_t for looping over an array.
---
alias AliasSeq(TList...) = TList;
alias size_t = ushort;

void foo(int a, int b, int c)
{
// OK
foreach (size_t i, e; [0, 1, 2, 3]) { }

// Errors
static foreach (size_t i, e; [0, 1, 2, 3]) { }
foreach (size_t i, e; AliasSeq!(0, 1, 2, 3)) { }
static foreach (size_t i, e; AliasSeq!(0, 1, 2, 3)) { }
}

[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Buclaw  ---
Fix committed

[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Buclaw  ---
Fix committed.

[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:

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

commit r9-9576-gd0ff449baf8d64819badb1883221b5b7295e7406
Author: Iain Buclaw 
Date:   Wed Jun 9 19:39:28 2021 +0200

d: TypeInfo error when using slice copy on Structs (PR100964)

Known limitation: does not work for struct with postblit or dtor.

gcc/d/ChangeLog:

PR d/100964
* dmd/expression.c (Expression::checkPostblit): Don't generate
TypeInfo when RTTI is disabled.

gcc/testsuite/ChangeLog:

PR d/100964
* gdc.test/compilable/betterCarray.d: Add test cases.

(cherry picked from commit 10d4f283f4177d80cec3c9e8bf447a48cab5bb47)

[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:

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

commit r9-9575-gfe555102dc224b4d946becc8a9db514ecec66161
Author: Iain Buclaw 
Date:   Wed Jun 9 19:37:22 2021 +0200

d: Respect explicit align(N) type alignment (PR100935)

It was previously the natural type alignment, defined as the maximum of
the field alignments for an aggregate.  Make sure an explicit align(N)
overrides it.

gcc/d/ChangeLog:

PR d/100935
* dmd/mtype.c (Type::getProperty): Prefer explicit alignment over
natural alignment for alignof property.

gcc/testsuite/ChangeLog:

PR d/100935
* gdc.test/compilable/aggr_alignment.d: Add test cases.

(cherry picked from commit 3ba036dd1a752d29764ad44adca6e68bec9599fe)

[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:

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

commit r10-9899-gd660f34b6718c5f107fd1f1a2126aec759a6593b
Author: Iain Buclaw 
Date:   Wed Jun 9 19:39:28 2021 +0200

d: TypeInfo error when using slice copy on Structs (PR100964)

Known limitation: does not work for struct with postblit or dtor.

gcc/d/ChangeLog:

PR d/100964
* dmd/expression.c (Expression::checkPostblit): Don't generate
TypeInfo when RTTI is disabled.

gcc/testsuite/ChangeLog:

PR d/100964
* gdc.test/compilable/betterCarray.d: Add test cases.

(cherry picked from commit 10d4f283f4177d80cec3c9e8bf447a48cab5bb47)

[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:

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

commit r10-9898-gf7ece1a32000a9943f5bd5ac597d6ce3829aff8e
Author: Iain Buclaw 
Date:   Wed Jun 9 19:37:22 2021 +0200

d: Respect explicit align(N) type alignment (PR100935)

It was previously the natural type alignment, defined as the maximum of
the field alignments for an aggregate.  Make sure an explicit align(N)
overrides it.

gcc/d/ChangeLog:

PR d/100935
* dmd/mtype.c (Type::getProperty): Prefer explicit alignment over
natural alignment for alignof property.

gcc/testsuite/ChangeLog:

PR d/100935
* gdc.test/compilable/aggr_alignment.d: Add test cases.

(cherry picked from commit 3ba036dd1a752d29764ad44adca6e68bec9599fe)

[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:10d4f283f4177d80cec3c9e8bf447a48cab5bb47

commit r11-8536-g10d4f283f4177d80cec3c9e8bf447a48cab5bb47
Author: Iain Buclaw 
Date:   Wed Jun 9 19:39:28 2021 +0200

d: TypeInfo error when using slice copy on Structs (PR100964)

Known limitation: does not work for struct with postblit or dtor.

gcc/d/ChangeLog:

PR d/100964
* dmd/expression.c (Expression::checkPostblit): Don't generate
TypeInfo when RTTI is disabled.

gcc/testsuite/ChangeLog:

PR d/100964
* gdc.test/compilable/betterCarray.d: Add test cases.

(cherry picked from commit 036e14ca44eaddf329a79d56d556862118b1f220)

[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

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

commit r11-8535-gc6c3ed60276b842114aefce54d73e30e578fdd6d
Author: Iain Buclaw 
Date:   Wed Jun 9 19:37:22 2021 +0200

d: Respect explicit align(N) type alignment (PR100935)

It was previously the natural type alignment, defined as the maximum of
the field alignments for an aggregate.  Make sure an explicit align(N)
overrides it.

gcc/d/ChangeLog:

PR d/100935
* dmd/mtype.c (Type::getProperty): Prefer explicit alignment over
natural alignment for alignof property.

gcc/testsuite/ChangeLog:

PR d/100935
* gdc.test/compilable/aggr_alignment.d: Add test cases.

(cherry picked from commit 04fea2d66bd680beb1a204e62f2f459307000813)

[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:036e14ca44eaddf329a79d56d556862118b1f220

commit r12-1345-g036e14ca44eaddf329a79d56d556862118b1f220
Author: Iain Buclaw 
Date:   Wed Jun 9 19:39:28 2021 +0200

d: TypeInfo error when using slice copy on Structs (PR100964)

Known limitation: does not work for struct with postblit or dtor.

Reviewed-on: https://github.com/dlang/dmd/pull/12648

gcc/d/ChangeLog:

PR d/100964
* dmd/MERGE: Merge upstream dmd 4a4e46a6f.

[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:04fea2d66bd680beb1a204e62f2f459307000813

commit r12-1344-g04fea2d66bd680beb1a204e62f2f459307000813
Author: Iain Buclaw 
Date:   Wed Jun 9 19:37:22 2021 +0200

d: Respect explicit align(N) type alignment (PR100935)

It was previously the natural type alignment, defined as the maximum of
the field alignments for an aggregate.  Make sure an explicit align(N)
overrides it.

Reviewed-on: https://github.com/dlang/dmd/pull/12646

gcc/d/ChangeLog:

PR d/100935
* dmd/MERGE: Merge upstream dmd f3fdeb578.

[Bug c/100998] New: bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'

[fossum at us dot ibm.com via Gcc-bugs]

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

Bug ID: 100998
   Summary: bug in experimental GCC12 with optimization '-O1',
disappears with optimization '-O0'
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fossum at us dot ibm.com
  Target Milestone: ---

(note: m, i and k are "long int", GEMM_UNROLL_M is 256, COMPSIZE is 1, and 
a, c, aa, cc are of type (float *))

Here's a snippet of our code:

===
for (i = 1; i < GEMM_UNROLL_M; i *= 2){
   if (m & i) {
 if (((m & ~(i - 1)) - i) < 0) { 
   fprintf(stderr, "EEK! m = %ld, i = %ld, ((m & ~(i - 1)) - i) = %ld\n", 
 m, i, ((m & ~(i - 1)) - i)); 
   fflush(stderr); 
 }
 aa = a + ((m & ~(i - 1)) - i) * k * COMPSIZE;
 cc = c + ((m & ~(i - 1)) - i) * COMPSIZE;
 ...
 [call a function using aa and cc]
  }
}
===

When we run with -O0, the printout does not occur, and all is well.

When we run with -O1, we see this printout:

EEK! m = 3, i = 1, ((m & ~(i - 1)) - i) = -2

The fact that we get a negative number ends up leading to a 
segfault in the called function, when we try to access the 
first element of the array "aa".

I would be DELIGHTED if you could help me understand that the tested 
construction ((m & ~(i - 1)) - i) is somehow illegal, but I feel like
it should NEVER return a negative value, as long as i is a power of 2,
and (m & i) is not 0.

I'm building this code with GCC12 (a version provided by my colleague
Peter Bergner, and I'm hoping he will add a comment clarifying exactly 
which version of your experimental GCC12 he is using.

[Bug other/100695] Format decoder, quoting in 'dump_printf' etc.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
As an example, can be reproduced e.g. on
./cc1 -quiet -fopt-info-omp-note --param=openacc-privatization=noisy -fopenacc
-O2 .../gcc/testsuite/c-c++-common/goacc/privatization-1-routine_gang-loop.c
when that omp-low.c %<%T%> is changed to %qT.

>From what I see, the quotes for %< are emitted using:
case '<':
  {
obstack_grow (&buffer->chunk_obstack,
  open_quote, strlen (open_quote));
const char *colorstr
  = colorize_start (pp_show_color (pp), "quote");
obstack_grow (&buffer->chunk_obstack, colorstr, strlen (colorstr));
but for %qX using:
  if (quote)
pp_begin_quote (pp, pp_show_color (pp));
and similarly for the closing quote.
In the case of dump_print_*, the characters go into chunk_obstack, while e.g.
what '%T' provides goes to the stashed items or where.

[Bug c++/100825] function signature constraints are not a part of mangled name

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

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

--- Comment #9 from Jonathan Wakely  ---
As comment 7 already said.

[Bug c++/100997] [c++20] parse error when id-expression of constructor is simple-template-id

[felix.morgner at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Felix Morgner  ---
Thank you for the quick response. I will file a bug report with Boost GIL.

[Bug c++/100997] [c++20] parse error when id-expression of constructor is simple-template-id

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

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

--- Comment #2 from Marek Polacek  ---
To make it work just remove the "" in A() {}.

[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||felix.morgner at gmail dot com

--- Comment #4 from Marek Polacek  ---
*** Bug 100997 has been marked as a duplicate of this bug. ***

[Bug c++/100997] [c++20] parse error when id-expression of constructor is simple-template-id

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
This is C++20 DR 2237, disallow simple-template-id in cdtor: see 
[diff.cpp17.class]p2.

The diagnostic should be improved, we have bug 97202 for that.

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

[Bug c++/100997] New: [c++20] parse error when id-expression of constructor is simple-template-id

[felix.morgner at gmail dot com via Gcc-bugs]

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

Bug ID: 100997
   Summary: [c++20] parse error when id-expression of constructor
is simple-template-id
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.morgner at gmail dot com
  Target Milestone: ---

Created attachment 50972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50972&action=edit
Example source file

In C++20 mode, GCC 11.1 rejects the following code:

  template
  struct A;

  template<>
  struct A {
A() {}
  };

With the following error:

  :6:12: error: expected unqualified-id before ')' token

I currently don't have access to my copy of the standard, but working from both
https://wg21.link/std and https://wg21.link/std20, I am under the expression
that this code should be valid since:

According to [class.ctor], the sole id-expression of the ptr-declarator of the
ctors function declarator may be the injected-class-name. [class.pre] tells us
that the class-name of the class being declared is injected into scope of the
class, where it is called the injected-class-name. Moreover, [class.pre]
defines a class-name to be either an indentifier or a simnple-template-id. I
would argue that in the case of the explicit specialization above, A would
be a simple-template-id and thus a valid injected-class-name.

The error does not occur in C++17 mode or in GCC prior to version 11.

Tested in all cases with "-Wall -Wextra -Werror -pedantic-errors"

[Bug c++/100825] function signature constraints are not a part of mangled name

[nickolay.merkin at gmail dot com via Gcc-bugs]

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

Nickolay Merkin  changed:

   What|Removed |Added

 CC||nickolay.merkin at gmail dot 
com

--- Comment #8 from Nickolay Merkin  ---
(In reply to Jonathan Wakely from comment #3)
> Clang and EDG agree with GCC here.
> 
> I think your code is ill-formed due to [temp.constr.atomic] p3:
> 
> "If, at different points in the program, the satisfaction result is
> different for identical atomic constraints and template arguments, the
> program is ill-formed, no diagnostic required."

Of course the constraints are different! First constraint is empty, second is
always-true.
So, these are different overloads.

Okay, let's help the compiler giving different mangled names:

https://gcc.godbolt.org/z/K8d9vv8oT

namespace a {}
namespace b {}

using namespace a;
using namespace b;

namespace a {
template void f() { std::cout << __PRETTY_FUNCTION__ << std::endl; }
}

void g() { f(); }

namespace b {
template void f() requires true { std::cout << __PRETTY_FUNCTION__ <<
std::endl; }
}

void h() { f(); }

g addresses to a::f, h addresses to b::f.

Is this still "ill-formed, no diagnostics required"?
Does it mean that a compiler may produce any corrupted binary code with any
undefined behavior? Just because we wrote same "f()" both times?
I believe, not, it does not.

The program is well-formed.
Both overloads are valid. And both are different, - it is not an ODR violation.

So, the issue is on the compiler's side: wrong rules of mangling.

[Bug c/84595] Add __builtin_break() built-in for a breakpointing mechanism

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

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

--- Comment #12 from Segher Boessenkool  ---
(In reply to H. Peter Anvin from comment #9)
> How is this different from raise(SIGTRAP);?

It does an architecture-specific trap instruction, not a SIGTRAP signal.
The former is useful even if you do not have an OS (or *are* the OS), for
example.

[Bug c/84595] Add __builtin_break() built-in for a breakpointing mechanism

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||segher at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-09

--- Comment #11 from Segher Boessenkool  ---
(In reply to Richard Biener from comment #7)
> I frequently use raise(SIGSTOP) ... (or x86 specific you can do asm ("int
> 3");
> or whatever that break thing was...
> 
> Note I think that a compiler-only-side implementation might not be possible
> on all targets given it might be dependent on OS and debugger preferences
> as well?

Generating a trap instruction is not.  How that then will be handled by
something else is that something else's concern, yes :-)

[Bug libstdc++/100982] wrong constraint in std::optional::operator=

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
   Keywords||rejects-valid

[Bug fortran/100972] Missing error with "implicit none (external)"

[gscfq--- via Gcc-bugs]

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

--- Comment #1 from G. Steinmetz  ---

Similarly, the helpful option -Wimplicit-procedure does not warn :
(-Wimplicit-procedure : Warn if a procedure is called that has neither
an explicit interface nor has been declared as EXTERNAL.)

$ gfortran-12-20210606 -c z1.f90 -Wimplicit-procedure
$

And the following error message refers to "IMPORT" :

$ _g2_v12test -c z1.f90 -std=f2008
z1.f90:2:19:

2 |implicit none (external)
  |   1
Error: Fortran 2018: IMPORT NONE with spec list at (1)

[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:4a0c4eaea320a418400afc4d63359ed6c4af5548

commit r12-1342-g4a0c4eaea320a418400afc4d63359ed6c4af5548
Author: Paul Eggert 
Date:   Wed Jun 9 12:25:26 2021 -0400

Document that -fno-trampolines is for Ada only [PR100735]

gcc/
PR other/100735
* doc/invoke.texi (Code Gen Options); Document that
-fno-trampolines
and -ftrampolines work only with Ada.
* doc/tm.texi.in (Trampolines): Likewise.
* doc/tm.texi: Regenerated.

[Bug fortran/100989] Bogus internal VOLATILE attribute for ASYNCHRONOUS

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug fortran/100989] Bogus internal VOLATILE attribute for ASYNCHRONOUS

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Thomas Koenig  ---
F2018, 8.5.4:

" An entity with the ASYNCHRONOUS attribute is a variable, and may be subject
to asynchronous input/output or asynchronous communication."

So, the variable can be changed without going through normal program
flow.  A pointer marked as escaping isn't enough, because there can
also be a change during code which does not invoke any other procedures.
(such as by an MPI call).

If volatile isn't the right model, what is?

[Bug c++/100995] Extend std::is_constant_evaluated in if warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
namespace std {
  constexpr inline bool
  is_constant_evaluated () noexcept
  {
return __builtin_is_constant_evaluated ();
  }
}

int
foo ()
{
  if (std::is_constant_evaluated ())
return 1;
  return 0;
}

constexpr int
bar ()
{
  if (std::is_constant_evaluated ())
return 1;
  if constexpr (std::is_constant_evaluated ())
return 2;
  return 0;
}

consteval int
baz ()
{
  if (std::is_constant_evaluated ())
return 1;
  return 0;
}

In foo, we know it will always evaluate to false, in baz always to true.
In non-constexpr functions it will not evaluate everywhere to false, so one
would need to leave out e.g. initializers of static variables and the other
spots which are manifestly constant evaluated.
But say if conditions except for statement expressions in them and if it is not
the init might be always ok and good enough for the warning.

[Bug middle-end/53267] Constant fold BUILT_IN_FMOD

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug middle-end/53267] Constant fold BUILT_IN_FMOD

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug c/84595] Add __builtin_break() built-in for a breakpointing mechanism

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||christophe.leroy at csgroup 
dot eu

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

[Bug middle-end/99299] Need a recoverable version of __builtin_trap()

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Dup of bug 84595.

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

[Bug target/100996] rs6000 p10 vector add-add fusion should work with -m32 but doesn't

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

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target||powerpc-*-*-*
   Last reconfirmed||2021-06-09
   Assignee|unassigned at gcc dot gnu.org  |acsawdey at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug target/100996] New: rs6000 p10 vector add-add fusion should work with -m32 but doesn't

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

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

Bug ID: 100996
   Summary: rs6000 p10 vector add-add fusion should work with -m32
but doesn't
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
  Target Milestone: ---

The fusion-p10-addadd.c test case does not get vector add-add fusion when
compiling with -m32:

/home/sawdey/work/gcc/trunk/build/gcc/xgcc
-B/home/sawdey/work/gcc/trunk/build/gcc/
/home/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.target/powerpc/fusion-p10-addadd.c
 -m32  -fdiagnostics-plain-output  -mcpu=power10 -O3 -dap -fno-ident -S

typedef vector long vlong;
vlong vaddadd(vlong a, vlong b, vlong c)
{
  return a+b+c;
}

vaddadd:
.LFB3:
.cfi_startproc
vadduwm 2,2,3# 8[c=4 l=4]  addv4si3
vadduwm 2,2,4# 14   [c=4 l=4]  addv4si3
blr  # 24   [c=4 l=4]  simple_return
.cfi_endproc

[Bug middle-end/53267] Constant fold BUILT_IN_FMOD

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r12-1332-g2c17b5f8cca82d1957242055991a2c23184a1af1
Author: Roger Sayle 
Date:   Wed Jun 9 11:23:41 2021 -0400

[PATCH] PR middle-end/53267: Constant fold BUILT_IN_FMOD.

gcc/ChangeLog
PR middle-end/53267
* fold-const-call.c (fold_const_call_sss) [CASE_CFN_FMOD]:
Support evaluation of fmod/fmodf/fmodl at compile-time.

gcc/testsuite/ChangeLog
* gcc.dg/builtins-70.c: New test.

[Bug libstdc++/100992] Wrong result for is_constructible for const ref of tuple of tuples

[kirshamir at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Amir Kirsh  ---
Maybe a dup of:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592

[Bug c++/100995] Extend std::is_constant_evaluated in if warning

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||diagnostic
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-06-09

[Bug c++/100995] New: Extend std::is_constant_evaluated in if warning

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

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

Bug ID: 100995
   Summary: Extend std::is_constant_evaluated in if warning
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Let's extend the existing warning to detect more cases, as in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1938r3.html#compiler-warnings

constexpr int f1() {
  if constexpr (!std::is_constant_evaluated() && sizeof(int) == 4) { //
warning: always true
return 0;
  }
  if (std::is_constant_evaluated()) {
return 42;
  } else {
if constexpr (std::is_constant_evaluated()) { // warning: always true
  return 0;
}
  }
  return 7;
}


consteval int f2() {
  if (std::is_constant_evaluated() && f1()) { // warning: always true
return 42;
  }
  return 7;
}


int f3() {
  if (std::is_constant_evaluated() && f1()) { // warning: always false
return 42;
  }
  return 7;
}

[Bug libstdc++/100992] Wrong result for is_constructible for const ref of tuple of tuples

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|c++ |libstdc++
   Last reconfirmed||2021-06-09
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
I think this is a dup

[Bug tree-optimization/100981] [11 Regression] ICE in info_for_reduction, at tree-vect-loop.c:4897

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE in info_for_reduction,  |[11 Regression] ICE in
   |at tree-vect-loop.c:4897|info_for_reduction, at
   ||tree-vect-loop.c:4897
   Target Milestone|--- |11.2
  Known to work||12.0
   Priority|P3  |P2

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar, the issue is most likely latent on the branch.

[Bug tree-optimization/100981] ICE in info_for_reduction, at tree-vect-loop.c:4897

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

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

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

https://gcc.gnu.org/g:374f93da97fb0378453d503f3cfea4d7a923a89c

commit r12-1330-g374f93da97fb0378453d503f3cfea4d7a923a89c
Author: Richard Biener 
Date:   Wed Jun 9 14:48:35 2021 +0200

tree-optimization/100981 - fix SLP patterns involving reductions

The following fixes the SLP FMA patterns to preserve reduction
info and the reduction vectorization to consider internal function
call defs for the reduction stmt.

2021-06-09  Richard Biener  

PR tree-optimization/100981
gcc/
* tree-vect-loop.c (vect_create_epilog_for_reduction): Use
gimple_get_lhs to also handle calls.
* tree-vect-slp-patterns.c (complex_pattern::build): Transfer
reduction info.

gcc/testsuite/
* gfortran.dg/vect/pr100981-1.f90: New testcase.

libgomp/
* testsuite/libgomp.fortran/pr100981-2.f90: New testcase.

[Bug ipa/100994] New: wrong code with "-O1 -finline-small-functions -fipa-cp"

[suochenyao at 163 dot com via Gcc-bugs]

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

Bug ID: 100994
   Summary: wrong code with "-O1 -finline-small-functions
-fipa-cp"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suochenyao at 163 dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
struct a {
  unsigned b : 4;
  unsigned c : 9;
} const d;
int e, f, g;
char h;
short i;
static int(j)() { return 0; }
static int k(const struct a l) {
  for (; g; j() & l.c)
;
  e = 1;
  i = e + 6;
  for (; e != 7; e = i)
h = f || l.b;
  int m = l.c;
  return 0;
}
void main() { k(d); }
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/data/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/data/bin/gcc-dev --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210608 (experimental) (GCC)

git version: 1afa4facb9348cac0349ff9c30066aa25a3608f7
***
Command Lines:
$ gcc -O1 -finline-small-functions -fipa-cp -Wall -Wextra -fno-strict-aliasing
-fwrapv a.c -o a1.out
a.c: In function ‘k’:
a.c:10:17: warning: value computed is not used [-Wunused-value]
   10 |   for (; g; j() & l.c)
  | ^
a.c:16:7: warning: unused variable ‘m’ [-Wunused-variable]
   16 |   int m = l.c;
  |   ^
a.c: At top level:
a.c:19:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
   19 | void main() { k(d); }
  |  ^~~~
$ /data/bin/gcc-dev/bin/gcc a.c -o a2.out
$ ./a1.out
Segmentation fault (core dumped)
$ ./a2.out
$

[Bug c++/100974] [C++23] Implement if consteval

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 50971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50971&action=edit
gcc12-pr100974.patch

Untested implementation.

[Bug c++/96560] Substitution triggers compile-time error when it shouldn't

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Marek Polacek  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569184.html

[Bug c/100993] New: ICE with -O2: Segmentation fault, cgraph_update_edges_for_call_stmt(gimple*, tree_node*, gimple*)

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 100993
   Summary: ICE with -O2: Segmentation fault,
cgraph_update_edges_for_call_stmt(gimple*, tree_node*,
gimple*)
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210609 (experimental) [master revision
:c23bc3c72:87f9ac937d6cfd81cbbe0a43518ba10781888d7c] (GCC)

$ cat mutant.c
__builtin_acc_on_device(dev) { return __builtin_acc_on_device(dev); }

$ gcc-trunk -O2 mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | __builtin_acc_on_device(dev) { return __builtin_acc_on_device(dev); }
  | ^~~
mutant.c: In function ‘__builtin_acc_on_device’:
mutant.c:1:1: warning: type of ‘dev’ defaults to ‘int’ [-Wimplicit-int]
during IPA pass: inline
In function ‘__builtin_acc_on_device’:
cc1: internal compiler error: Segmentation fault
0xf091b3 crash_signal
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/toplev.c:327
0xa826d0 cgraph_update_edges_for_call_stmt(gimple*, tree_node*, gimple*)
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraph.c:1729
0xf8bdcd fold_marked_statements
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/tree-inline.c:5384
0xf9bf87 tree_function_versioning(tree_node*, tree_node*, vec*, ipa_param_adjustments*, bool, bitmap_head*,
basic_block_def*)
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/tree-inline.c:6457
0xcc1f1b save_inline_function_body
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/ipa-inline-transform.c:658
0xcc1f1b inline_transform(cgraph_node*)
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/ipa-inline-transform.c:750
0xe1c8f4 execute_one_ipa_transform_pass
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/passes.c:2290
0xe1c8f4 execute_all_ipa_transforms(bool)
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/passes.c:2337
0xa89639 cgraph_node::expand()
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:1821
0xa8aa5f expand_all_functions
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:1992
0xa8aa5f symbol_table::compile()
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:2356
0xa8d95b symbol_table::compile()
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:2269
0xa8d95b symbol_table::finalize_compilation_unit()
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug tree-optimization/100981] ICE in info_for_reduction, at tree-vect-loop.c:4897

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

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

--- Comment #6 from avieira at gcc dot gnu.org ---
FYI Tamar asked me to make sure the instructions were being generated. I
checked and they were, but not being used as it decides to inline MAIN__ and
inlining seems to break (as in not apply/missed oppurtunity) the complex
optimization.

So for this specific test I'd use -fno-inline, it executes the fcmla
instructions that way and it runs fine.

[Bug c++/97375] Unexpected top-level const retainment when declaring non-type template paramter with decltype(auto)

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Fixed on trunk by r12-1224.  Maybe we want to backport that to 11 too.

[Bug c++/100065] Conditional explicit doesn't work for deduction guide

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/100065] Conditional explicit doesn't work for deduction guide

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

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

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

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

commit r11-8534-g0a9d8fd580d6afab669bae68e116e2135c2a8670
Author: Marek Polacek 
Date:   Mon Jun 7 16:06:00 2021 -0400

c++: explicit() ignored on deduction guide [PR100065]

When we have explicit() with a value-dependent argument, we can't
evaluate it at parsing time, so cp_parser_function_specifier_opt stashes
the argument into the decl-specifiers and grokdeclarator then stores it
into explicit_specifier_map, which is then used when substituting the
function decl.  grokdeclarator stores it for constructors and conversion
functions, but we also need to do it for deduction guides, otherwise
we'll forget that we've seen an explicit-specifier as in the attached
test.

PR c++/100065

gcc/cp/ChangeLog:

* decl.c (grokdeclarator): Store a value-dependent
explicit-specifier even for deduction guides.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/explicit18.C: New test.

(cherry picked from commit 1afa4facb9348cac0349ff9c30066aa25a3608f7)

[Bug c++/100992] New: Wrong result for is_constructible for const ref of tuple of tuples

[kirshamir at gmail dot com via Gcc-bugs]

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

Bug ID: 100992
   Summary: Wrong result for is_constructible for const ref of
tuple of tuples
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kirshamir at gmail dot com
CC: kirshamir at gmail dot com
  Target Milestone: ---

The second static_assert below fails, should pass:

#include 

struct F {
F() { }
F(const std::tuple& foo) {}
};

static_assert(std::is_constructible_v&>);
static_assert(std::is_constructible_v>&>); //
fails, unjustifiably

int main() {
F f1{std::tuple{F{}}};
auto tup = std::tuple{std::tuple{f1}};
F f2{tup}; // constructible
}

https://godbolt.org/z/3KfbxfhWE