[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 98674 Summary: [10 Regression] vectorizer failed for compilation time alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98674

   What|Removed |Added

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

[Bug tree-optimization/98674] [10 Regression] vectorizer failed for compilation time alias

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
But eventually needs backporting.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
The warning often warns on dead code.
But even if the warning is right, that doesn't make it ice-on-invalid-code.
The code may have UB at runtime, but that UB doesn't need to be ever triggered
when running the program.
ice-on-invalid-code stands for code that should be rejected (diagnosed with
errors, not warnings), but instead of giving the error we ICE on it instead.
That is not the case here.

[Bug target/70454] --with-arch=native isn't applied to 32-bit x86 target library

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #7 from H.J. Lu  ---
*** Bug 98695 has been marked as a duplicate of this bug. ***

[Bug target/98695] [r11-6672 Regression] Failed to bootstrap on Linux/x86_64

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Dup.

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

[Bug bootstrap/98696] New: ICE when build x86_64-elf-cross compiler with MinGW-w64

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 98696
   Summary: ICE when build x86_64-elf-cross compiler with
MinGW-w64
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

cp ../../gcc/gcc/../fixincludes/README-fixinc include-fixed/README
chmod a+r include-fixed/README
echo timestamp > stmp-int-hdrs
/home/unlvs/gcc_newlib/./gcc/xgcc -B/home/unlvs/gcc_newlib/./gcc/ -xc -nostdinc
nul -S -o nul -fself-test=../../gcc/gcc/testsuite/selftests
/home/unlvs/gcc_newlib/./gcc/xgcc -B/home/unlvs/gcc_newlib/./gcc/ -xc++
-nostdinc nul -S -o nul -fself-test=../../gcc/gcc/testsuite/selftests
../../gcc/gcc/diagnostic.c:2200:
test_print_parseable_fixits_bytes_vs_display_columns: FAIL: ASSERT_STREQ
(expected, pp_formatted_text ())
val1="fix-it:"D:\msys64\tmp\ccc0Ff2h.c":{1:12-1:18}:"color"
" val2="fix-it:"D:\\msys64\\tmp\\ccc0Ff2h.c":{1:12-1:18}:"color"
"
cc1.exe: internal compiler error: in fail_formatted, at selftest.c:63
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [../../gcc/gcc/c/Make-lang.in:127: s-selftest-c] Error 1
make[1]: *** Waiting for unfinished jobs
../../gcc/gcc/diagnostic.c:2200:
test_print_parseable_fixits_bytes_vs_display_columns: FAIL: ASSERT_STREQ
(expected, pp_formatted_text ())
val1="fix-it:"D:\msys64\tmp\ccQy4uLi.c":{1:12-1:18}:"color"
" val2="fix-it:"D:\\msys64\\tmp\\ccQy4uLi.c":{1:12-1:18}:"color"
"
cc1plus.exe: internal compiler error: in fail_formatted, at selftest.c:63
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [../../gcc/gcc/cp/Make-lang.in:196: s-selftest-c++] Error 1
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[1]: Leaving directory '/home/unlvs/gcc_newlib/gcc'
make: *** [Makefile:4770: all-gcc] Error 2

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[crazylht at gmail dot com via Gcc-bugs]

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

Bug 98674 Summary: [10 Regression] vectorizer failed for compilation time alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98674

   What|Removed |Added

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

[Bug tree-optimization/98674] [10 Regression] vectorizer failed for compilation time alias

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #9 from Hongtao.liu  ---
Fixed in GCC11.

[Bug target/98681] [8/9/10/11 Regression] aarch64: Invalid ubfiz instruction rejected by assembler

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87511 .

[Bug target/98695] New: cc1: error: ‘-fcf-protection’ is not compatible with this target

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 98695
   Summary: cc1: error: ‘-fcf-protection’ is not compatible with
this target
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-*-* i?86-*-*

gcc build fail with configure as

Using built-in specs.
COLLECT_GCC=./gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: /export/users2/liuhongt/gcc/git_trunk/master/configure
--disable-bootstrap --enable-languages=c,c++,fortran,lto,objc,obj-c++
--prefix=/export/users2/liuhongt/install/git_trunk_master
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210115 (experimental) (GCC)

error output.

make[8]: *** [Makefile:857: fxor_1_.lo] Error 1
cc1: error: ‘-fcf-protection’ is not compatible with this target
cc1: error: ‘-fcf-protection’ is not compatible with this target
cc1: error: ‘-fcf-protection’ is not compatible with this target
cc1: error: ‘-fcf-protection’ is not compatible with this target
make[8]: *** [Makefile:857: fnand_1_.lo] Error 1
make[8]: *** [Makefile:857: store_2_.lo] Error 1
make[8]: *** [Makefile:857: cas_2_.lo] Error 1
make[8]: *** [Makefile:857: exch_1_.lo] Error 1
make[8]: *** [Makefile:857: fadd_2_.lo] Error 1
make[8]: *** [Makefile:857: load_2_.lo] Error 1
cc1: error: ‘-fcf-protection’ is not compatible with this target
make[8]: *** [Makefile:857: exch_2_.lo] Error 1
make[8]: *** [Makefile:857: tas_1_.lo] Error 1
cc1: error: ‘-fcf-protection’ is not compatible with this target
make[8]: *** [Makefile:857: fsub_2_.lo] Error 1
make[7]: *** [Makefile:608: all-recursive] Error 1
make[6]: *** [Makefile:448: all] Error 2
make[5]: *** [Makefile:903: multi-do] Error 1
make[4]: *** [Makefile:873: all-multi] Error 2
make[4]: *** Waiting for unfinished jobs
make[3]: *** [Makefile:608: all-recursive] Error 1
make[2]: *** [Makefile:448: all] Error 2
make[1]: *** [Makefile:19169: all-target-libatomic] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:971: all] Error 2

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

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

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

--- Comment #5 from Segher Boessenkool  ---
The "warninb" says
  warning: ‘void* memcpy(void*, const void*, long unsigned int)’ writing 32
bytes into a region of size 8 overflows the destination [-Wstringop-overflow=]

It says it is wrong, so it is not a warning, it is an error.

Perhaps that warning is just completely broken, it is lying to the user?

[Bug tree-optimization/98694] New: GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server

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

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

Bug ID: 98694
   Summary: GCC produces incorrect code for loops with -O3 for
skylake-avx512 and icelake-server
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

The reproducer is a bit big, but I was not able to reduce it further.
Reproducer:

// func.cpp
#include 

extern short var_1, var_29, var_89;
extern unsigned var_2, var_11;
extern bool var_4;
extern long var_6;
extern char var_7;
extern int var_8, var_10;
extern short arr_206[10][14][13][21][14] __attribute__((aligned));
extern int arr_257[];

long f(long l) { return 0 > l ? 0 : l; }

void test() {
  var_11 = var_6;
  for (char a = 0; a < (char)var_2; a = 6)
for (int b = 0; b < var_2; b = ~0)
  for (int c = 0; c < 2; c = var_1)
for (bool d = 0; d < var_4; d = 1)
  var_29 = f(~var_6);
  for (short e = 0; e < short(var_6); e = var_6) {
for (; 0 < (int)var_6;)
  ;
for (char g = 0; g < 4; g++)
  for (; std::min(var_7 / 405077347810ULL, (unsigned long long)9);
   var_7 += 2)
for (char h = 0; h < (char)var_8; h += 4)
  for (short i = 0; i < (var_4 && var_6) + 13; i++) {
arr_206[0][g][0][h][i] = var_6;
var_89 = std::min(var_4 ?: 709U, (unsigned)var_4);
  }
for (short j = 0; j < var_2; j += 4)
  for (int k = 0; k < 5U; k = var_10)
arr_257[k] = var_6;
  }
}

// driver.cpp
#include 

short var_1 = (short)7531;
unsigned int var_2 = 187158918U;
bool var_4 = (bool)1;
unsigned long long int var_6 = 10263287916162477044ULL;
signed char var_7 = 0;
long long int var_8 = 21;
unsigned int var_10 = 3309705747U;
unsigned int var_11 = 222967114U;
short var_29 = (short)-22723;
short var_89 = (short)-19017;
short arr_206 [10] [14] [13] [21] [14] __attribute__((aligned));
int arr_257 [5];

void test();

int main() {
test();
for (size_t i_0 = 0; i_0 < 5; ++i_0)
printf("%d ", arr_257 [i_0]);
printf("\n");
}

Error:

>$ g++ -march=skylake-avx512 func.cpp driver.cpp -O2 && sde -skx -- ./a.out 
-2039714828 0 0 0 0 
>$ g++ -march=skylake-avx512 func.cpp driver.cpp -O3 && sde -skx -- ./a.out 
27636 0 0 0 0

gcc version 11.0.0 20210113 (8fc183ccd0628465205b8a88c29ab69bfe74a08a)

[Bug tree-optimization/98673] pass fre4 inhibit pass dom3 to create much more optimized code

[rjiejie at me dot com via Gcc-bugs]

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

--- Comment #2 from jojo  ---
(In reply to Richard Biener from comment #1)
> The analysis sounds a bit confused.  What is the transform that DOM cannot
> do after the transform that FRE does?  There's some older bug about
> out-of-SSA
> coalescing issues with loops and liveness of induction variables but it's
> not clear if this is related (the assembly doesn't show the loop exit block).
> 
> Can you name the loop in the source that is problematic?
> 

see this loop:

  for( i1 = 0 ; i1 < ( numXEntries - 1 ) ; i1++ )
{
if( ( loadValue < engLoad[i1+1] ) && ( loadValue >= engLoad[i1] ) )
{
break ;
}
}

[Bug c++/98687] [11 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at cp/name-lookup.c:2729 since r11-6652-g796ead19f85372

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

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

--- Comment #2 from Marek Polacek  ---
Adjusted test:

extern "C" namespace std {
  double log1p(double);
}
namespace std_fallback {
  template  void log1p();
}
template  struct log1p_impl {
  static int run() {
using std::log1p;
using std_fallback::log1p;
return 0;
  }
};
void log1p() { log1p_impl::run(); }

[Bug tree-optimization/98629] [11 Regression] ice during GIMPLE pass: widening_mul

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/98693] New: Compiling with -mcmodel=large emits .eh_frame with R_X86_64_PC32

[chorman64 at gmail dot com via Gcc-bugs]

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

Bug ID: 98693
   Summary: Compiling with -mcmodel=large emits .eh_frame with
R_X86_64_PC32
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chorman64 at gmail dot com
  Target Milestone: ---

I am attempting to use gcc to build an operating system for x86_64. I recently
reconfigured it to use the higher half of memory so that OS routines may be
preserved in userspace maps. However, when building with gcc using
`-mcmodel=large`, I get relocation overflow errors (from gold) in `.eh_frame`
(which is presumably a synthetic section, as I have written no sections by that
name). The error persists using gcc with lld (though it is reported
differently, and reports the relocation).
The same issue does not occur when building with the same flags using clang
with lld.

[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
The warning used to be in the FEs but that didn't work, see PR69835 for
details.

[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #9 from Eugene Rozenfeld  ---
I used XXX_MIN for consistency with comments on other patterns. If TYPE_MIN is
preferable, the change should be made in all of those comments as well.

[Bug c++/86769] g++ destroys condition variable in for statement too early

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

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

--- Comment #5 from Marek Polacek  ---
Further poking revealed that the patch above mishandles

// PR c++/86769
// { dg-do run }

#define assert(X) do { if (!(X)) __builtin_abort(); } while(0)

int g;

struct X {
  X() { g++; }
  ~X() { g--; }
  operator bool() { return g == 0; }
};

void
check_live ()
{
  assert (g > 0);
}

void
check_dead ()
{
  assert (g == 0);
}

void f(X &) { assert (!g); }

int
main ()
{
  for (int i = 0; i < 1; ++i, check_dead ())
{
  X x = X();
  check_live ();
}
}

So saving it here lest I lose it.

[Bug target/70454] --with-arch=native isn't applied to 32-bit x86 target library

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

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

H.J. Lu  changed:

   What|Removed |Added

   Keywords||patch
   Last reconfirmed||2021-01-14
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jakub at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
   Target Milestone|--- |11.0
Version|6.0 |11.0

--- Comment #6 from H.J. Lu  ---
Starting from

commit 77d372abec0fbf2cfe922e3140ee3410248f979e
Author: H.J. Lu 
Date:   Thu Jan 14 05:56:46 2021 -0800

x86: Error on -fcf-protection with incompatible target

GCC issues an error on -fcf-protection with incompatible target.  CET
is enabled in run-time libraries on x86 when GCC is configured with SSE2
enabled.  But 32-bit libitm/libgomp/libatomic are hardcoded to
compile with -march=i486 which is incompatible with CET.  We should
compile libitm/libgomp/libatomic -march=i486 only if the default -march=
is lower than i486.

Patches are posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563532.html

[Bug tree-optimization/98598] Missed opportunity to optimize dependent loads in loops

[jiangning.liu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #12 from Jiangning Liu  
---
MGO RFC is at https://gcc.gnu.org/pipermail/gcc/2021-January/234682.html

[Bug jit/98586] libgccjit crashes with segmentation fault on failed gcc_assert

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

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

David Malcolm  changed:

   What|Removed |Added

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

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

[Bug jit/98586] libgccjit crashes with segmentation fault on failed gcc_assert

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

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

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

https://gcc.gnu.org/g:387f6c15d303a8f8da508e419fea10a6ef0e2590

commit r11-6700-g387f6c15d303a8f8da508e419fea10a6ef0e2590
Author: David Malcolm 
Date:   Thu Jan 14 17:02:28 2021 -0500

Handle fancy_abort before diagnostic initialization [PR98586]

If fancy_abort is called before the diagnostic subsystem is initialized,
internal_error will crash internally in a way that prevents a useful
message reaching the user.

This can happen with libgccjit in the case of gcc_assert failures
that occur outside of the libgccjit mutex that guards the rest of
gcc's state, including global_dc (when global_dc may not be
initialized yet, or might be in use by another thread).

I tried a few approaches to fixing this as noted in PR jit/98586
e.g. using a temporary diagnostic_context and initializing it for
the call to internal_error, however the more code that runs, the
more chance there is for other errors to occur.

The best fix appears to be to simply fall back to a minimal abort
implementation that only relies on i18n, as implemented by this
patch.

gcc/ChangeLog:
PR jit/98586
* diagnostic.c (diagnostic_kind_text): Break out this array
from...
(diagnostic_build_prefix): ...here.
(fancy_abort): Detect when diagnostic_initialize has not yet been
called and fall back to a minimal implementation of printing the
ICE, rather than segfaulting in internal_error.

[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Uroš Bizjak  ---
Comment on attachment 49969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49969
Optimize combination of comparisons to dec+compare

>+/* y == XXX_MIN || x < y --> x <= y - 1 */

Can we use TYPE_MIN instead of XXX_MIN?

[Bug tree-optimization/97223] Failure to optimize comparison of char arithmetic to single comparison

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #4 from Eugene Rozenfeld  ---
The commit that fixed this:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=32ee472864ada44ef05b2a3b087b8ce413bee282

[Bug rtl-optimization/98692] Unitialized Values reported only with -Os

[nick.child at ibm dot com via Gcc-bugs]

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

--- Comment #1 from Nick Child  ---
Created attachment 49971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49971=edit
source

[Bug rtl-optimization/98692] New: Unitialized Values reported only with -Os

[nick.child at ibm dot com via Gcc-bugs]

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

Bug ID: 98692
   Summary: Unitialized Values reported only with -Os
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nick.child at ibm dot com
  Target Milestone: ---
  Host: powerpcle-*-linux-gnu*
Target: powerpcle-*-linux-gnu*
 Build: powerpcle-*-linux-gnu*

Created attachment 49970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49970=edit
Preprocesssed File

Hello all,

This is my first go at something like this so I apologize for any cringes now.
Recently, I implemented memory checks into our CI using valgrind. Everything
works fine on x86 with the same commands but gives issues when running on
POWER. Specifically, only when using the `-Os` size optimizer flag. Things like
`O2` and `O3` don't bring about any errors. While the code runs fine, these
valgrind errors are a bit alarming. I have run into the issue using the
following compiler versions and OS's:
gcc version 9.3.1 20200408 (Red Hat 9.3.1-2)
gcc version 10.2.1 20200723 (Red Hat 10.2.1-1)
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)

The errors revolve around an conditional jump on unitialized variables. I am
thinking it is a stack allocation issue. I have tried to narrow down my issue
to as simple a program as possible (attached). 
I then build using:
   $ gcc -Os issue.c -o issue
Compilation works and binary executes normally but valgrind complains with:
   $ valgrind ./issue

This could very well be a valgrind mistake, with too many things being
optimized off of the executable for valgrind to accurately keep track of
memory.

Here is the output from valgrind:

==3557285== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==3557285== Command: leak
==3557285==
==3557285== Conditional jump or move depends on uninitialised value(s)
==3557285==at 0x416E9B8: __vfprintf_internal (vfprintf-internal.c:1332)
==3557285==by 0x415E33B: printf@@GLIBC_2.17 (printf.c:33)
==3557285==by 0x15D3: main (in /home/jenkins/testPlace/test2/leak)
==3557285==
==3557285== Use of uninitialised value of size 8
==3557285==at 0x40A14DC: strchrnul (vg_replace_strmem.c:1394)
==3557285==by 0x416E9D3: __find_specmb (printf-parse.h:111)
==3557285==by 0x416E9D3: __vfprintf_internal (vfprintf-internal.c:1365)
==3557285==by 0x415E33B: printf@@GLIBC_2.17 (printf.c:33)
==3557285==by 0x15D3: main (in /home/jenkins/testPlace/test2/leak)
==3557285==
==3557285== Use of uninitialised value of size 8
==3557285==at 0x40A14F0: strchrnul (vg_replace_strmem.c:1394)
==3557285==by 0x416E9D3: __find_specmb (printf-parse.h:111)
==3557285==by 0x416E9D3: __vfprintf_internal (vfprintf-internal.c:1365)
==3557285==by 0x415E33B: printf@@GLIBC_2.17 (printf.c:33)
==3557285==by 0x15D3: main (in /home/jenkins/testPlace/test2/leak)
==3557285==
==3557285== Conditional jump or move depends on uninitialised value(s)
==3557285==at 0x418BABC: _IO_file_xsputn@@GLIBC_2.17 (fileops.c:1204)
==3557285==by 0x416EA33: __vfprintf_internal (vfprintf-internal.c:1373)
==3557285==by 0x415E33B: printf@@GLIBC_2.17 (printf.c:33)
==3557285==by 0x15D3: main (in /home/jenkins/testPlace/test2/leak)
==3557285==
==3557285== Conditional jump or move depends on uninitialised value(s)
==3557285==at 0x418BC94: _IO_new_file_xsputn (fileops.c:1253)
==3557285==by 0x418BC94: _IO_file_xsputn@@GLIBC_2.17 (fileops.c:1197)
==3557285==by 0x416EA33: __vfprintf_internal (vfprintf-internal.c:1373)
==3557285==by 0x415E33B: printf@@GLIBC_2.17 (printf.c:33)
==3557285==by 0x15D3: main (in /home/jenkins/testPlace/test2/leak)
==3557285==
...
...
...
==3558101==
==3558101== HEAP SUMMARY:
==3558101== in use at exit: 0 bytes in 0 blocks
==3558101==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==3558101==
==3558101== All heap blocks were freed -- no leaks are possible
==3558101==
==3558101== Use --track-origins=yes to see where uninitialised values come from
==3558101== For lists of detected and suppressed errors, rerun with: -s
==3558101== ERROR SUMMARY: 44 errors from 31 contexts (suppressed: 0 from 0)

[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #7 from Eugene Rozenfeld  ---
Thank you for the feedback, Gabriel and Jakub. I re-worked the patch based on
your suggestions. I attached the new patch and also sent it to gcc-patches.

[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare

[erozen at microsoft dot com via Gcc-bugs]

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

Eugene Rozenfeld  changed:

   What|Removed |Added

  Attachment #49940|0   |1
is obsolete||

--- Comment #6 from Eugene Rozenfeld  ---
Created attachment 49969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49969=edit
Optimize combination of comparisons to dec+compare

[Bug analyzer/98679] Four functions could be marked "const".

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by the above commit.

[Bug c++/98691] New: co_await in a conditional operator evaluates an unreachable code

[mail+gnu at tzik dot jp via Gcc-bugs]

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

Bug ID: 98691
   Summary: co_await in a conditional operator evaluates an
unreachable code
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mail+gnu at tzik dot jp
  Target Milestone: ---

In the repro case below, `foo()` in `co_return false ? co_await foo() : 1;`
should not be evaluated, and we should not see "NOTREACHED" text there.
That can be reproduced on the current master (9ac3e2feb3da89ed) and 10.2.0 by
$ g++ -std=c++20 -fcoroutines foo.cc && ./a.out

https://wandbox.org/permlink/KV2C7FhM561ETYFU
 foo.cc
#include 
#include 

#ifdef __clang__
#include 
namespace std {
  using namespace std::experimental;
}
#else
#include 
#endif

class promise;

class task {
 public:
  using promise_type = promise;
  using handle_type = std::coroutine_handle;

  explicit task(handle_type handle) : handle_(handle) {}
  ~task() { if (handle_) handle_.destroy(); }

  task(task&& other) : handle_(std::exchange(other.handle_, nullptr)) { }
  task& operator=(task&& other) {
if (handle_) handle_.destroy();
handle_ = std::exchange(other.handle_, nullptr);
return *this;
  }

 private:
  handle_type handle_;

  task(const task&) = delete;
  task& operator=(const task&) = delete;
};

class promise {
 public:
  promise() = default;
  ~promise() = default;

  std::suspend_never initial_suspend() noexcept { return {}; }
  std::suspend_always final_suspend() noexcept { return {}; }
  void unhandled_exception() noexcept { abort(); }

  task get_return_object() {
return task{std::coroutine_handle::from_promise(*this)};
  }

  void return_value(int rv) {
std::cout << rv << std::endl;
  }

 private:
  promise(const promise&) = delete;
  promise operator=(const promise&) = delete;
};

struct suspend_never_with_int {
  bool await_ready() { return true; }
  void await_suspend(std::coroutine_handle<>) {}
  int await_resume() { return 42; }
};

suspend_never_with_int foo() {
  std::cout << "NOTREACHED" << std::endl;
  return {};
}

task failcase() {
  co_return false ? co_await foo() : 1;
}

int main() {
  failcase();
  return 0;
}

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

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

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|mpolacek at gcc dot gnu.org|jason at gcc dot gnu.org
 CC||jason at gcc dot gnu.org

--- Comment #16 from Jason Merrill  ---
Mine.

[Bug analyzer/98679] Four functions could be marked "const".

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

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

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

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

commit r11-6689-g8a18261afd923151b8d2a37f667e4673b27acd3f
Author: David Malcolm 
Date:   Thu Jan 14 15:25:27 2021 -0500

analyzer: const fixes [PR98679]

gcc/analyzer/ChangeLog:
PR analyzer/98679
* analyzer.h (region_offset::operator==): Make const.
* pending-diagnostic.h (pending_diagnostic::equal_p): Likewise.
* store.h (binding_cluster::for_each_value): Likewise.
(binding_cluster::for_each_binding): Likewise.

[Bug target/98671] gcc/config/i386/i386-options.c:787:redundantAssignment

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to David Binderman from comment #5)
> (In reply to Uroš Bizjak from comment #4)
> > I'm not sure if solving this would bring us anything.
> 
> For clarity, at very most a 4% reduction in the size of the stack frame
> for function ix86_parse_stringop_strategy_string.

Unfortunately, patched and unpatched compiler results in the same frame size:

011dc690 <_ZL35ix86_parse_stringop_strategy_stringPcb>:
 11dc690:   41 57   push   %r15
 11dc692:   41 56   push   %r14
 11dc694:   41 55   push   %r13
 11dc696:   41 54   push   %r12
 11dc698:   55  push   %rbp
 11dc699:   53  push   %rbx
 11dc69a:   48 89 fbmov%rdi,%rbx
 11dc69d:   48 81 ec 08 01 00 00sub$0x108,%rsp
 ...

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

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

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

Bug 96984 Summary: bogus -Warray-bounds with -fsanitize due to FRE substituting 
subobjects at the same address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96984

   What|Removed |Added

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

[Bug tree-optimization/94655] [10/11 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a

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

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

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

[Bug middle-end/96984] bogus -Warray-bounds with -fsanitize due to FRE substituting subobjects at the same address

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
The underlying root cause is the same as in pr94655 so I'm going to resolve
this as a duplicate.

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

[Bug libstdc++/98471] [11 Regression] libstdc++ fails to build with clang on windows because of filesystem bug

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #5)
> Should be fixed now.

thank you!

[Bug c++/98690] New: unexpected "'removed_return.213' may be used uninitialized in this function" causes crash

[savoiu at yahoo dot com via Gcc-bugs]

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

Bug ID: 98690
   Summary: unexpected "'removed_return.213' may be used
uninitialized in this function" causes crash
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: savoiu at yahoo dot com
  Target Milestone: ---

Created attachment 49968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49968=edit
code exhibiting bug

When compiling the attached code I get:

error: 'removed_return.213' may be used uninitialized in this function
[-Werror=maybe-uninitialized]

and the error points to the 'endl' in that line.

If I downgrade the "maybe-uninitialized" to just a warning then it compiles but
the code crashes on that line.

The command line is:

  g++ -fnon-call-exceptions -Wmaybe-uninitialized -O2 gcc10bug.cpp
gcc10bug_main.cpp

If I remove -fnon-call-exceptions the the code compiles and runs as expected.
The code also runs just fine with GCC 9.1.0.

[Bug fortran/93340] [8/9/10/11 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Should be fixed on master.

[Bug fortran/93340] [8/9/10/11 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-6687-gbdd1b1f55529da00b867ef05a53a08fbfc3d1c2e
Author: Harald Anlauf 
Date:   Thu Jan 14 20:25:33 2021 +0100

PR fortran/93340 - fix missed substring simplifications

Substrings were not reduced early enough for use in initializations,
such as DATA statements.  Add an early simplification for substrings
with constant starting and ending points.

gcc/fortran/ChangeLog:

* gfortran.h (gfc_resolve_substring): Add prototype.
* primary.c (match_string_constant): Simplify substrings with
constant starting and ending points.
* resolve.c: Rename resolve_substring to gfc_resolve_substring.
(gfc_resolve_ref): Use renamed function gfc_resolve_substring.

gcc/testsuite/ChangeLog:

* substr_10.f90: New test.
* substr_9.f90: New test.

[Bug other/98689] New: FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O1 execution test

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

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

Bug ID: 98689
   Summary: FAIL: gcc.dg/torture/stackalign/builtin-return-1.c
-O1  execution test
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-*
Target: hppa*-*-*
 Build: hppa*-*-*

Created attachment 49967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49967=edit
.s file

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/stackalign/builtin-re
turn-1.c-fdiagnostics-plain-output-O1-lm  -o ./builtin-return-1.exe
   (timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/stackalign/builtin-
return-1.c -fdiagnostics-plain-output -O1 -lm -o ./builtin-return-1.exe
PASS: gcc.dg/torture/stackalign/builtin-return-1.c   -O1  (test for excess
error
s)
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/obj
dir/hppa-linux-gnu/./libatomic/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/g
nu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/hppa-li
nux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.
libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src/.libs:/home/dave/gnu
/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gn
u/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./pr
ev-gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dav
e/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linu
x-gnu/libphobos/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs
:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/obj
dir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O1  execution test

Similar fails:
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O1 -fpic execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O2  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O2 -fpic execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O3 -g -fpic execution
test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -Os  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -Os -fpic execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O2 -flto
-flto-partition=none -fpic execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c   -O2 -flto -fpic execution
test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O0  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O0 -fpic execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O1  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O1 -fpic execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O2  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O2 -fpic execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O3 -g  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O3 -g -fpic execution
test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -Os  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -Os -fpic execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O2 -flto
-flto-partition=none -fpic execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-2.c   -O2 -flto -fpic execution
test

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P4  |P1
 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Why do you think it is invalid?  The fact that there is some warning emitted
(which often has false positives) doesn't mean the code is invalid.
P4 is for error-recovery bugs or bugs affecting non-primary languages.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #39 from Mikael Pettersson  ---
I tried the few test cases listed in this PR with gcc-11 on sparcv9-linux-gnu,
but wasn't able to observe any miscompilation.

[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #15 from Ian Lance Taylor  ---
Should be fixed.

[Bug target/98688] C++ modules support does not work on PowerPC with opaque MMA types vector_pair/vector_quad

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

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
I don't know if this is the right thing to do, but ignoring the opaque type
here make the ICE go away. I suspect I need to construct a module test case
using vector_pair/vector_quad to really test this though.


diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index d2093916c9e..3ec0b04def3 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -8831,6 +8831,10 @@ trees_out::type_node (tree type)
   }
   break;

+case OPAQUE_TYPE:
+  /* No additional data.  */
+  break;
+
 case OFFSET_TYPE:
   tree_node (TYPE_OFFSET_BASETYPE (type));
   break;

[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
The commit in comment#4 unfortunately contained debugging stuff that should
never have been pushed.  Thus reverted and created the new commit in comment#5.

Sorry for that.

[Bug c++/98687] [11 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at cp/name-lookup.c:2729 since r11-6652-g796ead19f85372

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Well, that was quick.  Mine.

[Bug target/98688] New: C++ modules support does not work on PowerPC with opaque MMA types vector_pair/vector_quad

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

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

Bug ID: 98688
   Summary: C++ modules support does not work on PowerPC with
opaque MMA types vector_pair/vector_quad
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
  Target Milestone: ---

Similar to PR98645, we run into trouble if we try to compile code using
vector_pair/vector_quad using -fmodule-header:

/home/sawdey/work/gcc/trunk2/build/gcc/xg++
-B/home/sawdey/work/gcc/trunk2/build/gcc/
/home/sawdey/work/gcc/trunk2/gcc/gcc/testsuite/gcc.target/powerpc/mma-builtin-2.c
   -std=c++2a -fmodule-header  -S -o mb2.s
/home/sawdey/work/gcc/trunk2/gcc/gcc/testsuite/gcc.target/powerpc/mma-builtin-2.c:
internal compiler error: in type_node, at cp/module.cc:8779
0x10468287 trees_out::type_node(tree_node*)
../../gcc/gcc/cp/module.cc:8779
0x1046446b trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9106
0x10467dcb trees_out::type_node(tree_node*)
../../gcc/gcc/cp/module.cc:8773
0x1046446b trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9106
0x10465d57 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6088
0x1046783b trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7141
0x1046783b trees_out::fn_parms_init(tree_node*)
../../gcc/gcc/cp/module.cc:10037
0x10461833 trees_out::decl_value(tree_node*, depset*)
../../gcc/gcc/cp/module.cc:7738
0x1046e163 depset::hash::find_dependencies()
../../gcc/gcc/cp/module.cc:13199
0x1046eae7 module_state::write(elf_out*, cpp_reader*)
../../gcc/gcc/cp/module.cc:17568
0x10470313 finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:19747
0x103ae82f c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:5178
0x1072cad7 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1233
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

It looks like trees_out::type_node() needs to understand opaque type, and
possibly whatever reads that in needs to understand it on the way in as well.

[Bug c++/98687] [11 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at cp/name-lookup.c:2729 since r11-6652-g796ead19f85372

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.2.0
   Target Milestone|--- |11.0
 Ever confirmed|0   |1
  Known to fail||11.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-14
   Priority|P3  |P1

[Bug c++/98687] New: [11 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at cp/name-lookup.c:2729 since r11-6652-g796ead19f

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

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

Bug ID: 98687
   Summary: [11 Regression] ICE tree check: expected tree that
contains ‘decl minimal’ structure, have ‘overload’ in
diagnose_name_conflict, at cp/name-lookup.c:2729 since
r11-6652-g796ead19f85372e5
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Reduced from bitcoin package:

$ cat mesh.ii
extern "C" namespace std { void log1p(); }
namespace std_fallback {
template  void log1p();
}
template  struct log1p_impl {
  static int run() {
using std::log1p;
using std_fallback::log1p;
return 0;
  }
};
void log1p() { log1p_impl::run; }

$ g++ mesh.ii -c
mesh.ii:1:33: warning: declaration of ‘void std::log1p()’ conflicts with
built-in declaration ‘double std::log1p(double)’
[-Wbuiltin-declaration-mismatch]
1 | extern "C" namespace std { void log1p(); }
  | ^
mesh.ii: In instantiation of ‘static int log1p_impl< 
>::run() [with  = int]’:
mesh.ii:12:33:   required from here
mesh.ii:8:25: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at
cp/name-lookup.c:2729
8 | using std_fallback::log1p;
  | ^
0x876572 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9984
0x6b96d0 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3452
0x6b96d0 diagnose_name_conflict
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:2729
0xa9856e supplement_binding_1
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:2712
0xa9f566 supplement_binding
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:2750
0xa9f566 push_local_binding
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:4237
0xb3e19a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18138
0xb3e19a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18046
0xb3bf61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18073
0xb3bf61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18046
0xb3ba87 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18400
0xb3ba87 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18046
0xb27148 instantiate_body
/home/marxin/Programming/gcc/gcc/cp/pt.c:25748
0xb2832d instantiate_decl(tree_node*, bool, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:26037
0xb56bdb instantiate_pending_templates(int)
/home/marxin/Programming/gcc/gcc/cp/pt.c:26116
0xa16c2b c_parse_final_cleanups()
/home/marxin/Programming/gcc/gcc/cp/decl2.c:4965
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-6681-g9e1e6e631045c7eed2c72738b7084986d39ca09f
Author: Harald Anlauf 
Date:   Thu Jan 14 19:21:05 2021 +0100

PR fortran/98661 - valgrind issues with error recovery

During error recovery after an invalid derived type specification it was
possible to try to resolve an invalid array specification.  We now skip
this if the component has the ALLOCATABLE or POINTER attribute and the
shape is not deferred.

gcc/fortran/ChangeLog:

PR fortran/98661
* resolve.c (resolve_component): Derived type components with
ALLOCATABLE or POINTER attribute shall have a deferred shape.

gcc/testsuite/ChangeLog:

PR fortran/98661
* gfortran.dg/pr98661.f90: New test.

[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-6679-gd0d2becf2dfe8316c9014d962e7f3ec5c27e
Author: Harald Anlauf 
Date:   Thu Jan 14 19:13:16 2021 +0100

PR fortran/98661 - valgrind issues with error recovery

During error recovery after an invalid derived type specification it was
possible to try to resolve an invalid array specification.  We now skip
this if the component has the ALLOCATABLE or POINTER attribute and the
shape is not deferred.

gcc/fortran/ChangeLog:

PR fortran/98661
* resolve.c (resolve_component): Derived type components with
ALLOCATABLE or POINTER attribute shall have a deferred shape.

gcc/testsuite/ChangeLog:

PR fortran/98661
* gfortran.dg/pr98661.f90: New test.

[Bug libgomp/65099] nvptx offloading: hard-coded 64-bit assumptions

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Thomas Schwinge
:

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

commit r8-10728-gf9267925c648f2ccd9e4680b699e581003125bcf
Author: Thomas Schwinge 
Date:   Mon Nov 30 15:15:20 2020 +0100

[nvptx libgomp plugin] Build only in supported configurations

As recently again discussed in  "[nvptx] -m32
support", nvptx offloading other than for 64-bit host has never been
implemented, tested, supported.  So we simply should buildn't the nvptx
libgomp
plugin in this case.

This avoids build problems if, for example, in a (standard) bi-arch
x86_64-pc-linux-gnu '-m64'/'-m32' build, libcuda is available only in a
64-bit
variant but not in a 32-bit one, which, for example, is the case if you
build
GCC against the CUDA toolkit's 'stubs/libcuda.so' (see
).

This amends PR65099 commit a92defdab79a1268f4b9dcf42b937e4002a4cf15
(r225560)
"[nvptx offloading] Only 64-bit configurations are currently supported" to
match the way we're doing this for the HSA/GCN plugins.

libgomp/
PR libgomp/65099
* plugin/configfrag.ac (PLUGIN_NVPTX): Restrict to supported
configurations.
* configure: Regenerate.
* plugin/plugin-nvptx.c (nvptx_get_num_devices): Remove 64-bit
check.

(cherry picked from commit 6106dfb9f73a33c87108ad5b2dcd4842bdd7828e)

[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
F2018:

8.9  NAMELIST statement

(5) A namelist group object shall either be accessed by use or host association
or shall have its declared type, kind type parameters of the declared type, and
rank specified by previous specification statements or the procedure heading in
the same scoping unit or by the implicit typing rules in effect for the scoping
unit. If a namelist group object is typed by the implicit typing rules, its
appearance in any subsequent type declaration statement shall confirm the
implied
type and type parameters.

[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-6678-g9ac3e2feb3da89eda7a783d2c675ec897e81b338
Author: Ian Lance Taylor 
Date:   Wed Jan 13 11:54:15 2021 -0800

libgo: update hurd support

Patch from Svante Signell.

Fixes PR go/98496

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/283692

[Bug libgomp/65099] nvptx offloading: hard-coded 64-bit assumptions

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Thomas Schwinge
:

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

commit r9-9182-g0f1e1069a753e912b058f0d4bf599f0edde28408
Author: Thomas Schwinge 
Date:   Mon Nov 30 15:15:20 2020 +0100

[nvptx libgomp plugin] Build only in supported configurations

As recently again discussed in  "[nvptx] -m32
support", nvptx offloading other than for 64-bit host has never been
implemented, tested, supported.  So we simply should buildn't the nvptx
libgomp
plugin in this case.

This avoids build problems if, for example, in a (standard) bi-arch
x86_64-pc-linux-gnu '-m64'/'-m32' build, libcuda is available only in a
64-bit
variant but not in a 32-bit one, which, for example, is the case if you
build
GCC against the CUDA toolkit's 'stubs/libcuda.so' (see
).

This amends PR65099 commit a92defdab79a1268f4b9dcf42b937e4002a4cf15
(r225560)
"[nvptx offloading] Only 64-bit configurations are currently supported" to
match the way we're doing this for the HSA/GCN plugins.

libgomp/
PR libgomp/65099
* plugin/configfrag.ac (PLUGIN_NVPTX): Restrict to supported
configurations.
* configure: Regenerate.
* plugin/plugin-nvptx.c (nvptx_get_num_devices): Remove 64-bit
check.

(cherry picked from commit 6106dfb9f73a33c87108ad5b2dcd4842bdd7828e)

[Bug libgomp/65099] nvptx offloading: hard-coded 64-bit assumptions

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

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

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

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

commit r10-9270-g1e56a7c9a6631b217299b2ddcd5c4d497bb3445e
Author: Thomas Schwinge 
Date:   Mon Nov 30 15:15:20 2020 +0100

[nvptx libgomp plugin] Build only in supported configurations

As recently again discussed in  "[nvptx] -m32
support", nvptx offloading other than for 64-bit host has never been
implemented, tested, supported.  So we simply should buildn't the nvptx
libgomp
plugin in this case.

This avoids build problems if, for example, in a (standard) bi-arch
x86_64-pc-linux-gnu '-m64'/'-m32' build, libcuda is available only in a
64-bit
variant but not in a 32-bit one, which, for example, is the case if you
build
GCC against the CUDA toolkit's 'stubs/libcuda.so' (see
).

This amends PR65099 commit a92defdab79a1268f4b9dcf42b937e4002a4cf15
(r225560)
"[nvptx offloading] Only 64-bit configurations are currently supported" to
match the way we're doing this for the HSA/GCN plugins.

libgomp/
PR libgomp/65099
* plugin/configfrag.ac (PLUGIN_NVPTX): Restrict to supported
configurations.
* configure: Regenerate.
* plugin/plugin-nvptx.c (nvptx_get_num_devices): Remove 64-bit
check.

(cherry picked from commit 6106dfb9f73a33c87108ad5b2dcd4842bdd7828e)

[Bug libgomp/65099] nvptx offloading: hard-coded 64-bit assumptions

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:6106dfb9f73a33c87108ad5b2dcd4842bdd7828e

commit r11-6677-g6106dfb9f73a33c87108ad5b2dcd4842bdd7828e
Author: Thomas Schwinge 
Date:   Mon Nov 30 15:15:20 2020 +0100

[nvptx libgomp plugin] Build only in supported configurations

As recently again discussed in  "[nvptx] -m32
support", nvptx offloading other than for 64-bit host has never been
implemented, tested, supported.  So we simply should buildn't the nvptx
libgomp
plugin in this case.

This avoids build problems if, for example, in a (standard) bi-arch
x86_64-pc-linux-gnu '-m64'/'-m32' build, libcuda is available only in a
64-bit
variant but not in a 32-bit one, which, for example, is the case if you
build
GCC against the CUDA toolkit's 'stubs/libcuda.so' (see
).

This amends PR65099 commit a92defdab79a1268f4b9dcf42b937e4002a4cf15
(r225560)
"[nvptx offloading] Only 64-bit configurations are currently supported" to
match the way we're doing this for the HSA/GCN plugins.

libgomp/
PR libgomp/65099
* plugin/configfrag.ac (PLUGIN_NVPTX): Restrict to supported
configurations.
* configure: Regenerate.
* plugin/plugin-nvptx.c (nvptx_get_num_devices): Remove 64-bit
check.

[Bug objc++/98606] [10 regression] obj-c++.dg/template-4.mm fails erratically

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Resolved by backporting r11-4706:

$ make check-obj-c++ RUNTESTFLAGS=dg.exp=template-4.mm

=== obj-c++ Summary ===

# of expected passes2
/home/mpolacek/x/gcc10/gcc/xg++  version 10.2.1 20210114 (GCC)

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

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

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

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P1  |P4

--- Comment #3 from Segher Boessenkool  ---
It is an ICE-on-invalid, so it cannot be P1.

[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu

[ian at airs dot com via Gcc-bugs]

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

--- Comment #13 from Ian Lance Taylor  ---
In this case I've already sent the change out for review at
https://golang.org/cl/283692 and they should go in today (as before, this
process would go faster if you were able to send changes using Gerrit).

[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P4
Version|fortran-dev |11.0

[Bug fortran/98686] New: Namelist group objects shall be defined before appearing in namelist for -std=f2018

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

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

Bug ID: 98686
   Summary: Namelist group objects shall be defined before
appearing in namelist for -std=f2018
   Product: gcc
   Version: fortran-dev
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

The following code is silently accepted even with -std=f95 ... -std=2018:

  implicit none
  namelist /NML/ x, m, q
  real:: x, m
  integer :: q
  x = 1.0
  m = 2.0
  q = 3
  write(*, nml=NML)
end

It is properly rejected by NAG, and leads to fun with ifort, depending on
the -stand setting.

[Bug target/98671] gcc/config/i386/i386-options.c:787:redundantAssignment

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to Uroš Bizjak from comment #4)
> I'm not sure if solving this would bring us anything.

For clarity, at very most a 4% reduction in the size of the stack frame
for function ix86_parse_stringop_strategy_string.

[Bug target/98683] Non-canonical compare produced with the VAX backend

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
Maybe TARGET_CANONICALIZE_COMPARISON would help here? x86 had a similar issue
with ficom x87 insn where float RTX was always the first operand, but the
compare was with the float extend of the second one.

[Bug c++/86769] g++ destroys condition variable in for statement too early

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug tree-optimization/98685] [11 Regression] ICE verify_flow_info failed since r11-6649-g285fa338b06b804e

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
 Ever confirmed|0   |1
  Known to work||10.2.0
  Known to fail||11.0
   Last reconfirmed||2021-01-14

[Bug tree-optimization/98685] New: [11 Regression] ICE verify_flow_info failed since r11-6649-g285fa338b06b804e

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

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

Bug ID: 98685
   Summary: [11 Regression] ICE verify_flow_info failed since
r11-6649-g285fa338b06b804e
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  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: ---

Reduced from schily package:

$ cat lockit.i
char onelock_lock[16];
void write(void);

void lockit(int count) {
  for (; count;) {
int pid, i;
char *p;
for (i = 0, p = (char *) i < sizeof 0; i++)
  onelock_lock[i] = *p++;
write();
  }
}

$ gcc lockit.i -c -O3 -fdump-tree-slp=/dev/stdout

;; Function lockit (lockit, funcdef_no=0, decl_uid=1946, cgraph_uid=1,
symbol_order=1)

lockit.i: In function ‘lockit’:
lockit.i:4:6: error: control flow in the middle of basic block 2
4 | void lockit(int count) {
  |  ^~
lockit.i:4:6: error: control flow in the middle of basic block 2
lockit.i:4:6: error: true/false edge after a non-GIMPLE_COND in bb 2
lockit.i:4:6: error: true/false edge after a non-GIMPLE_COND in bb 2
during GIMPLE pass: slp
dump file: /dev/stdout

A SLP node is placed after a condition:

   [local count: 26541933]:
  if (count_8(D) != 0)
  _6 = VIEW_CONVERT_EXPR(pid_16(D));
  _4 = _6;

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[law at redhat dot com via Gcc-bugs]

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

--- Comment #38 from Jeffrey A. Law  ---
sparc might be able to trip this.

[Bug libstdc++/98471] [11 Regression] libstdc++ fails to build with clang on windows because of filesystem bug

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Should be fixed now.

[Bug libstdc++/98471] [11 Regression] libstdc++ fails to build with clang on windows because of filesystem bug

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

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

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

https://gcc.gnu.org/g:57a4f5e4eacfbbbd0ca5f1e3f946c27d63e2b533

commit r11-6676-g57a4f5e4eacfbbbd0ca5f1e3f946c27d63e2b533
Author: Jonathan Wakely 
Date:   Thu Jan 14 14:26:19 2021 +

libstdc++: Define function to throw filesystem_error [PR 98471]

Fix ordering problem on Windows targets where filesystem_error was used
before being defined.

libstdc++-v3/ChangeLog:

PR libstdc++/98471
* include/bits/fs_path.h (__throw_conversion_error): New
function to throw or abort on character conversion errors.
(__wstr_from_utf8): Move definition after filesystem_error has
been defined. Use __throw_conversion_error.
(path::_S_convert<_EcharT>): Use __throw_conversion_error.
(path::_S_str_convert<_CharT, _Traits, _Allocator>): Likewise.
(path::u8string): Likewise.

[Bug libstdc++/98471] [11 Regression] libstdc++ fails to build with clang on windows because of filesystem bug

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||11.0
  Known to work||10.2.1
Summary|libstdc++ fails to build|[11 Regression] libstdc++
   |with clang on windows   |fails to build with clang
   |because of filesystem bug   |on windows because of
   ||filesystem bug
   Target Milestone|--- |11.0

[Bug sanitizer/98669] SIGSEGV on pc=0 in crypt() with -fsanitize=address

[marko.makela at mariadb dot com via Gcc-bugs]

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

--- Comment #13 from Marko Mäkelä  ---
Thank you. I have reported this upstream:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980110

[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives

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

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

--- Comment #7 from Marek Polacek  ---
Or, disable it when we call build_base_path with nonnull == 1?

[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives

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

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

--- Comment #6 from Marek Polacek  ---
(In reply to Martin Sebor from comment #1)
> Confirmed.  It must be an instance we missed in the fix for pr96003 where
> the C++ front end adds a COND_EXPR to static_cast.
> 
> The larger context in the translation unit is:
> 
>   if (tp && tp->handle())
> transientXcbParent = static_cast *>(tp->handle())->winId();
> 
> The caller guards against tp->handle() being null but the front end doesn't
> consider that and adds another guard which then triggers the warning that
> also runs in the front end.  The pr96003 fix works around the same problem
> by setting the TREE_NO_WARNING bit so the same hack is needed wherever else
> the front end builds a static_cast.

This won't work here, because we're not creating the null test; build_base_path
is called from build_over_call:

 8902   tree converted_arg = build_base_path (PLUS_EXPR, arg,
 8903 base_binfo, 1, complain);

where the 1 means nonnull is true.

The warning probably has to be moved out of the FE.  Null 'this' has to be
detected in constexpr context, that is bug 97230.

[Bug tree-optimization/97104] [11 Regression] aarch64, SVE: ICE in vect_get_loop_mask since r11-3070-g783dc66f9cc

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

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

--- Comment #3 from Alex Coplan  ---
Seems to have gone latent for the previous testcases, but still ICEs for:

extern int a[];
extern long b[];
char c;
long d;
void e(_Bool f[], long g[]) {
  for (int h; h; h += 1) {
a[h] = c < f[0];
b[h] = d ? d : g[h];
  }
}

with -O1 -ftree-vectorize -march=armv8.2-a+sve.

[Bug ada/98595] [RISC-V, Ada] a-nallfl.ads:48:13: warning: profile of "Sin" doesn't match the builtin it binds

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

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

--- Comment #2 from Sebastian Huber  ---
Fixed by commit above.

[Bug ada/98595] [RISC-V, Ada] a-nallfl.ads:48:13: warning: profile of "Sin" doesn't match the builtin it binds

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Sebastian Huber :

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

commit r11-6675-gaa3d33dccb57621b2ab2029dce79208c0c9392c1
Author: Sebastian Huber 
Date:   Thu Jan 14 16:05:14 2021 +0100

RTEMS: Fix Ada build for riscv

gcc/ada/

PR ada/98595
* Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use
wraplf version of Aux_Long_Long_Float.

[Bug middle-end/95021] [10 Regression] Bogus -Wclobbered warning

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

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

Bug 98676 Summary: [11 Regression] gcc.target/i386/pr95021-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98676

   What|Removed |Added

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

[Bug testsuite/98676] [11 Regression] gcc.target/i386/pr95021-1.c etc. FAIL

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed.

[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486

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

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

--- Comment #10 from H.J. Lu  ---
(In reply to Matthew Whitehead from comment #1)
> Here is the full set of compiler flags used.
> 
> readelf --string-dump='.GCC.command.line' /usr/lib/debug/$( which eix
> ).debug  
> 
> String dump of section '.GCC.command.line':
>   [ 0]  -I .
>   [ 5]  -I ..
>   [ b]  -D_GNU_SOURCE
>   [19]  -D HAVE_CONFIG_H
>   [2a]  -D SYSCONFDIR="/etc"
>   [3f]  -D LOCALEDIR="/usr/share/locale"
>   [60]  -D _FORTIFY_SOURCE=2
>   [75]  various/drop_permissions.cc
>   [91]  -march=i486
>   [9d]  -auxbase-strip various/drop_permissions.o
>   [c7]  -g
>   [ca]  -ggdb
>   [d0]  -O2
>   [d4]  -fdata-sections
>   [e4]  -ffunction-sections
>   [f8]  -fcf-protection=full
>

Please remove -fcf-protection=full.

[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486

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

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

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

https://gcc.gnu.org/g:77d372abec0fbf2cfe922e3140ee3410248f979e

commit r11-6672-g77d372abec0fbf2cfe922e3140ee3410248f979e
Author: H.J. Lu 
Date:   Thu Jan 14 05:56:46 2021 -0800

x86: Error on -fcf-protection with incompatible target

-fcf-protection with CF_BRANCH inserts ENDBR32 at function entries.
ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOV
processors.  Issue an error for -fcf-protection with CF_BRANCH when
compiling for 32-bit non-TARGET_CMOV targets.

gcc/

PR target/98667
* config/i386/i386-options.c (ix86_option_override_internal):
Issue an error for -fcf-protection with CF_BRANCH when compiling
for 32-bit non-TARGET_CMOV targets.

gcc/testsuite/

PR target/98667
* gcc.target/i386/pr98667-1.c: New file.
* gcc.target/i386/pr98667-2.c: Likewise.
* gcc.target/i386/pr98667-3.c: Likewise.

[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu

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

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

--- Comment #12 from Marius Hillenbrand  ---
found a miscompilation in gnat1 (that I can trigger to cause a segfault),
a loop in sem_res.adb:2405 in procedure Resolve (N : Node_Id; Typ : Entity_Id)

while Present (It.Typ) loop
  Get_Next_Interp (I, It); // <- from sem_type.adb
end loop;

is optimized into an endless loop, apparently by wrongly concluding that
Get_Next_Interp would not change It (which it does).

  while Present (It.Typ) loop 
 18558fe:  e3 20 f1 14 00 12  lt %r2,276(%r15)
 1855904:  a7 84 0c 23je 185714a 
 1855908:  b3 cd 00 28lgdr   %r2,%f8

looping back here:
Get_Next_Interp (I, It);
 185590c:  b9 04 00 3algr%r3,%r10
 1855910:  c0 e5 00 00 cb 70  brasl  %r14,186eff0

 1855916:  b9 14 00 22lgfr   %r2,%r2
 185591a:  a7 f4 ff f9j  185590c 

when suppressing ipa-modref info for Get_Next_Interp, we get a sane check and
conditional branch instead.

[Bug target/98671] gcc/config/i386/i386-options.c:787:redundantAssignment

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
Fixed all but:

> trunk.git/gcc/config/i386/i386-options.c:1520:11: warning:inconclusive: Width 
> 10
> given in format string (no. 3) is smaller than destination buffer 'align[16]'.
> [invalidScanfFormatWidth_smaller]

I'm not sure if solving this would bring us anything.

[Bug target/98648] Failure to optimize out no-op vector operation using andnot

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Gabriel Ravier  ---
This code :

typedef int64_t v2di __attribute__((vector_size(16)));

v2di f(__m128 val) 
{
return (~(v2di)_mm_set_ps1(0.0f) & (v2di)val);
}

is optimized better (and is equivalent, if I understand the semantics of andnps
right). Maybe the builtin for andnot should be thrown out as soon as possible
(i.e. transformed into ~a & b`) ? From what I can see, `~a & b` for vectors in
general is optimized to an andnot operation too.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 98674 Summary: [10 Regression] vectorizer failed for compilation time alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98674

   What|Removed |Added

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

[Bug tree-optimization/98674] [10 Regression] vectorizer failed for compilation time alias

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 98674 Summary: [10 Regression] vectorizer failed for compilation time alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98674

   What|Removed |Added

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

[Bug tree-optimization/98674] [10 Regression] vectorizer failed for compilation time alias

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[10/11 Regression]  |[10 Regression] vectorizer
   |vectorizer failed for   |failed for compilation time
   |compilation time alias  |alias
 Resolution|--- |FIXED
  Known to fail||10.2.1
 Status|ASSIGNED|RESOLVED
  Known to work||11.0

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

[Bug tree-optimization/98674] [10/11 Regression] vectorizer failed for compilation time alias

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

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

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

https://gcc.gnu.org/g:2182274f510c180ea92a4f826a0f6cf5f1f55b66

commit r11-6670-g2182274f510c180ea92a4f826a0f6cf5f1f55b66
Author: Richard Biener 
Date:   Thu Jan 14 14:08:41 2021 +0100

tree-optimization/98674 - improve dependence analysis

This improves dependence analysis on refs that access the same
array but with different typed but same sized accesses.  That's
obviously safe for the case of types that cannot have any
access function based off them.  For the testcase this is
signed short vs. unsigned short.

2021-01-14  Richard Biener  

PR tree-optimization/98674
* tree-data-ref.c (base_supports_access_fn_components_p): New.
(initialize_data_dependence_relation): For two bases without
possible access fns resort to type size equality when determining
shape compatibility.

* gcc.dg/vect/pr98674.c: New testcase.

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Sebor  ---
The latest trunk outputs the same warning with a better note (the offset is
correct).  As discussed in comment #7 the warning for the small test case is
correct: the loop overflows the small buffer.  It iterates at least three
times, writing two bytes into the four byte destination in each iteration, for
a total of six bytes.  I don't see a bug here so I'm resolving it as invalid. 
If the test case below isn't representative of the fortran code please submit
one that is.

$ cat pr95276.c && gcc -O2 -S -Wall pr95276.c
char a[4];

void f (char *s, int n)
{
  if (n <= 2)
return;

  char *d = a;

  for (int i = 0; i < n; i++)
{
  extern volatile unsigned char h, l;

  *d++ = s[h];
  *d++ = s[l];
}

  *d = '\0';
}
pr95276.c: In function ‘f’:
pr95276.c:18:6: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   18 |   *d = '\0';
  |   ~~~^~
pr95276.c:1:6: note: at offset 6 into destination object ‘a’ of size 4
1 | char a[4];
  |  ^

[Bug c/98684] -Wswitch interaction with "case X ... Y" -- warns for X and Y not being in the enum, but not X+1, X+2, ... Y-1

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |10.2.1
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-01-14
   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug middle-end/95021] [10 Regression] Bogus -Wclobbered warning

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

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

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

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

commit r11-6669-ga512079ef40e442c1269ea1cc55f18790ba68449
Author: H.J. Lu 
Date:   Thu Jan 14 06:56:17 2021 -0800

i386: Update PR target/95021 tests

Also pass -mpreferred-stack-boundary=4 -mno-stackrealign to avoid
disabling STV by:

  /* Disable STV if -mpreferred-stack-boundary={2,3} or
 -mincoming-stack-boundary={2,3} or -mstackrealign - the needed
 stack realignment will be extra cost the pass doesn't take into
 account and the pass can't realign the stack.  */
  if (ix86_preferred_stack_boundary < 128
  || ix86_incoming_stack_boundary < 128
  || opts->x_ix86_force_align_arg_pointer)
opts->x_target_flags &= ~MASK_STV;

PR target/98676
* gcc.target/i386/pr95021-1.c: Add -mpreferred-stack-boundary=4
-mno-stackrealign.
* gcc.target/i386/pr95021-3.c: Likewise.

[Bug testsuite/98676] [11 Regression] gcc.target/i386/pr95021-1.c etc. FAIL

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

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

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

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

commit r11-6669-ga512079ef40e442c1269ea1cc55f18790ba68449
Author: H.J. Lu 
Date:   Thu Jan 14 06:56:17 2021 -0800

i386: Update PR target/95021 tests

Also pass -mpreferred-stack-boundary=4 -mno-stackrealign to avoid
disabling STV by:

  /* Disable STV if -mpreferred-stack-boundary={2,3} or
 -mincoming-stack-boundary={2,3} or -mstackrealign - the needed
 stack realignment will be extra cost the pass doesn't take into
 account and the pass can't realign the stack.  */
  if (ix86_preferred_stack_boundary < 128
  || ix86_incoming_stack_boundary < 128
  || opts->x_ix86_force_align_arg_pointer)
opts->x_target_flags &= ~MASK_STV;

PR target/98676
* gcc.target/i386/pr95021-1.c: Add -mpreferred-stack-boundary=4
-mno-stackrealign.
* gcc.target/i386/pr95021-3.c: Likewise.

[Bug analyzer/98679] Four functions could be marked "const".

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from David Malcolm  ---
Thanks.  Am testing a fix.

[Bug testsuite/98676] [11 Regression] gcc.target/i386/pr95021-1.c etc. FAIL

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

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from H.J. Lu  ---
> Created attachment 49966
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49966=edit
> A patch
>
> STV is disabled by
[...]
> Please try this.

Successfully tested on i386-pc-solaris2.11 (both 32 and 64-bit).
Thanks.

[Bug c/98684] New: -Wswitch interaction with "case X ... Y" -- warns for X and Y not being in the enum, but not X+1, X+2, ... Y-1

[pmaydell at chiark dot greenend.org.uk via Gcc-bugs]

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

Bug ID: 98684
   Summary: -Wswitch interaction with "case X ... Y" -- warns for
X and Y not being in the enum, but not X+1, X+2, ...
Y-1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pmaydell at chiark dot greenend.org.uk
  Target Milestone: ---

The gcc -Wswitch warning is documented as producing warnings for "case labels
outside the enumeration range" (among other things). The implementation of this
seems to interact oddly with the "case X ... Y" syntax for specifying that a
case covers a range of values: gcc warns if X or Y is not in the enumeration,
but doesn't warn if the other values covered by this case label (X+1, X+2, ...
Y-1) are not in the enum.

Test case:

enum myenum {
  foo = -1,
  r0_low = 0,
  r0_high = 5,
};

int z(enum myenum e) {
switch (e) {
case foo:
return 42;
case r0_low ... r0_high:
return 0;
case 8 ... 10:
return 5;
}
/* notreached */
return 0;
}

The generated warnings are:
: In function 'z':
:13:9: warning: case value '8' not in enumerated type 'enum myenum'
[-Wswitch]
   13 | case 8 ... 10:
  | ^~~~
:13:9: warning: case value '10' not in enumerated type 'enum myenum'
[-Wswitch]

So the compiler warns about only 8 and 10, but the switch cases cover also 1,
2, 3, 4 and 9 which are not in the enum.

Tested with compiler-explorer, which at the time was:
GNU C17 (Compiler-Explorer-Build) version 11.0.0 20210106 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

https://godbolt.org/z/x88KzE

(Side note: it would be useful to have a syntax in the enum definition to say
"all values X ... Y are valid for this enum type", so as to be able to tell the
compiler that without having to write them all out.)

[Bug testsuite/98676] [11 Regression] gcc.target/i386/pr95021-1.c etc. FAIL

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

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

--- Comment #1 from H.J. Lu  ---
Created attachment 49966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49966=edit
A patch

STV is disabled by

  /* Disable STV if -mpreferred-stack-boundary={2,3} or
 -mincoming-stack-boundary={2,3} or -mstackrealign - the needed
 stack realignment will be extra cost the pass doesn't take into
 account and the pass can't realign the stack.  */
  if (ix86_preferred_stack_boundary < 128
  || ix86_incoming_stack_boundary < 128
  || opts->x_ix86_force_align_arg_pointer)
opts->x_target_flags &= ~MASK_STV;

Please try this.

[Bug target/98683] New: Non-canonical compare produced with the VAX backend

[macro--- via Gcc-bugs]

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

Bug ID: 98683
   Summary: Non-canonical compare produced with the VAX backend
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ma...@linux-mips.org
CC: ma...@linux-mips.org
  Target Milestone: ---
Target: vax-*-netbsdelf

Due to how operands are presented to the `cbranch*' patterns a
non-canonical compare operation might be produced with reload that has
an immediate in its first input operand (and a non-immediate second input
operand, although forms with two immediate inputs have been also
observed).

This can be reproduced with the existing 2422-1.c test case and the
`-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions' options, a set from the usual ones used with
regression testing:

(jump_insn 549 550 556 99 (set (pc)
(if_then_else (ge (const_int 0 [0])
(reg:SI 10 %r10 [orig:188 _138 ] [188]))
(label_ref:SI 707)
(pc))) ".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27
521 {*cbranchsi4_ccn}
 (int_list:REG_BR_PROB 118111604 (nil))
 -> 707)

which gets split to:

(insn 1959 550 1960 99 (set (reg:CCN 16 %psl)
(compare:CCN (const_int 0 [0])
(reg:SI 10 %r10 [orig:188 _138 ] [188])))
".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27 6 {*cmpsi_ccn}
 (nil))
(jump_insn 1960 1959 556 99 (set (pc)
(if_then_else (ge (reg:CCN 16 %psl)
(const_int 0 [0]))
(label_ref 707)
(pc))) ".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27
535 {*branch_ccn}
 (int_list:REG_BR_PROB 118111604 (nil))
 -> 707)

and ultimately leads to:

#(insn 1959 550 1960 (set (reg:CCN 16 %psl)
#(compare:CCN (const_int 0 [0])
#(reg:SI 10 %r10 [orig:188 _138 ] [188])))
".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27 6 {*cmpsi_ccn}
# (nil))
cmpl $0,%r10# 1959  [c=6]  *cmpsi_ccn/1
#(jump_insn 1960 1959 556 (set (pc)
#(if_then_else (ge (reg:CCN 16 %psl)
#(const_int 0 [0]))
#(label_ref 707)
#(pc)))
".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27 535 {*branch_ccn}
# (expr_list:REG_DEAD (reg:CCN 16 %psl)
#(int_list:REG_BR_PROB 118111604 (nil)))
# -> 707)
jgeq .L73   # 1960  [c=26]  *branch_ccn

As observed here this is handled by the backend just fine, however causes
the less optimal CMPL instruction to be produced rather than TSTL that
has an implicit immediate zero second operand, which could be used if the
inputs were swapped.  This applies to both integer and FP operations.

Currently canonicalization requires that an immediate input operand to
to the compare operation has to come as the second one, however there is
no such requirement for the `cbranch*' patterns, so the fix would have to
be made in the backend, in the relevant splitters, presumably by swapping
the operands and using the reverse branch if an immediate is presented
as the first input operand.

Requiring the first input operand to `cbranch*' to be non-immediate by
means of a predicate results in yet worse code being produced as any
immediate used is then moved to a register by reload, so this would best
be avoided.