[Bug target/103066] __sync_val_compare_and_swap/__sync_bool_compare_and_swap aren't optimized

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongyu Wang  ---
__sync_val_compare_and_swap will be expanded to atomic_compare_exchange_strong
by default, should we restrict the check and return under
atomic_compare_exchange_weak which is allowed to fail spuriously?

[Bug target/102991] [12 regression] gcc.dg/vect/vect-simd-17.c fails after r12-4757

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

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

--- Comment #7 from luoxhu at gcc dot gnu.org ---
Fixed, will backport to gcc-11 in a week.

[Bug target/102991] [12 regression] gcc.dg/vect/vect-simd-17.c fails after r12-4757

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Xiong Hu Luo :

https://gcc.gnu.org/g:614b39757b8b61f70ac1c666edb7a01a5fc19cd4

commit r12-4930-g614b39757b8b61f70ac1c666edb7a01a5fc19cd4
Author: Xionghu Luo 
Date:   Wed Nov 3 20:23:03 2021 -0500

rs6000: Fix incorrect fusion constraint [PR102991]

gcc/ChangeLog:

2021-11-05  Xionghu Luo  

PR target/102991
* config/rs6000/fusion.md: Regenerate.
* config/rs6000/genfusion.pl: Fix incorrect clobber constraint.

[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |sandra at gcc dot 
gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
Patch posted:

https://gcc.gnu.org/pipermail/fortran/2021-November/056906.html

[Bug tree-optimization/102714] [10 Regression] A volatile-related problem cased by ipa inline pass

[duan.db at linux dot alibaba.com via Gcc-bugs]

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

--- Comment #10 from Bo Duan  ---
(In reply to Richard Biener from comment #7)
> (In reply to Bo Duan from comment #6)
> > Hello, should we backport this patch to gcc-10?
> 
> It's scheduled for a backport to GCC 11, I'm not aware that GCC 10 is
> affected?

Hi, I am going to backport this patch to GCC 10, is it ok for you？

[Bug target/103090] [i386] GCC should use the SF and ZF flags in some atomic_fetch_op sequences

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #1 from Thiago Macieira  ---
One more:

bool tsign3(std::atomic )
{
// any two or more bits, so long as the sign bit is one of them 
// (or the compiler doesn't know what's in the variable)
int bits = 1 | signbit; 
return i.fetch_and(bits, std::memory_order_relaxed) & signbit;
}

[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression

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

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

--- Comment #7 from Martin Sebor  ---
Both for the purposes of the warning (which can be more restrictive than what
the language considers valid), and in the C language, the semantics of the ->
expression depend on the first operand designating an object.  In C they're
defined like so:

  A postfix expression followed by the -> operator and an identifier designates
a member of a structure or union object.  The value is that of the named member
of the object to which the first expression points, and is an lvalue. 106)

Footnote 106) If  is a valid pointer expression (where & is the "address-of"
operator, which generates a pointer to its operand), the expression ()->MOS
is the same as E.MOS .

[Bug c++/55227] designated initializer for char array by string constant

[wjwray at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Will Wray  ---
Created attachment 51737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51737=edit
Proposed patch Nov 4

Sent to gcc-patches for review
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583379.html

This patch aims to fix PR 55227; two underlying bugs that have caused:

(1) Rejection of valid designated initialization of char array fields by
string literals (a) when enclosed in optional braces or (b) unbraced
when the string literal is shorter than the target char array field.

(2) Acceptance of an invalid designator appearing within the braces of a
braced string literal, in which case the 'designator' was entirely
ignored and the string literal treated as a positional initializer.

[Bug libstdc++/103086] [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

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

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

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far.

The fix needs to be backported to gcc-11 because std::tuple uses
[[no_unique_address]] there, so the bug is present.

I think it's also present on older branches, but would only show up for a
unique_ptr with a non-empty pointer and non-empty deleter. I don't think we
test that, but I will check if it fails with GDB 11 and backport the fix if
needed.

[Bug libstdc++/103086] [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

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

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

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

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

commit r12-4928-ga634928f5c8a281442ac8f5fb1636aed048ed72c
Author: Jonathan Wakely 
Date:   Thu Nov 4 22:50:02 2021 +

libstdc++: Fix pretty printing of std::unique_ptr [PR103086]

Since std::tuple started using [[no_unique_address]] the tuple
member of std::unique_ptr has two _M_head_impl subobjects, in
different base classes. That means this printer code is ambiguous:

tuple_head_type = tuple_impl_type.fields()[1].type   # _Head_base
head_field = tuple_head_type.fields()[0]
if head_field.name == '_M_head_impl':
self.pointer = tuple_member['_M_head_impl']

In older versions of GDB it happened to work by chance, because GDB
returned the last _M_head_impl member and std::tuple's base classes are
stored in reverse order, so the last one was the T* element of the
tuple. Since GDB 11 it returns the first _M_head_impl, which is the
deleter element.

The fix is for the printer to stop using an ambiguous field name and
cast the tuple to the correct base class before accessing the
_M_head_impl member.

Instead of fixing this in both UniquePointerPrinter and StdPathPrinter a
new unique_ptr_get function is defined to do it correctly. That is
defined in terms of new tuple_get and _tuple_impl_get functions.

It would be possible to reuse _tuple_impl_get to access each element in
StdTuplePrinter._iterator.__next__, but that already does the correct
casting, and wouldn't be much simpler anyway.

libstdc++-v3/ChangeLog:

PR libstdc++/103086
* python/libstdcxx/v6/printers.py (_tuple_impl_get): New helper
for accessing the tuple element stored in a _Tuple_impl node.
(tuple_get): New function for accessing a tuple element.
(unique_ptr_get): New function for accessing a unique_ptr.
(UniquePointerPrinter, StdPathPrinter): Use unique_ptr_get.
* python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker): Cast
tuple to its base class before accessing _M_head_impl.

[Bug libstdc++/103086] [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

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

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

--- Comment #1 from Jonathan Wakely  ---
This affects the filesystem::path printer too:

  impl = self.val['_M_cmpts']['_M_impl']['_M_t']['_M_t']['_M_head_impl']

[Bug target/103069] cmpxchg isn't optimized

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #2 from Thiago Macieira  ---
See also bug 103090 for a few more (restricted) possibilities to replace a
cmpxchg loop with a LOCK RMW operation.

[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #29 from Thiago Macieira  ---
New suggestion in bug 103090

[Bug middle-end/103090] New: [i386] GCC should use the SF and ZF flags in some atomic_fetch_op sequences

[thiago at kde dot org via Gcc-bugs]

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

Bug ID: 103090
   Summary: [i386] GCC should use the SF and ZF flags in some
atomic_fetch_op sequences
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

Disclaimer: I don't know this code actually exists anywhere. But I've just come
up with it.

In Bug 102566, we optimised:

bool tbit(std::atomic )
{
return i.fetch_or(1, std::memory_order_relaxed) & 1;
}

To emit LOCK BTS. Similarly, fetch_xor got LOCK BTC and fetch_and got LOCK BTR.
These all work because CF is set by the bit-test-and-op instructions.

It occurs to me that LOCK AND, LOCK OR and LOCK XOR reliably set the SF, ZF,
and PF flags according to the result, so they may be used too. I can't think of
any time the PF flag would be useful and obviously ZF will not be set after a
LOCK OR (unless you OR'ed zero, but why would you do that?).

So possibilities are:

static constexpr int signbit = 0x8000;
bool tsign1(std::atomic )
{
int bit = 1; // any one or more bits, except for a constant sign bit
return i.fetch_or(bit, std::memory_order_relaxed) & signbit;
}
bool tsign2(std::atomic )
{
int bit = 1; // any one or more bits, except for a constant sign bit
return i.fetch_xor(bit, std::memory_order_relaxed) & signbit;
}
bool tzero1(std::atomic )
{
int bits = 1; // any one or more bits
return i.fetch_and(bit, std::memory_order_relaxed) == 0;
}
bool tzero2(std::atomic )
{
int bits = 1; // any one or more bits
return i.fetch_xor(bit, std::memory_order_relaxed) == 0;
}

all of the above can be negated too (op != 0 and (op & signbit) == 0).

[Bug tree-optimization/103089] -Wmaybe-uninitialized -O2 false positive

[xantares09 at hotmail dot com via Gcc-bugs]

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

xantares09 at hotmail dot com changed:

   What|Removed |Added

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

--- Comment #3 from xantares09 at hotmail dot com ---
my bad, thanks for the reply

[Bug tree-optimization/103089] -Wmaybe-uninitialized -O2 false positive

[xantares09 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from xantares09 at hotmail dot com ---
indeed, I assumed both were positive, I guess there's no bug then

[Bug tree-optimization/103089] -Wmaybe-uninitialized -O2 false positive

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

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

--- Comment #1 from Andrew Pinski  ---
If I add:

  if (n <= 0 || m <= 0) __builtin_unreachable();
before the malloc, I get no warning.
I think the warning is correct if either n or m is negative.

[Bug c++/97121] ICE (segfault) on incorrect default three-way comparison declaration

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #6 from Jonathan Wakely  ---
Fixed in gcc 11.

[Bug c/103089] New: -Wmaybe-uninitialized -O2 false positive

[xantares09 at hotmail dot com via Gcc-bugs]

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

Bug ID: 103089
   Summary: -Wmaybe-uninitialized -O2 false positive
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xantares09 at hotmail dot com
  Target Milestone: ---

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

on this example gcc 11.2, 11.1 gives a false positive for -Wmaybe-uninitialized
(at O2 only)


$ gcc -c -O2 -Wmaybe-uninitialized ks.c
ks.c: In function ‘DurbinMatrix’:
ks.c:21:18: warning: ‘*H_67 + _146’ may be used uninitialized
[-Wmaybe-uninitialized]
   21 |   H[(m - 1) * m] += (2 * h - 1 > 0 ? pow (2 * h - 1, (double) m) : 0);
  |  ^~
ks.c:21:18: warning: ‘*H_67 + _146’ may be used uninitialized
[-Wmaybe-uninitialized]


we can see the whole H array is initialized because H[i * m + j] covers the
whole (0, m*m( range:

H = (double *) malloc ((m * m) * sizeof (double));
  for (i = 0; i < m; i++)
for (j = 0; j < m; j++)
  if (i - j + 1 < 0)
H[i * m + j] = 0;
  else
H[i * m + j] = 1;

[Bug other/103088] New: [12 regression] 500.perlbench from spec 2017 fails since r12-4698

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

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

Bug ID: 103088
   Summary: [12 regression] 500.perlbench from spec 2017 fails
since r12-4698
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f6d012338bf87f427b7420f2f309963c29fe33ba, r12-4698

commit f6d012338bf87f427b7420f2f309963c29fe33ba (HEAD)
Author: Aldy Hernandez 
Date:   Wed Oct 20 07:29:25 2021 +0200

Try to resolve paths in threader without looking further back.


I am seeing a strange problem starting with this revision.  The spec 2017 test
case 500.perlbench is producing a few extraneous lines of output which is
causing it to fail.

seurer@muskie:~/gcc/cpu2017$ diff
./benchspec/CPU/500.perlbench_r/data/refrate/output/diffmail.4.800.10.17.19.300.out

./benchspec/CPU/500.perlbench_r/run/run_peak_refrate_none./diffmail.4.800.10.17.19.300.out
3257a3258
> Minimum abstol: nan   
3259a3261
> Minimum reltol: nan   
3507a3510
> Minimum abstol: nan   
3509a3513
> Minimum reltol: nan   
3694a3699
> Minimum abstol: nan   
3696a3702
> Minimum reltol: nan   
3818a3825
> Minimum abstol: nan   
3820a3828
> Minimum reltol: nan   


These extra lines come from here in the perl code:

if ($opts->{'calctol'}) {
push @errstats, 'Calculated tolerances:';
foreach my $type (qw(abstol reltol obiwan skiptol)) {
if (exists($max->{$type}) && ($max->{$type} >= 0)) {
push @errstats, sprintf "Maximum $type: %-10.5e",
$max->{$type};
}
if (exists($min->{$type}) && ($min->{$type} >= 0)) {
push @errstats, sprintf "Minimum $type: %-10.5e",
$min->{$type};
}
if (exists($errcnt->{$type}) && ($errcnt->{$type} >= 0)) {
push @errstats, "# of $type errors: ".$errcnt->{$type};
}
if (exists($opts->{"skip$type"}) && ($opts->{"skip$type"} > 0)) {
push @errstats, "# of skip$type unused: ".$opts->{"skip$type"};
}
}
}

So it appears that either the results of the perl exists function changed or
the values that are being checked did not exist before but do now.

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from seurer at gcc dot gnu.org ---
FWIW I see this on powerpc64 as well.

[Bug ipa/103073] [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578 since r12-4401-gfecd145359fc981b

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

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

--- Comment #6 from Martin Liška  ---
> BTW, should I add new bugs to the meta-bug before or after they were
> confirmed?

Right after you create it I would say.

[Bug ipa/103082] [12 Regression] gcc/poly-int.h:1162:5: runtime error: left shift of negative value -40

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Shifting a negative value left is well defined in C++20, but undefined in C++11
.. C++17.
I guess one possibility would be to cast to poly_uint64 and back, another one
would be to do (a.parm_offset - parm_offset) * BITS_PER_UNIT and let the
compiler optimize it.

[Bug target/103085] [12 Regression] -fPIC and -fstack-protector-strong broken AArch64

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

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-11-04
   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Wilco  ---
Yes there is something hacky about the way the salt thingy works. It adds some
unspec around a memory operand and still expects the standard movdi pattern to
recognize it.

It looks like adding support for CONST in Usw constraint and stripping the salt
before checking the symbol in mov_operand_p fixes it. I'm testing a patch.

[Bug fortran/103058] [12 Regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Looking at the particular ICE, this looks like a fortran frond-end issue -
> this is during compilation and not during link and I do not see why Fortran
> should produce nested function with external linkage.
> I comitted a patch that silences the ICE, but it would be nice to make the
> function static for Fortran.
> 
> Changing component to fortran.

Can you attach a reproducer?

[Bug c++/102869] [11/12 Regression] Expansion pattern 'std::integer_sequence' contains no parameter packs

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Started with r11-7931.  Reduced rejects-valid testcase:


template struct integer_sequence;

template
using make_index_sequence = integer_sequence<__integer_pack(_Num)...>;

template struct Tuple;

template using tuple_t = Tuple...>;

template
void f() {
  tuple_t t;
}

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #8 from Aaron Ballman  ---
(In reply to M Welinder from comment #6)
> elaborated-enum-specifier can be a elaborated-type-specifier.  It is in the
> "enum Hog H;" case.
> 
> But elaborated-enum-specifier is NOT an elaborated-type-specifier in the
> "using enum Hog;" case,
> 
> See http://eel.is/c++draft/enum.udecl -- this uses elaborated-enum-specifier
> directly.

You're correct about the productions, but http://eel.is/c++draft/dcl.type.elab
then provides no semantics whatsoever for what type is referred to by an
elaborated-enum-specifier. https://eel.is/c++draft/dcl.type.elab#6 would not
apply, so the only requirement on the type then comes from
http://eel.is/c++draft/enum.udecl#1, which says that the type referred to must
be a reachable enum-specifier. But the type named isn't a reachable
enum-specifier (maybe, who knows, no semantics means we can't really say), it's
a type alias to an enum-specifier. So there's confusion either way you read it,
IMO.

(In reply to M Welinder from comment #7)
> Maybe kick it up to the C++ people?
>
> Note, that if the code is not allowed then a type alias is no longer as
> powerful as the original type.  I really doubt that was intended.

FWIW, my initial inclination was that Clang and ICC were wrong to reject
because this does seem like a useful construct that should be supported. It is
possible there's a Core issue here and that this should not be rejected. The
original paper on the topic doesn't say anything, and I didn't see a mention of
type aliases in the WG21 wiki discussions for the paper, but it's entirely
possible I missed something while looking. So I agree that it'd be useful to
allow this, but I'm not convinced the standard permits it currently.

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #7 from M Welinder  ---
Maybe kick it up to the C++ people?

Note, that if the code is not allowed then a type alias is no longer as
powerful as the original type.  I really doubt that was intended.

[Bug tree-optimization/102981] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #4 from Jeffrey A. Law  ---
I have no strong opinions about this specific testcase.  More generally I am in
agreement with Zdenek and others that the threaders should not be peeling
iterations off loops or rotating loops.

Fundamentally the threaders don't have the kind of costing model to know if
peeling an iteration off is profitable or not.  So even after the loop
optimizers are done, I'd still lean against peeling since if it was profitable
it should have been done by the loop optimizer or vectorizer.

So unless someone can show this is a significant issue in real world code, I
would  argue that it ought to be fixed by including the possibility of
eliminating unreachable code int he profitibility analysis for loop peeling by
the loop optimizers and possibly the unroller (for this specific example).

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #6 from M Welinder  ---
elaborated-enum-specifier can be a elaborated-type-specifier.  It is in the
"enum Hog H;" case.

But elaborated-enum-specifier is NOT an elaborated-type-specifier in the "using
enum Hog;" case,

See http://eel.is/c++draft/enum.udecl -- this uses elaborated-enum-specifier
directly.

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #5 from Aaron Ballman  ---
(In reply to Marek Polacek from comment #4)
> But elaborated-enum-specifier is an elaborated-type-specifier, so
> [dcl.type.elab]#6 should still apply, right?

That is my understanding. Otherwise p6 doesn't make much sense when it says
"The class-key or enum keyword present in the elaborated-type-specifier shall
agree" because that production has no enum keyword directly within it.

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

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

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

--- Comment #4 from Marek Polacek  ---
But elaborated-enum-specifier is an elaborated-type-specifier, so
[dcl.type.elab]#6 should still apply, right?

[Bug target/103028] ICE in extract_constrain_insn, at recog.c:2670

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

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

--- Comment #3 from Andreas Krebbel  ---
So I think what is needed is something like this:

diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 017944f4f79a..1f5b9476ac2e 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -4341,7 +4341,8 @@ find_if_header (basic_block test_bb, int pass)
   && cond_exec_find_if_block (_info))
 goto success;

-  if (targetm.have_trap ()
+  if (!reload_completed
+  && targetm.have_trap ()
   && optab_handler (ctrap_optab, word_mode) != CODE_FOR_nothing
   && find_cond_trap (test_bb, then_edge, else_edge))
 goto success;

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #3 from M Welinder  ---
I actually think gcc is right there.

http://eel.is/c++draft/dcl.type.elab#nt:elaborated-enum-specifier

There are requirements for elaborated-type-specifier, but none for 
elaborated-enum-specifier.  It's a separate production.

[Bug ipa/103073] [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578 since r12-4401-gfecd145359fc981b

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #5 from Jan Hubicka  ---
OK, after some inlining we produce an access past the end of array which makes
get_base_ref_and_extend to produce an access with size==8 and max_size==0.
Modref access merging is built on an assumption that max_size>size (if both are
known).

The access is (*g_18(D))[3][_207];:
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x773ebb28 precision:1 min  max 
pointer_to_this >

arg:0 
type_6 BLK
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x77534dc8 domain >

arg:0 

arg:0 
visited var 
def_stmt GIMPLE_NOP
version:18
ptr-info 0x77541f60>
arg:1 
tt.C:5:14 start: tt.C:5:11 finish: tt.C:5:14>
arg:1 
tt.C:5:17 start: tt.C:5:11 finish: tt.C:5:17>
arg:1 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x773eb690 precision:32 min  max 
pointer_to_this >
visited
def_stmt _207 = _293 + 21;
version:207
ptr-info 0x77567860>
tt.C:5:24 start: tt.C:5:11 finish: tt.C:5:24>

and we get maxsize reduced based on value range info:
582   TYPE_PRECISION (sizetype));
583 woffset *= wi::to_offset (unit_size);
584 woffset <<= LOG2_BITS_PER_UNIT;
585 bit_offset += woffset;
586 if (known_size_p (maxsize))
587   maxsize -= woffset;
588   }
589   }
590   }
(gdb) p woffset
$114 = { > >> =
{coeffs = {{> = {val = {168, 0, 140737488345944},
len = 1}, static is_sign_extended = true}}}, }
(gdb) p maxsize
$115 = { > >> =
{coeffs = {{> = {val = {168, 0, 140737488346016},
len = 1}, static is_sign_extended = true}}}, }

I suppose we can ignore such paradoxical range becuase executing that code
undefined.  But I think we may want to handle this in alias oracle as well?

[Bug ada/103070] [12 regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Component|ipa |ada
   Last reconfirmed||2021-11-04

--- Comment #1 from Jan Hubicka  ---
Confirmed. Also reproduces on x86_64-linux.

The test is checking that nested functions are not interposable.  I think all
nested functions should be static since they can not be called cross-module
(since their ABI depends on outer function frame layout).  So I think this
would be best fixed on Ada frotend side.

Note that I have silenced the sanity check for now to unbreak some Fortran
builds.

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||terra at gnome dot org

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

[Bug c++/103087] "using enum" possibly incorrectly accepted

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Dup.

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

[Bug c++/103087] New: "using enum" possibly incorrectly accepted

[terra at gnome dot org via Gcc-bugs]

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

Bug ID: 103087
   Summary: "using enum" possibly incorrectly accepted
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

See https://bugs.llvm.org/show_bug.cgi?id=52403

enum class Pig { Oink };
using Hog = Pig;
using enum Hog;

gcc 11.1 accepts this code.  clang13 does not.

https://en.cppreference.com/w/cpp/language/enum suggests this should be valid.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html suggests
it should be valid.

http://eel.is/c++draft/enum.udecl suggests invalid.

[Bug libstdc++/103086] [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||11.2.1, 12.0
   Target Milestone|--- |11.3
  Known to work||10.3.0
   Last reconfirmed||2021-11-04
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/103086] New: [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

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

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

Bug ID: 103086
   Summary: [11/12 Regression] std::unique_ptr printer gets
confused by [[no_unique_address]] in tuple
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

When using GDB 11 or 12 and GCC 11 or 12 the pretty printer for std::unique_ptr
shows the value of the deleter instead of the pointer:

$1 = std::unique_ptr = {get() = {}}

I filed this as https://sourceware.org/bugzilla/show_bug.cgi?id=28480 but with
Bruno's help we realised it's actually a libstdc++ printer bug.

The problem is that since std::tuple started using [[no_unique_address]] the
tuple> object has two _M_head_impl subobjects, in
different base classes. That means this printer code is ambiguous:

tuple_head_type = tuple_impl_type.fields()[1].type   # _Head_base
head_field = tuple_head_type.fields()[0]
if head_field.name == '_M_head_impl':
self.pointer = tuple_member['_M_head_impl']

In older versions of GDB it happened to work by chance, because GDB returned
the last _M_head_impl member and std::tuple's base classes are stored in
reverse order, so the last one was the T* element of the tuple. Since GDB 11 it
returns the first _M_head_impl, which is probably more sensible, but now the
printer gets the default_delete element.

The fix is for the printer to stop using an ambiguous field name and cast the
tuple to the right base class before accessing the _M_head_impl member:

--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -258,7 +258,7 @@ class UniquePointerPrinter:
 tuple_head_type = tuple_impl_type.fields()[1].type   # _Head_base
 head_field = tuple_head_type.fields()[0]
 if head_field.name == '_M_head_impl':
-self.pointer = tuple_member['_M_head_impl']
+self.pointer = tuple_member.cast(tuple_head_type)['_M_head_impl']
 elif head_field.is_base_class:
 self.pointer = tuple_member.cast(head_field.type)
 else:

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #12 from Andrew Macleod  ---
fixed

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:004afb984beb6efbe25f44a5857b1c27ebc2ec82

commit r12-4921-g004afb984beb6efbe25f44a5857b1c27ebc2ec82
Author: Andrew MacLeod 
Date:   Thu Nov 4 11:07:28 2021 -0400

Treat undefined operands as varying in GORI.

If the LHS is UNDEFINED simply stop calculating.  Treat op1 and op2
as VARYING if they are UNDEFINED.

PR tree-optimization/103079
gcc/
* gimple-range-gori.cc (gimple_range_calc_op1): Treat undefined as
varying.
(gimple_range_calc_op2): Ditto.

gcc/testsuite/
* gcc.dg/pr103079.c: New.

[Bug target/103085] New: [12 Regression] -fPIC and -fstack-protector-strong broken AArch64

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

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

Bug ID: 103085
   Summary: [12 Regression] -fPIC and -fstack-protector-strong
broken AArch64
   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: tnfchris at gcc dot gnu.org
CC: wilco at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*

-fPIC and -fstack-protector-strong are broken since
g:a195c7270e4705a06a9aaade0d721d5f52ca2275

The following testcase

---

struct A {
  int operator*();
  void operator++();
  friend bool operator!=(A, A);
};
class B {
public:
  A begin();
  A end();
};
class C {
  void emitMaps();
  B Events;
};
void C::emitMaps() {
  for (auto a : Events)
;
}



ICEs with gcc -O2 -g -fstack-protector-strong -fPIC -c -std=c++11

foo.cpp: In member function 'void C::emitMaps()':
foo.cpp:18:1: error: unrecognizable insn:
   18 | }
  | ^
(insn 4 3 5 2 (set (reg:DI 96)
(const:DI (unspec:DI [
(symbol_ref:DI ("__stack_chk_guard") [flags 0xc0] )
(const_int 0 [0])
] UNSPEC_SALT_ADDR))) "foo.cpp":15:20 -1
 (nil))
during RTL pass: vregs
foo.cpp:18:1: internal compiler error: in extract_insn, at recog.c:2769
0x750627 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-fsf/gcc/rtl-error.c:108
0x750653 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-fsf/gcc/rtl-error.c:116
0x10e332b extract_insn(rtx_insn*)
../../gcc-fsf/gcc/recog.c:2769
0xdf6477 instantiate_virtual_regs_in_insn
../../gcc-fsf/gcc/function.c:1611
0xdf6477 instantiate_virtual_regs
../../gcc-fsf/gcc/function.c:1985
0xdf6477 execute
../../gcc-fsf/gcc/function.c:2034

because the salt address is no longer folded away.

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-11-04
 Status|UNCONFIRMED |NEW
   Keywords||accepts-invalid
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug ipa/93385] [10/11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

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

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

--- Comment #48 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r12-4920-g1ece90ffa9ce63b416296bd662b8117d9b538913
Author: Martin Jambor 
Date:   Thu Nov 4 18:01:20 2021 +0100

ipa-sra: Improve debug info for removed parameters (PR 93385)

In spring I added code eliminating any statements using parameters
removed by IPA passes (to fix PR 93385).  That patch fixed issues such
as divisions by zero that such code could perform but it only reset
all affected debug bind statements, this one updates them with
expressions which can allow the debugger to print the removed value -
see the added test-case for an example.

Even though I originally did not want to create DEBUG_EXPR_DECLs for
intermediate values, I ended up doing so, because otherwise the code
started creating statements like

   # DEBUG __aD.198693 => [(const struct _Alloc_nodeD.171110
*)D#195]._M_tD.184726->_M_implD.171154

which not only is a bit scary but also gimple-fold ICEs on
it. Therefore I decided they are probably quite necessary.

The patch simply notes each removed SSA name present in a debug
statement and then works from it backwards, looking if it can
reconstruct the expression it represents (which can fail if a
non-degenerate PHI node is in the way).  If it can, it populates two
hash maps with those expressions so that 1) removed assignments are
replaced with a debug bind defining a new intermediate debug_decl_expr
and 2) existing debug binds that refer to SSA names that are bing
removed now refer to corresponding debug_decl_exprs.

If a removed parameter is passed to another function, the debugging
information still cannot describe its value there - see the xfailed
test in the testcase.  I sort of know what needs to be done but that
needs a little bit more of IPA infrastructure on top of this patch and
so I would like to get this patch reviewed first.

Bootstrapped and tested on x86_64-linux, i686-linux and (long time
ago) on aarch64-linux.  Also LTO-bootstrapped and on x86_64-linux.

Perhaps it is good to go to trunk?

Thanks,

Martin

gcc/ChangeLog:

2021-03-29  Martin Jambor  

PR ipa/93385
* ipa-param-manipulation.h (class ipa_param_body_adjustments): New
members remap_with_debug_expressions, m_dead_ssa_debug_equiv,
m_dead_stmt_debug_equiv and prepare_debug_expressions.  Added
parameter to mark_dead_statements.
* ipa-param-manipulation.c: Include tree-phinodes.h and
cfgexpand.h.
(ipa_param_body_adjustments::mark_dead_statements): New parameter
debugstack, push into it all SSA names used in debug statements,
produce m_dead_ssa_debug_equiv mapping for the removed param.
(replace_with_mapped_expr): New function.
(ipa_param_body_adjustments::remap_with_debug_expressions):
Likewise.
(ipa_param_body_adjustments::prepare_debug_expressions): Likewise.
(ipa_param_body_adjustments::common_initialization): Gather and
procecc SSA which will be removed but are in debug statements.
Simplify.
(ipa_param_body_adjustments::ipa_param_body_adjustments):
Initialize
new members.
* tree-inline.c (remap_gimple_stmt): Create a debug bind when
possible
when avoiding a copy of an unnecessary statement.  Remap removed
SSA
names in existing debug statements.
(tree_function_versioning): Do not create DEBUG_EXPR_DECL for
removed
parameters if we have already done so.

gcc/testsuite/ChangeLog:

2021-03-29  Martin Jambor  

PR ipa/93385
* gcc.dg/guality/ipa-sra-1.c: New test.

[Bug c++/103084] New: Accepts invalid using enum declaration with an invalid elaborated-type-specifier

[aaron at aaronballman dot com via Gcc-bugs]

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

Bug ID: 103084
   Summary: Accepts invalid using enum declaration with an invalid
elaborated-type-specifier
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron at aaronballman dot com
  Target Milestone: ---

GCC (and MSVC) currently accepts the following snippet while Clang and ICC
reject:
```
enum class Pig { Oink };
using Hog = Pig;
using enum Hog; // Clang & ICC rejects, GCC & MSVC accepts
```
I think Clang and ICC are correct to reject this code.
http://eel.is/c++draft/enum.udecl says that the production needs to parse an
elaborated-enum-specifier. One of the requirements for a valid
elaborated-enum-specifier is that the elaboration has to agree in kind with the
given declaration (https://eel.is/c++draft/dcl.type.elab#6). In this case, the
given declaration is not an enum, it's a type alias.

Note that all compilers reject the following slightly different example due to
the elaborated type specifier being invalid:
```
enum class Pig { Oink };
using Hog = Pig;
enum Hog H; // Everyone rejects
```

[Bug ipa/103073] [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578 since r12-4401-gfecd145359fc981b

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

--- Comment #4 from Vsevolod Livinskiy  ---
(In reply to Martin Liška from comment #2)
> Started with r12-4401-gfecd145359fc981b.
> 
> @Vsevolod: Is it a yarpgen test-case?

Yes. I've added stencil support recently, but it was a surprise to trigger a
bug in IPA.

BTW, should I add new bugs to the meta-bug before or after they were confirmed?

[Bug fortran/103058] [12 Regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r

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

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

Jan Hubicka  changed:

   What|Removed |Added

  Component|ipa |fortran

--- Comment #6 from Jan Hubicka  ---
Looking at the particular ICE, this looks like a fortran frond-end issue - this
is during compilation and not during link and I do not see why Fortran should
produce nested function with external linkage.
I comitted a patch that silences the ICE, but it would be nice to make the
function static for Fortran.

Changing component to fortran.

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #19 from hubicka at kam dot mff.cuni.cz ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
> 
> Aldy Hernandez  changed:
> 
>What|Removed |Added
> 
>  Depends on||103058
> 
> --- Comment #18 from Aldy Hernandez  ---
> 251.wrf_r is no longer building.  Seems to be the same issue in PR103058.
> 
> during GIMPLE pass: alias
> module_fr_fire_phys.fppized.f90: In function 'init_fuel_cats':
> module_fr_fire_phys.fppized.f90:136:25: internal compiler error: in
> gimple_call_static_chain_flags, at gimple.c:1669
>   136 | subroutine init_fuel_cats
>   | ^
> 0x6957b5 gimple_call_static_chain_flags(gcall const*)
> /home/aldyh/src/clean/gcc/gimple.c:1669

I have commited workaround for this.
However here it looks like a frontend issue - I do not think Fortran
should produce nested functions with external linkage. At least there
seems to be no good reason for doing so since they can not be called
cross-module.

Honza

Re: [Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

[Jan Hubicka via Gcc-bugs]

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
> 
> Aldy Hernandez  changed:
> 
>What|Removed |Added
> 
>  Depends on||103058
> 
> --- Comment #18 from Aldy Hernandez  ---
> 251.wrf_r is no longer building.  Seems to be the same issue in PR103058.
> 
> during GIMPLE pass: alias
> module_fr_fire_phys.fppized.f90: In function 'init_fuel_cats':
> module_fr_fire_phys.fppized.f90:136:25: internal compiler error: in
> gimple_call_static_chain_flags, at gimple.c:1669
>   136 | subroutine init_fuel_cats
>   | ^
> 0x6957b5 gimple_call_static_chain_flags(gcall const*)
> /home/aldyh/src/clean/gcc/gimple.c:1669

I have commited workaround for this.
However here it looks like a frontend issue - I do not think Fortran
should produce nested functions with external linkage. At least there
seems to be no good reason for doing so since they can not be called
cross-module.

Honza

[Bug ipa/103082] [12 Regression] gcc/poly-int.h:1162:5: runtime error: left shift of negative value -40

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-11-04
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #1 from Jan Hubicka  ---
The compuation is supposed to be working for negative values. Later we add the
bitoffset which can make it positive again and range check will match. 

The computation is correct on any complement of two host and we do not really
support others I believe, but I guess changing it to *HOST_BITS_PER_UNIT is
easiest way to get ubsan quiet?

[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression

[schwab--- via Gcc-bugs]

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

--- Comment #6 from Andreas Schwab  ---
&*E is allowed for E == NULL, but I don't think this can be generalized to
>m.

[Bug target/102961] Build fails for AIX 6.1

[John.Parke at alebra dot com via Gcc-bugs]

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

--- Comment #3 from John Parke  ---
I think the problem is caused by: 

>> 0711-738 ERROR: Input file /usr/gcc-11.2.0-build/./gcc/ppc64/crtcxa_s.o:

See below:
XCOFF32 object files are not allowed in 64-bit mode.
# @multilib_flags@ is still needed because this may use
# /usr/gcc-11.2.0-build/./gcc/xgcc -B/usr/gcc-11.2.0-build/./gcc/
-B/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/bin/
-B/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/lib/ -isystem
/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/include -isystem
/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/sys-include   -fno-checking and
-O2  -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include 
-mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector 
directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh ../../../../gcc-11.2.0/libgcc/../mkinstalldirs ppc64
mkdir -p -- ppc64
if test svr4 != aix ; then /usr/gcc-11.2.0-build/./gcc/xgcc
-B/usr/gcc-11.2.0-build/./gcc/
-B/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/bin/
-B/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/lib/ -isystem
/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/include -isystem
/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/sys-include   -fno-checking -O2
 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include 
-mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector 
-shared -Wl,-bnortl -nodefaultlibs -Wl,-bE:libgcc.map -o shr.o -g -O2 -maix64
-B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o
_ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o
_absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o
_mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o
_clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o
_mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o
_fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o
_floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o
_fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o _fixunssfti_s.o
_fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o _floattidf_s.o
_floattixf_s.o _floattitf_s.o _floatuntisf_s.o _floatuntidf_s.o
_floatuntixf_s.o _floatuntitf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o
_udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o _pack_sf_s.o
_unpack_sf_s.o _addsub_sf_s.o _mul_sf_s.o _div_sf_s.o _fpcmp_parts_sf_s.o
_compare_sf_s.o _eq_sf_s.o _ne_sf_s.o _gt_sf_s.o _ge_sf_s.o _lt_sf_s.o
_le_sf_s.o _unord_sf_s.o _si_to_sf_s.o _sf_to_si_s.o _negate_sf_s.o
_make_sf_s.o _sf_to_df_s.o _thenan_sf_s.o _sf_to_usi_s.o _usi_to_sf_s.o
_pack_df_s.o _unpack_df_s.o _addsub_df_s.o _mul_df_s.o _div_df_s.o
_fpcmp_parts_df_s.o _compare_df_s.o _eq_df_s.o _ne_df_s.o _gt_df_s.o _ge_df_s.o
_lt_df_s.o _le_df_s.o _unord_df_s.o _si_to_df_s.o _df_to_si_s.o _negate_df_s.o
_make_df_s.o _df_to_sf_s.o _thenan_df_s.o _df_to_usi_s.o _usi_to_df_s.o
ibm-ldouble_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde_s.o
unwind-sjlj_s.o unwind-c_s.o cxa_atexit_s.o cxa_finalize_s.o atexit_s.o
on_exit_s.o emutls_s.o libgcc.a -lc `case ppc64 in *pthread*) echo
-L/usr/lib/threads -lpthreads -lc_r /usr/lib/libc.a ;; *) echo -lc ;; esac` ;
rm -f tmp-libgcc_s.a ; ar -X32_64 -X32_64 rc tmp-libgcc_s.a shr.o ; mv
tmp-libgcc_s.a libgcc_s.a ; rm -f shr.o ; fi ; if test aix != aix ; then case
ppc64 in *64*) shr='shr_64' ;; *) shr='shr' ;; esac ;
/usr/gcc-11.2.0-build/./gcc/xgcc -B/usr/gcc-11.2.0-build/./gcc/
-B/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/bin/
-B/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/lib/ -isystem
/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/include -isystem
/opt/freeware/gcc-11.2.0/powerpc-ibm-aix6.1.9.0/sys-include   -fno-checking -O2
 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include 
-mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector 
-shared -Wl,-G -nodefaultlibs -Wl,-bE:libgcc.map -o $shr.o -g -O2 -maix64 -B./
_muldi3_s.o _negdi2_s.o _lshrdi3_s.o 

[Bug ipa/103058] [12 Regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r12-4914-gd3f7a2fa64f8777cb7eae1b99ff80fbe717095ac
Author: Jan Hubicka 
Date:   Thu Nov 4 17:07:44 2021 +0100

Workaround ICE in gimple_call_static_chain_flags

gcc/ChangeLog:

2021-11-04  Jan Hubicka  

PR ipa/103058
* gimple.c (gimple_call_static_chain_flags): Handle case when
nested function does not bind locally.

[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression

[jbeulich at suse dot com via Gcc-bugs]

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

--- Comment #5 from jbeulich at suse dot com ---
(In reply to Martin Sebor from comment #4)
> The expression pa->c is only valid if pa points to a valid object.

Well, yes, you may not deref pa if it's NULL, i.e. I agree for pa->c. But is
>c actually a deref?

[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression

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

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

--- Comment #4 from Martin Sebor  ---
The expression pa->c is only valid if pa points to a valid object.

[Bug ipa/103058] [12 Regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #4 from hubicka at kam dot mff.cuni.cz ---
Hi,
I am testing the following to unbreak fortran.
However the real bug is that binds_to_current_def should work on whole
WPA and be independent of partitioning.  I remember I had patch fixing
that. Will look it up.

Honza

diff --git a/gcc/gimple.c b/gcc/gimple.c
index 76768c19c8e..7a578f5113e 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -1666,7 +1666,18 @@ gimple_call_static_chain_flags (const gcall *stmt)
  int modref_flags = summary->static_chain_flags;

  /* We have possibly optimized out load.  Be conservative here.  */
- gcc_checking_assert (node->binds_to_current_def_p ());
+ if (!node->binds_to_current_def_p ())
+   {
+ if ((modref_flags & EAF_UNUSED) && !(flags & EAF_UNUSED))
+   {
+ modref_flags &= ~EAF_UNUSED;
+ modref_flags |= EAF_NOESCAPE;
+   }
+ if ((modref_flags & EAF_NOREAD) && !(flags & EAF_NOREAD))
+   modref_flags &= ~EAF_NOREAD;
+ if ((modref_flags & EAF_DIRECT) && !(flags & EAF_DIRECT))
+   modref_flags &= ~EAF_DIRECT;
+   }
  if (dbg_cnt (ipa_mod_ref_pta))
flags |= modref_flags;
}

[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's value range propagation since r10-5538-gc7ac9a0c7e3916f1

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
Mine.

[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's value range propagation since r10-5538-gc7ac9a0c7e3916f1

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Wrong code due to ipa-cp's  |[10/11/12 Regression] Wrong
   |value range propagation |code due to ipa-cp's value
   ||range propagation since
   ||r10-5538-gc7ac9a0c7e3916f1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-04

--- Comment #1 from Martin Liška  ---
If I see correctly, started with r10-5538-gc7ac9a0c7e3916f1.

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Depends on||103058

--- Comment #18 from Aldy Hernandez  ---
251.wrf_r is no longer building.  Seems to be the same issue in PR103058.

during GIMPLE pass: alias
module_fr_fire_phys.fppized.f90: In function 'init_fuel_cats':
module_fr_fire_phys.fppized.f90:136:25: internal compiler error: in
gimple_call_static_chain_flags, at gimple.c:1669
  136 | subroutine init_fuel_cats
  | ^
0x6957b5 gimple_call_static_chain_flags(gcall const*)
/home/aldyh/src/clean/gcc/gimple.c:1669
0xf72359 handle_rhs_call
/home/aldyh/src/clean/gcc/tree-ssa-structalias.c:4258
0xf75014 find_func_aliases_for_call
/home/aldyh/src/clean/gcc/tree-ssa-structalias.c:4921
0xf75014 find_func_aliases
/home/aldyh/src/clean/gcc/tree-ssa-structalias.c:5024
0xf76906 compute_points_to_sets
/home/aldyh/src/clean/gcc/tree-ssa-structalias.c:7440
0xf76906 compute_may_aliases()
/home/aldyh/src/clean/gcc/tree-ssa-structalias.c:7948
0xc84884 execute_function_todo
/home/aldyh/src/clean/gcc/passes.c:2014
0xc851fe execute_todo
/home/aldyh/src/clean/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [/tmp/cc3vtkEO.mk:116: /tmp/ccUtPK6E.ltrans38.ltrans.o] Error 1
make[1]: *** Waiting for unfinished jobs


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
[Bug 103058] [12 Regression] ICE in gimple_call_static_chain_flags, at
gimple.c:1669 when building 527.cam4_r

[Bug ipa/103083] New: Wrong code due to ipa-cp's value range propagation

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

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

Bug ID: 103083
   Summary: Wrong code due to ipa-cp's value range propagation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

struct b {int b;};
struct a {int a; struct b b;};

long i;

__attribute__ ((noinline))
static void test2 (struct b *b)
{
if (((int)b)&4)
__builtin_abort ();
}

__attribute__ ((noinline))
static void
test (struct a *a)
{
 test2(a? >b : 0);
}
void
main()
{
test(0);
}

aborts when built with -O2.

[Bug c++/103081] [ICE] with "using enum"

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #4 from M Welinder  ---
That version of clang does not do "using enum" at all.  clang 13 accepts this
code, but it has other issues with "using enum".

[Bug ipa/103080] LTO alters the ordering of static constructors/destructors in pass_ipa_cdtor_merge.

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

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

--- Comment #3 from Iain Sandoe  ---
(In reply to hubicka from comment #1)
> The cdtor merging code is predating LTO - it is also used for collect2
> path on targets w/o cdtor sections.

Even so, I do not see how it can work there either*** - within a single built
__GLOBAL_I_xx we would have the CTOR order reversed from the source.  There
is nothing collect2 can do to fix that ;)

> I guess the DECL_UID compare is not very safe things to do since it
> depends on the tree merging decisions.

I agree it looks very fragile to depend on DECL_UID ordering (unless there is a
strong guarantee that the UID value indicates definition order (what about
declarations that become definitions later in the TU - but with different
ordering?).

>  We do not record declaration
> order to LTO time, however we have order of definitions which would be
> cgraph_node::get (f1)->order

Presumably, something new would need to be streamed - or would the relative
ordering of the functions be preserved ?

===

*** I was also looking a while ago at making collect2 do init_prio on Darwin -
but making it work with LTO seems quite a bit of lifting still to do

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

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

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

--- Comment #12 from Marek Polacek  ---
OK, I'd totally forgotten about this PR.

[Bug ipa/103082] [12 Regression] gcc/poly-int.h:1162:5: runtime error: left shift of negative value -40

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||12.0
   Target Milestone|--- |12.0

[Bug ipa/103082] New: [12 Regression] gcc/poly-int.h:1162:5: runtime error: left shift of negative value -40

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

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

Bug ID: 103082
   Summary: [12 Regression] gcc/poly-int.h:1162:5: runtime error:
left shift of negative value -40
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

I see the following UBSAN error:

../../gcc/poly-int.h:1162:5: runtime error: left shift of negative value -40
#0 0x2d20c79 in poly_int<1u, poly_result::result_kind>::type> operator<< <1u, long,
int>(poly_int_pod<1u, long> const&, int const&) ../../gcc/poly-int.h:1162
#1 0x2d20c79 in modref_access_node::contains(modref_access_node const&)
const ../../gcc/ipa-modref-tree.h:120
#2 0x2d40293 in modref_ref_node::insert_access(modref_access_node,
unsigned long, bool) ../../gcc/ipa-modref-tree.h:521
#3 0x2d45fdd in modref_tree::insert(int, int, modref_access_node,
bool) ../../gcc/ipa-modref-tree.h:848
#4 0x2cf0b88 in record_access ../../gcc/ipa-modref.c:758
#5 0x2d16ac1 in analyze_store ../../gcc/ipa-modref.c:1290
#6 0x2932310 in walk_stmt_load_store_addr_ops(gimple*, void*, bool
(*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*,
tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
../../gcc/gimple-walk.c:767
#7 0x2cf4561 in analyze_stmt ../../gcc/ipa-modref.c:1313
#8 0x2cf4561 in analyze_function ../../gcc/ipa-modref.c:2366
#9 0x2cfe26d in execute ../../gcc/ipa-modref.c:3213
#10 0x348e890 in execute_one_pass(opt_pass*) ../../gcc/passes.c:2567
#11 0x3491f51 in execute_pass_list_1 ../../gcc/passes.c:2656

one can see it easily with:

diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h
index 9976e489697..65875d9539f 100644
--- a/gcc/ipa-modref-tree.h
+++ b/gcc/ipa-modref-tree.h
@@ -116,6 +116,7 @@ struct GTY(()) modref_access_node
   if (!known_le (parm_offset, a.parm_offset)
   && !range_info_useful_p ())
 return false;
+  gcc_checking_assert ((a.parm_offset - parm_offset).to_constant
() >= 0);
   aoffset_adj = (a.parm_offset - parm_offset)
 << LOG2_BITS_PER_UNIT;
}

$ cat d2s.i
long mulShift(long *mul) { return mul[0] + mul[1]; }

$ gcc d2s.i -c -O2
during GIMPLE pass: modref
d2s.i: In function ‘mulShift’:
d2s.i:1:1: internal compiler error: in contains, at ipa-modref-tree.h:119
1 | long mulShift(long *mul) { return mul[0] + mul[1]; }
  | ^~~~
0xcce4a9 modref_access_node::contains(modref_access_node const&) const
/home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:119
0xcce4a9 modref_access_node::contains(modref_access_node const&) const
/home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:101
0xcd1912 modref_ref_node::insert_access(modref_access_node, unsigned long,
bool)
/home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:523
0xcd25ce modref_tree::insert(int, int, modref_access_node, bool)
/home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:850
0xcc5d62 record_access
/home/marxin/Programming/gcc/gcc/ipa-modref.c:758
0xcccb73 analyze_load
/home/marxin/Programming/gcc/gcc/ipa-modref.c:1262
0xc1df93 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
/home/marxin/Programming/gcc/gcc/gimple-walk.c:800
0xcc6b9c analyze_stmt
/home/marxin/Programming/gcc/gcc/ipa-modref.c:1313
0xcc6b9c analyze_function
/home/marxin/Programming/gcc/gcc/ipa-modref.c:2366
0xcc8991 execute
/home/marxin/Programming/gcc/gcc/ipa-modref.c:3213
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug c++/103081] [ICE] with "using enum"

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

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

--- Comment #3 from Richard Biener  ---
Confirmed on the GCC 11 branch head and trunk.  clang complains:

> clang++-11 -S t.C -std=c++20
t.C:4:9: error: expected unqualified-id
  using enum Pig;
^
t.C:10:18: error: no member named 'OINK' in 'Hog'
  (void)Hog(Hog::OINK);
~^
2 errors generated.

[Bug c++/103081] [ICE] with "using enum"

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

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

--- Comment #2 from Marek Polacek  ---
Started with r11-5003.

[Bug ipa/103080] LTO alters the ordering of static constructors/destructors in pass_ipa_cdtor_merge.

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

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

--- Comment #2 from Richard Biener  ---
IIRC there is also an older bug about CTOR/DTOR order across multiple TUs where
with -flto be behave differently than without where I said it might be nice to
preserve linker command line order (we have that order available somewhere at
WPA time as well).

OTOH, it might be nice to diagnose CTOR/DTOR dependences between TUs as
that is really UB and at WPA time we should have IPA REFs providing such
dependences.

[Bug c++/103081] [ICE] with "using enum"

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-11-04
   Keywords||ice-on-valid-code
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/103072] Folding common switch code

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #3 from Jeremy R.  ---
(In reply to Jakub Jelinek from comment #1)
> So maybe the switchconv pass could be
> improved not to do just the linear etc. expression handling, but also
> consider code sequences that are the same except for the linear expression
> somewhere in it and turn it back into use of a temporary.

I think this is how LLVM approaches it. It might be nice to be able to fold
switches where it's not a linear sequence too, such as:

void bar(int x) {
switch(x) {
case 1: func(x); break;
case 4: func(x); break;
case 7: func(x); break;
case 3: func(x); break;
case 9: func(x); break;
default: __builtin_unreachable();
}
}

LLVM is able to fold this out of a switch though it also struggles due to the
early constant propagation and doesn't fold this perfectly.

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

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

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:6a9678f0b30d36ae13259ad635e175a1e24917a1

commit r12-4905-g6a9678f0b30d36ae13259ad635e175a1e24917a1
Author: Aldy Hernandez 
Date:   Thu Nov 4 12:37:16 2021 +0100

path solver: Prefer range_of_expr instead of range_on_edge.

The range_of_expr method provides better caching than range_on_edge.
If we have a statement, we can just it and avoid the range_on_edge
dance.  Plus we can use all the range_of_expr fanciness.

Tested on x86-64 and ppc64le Linux with the usual regstrap.  I also
verified that the before and after number of threads was the same or
greater in a suite of .ii files from a bootstrap.

gcc/ChangeLog:

PR tree-optimization/102943
* gimple-range-path.cc (path_range_query::range_on_path_entry):
Prefer range_of_expr unless there are no statements in the BB.

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r12-4904-ge4411622690654cdc530c6262c7115a9e15dc359
Author: Aldy Hernandez 
Date:   Thu Nov 4 11:34:55 2021 +0100

Avoid repeating calculations in threader.

We already attempt to resolve the current path on entry to
find_paths_to_name(), so there's no need to do so again for each
exported range since nothing has changed.

Removing this redundant calculation avoids 22% of calls into the path
solver.

Tested on x86-64 and ppc64le Linux with the usual regstrap.  I also
verified that the before and after number of threads was the same
in a suite of .ii files from a bootstrap.

gcc/ChangeLog:

PR tree-optimization/102943
* tree-ssa-threadbackward.c (back_threader::find_paths_to_names):
Avoid duplicate calculation of paths.

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r12-4903-g5ea1ce43b6070aaa94882e8b15f3340344aaa6b2
Author: Aldy Hernandez 
Date:   Wed Nov 3 08:23:25 2021 +0100

path solver: Only compute relations for imports.

We are currently calculating implicit PHI relations for all PHI
arguments.  This creates unecessary work, as we only care about SSA
names in the import bitmap.  Similarly for inter-path relationals.  We
can avoid things not in the bitmap.

Tested on x86-64 and ppc64le Linux with the usual regstrap.  I also
verified that the before and after number of threads was the same
in a suite of .ii files from a bootstrap.

gcc/ChangeLog:

PR tree-optimization/102943
* gimple-range-path.cc (path_range_query::compute_phi_relations):
Only compute relations for SSA names in the import list.
(path_range_query::compute_outgoing_relations): Same.
* gimple-range-path.h (path_range_query::import_p): New.

[Bug c++/103081] New: [ICE] with "using enum"

[terra at gnome dot org via Gcc-bugs]

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

Bug ID: 103081
   Summary: [ICE] with "using enum"
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

This code triggers an internal compiler error.


enum class Pig { OINK };

struct Hog {
  using enum Pig;
  Hog(Pig) { }
};

template 
void pen() {
  (void)Hog(Hog::OINK);
}

void pen() {
  pen<0>();
}



.../gcc/11.1.0/bin/g++  -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
-pedantic-errors -Wall -Wno-unknown-pragmas -W -fsigned-char -malign-data=abi
-fno-semantic-interposition -gz=zlib-gnu -c -march=westmere -mmmx -mno-3dnow
-msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes
-mno-sha -mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop
-mno-bmi -mno-sgx -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1
-mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed
-mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma
-mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx
-mno-clzero -mno-pku -mno-rdpid --param "l1-cache-size=32" --param
"l1-cache-line-size=64" --param "l2-cache-size=12288" -mtune=westmere
-std=gnu++20 -Wrestrict -Wdangling-else -Wno-placement-new
-Wno-deprecated-declarations -fno-strict-overflow
-Wzero-as-null-pointer-constant -Wwrite-strings -Wno-ignored-qualifiers
-Wno-array-bounds -Wno-mismatched-new-delete -Wdeprecated-copy
-Wdeprecated-copy-dtor -Wredundant-move -m32 -mfpmath=sse -Woverloaded-virtual
-fPIC -g -o /home/welinder/using-enum_L111a3.o /home/welinder/using-enum.C
/home/welinder/using-enum.C: In instantiation of ‘void pen() [with unsigned int
 = 0]’:
/home/welinder/using-enum.C:14:9:   required from here
/home/welinder/using-enum.C:10:18: internal compiler error: in tsubst_copy, at
cp/pt.c:16715
   10 |   (void)Hog(Hog::OINK);
  | ~^~~~
0x669a60 tsubst_copy
../../../gcc-11.1.0/gcc/cp/pt.c:16715
0x802d0c tsubst_qualified_id
../../../gcc-11.1.0/gcc/cp/pt.c:16449
0x8041b6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:19948
0x814e01 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:19587
0x814e01 tsubst_tree_list(tree_node*, tree_node*, int, tree_node*)
../../../gcc-11.1.0/gcc/cp/pt.c:15417
0x8037fa tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:20586
0x804f67 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:19587
0x804f67 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:19797
0x814e01 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:19587
0x814e01 tsubst_tree_list(tree_node*, tree_node*, int, tree_node*)
../../../gcc-11.1.0/gcc/cp/pt.c:15417
0x8037fa tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:20586
0x804f67 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:19587
0x804f67 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:19797
0x815114 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../gcc-11.1.0/gcc/cp/pt.c:19587
0x815114 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../../gcc-11.1.0/gcc/cp/pt.c:19198
0x816181 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../../gcc-11.1.0/gcc/cp/pt.c:18223
0x816181 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../../gcc-11.1.0/gcc/cp/pt.c:18268
0x815c4f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../../gcc-11.1.0/gcc/cp/pt.c:18223
0x815c4f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../../gcc-11.1.0/gcc/cp/pt.c:18589
0x809719 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../../gcc-11.1.0/gcc/cp/pt.c:25909
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Return code for compiling using-enum.C: 1


This is an x86_64 system running OpenSuSE 15.2.

[Bug ipa/103080] LTO alters the ordering of static constructors/destructors in pass_ipa_cdtor_merge.

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #1 from hubicka at kam dot mff.cuni.cz ---
The cdtor merging code is predating LTO - it is also used for collect2
path on targets w/o cdtor sections.

I guess the DECL_UID compare is not very safe things to do since it
depends on the tree merging decisions.  We do not record declaration
order to LTO time, however we have order of definitions which would be
cgraph_node::get (f1)->order

Honza

[Bug testsuite/103042] gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c etc. FAIL

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #4 from Tamar Christina  ---
This should be fixed.

[Bug ipa/103080] New: LTO alters the ordering of static constructors/destructors in pass_ipa_cdtor_merge.

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

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

Bug ID: 103080
   Summary: LTO alters the ordering of static
constructors/destructors in pass_ipa_cdtor_merge.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

consider the following :

#include 

/* Define USE_PRIO to to test that.*/

#ifdef USE_PRIO
#define PRIO_CTOR constructor(12345)
#define PRIO_DTOR destructor(12345)
#else
#define PRIO_CTOR constructor
#define PRIO_DTOR destructor
#endif

__attribute__((constructor))
static void
startup ()
{
  fprintf(stderr, "startup\n");
}

__attribute__((destructor))
static void
shutdown ()
{
  fprintf(stderr, "shutdown\n");
}

__attribute__((PRIO_CTOR))
static void
startup1 ()
{
  fprintf(stderr, "startup1\n");
}

__attribute__((PRIO_CTOR))
static void
startup2 ()
{
  fprintf(stderr, "startup2\n");
}

__attribute__((PRIO_DTOR))
static void
shutdown1 ()
{
  fprintf(stderr, "shutdown1\n");
}

__attribute__((destructor))
static void
shutdown2 ()
{
  fprintf(stderr, "shutdown2\n");
}

int main ()
{
  printf ("42\n");
  return 0;
}



This initial output is (to the best of my knowledge, although we do not
document it well enough) the correct behaviour.  Essentially, we execute the
static constructors in order of declaration and the destructors in the reverse
order.  This is the most reasonable ordering from the user's perspective and
more-or-less follows what C++ does (although the static DTORs are not tied to
their CTORs - they *can* be placed together in the source to make it readable).

$ ./gcc/xgcc -Bgcc ~/ctor-dtor.c -o ct 
$ ./ct
startup
startup1
startup2
42
shutdown2
shutdown1
shutdown

-

$ ./gcc/xgcc -Bgcc ~/ctor-dtor.c -o ct -flto
$ ./ct
startup2
startup1
startup
42
shutdown
shutdown1
shutdown2

This is not (IMO at least) correct - at the very least the program behaviour
will be different with/without LTO.

I suspect that the logic is inverted in ipa.c:compare_ctor / compare_dtor. 
There is a comment that this is intended to make it more likely that library
CTORs will run early - but ISTM that if that is needed then an alternate
mechanism must be used.

===
similar issues when priority is in use
NOTE that the different DTOR ordering *is* intentional as can be seen from the
source above.

$ ./gcc/xgcc -Bgcc ~/ctor-dtor.c -o ct -DUSE_PRIO
$ ./ct
startup1
startup2
startup
42
shutdown2
shutdown
shutdown1
---
$ ./gcc/xgcc -Bgcc ~/ctor-dtor.c -o ct -DUSE_PRIO -flto
$ ./ct
startup2
startup1
startup
42
shutdown
shutdown2
shutdown1
==

[Bug testsuite/103042] gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c etc. FAIL

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:5914a7b5c637c9007283226f200dcab8b745abc8

commit r12-4900-g5914a7b5c637c9007283226f200dcab8b745abc8
Author: Tamar Christina 
Date:   Thu Nov 4 13:43:36 2021 +

testsuite: Add more guards to complex tests

This test hopefully fixes all the remaining target specific test issues by

1: Unrolling all add testcases by 16 using pragma GCC unroll
2. On armhf use Adv.SIMD instead of MVE to test. MVE's autovec is too
incomplete
   to be a general test target.
3. Add appropriate vect_ and float guards on testcases.

gcc/testsuite/ChangeLog:

PR testsuite/103042
* gcc.dg/vect/complex/bb-slp-complex-add-pattern-int.c: Update
guards.
* gcc.dg/vect/complex/bb-slp-complex-add-pattern-long.c: Likewise.
* gcc.dg/vect/complex/bb-slp-complex-add-pattern-short.c: Likewise.
* gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-int.c:
Likewise.
* gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c:
Likewise.
* gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-short.c:
Likewise.
* gcc.dg/vect/complex/complex-add-pattern-template.c: Likewise.
* gcc.dg/vect/complex/complex-add-template.c: Likewise.
* gcc.dg/vect/complex/complex-operations-run.c: Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-add-double.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-add-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-add-half-float.c:
Likewise.
*
gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-double.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-float.c:
Likewise.
*
gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-half-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-double.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-half-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-double.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-half-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-double.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-half-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-double.c:
Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-half-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-complex-mla-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mla-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mla-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-half-float.c: Likewise.
* gcc.dg/vect/complex/vect-complex-add-pattern-byte.c: Likewise.
* gcc.dg/vect/complex/vect-complex-add-pattern-int.c: Likewise.
* gcc.dg/vect/complex/vect-complex-add-pattern-long.c: Likewise.
* gcc.dg/vect/complex/vect-complex-add-pattern-short.c: Likewise.
* gcc.dg/vect/complex/vect-complex-add-pattern-unsigned-byte.c:
Likewise.
* gcc.dg/vect/complex/vect-complex-add-pattern-unsigned-int.c:
Likewise.
* gcc.dg/vect/complex/vect-complex-add-pattern-unsigned-long.c:
Likewise.
* gcc.dg/vect/complex/vect-complex-add-pattern-unsigned-short.c:
Likewise.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #10 from Andrew Macleod  ---
That patch wont generally work until rangeops op1_range routines are adjusted
to deal with undefined being passed in.. I think it assumes until now that its
been trimmed out.


(In reply to Richard Biener from comment #8)
> Btw, I find the vrp-details dump not really useful with all the ranger
> "debug" appearing _after_ the folding of stmts.  Can we instead have
> this somehow interleaved?

well  the block you quoted is an after-the fact dumping of everything ranger
knows after its been run.   That info is hard to interleave with the folding.  

The traces interleave with the folding messages, but I haven't gotten to the
point where I can interleave the same kind of information.. 

I'll look to improve that once things settle down a bit and see how much of
that I can integrate into the folder routines to dump it as we go.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #9 from Andrew Macleod  ---
Created attachment 51735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51735=edit
patch for the undefined bit

(In reply to Richard Biener from comment #7)
> === BB 2 
> Imports: b.0_1  t_4(D)
> Exports: b.0_1  t_4(D)  _6
>  _6 : b.0_1(I)  t_4(D)(I)
> t_4(D)  UNDEFINED
>  [local count: 176285970]:
> b.0_1 = b;
> _6 = b.0_1 | t_4(D);
> if (_6 != 0)
>   goto ; [34.00%]
> else
>   goto ; [66.00%]
> 
> 2->3  (T) b.0_1 :   UNDEFINED
> 2->3  (T) t_4(D) :  UNDEFINED
> 2->3  (T) _6 :  int [-INF, -1][1, +INF]
> 
> I think 2->3 (T) b.0_1 : UNDEFINED is wrong.  if b.0_1 is 1 then 1 | UNDEF
> is still 1 and there's nothing "undefined" in evaluating if (1 | UNDEF !+ 0).

yeah looks like gori calculations just assumes an undefined argument makes
everything undefined..  we should probably just left the op1/op2_range routines
handle it.
We can't actually know b.0_1 if the branch is taken because of the undefined,
so it'll get calculated as varying. With the untested patch, we now get

2->3  (T) t_4(D) :  UNDEFINED
2->3  (T) _6 :  int [-INF, -1][1, +INF]
2->7  (F) b.0_1 :   int [0, 0]
2->7  (F) t_4(D) :  UNDEFINED
2->7  (F) _6 :  int [0, 0] 

we do know that b.0_1 is 0 on the false side...

[Bug testsuite/103042] gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c etc. FAIL

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

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

Tamar Christina  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-11-04
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug target/101981] GCC10 produces bigger asm for simple switch than GCC7 - cortexM4 since r8-2701-g9dc3d6a96167b4c8

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #10 from Martin Liška  ---
Thus closing as work for me.

[Bug tree-optimization/103072] Folding common switch code

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

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

--- Comment #2 from Martin Liška  ---
Or we can alternatively merge all the case blocks into one..

[Bug rtl-optimization/103075] [12 Regression] ICE in exact_int_to_float_conversion_p with -O1 -frounding-math and int to float conversion with multiply

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/103075] [12 Regression] ICE in exact_int_to_float_conversion_p with -O1 -frounding-math and int to float conversion with multiply

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

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

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

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

commit r12-4898-gd13603501680fcdbb933cb086cd01fcc39be1908
Author: Richard Biener 
Date:   Thu Nov 4 09:17:18 2021 +0100

rtl-optimization/103075 - avoid ICEing on unfolded int-to-float converts

The following avoids asserting in exact_int_to_float_conversion_p that
the argument is not constant which it in fact can be with
-frounding-math and inexact int-to-float conversions.  Say so.

2021-11-04  Richard Biener  

PR rtl-optimization/103075
* simplify-rtx.c (exact_int_to_float_conversion_p): Return
false for a VOIDmode operand.

* gcc.dg/pr103075.c: New testcase.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

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

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

--- Comment #8 from Richard Biener  ---
Btw, I find the vrp-details dump not really useful with all the ranger
"debug" appearing _after_ the folding of stmts.  Can we instead have
this somehow interleaved?

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

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

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

--- Comment #7 from Richard Biener  ---
=== BB 2 
Imports: b.0_1  t_4(D)
Exports: b.0_1  t_4(D)  _6
 _6 : b.0_1(I)  t_4(D)(I)
t_4(D)  UNDEFINED
 [local count: 176285970]:
b.0_1 = b;
_6 = b.0_1 | t_4(D);
if (_6 != 0)
  goto ; [34.00%]
else
  goto ; [66.00%]

2->3  (T) b.0_1 :   UNDEFINED
2->3  (T) t_4(D) :  UNDEFINED
2->3  (T) _6 :  int [-INF, -1][1, +INF]

I think 2->3 (T) b.0_1 : UNDEFINED is wrong.  if b.0_1 is 1 then 1 | UNDEF
is still 1 and there's nothing "undefined" in evaluating if (1 | UNDEF !+ 0).

[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression

[jbeulich at suse dot com via Gcc-bugs]

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

jbeulich at suse dot com changed:

   What|Removed |Added

 CC||jbeulich at suse dot com

--- Comment #3 from jbeulich at suse dot com ---
(In reply to Martin Sebor from comment #1)
> The warning is intended: it points out that the second operand of the
> conditional expression is necessarily true:
> 
>   if ( !(pa ? >c : NULL) )
>   ^^
> 
> There's no point in testing the address of a member for equality to null
> because  the member of no object can reside at that address.

Except that if pa is NULL and c is the first member of typeof(*pa), then >c
is also NULL, isn't it?

>  The above can
> be simplified to
> 
>   if (!pa)

If there was no macro expansion involved in the former case, I'd agree with the
option of simplifying the expression. But the use of the macro expanding to
this construct may be intended, perhaps at least for the code to be
self-documenting. The macro itself, in turn, may be (and in our case is) also
used in contexts where the produced pointer actually gets used as such, not for
boolean NULL / non-NULL checks.

In any event I don't see how it matters here that, as you say, "the second
operand of the conditional expression is necessarily true". Especially
considering the macro aspect, changing to "pa ? 1 : NULL" or (to make the
construct type-correct) "pa ? 1 : 0" isn't an option, yet that's what you
appear to be suggesting (as intermediate step to arrive at simply "pa").

Imo the compiler wrongly connects the use of >c in the conditional
expression to the boolean context of the enclosing if(), even irrespective of
the use of !() around the conditional operator. IOW

if ( pa ? >c : NULL )

should also go through without any diagnostic (at least as long as the compiler
doesn't also take into account whether the expression is the result of macro
expansion). Otherwise all you do is force people to write less legible code,
e.g. the macro becoming

#define a_to_c(pa) ({ \
type_of_c *pc_ = (pa) ? &(pa)->c : NULL; \
pc_; \
})

based on Andrew's observation that breaking out the expression doesn't result
in any warning (didn't check whether that in practice extends to the case
above).

[Bug tree-optimization/103062] [12 Regression] ICE: SIGSEGV in gimple_simplify_CONVERT_EXPR with -O2 -fno-tree-forwprop since r12-4694-gcb153222404e2e14

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/103062] [12 Regression] ICE: SIGSEGV in gimple_simplify_CONVERT_EXPR with -O2 -fno-tree-forwprop since r12-4694-gcb153222404e2e14

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r12-4891-gbb27f5e9ec3c7ab0f5c859d90c59dd4573b53d97
Author: Aldy Hernandez 
Date:   Thu Nov 4 09:23:24 2021 +0100

Convert arrays in ssa pointer_equiv_analyzer to auto_vec's.

The problem in this PR is an off-by-one bug.  We should've allocated
num_ssa_names + 1.  However, in fixing this, I noticed that
num_ssa_names can change between queries, so I have replaced the array
with an auto_vec and added code to grow the vector as necessary.

Tested on x86-64 Linux.

PR tree-optimization/103062

gcc/ChangeLog:

PR tree-optimization/103062
* value-pointer-equiv.cc (ssa_equiv_stack::ssa_equiv_stack):
Increase size of allocation by 1.
(ssa_equiv_stack::push_replacement): Grow as needed.
(ssa_equiv_stack::get_replacement): Same.
(pointer_equiv_analyzer::pointer_equiv_analyzer): Same.
(pointer_equiv_analyzer::~pointer_equiv_analyzer): Remove delete.
(pointer_equiv_analyzer::set_global_equiv): Grow as needed.
(pointer_equiv_analyzer::get_equiv): Same.
(pointer_equiv_analyzer::get_equiv_expr): Remove const.
* value-pointer-equiv.h (class pointer_equiv_analyzer): Remove
const markers.  Use auto_vec instead of tree *.

gcc/testsuite/ChangeLog:

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

[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840

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

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

--- Comment #4 from Martin Liška  ---
All right, so I would ideally use:

/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
has_arch_pwr7 } } } } */

but I see the following problem with detection of the target:

 78 Executing on host: /dev/shm/objdir/gcc/xgcc -B/dev/shm/objdir/gcc/
arch_pwr759296.c  -fdiagnostics-plain-output  -S   -o arch_pwr759296.s   
(timeout = 300)
 79 spawn -ignore SIGHUP /dev/shm/objdir/gcc/xgcc -B/dev/shm/objdir/gcc/
arch_pwr759296.c -fdiagnostics-plain-output -S -o arch_pwr759296.s^M
 80 arch_pwr759296.c:3:18: error: #error does not have power7 support.^M
 81 compiler exited with status 1   
 82 output is:  
 83 arch_pwr759296.c:3:18: error: #error does not have power7 support.^M

Note the 

#ifndef _ARCH_PWR7

only works when one uses -mcpu=native (or a corresponding -mflag), am I right?
Shouldn't the function check_effective_target_has_arch_pwr7 pass -mcpu=native?

[Bug other/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32

[pexu--- via Gcc-bugs]

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

--- Comment #8 from Pekka S  ---
Created attachment 51734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51734=edit
For CPP_FOR_BUILD use $(CC_FOR_BUILD) -E instead of $(CPP).

The problem is that when $(CPP) is not defined it is set to $(CC) -E by default
(by GNU make).  However, CPP_FOR_BUILD shall use CC_FOR_BUILD, not CC.

[Bug ipa/103073] [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578 since r12-4401-gfecd145359fc981b

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Hubicka  ---
mine.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

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

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

--- Comment #6 from Andrew Pinski  ---
VRP2:
Predicate evaluates to: DON'T KNOW
Matching expression match.pd:1972, gimple-match.c:819
Matching expression match.pd:1975, gimple-match.c:892
Matching expression match.pd:1982, gimple-match.c:952
Not folded
Folding PHI node: d_5 = PHI 
Queued PHI for removal.  Folds to: 0
Folding statement: if (d_5 >= 0)
gimple_simplified to if (1 != 0)
gimple_simplified to if (1 != 0)
Folded into: if (1 != 0)

Is it because of the uninitilized variable causing this to be done this way?

Here is a testcase which does not need an inline function but it shows that
there needs to be an uninitilized variable on a path and all.
int a, b = -2;
int main() {
  int d = 0;
  int t;
  if (b)
goto t1;
  if (t) {
t1:
if (!a)
  d = b;
while (d > -1)
  ;
  }
  return 0;
}

[Bug fortran/102460] fortran internal compile error in coverage.c

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #8 from Martin Liška  ---
Unassigning as it's a Fortran issue (where I asked at Fortran mailing list).

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

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

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

--- Comment #5 from Martin Liška  ---
> static int c() {
>   if (b)
> return b;
> }

Yes, one can use the return value as long as the function returns a value.
This means, c() can be used iff b != 0.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> The problem is latent though. The issue is reassociatation introduces an
> unconditional use of an uninitilized vairable:

Whoops that is not the issue here though.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

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

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

--- Comment #3 from Andrew Pinski  ---
The problem is latent though. The issue is reassociatation introduces an
unconditional use of an uninitilized vairable:
Before
  if (b.1_3 != 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 116348739]:
  if (_5(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]
After:
  _6 = _5(D) | b.1_3;
  _7 = _6 != 0;
  if (_7 != 0)
goto ; [34.00%]
  else
goto ; [66.00%]