[Bug target/97326] [11 Regression] s390: ICE in do_store_flag after 10843f830350

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

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #4 from Andreas Krebbel  ---
Fixed

[Bug target/97326] [11 Regression] s390: ICE in do_store_flag after 10843f830350

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

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #5 from Andreas Krebbel  ---
closing

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

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

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

--- Comment #9 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #8)
> Comment on attachment 49548 [details]
> bugtest.f -- program evincing bug
> 
> So, commit the test case to guard against regressions
> (since it is not immediately obvious if this is already
> covered).
> 
> I'll do so in a short while.

Or as soon as bootstrap works again.

[Bug bootstrap/97806] [11 regression] bootstrap ICE starting with r11-4921

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

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

--- Comment #3 from Richard Biener  ---
int b;
long c;
int g();
void h(long *);
void i(long *);
void d() {
  int e, f = b - e;
  if (g())
h( + f);
  else
i( + f);
  __builtin_memset(0, 0, f * 8);
}

heh, quite simple - so much for test coverage :/

[Bug bootstrap/97806] [11 regression] bootstrap ICE starting with r11-4921

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #2 from Richard Biener  ---
OK, confirmed and reducing a testcase.

[Bug target/97326] [11 Regression] s390: ICE in do_store_flag after 10843f830350

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Andreas Krebbel :

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

commit r11-4935-g5d9ade39b8720b61cf63a8be181fb3b487f6ac5b
Author: Andreas Krebbel 
Date:   Thu Nov 12 08:20:43 2020 +0100

IBM Z: Fix PR97326: Enable fp compares in vec_cmp

gcc/ChangeLog:

PR target/97326
* config/s390/vector.md: Support vector floating point modes in
vec_cmp.

[Bug target/97770] [ICELAKE]Missing vectorization for vpopcnt

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #10 from Richard Biener  ---
Hmm, but

DEF_INTERNAL_INT_FN (POPCOUNT, ECF_CONST | ECF_NOTHROW, popcount, unary)

so there's clearly a mismatch between either the vectorizers interpretation
or the optab.  But as far as I can see this is not a direct internal fn so
vectorizable_internal_function shouldn't apply and I do not see the x86
backend handle POPCOUNT in the vectorizable function target hook.

So w/o a compiler capable I can't trace how the vectorizer vectorizes this
and thus I have no idea where it goes wrong ...

[Bug bootstrap/97806] [11 regression] bootstrap ICE starting with r11-4921

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |11.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2020-11-12
   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
Mine - trying to reproduce on x86_64-linux with in-tree mpfr.

[Bug c++/97804] [9/10/11 Regression] ICE in output_constructor_register_field varasm.c:5407 since r9-5710

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords||ice-on-valid-code

[Bug testsuite/97803] c-c++-common/asan/pointer-compare-1.c assumes variable placement

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

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

--- Comment #1 from Richard Biener  ---
Does it work if you add -fno-toplevel-reorder?  SHF_GNU_RETAIN should preserve
the order of vars even if 'used' then.

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-12
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
As Andrew says the reason is that C library builtins are marked nothrow which
currently implies "notrap" in the context of -fnon-call-exceptions.  There's
no separate attribute for not trapping (or IPA discovery of this) but a
simple enough workaround only pessimizing -fnon-call-exceptions would be sth
like the following

diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index c3314bbd78c..bcf6a7fb348 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -2902,6 +2902,12 @@ stmt_could_throw_p (function *fun, gimple *stmt)
   return true;

 case GIMPLE_CALL:
+  /* ???  We need to check whether the callee can throw non-call
+exceptions or conservatively assume so if we cannot tell but
+non-call exceptions are enabled.  */
+  if (fun && fun->can_throw_non_call_exceptions
+ || flag_non_call_exceptions)
+   return true;
   return !gimple_call_nothrow_p (as_a  (stmt));

 case GIMPLE_COND:

as the comments says the check isn't correct but it might work for simple
non-LTO cases.  Anybody willing to try?

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

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

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #8 from Thomas Koenig  ---
Comment on attachment 49548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49548
bugtest.f -- program evincing bug

So, commit the test case to guard against regressions
(since it is not immediately obvious if this is already
covered).

I'll do so in a short while.

[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:87b7d45e358e4df93b6a93b2e7a55b123ea76f5d

commit r11-4933-g87b7d45e358e4df93b6a93b2e7a55b123ea76f5d
Author: Jason Merrill 
Date:   Tue Nov 10 18:02:04 2020 -0500

dwarf2: Set DW_AT_declaration for undefined fns [PR97060]

If DECL_INITIAL isn't set, we can't emit anything about the body of the
function, so add the declaration attribute.

gcc/ChangeLog:

PR debug/97060
* dwarf2out.c (gen_subprogram_die): It's a declaration
if DECL_INITIAL isn't set.

gcc/testsuite/ChangeLog:

PR debug/97060
* gcc.dg/debug/dwarf2/pr97060.c: New test.

[Bug target/97770] [ICELAKE]Missing vectorization for vpopcnt

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---

> I guess that the vectorized popcount IFN is defined to be VnDI -> VnDI
> but we want to have VnSImode results.  This means the instruction is
> wrongly modeled in vectorized form?
> 

Yes, because we have __builtin_popcount{l,ll} defined as {BT_FN_INT_ULONG,
BT_FN_INT_ULONGLONG}

but for vectorized form, gcc require mode of src and dest to be the same. 

popcountm2:

Store into operand 0 the number of 1-bits in operand 1.
m is either a scalar or vector integer mode. When it is a scalar, operand 1 has
mode m but operand 0 can have whatever scalar integer mode is suitable for the
target. The compiler will insert conversion instructions as necessary
(typically to convert the result to the same width as int). When m is a vector,
both operands must have mode m. This pattern is not allowed to FAIL.

[Bug bootstrap/97806] New: [11 regression] bootstrap ICE starting with r11-4921

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

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

Bug ID: 97806
   Summary: [11 regression] bootstrap ICE starting with r11-4921
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:86cca5cc14602814b98e55aae313fbe237af1b04, r11-4921 

commit 86cca5cc14602814b98e55aae313fbe237af1b04
Author: Richard Biener 
Date:   Wed Nov 11 16:09:17 2020 +0100



/bin/sh ../libtool  --tag=CC   --mode=compile
/home/seurer/gcc/git/build/gcc-test/./prev-gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./prev-gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include  
-fchecking=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1
-DHAVE_STRUCT_LCONV_DECIMAL_POINT=1 -DHAVE_STRUCT_LCONV_THOUSANDS_SEP=1
-DHAVE_ALLOCA_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1
-DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1
-DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1
-DHAVE_SIGNEDZ=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1
-DHAVE_NEARBYINT=1 -DMPFR_USE_THREAD_SAFE=1 -DMPFR_USE_C11_THREAD_SAFE=1
-DHAVE_CLOCK_GETTIME=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1
-DHAVE___GMPN_ROOTREM=1 -DHAVE___GMPN_SBPI1_DIVAPPR_Q=1 -I.
-I/home/seurer/gcc/git/gcc-test/mpfr/src  
-I/home/seurer/gcc/git/build/gcc-test/gmp -DNO_ASM -g -O2 -fchecking=1 -MT
sub1sp.lo -MD -MP -MF .deps/sub1sp.Tpo -c -o sub1sp.lo
/home/seurer/gcc/git/gcc-test/mpfr/src/sub1sp.c
libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./prev-gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./prev-gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-fchecking=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1
-DHAVE_STRUCT_LCONV_DECIMAL_POINT=1 -DHAVE_STRUCT_LCONV_THOUSANDS_SEP=1
-DHAVE_ALLOCA_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1
-DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1
-DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1
-DHAVE_SIGNEDZ=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1
-DHAVE_NEARBYINT=1 -DMPFR_USE_THREAD_SAFE=1 -DMPFR_USE_C11_THREAD_SAFE=1
-DHAVE_CLOCK_GETTIME=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1
-DHAVE___GMPN_ROOTREM=1 -DHAVE___GMPN_SBPI1_DIVAPPR_Q=1 -I.
-I/home/seurer/gcc/git/gcc-test/mpfr/src
-I/home/seurer/gcc/git/build/gcc-test/gmp -DNO_ASM -g -O2 -fchecking=1 -MT
sub1sp.lo -MD -MP -MF .deps/sub1sp.Tpo -c
/home/seurer/gcc/git/gcc-test/mpfr/src/sub1sp.c -o sub1sp.o
during GIMPLE pass: pre
/home/seurer/gcc/git/gcc-test/mpfr/src/sub1sp.c: In function 'mpfr_sub1sp':
/home/seurer/gcc/git/gcc-test/mpfr/src/sub1sp.c:135:1: internal compiler error:
in clean, at tree-ssa-pre.c:2053
  135 | mpfr_sub1sp (mpfr_ptr a, mpfr_srcptr b, mpfr_srcptr c, mpfr_rnd_t
rnd_mode)
  | ^~~
0x3fffb7c87c6b generic_start_main
../csu/libc-start.c:266

[Bug tree-optimization/97424] Warn on invalid shift amount after inlining

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

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

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

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

commit r11-4930-g5e00ad3ffbfb4df7242c313a0d836f5b538eb2fb
Author: David Malcolm 
Date:   Wed Nov 11 21:16:45 2020 -0500

analyzer: warn on invalid shift counts [PR97424]

This patch implements -Wanalyzer-shift-count-negative
and -Wanalyzer-shift-count-overflow, analogous to the C/C++
warnings -Wshift-count-negative and -Wshift-count-overflow, but
implemented via interprocedural path analysis rather than via parsing
in a front end, and thus capable of detecting interprocedural cases that
the
warnings implemented in the front ends can miss.

gcc/analyzer/ChangeLog:
PR tree-optimization/97424
* analyzer.opt (Wanalyzer-shift-count-negative): New.
(Wanalyzer-shift-count-overflow): New.
* region-model.cc (class shift_count_negative_diagnostic): New.
(class shift_count_overflow_diagnostic): New.
(region_model::get_gassign_result): Complain about shift counts
that
are negative or are >= the operand's type's width.

gcc/ChangeLog:
PR tree-optimization/97424
* doc/invoke.texi (Static Analyzer Options): Add
-Wno-analyzer-shift-count-negative and
-Wno-analyzer-shift-count-overflow.
(-Wno-analyzer-shift-count-negative): New.
(-Wno-analyzer-shift-count-overflow): New.

gcc/testsuite/ChangeLog:
PR tree-optimization/97424
* gcc.dg/analyzer/invalid-shift-1.c: New test.

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[admin at levyhsu dot com via Gcc-bugs]

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

--- Comment #34 from Levy  ---
(In reply to Jim Wilson from comment #33)
> I did say that I'm willing to fix code style issues.  All major software
> projects I have worked with have coding style conventions.  It makes it
> easier to maintain a large software base when everything is using the same
> coding style.  We do have info to help you follow the GNU coding style.  See
> https://gcc.gnu.org/wiki/FormattingCodeForGCC
> which has emacs and vim settings to get the right code style.

No problem and thank you, Jim, I'll try to catch up the coding style.
what about the combine issue and shorten-memrefs? 
Shall we fix it here or someplace else?

[Bug middle-end/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #12 from Martin Sebor  ---
With the patch under test GCC issues the following for the test case in comment
#0 (the test case in comment #7 has been diagnosed on trunk since r11-2370):

$ gcc -O2 -S -Wall pr93848.c
pr93848.c: In function ‘foo’:
pr93848.c:8:3: warning: ‘i’ is used uninitialized [-Wuninitialized]
8 |   foo_aux (p[1]);
  |   ^~
pr93848.c:6:7: note: ‘i’ declared here
6 |   int i;
  |   ^
pr93848.c:8:3: warning: array subscript 1 is outside array bounds of ‘int[1]’
[-Warray-bounds]
8 |   foo_aux (p[1]);
  |   ^~
pr93848.c:6:7: note: while referencing ‘i’
6 |   int i;
  |   ^
pr93848.c: In function ‘bar’:
pr93848.c:17:3: warning: subscript 4 in argument 1 to ‘bar_aux’ is just past
the end of ‘int[4]’ [-Warray-bounds]
   17 |   bar_aux (p[1]);
  |   ^~
pr93848.c:15:7: note: at offset 16 into source object ‘i’ of size 16
   15 |   int i[4];
  |   ^

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

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

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

--- Comment #8 from Jonathan Wakely  ---
My attempt to build msp430 fails with:

In file included from
/home/jwakely/gcc/msp430-elf/msp430-elf/include/stdint.h:13,
 from /home/jwakely/src/gcc/build-16bit/gcc/include/stdint.h:9,
 from
/home/jwakely/src/gcc/build-16bit/msp430-elf/large/libstdc++-v3/include/bits/align.h:36,
 from
/home/jwakely/src/gcc/build-16bit/msp430-elf/large/libstdc++-v3/include/memory:72,
 from
/home/jwakely/src/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:82:
/home/jwakely/gcc/msp430-elf/msp430-elf/include/sys/_intsup.h:68:2: error:
#error "Unable to determine type definition of intptr_t"
   68 | #error "Unable to determine type definition of intptr_t"
  |  ^


Is that related?

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|mpolacek at gcc dot gnu.org|redi at gcc dot gnu.org
  Component|c++ |libstdc++

--- Comment #7 from Jonathan Wakely  ---
Reassigning to the library as the compiler is right to reject this code.

I think we can specialize std::__numeric_traits and std::numeric_limits by
using the __GLIBCXX_BITSIZE_INT_N_0 for the width.

[Bug ada/97805] New: adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

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

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

Bug ID: 97805
   Summary: adaint.c:1488:12: note: 'LLONG_MIN' is defined in
header ''; did you forget to '#include
'?
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

g++ -std=c++11  -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions
-
fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-W
cast-qual -Wno-format -mdisable-indexing -Wmissing-format-attribute
-Woverloaded
-virtual -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common
  -DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada
-I../../gcc/gcc/
../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gmp/include 
-I../..
/gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-
I../../gcc/gcc/../libbacktrace   -o ada/argv.o -MT ada/argv.o -MMD -MP -MF
ada/.
deps/argv.TPo ../../gcc/gcc/ada/argv.c
../../gcc/gcc/ada/adaint.c: In function 'long long int
__gnat_file_time(char*)':
../../gcc/gcc/ada/adaint.c:1488:12: error: 'LLONG_MIN' was not declared in this
scope
 return LLONG_MIN;
^
../../gcc/gcc/ada/adaint.c:1488:12: note: 'LLONG_MIN' is defined in header
''; did you forget to '#include '?
../../gcc/gcc/ada/adaint.c:239:1:
+#include 

[Bug c++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

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

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

--- Comment #6 from Jonathan Wakely  ---
I think the reduction is not a fair representation of the original code.
Obviously shifting by -1 is not OK, but the code doesn't do that ... at least
not for most targets.

The problem is specific to msp430 because of it's 20-bit type:


  template
struct __numeric_traits_integer
{
  static const int is_signed = ((_Value)-1 < 0);
  static const int digits = sizeof(_Value) * __CHAR_BIT__ - is_signed;

  static const _Value __max = (is_signed ? (_Value)1 << (digits - 1)) -
1) << 1) + 1) : ~(_Value)0);
};

static_assert( sizeof(__int20) == 4 ); // uhoh
static_assert( __numeric_traits_integer<__int20>::digits == 31 ); // uhoh

static_assert( __numeric_traits_integer<__int20>::__max < __INT_MAX__ );


The expression initializing __max works fine on 32-bit and 64-bit targets, but
for __int20 it's wrong. sizeof(__int20) is 4 (as shown by the static assert
that passes) and so we determine digits as 31, but it should be 19 for this
type.

The code assumes that all bits in the object representation are part of the
value representation, which is wrong for __int20.

The code above produced this warning with GCC 10.0 (the last time I built
msp430):

num.C: In instantiation of ‘const __int20
__numeric_traits_integer<__int20>::__max’:
num.C:13:51:   required from here
num.C:7:62: warning: left shift count >= width of type [-Wshift-count-overflow]
7 |   static const _Value __max = (is_signed ? (_Value)1 << (digits
- 1)) - 1) << 1) + 1) : ~(_Value)0);
  |  
~~~^~~~
num.C:7:62: error: right operand of shift expression ‘(1 << 30)’ is greater
than or equal to the precision 20 of the left operand [-fpermissive]
num.C:13:57: error: non-constant condition for static assertion
   13 | static_assert( __numeric_traits_integer<__int20>::__max < __INT_MAX__
);
  | ^


Presumably the shift is now an error rather than a warning, because it occurs
in a constant expression.

Maybe the right solution is for the library to specialize the trait for
__int20.

[Bug c++/97804] [9/10/11 Regression] ICE in output_constructor_register_field varasm.c:5407 since r9-5710

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|middle-end  |c++
   Target Milestone|--- |9.4
   Last reconfirmed||2020-11-11
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|ICE in  |[9/10/11 Regression] ICE in
   |output_constructor_register |output_constructor_register
   |_field  varasm.c:5407   |_field  varasm.c:5407 since
   ||r9-5710
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jakub Jelinek  ---
Started with r9-5710-g7e574f68fa82e7c5f879fd468291ec8b5ebecc83
Reduced testcase (-std=c++17):
template  struct b {
  constexpr b() : c() {}
  [[no_unique_address]] a c;
};
template  struct d;
template 
struct d : d<1, f...>, b {};
template  struct d : b {};
template  class h : d<0, g...> {};
struct i {};
class j {
  using k = int;
  h l;
  float m = 0.025f;
} n;

[Bug middle-end/97804] ICE in output_constructor_register_field varasm.c:5407

[law at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Jeffrey A. Law  ---
Created attachment 49550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49550=edit
Testcase

[Bug middle-end/97804] New: ICE in output_constructor_register_field varasm.c:5407

[law at redhat dot com via Gcc-bugs]

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

Bug ID: 97804
   Summary: ICE in output_constructor_register_field
varasm.c:5407
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at redhat dot com
  Target Milestone: ---

Trunk as of 5d46ec3db21d8c8926f15a634b2d6570536db5f1 faults compiling the
attached code with -O2 -std=c++17 on x86_64:

./cc1plus -O2 -std=c++17 FreeLookCamera.cpp.ii -quiet -w
/builddir/build/BUILD/dolphin-31524288e3b2450eaefff8202c6d26c4ba3f7333/Source/Core/VideoCommon/FreeLookCamera.cpp:305:1:
internal compiler error: in output_constructor_regular_field, at varasm.c:5407
0x1bd1821 output_constructor_regular_field
/home/gcc/gcc/gcc/varasm.c:5407
0x1bd2742 output_constructor
/home/gcc/gcc/gcc/varasm.c:5713
0x1bd0ed0 output_constant
/home/gcc/gcc/gcc/varasm.c:5222
0x1bd1b62 output_constructor_regular_field
/home/gcc/gcc/gcc/varasm.c:5446
0x1bd2742 output_constructor
/home/gcc/gcc/gcc/varasm.c:5713
0x1bd0ed0 output_constant
/home/gcc/gcc/gcc/varasm.c:5222
0x1bd1b62 output_constructor_regular_field
/home/gcc/gcc/gcc/varasm.c:5446
0x1bd2742 output_constructor
/home/gcc/gcc/gcc/varasm.c:5713
0x1bd0ed0 output_constant
/home/gcc/gcc/gcc/varasm.c:5222
0x1bd1b62 output_constructor_regular_field
/home/gcc/gcc/gcc/varasm.c:5446
0x1bd2742 output_constructor
/home/gcc/gcc/gcc/varasm.c:5713
0x1bd0ed0 output_constant
/home/gcc/gcc/gcc/varasm.c:5222
0x1bd1b62 output_constructor_regular_field
/home/gcc/gcc/gcc/varasm.c:5446
0x1bd2742 output_constructor
/home/gcc/gcc/gcc/varasm.c:5713
0x1bd0ed0 output_constant
/home/gcc/gcc/gcc/varasm.c:5222
0x1bd1b62 output_constructor_regular_field
/home/gcc/gcc/gcc/varasm.c:5446
0x1bd2742 output_constructor
/home/gcc/gcc/gcc/varasm.c:5713
0x1bd0ed0 output_constant
/home/gcc/gcc/gcc/varasm.c:5222
0x1bc6059 assemble_variable_contents
/home/gcc/gcc/gcc/varasm.c:2128
0x1bc6afc assemble_variable(tree_node*, int, int, int)
/home/gcc/gcc/gcc/varasm.c:2307


I haven't tried to reproduce or bisect.  However, I would assume is likely a
regression.

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[hockney at jpl dot nasa.gov via Gcc-bugs]

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

George Hockney  changed:

   What|Removed |Added

  Known to work||10.2.1

--- Comment #7 from George Hockney  ---
We have build 10.2.1 20201017 locally and bugtest.f passes.

No warning messages
valgrind says it's OK
runs OK.


We are in process of a major build testing a large-scale legacy software
package, but it looks as if this regression is fixed.

[Bug testsuite/97803] New: c-c++-common/asan/pointer-compare-1.c assumes variable placement

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

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

Bug ID: 97803
   Summary: c-c++-common/asan/pointer-compare-1.c assumes variable
placement
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

c-c++-common/asan/pointer-compare-1.c has

char global1[100] = {}, global2[100] = {}; 
char __attribute__((used)) smallest_global[5] = {}; 
char small_global[7] = {}; 
char __attribute__((used)) little_global[10] = {}; 
char __attribute__((used)) medium_global[4000] = {}; 
char large_global[5000] = {}; 
char __attribute__((used)) largest_global[6000] = {}; 

They are used to has layout:

00404380 B largest_global
00405b20 B large_global
00406ee0 B medium_global
00407ea0 B little_global
00407ee0 B small_global
00407f20 B smallest_global
00407f60 B global2
00408000 B global1
004080e0 B __odr_asan.largest_global
004080e1 B __odr_asan.large_global
004080e2 B __odr_asan.medium_global
004080e3 B __odr_asan.little_global
004080e4 B __odr_asan.small_global
004080e5 B __odr_asan.smallest_global
004080e6 B __odr_asan.global2
004080e7 B __odr_asan.global1

With SHF_GNU_RETAIN change:

https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/elf/shf_retain

the new layout become:

00404380 B large_global
00405740 B small_global
00405780 B global2
00405820 B global1
00405900 B __odr_asan.largest_global
00405901 B __odr_asan.large_global
00405902 B __odr_asan.medium_global
00405903 B __odr_asan.little_global
00405904 B __odr_asan.small_global
00405905 B __odr_asan.smallest_global
00405906 B __odr_asan.global2
00405907 B __odr_asan.global1
00405920 B largest_global
004070c0 B medium_global
00408080 B little_global
004080c0 B smallest_global

and test fails.

[Bug target/97802] [AArch64] Incorrect documentation for Arm64 NEON

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
See https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/ARM-Options.html#index-mfpu-1

The comment still applies to ARMv8 aarch32 NEON though so there is no bug here.
The only thing that can cause confusion is arm vs aarch64 but that is explained
in many other places.

[Bug c/97793] Bogus return-type warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The reason for that is that for static functions it is the FE that emits the
warnings and doesn't have the ability to check for fallthrough into the end of
function being unreachable, while for public functions it is only the
middle-end (after cfg is created, so has the ability to check that).
The C++ FE does it very similarly, but since PR55189 it has some quick infinite
loops check, to cite Jason:
> To avoid spurious warnings on code with infinite loops we could add a 
>
> simple check for infinite loops and suppress the warning in that case.
>
> Basically, if we see a loop with an always-true condition and no breaks.  
>
Not sure how hard would it be to add similar tracking of infinite loops to the
C FE.

[Bug target/97802] [AArch64] Incorrect documentation for Arm64 NEON

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-11
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This documentation applies only to arm-*-* target and is in the arm option
section rather than the aarch64 section.  So I don't understand why you think
it is confusing at all.

[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits

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

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

--- Comment #8 from Jonathan Wakely  ---
I suppose I could change the static_assert message to also suggest defining
your own specialization of std::pointer_traits, which is another way to make it
work.

[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Thanks, Glen. So it seems I was right the first time, and using std::to_address
does require a type that can be used with std::pointer_traits.

Not a bug then. Sorry, Zach!

[Bug target/97802] New: [AArch64] Incorrect documentation for Arm64 NEON

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

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

Bug ID: 97802
   Summary: [AArch64] Incorrect documentation for Arm64 NEON
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spop at gcc dot gnu.org
  Target Milestone: ---

The following text in doc/invoke.texi seems to be outdated.  To avoid confusion
the text needs to be more specific on which NEON implementations it applies:

"If the selected floating-point hardware includes the NEON extension
(e.g.@: @option{-mfpu=neon}), note that floating-point
operations are not generated by GCC's auto-vectorization pass unless
@option{-funsafe-math-optimizations} is also specified.  This is
because NEON hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated as
zero), so the use of NEON instructions may lead to a loss of precision."

This used to be true for older NEON implementations.
NEON implementation in Armv8 and later is IEEE 754 compliant.

[Bug target/97784] Expressions evaluated as long chain instead of as tree or the like

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

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

--- Comment #6 from Segher Boessenkool  ---
(In reply to Richard Biener from comment #3)
> There is targetm.sched.reassociation_width which specifies how re-assocation
> should make such sequence "wide".

Ah cool, thank you :-)

> Andrew is correct that we don't do this
> for any types that are TYPE_OVERFLOW_UNDEFINED.

Yes; but I see the sub-optimal behaviour for unsigned, too.

> And powerpc has
> 
> static int
> rs6000_reassociation_width (unsigned int opc ATTRIBUTE_UNUSED,
> machine_mode mode)
> {
>   switch (rs6000_tune)
> {
> case PROCESSOR_POWER8:
> case PROCESSOR_POWER9:
> case PROCESSOR_POWER10:
>   if (DECIMAL_FLOAT_MODE_P (mode))
> return 1;
>   if (VECTOR_MODE_P (mode))
> return 4;
>   if (INTEGRAL_MODE_P (mode))
> return 1;

Yeah this last 1 is the problem :-)

> thus you get width 1 which means a linear chain (even if the user wrote
> a tree).

Yup.

> Note RTL doesn't do any such thing like re-assocation (I guess in principle
> scheduling could, and that's the only place where it would make sense
> on RTL).

RTL unrolling can, actually!  "Variable expansion" is its horrible name
(and it makes a lot of sense there: it allows breaking a bit linear chain
into pieces).

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
I couldn't find any current 11-master, 10-, 9- and 8-branch version that
fails on x86_64-pc-linux-gnu, under valgrind, and with -m32 and -m64.

So it looks very likely that Dominique is right that this has been fixed
everywhere.  Otherwise please provide more details on your environment.

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:61827d5d9a5a09a8c05d5e41f95b03ebc6c43f61

commit r11-4925-g61827d5d9a5a09a8c05d5e41f95b03ebc6c43f61
Author: Patrick Palka 
Date:   Wed Nov 11 14:43:39 2020 -0500

c++: Correct the handling of alignof(expr) [PR88115]

We're currently neglecting to set the ALIGNOF_EXPR_STD_P flag on an
ALIGNOF_EXPR when its operand is an expression.  This leads to us
handling alignof(expr) as if it were written __alignof__(expr), and
returning the preferred alignment instead of the ABI alignment.  In the
testcase below, this causes the first and third static_assert to fail on
x86.

gcc/cp/ChangeLog:

PR c++/88115
* cp-tree.h (cxx_sizeof_or_alignof_expr): Add bool parameter.
* decl.c (fold_sizeof_expr): Pass false to
cxx_sizeof_or_alignof_expr.
* parser.c (cp_parser_unary_expression): Pass std_alignof to
cxx_sizeof_or_alignof_expr.
* pt.c (tsubst_copy): Pass false to cxx_sizeof_or_alignof_expr.
(tsubst_copy_and_build): Pass std_alignof to
cxx_sizeof_or_alignof_expr.
* typeck.c (cxx_alignof_expr): Add std_alignof bool parameter
and pass it to cxx_sizeof_or_alignof_type.  Set ALIGNOF_EXPR_STD_P
appropriately.
(cxx_sizeof_or_alignof_expr): Add std_alignof bool parameter
and pass it to cxx_alignof_expr.  Assert op is either
SIZEOF_EXPR or ALIGNOF_EXPR.

libcc1/ChangeLog:

PR c++/88115
* libcp1plugin.cc (plugin_build_unary_expr): Pass true to
cxx_sizeof_or_alignof_expr.

gcc/testsuite/ChangeLog:

PR c++/88115
* g++.dg/cpp0x/alignof6.C: New test.

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r11-4926-gb1c9b3c3408c1ec8043f9b9e1a148f84bb7f3b25
Author: Patrick Palka 
Date:   Wed Nov 11 15:11:23 2020 -0500

c++: Change the mangling of __alignof__ [PR88115]

This patch changes the mangling of __alignof__ to v111__alignof__,
making its mangling distinct from that of alignof(type) and
alignof(expr).

How we mangle ALIGNOF_EXPR now depends on its ALIGNOF_EXPR_STD_P flag,
which after the previous patch gets consistently set for alignof(type)
as well as alignof(expr).

gcc/c-family/ChangeLog:

PR c++/88115
* c-opts.c (c_common_post_options): Update latest_abi_version.

gcc/ChangeLog:

PR c++/88115
* common.opt (-fabi-version): Document =15.
* doc/invoke.texi (C++ Dialect Options): Likewise.

gcc/cp/ChangeLog:

PR c++/88115
* mangle.c (write_expression): Mangle __alignof_ differently
from alignof when the ABI version is at least 15.

libiberty/ChangeLog:

PR c++/88115
* cp-demangle.c (d_print_comp_inner)
: Don't print the
"operator " prefix for __alignof__.
: Always print parens around the
operand of __alignof__.
* testsuite/demangle-expected: Test demangling for __alignof__.

gcc/testsuite/ChangeLog:

PR c++/88115
* g++.dg/abi/macro0.C: Adjust.
* g++.dg/cpp0x/alignof7.C: New test.
* g++.dg/cpp0x/alignof8.C: New test.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[avi--- via Gcc-bugs]

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

--- Comment #36 from Avi Kivity  ---
A reminder that coroutines are crippled without this fixed, as it is standard
practice these days to use sanitizers.

[Bug c++/97801] New: overload resolution ambiguity isn't detected when rvalue ref qualifier is involved

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 97801
   Summary: overload resolution ambiguity isn't detected when
rvalue ref qualifier is involved
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/7onfa6
struct G {
   static int min(int=0) { return 1; }
   int min() && { return 2; }
};
int x = G::min();

GCC accepts; Clang, MSVC, and ICC reject.

GCC treats `G::min()` as an unambiguous call to the static member function.
However, C++ seems to require that overload resolution reject this code as
ambiguous -- it should be ambiguous between the two different G::min()s capable
of taking zero arguments, *even though* the non-static one can't actually be
called without a "this" argument.

Strangely, this bug appears only when the non-static candidate is
rvalue-ref-qualified (either "&&" or "const&&" or "volatile&&"). It does not
appear with "&" or "const&" or "const", nor if the function is not
ref-qualified.

[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits

[glenjofe at gmail dot com via Gcc-bugs]

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

Glen Joseph Fernandes  changed:

   What|Removed |Added

 CC||glenjofe at gmail dot com

--- Comment #6 from Glen Joseph Fernandes  ---
> Do we then have a spec bug?

The to_address(const P&) overload always assumed a valid pointer_traits.
Even before it was std::to_address in C++20, when it was __to_address in
libstdc++, or boost::to_address, or __to_raw_pointer in libc++, and was used in
C++11 and above, its return type was 'typename
std::pointer_traits::element_type*' which requires a valid pointer_traits.

i.e. Our allocator-aware containers would only ever work with fancy pointer P
for which pointer_traits is valid.

std::to_address being used for more than just raw-or-fancy-pointers came later
(since Casey's P1474 which chose to use it for contiguous iterators). My guess
is they didn't realize pointer_traits wouldn't be valid for those iterator
types.

[Bug ipa/97757] [11 Regression] fortran save_6.f90 fails with a segv for -flto -O >= 2

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

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

--- Comment #2 from Dominique d'Humieres  ---
Reduced test:

subroutine bar_array()
  logical, save :: first = .true.
  character(len=:), allocatable :: str
  if (first) then
first = .false.
if (allocated (str)) STOP 7
str = "ABCDEF"
  end if
end subroutine bar_array

call bar_array()
end

% gfc save_5_red.f90 -fno-automatic -flto -O2
during IPA pass: modref
save_5_red.f90:12:3: internal compiler error: Segmentation fault: 11
   12 | end
  |   ^

>From the manual

-fno-automatic
Treat each program unit (except those marked as RECURSIVE) as if the SAVE
statement were specified for every local variable and array referenced in it.
Does not affect common blocks. (Some Fortran compilers provide this option
under the name -static or -save.) The default, which is -fautomatic, uses the
stack for local variables smaller than the value given by -fmax-stack-var-size.
Use the option -frecursive to use no static memory.

Local variables or arrays having an explicit SAVE attribute are silently
ignored unless the -pedantic option is added.

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

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

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

--- Comment #33 from Jim Wilson  ---
I did say that I'm willing to fix code style issues.  All major software
projects I have worked with have coding style conventions.  It makes it easier
to maintain a large software base when everything is using the same coding
style.  We do have info to help you follow the GNU coding style.  See
https://gcc.gnu.org/wiki/FormattingCodeForGCC
which has emacs and vim settings to get the right code style.

[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

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

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

--- Comment #5 from Dominique d'Humieres  ---
> Did you happen to run valgrind using the 10.2.1 build?

Unfortunately I don't have valgrind on my new laptop (OSX Catalina).
However I have run the test 20 times with 10.2.1 without any failure, while I
got 10 failures out of 10 runs on 10.2.0.

Also I get the warning with 10.2 but not with any other release I have tried
(including an instrumented compiler).

I have tried another laptop with valgrind and did not see any problem, but I
don't have 10.2.0 on it.

So it seems you stumbled on a 10 regression that have been fixed.

[Bug bootstrap/97800] [11 regression] bootstrap build failure starting with r11-4913

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Looks like 2e8b368c3d33fd8ddafdd37f8e1b2ba45d1a122e maybe fixed this

[Bug bootstrap/97800] New: [11 regression] bootstrap build failure starting with r11-4913

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

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

Bug ID: 97800
   Summary: [11 regression] bootstrap build failure starting with
r11-4913
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:bd87cc14ebdb6789e067fb1828d5808407c308b3, r11-4913 

/bin/sh ../libtool  --tag=CC   --mode=compile
/home/seurer/gcc/git/build/gcc-test/./prev-gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./prev-gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include  
-fno-checking -DHAVE_CONFIG_H -I. -I/home/seurer/gcc/git/gcc-test/gmp/mpn -I.. 
-D__GMP_WITHIN_GMP -I/home/seurer/gcc/git/gcc-test/gmp -DOPERATION_`echo
sec_powm | sed 's/_$//'`  -DNO_ASM -g -O2 -fno-checking -gtoggle -c -o
sec_powm.lo sec_powm.c
libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./prev-gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./prev-gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-fno-checking -DHAVE_CONFIG_H -I. -I/home/seurer/gcc/git/gcc-test/gmp/mpn -I..
-D__GMP_WITHIN_GMP -I/home/seurer/gcc/git/gcc-test/gmp -DOPERATION_sec_powm
-DNO_ASM -g -O2 -fno-checking -gtoggle -c sec_powm.c -o sec_powm.o
during GIMPLE pass: pre
In file included from sec_powm.c:59:
sec_powm.c: In function '__gmpn_sec_powm':
../gmp.h:252:18: internal compiler error: Segmentation fault
  252 | #define __MPN(x) __gmpn_##x
  |  ^~~
../gmp.h:1671:22: note: in expansion of macro '__MPN'
 1671 | #define mpn_sec_powm __MPN(sec_powm)
  |  ^
sec_powm.c:218:1: note: in expansion of macro 'mpn_sec_powm'
  218 | mpn_sec_powm (mp_ptr rp, mp_srcptr bp, mp_size_t bn,
  | ^~~~
0x111bbf1f crash_signal
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:330
0x1080f878 bitmap_bit_p(bitmap_head const*, int)
/home/seurer/gcc/git/gcc-test/gcc/bitmap.c:989
0x114ecfcf bitmap_set_contains_value
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-pre.c:899
0x114ed0c7 bitmap_value_replace_in_set
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-pre.c:920
0x114f3ddb create_expression_by_pieces
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-pre.c:3003
0x114f641b do_hoist_insertion
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-pre.c:3648
0x114f6a07 insert
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-pre.c:3764
0x114f866f execute
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-pre.c:4299

commit bd87cc14ebdb6789e067fb1828d5808407c308b3
Author: Richard Biener 
Date:   Wed Nov 11 11:51:59 2020 +0100

[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits

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

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

--- Comment #5 from Jonathan Wakely  ---
But on third thoughts, I don't know how to implement this reliably.

[Bug c++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

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

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

Marek Polacek  changed:

   What|Removed |Added

 Target|msp430-elf  |

--- Comment #5 from Marek Polacek  ---
Even simpler:

const int var = 1 << -1;

template
void
fn ()
{
  static_assert(N != var);
}

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[laszlo.2.nemeth--- via Gcc-bugs]

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

Leslie  changed:

   What|Removed |Added

 CC||laszlo.2.nemeth@continental
   ||-corporation.com

--- Comment #3 from Leslie  ---
I encountered the same problem, so I put +1 vote for fixing this :)

Following Comment 2, this looks like related to already reported bugs:
built-ins are always considers as "noexcept":
Bug 96985, Bug 39801 (from 2009) and maybe Bug 94357, too ?

Thanks Jorge for reporting this!

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[ted.drain at jpl dot nasa.gov via Gcc-bugs]

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

Ted Drain  changed:

   What|Removed |Added

 CC||ted.drain at jpl dot nasa.gov

--- Comment #4 from Ted Drain  ---
Dominique,
Did you happen to run valgrind using the 10.2.1 build?  This error doesn't
always cause a core dump - sometimes it appears to work.  Valgrind reports the
error even if the program seems to run.

Thanks,
Ted

[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-11-11
 Ever confirmed|0   |1
   Target Milestone|--- |10.3

--- Comment #4 from Jonathan Wakely  ---
On reading this again, I think the implementation should be required to check
whether the specialization pointer_­traits​ would be well-formed as part
of checking the expression pointer_­traits​::​to_­address(p).

So it's unnecessarily awkward, but still the implementation's job to do that.

[Bug c++/96985] c++ `noexcept` is ignored for *known* functions

[laszlo.2.nemeth--- via Gcc-bugs]

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

Leslie  changed:

   What|Removed |Added

 CC||laszlo.2.nemeth@continental
   ||-corporation.com

--- Comment #1 from Leslie  ---
Looks like it's the same as bug 39801 ?

[Bug c++/97518] Improving static_assert diagnostics

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r11-4924-gd6e5745a9a88314e27f387b2277299076862af67
Author: Marek Polacek 
Date:   Tue Nov 10 16:39:19 2020 -0500

c++: Tweak tsubst_qualified_id location.

Retain the location when tsubstituting a qualified-id so that our
static_assert diagnostic can benefit.  Don't create useless location
wrappers for temporary variables.

gcc/ChangeLog:

PR c++/97518
* tree.c (maybe_wrap_with_location): Don't add a location
wrapper around an artificial and ignored decl.

gcc/cp/ChangeLog:

PR c++/97518
* pt.c (tsubst_qualified_id): Use EXPR_LOCATION of the
qualified-id.
Use it to maybe_wrap_with_location the final expression.

gcc/testsuite/ChangeLog:

PR c++/97518
* g++.dg/diagnostic/static_assert3.C: New test.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

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

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #14)
> > --- a/libgcc/gthr-posix.h
> > +++ b/libgcc/gthr-posix.h
> > @@ -684,7 +684,12 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
> >  static inline __gthread_t
> >  __gthread_self (void)
> >  {
> > +#if __GLIBC_PREREQ(2, 27)
> 
> Hmm, maybe we should just check #ifdef __GLIBC__ here, since it's available
> in libc even before glibc 2.27 (it returns 0 rather than a real tid before
> 2.27, but that's OK).

Except that as Florian said above, it's missing from libc.a prior to 2.27 so if
we used it unconditionally, you wouldn't be able to link statically.

> > --- a/libstdc++-v3/include/std/thread
> > +++ b/libstdc++-v3/include/std/thread
> > @@ -364,13 +364,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >  inline thread::id
> >  get_id() noexcept
> >  {
> > -#ifdef __GLIBC__
> > +#if defined __GLIBC__ && ! __GLIBC_PREREQ(2, 27)
> 
> And maybe we shouldn't change this check either.
> 
> If we make it depend on the glibc version then because this function is
> inline a program could have two different definitions inlined if different
> objects were compiled by different versions of gcc, or against different
> versions of glibc. One object could inline the version returning
> thread::id(1) and another could inline the version returning
> thread::id(__gthread_self()). This could result in two different IDs for the
> main thread of a single-threaded program. So maybe we should just stick to
> returning thread::id(1) for all glibc versions.

I've decided I'm not too concerned about this. There are probably not many
users of std::this_thread::get_id() in programs not linked with -lpthread, and
any such code will have to deal with a change here once all pthreads symbols
move into glibc's libc anyway. When that happens __gthread_active_p will always
be true. Let's just go ahead and use pthread_self() when it's known to work
(i.e. glibc 2.27 and later).

Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558737.html

[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))

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

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

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

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

commit r11-4923-g2e8b368c3d33fd8ddafdd37f8e1b2ba45d1a122e
Author: Richard Biener 
Date:   Wed Nov 11 18:15:57 2020 +0100

Fix PRE NEW_SETS guarding

Accesses to NEW_SETS should be properly guarded.  Committed
as obvious.

2020-11-11  Richard Biener  

PR tree-optimization/97623
* tree-ssa-pre.c (create_expression_by_pieces): Guard
NEW_SETS access.
(insert_into_preds_of_block): Likewise.

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-11-11
   Priority|P3  |P4

--- Comment #3 from Dominique d'Humieres  ---
I confirm the problem for GCC 10.2, but it seems fixed for 10.2.1 20201017, and
11.

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[hockney at jpl dot nasa.gov via Gcc-bugs]

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

George Hockney  changed:

   What|Removed |Added

  Known to work||9.2.0
  Known to fail||10.2.0

--- Comment #2 from George Hockney  ---
Added details.txt attachment and updated Known to work and Known to fail fields

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[hockney at jpl dot nasa.gov via Gcc-bugs]

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

--- Comment #1 from George Hockney  ---
Created attachment 49549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49549=edit
details.txt -- detailed invocation and outputs

[Bug fortran/97799] New: Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[hockney at jpl dot nasa.gov via Gcc-bugs]

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

Bug ID: 97799
   Summary: Passing CHARACTER*(*) var(*) through ENTRY causes
segfaults
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hockney at jpl dot nasa.gov
  Target Milestone: ---

Created attachment 49548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49548=edit
bugtest.f -- program evincing bug

When a character(*)* var(*) is passed to a subroutine
through an entry point in another subroutine, gfortran 10.2.0
generates an exectuable which segfaults in a probablistic way.  This
is probably related to a warning about an internally
generated variable being used uninitialized.  The warning and error
do not occur in gfortran 9.2.0

   The attached file bugtest.f evinces this behavior.  The
attached file details.txt shows the exact compilition
flags to reproduce the failure, and also the resulting
backtrace.

  The exact combination of compilation flags matters.  All of
them produce the warning about carray.0 but some of them
both work and pass our valgrind test:

gfortran -Wall -g -S bugtest.f; gfortran bugtest.s -o bugtest  #  fail
gfortran -g bugtest.f -o bugtest  #  fail
gfortran -O1 bugtest.f -o bugtest  #  fail
gfortran -O2 bugtest.f -o bugtest  #  ok
gfortran -O3 bugtest.f -o bugtest  #  ok
gfortran -O2 -fPIC bugtest.f -o bugtest  #  fail
gfortran -O3 -fPIC bugtest.f -o bugtest  #  fail


The valgrind error trace for the errors is:
==32181== Conditional jump or move depends on uninitialised value(s)
==32181==at 0x401438: master.0.top_entry_ (bugtest.f:53)
==32181==by 0x40141B: char_entry_ (bugtest.f:49)
==32181==by 0x40148F: MAIN__ (bugtest.f:6)
==32181==by 0x401698: main (bugtest.f:12)


  gfortran 9.2.0 does not evince this bug.

[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #18 from Thomas Schwinge  ---
Noting the following in case there's something unexpected there:

(In reply to CVS Commits from comment #17)
> commit r11-4913-gbd87cc14ebdb6789e067fb1828d5808407c308b3
> Author: Richard Biener 
> Date:   Wed Nov 11 11:51:59 2020 +0100
> 
> tree-optimization/97623 - Avoid PRE hoist insertion iteration

On x84_64 GNU/Linux native, this introduced an ICE regression in
'libgomp/plugin/plugin-gcn.c' build (only! -- all other target libraries built
fine):

during GIMPLE pass: pre
[...]/libgomp/plugin/plugin-gcn.c: In function ‘run_kernel’:
[...]/libgomp/plugin/plugin-gcn.c:2066:1: internal compiler error:
Segmentation fault
 2066 | run_kernel (struct kernel_info *kernel, void *vars,
  | ^~

Program received signal SIGSEGV, Segmentation fault.
bitmap_bit_p (head=0x20, bit=879) at [...]/gcc/bitmap.c:989
989   if (!head->tree_form)
(gdb) bt
#0  bitmap_bit_p (head=0x20, bit=879) at [...]/gcc/bitmap.c:989
#1  0x01057bb3 in bitmap_set_contains_value (value_id=879, set=0x0)
at [...]/gcc/tree-ssa-pre.c:899
#2  bitmap_value_replace_in_set (set=0x0, expr=expr@entry=0x2d7f990) at
[...]/gcc/tree-ssa-pre.c:920
#3  0x01057f35 in create_expression_by_pieces
(block=block@entry=0x763a51a0, expr=expr@entry=0x2d798f0,
stmts=stmts@entry=0x7fffc440, type=) at
[...]/gcc/tree-ssa-pre.c:3003
#4  0x0105e3e9 in do_hoist_insertion (block=) at
[...]/gcc/tree-ssa-pre.c:3648
#5  insert () at [...]/gcc/tree-ssa-pre.c:3764
#6  (anonymous namespace)::pass_pre::execute (this=,
fun=0x76221da8) at [...]/gcc/tree-ssa-pre.c:4299
#7  0x00d50820 in execute_one_pass (pass=pass@entry=0x2c132f0) at
[...]/gcc/passes.c:2564
#8  0x00d51198 in execute_pass_list_1 (pass=0x2c132f0) at
[...]/gcc/passes.c:2653
#9  0x00d511aa in execute_pass_list_1 (pass=0x2c12220) at
[...]/gcc/passes.c:2654
#10 0x00d511f5 in execute_pass_list (fn=,
pass=) at [...]/gcc/passes.c:2664
#11 0x0094ae6d in cgraph_node::expand (this=0x76220dd0) at
[...]/gcc/cgraphunit.c:1829
#12 0x0094c69d in expand_all_functions () at
[...]/gcc/cgraphunit.c:1997
#13 symbol_table::compile (this=this@entry=0x767a8100) at
[...]/gcc/cgraphunit.c:2361
#14 0x0094fdde in symbol_table::compile (this=0x767a8100) at
[...]/gcc/cgraphunit.c:2274
#15 symbol_table::finalize_compilation_unit (this=0x767a8100) at
[...]/gcc/cgraphunit.c:2542
#16 0x00e866b1 in compile_file () at [...]/gcc/toplev.c:485
#17 0x00742f4c in do_compile () at [...]/gcc/toplev.c:2320
#18 toplev::main (this=this@entry=0x7fffc6e0, argc=argc@entry=62,
argv=argv@entry=0x7fffc7e8) at [...]/gcc/toplev.c:2459
#19 0x00746f87 in main (argc=62, argv=0x7fffc7e8) at
[...]/gcc/main.c:39

I find this ICE is then again cured by your follow-on commit
r11-4921-g86cca5cc14602814b98e55aae313fbe237af1b04 "Fix PRE topological
expression set sorting", but I can't easily tell if that's now all
fine/expected, or if there may be some underlying problem here, which makes the
ICE just hidden again?  If relevant, please tell if you'd like me to attach a
pre-processed source file.

[Bug c++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

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

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

--- Comment #4 from Marek Polacek  ---
Reduced.  Nothing MSP430-specific here.

template  struct A;
struct B {
  typedef A type;
};
template  struct A { static const T max = 1 ? 1 << (T) -1 : 0; };
template  const T A::max;
class F {};
template  void operator>(F, int) { static_assert(N <= B::type::max); }

[Bug pch/14940] PCH largefile test fails on various platforms

[julien.ruffin at ivu dot de via Gcc-bugs]

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

Julien Ruffin  changed:

   What|Removed |Added

 CC||julien.ruffin at ivu dot de

--- Comment #51 from Julien Ruffin  ---
I can confirm Martin's patches in #49 and #50 work on GCC 9.2.0. They solve
silent segfaults when using large PCHs (> 128MB).

[Bug c++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-11-11
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |11.0

--- Comment #3 from Marek Polacek  ---
Thanks!  I've reproduced it now, and I'm reducing it.

tester.ii: In function ‘std::basic_istream<_CharT, _Traits>&
std::operator>>(std::basic_istream<_CharT, _Traits>&, _CharT (&)[_Num])’:
tester.ii:33343:26: error: non-constant condition for static assertion
33343 |   static_assert(_Num <=
__gnu_cxx::__numeric_traits::__max);
  |
~^
tester.ii:33343:26: error: the value of
‘__gnu_cxx::__numeric_traits_integer<__int20>::__max’ is not usable in a
constant expression
tester.ii:5079:27: note: ‘__gnu_cxx::__numeric_traits_integer<__int20>::__max’
was not initialized with a constant expression
 5079 |   static const _Value __max = (((_Value)(-1) < 0) ? (_Value)1
<< ((sizeof(_Value) * 8 - ((_Value)(-1) < 0)) - 1)) - 1) << 1) + 1) :
~(_Value)0);
  |   ^

[Bug tree-optimization/97789] valgrind error with ./gcc.dg/c11-atomic-2.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to David Binderman from comment #6)
>Maybe something like
> 
> $ git rev-parse HEAD >> gcc/trunk.git/gcc/DATESTAMP
> 
> would be enough to get it into the output of gcc -v.

For the record, my current bash code for this is:

cd ../trunk.git
HASH=`git rev-parse HEAD`
cd ../working
echo $HASH

and later

../trunk.git/configure --with-pkgversion=$HASH

Here is an example of it in practice:

$ ./results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=./results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.2020/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.git/configure --prefix=/home/dcb/gcc/results.2020
--disable-bootstrap --disable-multilib --disable-werror
--with-pkgversion=46c705e70e078f6a1920d92e49042125d5e18495
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 2020 (experimental)
(46c705e70e078f6a1920d92e49042125d5e18495) 
$

[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

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

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

--- Comment #4 from Richard Biener  ---
Hmm, the final linker input, namely /tmp/bibletime.kNyaLB.ltrans9.ltrans.o
would be a start.  Adding -save-temps should eventually retain it (but likely
somewhere else with a different name).

You can also try to 'reduce' the testcase.  Since you are linking a shared
object you can try to strip as many linker inputs as possible and then
reduce the source files.  creduce or multi-delta or cvise might help you
here.  Eventually Martin can help but I don't think the compile-farm has
a mips64 machine.

[Bug c++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

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

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

--- Comment #2 from jozefl at gcc dot gnu.org ---
Created attachment 49547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49547=edit
tester.ii

(In reply to Marek Polacek from comment #1)
> Would it be possible to provide a preprocessed source file?

(Large) testcase attached. I can run it through a reducer and re-upload if
required.

Reproduces with:

> $ msp430-elf-gcc -mlarge -std=gnu++20 tester.ii -S -w

Thanks,
Jozef

[Bug c/97794] internal compiler error: tree code 'ssa_name' is not supported in LTO streams

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
The failure was reported in pr97298 which is a duplicate of pr97172.

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

[Bug lto/97298] [11 regression] ICE at lto-streamer-out.c:554 after r11-3303

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||vladimir.kokovic at gmail dot 
com

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

[Bug c++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

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

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

--- Comment #1 from Marek Polacek  ---
Would it be possible to provide a preprocessed source file?

[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[bunk at stusta dot de via Gcc-bugs]

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

Adrian Bunk  changed:

   What|Removed |Added

 CC||bunk at stusta dot de

--- Comment #3 from Adrian Bunk  ---
(In reply to Richard Biener from comment #1)
> I guess it succeeds when you do not enable -g?

Still fails with -g0

(In reply to Richard Biener from comment #1)
> Can you check if reverting
> 63a2bdbfb42628800a6999e98804928855592ce7 or
> 136256c32db63600168516e562441f73c26a187a helps?  That said, is 10.1.0 OK?

(In reply to Martin Liška from comment #2)
> I bet 136256c32db63600168516e562441f73c26a187a should fix that.

Sorry for omitting more exact version information in the bug report.

Known-broken are all Debian gcc-10 packages since gcc 10 became default in
Debian unstable, upstream this is the gcc-10 branch from 20200808 to 20201029.

This implies that the two mentioned commits did not break or fix it.

Is there any debug information I could gather that might be useful for you?

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #11 from abebeos at lazaridis dot com ---
(In reply to John Paul Adrian Glaubitz from comment #10)
[...]
> The main problem is apparently that the target hasn't been properly worked
> on for a long time.
[...]

Yes, this seems to result in this barrier:

=> missing stable development environment for the work on the avr backend
itself (build/test/simulate).

So this issue here splits into 3 major steps:

A) create a stable dev environment fro work on the avr backend
B) remove deprecated cc0 from avr backend (gcc11 requirement, main
issue), without necessarily using MODE_CC (similar to m68k)
C) (optional) convert code to MODE_CC

Seeing that the microchip custom version uses 5.x gcc and with different
dependencies than the original code, step A could already become a multi month
effort.

If anyone knows a "stable starting point" (for developing on the avr backend),
please point to it (ideally a public repo containing all).

[Bug c++/97798] New: FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

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

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

Bug ID: 97798
   Summary: FTB msp430-elf error: the value of
'__gnu_cxx::__numeric_traits_integer<__int20>::__max'
is not usable in a constant expression
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jozefl at gcc dot gnu.org
  Target Milestone: ---

GCC fails to build for msp430-elf since:

commit c2856ceec2e7542fe9b0bf104afb57d6996d
Author: Marek Polacek 
Date:   Thu Oct 29 15:19:51 2020 -0400

c++: Tweaks for value_dependent_expression_p.

There is an error building libstdc++ for the -mlarge multilib, which uses
__int20 pointers:

> In file included from 
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/sstream:38,
>  from 
> ../../../../../../libstdc++-v3/src/c++20/sstream-inst.cc:30:
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:
>  In function 'std::basic_istream<_CharT, _Traits>& 
> std::operator>>(std::basic_istream<_CharT, _Traits>&, _CharT (&)[_Num])':
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:840:26:
>  error: non-constant condition for static assertion
>   840 |   static_assert(_Num <= 
> __gnu_cxx::__numeric_traits::__max);
>   | 
> ~^
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:840:26:
>  error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is 
> not usable in a constant expression
> In file included from 
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/bits/stl_algobase.h:63,
>  from 
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/bits/char_traits.h:39,
>  from 
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/ios:40,
>  from 
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:38,
>  from 
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/sstream:38,
>  from 
> ../../../../../../libstdc++-v3/src/c++20/sstream-inst.cc:30:
> /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/ext/numeric_traits.h:78:27:
>  note: '__gnu_cxx::__numeric_traits_integer<__int20>::__max' was not 
> initialized with a constant expression
>78 |   static const _Value __max = __glibcxx_max(_Value);
>   |   ^
> make[9]: *** [Makefile:550: sstream-inst.lo] Error 1

Configured with:
> ../configure --target=msp430-elf --enable-languages=c,c++ --disable-nls 
> --disable-no-exceptions --disable-full-memory-range

[Bug c++/97790] constexpr evaluation reports false positive memory leak

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 49546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49546=edit
gcc11-pr97790.patch

Untested fix.

[Bug testsuite/97797] internal compiler error: in build2, at tree.c:4814

[vladimir.kokovic at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Vladimir Koković  ---
What is with ssa-fre-7.c ?


Vladimir Koković, DP senior(70),

Serbia, Belgrade, 10.November 2020

On 11.11.20. 12:53, cvs-commit at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97797
>
> --- Comment #3 from CVS Commits  ---
> The releases/gcc-10 branch has been updated by Richard Biener
> :
>
> https://gcc.gnu.org/g:d6da7c7e0843e0595d8c3b3aa37296b6c8f68dd0
>
> commit r10-9003-gd6da7c7e0843e0595d8c3b3aa37296b6c8f68dd0
> Author: Richard Biener 
> Date:   Wed Nov 11 12:49:57 2020 +0100
>
>  testsuite/97797 - adjust GIMPLE tests for sizetype
>
>  Tested on x86_64-unknown-linux-gnu, pushed.
>
>  2020-11-11  Richard Biener  
>
>  PR testsuite/97797
>  * gcc.dg/torture/ssa-fre-5.c: Use __SIZETYPE__ where
>  appropriate.
>  * gcc.dg/torture/ssa-fre-6.c: Likewise.
>
>  (cherry picked from commit 4ac93608d7e33a3e10bbd8d50259bc00a7d01237)
>

[Bug c++/97790] constexpr evaluation reports false positive memory leak

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The lambda, or templates aren't needed for that.
struct S
{
  int *d;
  int n;
  constexpr S () : d(new int[1]{}), n(1) {}
  constexpr ~S () { delete [] d; }
};

constexpr S
foo ()
{
  return S ();
}

constexpr int
bar ()
{
  return foo ().n;
}

constexpr int
baz ()
{
  return S ().n;
}

constexpr int a = baz ();
constexpr int b = bar ();

[Bug testsuite/97797] internal compiler error: in build2, at tree.c:4814

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.2.1, 11.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug testsuite/97797] internal compiler error: in build2, at tree.c:4814

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

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

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

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

commit r10-9003-gd6da7c7e0843e0595d8c3b3aa37296b6c8f68dd0
Author: Richard Biener 
Date:   Wed Nov 11 12:49:57 2020 +0100

testsuite/97797 - adjust GIMPLE tests for sizetype

Tested on x86_64-unknown-linux-gnu, pushed.

2020-11-11  Richard Biener  

PR testsuite/97797
* gcc.dg/torture/ssa-fre-5.c: Use __SIZETYPE__ where
appropriate.
* gcc.dg/torture/ssa-fre-6.c: Likewise.

(cherry picked from commit 4ac93608d7e33a3e10bbd8d50259bc00a7d01237)

[Bug testsuite/97797] internal compiler error: in build2, at tree.c:4814

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

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

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

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

commit r11-4914-g4ac93608d7e33a3e10bbd8d50259bc00a7d01237
Author: Richard Biener 
Date:   Wed Nov 11 12:49:57 2020 +0100

testsuite/97797 - adjust GIMPLE tests for sizetype

Tested on x86_64-unknown-linux-gnu, pushed.

2020-11-11  Richard Biener  

PR testsuite/97797
* gcc.dg/torture/ssa-fre-5.c: Use __SIZETYPE__ where
appropriate.
* gcc.dg/torture/ssa-fre-6.c: Likewise.

[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))

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

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

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

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

commit r11-4913-gbd87cc14ebdb6789e067fb1828d5808407c308b3
Author: Richard Biener 
Date:   Wed Nov 11 11:51:59 2020 +0100

tree-optimization/97623 - Avoid PRE hoist insertion iteration

The recent previous change in this area limited hoist insertion
iteration via a param but the following is IMHO better since
we are not really interested in PRE opportunities exposed by
hoisting but only the other way around.  So this moves hoist
insertion after PRE iteration finished and removes hoist
insertion iteration alltogether.

2020-11-11  Richard Biener  

PR tree-optimization/97623
* params.opt (-param=max-pre-hoist-insert-iterations): Remove
again.
* doc/invoke.texi (max-pre-hoist-insert-iterations): Likewise.
* tree-ssa-pre.c (insert): Move hoist insertion after PRE
insertion iteration and do not iterate it.

* gcc.dg/tree-ssa/ssa-hoist-3.c: Adjust.
* gcc.dg/tree-ssa/ssa-hoist-7.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-30.c: Likewise.

[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/97793] Bogus return-type warning

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-11
   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
Testcase:

static int
foo ()
{
  for (;;)
;
}

int (*x)() = foo;

making foo not static elides the warning.

[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

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

commit r10-9001-gf7c2be50afa7935d3a05e3c7761e69d8b539da5b
Author: Jakub Jelinek 
Date:   Wed Nov 11 08:27:38 2020 +0100

fortran: Fix up gfc_typename CHARACTER length handling [PR97768]

The first testcase below ICEs when f951 is 32-bit (or 64-bit big-endian).
The problem is that ex->ts.u.cl && ex->ts.u.cl->length are both non-NULL,
but ex->ts.u.cl->length->expr_type is not EXPR_CONSTANT, but EXPR_FUNCTION.
value.function.actual and value.function.name are in that case pointers,
but value._mp_alloc and value._mp_size are 4 byte integers no matter what.
So, in 64-bit little-endian the function returns most of the time incorrect
CHARACTER(0) because the most significant 32 bits of the
value.function.actual pointer are likely 0.
Anyway, the following patch is an attempt to get all the cases right.
Uses ex->value.character.length only for ex->expr_type == EXPR_CONSTANT
(i.e. CHARACTER literals), handles the deferred lengths, assumed lengths,
known constant lengths and finally if the length is something other,
just doesn't print it, i.e. prints just CHARACTER (for default kind)
or CHARACTER(KIND=4) (for e.g. kind 4).

2020-11-11  Jakub Jelinek  

PR fortran/97768
gcc/fortran/
* misc.c (gfc_typename): Use ex->value.character.length only if
ex->expr_type == EXPR_CONSTANT.  If ex->ts.deferred, print :
instead
of length.  If ex->ts.u.cl && ex->ts.u.cl->length == NULL, print *
instead of length.  Otherwise if character length is non-constant,
print just CHARACTER or CHARACTER(KIND=N).
gcc/testsuite/
* gfortran.dg/pr97768_1.f90: New test.
* gfortran.dg/pr97768_2.f90: New test.

(cherry picked from commit 81372618277bfae682434fcdc80b311ee6007476)

[Bug c++/97796] internal compiler error: Segmentation fault 0xb2ed5f crash_signal - graphite

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-11-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hmm the point of crash doesn't make much sense, I assume it crashes inside the
ISL library?  What version do you use?  I guess you built that in-tree?

[Bug testsuite/97797] internal compiler error: in build2, at tree.c:4814

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-11
 Ever confirmed|0   |1
  Component|c++ |testsuite
Version|unknown |10.2.0
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
Confirmed, those are testsuite issues really.  sizeof(void *) != sizeof (long)
for mingw?

[Bug c++/97797] New: internal compiler error: in build2, at tree.c:4814

[vladimir.kokovic at gmail dot com via Gcc-bugs]

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

Bug ID: 97797
   Summary: internal compiler error: in build2, at tree.c:4814
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.kokovic at gmail dot com
  Target Milestone: ---

GIT_DIR=/mnt/WD-Elements-25A1/src/gcc-mirror-git/gcc/.git git describe HEAD
misc/first-auto-changelog-4144-gc283a711c85

Build a cross compiler for MinGW(gcc 10.2.0)

Executing on host:
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/torture/ssa-fre-5.c 
  -fdiagnostics-plain-output-O1  -fgimple -fdump-tree-fre1 -S -o
ssa-fre-5.s(timeout = 300)
spawn -ignore SIGHUP
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/torture/ssa-fre-5.c
-fdiagnostics-plain-output -O1 -fgimple -fdump-tree-fre1 -S -o ssa-fre-5.s
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/torture/ssa-fre-5.c:
In function 'foo':
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/torture/ssa-fre-5.c:22:3:
internal compiler error: in build2, at tree.c:4814
0x5efe8f build2(tree_code, tree_node*, tree_node*, tree_node*)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/tree.c:4814
0x682779 build2_loc
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/tree.h:4366
0x682779 c_parser_gimple_binary_expression
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:1003
0x6838aa c_parser_gimple_statement
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:858
0x6838aa c_parser_gimple_compound_statement
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:649
0x685dfe c_parser_gimple_compound_statement
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:385
0x685dfe c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:253
0x677257 c_parser_declaration_or_fndef
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/c-parser.c:2537
0x67e293 c_parser_external_declaration
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/c-parser.c:1777
0x67eda1 c_parser_translation_unit
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/c-parser.c:1650
0x67eda1 c_parse_file()
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/c-parser.c:21855
0x6cd07d c_common_parse_file()
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c-family/c-opts.c:1196
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/torture/ssa-fre-5.c   -O1  (internal compiler error)
FAIL: gcc.dg/torture/ssa-fre-5.c   -O1  (test for excess errors)

Executing on host:
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/torture/ssa-fre-6.c 
  -fdiagnostics-plain-output-O1  -fgimple -fdump-tree-fre1 -S -o
ssa-fre-6.s(timeout = 300)
spawn -ignore SIGHUP
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/torture/ssa-fre-6.c
-fdiagnostics-plain-output -O1 -fgimple -fdump-tree-fre1 -S -o ssa-fre-6.s
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/torture/ssa-fre-6.c:
In function 'foo':
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/torture/ssa-fre-6.c:22:3:
internal compiler error: in build2, at tree.c:4814
0x5efe8f build2(tree_code, tree_node*, tree_node*, tree_node*)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/tree.c:4814
0x682779 build2_loc
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/tree.h:4366
0x682779 c_parser_gimple_binary_expression
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:1003
0x6838aa c_parser_gimple_statement
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:858
0x6838aa c_parser_gimple_compound_statement
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:649
0x685dfe c_parser_gimple_compound_statement
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:385
0x685dfe c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/gimple-parser.c:253
0x677257 c_parser_declaration_or_fndef
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/c/c-parser.c:2537
0x67e293 c_parser_external_declaration

[Bug c++/97796] New: internal compiler error: Segmentation fault 0xb2ed5f crash_signal - graphite

[vladimir.kokovic at gmail dot com via Gcc-bugs]

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

Bug ID: 97796
   Summary: internal compiler error: Segmentation fault 0xb2ed5f
crash_signal - graphite
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.kokovic at gmail dot com
  Target Milestone: ---

GIT_DIR=/mnt/WD-Elements-25A1/src/gcc-mirror-git/gcc/.git git describe HEAD
misc/first-auto-changelog-4144-gc283a711c85

Build a cross compiler for MinGW(gcc 10.2.0)

Executing on host:
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/graphite/pr83385.c  
 -fdiagnostics-plain-output   -O1 -floop-nest-optimize  -lm  -o ./pr83385.exe  
 (timeout = 300)
spawn -ignore SIGHUP
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/graphite/pr83385.c
-fdiagnostics-plain-output -O1 -floop-nest-optimize -lm -o ./pr83385.exe
during GIMPLE pass: graphite
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/graphite/pr83385.c:
In function 'main':
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/graphite/pr83385.c:8:1:
internal compiler error: Segmentation fault
0xb2ed5f crash_signal
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/toplev.c:330
0x13e4afb optimize_isl
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/graphite-optimize-isl.c:151
0x13e4afb apply_poly_transforms(scop*)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/graphite-optimize-isl.c:211
0x13ded5c graphite_transform_loops()
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/graphite.c:468
0x13df820 graphite_transforms
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/graphite.c:538
0x13df820 execute
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/graphite.c:615
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/graphite/pr83385.c (internal compiler error)
FAIL: gcc.dg/graphite/pr83385.c (test for excess errors)

[Bug c++/97795] New: internal compiler error: in i386_pe_seh_unwind_emit

[vladimir.kokovic at gmail dot com via Gcc-bugs]

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

Bug ID: 97795
   Summary: internal compiler error: in i386_pe_seh_unwind_emit
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.kokovic at gmail dot com
  Target Milestone: ---

GIT_DIR=/mnt/WD-Elements-25A1/src/gcc-mirror-git/gcc/.git git describe HEAD
misc/first-auto-changelog-4144-gc283a711c85

Build a cross compiler for MinGW(gcc 10.2.0)

Executing on host:
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/stack-check-16.c   
-fdiagnostics-plain-output   -fstack-clash-protection -S -o stack-check-16.s   
(timeout = 300)
spawn -ignore SIGHUP
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/stack-check-16.c
-fdiagnostics-plain-output -fstack-clash-protection -S -o stack-check-16.s
during RTL pass: final
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/stack-check-16.c: In
function 'do_test':
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/stack-check-16.c:36:1:
internal compiler error: in i386_pe_seh_unwind_emit, at
config/i386/winnt.c:1258
0x5f6769 i386_pe_seh_unwind_emit(_IO_FILE*, rtx_insn*)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/config/i386/winnt.c:1258
0x85560a final_scan_insn_1
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:3116
0x8558bb final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:3152
0x855ba4 final_1
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:2020
0x856394 rest_of_handle_final
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:4658
0x856394 execute
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/stack-check-16.c (internal compiler error)
FAIL: gcc.dg/stack-check-16.c (test for excess errors)

Executing on host:
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/stack-check-2.c   
-fdiagnostics-plain-output   -O2 -fstack-clash-protection -fdump-tree-tailc
-fdump-tree-optimized -S -o stack-check-2.s(timeout = 300)
spawn -ignore SIGHUP
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/stack-check-2.c
-fdiagnostics-plain-output -O2 -fstack-clash-protection -fdump-tree-tailc
-fdump-tree-optimized -S -o stack-check-2.s
during RTL pass: final
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/stack-check-2.c: In
function 'test_direct_1':
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/stack-check-2.c:25:1:
internal compiler error: in seh_emit_stackalloc, at config/i386/winnt.c:1043
0x5f6575 seh_emit_stackalloc
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/config/i386/winnt.c:1043
0x5f6575 seh_emit_stackalloc
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/config/i386/winnt.c:1038
0xeb1cf8 i386_pe_seh_unwind_emit(_IO_FILE*, rtx_insn*)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/config/i386/winnt.c:1273
0x85560a final_scan_insn_1
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:3116
0x8558bb final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:3152
0x855ba4 final_1
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:2020
0x856394 rest_of_handle_final
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:4658
0x856394 execute
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/stack-check-2.c (internal compiler error)
FAIL: gcc.dg/stack-check-2.c (test for excess errors)

Executing on host:
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/stack-check-6.c   
-fdiagnostics-plain-output  -O2 -fstack-clash-protection
-fdump-rtl-pro_and_epilogue -fno-optimize-sibling-calls --param
stack-clash-protection-probe-interval=12 --param
stack-clash-protection-guard-size=12 -ffat-lto-objects -S -o 

[Bug tree-optimization/38592] Optimize memmove / memcmp combination

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2017-08-15 00:00:00 |2020-11-11

--- Comment #10 from Thomas Koenig  ---
For the C test case, we now get

yes:
.LFB0:
.cfi_startproc
movl$25977, %eax
movb$115, -1(%rsp)
movw%ax, -3(%rsp)
movzbl  -2(%rsp), %eax
subl$101, %eax
jne .L1
movzbl  -1(%rsp), %eax
subl$115, %eax
.L1:
ret

So, optimized further, but not folded.

clang 7 folds this completely:

yes:# @yes
.cfi_startproc
# %bb.0:
xorl%eax, %eax
retq
.Lfunc_end0:

[Bug tree-optimization/30398] memmove for string operations

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
This is what we generated now for

program main
  character(len=1) :: s
  character(len=2) :: c
  s = 'a'
  c = repeat(s,2)
  call foo(c)
end program main

:

;; Function main (main, funcdef_no=1, decl_uid=3926, cgraph_uid=2,
symbol_order=1) (executed once)

__attribute__((externally_visible))
main (integer(kind=4) argc, character(kind=1) * * argv)
{
  character(kind=1) c[1:2];
  static integer(kind=4) options.3[7] = {2116, 4095, 0, 1, 1, 0, 31};

   [local count: 1073741825]:
  _gfortran_set_args (argc_2(D), argv_3(D));
  _gfortran_set_options (7, [0]);
  MEM  [(c_char * {ref-all})] = 24929;
  foo (, 2);
  c ={v} {CLOBBER};
  return 0;

}

So, everything that should be optimized is now optimized.

Fixed.

[Bug c++/97794] New: internal compiler error: tree code 'ssa_name' is not supported in LTO streams

[vladimir.kokovic at gmail dot com via Gcc-bugs]

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

Bug ID: 97794
   Summary: internal compiler error: tree code 'ssa_name' is not
supported in LTO streams
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.kokovic at gmail dot com
  Target Milestone: ---

GIT_DIR=/mnt/WD-Elements-25A1/src/gcc-mirror-git/gcc/.git git describe HEAD
misc/first-auto-changelog-4144-gc283a711c85

Build a cross compiler for MinGW(gcc 10.2.0)

Executing on host:
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/atomic/pr65345-4.c  
 
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/x86_64-w64-mingw32/./libatomic/

-L/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/x86_64-w64-mingw32/./libatomic/.libs
-latomic  -fdiagnostics-plain-output-O2 -flto -fno-use-linker-plugin
-flto-partition=none   -S -o pr65345-4.s(timeout = 300)
spawn -ignore SIGHUP
/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/xgcc
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/gcc/
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/atomic/pr65345-4.c
-B/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/x86_64-w64-mingw32/./libatomic/
-L/mnt/WD-Elements-25A1/src/gcc-mirror-git/mingw-objdir/x86_64-w64-mingw32/./libatomic/.libs
-latomic -fdiagnostics-plain-output -O2 -flto -fno-use-linker-plugin
-flto-partition=none -S -o pr65345-4.s
during IPA pass: modref
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/atomic/pr65345-4.c:58:1:
internal compiler error: tree code 'ssa_name' is not supported in LTO streams
0x9ee43b lto_write_tree
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:554
0x9ee43b lto_output_tree_1
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:592
0x9f51a4 DFS::DFS(output_block*, tree_node*, bool, bool, bool)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:892
0x9f5fbb lto_output_tree(output_block*, tree_node*, bool, bool)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:1853
0x9ede61 write_global_stream
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:2847
0x9f8906 lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:2894
0x9f8906 produce_asm_for_decls()
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:3288
0xa6ae9a write_lto
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/passes.c:2680
0xa6ae9a ipa_write_summaries_1
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/passes.c:2741
0xa6ae9a ipa_write_summaries()
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/passes.c:2797
0x77275b ipa_passes
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/cgraphunit.c:2207
0x77275b symbol_table::compile()
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/cgraphunit.c:2294
0x7749c7 symbol_table::compile()
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/cgraphunit.c:2274
0x7749c7 symbol_table::finalize_compilation_unit()
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/cgraphunit.c:2542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
Excess errors:
during IPA pass: modref
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/testsuite/gcc.dg/atomic/pr65345-4.c:58:1:
internal compiler error: tree code 'ssa_name' is not supported in LTO streams
0x9ee43b lto_write_tree
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:554
0x9ee43b lto_output_tree_1
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:592
0x9f51a4 DFS::DFS(output_block*, tree_node*, bool, bool, bool)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:892
0x9f5fbb lto_output_tree(output_block*, tree_node*, bool, bool)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:1853
0x9ede61 write_global_stream
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:2847
0x9f8906 lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:2894
0x9f8906 produce_asm_for_decls()
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/lto-streamer-out.c:3288
0xa6ae9a write_lto
/mnt/sdd1/home/src/gcc-mirror-git/gcc/gcc/passes.c:2680
0xa6ae9a ipa_write_summaries_1

[Bug tree-optimization/21046] move memory allocation out of a loop

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2014-12-25 00:00:00 |2020-11-11

--- Comment #6 from Thomas Koenig  ---
Just thought to see if this has been fixed in the meantime;
it's not optimized with current trunk.

[Bug c/97793] New: Bogus return-type warning

[schwab--- via Gcc-bugs]

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

Bug ID: 97793
   Summary: Bogus return-type warning
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---

Created attachment 49545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49545=edit
test-nl_langinfo-mt.i

$ gcc -Werror=return-type -S test-nl_langinfo-mt.i
test-nl_langinfo-mt.i: In function ‘threadN_func’:
test-nl_langinfo-mt.i:6268:1: error: no return statement in function returning
non-void [-Werror=return-type]
 }
 ^
cc1: some warnings being treated as errors

[Bug target/97784] Expressions evaluated as long chain instead of as tree or the like

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

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

--- Comment #5 from Richard Biener  ---
Created attachment 49544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49544=edit
patch doing -fwrapv late

One piece of the approach would move reassoc after the last VRP pass:

diff --git a/gcc/passes.def b/gcc/passes.def
index c68231287b6..872511442f1 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -317,7 +317,6 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_lower_vector_ssa);
   NEXT_PASS (pass_lower_switch);
   NEXT_PASS (pass_cse_reciprocals);
-  NEXT_PASS (pass_reassoc, false /* insert_powi_p */);
   NEXT_PASS (pass_strength_reduction);
   NEXT_PASS (pass_split_paths);
   NEXT_PASS (pass_tracer);
@@ -332,6 +331,8 @@ along with GCC; see the file COPYING3.  If not see
   /* Threading can leave many const/copy propagations in the IL.
 Clean them up.  */
   NEXT_PASS (pass_copy_prop);
+  NEXT_PASS (pass_reassoc, false /* insert_powi_p */);
   NEXT_PASS (pass_warn_restrict);
   NEXT_PASS (pass_dse);
   NEXT_PASS (pass_cd_dce);

that seems to at least regress

FAIL: gcc.dg/tree-ssa/pr96480.c scan-tree-dump optimized " = _[0-9]* <= 3;"

maybe also some Wstringop-overflow.c diagnostics.

Now, altering a flag is a bit awkward since we have to restore it somewhere
as 'flag_wrapv' is global state also affecting other functions not yet in
late state.  A cleaner approach would be to move flag_wrapv (& friends)
to struct function fully (and change all users) much like we did for
can_throw_non_call_exceptions & flag_non_call_exceptions.  Maybe it's not
too bad (not so many users of flag_wrapv), but well - have coded the "ugly"
variant here.

We also can't alter flag_wrapv in case flag_trapv is set, obviously.

It might be interesting to do some more pass shuffling here, eventually
moving VRP a bit earlier.  We're doing a bit much threading and CSE late
nowadays.  It's also not entirely clear what late passes actually benefit
from undefined overflow (besides VRP, that is).

Bootstrapped / tested on x86_64-unknown-linux-gnu.

FAIL: gcc.dg/pr64434.c scan-rtl-dump-times expand "Swap operands" 1
FAIL: gcc.dg/tree-ssa/phi-opt-15.c scan-tree-dump-not optimized "ABS"
FAIL: gcc.dg/tree-ssa/pr44133.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/pr92712-3.c scan-tree-dump-not optimized " =
[tv]_[0-9]*(D) * [tv]_[0-9]*(D);"
FAIL: gcc.dg/tree-ssa/pr96480.c scan-tree-dump optimized " = _[0-9]* <= 3;"
XPASS: gcc.dg/tree-ssa/reassoc-2.c scan-tree-dump-times optimized "return 0" 1
FAIL: gcc.dg/tree-ssa/slsr-10.c scan-tree-dump-times optimized " * " 1
FAIL: gcc.dg/tree-ssa/slsr-11.c scan-tree-dump-times optimized " * " 1
FAIL: gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times optimized " * 4" 2
FAIL: gcc.dg/tree-ssa/slsr-20.c scan-tree-dump-times optimized " * s" 1
FAIL: gcc.dg/tree-ssa/slsr-31.c scan-tree-dump-times optimized " * 2" 1
FAIL: gcc.dg/tree-ssa/slsr-32.c scan-tree-dump-times optimized " * 2" 1
FAIL: gcc.dg/tree-ssa/slsr-33.c scan-tree-dump-times optimized " * " 1
FAIL: gcc.dg/tree-ssa/slsr-34.c scan-tree-dump-times optimized " * " 1
FAIL: gcc.dg/tree-ssa/slsr-37.c scan-tree-dump-times optimized " * 2" 1
FAIL: gcc.dg/tree-ssa/slsr-38.c scan-tree-dump-times optimized " * " 1
FAIL: gcc.dg/tree-ssa/slsr-5.c scan-tree-dump-times optimized " * " 1
FAIL: gcc.dg/tree-ssa/slsr-7.c scan-tree-dump-times optimized " * " 1
FAIL: gcc.dg/tree-ssa/slsr-9.c scan-tree-dump-times optimized " * " 1

[Bug tree-optimization/97789] valgrind error with ./gcc.dg/c11-atomic-2.c

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

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

--- Comment #7 from Martin Liška  ---
(In reply to David Binderman from comment #6)
> (In reply to Martin Liška from comment #5)
> > Nice. Next time, please mention the exact revision you use.
> 
> Will do, although I suspect mentioning 20201107 in the compiler name
> was a small clue.

Yep, but it's still quite a lot revisions.

> 
> For more precision, I will have a look at embedding the git revision hash
> into the gcc build. Maybe something like
> 
> $ git rev-parse HEAD >> gcc/trunk.git/gcc/DATESTAMP

Yes, please do so.

> 
> would be enough to get it into the output of gcc -v.
> 
> > Thanks for it!
> 
> You are welcome.

[Bug tree-optimization/97789] valgrind error with ./gcc.dg/c11-atomic-2.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to Martin Liška from comment #5)
> Nice. Next time, please mention the exact revision you use.

Will do, although I suspect mentioning 20201107 in the compiler name
was a small clue.

For more precision, I will have a look at embedding the git revision hash
into the gcc build. Maybe something like

$ git rev-parse HEAD >> gcc/trunk.git/gcc/DATESTAMP

would be enough to get it into the output of gcc -v.

> Thanks for it!

You are welcome.

[Bug tree-optimization/97789] valgrind error with ./gcc.dg/c11-atomic-2.c

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

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

--- Comment #5 from Martin Liška  ---
(In reply to David Binderman from comment #4)
> (In reply to Martin Liška from comment #3)
> > I can't reproduce that.
> 
> Presumably you mean on today's compiler ?

Yes.

> 
> Richard's change of Monday 9 November seemingly fixes it.
> I'll check this on next Friday's valgrind build.

Nice. Next time, please mention the exact revision you use.
Thanks for it!

[Bug tree-optimization/97789] valgrind error with ./gcc.dg/c11-atomic-2.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to Martin Liška from comment #3)
> I can't reproduce that.

Presumably you mean on today's compiler ?

Richard's change of Monday 9 November seemingly fixes it.
I'll check this on next Friday's valgrind build.

[Bug tree-optimization/97789] valgrind error with ./gcc.dg/c11-atomic-2.c

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
I can't reproduce that.

[Bug tree-optimization/97789] valgrind error with ./gcc.dg/c11-atomic-2.c

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
So I can't see the error, assuming fixed.