[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

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

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

--- Comment #50 from Martin Liška  ---
(In reply to David Binderman from comment #49)
> Created attachment 51095 [details]
> C source code
> 
> Command line is
> 
> /home/dcb/gcc/working/./gcc/xgcc  -B/home/dcb/gcc/working/./gcc/  -g -O3
> -march
> =bdver2 -c bug734.c
> 
> and the reduced version of the code is
> 
> $ more bug734.c
> #pragma GCC push_options
> #pragma GCC pop_options
> $

Thanks for it. For some reason, I can't still reproduce it. Please provide the
output of -v option here.

[Bug target/101275] [RISCV] Document the machine constraint 'S' and make it non-internal

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

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #1 from Kito Cheng  ---
I am happy to add it to document, here it the patch:

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574318.html

[Bug c/101289] bogus -Wvla-paramater warning when using const for vla param

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
  Known to fail||11.1.0, 12.0

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574310.html

[Bug c/97548] bogus -Wvla-parameter on a bound expression involving a parameter

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
  Known to fail||11.1.0
   Target Milestone|--- |11.2

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574310.html

[Bug libstdc++/101274] [11/12 Regression] std::execution::seq has incorrect behaviour under GCC 11.1.0

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

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

--- Comment #4 from Thomas Rodgers  ---
I did some more reading of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4878.pdf and it would
seem that you are not even guaranteed a deterministic ordering of the
application of binary_op on the non-execution policy accepting overloads of
std::reduce().

See [reduce] the note at bullet 9 -

"[Note 1 : The difference between reduce and accumulate is that reduce applies
binary_op in an unspecified order, which yields a nondeterministic result for
non-associative or non-commutative binary_op such as floating-point addition. —
end note]"

[Bug ipa/101279] Function attributes often block inlining

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-07-02
 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Martin Sebor  ---
Compiling the test case with -Winline shows the problem:

pr101279.c: In function ‘foo’:
pr101279.c:2:19: warning: inlining failed in call to ‘wrapped_add’:
optimization level attribute mismatch [-Winline]
2 | static inline int wrapped_add(int a, int b) {
  |   ^~~
pr101279.c:7:12: note: called from here
7 | return wrapped_add(wrapped_add(x, y), z);
  |^
pr101279.c:2:19: warning: inlining failed in call to ‘wrapped_add’:
optimization level attribute mismatch [-Winline]
2 | static inline int wrapped_add(int a, int b) {
  |   ^~~
pr101279.c:7:12: note: called from here
7 | return wrapped_add(wrapped_add(x, y), z);
  |^

Declaring wrapped_add() with attribute always_inline avoids the warning but
also loses the -fwrapv option.  This also seems somewhat surprising and could
stand be made clearer in the manual.  The manual says "this attribute inlines
the function independent of any restrictions that otherwise apply to inlining."
but I see no such restrictions discussed under the optimize attribute or in the
inlining setion (https://gcc.gnu.org/onlinedocs/gcc/Inline.html).

But this report isn't just about attribute optimize but rather about the
general inconsistency of the interplay between inlining and each function
attribute, and the lack of documentation of it.  Confirmed.  I'll see if I can
add a few words to the manual for now.

[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #7 from sandra at gcc dot gnu.org ---
I think the remaining bind(c) problems are the same bug that is causing
failures in tests

interoperability/cf-out-descriptor-6.f90
interoperability/fc-descriptor-6.f90
interoperability/fc-out-descriptor-6.f90
interoperability/ff-descriptor-6.f90
intrinsics/size.f90

from the new TS29113 testsuite posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html

TS29113 says:

  (1) for an assumed-rank object that is associated with an 
  assumed-size array, the result has the value −1 if DIM is 
  present and equal to the rank of ARRAY

Also in the description of CFI_cdesc_t in section 8.3.3, it says

  In a C descriptor of an assumed-size array, the extent member of the
  last element of the dim member has the value −1.

Neither of these things appears to be happening.  

This might also be related to PR 94289?

[Bug c/101289] bogus -Wvla-paramater warning when using const for vla param

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

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Depends on||97548
 Status|NEW |ASSIGNED


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548
[Bug 97548] bogus -Wvla-parameter on a bound expression involving a parameter

[Bug c/101289] bogus -Wvla-paramater warning when using const for vla param

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

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |11.2
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-07-01

--- Comment #1 from Martin Sebor  ---
Confirmed.  The root cause is the same as in pr97548 even though the test case
here is quite different.  They're both worth adding to the test suite.

[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #17 from kargl at gcc dot gnu.org ---
> 
> gfortran.dg/ts29113/interoperability/cf-out-descriptor-3.f90
> gfortran.dg/ts29113/interoperability/cf-out-descriptor-4.f90
> gfortran.dg/ts29113/interoperability/fc-out-descriptor-4.f90
> 
> from my new TS29113 testsuite

Hi Sandra,

I have general question.  Why are you using the ts29113
designation for your BIND(C) testing?  ISO/IEC TS 29113:2012
was incorporated into the Fortran 2018 standard.  There 
appears to be a few changes/additions in Fortran 2018
that are not present in TS 29113.

[Bug tree-optimization/101290] New: ICE with -O1 on valid code: in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:5976

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 101290
   Summary: ICE with -O1 on valid code: in
maybe_canonicalize_mem_ref_addr, at gimple-fold.c:5976
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

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

$ cat mutant.c
typedef *a;
typedef struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
unsigned b, c, d, e
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, d, e, f
} b, c, d, e, f
  } b, c, f
} * g;
int h;
struct i k;
struct i {
  a j
} l(struct i *m) {
  *(volatile *)&((g)m->j)->f;
}
n() {
  k.j = 
  l();
}

$ gcc-trunk -w -O1 mutant.c
during GIMPLE pass: copyprop
mutant.c: In function ‘n’:
mutant.c:66:1: internal compiler error: in maybe_canonicalize_mem_ref_addr, at
gimple-fold.c:5976
   66 | n() {
  | ^
0x6def4a maybe_canonicalize_mem_ref_addr
/tmp/tmp.66z1mEqhUB-gcc-builder/gcc/gcc/gimple-fold.c:5976
0xc1f18a fold_stmt_1
/tmp/tmp.66z1mEqhUB-gcc-builder/gcc/gcc/gimple-fold.c:6085
0x10db4c6 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/tmp/tmp.66z1mEqhUB-gcc-builder/gcc/gcc/tree-ssa-propagate.c:853
0x194d647 dom_walker::walk(basic_block_def*)
/tmp/tmp.66z1mEqhUB-gcc-builder/gcc/gcc/domwalk.c:309
0x10da869 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/tmp/tmp.66z1mEqhUB-gcc-builder/gcc/gcc/tree-ssa-propagate.c:987
0x104726a fini_copy_prop
/tmp/tmp.66z1mEqhUB-gcc-builder/gcc/gcc/tree-ssa-copy.c:566
0x104726a execute_copy_prop
/tmp/tmp.66z1mEqhUB-gcc-builder/gcc/gcc/tree-ssa-copy.c:619
0x104726a execute
/tmp/tmp.66z1mEqhUB-gcc-builder/gcc/gcc/tree-ssa-copy.c:649
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c/101289] New: bogus -Wvla-paramater warning when using const for vla param

[ljrk at ljrk dot org via Gcc-bugs]

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

Bug ID: 101289
   Summary: bogus -Wvla-paramater warning when using const for vla
param
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ljrk at ljrk dot org
  Target Milestone: ---

Created attachment 51099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51099=edit
minimum working/reproducing example

If the vla parameter has a const specifier, the compiler will warn about
mismatched bounds:

$ cat mwe.c && make CFLAGS=-Wvla-parameter mwe.o 
extern void mwe(const int len, char buf[len]);
void mwe(const int len, char buf[len]) {}
cc -Wvla-parameter   -c -o mwe.o mwe.c
mwe.c:2:30: warning: argument 2 of type ‘char[len]’ declared with mismatched
bound ‘len’ [-Wvla-parameter]
2 | void mwe(const int len, char buf[len]) {}
  | ~^~~~
mwe.c:1:37: note: previously declared as ‘char[len]’ with bound ‘len’
1 | extern void mwe(const int len, char buf[len]);
  |~^~~~
$

If I remove the const specifier to len, the warning goes away:

$ sed 's/const //g' -i mwe.c && make CFLAGS=-Wvla-parameter mwe.o  
cc -Wvla-parameter   -c -o mwe.o mwe.c
$

Maybe this is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548 ?

[Bug target/101177] sh3: internal compiler error: Illegal instruction

[gcc_bugzilla at foobar dot franken.de via Gcc-bugs]

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

--- Comment #2 from Harold Gutch  ---
Created attachment 51098
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51098=edit
revert the change of condition

[Bug target/101177] sh3: internal compiler error: Illegal instruction

[gcc_bugzilla at foobar dot franken.de via Gcc-bugs]

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

Harold Gutch  changed:

   What|Removed |Added

 CC||gcc_bugzilla at foobar dot 
franken
   ||.de

--- Comment #1 from Harold Gutch  ---
(In reply to Roland Illig from comment #0)
> $ cat lex.c
> int
> lex_input(void);
> 
> int
> lex_character_constant(void);
> 
> int
> lex_character_constant(void)
> {
> int c = lex_input();
> if (c == 7)
> return c;
> c &= 255;
> return c == 0 ? -1 : c;
> }
> 
> $ /home/rillig/builds/sh3-tools/bin/sh--netbsdelf-gcc --version
> sh--netbsdelf-gcc (NetBSD nb1 20200907) 9.3.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> 
> $ /home/rillig/builds/sh3-tools/bin/sh--netbsdelf-gcc lex.c -O1
> sh--netbsdelf-gcc: internal compiler error: Illegal instruction signal
> terminated program cc1

This is not specific to the NetBSD cross toolchain, this also happens with a
vanilla GCC built on Linux, verified with both 9.3.0 and git head.

I bisected this to commit 91f66e78cc141da77ff9e0e3c8519e1af3f26c07 ,
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/sh/sh.md;h=e19e977087db4d5231f2276af53a42ee82bd50de;hp=2645fca47383c96571f4750033f893ad869e;hb=91f66e78cc141da77ff9e0e3c8519e1af3f26c07;hpb=8faa81184f856447084a9ee41a63fc4be6bca572

I cannot claim to understand the details of this patch, but note that in the
second part of the diff the condition gets inverted.  Take for this the simple
case of SUBREG_P(reg) being false, then this changed from

  if (find_regno_note (curr_insn, REG_DEAD, REGNO (operands[0])) == NULL_RTX)

to

  if (find_regno_note (curr_insn, REG_DEAD, REGNO (operands[0])) != NULL_RTX)

After changing this back to "==", the test case passes for me again, and I can
run a full build of NetBSD/Dreamcast (SH3).  I have not verified however if the
built system works correctly.

[Bug ipa/101279] Function attributes often block inlining

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

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

--- Comment #1 from Andrew Pinski  ---
See also https://gcc.gnu.org/legacy-ml/gcc/2009-02/msg00408.html which was a
way forward for wrapv but there was not much work on it really since that year.
 The work on this has a huge impact to the IR really.

[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #16 from sandra at gcc dot gnu.org ---
There seems to be no actual v2 patch at the link posted previously

https://gcc.gnu.org/pipermail/fortran/2021-April/055991.html

or the recent mail pinging that patch, and the original version at

https://gcc.gnu.org/pipermail/fortran/2020-February/054001.html

doesn't apply cleanly.  Can you repost the patch or attach it to this issue?

I think this PR may be the same issue that is affecting 

gfortran.dg/ts29113/interoperability/cf-out-descriptor-3.f90
gfortran.dg/ts29113/interoperability/cf-out-descriptor-4.f90
gfortran.dg/ts29113/interoperability/fc-out-descriptor-4.f90

from my new TS29113 testsuite

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html

and I'd like to try out the proposed fix.

My own diagnosis was "Fortran function with C binding fails to automatically
deallocate intent(out) allocated allocatable on entry when called from C". 
These testcases additionally trigger nasty errors from the memory allocator.

[Bug target/101286] [12 Regression] ICE: in ix86_expand_vector_move, at config/i386/i386-expand.c:574 with -mavx2 and __int128 vector

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/101179] y % (x ? 16 : 4) and y % (4 << (2 * (bool)x)) produce different code

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

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

--- Comment #9 from Andrew Pinski  ---
Here is one more function which should be the same:
int f0(int y)
{
const bool x = y % 100 == 0;
return (y & ((4 << (x * 2)) - 1)) != 0;
}

[Bug c++/101288] New: Invalid instantiated redeclaration considered valid by gcc

[eligorkadaf at gmail dot com via Gcc-bugs]

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

Bug ID: 101288
   Summary: Invalid instantiated redeclaration considered valid by
gcc
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eligorkadaf at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/KG5WG43vE

https://eel.is/c++draft/temp.spec#temp.inst-example-4

template
struct Outer {
  template struct Inner;
  template struct Inner; // #1a
  template struct Inner { }; // #1b; OK: valid redeclaration
of #1a
  template struct Inner { }; // #2
};

Outer outer;  // error at #2

int main() {}

[Bug tree-optimization/101179] y % (x ? 16 : 4) and y % (4 << (2 * (bool)x)) produce different code

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

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

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

[Bug middle-end/101251] Optimize i % (b ? C0 : C1) into i & (b ? C0-1 : C1-1) for power of 2 C0 and C1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 101179.

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

[Bug tree-optimization/101179] y % (x ? 16 : 4) and y % (4 << (2 * (bool)x)) produce different code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

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

[Bug middle-end/101252] Optimize (b ? i % C0 : i % C1) into i & (b ? C0-1 : C1-1) for power of 2 C0 and C1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 101179.

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

[Bug c++/101287] Implicit template specialization redefines member function but compiles

[eligorkadaf at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Eligor Kadaf  ---
Agree, and the link was incorrect, so there is a correct one: 
https://godbolt.org/z/zEz8c7abM

[Bug target/101286] [12 Regression] ICE: in ix86_expand_vector_move, at config/i386/i386-expand.c:574 with -mavx2 and __int128 vector

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-01
 Ever confirmed|0   |1
   Priority|P3  |P1
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Most likely r12-1958-gedafb35bdadf309ebb9d1eddc5549f9e1ad49c09

[Bug c++/101287] Implicite template specialization redefines member function but compiles

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

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

--- Comment #1 from Jonathan Wakely  ---
The actual code is required though, as https://gcc.gnu.org/bugs says:

template
struct C {
  void f() { T x; }
  void g() = delete;
};
C c;  // OK, definition of C​::​f is not
instantiated at this point
template<> void C::g() { } // error: redefinition of C​::​g

int main(){}

[Bug c++/101287] New: Implicite template specialization redefines member function but compiles

[eligorkadaf at gmail dot com via Gcc-bugs]

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

Bug ID: 101287
   Summary: Implicite template specialization redefines member
function but compiles
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eligorkadaf at gmail dot com
  Target Milestone: ---

It is exactly an example from the standard, so I don't thin any additional
explanations required.

https://godbolt.org/z/Ebcc7vsjq

https://eel.is/c++draft/temp.spec#temp.inst-example-3

[Bug fortran/93308] bind(c) subroutine changes lower bound of array argument in caller

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

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

--- Comment #8 from sandra at gcc dot gnu.org ---
I tested the second version of the patch; it does fix the bug I observed with
an assumed-rank array argument in a Fortran subroutine with C binding called
from C having lower bound 0 instead of 1.

This is interoperability/cf-descriptor-2.f90 in the new TS29113 testsuite.

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html

I think the patch was approved modulo some small cleanup; can we get it
committed soon so I can cross it off the list of test failures I'm tracking?

[Bug target/101286] New: [12 Regression] ICE: in ix86_expand_vector_move, at config/i386/i386-expand.c:574 with -mavx2 and __int128 vector

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 101286
   Summary: [12 Regression] ICE: in ix86_expand_vector_move, at
config/i386/i386-expand.c:574 with -mavx2 and __int128
vector
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -mavx2 testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:6:6: internal compiler error: in ix86_expand_vector_move, at
config/i386/i386-expand.c:574
6 |   (V){(__int128) 1 << 64 | 1, (__int128) 1 << 64 | 1};
  |  ^
0x7f27cf ix86_expand_vector_move(machine_mode, rtx_def**)
/repo/gcc-trunk/gcc/config/i386/i386-expand.c:574
0x1898c88 gen_movv2ti(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/i386/sse.md:1043
0xcf7da7 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/repo/gcc-trunk/gcc/recog.h:407
0xcf7da7 emit_move_insn_1(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.c:3865
0xcf81f5 emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.c:4035
0xd01f88 store_expr(tree_node*, rtx_def*, int, bool, bool)
/repo/gcc-trunk/gcc/expr.c:6180
0xd02d8e expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.c:5729
0xbb952b expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3943
0xbb952b expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:4041
0xbbfcfa expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:6083
0xbc19a7 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6809
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug fortran/101255] FLUSH statement - error should be negative

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
> F2018 states:
> 
> "Fortran 2008 specifies that the IOSTAT= variable shall be set to a
> processor-dependent negative value if the flush operation is not supported
> for the unit specified. This document specifies that the processor-dependent
> negative27integer value shall be different from the named constants
> IOSTAT_EOR or IOSTAT_END from the intrinsic28module ISO_FORTRAN_ENV."
> 
> However, the following program prints:
> 5002 Specified UNIT in FLUSH is not connected  
>   -2  -1
> shouldn't the 5002 be a negative number (such as -5002)?
> 
> use iso_fortran_env
> implicit none
> character(len=50) :: err
> integer :: i
> !open(99)
> !close(99)
> flush(99,iostat=i,iomsg=err)
> print *, i, err
> print *, IOSTAT_EOR , IOSTAT_END 
> end

diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c
index 7e71ca577e0..4ed1698f17a 100644
--- a/libgfortran/io/file_pos.c
+++ b/libgfortran/io/file_pos.c
@@ -527,7 +527,7 @@ st_flush (st_parameter_filepos *fpp)
 }
   else
 /* FLUSH on unconnected unit is illegal: F95 std., 9.3.5. */ 
-generate_error (>common, LIBERROR_BAD_OPTION,
+generate_error (>common, -LIBERROR_BAD_UNIT,
"Specified UNIT in FLUSH is not connected");

   if (needs_unlock)

[Bug libstdc++/40380] class documentation should mention include file to use

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

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

--- Comment #5 from Jonathan Wakely  ---
If we do this for each class:

@class unique_ptr memory

and enable SHOW_INCLUDE_FILES=YES in the doxygen config, then we get this in
the docs for unique_ptr:

#include 

It also seems to avoid the doxygen bug that causes @ingroup or @addtogroup to
be ignored for classes.

The downside is that SHOW_INCLUDE_FILES=YES also causes the docs for each file
to show a full list of all headers it includes:

#include 
#include 
#include 
#include 

I don't think we want to show those internal headers in the public API docs, so
I've asked for a way to avoid that:
https://github.com/doxygen/doxygen/issues/8639

[Bug c++/100976] [C++23] Make constexpr reference temp constexpr

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

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

--- Comment #3 from Marek Polacek  ---
(In reply to Jason Merrill from comment #2)
> Or rather,
> 
> int main()
> {
>   constexpr const int  = 42;
>   static_assert(r == 42); // { dg-bogus "" }
> }
> 
> [expr.const]/4.7 says that "a temporary object of non-volatile
> const-qualified literal type whose lifetime is extended to that
> of a variable that is usable in constant expressions" is usable in a
> constant expression.

This was actually CWG 2126 which we don't seem to fully implement:

struct A { int n; };

const A  = {1};  // const temporary
A  = (A &)(const A &)A{1};   // const temporary
A & = (A &&)(const A &)A{1}; // const temporary

static_assert(a.n == 1, "");
static_assert(b.n == 1, "");
static_assert(c.n == 1, "");

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #49 from David Binderman  ---
Created attachment 51095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51095=edit
C source code

Command line is

/home/dcb/gcc/working/./gcc/xgcc  -B/home/dcb/gcc/working/./gcc/  -g -O3 -march
=bdver2 -c bug734.c

and the reduced version of the code is

$ more bug734.c
#pragma GCC push_options
#pragma GCC pop_options
$

[Bug c/101285] [9/10/11/12 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_safe_arg_type_equiv_p, at c/c-typeck.c:5830

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12 Regression] ICE: tree   |[9/10/11/12 Regression]
   |check: expected class   |ICE: tree check: expected
   |‘type’, have ‘exceptional’  |class ‘type’, have
   |(error_mark) in |‘exceptional’ (error_mark)
   |c_safe_arg_type_equiv_p, at |in c_safe_arg_type_equiv_p,
   |c/c-typeck.c:5830   |at c/c-typeck.c:5830
 CC||edlinger at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-5312-gc65e18d3331aa999.

[Bug libstdc++/101274] [11/12 Regression] std::execution::seq has incorrect behaviour under GCC 11.1.0

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

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

Thomas Rodgers  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Rodgers  ---
The standard only requires that the the parallel algorithm's execution, when
invoked with std::sequenced_policy, be invoked on the calling thread, and (as
with the other execution policies) allows for the invocations of element access
functions to be indeterminately sequenced on the execution agent.

This is also spelled at -

https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t

"1) The execution policy type used as a unique type to disambiguate parallel
algorithm overloading and require that a parallel algorithm's execution may not
be parallelized. The invocations of element access functions in parallel
algorithms invoked with this policy (usually specified as std::execution::seq)
are indeterminately sequenced in the calling thread."

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

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

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

--- Comment #48 from Martin Liška  ---
> -O3 fine. Looks like an march=bdver2 issue.

All right, so please attach me here the pre-processed source file. I tried
doing that myself (using -O3 -march=bdver2), but it was fine (for some reason).

[Bug libstdc++/101268] Refer manual readers to cppreference.com for API details

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

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

--- Comment #2 from Jonathan Wakely  ---
c.f. PR 40380 comment 4

[Bug libstdc++/97001] API documentation should mention the minimum dialect

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

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

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

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

commit r12-1964-gf2ce64b53fa76a4c192fe51b2f6c5a863a3b1241
Author: Jonathan Wakely 
Date:   Thu Jul 1 00:30:54 2021 +0100

libstdc++: Improvements to Doxygen markup

This attempst to improve the doxygen output to work around what seems to
be some bugs in doxygen (issues 8635 and 8638).

The @addtogroup command doesn't work for entities inside a nested
namespace (see 8635) so we need to close and reopen groups on entering
and elaving nested namespaces. This fixes the problem that
chrono::duration and chrono::time_point were not documented in the
"Time" documentation group. I am unable to make the path classes appear
as part of their relevant groups (File System and Filesystem TS), nor
the contents of  or . I have made some minor
improvements to the docs for those types, including starting to address
PR 97001 by adding @since to the doxygen comments.

This change also excludes the  header from
Doxygen processing, so we don't get an unwanted "Networking-ts" group
in the documentation.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* doc/doxygen/doxygroups.cc: Fix docs for std::literals.
* doc/doxygen/user.cfg.in: Exclude the Networking TS header.
Add some more predefined macros.
* include/bits/fs_fwd.h: Move @addtogroup commands inside
namespaces. Add better documentation.
* include/bits/fs_path.h: Likewise.
* include/experimental/bits/fs_fwd.h: Likewise.
* include/experimental/bits/fs_path.h: Likewise.
* include/ext/throw_allocator.h: Fix typo and improve docs.
* include/std/chrono: Move @addtogroup commands.
* include/std/system_error: Move @addtogroup commands.
* libsupc++/exception: Improve documentation.
* libsupc++/exception.h: Add @since documentation.

[Bug ada/101094] [11/12 regression] Enum_Rep returns unsigned value for negative representation

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug libstdc++/66792] Document sort template in bits/list.tcc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-01
 Depends on||66742
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jonathan Wakely  ---
Fixed in my patch for PR 66742


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742
[Bug 66742] abort on sorting list with custom allocator that is not stateless

[Bug libstdc++/51539] multiplies ::operator () undocumented

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Jonathan Wakely  ---
The class has a doxygen comment. I see no benefit to adding a single sentence
about the operator() to one of the classes and not the other ones in the group.

Closing because nobody is motivated to do anything about this. If you want
improvements then make them yourself. I started doing it twenty years ago but
now I'm doing more important changes to the library.

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #47 from David Binderman  ---
(In reply to David Binderman from comment #46)
> (In reply to David Binderman from comment #43)
> > Rebroken, this time during bootstrap, so much more serious.
> 
> > I'll have a go at dropping the -O3 -march=native back downto
> > -O2 and see what happens.
> 
> -O2 fine. I'll try -O3 without the -march=native.

-O3 fine. Looks like an march=bdver2 issue.

[Bug libstdc++/57840] ::std ::result_of is undocumented

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
It shows up in the latest docs:
https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a03925.html

But several other classes don't appear on the type traits page:
https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a01565.html

That seems to be due to 
https://github.com/doxygen/doxygen/issues/8638

[Bug tree-optimization/101260] [10/11 Regression] Backport 27381e78925 to GCC 11

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #8 from Stefan Schulze Frielinghaus  
---
Pass split2 transforms

(insn 218 222 114 15 (set (reg/v:TI 10 %r10 [orig:87 a ] [87])
(reg/v:TI 18 %f4 [orig:87 a ] [87])) 1466 {movti}
 (nil))

into

(insn 234 222 235 15 (set (reg:DI 10 %r10 [ a ])
(reg:DI 18 %f4)) 1467 {*movdi_64}
 (nil))
(insn 235 234 114 15 (set (reg:DI 11 %r11 [orig:87 a+8 ] [87])
(unspec:DI [
(reg:V2DI 18 %f4)
(const_int 1 [0x1])
] UNSPEC_VEC_EXTRACT)) 495 {*vec_extractv2di}
 (nil))

which is then transformed by cprop_hardreg into

(insn 234 222 235 14 (set (reg:DI 10 %r10 [ a ])
(reg:DI 11 %r11 [18])) 1467 {*movdi_64}
 (expr_list:REG_DEAD (reg:DI 11 %r11 [18]) 
   
  (nil)))
(insn 235 234 114 14 (set (reg:DI 11 %r11 [orig:87 a+8 ] [87])
(unspec:DI [
(reg:V2DI 18 %f4)
(const_int 1 [0x1])
] UNSPEC_VEC_EXTRACT)) 495 {*vec_extractv2di}
 (expr_list:REG_DEAD (reg:V2DI 18 %f4)
(nil)))

where in insn 234 register f4 is substituted by r11 which is wrong. This can
also be observed in the final assembler output:

vlvgp   %v4,%r10,%r11
l   %r2,12(%r1)
ahi %r2,-1
st  %r2,12(%r1)
cijhe   %r2,0,.L13
lgr %r10,%r11   // (*)
vlgvg   %r11,%v4,1

Registers r10 and r11 are moved into v4. The inverse move from v4 into r10 and
r11 is broken since cprop_hardreg wrongly substitutes f4 by r11. Thus the
expected output for (*) is:

lgdr%r10,%f4

[Bug c++/100976] [C++23] Make constexpr reference temp constexpr

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/101220] arm: iwmmxt2: generating bad assembler ?

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

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

--- Comment #4 from Richard Earnshaw  ---
FTR I've committed fixes to binutils on the master and 2.36 branches.  Although
I think this affects binutils 2.34 and later older branches of binutils are
no-longer maintained.

[Bug debug/101283] Several tests fail on Darwin with -gctf

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-01
 Ever confirmed|0   |1

[Bug debug/101283] Several tests fail on Darwin with -gctf

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

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

--- Comment #3 from Iain Sandoe  ---
(In reply to Indu Bhagat from comment #2)
> I see that .section directive needs a different semantic for Darwin.  The
> DWARF debug_info section, for example, appears as:
> 
> .section __DWARF,__debug_info,regular,debug
> Lsection__debug_info:
> Ldebug_info0:
> 
> This implies GCC needs to emit the .ctf section adhering to the required
> semantics. I see now that this recent commit adds the required CTF section
> name strings explicitly for Darwin (config/darwin.h).

that's all fixed with the patch above.. .. but ..

> Not only that, accompanying changes need to be made in gas/bfd to support
> the new __CTF category or the CTF section ?

Well .. how this new feature will be used on non-ELF platforms remains to be
seen.

If there is no platform consumer for the format, then I imagine that the
take-up will be slow.

Darwin does not use GAS/binutils by default, the assembler comes from LLVM, the
"binutils" come in part from LLVM and in part from Apple's "cctools" package. 
Unless there is support for CTF in LLDB the majority of Darwin users will not
be able to make use of it.

GDB can (probably) be built for Darwin (there were some issues last time I
tried), but if there are BFD changes needed? 

There are also test fails which are most likely from Darwin's optimisation of
DWARF debug to eliminate most relocations (by using file-offsets from which the
addresses can be computed by the DWARF importer).  TBH I have not looked at any
of this (and Darwin is not the only non-ELF platform)

[Bug debug/101283] Several tests fail on Darwin with -gctf

[ibhagatgnu at gmail dot com via Gcc-bugs]

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

Indu Bhagat  changed:

   What|Removed |Added

 CC||ibhagatgnu at gmail dot com

--- Comment #2 from Indu Bhagat  ---
I see that .section directive needs a different semantic for Darwin.  The DWARF
debug_info section, for example, appears as:

.section __DWARF,__debug_info,regular,debug
Lsection__debug_info:
Ldebug_info0:

This implies GCC needs to emit the .ctf section adhering to the required
semantics. I see now that this recent commit adds the required CTF section name
strings explicitly for Darwin (config/darwin.h).

Not only that, accompanying changes need to be made in gas/bfd to support the
new __CTF category or the CTF section ?

[Bug ada/101094] [11/12 regression] Enum_Rep returns unsigned value for negative representation

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

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

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

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

commit r11-8667-g3a17c1663a96640874067988ffe36c1d06fb93a1
Author: Eric Botcazou 
Date:   Thu Jul 1 17:57:16 2021 +0200

Use intermediate integer type with proper signedness

This is a minor regression present on mainline and 11 branch, whereby the
value of the Enum_Rep attribute is always unsigned.

gcc/ada/
PR ada/101094
* exp_attr.adb (Get_Integer_Type): Return an integer type with the
same signedness as the input type.

[Bug ada/101094] [11/12 regression] Enum_Rep returns unsigned value for negative representation

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r12-1961-gcdf4576b201aa81fd853b06242b16e4215ead5a9
Author: Eric Botcazou 
Date:   Thu Jul 1 17:57:16 2021 +0200

Use intermediate integer type with proper signedness

This is a minor regression present on mainline and 11 branch, whereby the
value of the Enum_Rep attribute is always unsigned.

gcc/ada/
PR ada/101094
* exp_attr.adb (Get_Integer_Type): Return an integer type with the
same signedness as the input type.

[Bug debug/101283] Several tests fail on Darwin with -gctf

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

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

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

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

commit r12-1960-gcc8453012f75dc6dbd20bf3a94c4819a2bff46db
Author: Iain Sandoe 
Date:   Thu Jul 1 15:02:43 2021 +0100

Darwin: Define a suitable section name for CTF [PR101283]

This is a placeholder name ahead of any CTF implementation on
LLVM (which sets Darwin ABI).  Ideally, we would get agreement
on this choice (or any replacement) before GCC12 is shipped.

PR debug/101283 - Several tests fail on Darwin with -gctf

PR debug/101283

gcc/ChangeLog:

* config/darwin.h (CTF_INFO_SECTION_NAME): New.

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #46 from David Binderman  ---
(In reply to David Binderman from comment #43)
> Rebroken, this time during bootstrap, so much more serious.

> I'll have a go at dropping the -O3 -march=native back downto
> -O2 and see what happens.

-O2 fine. I'll try -O3 without the -march=native.

[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wuninitialized

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

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

--- Comment #12 from Tobias Burnus  ---
character(len=:), allocatable :: aa(:)
character(len=:), pointer :: pp(:)

allocate(character(len=5) :: aa(5), pp(5))
end



gives with  gfortran -Wall

1 | character(len=:), allocatable :: aa(:)
  |  ^
Warning: ‘.aa’ is used uninitialized [-Wuninitialized]
afoo.f90:2:34:

2 | character(len=:), pointer :: pp(:)
  |  ^
Warning: ‘.pp’ is used uninitialized [-Wuninitialized]



The reason is how dtype is initialized:

  D.3965 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <.aa> * 8;
  D.3966 = (sizetype) NON_LVALUE_EXPR <.aa>;
  aa.data = 0B;
  aa.dtype = {.elem_len=(unsigned long) .aa, .rank=1, .type=6};


Later with the alloc, it is correctly set, i.e. it is only an issue for the
initial deallocate state; during allocate:

.aa = 5;
aa.dtype = {.elem_len=(unsigned long) .aa, .rank=1, .type=6};


=> Solution: Don't set .elem_len  if the typespec is expr->ts.deferred)

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

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

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

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

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

commit r12-1958-gedafb35bdadf309ebb9d1eddc5549f9e1ad49c09
Author: H.J. Lu 
Date:   Wed Jun 2 07:15:45 2021 -0700

x86: Convert CONST_WIDE_INT/CONST_VECTOR to broadcast

1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTOR
operands to vector broadcast from an integer with AVX.
2. Add ix86_gen_scratch_sse_rtx to return a scratch SSE register which
won't increase stack alignment requirement and blocks transformation by
the combine pass.

A small benchmark:

https://gitlab.com/x86-benchmarks/microbenchmark/-/tree/memset/broadcast

shows that broadcast is a little bit faster on Intel Core i7-8559U:

$ make
gcc -g -I. -O2   -c -o test.o test.c
gcc -g   -c -o memory.o memory.S
gcc -g   -c -o broadcast.o broadcast.S
gcc -g   -c -o vec_dup_sse2.o vec_dup_sse2.S
gcc -o test test.o memory.o broadcast.o vec_dup_sse2.o
./test
memory  : 147215
broadcast   : 121213
vec_dup_sse2: 171366
$

broadcast is also smaller:

$ size memory.o broadcast.o
   textdata bss dec hex filename
132   0   0 132  84 memory.o
122   0   0 122  7a broadcast.o
$

3. Update PR 87767 tests to expect integer broadcast instead of broadcast
from memory.
4. Update avx512f_cond_move.c to expect integer broadcast.

A small benchmark:

https://gitlab.com/x86-benchmarks/microbenchmark/-/tree/vpaddd/broadcast

shows that integer broadcast is faster than embedded memory broadcast:

$ make
gcc -g -I. -O2 -march=skylake-avx512   -c -o test.o test.c
gcc -g   -c -o memory.o memory.S
gcc -g   -c -o broadcast.o broadcast.S
gcc -o test test.o memory.o broadcast.o
./test
memory  : 425538
broadcast   : 375260
$

gcc/

PR target/100865
* config/i386/i386-expand.c (ix86_expand_vector_init_duplicate):
New prototype.
(ix86_byte_broadcast): New function.
(ix86_convert_const_wide_int_to_broadcast): Likewise.
(ix86_expand_move): Convert CONST_WIDE_INT to broadcast if mode
size is 16 bytes or bigger.
(ix86_broadcast_from_integer_constant): New function.
(ix86_expand_vector_move): Convert CONST_WIDE_INT and CONST_VECTOR
to broadcast if mode size is 16 bytes or bigger.
* config/i386/i386-protos.h (ix86_gen_scratch_sse_rtx): New
prototype.
* config/i386/i386.c (ix86_gen_scratch_sse_rtx): New function.

gcc/testsuite/

PR target/100865
* gcc.target/i386/avx512f-broadcast-pr87767-1.c: Expect integer
broadcast.
* gcc.target/i386/avx512f-broadcast-pr87767-5.c: Likewise.
* gcc.target/i386/avx512vl-broadcast-pr87767-1.c: Likewise.
* gcc.target/i386/avx512vl-broadcast-pr87767-5.c: Likewise.
* gcc.target/i386/avx512f_cond_move.c: Also pass
-mprefer-vector-width=512 and expect integer broadcast.
* gcc.target/i386/pr100865-1.c: New test.
* gcc.target/i386/pr100865-2.c: Likewise.
* gcc.target/i386/pr100865-3.c: Likewise.
* gcc.target/i386/pr100865-4a.c: Likewise.
* gcc.target/i386/pr100865-4b.c: Likewise.
* gcc.target/i386/pr100865-5a.c: Likewise.
* gcc.target/i386/pr100865-5b.c: Likewise.
* gcc.target/i386/pr100865-6a.c: Likewise.
* gcc.target/i386/pr100865-6b.c: Likewise.
* gcc.target/i386/pr100865-6c.c: Likewise.
* gcc.target/i386/pr100865-7a.c: Likewise.
* gcc.target/i386/pr100865-7b.c: Likewise.
* gcc.target/i386/pr100865-7c.c: Likewise.
* gcc.target/i386/pr100865-8a.c: Likewise.
* gcc.target/i386/pr100865-8b.c: Likewise.
* gcc.target/i386/pr100865-8c.c: Likewise.
* gcc.target/i386/pr100865-9a.c: Likewise.
* gcc.target/i386/pr100865-9b.c: Likewise.
* gcc.target/i386/pr100865-9c.c: Likewise.
* gcc.target/i386/pr100865-10a.c: Likewise.
* gcc.target/i386/pr100865-10b.c: Likewise.
* gcc.target/i386/pr100865-11a.c: Likewise.
* gcc.target/i386/pr100865-11b.c: Likewise.
* gcc.target/i386/pr100865-11c.c: Likewise.
* gcc.target/i386/pr100865-12a.c: Likewise.
* gcc.target/i386/pr100865-12b.c: Likewise.
* gcc.target/i386/pr100865-12c.c: Likewise.

[Bug target/100865] Convert CONST_WIDE_INT to broadcast

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

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

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

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

commit r12-1958-gedafb35bdadf309ebb9d1eddc5549f9e1ad49c09
Author: H.J. Lu 
Date:   Wed Jun 2 07:15:45 2021 -0700

x86: Convert CONST_WIDE_INT/CONST_VECTOR to broadcast

1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTOR
operands to vector broadcast from an integer with AVX.
2. Add ix86_gen_scratch_sse_rtx to return a scratch SSE register which
won't increase stack alignment requirement and blocks transformation by
the combine pass.

A small benchmark:

https://gitlab.com/x86-benchmarks/microbenchmark/-/tree/memset/broadcast

shows that broadcast is a little bit faster on Intel Core i7-8559U:

$ make
gcc -g -I. -O2   -c -o test.o test.c
gcc -g   -c -o memory.o memory.S
gcc -g   -c -o broadcast.o broadcast.S
gcc -g   -c -o vec_dup_sse2.o vec_dup_sse2.S
gcc -o test test.o memory.o broadcast.o vec_dup_sse2.o
./test
memory  : 147215
broadcast   : 121213
vec_dup_sse2: 171366
$

broadcast is also smaller:

$ size memory.o broadcast.o
   textdata bss dec hex filename
132   0   0 132  84 memory.o
122   0   0 122  7a broadcast.o
$

3. Update PR 87767 tests to expect integer broadcast instead of broadcast
from memory.
4. Update avx512f_cond_move.c to expect integer broadcast.

A small benchmark:

https://gitlab.com/x86-benchmarks/microbenchmark/-/tree/vpaddd/broadcast

shows that integer broadcast is faster than embedded memory broadcast:

$ make
gcc -g -I. -O2 -march=skylake-avx512   -c -o test.o test.c
gcc -g   -c -o memory.o memory.S
gcc -g   -c -o broadcast.o broadcast.S
gcc -o test test.o memory.o broadcast.o
./test
memory  : 425538
broadcast   : 375260
$

gcc/

PR target/100865
* config/i386/i386-expand.c (ix86_expand_vector_init_duplicate):
New prototype.
(ix86_byte_broadcast): New function.
(ix86_convert_const_wide_int_to_broadcast): Likewise.
(ix86_expand_move): Convert CONST_WIDE_INT to broadcast if mode
size is 16 bytes or bigger.
(ix86_broadcast_from_integer_constant): New function.
(ix86_expand_vector_move): Convert CONST_WIDE_INT and CONST_VECTOR
to broadcast if mode size is 16 bytes or bigger.
* config/i386/i386-protos.h (ix86_gen_scratch_sse_rtx): New
prototype.
* config/i386/i386.c (ix86_gen_scratch_sse_rtx): New function.

gcc/testsuite/

PR target/100865
* gcc.target/i386/avx512f-broadcast-pr87767-1.c: Expect integer
broadcast.
* gcc.target/i386/avx512f-broadcast-pr87767-5.c: Likewise.
* gcc.target/i386/avx512vl-broadcast-pr87767-1.c: Likewise.
* gcc.target/i386/avx512vl-broadcast-pr87767-5.c: Likewise.
* gcc.target/i386/avx512f_cond_move.c: Also pass
-mprefer-vector-width=512 and expect integer broadcast.
* gcc.target/i386/pr100865-1.c: New test.
* gcc.target/i386/pr100865-2.c: Likewise.
* gcc.target/i386/pr100865-3.c: Likewise.
* gcc.target/i386/pr100865-4a.c: Likewise.
* gcc.target/i386/pr100865-4b.c: Likewise.
* gcc.target/i386/pr100865-5a.c: Likewise.
* gcc.target/i386/pr100865-5b.c: Likewise.
* gcc.target/i386/pr100865-6a.c: Likewise.
* gcc.target/i386/pr100865-6b.c: Likewise.
* gcc.target/i386/pr100865-6c.c: Likewise.
* gcc.target/i386/pr100865-7a.c: Likewise.
* gcc.target/i386/pr100865-7b.c: Likewise.
* gcc.target/i386/pr100865-7c.c: Likewise.
* gcc.target/i386/pr100865-8a.c: Likewise.
* gcc.target/i386/pr100865-8b.c: Likewise.
* gcc.target/i386/pr100865-8c.c: Likewise.
* gcc.target/i386/pr100865-9a.c: Likewise.
* gcc.target/i386/pr100865-9b.c: Likewise.
* gcc.target/i386/pr100865-9c.c: Likewise.
* gcc.target/i386/pr100865-10a.c: Likewise.
* gcc.target/i386/pr100865-10b.c: Likewise.
* gcc.target/i386/pr100865-11a.c: Likewise.
* gcc.target/i386/pr100865-11b.c: Likewise.
* gcc.target/i386/pr100865-11c.c: Likewise.
* gcc.target/i386/pr100865-12a.c: Likewise.
* gcc.target/i386/pr100865-12b.c: Likewise.
* gcc.target/i386/pr100865-12c.c: Likewise.

[Bug middle-end/100685] #pragma GCC push_options ineffective for optimize options

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

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

--- Comment #6 from Martin Sebor  ---
Yes, thanks.

[Bug tree-optimization/101272] [12 Regression] error: ‘nonnull’ argument ‘message’ compared to NULL [-Werror=nonnull-compare] since r12-1805

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

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

--- Comment #4 from Martin Liška  ---
Btw. moved to gdb bugzilla as
https://sourceware.org/bugzilla/show_bug.cgi?id=28042.

[Bug tree-optimization/101272] [12 Regression] error: ‘nonnull’ argument ‘message’ compared to NULL [-Werror=nonnull-compare] since r12-1805

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Yes, let me close it.

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #45 from David Binderman  ---
(In reply to Martin Liška from comment #44)
> What CPU do you have? 

AMD FX-8350. 

> What -march=native expands to (-v argument). 

bdver2

> Can you please attach the pre-processed source file.

 I'll let you know when I have it again.

[Bug c/101285] New: [12 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_safe_arg_type_equiv_p, at c/c-typeck.c:5830

[anbu1024.me at gmail dot com via Gcc-bugs]

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

Bug ID: 101285
   Summary: [12 Regression] ICE: tree check: expected class
‘type’, have ‘exceptional’ (error_mark) in
c_safe_arg_type_equiv_p, at c/c-typeck.c:5830
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat 5b.c 

extern char b[1];

void foo(void (*func)(void *), void * z);

static void bar(void * z) 
{
return z;
}

void baz()
{
foo( (void (*)(int (*a)[b++])) bar);
}



$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210627 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-sp12 5b.c 
5b.c: In function ‘bar’:
5b.c:8:12: warning: ‘return’ with a value, in function returning void
8 | return z;
  |^
5b.c:6:13: note: declared here
6 | static void bar(void * z)
  | ^~~
5b.c: In function ‘baz’:
5b.c:13:30: error: lvalue required as increment operand
   13 | foo( (void (*)(int (*a)[b++])) bar);
  |  ^~
5b.c:13:5: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in c_safe_arg_type_equiv_p, at c/c-typeck.c:5830
   13 | foo( (void (*)(int (*a)[b++])) bar);
  | ^~~
0x7a7886 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-12-20210627/gcc/tree.c:8734
0x663d43 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-12-20210627/gcc/tree.h:3496
0x663d43 c_safe_arg_type_equiv_p
../../gcc-12-20210627/gcc/c/c-typeck.c:5830
0x8a8c75 c_safe_function_type_cast_p
../../gcc-12-20210627/gcc/c/c-typeck.c:5872
0x8a8c75 build_c_cast(unsigned int, tree_node*, tree_node*)
../../gcc-12-20210627/gcc/c/c-typeck.c:6079
0x8a9a34 c_cast_expr(unsigned int, c_type_name*, tree_node*)
../../gcc-12-20210627/gcc/c/c-typeck.c:6160
0x8cba45 c_parser_cast_expression
../../gcc-12-20210627/gcc/c/c-parser.c:8058
0x8cbbac c_parser_binary_expression
../../gcc-12-20210627/gcc/c/c-parser.c:7869
0x8cce65 c_parser_conditional_expression
../../gcc-12-20210627/gcc/c/c-parser.c:7592
0x8cd4a0 c_parser_expr_no_commas
../../gcc-12-20210627/gcc/c/c-parser.c:7507
0x8bf207 c_parser_expr_list
../../gcc-12-20210627/gcc/c/c-parser.c:10746
0x8ce66c c_parser_postfix_expression_after_primary
../../gcc-12-20210627/gcc/c/c-parser.c:10475
0x8c5d63 c_parser_postfix_expression
../../gcc-12-20210627/gcc/c/c-parser.c:10178
0x8ca16a c_parser_unary_expression
../../gcc-12-20210627/gcc/c/c-parser.c:8224
0x8cb939 c_parser_cast_expression
../../gcc-12-20210627/gcc/c/c-parser.c:8066
0x8cbbac c_parser_binary_expression
../../gcc-12-20210627/gcc/c/c-parser.c:7869
0x8cce65 c_parser_conditional_expression
../../gcc-12-20210627/gcc/c/c-parser.c:7592
0x8cd4a0 c_parser_expr_no_commas
../../gcc-12-20210627/gcc/c/c-parser.c:7507
0x8cd721 c_parser_expression
../../gcc-12-20210627/gcc/c/c-parser.c:10641
0x8cde98 c_parser_expression_conv
../../gcc-12-20210627/gcc/c/c-parser.c:10680
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-sp11 --version
gcc (GCC) 11.1.1 20210619
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-sp11 5b.c 
5b.c: In function ‘bar’:
5b.c:8:12: warning: ‘return’ with a value, in function returning void
8 | return z;
  |^
5b.c:6:13: note: declared here
6 | static void bar(void * z)
  | ^~~
5b.c: In function ‘baz’:
5b.c:13:30: error: lvalue required as increment operand
   13 | foo( (void (*)(int (*a)[b++])) bar);
  |  ^~
5b.c:13:5: error: too few arguments to function ‘foo’
   13 | foo( (void (*)(int (*a)[b++])) bar);
  | ^~~
5b.c:4:6: note: declared here
4 | void foo(void (*func)(void *), void * z);
  |  ^~~

[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10

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

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

--- Comment #12 from Christophe Lyon  ---
Yes, I've been working on it for a while, it's proving to be a bit tricky when
switching to HImode as suggested by Richard. I have something working, now
checking I haven't broken Neon.

[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10

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

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

--- Comment #11 from Alex Coplan  ---
@Christophe: do you still plan to look at this? I'm happy to pick it up if not

[Bug other/71268] [PATCH] Fix description of x86_64's -m32 option

[ismael at linux dot com via Gcc-bugs]

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

--- Comment #3 from Ismael Luceno  ---
Ping. The issue is still valid. Is the revised patch acceptable? How can I
improve it?

[Bug middle-end/100685] #pragma GCC push_options ineffective for optimize options

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

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

--- Comment #5 from Martin Liška  ---
Good. So all is fine, right?

[Bug c/101265] C2X [[maybe_unused]] ignored when placed after array declaration

[gcc at alanwu dot email via Gcc-bugs]

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

Alan Wu  changed:

   What|Removed |Added

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

--- Comment #4 from Alan Wu  ---
Thank you! The key paragraph in N2596 seems to be 6.7.6.2p3. I also reached out
to Aaron Ballman for clarification.

gcc is right to ignore the attribute in this case. g++ accepting the attribute
is potentially an issue, since the C++ spec has similar rules ([dcl.array]p3).

Clang accepting the attribute also seems to be a bug. There is now a ticket for
it: https://bugs.llvm.org/show_bug.cgi?id=50954

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

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

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

Bug 101280 Summary: [12 Regression] TSVC s231 slower with -Ofast -march=znver1 
since r12-1836-g0ad9d88a3d7170b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101280

   What|Removed |Added

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

[Bug tree-optimization/101280] [12 Regression] TSVC s231 slower with -Ofast -march=znver1 since r12-1836-g0ad9d88a3d7170b3

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Should be fixed.

[Bug target/101284] conflicting arch/fpu result in unexpected preprocessor defines

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

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

--- Comment #1 from Richard Earnshaw  ---
I think this combination of options should result in an error.  As we move away
from -mfpu to permitting only the 'auto' model, we are increasingly adding
'fpu' features that cannot be expressed via this option since we are not adding
new fpu names any more.

So in some ways, this is an invalid use case, but it does highlight we should
emit a diagnostic in this case.

[Bug target/101284] New: conflicting arch/fpu result in unexpected preprocessor defines

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

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

Bug ID: 101284
   Summary: conflicting arch/fpu result in unexpected preprocessor
defines
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Compiling with -march=armv8.1-m.main+mve.fp -mfpu=neon-fp16 -mfloat-abi=softfp
produces no warning and generates the following defines:
#define __ARM_NEON__ 1
#define __ARM_NEON 1
#define __ARM_NEON_FP 6
#define __ARM_FEATURE_MVE 3

which I didn't expect.

This also means that TARGET_HAVE_MVE is defined in the compiler as well as
TARGET_NEON. So vectorization code that has to do different things for Neon and
MVE can quite easily ICE if you provide all these flags on the command-line.

(I wanted to compare vectorization with MVE and Neon on one testcase and hoped
to override the MVE FPU by just adding -mfpu=neon-fp16 and the end of the
command-line).

[Bug debug/101283] New: Severaal test fail on Darwin with -gctf

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Bug ID: 101283
   Summary: Severaal test fail on Darwin with -gctf
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin20
Target: x86_64-apple-darwin20
 Build: x86_64-apple-darwin20

Severaal test fail on Darwin with -gctf

FAIL: gcc.dg/debug/20020220-1.c -gctf (test for excess errors)
UNRESOLVED: gcc.dg/debug/20020220-1.c -gctf compilation failed to produce
executable
FAIL: gcc.dg/debug/20020327-1.c -gctf (test for excess errors)
FAIL: gcc.dg/debug/20050907-1.c -gctf (test for excess errors)
FAIL: gcc.dg/debug/pr29609-1.c -gctf (test for excess errors)
UNRESOLVED: gcc.dg/debug/pr29609-1.c -gctf compilation failed to produce
executable
FAIL: gcc.dg/debug/pr29609-2.c -gctf (test for excess errors)
UNRESOLVED: gcc.dg/debug/pr29609-2.c -gctf compilation failed to produce
executable
FAIL: gcc.dg/debug/pr36690-1.c -gctf (test for excess errors)
UNRESOLVED: gcc.dg/debug/pr36690-1.c -gctf compilation failed to produce
executable
FAIL: gcc.dg/debug/pr36690-2.c -gctf (test for excess errors)
UNRESOLVED: gcc.dg/debug/pr36690-2.c -gctf compilation failed to produce
executable
FAIL: gcc.dg/debug/pr36690-3.c -gctf (test for excess errors)
UNRESOLVED: gcc.dg/debug/pr36690-3.c -gctf compilation failed to produce
executable
FAIL: gcc.dg/debug/pr37616.c -gctf (test for excess errors)
UNRESOLVED: gcc.dg/debug/pr37616.c -gctf compilation failed to produce
executable
FAIL: gcc.dg/debug/pr41893-1.c -gctf (test for excess errors)
FAIL: gcc.dg/debug/pr49032.c -gctf (test for excess errors)
FAIL: gcc.dg/debug/pr65771.c -gctf (test for excess errors)
FAIL: gcc.dg/debug/tls-1.c -gctf (test for excess errors)
FAIL: gcc.dg/debug/trivial.c -gctf (test for excess errors)
UNRESOLVED: gcc.dg/debug/trivial.c -gctf compilation failed to produce
executable

The errors are

% /opt/gcc/gcc12w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.dg/debug/trivial.c
-gctf
/var/folders/ls/2kcvbftx2bj70mvvv8j7cclmgn/T//ccfWQsWN.s:1:15: error:
unexpected token in '.section' directive
.section .ctf
 ^

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

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

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

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

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

commit r12-1954-g0a77c07b9b3fe83679358c3ef57721e09e2ad5fb
Author: Richard Biener 
Date:   Thu Jul 1 12:49:45 2021 +0200

tree-optimization/101280 - revise interchange fix for PR101173

The following revises the original fix for PR101173 to correctly
check for a reversed dependence rather than disallowing a zero
distance.  It also adds a check from TSVC which asks for this
kind of interchange (but with a valid dependence).

2021-07-01  Richard Biener  

PR tree-optimization/101280
PR tree-optimization/101173
* gimple-loop-interchange.cc
(tree_loop_interchange::valid_data_dependences): Revert
previous change and instead correctly handle DDR_REVERSED_P
dependence.

* gcc.dg/tree-ssa/loop-interchange-16.c: New testcase.

[Bug tree-optimization/101280] [12 Regression] TSVC s231 slower with -Ofast -march=znver1 since r12-1836-g0ad9d88a3d7170b3

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

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

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

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

commit r12-1954-g0a77c07b9b3fe83679358c3ef57721e09e2ad5fb
Author: Richard Biener 
Date:   Thu Jul 1 12:49:45 2021 +0200

tree-optimization/101280 - revise interchange fix for PR101173

The following revises the original fix for PR101173 to correctly
check for a reversed dependence rather than disallowing a zero
distance.  It also adds a check from TSVC which asks for this
kind of interchange (but with a valid dependence).

2021-07-01  Richard Biener  

PR tree-optimization/101280
PR tree-optimization/101173
* gimple-loop-interchange.cc
(tree_loop_interchange::valid_data_dependences): Revert
previous change and instead correctly handle DDR_REVERSED_P
dependence.

* gcc.dg/tree-ssa/loop-interchange-16.c: New testcase.

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

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

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

--- Comment #9 from Richard Biener  ---
In the light of PR101280 I am now testing the following alternate fix for the
original problem, avoiding this regression:

diff --git a/gcc/gimple-loop-interchange.cc b/gcc/gimple-loop-interchange.cc
index 43045c5455e..43ef112a2d0 100644
--- a/gcc/gimple-loop-interchange.cc
+++ b/gcc/gimple-loop-interchange.cc
@@ -1043,8 +1043,11 @@ tree_loop_interchange::valid_data_dependences (unsigned
i_idx, unsigned o_idx,
continue;

  /* Be conservative, skip case if either direction at i_idx/o_idx
-levels is not '=' (for the inner loop) or '<'.  */
- if (dist_vect[i_idx] < 0 || dist_vect[o_idx] <= 0)
+levels is not '=' or '<'.  */
+ if (dist_vect[i_idx] < 0
+ || (DDR_REVERSED_P (ddr) && dist_vect[i_idx] > 0)
+ || dist_vect[o_idx] < 0
+ || (DDR_REVERSED_P (ddr) && dist_vect[o_idx] > 0))
return false;
}
 }

[Bug tree-optimization/101280] [12 Regression] TSVC s231 slower with -Ofast -march=znver1 since r12-1836-g0ad9d88a3d7170b3

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Testing fix.

[Bug tree-optimization/101280] [12 Regression] TSVC s231 slower with -Ofast -march=znver1 since r12-1836-g0ad9d88a3d7170b3

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-01

--- Comment #3 from Richard Biener  ---
void dummy (double *, double *);
#define LEN_2D 32
double aa[LEN_2D][LEN_2D], bb[LEN_2D][LEN_2D];
double s231(int iterations)
{
//loop interchange
//loop with data dependency
for (int nl = 0; nl < 100*(iterations/LEN_2D); nl++) {
for (int i = 0; i < LEN_2D; ++i) {
for (int j = 1; j < LEN_2D; j++) {
aa[j][i] = aa[j - 1][i] + bb[j][i];
}
}
dummy(aa[0],bb[0]);
}
}

compiles and

> gcc-11 t.c -O3 -fopt-info-loop -S
t.c:9:27: optimized: loops interchanged in loop nest
t.c:10:31: optimized: loop vectorized using 16 byte vectors
t.c:4:8: optimized: loop with 15 iterations completely unrolled (header
execution count 33608120)

while trunk only vectorizes.

[Bug d/101282] New: d: RHS value lost when a target_expr appears in a cond_expr

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 101282
   Summary: d: RHS value lost when a target_expr appears in a
cond_expr
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

The assignment ends up looking like:

a = opCmp (, 0) < 0 ? TARGET_EXPR  : a;

---
void main()
{
struct CrippledInt
{
int impl;
CrippledInt opUnary(string op : "-")()
{
return CrippledInt(-impl);
}
int opCmp(int i) { return (impl < i) ? -1 : (impl > i) ? 1 : 0; }
}
auto a = CrippledInt(120);
a = -a;
assert(a.impl == -120);
a = a >= 0 ? a : -a;
assert(a.impl == 120); // fails
}

[Bug tree-optimization/101280] [12 Regression] TSVC s231 slower with -Ofast -march=znver1 since r12-1836-g0ad9d88a3d7170b3

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

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

--- Comment #2 from Richard Biener  ---
Seems to be this one:

real_t s231(struct args_t * func_args)
{
//loop interchange
//loop with data dependency

initialise_arrays(__func__);
gettimeofday(_args->t1, NULL);

for (int nl = 0; nl < 100*(iterations/LEN_2D); nl++) {
for (int i = 0; i < LEN_2D; ++i) {
for (int j = 1; j < LEN_2D; j++) {
aa[j][i] = aa[j - 1][i] + bb[j][i];
}
}
dummy(a, b, c, d, e, aa, bb, cc, 0.);
}

gettimeofday(_args->t2, NULL);
return calc_checksum(__func__);
}

[Bug target/94096] amdgcn build instructions missing

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Thomas Schwinge  ---
This has been addressed in r268146 (Git commit
1b7ee8b4c9124d611caf46f74f7d2ce1a5d283b3) "Document AMD GCN" etc., and
 etc.

[Bug tree-optimization/101278] [12 regression] g++ miscompiles cmake-3.18.5

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.0
Summary|[11/12 Regression] Get  |[11 Regression] Get SIGFPE
   |SIGFPE on simple test with  |on simple test with
   |-fpe-trap=invalid and SLP   |-fpe-trap=invalid and SLP
   |vectorization ON, with  |vectorization ON, with
   |gfortran 11.1.0 on x86_64   |gfortran 11.1.0 on x86_64

--- Comment #10 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/101278] [12 regression] g++ miscompiles cmake-3.18.5

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

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

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

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

commit r12-1952-g4a87605938428f6c4c62d5b92cfc183cd2b2554e
Author: Richard Biener 
Date:   Thu Jul 1 11:16:01 2021 +0200

tree-optimization/101278 - handle self-use in DSE analysis

DSE store classification short-cuts the to-be classified stmt itself
from chaining but fails to first check whether the store uses itself
which can be the case when it is a call with the LHS also passed by
value as argument.

2021-07-01  Richard Biener  

PR tree-optimization/101278
* tree-ssa-dse.c (dse_classify_store): First check for
uses, then ignore stmt for chaining purposes.

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

[Bug tree-optimization/100778] [11/12 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64

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

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

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

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

commit r12-1951-ga3aaba68405751bae3f630669515b7ecdf77efa6
Author: Richard Biener 
Date:   Thu Jul 1 10:35:38 2021 +0200

tree-optimization/100778 - fix placement of trapping vectorized ops

This avoids placing possibly trapping vectorized operations where
the corresponding scalar operation was possibly not executed.

2021-01-07  Richard Biener  

PR tree-optimization/100778
* tree-vect-slp.c (vect_schedule_slp_node): Do not place trapping
vectorized ops ahead of their scalar BB.

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

[Bug tree-optimization/101280] [12 Regression] TSVC s231 slower with -Ofast -march=znver1 since r12-1836-g0ad9d88a3d7170b3

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |12.0
 Blocks||101173

--- Comment #1 from Richard Biener  ---
Can you paste the loop kernel?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101173
[Bug 101173] [9/10/11 Regression] wrong code at -O3 on x86_64-linux-gnu

[Bug d/101273] d: missed RVO optimization with non-pod structs

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #0)
> It looks like fixing PR d/100882 introduced a small regression:
On further inspection, this is not the case.  The front-end semantic pass
returns us code that uses an intermediate temporary. i.e:

  return __ctor((S tmp = S(), ), 42);

The code generator in D just doesn't detect this pattern and replace `tmp' with
the DECL_RESULT variable to give us a more desired representation:

  S tmp [value-expr: ];
  __ctor( = S(), &, 42);
  return ;

[Bug fortran/101281] [11/12 Regression] ICE with -std=f2003/f2008 and assumed-rank array

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |11.2

[Bug fortran/96797] OpenACC fortran acc_get_cuda_stream

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   See Also||https://github.com/OpenACC/
   ||openacc-spec/issues/25
 CC||tschwinge at gcc dot gnu.org
   Last reconfirmed||2021-07-01

[Bug fortran/96080] OpenACC/Fortran runtime library routines vs. Fortran 'pointer'

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://github.com/OpenACC/
   ||openacc-spec/issues/57
 Status|NEW |WAITING

[Bug fortran/101281] [11/12 Regression] ICE with -std=f2003/f2008 and assumed-rank array

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

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

--- Comment #1 from Tobias Burnus  ---
The main culprit is:

subroutine ar3 (xn) bind(C)
  character(len=n) :: xn(:,:,:)
end

and I forgot to mention that 'n' is only implicitly defined - otherwise, there
is not ICE.

[Bug fortran/101281] New: [11/12 Regression] ICE with -std=f2003/f2008 and assumed-rank array

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

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

Bug ID: 101281
   Summary: [11/12 Regression] ICE with -std=f2003/f2008 and
assumed-rank array
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51094=edit
Compile with -std=f2003 or -std=f2008

Found when working on a BIND(C) character testcase. Can probably be reduced.

The problem seems to be related to assumed-rank arrays and it only occurs (at
least in this testcase) for -std=f2003 and -std=f2008, i.e. it works with
-std=-f2008.

I did see it with GCC 11 and GCC 12 - but GCC 10 also showed:
(null):0: confused by earlier errors, bailing out

For some reasons, it does sometimes not crash with 'f951' in the debugger,
unless I pass '-quiet'

It looks as if some error recovery is failing. In any case:

0x008e6ca6 in gfc_resolve_expr (e=0x270a9f0) at
../../repos/gcc/gcc/fortran/resolve.c:7085
7085  else if (e->symtree != NULL
(gdb) p e->symtree
$1 = (gfc_symtree *) 0x270a9b0
(gdb) p e->symtree->n.sym
$2 = (gfc_symbol *) 0x0

The proc being processed is:

(gdb) p gfc_current_ns->proc_name->name
$9 = 0x7716f258 "a3ar"


Depending how the code is reduced, the ICE is gone. However, I did not try very
hard to reduce the code.


Stacktrace is:

(gdb) p *e
$6 = {expr_type = EXPR_VARIABLE, ts = {type = BT_UNKNOWN,
and all values are 0 except for 'where' and 'symtree'.


ICEs in

0xeb368f crash_signal
../../repos/gcc/gcc/toplev.c:328
0x8e6ca6 gfc_resolve_expr(gfc_expr*)
../../repos/gcc/gcc/fortran/resolve.c:7086
0x8ea58a gfc_resolve_expr(gfc_expr*)
../../repos/gcc/gcc/fortran/resolve.c:7071
0x8ea58a resolve_index_expr
../../repos/gcc/gcc/fortran/resolve.c:12444
0x8ea58a resolve_charlen
../../repos/gcc/gcc/fortran/resolve.c:12497
0x8ee550 resolve_charlen
../../repos/gcc/gcc/fortran/resolve.c:12465
0x8ee550 resolve_types
../../repos/gcc/gcc/fortran/resolve.c:17343

[Bug tree-optimization/101280] New: [12 Regression] TSVC s231 slower with -Ofast -march=znver1 since r12-1836-g0ad9d88a3d7170b3

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

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

Bug ID: 101280
   Summary: [12 Regression] TSVC s231 slower with -Ofast
-march=znver1 since r12-1836-g0ad9d88a3d7170b3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Seen e.g. here:
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.847.0

[Bug c/87911] OpenACC/OpenMP clauses parsing: comma operator vs. separator

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

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

--- Comment #3 from Jakub Jelinek  ---
For OpenMP, I think after the clarification it got fixed in
r9-3992-g81a227c6054a82118d80d3f4b2fffb44bc43aae2
There is still the fuzzy case whether #pragma omp declare reduction combiner
expression should allow commas or not, all compilers I've checked do allow it
there and IMNSHO it is the right thing, but maybe the standard doesn't allow
that, but it is the standard that should be fixed in that case.
#pragma omp declare reduction(+:struct S:omp_out.x += omp_in.x, omp_out.y +=
omp_in.y)

[Bug c/87911] OpenACC/OpenMP clauses parsing: comma operator vs. separator

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
   Last reconfirmed||2021-07-01
   See Also||https://github.com/OpenACC/
   ||openacc-spec/pull/363
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Thomas Schwinge  ---
For OpenACC this got discussed/resolved in
 "Issue 354: Disallow C/C++
comma operators" (similar to the OpenMP wording), and -- if I remember
correctly -- Tobias verified that the GCC/OpenACC implementation behaves
properly?

Don't know about the OpenMP status.

[Bug c/99137] ICE in gimplify_scan_omp_clauses, at gimplify.c:9833

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

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

--- Comment #10 from Thomas Schwinge  ---
*** Bug 87912 has been marked as a duplicate of this bug. ***

[Bug c/87912] ICE with comma operator in C OpenACC async clause

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |burnus at gcc dot 
gnu.org
 Resolution|--- |DUPLICATE
 CC||burnus at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
Tobias fixed this in PR99137 "ICE in gimplify_scan_omp_clauses, at
gimplify.c:9833".

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

[Bug middle-end/101204] [12 Regression] infinite recursion in gtype-desc.c since r12-1801-g7036e9ef462fde8181bece4ac4e03f3aa27204dc

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|infinite recursion in   |[12 Regression] infinite
   |gtype-desc.c|recursion in gtype-desc.c
   ||since
   ||r12-1801-g7036e9ef462fde818
   ||1bece4ac4e03f3aa27204dc
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-01

--- Comment #4 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #1)
> Most likely r12-1801-g7036e9ef462fde8181bece4ac4e03f3aa27204dc

It really started with this revision.

[Bug target/101044] -ABS(A) produces two neg instructions

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Fixed.

[Bug target/101044] -ABS(A) produces two neg instructions

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:9f6aeb85ee87c6b4e580b6b71e26cbe99e1dab70

commit r12-1950-g9f6aeb85ee87c6b4e580b6b71e26cbe99e1dab70
Author: Uros Bizjak 
Date:   Thu Jul 1 10:56:32 2021 +0200

i386: Add integer nabs instructions [PR101044]

The patch adds integer nabs "(NEG (ABS (...)))" instructions, adds STV
conversion and adjusts STV cost calculations accordingly.  When CMOV
instruction is used to implement abs, the sign is determined from the
preceeding operand negation, and CMOVS is used to select between
negated and non-negated value.

To implement nabs, just reverse the condition and emit CMOVNS instead.

The STV costs are adjusted for inherent NOT of nabs insn. V2DI NOT is
somehow costly operation, since it is implemented as a load of zero,
followed by a SUB insn. OTOH, integer nabs with inherent NOT is relatively
cheap, so some STV chains became less profitable for conversion.

The patch rewrites operand scanner in compute_convert_gain to a switch
and reorders case instances in general_scalar_to_vector_candidate_p
to benefit from fallthroughs, and to remove special processing of
andnot in the later case.

gcc/

2021-07-01  Uroš Bizjak  

PR target/101044
* config/i386/i386.md (*nabs2_doubleword):
New insn_and_split pattern.
(*nabs2_1): Ditto.
* config/i386/i386-features.c
(general_scalar_chain::compute_convert_gain):
Handle (NEG (ABS (...))) RTX.  Rewrite src code
scanner as switch statement.
(general_scalar_chain::convert_insn):
Handle (NEG (ABS (...))) RTX.
(general_scalar_to_vector_candidate_p):
Detect  (NEG (ABS (...))) RTX.  Reorder case statements
for (AND (NOT (...) ...)) fallthrough.

gcc/testsuite/

2021-07-01  Uroš Bizjak  

PR target/101044
* gcc.target/i386/pr101044.c: New test.

[Bug tree-optimization/101278] [12 regression] g++ miscompiles cmake-3.18.5

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

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

--- Comment #4 from Richard Biener  ---
Created attachment 51093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51093=edit
untested patch

I will test this.  Self-assignments x = x are handled explicitely already.

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

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

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

--- Comment #44 from Martin Liška  ---
(In reply to David Binderman from comment #43)
> Rebroken, this time during bootstrap, so much more serious.
> 
> /home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/
> -B/home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/bin/
> -B/home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/lib/ -isystem
> /home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/include -isystem
> /home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/sys-include  
> -fchecking=1 -g -O3 -march=native -O2  -g -O3 -march=native -DIN_GCC-W
> -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
> -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag
> -Wold-style-definition  -isystem ./include  -fpic -mlong-double-80
> -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc
> -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
> -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../trunk.git/libgcc
> -I../../../trunk.git/libgcc/. -I../../../trunk.git/libgcc/../gcc
> -I../../../trunk.git/libgcc/../include
> -I../../../trunk.git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
> -DHAVE_CC_TLS  -DUSE_TLS -o _cmpdi2_s.o -MT _cmpdi2_s.o -MD -MP -MF
> _cmpdi2_s.dep -DSHARED -DL_cmpdi2 -c ../../../trunk.git/libgcc/libgcc2.c
> In file included from /home/dcb/gcc/working/gcc/include/x86gprintrin.h:37,
>  from
> ../../../trunk.git/libgcc/config/i386/shadow-stack-unwind.h:25,
>  from ./md-unwind-support.h:27,
>  from ../../../trunk.git/libgcc/unwind-dw2.c:412:
> /home/dcb/gcc/working/gcc/include/bmi2intrin.h:106:9: internal compiler
> error: ‘global_options’ are modified in local context
>   106 | #pragma GCC pop_options
>   | ^~~
> 
> Configure lines are:
> 
> ../trunk.git/configure --prefix=/home/dcb/gcc/$PREFIX \
>   --disable-multilib \
>   --disable-werror \
>   --with-pkgversion=$HASH \
>   --enable-checking=df,extra,fold,rtl,yes \
>   --enable-languages=c,c++,fortran,d,go
> 
> sed 's/-O2/-O3 -march=native/' < Makefile > Makefile.tmp
> diff Makefile Makefile.tmp
> mv Makefile.tmp Makefile
> 
> I'll have a go at dropping the -O3 -march=native back downto
> -O2 and see what happens.

What CPU do you have? What -march=native expands to (-v argument). Can you
please attach the pre-processed source file.