[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Ville Voutilainen  ---
..or maybe I'm just too dumb to invoke g++ -E properly, and the rest of the
options confuse the compiler.

[Bug tree-optimization/98630] Seg-fault when using a goto after condition (if)

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
 Ever confirmed|0   |1
  Known to fail||11.0
   Keywords||wrong-code
   Last reconfirmed||2021-01-12
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed with -O1 on trunk.  We're losing the m initialization.

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

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

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

--- Comment #8 from Martin Liška  ---
(In reply to Andrea Corallo from comment #7)
> Thanks Martin, I can confirm that also the bootstrap is back okay.

You're welcome.
Can you please point me to Emacs JIt usage? I'm curious what for is libgccjit
used in the project?

[Bug tree-optimization/98630] Seg-fault when using a goto after condition (if)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Vanishes in CCP - I'll see what happens.

[Bug tree-optimization/98630] Seg-fault when using a goto after condition (if)

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Richard Biener  ---
OK, so the issue is that 'm' goes out of scope before the goto p; and this
goto skips the initialization.  This means this is an invalid testcase unless
somehow C makes this well-defined.

[Bug c/98630] Seg-fault when using a goto after condition (if)

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
  Component|tree-optimization   |c
 Resolution|INVALID |---
   Keywords|wrong-code  |diagnostic

--- Comment #4 from Richard Biener  ---
And -Wall says correctly

t.c: In function ‘j’:
t.c:16:14: warning: ‘m’ is used uninitialized [-Wuninitialized]
   16 | ***o = 0;
  | ~^~~

but we fail to diagnose that the goto crosses the initialization.  Re-opening
for that to improve.

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Ville Voutilainen  ---
Created attachment 49943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49943&action=edit
Output of gcc -E

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

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

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

--- Comment #14 from Przemyslaw Wirkus  ---
Hi Vladimir,

I'm assigned to the issue and I'm working on it. I think I got the root cause.
I'm in the process of creating a patch after I complete few tests.

kind regards
Przemyslaw

[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
> ```c++
> struct QQmlRefCount {
>   void release() const;
>   virtual ~QQmlRefCount();
> };
> QQmlRefCount::~QQmlRefCount() {}
> void QQmlRefCount::release() const { delete this; }
> struct QQmlJavaScriptExpression {
>   virtual int sourceLocation();
> };
> struct QQmlBoundSignalExpression : QQmlJavaScriptExpression, QQmlRefCount {};
> struct QQmlProfilerDefinitions {
>   enum RangeType { HandlingSignal };
> };
> struct QQmlProfiler : QQmlProfilerDefinitions {
>   struct RefLocation {
> RefLocation() {
>   switch (locationType)
>   case HandlingSignal:
> boundSignal->release();
> }
> RangeType locationType;
> QQmlBoundSignalExpression *boundSignal;
>   };
>   void startCompiling() { RefLocation(); }
> };
> struct QQmlCompilingProfiler {
>   QQmlProfiler QQmlCompilingProfiler_profiler;
>   QQmlCompilingProfiler(int *) {
> QQmlCompilingProfiler_profiler.startCompiling();
>   }
> };
> int notifyComplete_blob;
> void QQmlDataBlobnotifyComplete() {
>   QQmlCompilingProfiler prof(¬ifyComplete_blob);
> }
> ```
> 

This also started with r11-6508-gabb1b6058c09a7c0.

@Martin: Can you please take a look?

[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

--- Comment #3 from Andreas Krebbel  ---
Created attachment 49944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49944&action=edit
Reduced testcase

This testcase fails on bcb3065b2ba with
cc1plus t.cpp -march=z13 -O3

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

--- Comment #4 from Andreas Krebbel  ---
The problem occurs starting with:

commit 1e1e1edf88a7c40ae4ae0de9e6077179e13ccf6d
Author: Richard Biener 
Date:   Thu Oct 29 08:48:15 2020 +0100

More BB vectorization tweaks

This tweaks the op build from splats to allow loads marked as not
vectorizable.  It also amends some dump prints with the address of
the SLP node or the instance to better be able to debug things.

2020-10-29  Richard Biener  

* tree-vect-slp.c (vect_build_slp_tree_2): Allow splatting
not vectorizable loads.
(vect_build_slp_instance): Amend dumping with address.
(vect_slp_convert_to_external): Likewise.

* gcc.dg/vect/bb-slp-pr65935.c: Adjust.

[Bug c/98630] Seg-fault when using a goto after condition (if)

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

--- Comment #5 from Karine EM  ---
This is an automatically reduced program. If GCC will give the Wuninitialized
warning I can reduce the original program again, taking it into account. 

I attached the long program in case you find it helpful. It also ends with
Seg-Fault for gcc-10 but not with gcc-7, gcc-8, gcc-9 for example. G++-10
doesn't give uninitialized warning on the long program.

[Bug c/98630] Seg-fault when using a goto after condition (if)

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

--- Comment #6 from Karine EM  ---
Created attachment 49945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49945&action=edit
Original large code that caused Seg-fault in GCC-10

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Andreas Krebbel  ---
With the patch the sign extension of 6 shift count operands from int to long
int is now marked as vect_external_def. This makes the vectype field in the slp
node to be bumped from "vector 2 int" to a "vector 4 int" in:
vectorizable_conversion->vect_maybe_update_slp_op_vectype

This then triggers the ICE when trying to divide vf*group_size (which is 1*6
here) by the number of elements in the vector type (now 4) in
vect_slp_analyze_node_operations.

Is changing the vectype field of an slp node to a type with a different number
of elements actually valid?


slp1:


  bb$dh_5 = D.4123.dh;
  _10 = MEM[(int *)bb$dh_5];
  pretmp_62 = a.cp[1];
  pretmp_79 = a.cp[2];
  pretmp_31 = a.cp[3];
  pretmp_39 = a.cp[4];
  pretmp_16 = a.cp[5];
  pretmp_19 = a.cp[6];
  goto ; [100.00%]

   [local count: 1014686041]:
  _20 = prephitmp_78 >> _10;
  a.cp[1] = _20;
  _22 = prephitmp_80 >> _10;
  a.cp[2] = _22;
  _24 = prephitmp_32 >> _10;
  a.cp[3] = _24;
  _26 = prephitmp_40 >> _10;
  a.cp[4] = _26;
  _28 = prephitmp_17 >> _10;
  a.cp[5] = _28;
  _30 = prephitmp_11 >> _10;
  a.cp[6] = _30;
  cn ={v} {CLOBBER};

[Bug other/89701] Provide -fcf-protection=branch,return

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
(In reply to Marek Polacek from comment #1)
> Confirmed.  While we support -fcf-protection=branch and
> -fcf-protection=return,
> -fcf-protection=branch,return gives an error:
> 
> xgcc: error: unknown Control-Flow Protection Level ‘branch,return’
> xgcc: note: valid arguments to ‘-fcf-protection=’ are: branch check full
> none retur

We can add a new EnumValue with string (branch,return) and value ({(enum
cf_protection_level) (CF_BRANCH | CF_RETURN)}) for this specific case,  but the
implementation is too cumbersome considering the many permutations possible.

Another way is adding parser_cf_protection_options, called in
parse_sanitizer_options, decoding the string value and set corresponding bit in
flag_cf_protection.

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

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

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

--- Comment #5 from Martin Liška  ---
Still can't reproduce it.
Please send me also output of --verbose.

Re: [Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[Andrea Corallo via Gcc-bugs]

"marxin at gcc dot gnu.org via Gcc-bugs"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615
>
> --- Comment #8 from Martin Liška  ---
> (In reply to Andrea Corallo from comment #7)
>> Thanks Martin, I can confirm that also the bootstrap is back okay.
>
> You're welcome.
> Can you please point me to Emacs JIt usage? I'm curious what for is libgccjit
> used in the project?

That's a feature branch that being integrated as is planed to have it in
for 28.

Essentially we use it to compile .el files into shared libraries we then
load to have Elisp executed as native code.

Here is the recording for my presentation at LPC2020/Cauldron:


and this is my development blog:
.

  Andrea

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[andrea.corallo at arm dot com via Gcc-bugs]

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

--- Comment #9 from Andrea Corallo  ---
"marxin at gcc dot gnu.org via Gcc-bugs"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615
>
> --- Comment #8 from Martin Liška  ---
> (In reply to Andrea Corallo from comment #7)
>> Thanks Martin, I can confirm that also the bootstrap is back okay.
>
> You're welcome.
> Can you please point me to Emacs JIt usage? I'm curious what for is libgccjit
> used in the project?

That's a feature branch that being integrated as is planed to have it in
for 28.

Essentially we use it to compile .el files into shared libraries we then
load to have Elisp executed as native code.

Here is the recording for my presentation at LPC2020/Cauldron:


and this is my development blog:
.

  Andrea

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Ville Voutilainen  ---
Created attachment 49946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49946&action=edit
Output of --verbose

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Ville Voutilainen  ---
(In reply to Martin Liška from comment #5)
> Still can't reproduce it.
> Please send me also output of --verbose.

Yeah, I fed that output to g++, and then it compiles just fine. But when it's
in the actual build with all the -MD -MT -MF flags, it doesn't. Those are, btw,
in case it's of any help,
-MD -MT qtbase/qmake/CMakeFiles/qmake.dir/__/src/corelib/global/qendian.cpp.o
-MF qtbase/qmake/CMakeFiles/qmake.dir/__/src/corelib/global/qendian.cpp.o.d -o
qtbase/qmake/CMakeFiles/qmake.dir/__/src/corelib/global/qendian.cpp.o

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Ville Voutilainen  ---
Also, you can just try the actual build, if you follow
https://wiki.qt.io/Building_Qt_6_from_Git

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

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

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

--- Comment #9 from Martin Liška  ---
(In reply to Ville Voutilainen from comment #8)
> Also, you can just try the actual build, if you follow
> https://wiki.qt.io/Building_Qt_6_from_Git

I tried, but it fails quite fast with:

/home/marxin/bin/gcc/bin/c++ -DHAVE_CONFIG_H -DPCRE2_CODE_UNIT_WIDTH=16
-DPCRE2_DISABLE_JIT -DQT_BOOTSTRAPPED -DQT_NO_CAST_FROM_ASCII
-DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_USE_QSTRINGBUILDER
-DQT_VERSION_MAJOR=6 -DQT_VERSION_MINOR=0 -DQT_VERSION_PATCH=1
-DQT_VERSION_STR=\"6.0.1\" -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
-I../qtbase/src/tools/bootstrap/../../3rdparty/pcre2/src
-Iqtbase/src/corelib/Core_autogen/include -Iqtbase/include
-Iqtbase/include/QtCore -I../qtbase/src/corelib -Iqtbase/src/corelib
-Iqtbase/src/corelib/global -I../qtbase/src/corelib/../3rdparty/tinycbor/src
-Iqtbase/include/QtCore/6.0.1 -Iqtbase/include/QtCore/6.0.1/QtCore
-I../qtbase/src/corelib/../3rdparty/forkfd -Iqtbase/src/corelib/.rcc
-I../qtbase/mkspecs/linux-g++ -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -Iqtbase/src/xml/Xml_autogen/include
-Iqtbase/include/QtXml -I../qtbase/src/xml -Iqtbase/src/xml
-Iqtbase/include/QtXml/6.0.1 -Iqtbase/include/QtXml/6.0.1/QtXml
-I../qtbase/src/tools/bootstrap/..
-I../qtbase/src/tools/bootstrap/../../3rdparty/tinycbor/src -DNDEBUG -O2 -fPIC
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra
-ffunction-sections -fdata-sections -Wsuggest-override -std=gnu++17 -MD -MT
qtbase/src/tools/bootstrap/CMakeFiles/Bootstrap.dir/__/__/corelib/global/qfloat16.cpp.o
-MF
qtbase/src/tools/bootstrap/CMakeFiles/Bootstrap.dir/__/__/corelib/global/qfloat16.cpp.o.d
-o
qtbase/src/tools/bootstrap/CMakeFiles/Bootstrap.dir/__/__/corelib/global/qfloat16.cpp.o
-c ../qtbase/src/corelib/global/qfloat16.cpp
In file included from qtbase/include/QtCore/qanystringview.h:1,
 from
qtbase/include/QtCore/../../../../qtbase/src/corelib/text/qstring.h:56,
 from qtbase/include/QtCore/qstring.h:1,
 from
qtbase/include/QtCore/../../../../qtbase/src/corelib/tools/qhashfunctions.h:44,
 from qtbase/include/QtCore/qhashfunctions.h:1,
 from
qtbase/include/QtCore/../../../../qtbase/src/corelib/tools/qvarlengtharray.h:47,
 from qtbase/include/QtCore/qvarlengtharray.h:1,
 from
qtbase/include/QtCore/../../../../qtbase/src/corelib/kernel/qmetatype.h:49,
 from qtbase/include/QtCore/qmetatype.h:1,
 from ../qtbase/src/corelib/global/qfloat16.h:45,
 from ../qtbase/src/corelib/global/qfloat16.cpp:41:
qtbase/include/QtCore/../../../../qtbase/src/corelib/text/qanystringview.h:250:46:
error: ‘numeric_limits’ is not a member of ‘std’
  250 | static constexpr size_t SizeMask =
(std::numeric_limits::max)() / 4;
  |  ^~
qtbase/include/QtCore/../../../../qtbase/src/corelib/text/qanystringview.h:250:67:
error: expected primary-expression before ‘>’ token
  250 | static constexpr size_t SizeMask =
(std::numeric_limits::max)() / 4;
  |   ^
qtbase/include/QtCore/../../../../qtbase/src/corelib/text/qanystringview.h:250:70:
error: ‘::max’ has not been declared; did you mean ‘std::max’?
  250 | static constexpr size_t SizeMask =
(std::numeric_limits::max)() / 4;
  | 
^~~
  | 
std::max
In file included from /home/marxin/bin/gcc/include/c++/11.0.0/algorithm:62,
 from
qtbase/include/QtCore/../../../../qtbase/src/corelib/global/qglobal.h:126,
 from qtbase/include/QtCore/qglobal.h:1,
 from ../qtbase/src/corelib/global/qfloat16.h:44,
 from ../qtbase/src/corelib/global/qfloat16.cpp:41:
/home/marxin/bin/gcc/include/c++/11.0.0/bits/stl_algo.h:3467:5: note:
‘std::max’ declared here
 3467 | max(initializer_list<_Tp> __l, _Compare __comp)
  | ^~~
In file included from qtbase/include/QtCore/qanystringview.h:1,
 from
qtbase/include/QtCore/../../../../qtbase/src/corelib/text/qstring.h:56,
 from qtbase/include/QtCore/qstring.h:1,
 from
qtbase/include/QtCore/../../../../qtbase/src/corelib/tools/qhashfunctions.h:44,
 from qtbase/include/QtCore/qhashfunctions.h:1,
 from
qtbase/include/QtCore/../../../../qtbase/src/corelib/tools/qvarlengtharray.h:47,
 from qtbase/include/QtCore/qvarlengtharray.h:1,
 from
qtbase/include/QtCore/../../../../qtbase/src/corelib/kernel/qmetatype.h:49,
 from qtbase/include/QtCore/qmetatype.h:1,
 from ../qtbase/src/corelib/global/qfloat16.h:45,
 from ../qtbase/src/corelib/global

[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library

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

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

--- Comment #4 from Martin Liška  ---
Created attachment 49947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49947&action=edit
Reduced test-case

I reduced a test-case where GCC 10 does not inline all in fn called
'should_inline'.

[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug tree-optimization/98221] [10 regression] Wrong unpack operation emitted in tree-ssa-forwprop.c

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

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

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

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

commit r10-9253-gecab0d9106a317073f5891f161f031078d835b2f
Author: Andreas Krebbel 
Date:   Mon Jan 11 10:59:43 2021 +0100

tree-optimization/98221 - fix wrong unpack operation used for big-endian

The vec-abi-varargs-1.c testcase on IBM Z currently fails.

While adding an SI mode vector to a DI mode vector the first is unpacked
using:

  _28 = BIT_INSERT_EXPR <{ 0, 0, 0, 0 }, _2, 0>;
  _34 = [vec_unpack_lo_expr] _28;

However, on big endian targets lo refers to the right hand side of the
vector - in this case the zeroes.

2021-01-11  Andreas Krebbel  

PR tree-optimization/98221
* tree-ssa-forwprop.c (simplify_vector_constructor): For
big-endian, use UNPACK[_FLOAT]_HI.

(cherry picked from commit 300a3ce5c5695eb1a7c0476e9d1b45420a463248)

[Bug tree-optimization/98221] [10 regression] Wrong unpack operation emitted in tree-ssa-forwprop.c

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.2.1
  Known to fail||10.2.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug other/89701] Provide -fcf-protection=branch,return

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> (In reply to Marek Polacek from comment #1)
> > Confirmed.  While we support -fcf-protection=branch and
> > -fcf-protection=return,
> > -fcf-protection=branch,return gives an error:
> > 
> > xgcc: error: unknown Control-Flow Protection Level ‘branch,return’
> > xgcc: note: valid arguments to ‘-fcf-protection=’ are: branch check full
> > none retur
> 
> We can add a new EnumValue with string (branch,return) and value ({(enum
> cf_protection_level) (CF_BRANCH | CF_RETURN)}) for this specific case,  but
> the implementation is too cumbersome considering the many permutations
> possible.
> 
> Another way is adding parser_cf_protection_options, called in
> parse_sanitizer_options, decoding the string value and set corresponding bit
> in flag_cf_protection.

called in common_handle_option

[Bug target/89057] [8/9 Regression] AArch64 ld3 st4 less optimized

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] AArch64 |[8/9 Regression] AArch64
   |ld3 st4 less optimized  |ld3 st4 less optimized

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
Fixed for GCC 10 by r10-9255.

[Bug tree-optimization/98371] [10 Regression] gcc.dg/torture/pr69719.c fails for fixed-length 128-bit SVE

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Fixed for GCC 10 by r10-9256.

[Bug target/98302] [9 Regression] Wrong code on aarch64

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[9/10 Regression] Wrong |[9 Regression] Wrong code
   |code on aarch64 |on aarch64

--- Comment #17 from rsandifo at gcc dot gnu.org  
---
Fixed for GCC 10 by r10-9257.

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #12 from Alex Coplan  ---
Fixed.

[Bug target/98214] [10 Regression] SVE: Wrong code with -O3 -msve-vector-bits=512

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Fixed for GCC 10 by r10-9258.

[Bug target/97144] [10 Regression] SVE: ICE (could not split insn) in final_scan_insn_1 since r10-2553-g0fdc30bcf56

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed for GCC 10 by r10-9259.

[Bug tree-optimization/95731] Failure to optimize a >= 0 && b >= 0 to (a | b) >= 0

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:13d47c37a2c043f3e5981e73e4c82158a39f41e8

commit r11-6609-g13d47c37a2c043f3e5981e73e4c82158a39f41e8
Author: Jakub Jelinek 
Date:   Tue Jan 12 11:03:40 2021 +0100

reassoc: Optimize in reassoc x < 0 && y < 0 to (x | y) < 0 etc. [PR95731]

We already had x != 0 && y != 0 to (x | y) != 0 and
x != -1 && y != -1 to (x & y) != -1 and
x < 32U && y < 32U to (x | y) < 32U, this patch adds signed
x < 0 && y < 0 to (x | y) < 0.  In that case, the low/high seem to be
always the same and just in_p indices whether it is >= 0 or < 0,
also, all types in the same bucket (same precision) should be type
compatible, but we can have some >= 0 and some < 0 comparison mixed,
so the patch handles that by using the right BIT_IOR_EXPR or BIT_AND_EXPR
and doing one set of < 0 or >= 0 first, then BIT_NOT_EXPR and then the
other
one.  I had to move optimize_range_tests_var_bound before this optimization
because that one deals with signed a >= 0 && a < b, and limited it to the
last reassoc pass as reassoc itself can't virtually undo this optimization
yet (and not sure if vrp would be able to).

2021-01-12  Jakub Jelinek  

PR tree-optimization/95731
* tree-ssa-reassoc.c (optimize_range_tests_cmp_bitwise): Also
optimize
x < 0 && y < 0 && z < 0 into (x | y | z) < 0 for signed x, y, z.
(optimize_range_tests): Call optimize_range_tests_cmp_bitwise
only after optimize_range_tests_var_bound.

* gcc.dg/tree-ssa/pr95731.c: New test.
* gcc.c-torture/execute/pr95731.c: New test.

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

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:24ea113f75cfad38894dc1ad16b23c0538ef17d4

commit r11-6610-g24ea113f75cfad38894dc1ad16b23c0538ef17d4
Author: Jakub Jelinek 
Date:   Tue Jan 12 11:04:46 2021 +0100

widening_mul: Fix up ICE caused by my signed multiplication overflow
pattern recognition changes [PR98629]

As the testcase shows, my latest changes caused ICE on that testcase.
The problem is that arith_overflow_check_p now can change the use_stmt
argument (has a reference), so that if it succeeds (returns non-zero),
it points it to the GIMPLE_COND or EQ/NE or COND_EXPR assignment from the
TRUNC_DIV_EXPR assignment.
The problem was that it would change use_stmt also if it returned 0 in some
cases, such as multiple imm uses of the division, and in one of the callers
if arith_overflow_check_p returns 0 it looks at use_stmt again and performs
other checks, which of course assumes that use_stmt is the one passed
to arith_overflow_check_p and not e.g. NULL instead or some other unrelated
stmt.

The following patch fixes that by only changing use_stmt when we are about
to return non-zero (for the MULT_EXPR case, which is the only one with the
need to use different use_stmt).

2021-01-12  Jakub Jelinek  

PR tree-optimization/98629
* tree-ssa-math-opts.c (arith_overflow_check_p): Don't update
use_stmt
unless returning non-zero.

* gcc.c-torture/compile/pr98629.c: New test.

[Bug tree-optimization/95401] [10 Regression] GCC produces incorrect instruction with -O3 for AVX2 since r10-2257-g868363d4f52df19d

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Fixed for GCC 10 by r10-9260.

[Bug middle-end/94994] [10 Regression] possible miscompilation of word-at-a-time copy via packed structs

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Fixed for GCC 10 by r10-9261.

[Bug c/98630] Seg-fault when using a goto after condition (if)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
(In reply to Karine EM from comment #6)
> Created attachment 49945 [details]
> Original large code that caused Seg-fault in GCC-10

Can you please preprocess this (so that it doesn't contain csmith.h include)?
Thanks.

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
So it changes the type from NULL to v4si and the conversion node is

t.ii:87:6: note: node 0x30b4080 (max_nunits=4, refcnt=1)
t.ii:87:6: note: op template: patt_41 = (long int) _10;
t.ii:87:6: note:stmt 0 patt_41 = (long int) _10;
t.ii:87:6: note:stmt 1 patt_47 = (long int) _10;
t.ii:87:6: note:stmt 2 patt_53 = (long int) _10;
t.ii:87:6: note:stmt 3 patt_18 = (long int) _10;
t.ii:87:6: note:children 0x30b4100
$15 = void

already anticipating max_nunits == 4.  The problematic node is

t.ii:87:6: note: node 0x30b3d80 (max_nunits=4, refcnt=1)
t.ii:87:6: note: op template: patt_41 = (long int) _10;
t.ii:87:6: note:stmt 0 patt_41 = (long int) _10;
t.ii:87:6: note:stmt 1 patt_47 = (long int) _10;
t.ii:87:6: note:stmt 2 patt_53 = (long int) _10;
t.ii:87:6: note:stmt 3 patt_18 = (long int) _10;
t.ii:87:6: note:stmt 4 patt_23 = (long int) _10;
t.ii:87:6: note:stmt 5 patt_27 = (long int) _10;
t.ii:87:6: note:children 0x30b3e00

where the issue is that we fail to reject this for BB vectorization because
it would need unrolling.  Looks like the test in vect_record_max_nunits
isn't catching this case:

  /* If populating the vector type requires unrolling then fail
 before adjusting *max_nunits for basic-block vectorization.  */
  poly_uint64 nunits = TYPE_VECTOR_SUBPARTS (vectype);
  unsigned HOST_WIDE_INT const_nunits;
  if (is_a  (vinfo)
  && (!nunits.is_constant (&const_nunits)
  || const_nunits > group_size))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "Build SLP failed: unrolling required "
 "in basic block SLP\n");
  /* Fatal mismatch.  */
  return false;
}

I guess it should be a !multiple_p (group_size, nunits) check instead?

[Bug c++/98632] New: Warn about unspecified expression ordering for atomics with non-relaxed memory ordering.

[tilps at hotmail dot com via Gcc-bugs]

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

Bug ID: 98632
   Summary: Warn about unspecified expression ordering for atomics
with non-relaxed memory ordering.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tilps at hotmail dot com
  Target Milestone: ---

C++ defines that execution ordering for expressions is largely unspecified.  In
cases where there are multiple atomic operations in an expression for which
there is no standard required ordering, and if those atomic operations are
marked with a non-relaxed memory ordering, it would be useful to have a
warning. Since the compiler is technically free to reorder them in-spite of the
memory ordering indicating that the user cares about the specific ordering.

While it might be able to be argued that the warning should fire for any
expression involving just a single atomic and some other expression component
that would be unable to be reordered if the sub-expressions had been assigned
to locals first, it seems that would be likely to have vastly more false
positives than expressions that involve multiple atomic operations. So I would
suggest only triggering for expressions involving multiple atomic operations.

[Bug c/98630] Seg-fault when using a goto after condition (if)

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

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

--- Comment #8 from Jakub Jelinek  ---
For goto crossing initialization, C++ makes it a hard error and C only has a
non-default warning (not even in -W), -Wjump-misses-init included in
-Wc++-compat.
As can be seen on:
int
foo (void)
{
  goto a;
  int b = 1;
a:
  b++;
  return b;
}

int
bar (void)
{
  goto a;
  {
int b = 1;
  a:
b++;
return b;
  }
}

int
baz (void)
{
  {
int b = 1;
if (1)
  ;
else
  {
  a:
b++;
return b;
  }
  }
  goto a;
}

with g++ or gcc -Wjump-misses-init

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

--- Comment #7 from Richard Biener  ---
Created attachment 49948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49948&action=edit
patch

untested patch

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #6)
> I guess it should be a !multiple_p (group_size, nunits) check instead?
Sounds plausible :-)

[Bug tree-optimization/95034] Failure to convert xor pattern (made out of or+and) to xor

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For
int
combine (int a, int b)
{
  return (a | b) & ~(a & b);
}
we do optimize it, for the ||s and &&s the problem is that it is split accross
multiple basic blocks, so match.pd is out of the picture, but on the other side
reassoc which can handle conditions split across multiple bbs will handle only
a single truth operation (so the && in this case) and so we'd need to look
through the |s from there manually.

Ah, an option could be to add some truth_{and,ior,*} rules in match.pd, limited
to GENERIC probably, as it won't trigger afterwards.
But of course that would handle only the above testcase and not e.g.
bool t1 = a || b;
bool t2 = !(a && b);
return t1 && t2;
etc.

Richard, any ideas?

[Bug c/98630] Seg-fault when using a goto after condition (if)

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

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

--- Comment #9 from Richard Biener  ---
Given we now place CLOBBERS at scope ends even for C code (which is why we
"miscompile" the reduced testcase) doesn't it make sense to at least include
-Wjump-misses-init into -W[extra] or even -Wall?

[Bug bootstrap/98633] New: Bootstrap comparison failure, libcody/fatal.o differs

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

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

Bug ID: 98633
   Summary: Bootstrap comparison failure, libcody/fatal.o differs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49949&action=edit
objects

I sometimes (now second time) get a bootstrap comparison failure on
libcody/fatal.o doing a bootstrap on x86_64-unknown-linux-gnu with
just ./configure; make -j24 STAGE1_CFLAGS="-O2"

Attached the miscomparing objects.

[Bug c/98630] Seg-fault when using a goto after condition (if)

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

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

--- Comment #10 from Jakub Jelinek  ---
Maybe, but I think it is too late to do it now for GCC 11, it will take time
before we figure out how many projects will be affected by that.

[Bug c/98630] Seg-fault when using a goto after condition (if)

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

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

--- Comment #11 from Jakub Jelinek  ---
The reason why C++ has it as hard error is I think object
construction/destruction, in C the warning is for code to be portable to C++,
in plain C it is all about making sure variables are initialized, which users
can do correctly even if they cross variable initialization.
So in C there is nothing wrong per se on the crossing, just the warning can
help if -Wuninitialized or -Wmaybe-uninitialized has false negatives as in this
case.

[Bug bootstrap/98633] Bootstrap comparison failure, libcody/fatal.o differs

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

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

--- Comment #1 from Richard Biener  ---
Hmm.  I see in libcody/Makefile.in

revision.stamp: $(addprefix $(srcdir)/,. $(SUBDIRS))
@revision=$$(git -C $(srcdir) rev-parse HEAD 2>/dev/null) ;\
if test -n "$$revision" ;\
then revision=git-$$revision ;\
  if git -C $(srcdir) status --porcelain 2>/dev/null | grep -vq '^  '
;\
  then revision+=M ;\
  fi ;\
else revision=unknown ;\
fi ;\
echo $$revision > $@

and when this happened to me I was committing sth to the tree (uncommitted
changes) during the  bootstrap.  Not sure if the git rev somehow ends up
in fatal.o

[Bug bootstrap/98633] Bootstrap comparison failure, libcody/fatal.o differs

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Makesub.in:CXXFLAGS/fatal.cc = -DREVISION='"$(shell cat revision)"'
-DSRCDIR='"$(srcdir)"'

so there it is I guess.  So don't commit into the bootstrapping tree :/
(but it worked before!)

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

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

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

--- Comment #10 from Martin Liška  ---
> That's a feature branch that being integrated as is planed to have it in
> for 28.
> 
> Essentially we use it to compile .el files into shared libraries we then
> load to have Elisp executed as native code.

Great! Good we have a consumer of the infrastructure.

> 
> Here is the recording for my presentation at LPC2020/Cauldron:
> 

I'm going to watch, thanks!

[Bug tree-optimization/95034] Failure to convert xor pattern (made out of or+and) to xor

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

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

--- Comment #2 from Jakub Jelinek  ---
On:
int
combine (int a, int b)
{
  int c = (a | b);
  int d = ~(a & b);
  return c & d;
}
it is the
/* (x | y) & ~(x & y) -> x ^ y */
(simplify
 (bit_and:c (bit_ior @0 @1) (bit_not (bit_and @0 @1)))
 (bit_xor @0 @1))
simplification (and there are similar around it).
So, if we go to doing this in GENERIC, we'd need
variants of this for truth_{and,ior} and truth_{and,ior}if (and for the latter
only under the !TREE_SIDE_EFFECTS and !generic_expr_could_trap_p conditions,
(though doesn't the more than one @1 already imply !TREE_SIDE_EFFECTS).
We do have truth_xor, but that will evaluate both arguments.

[Bug tree-optimization/95034] Failure to convert xor pattern (made out of or+and) to xor

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

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

--- Comment #3 from Jakub Jelinek  ---
Actually in this case we are probably fine even if b can trap, the reason is
that
if a evaluated to true, then b in (a && b) is evaluated, and if a evaluates to
false, then b in (a || b) is evaluated.  So it is all about a and b being the
same expressions with no side-effects (which ensures that it isn't just e.g.
calling the same function with the same arguments twice).

[Bug c/98634] New: gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so

[zuogang at huawei dot com via Gcc-bugs]

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

Bug ID: 98634
   Summary: gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe
and linking with a so, and exe's source file extern a
var, the final exe has the var with the same name with
the one in the so file
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zuogang at huawei dot com
  Target Milestone: ---

during linking some externed var are added into the final exe file

step to reproduce :

zoge@123:/mnt/f/test$ gcc -c -fPIC share.c -o share.o
zoge@123:/mnt/f/test$ gcc share.o -shared -o libshare.so
zoge@123:/mnt/f/test$ gcc ./test-share.c ./libshare.so
zoge@123:/mnt/f/test$ readelf -s -W ./a.out | grep aaa
 6: 4028 4 OBJECT  GLOBAL DEFAULT   24 aaa
62: 4028 4 OBJECT  GLOBAL DEFAULT   24 aaa
zoge@123:/mnt/f/test$

zoge@123:/mnt/f/test$ cat share.c
#include 
int aaa=123;
void hello()
{
printf("Hello world!\n");
}
zoge@123:/mnt/f/test$ cat test-share.c
extern int aaa;

int main()
{
return aaa;
}

zoge@123:/mnt/f/test$

[Bug c++/98635] New: ad-hoc requirement without semicolon creates internal compiler bug

[nico at josuttis dot de via Gcc-bugs]

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

Bug ID: 98635
   Summary: ad-hoc requirement without semicolon creates internal
compiler bug
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nico at josuttis dot de
  Target Milestone: ---

https://godbolt.org/z/nPsT7n:

void printColl(auto& coll)
requires requires {
   coll.begin()
 } 
{
}

yields:

:3:24: error: expected ';' before '}' token
3 |coll.begin()
  |^
  |;
4 |  }
  |  ~  
:4:10: internal compiler error: Segmentation fault
4 |  }
  |  ^
0x1cc31d9 internal_error(char const*, ...)
???:0
0x79a2b6 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x79dda6 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
???:0
0x8d803d c_parse_file()
???:0
0xa54072 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug target/98636] New: [ARM] ICE on passing incompatible options for fp16

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

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

Bug ID: 98636
   Summary: [ARM] ICE on passing incompatible options for fp16
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

For any test-case, that includes arm_neon.h, for instance:
#include 
void f() {}

Passing incompatible fp16 format seems to result in ICE.
For example, passing -mfp16-format=alternative resulted in:
In file included from test.c:1:
../arm-stage1-build/gcc/include/arm_neon.h:18122:9: error: selected fp16
options are incompatible
18122 | #pragma GCC target ("arch=armv8.2-a+fp16fml")
  | ^~~
../arm-stage1-build/gcc/include/arm_neon.h:18324:9: internal compiler error:
‘global_options’ are modified in local context
18324 | #pragma GCC pop_options
  | ^~~
0xdcb103 cl_optimization_compare(gcc_options*, gcc_options*)
   
/home/bilbo/gnu-toolchain/gcc/vfma/arm-stage1-build/gcc/options-save.c:12555
0x97d54d handle_pragma_pop_options
../../gcc/gcc/c-family/c-pragma.c:1092
0x8f3cbb c_parser_pragma
../../gcc/gcc/c/c-parser.c:12525
0x91aab5 c_parser_external_declaration
../../gcc/gcc/c/c-parser.c:1758
0x91b269 c_parser_translation_unit
../../gcc/gcc/c/c-parser.c:1650
0x91b269 c_parse_file()
../../gcc/gcc/c/c-parser.c:21935
0x97b045 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1211


My built version is configured as:
Using built-in specs.
COLLECT_GCC=../arm-stage1-build/gcc/xgcc
Target: arm-linux-gnueabihf
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
--target=arm-linux-gnueabihf --with-arch=armv7-a --with-fpu=neon
--with-float=hard --with-mode=thumb
--with-sysroot=/home/bilbo/gnu-toolchain/sysroots/arm-linux-gnueabihf
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210111 (experimental) (GCC)

Thanks,
Prathamesh

[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
And the bug is?
This is due to copy relocations.
And, it has nothing to do with the compiler, it is how linker handles it.

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Ville Voutilainen  ---
Right - that's the Qt bug I'm hoping to fix, but I don't get far because of the
ICE. :) The libstdc++ headers have been reorganized, so Qt's expectations that
numeric_limits is available without including  are no longer valid with
GCC 11.

[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This is called a copy relocation.  I suspect the GCC you are using is
defaulting to PIE too.

[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

[zuogang at huawei dot com via Gcc-bugs]

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

--- Comment #3 from zuogang  ---
(In reply to Andrew Pinski from comment #2)
> This is called a copy relocation.  I suspect the GCC you are using is
> defaulting to PIE too.

the gcc in centos 7 maybe is not pie-default?

this verion is also has the same output.

[zoge@localhost shm]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) 
[zoge@localhost shm]$ file ./a.out
./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=af75712d9758e1267a8554d881915a658d36d382, not stripped

[Bug c++/98637] New: Changing active union member via assignment expression should require trivial default constructor in constexpr context

[m.cencora at gmail dot com via Gcc-bugs]

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

Bug ID: 98637
   Summary: Changing active union member via assignment expression
should require trivial default constructor in
constexpr context
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

According to http://eel.is/c++draft/class.union#general-6 following code should
be rejected
because changing of active union member via assignment expression should be
allowed only for classes with non-deleted trivial default constructor.

This is per Richard Smith's comment in
https://bugs.llvm.org/show_bug.cgi?id=48453

g++ -std=c++20

#include 

struct NonTrivial
{
constexpr NonTrivial() : b(true) {}

bool b;
};

union Un
{
bool f1;
NonTrivial f2;
};

constexpr bool test()
{
Un un{ .f1 = false };
un.f2 = {}; // should be an error here, and require
std::construct_at(&un.f2);
return un.f2.b;
}

static_assert(test());

[Bug demangler/88629] Regression lead to Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt

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

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #13 from Nick Clifton  ---
(In reply to prajwapa from comment #12)

> Could you please let me know, in which binutils version is this fixed?

Not really.  I can confirm that the test cases do not fail when tested with
binutils 2.35 (with sanitization enabled) and with any binutils all the way
back to 2.30 if sanitization is not enabled.

Given that the bug was reported in 2018-12 and assuming that it was fixed at
some point in the 6 months after that, then the nearest binutils release that
would have included the fix is 2.33.

I hope that this helps.

Cheers
  Nick

[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

[zuogang at huawei dot com via Gcc-bugs]

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

--- Comment #4 from zuogang  ---
(In reply to Jakub Jelinek from comment #1)
> And the bug is?
> This is due to copy relocations.
> And, it has nothing to do with the compiler, it is how linker handles it.

thanks for the reply, can you explain why the ld add a var into the bss
section?

why I add -fPIC, and the added var has gone?

[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

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

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

--- Comment #5 from Jakub Jelinek  ---
No RHEL or Fedora compilers are -pie by default, I hate when such important
details change silently under you.
Instead of changing the GCC default in these distros the rpm macros ensure PIE
by default when building rpm packages (unless one chooses to opt out).

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #11 from Martin Liška  ---
Good, I placed a couple of '#include ' and I can reproduce it now.
Thanks for the report.

[Bug fortran/98638] New: ICE: Segmentation fault (in lookup_page_table_entry)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 98638
   Summary: ICE: Segmentation fault (in lookup_page_table_entry)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: GC, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

Created attachment 49950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49950&action=edit
Testcase

gfortran-11.0.0-alpha20210110 snapshot
(g:872373360dab259d51caa002ff1722ff84746d8b) ICEs when compiling the attached
testcase, only mildly reduced from test/f90_correct/src/oop324.f90 from the
flang test suite, w/ -mcpu=860 -O2 -fexceptions -fnon-call-exceptions -fopenacc
-fpredictive-commoning --param integer-share-limit=2:

% powerpc-e300c3-linux-gnu-gfortran-11.0.0 -mcpu=860 -O2 -fexceptions
-fnon-call-exceptions -fopenacc -fpredictive-commoning --param
integer-share-limit=2 -c qvft2ssg.f90
qvft2ssg.f90:18:20:

   18 | end module shape_mod
  |^
internal compiler error: Segmentation fault
0xe8d916 crash_signal
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/gcc-11-20210110/gcc/toplev.c:327
0x97e833 lookup_page_table_entry
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/gcc-11-20210110/gcc/ggc-page.c:630
0x97e833 ggc_set_mark(void const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/gcc-11-20210110/gcc/ggc-page.c:1544
0xbf92c1 gt_ggc_mx_basic_block_def(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1517
0xbfb707 gt_ggc_mx_gimple(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1287
0x8cd40f gt_ggc_mx_lang_tree_node(void*)
./gt-fortran-f95-lang.h:403
0x8cd4b0 gt_ggc_mx_lang_tree_node(void*)
./gt-fortran-f95-lang.h:394
0x8cd4b0 gt_ggc_mx_lang_tree_node(void*)
./gt-fortran-f95-lang.h:394
0x8ccfa9 gt_ggc_mx_lang_decl(void*)
./gtype-fortran.h:72
0x8ccfa9 gt_ggc_mx_lang_decl(void*)
./gtype-fortran.h:67
0x8cd3ab gt_ggc_mx_lang_tree_node(void*)
./gt-fortran-f95-lang.h:177
0x8cd39d gt_ggc_mx_lang_tree_node(void*)
./gt-fortran-f95-lang.h:176
0xbfb9ae gt_ggc_mx_gimple(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1268
0xbf9379 gt_ggc_mx_basic_block_def(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1537
0xbfb707 gt_ggc_mx_gimple(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1287
0xbfe261 gt_ggc_mx_cgraph_edge(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1403
0xbfe253 gt_ggc_mx_cgraph_edge(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1402
0xbfe253 gt_ggc_mx_cgraph_edge(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1402
0xbfe253 gt_ggc_mx_cgraph_edge(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1402
0xbfdfee gt_ggc_mx_symtab_node(void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/build/gcc/gtype-desc.c:1349

[Bug rtl-optimization/97978] [11 Regression] ICE in lra_assign, at lra-assigns.c:1648 since r11-5066-gbe39636d9f68c437

[asolokha at gmx dot com via Gcc-bugs]

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

Arseny Solokha  changed:

   What|Removed |Added

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

--- Comment #6 from Arseny Solokha  ---
Fixed.

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #49948|0   |1
is obsolete||

--- Comment #9 from Richard Biener  ---
Created attachment 49951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49951&action=edit
patch

So while technically correct this interferes with group splitting:

FAIL: gcc.dg/vect/bb-slp-19.c -flto -ffat-lto-objects  scan-tree-dump-times
slp2 "optimized: basic block" 1
FAIL: gcc.dg/vect/bb-slp-19.c scan-tree-dump-times slp2 "optimized: basic
block" 1
FAIL: gcc.dg/vect/bb-slp-pr58135.c -flto -ffat-lto-objects 
scan-tree-dump-times slp2 "optimized: basic block" 1
FAIL: gcc.dg/vect/bb-slp-pr58135.c scan-tree-dump-times slp2 "optimized: basic
block" 1

bb-slp-19.c has a grouped store of size 9 where we immediately fail due to
the check which is "fatal" as in

  tree nunits_vectype;
  if (!vect_get_vector_types_for_stmt (vinfo, stmt_info, &vectype,
   &nunits_vectype, group_size)
  || (nunits_vectype
  && !vect_record_max_nunits (vinfo, stmt_info, group_size,
  nunits_vectype, max_nunits)))
{
  if (is_a  (vinfo) && i != 0)
continue;
  /* Fatal mismatch.  */
  matches[0] = false;
  return false;

which means we do not re-try with splitting the store group up.

Now, starting analysis with a group size of 9 is never going to
succeed.  Also note that get_vectype_for_scalar_type mimics the old
test:

  /* If the natural choice of vector type doesn't satisfy GROUP_SIZE,
 try again with an explicit number of elements.  */
  if (vectype
  && group_size
  && maybe_ge (TYPE_VECTOR_SUBPARTS (vectype), group_size))
{

but the fix must be to how we go discover splitting opportunities I guess.
One option is to only "soft-fail" for max_nunits issues, but then analysis
would still stop at the store (maybe that's even good - who knows, but
how far the match is good is only going to be determined later).

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

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Gabriel Ravier  ---
Isn't __attribute__((noipa)) usually used instead of __attribute__((noinline))
?

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

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

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

--- Comment #12 from Martin Liška  ---
So it's caused by PCH:

$ cat qt.ii
[empty]

$ cat q.ii
#pragma GCC pch_preprocess "cmake_pch.hxx.gch"
#pragma GCC push_options
#pragma GCC target ""
#pragma GCC pop_options

$ g++ -x c++-header qt.ii -o cmake_pch.hxx.gch && g++ q.ii -c
q.ii:4:9: internal compiler error: ‘global_options’ are modified in local
context
4 | #pragma GCC pop_options
  | ^~~
0x115df28 cl_optimization_compare(gcc_options*, gcc_options*)
/dev/shm/objdir/gcc/options-save.c:15271
0xcbc30e handle_pragma_pop_options
/home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:1092
0xcbcdb7 c_invoke_pragma_handler(unsigned int)
/home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:1515
0xb346ad cp_parser_pragma
/home/marxin/Programming/gcc/gcc/cp/parser.c:45062
0xb693ab cp_parser_toplevel_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:14096
0xb693ab cp_parser_translation_unit
/home/marxin/Programming/gcc/gcc/cp/parser.c:4936
0xb693ab c_parse_file()
/home/marxin/Programming/gcc/gcc/cp/parser.c:45121
0xcb4669 c_common_parse_file()
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1211
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

[zuogang at huawei dot com via Gcc-bugs]

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

--- Comment #6 from zuogang  ---
(In reply to Jakub Jelinek from comment #5)
> No RHEL or Fedora compilers are -pie by default, I hate when such important
> details change silently under you.
> Instead of changing the GCC default in these distros the rpm macros ensure
> PIE by default when building rpm packages (unless one chooses to opt out).

I add -fPIE and no change, but I use -fPIC the var is not added into the elf
a.out file

why -fPIC turnoff the "copy relocation" ? but -fPIE doesn't

[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

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

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

--- Comment #7 from Jakub Jelinek  ---
Just read something about copy relocations, bugzilla is not a tool for
education.

[Bug fortran/64290] [F03] No finalization at deallocation of LHS

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

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

--- Comment #3 from Paul Thomas  ---
Created attachment 49952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49952&action=edit
Slightly better patch

This gets rid of the regression in gfortran.dg/finalize_29.f08.

However, finalize_25.f90 exposes the real scale of the problem because it shows
that finalization is partially implemented for variables with allocatable
components and this causes collisions with the finalization in the patch.

Cheers

Paul

[Bug tree-optimization/95034] Failure to convert xor pattern (made out of or+and) to xor

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

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

--- Comment #4 from Jakub Jelinek  ---
Tried
--- match.pd.jj12021-01-05 16:33:21.809960885 +0100
+++ match.pd2021-01-12 12:47:11.232713918 +0100
@@ -1228,6 +1228,64 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (bit_xor (bit_ior:c (bit_not @0) @1) (bit_ior:c @0 (bit_not @1)))
  (bit_xor @0 @1))

+#if GENERIC
+/* Repeat the above simplifications for truth* for GENERIC.
+   It can be done even for truth_*if as both x and y are always evaluated.
+   Unfortunately :c on truth_*if aren't allowed (they aren't commutative,
+   but in this case we don't care).  */
+(for andop (truth_and truth_andif)
+ orop (truth_or truth_orif)
+ /* (x || y) && !(x && y) -> x ^ y */
+ (simplify
+  (andop (orop @0 @1) (truth_not (andop @0 @1)))
+  (truth_xor @0 @1))
+ (simplify
+  (andop (truth_not (andop @0 @1)) (orop @0 @1))
+  (truth_xor @0 @1))
+
+ /* (x || y) && (!x ^ y) -> x && y */
+ (simplify
+  (andop (orop @0 @1) (truth_xor:c @1 (truth_not @0)))
+  (truth_and @0 @1))
+ (simplify
+  (andop (orop @1 @0) (truth_xor:c @1 (truth_not @0)))
+  (truth_and @0 @1))
+ (simplify
+  (andop (truth_xor:c @1 (truth_not @0)) (orop @0 @1))
+  (truth_and @0 @1))
+ (simplify
+  (andop (truth_xor:c @1 (truth_not @0)) (orop @1 @0))
+  (truth_and @0 @1))
+
+ /* (!x || y) && (x || !y) -> !(x ^ y) */
+ (simplify
+  (andop (orop:s (truth_not @0) @1) (orop:s @0 (truth_not @1)))
+  (truth_not (truth_xor @0 @1)))
+ (simplify
+  (andop (orop:s @1 (truth_not @0)) (orop:s @0 (truth_not @1)))
+  (truth_not (truth_xor @0 @1)))
+ (simplify
+  (andop (orop:s (truth_not @0) @1) (orop:s (truth_not @1) @0))
+  (truth_not (truth_xor @0 @1)))
+ (simplify
+  (andop (orop:s @1 (truth_not @0)) (orop:s (truth_not @1) @0))
+  (truth_not (truth_xor @0 @1)))
+
+ /* (!x || y) ^ (x || !y) -> x ^ y */
+ (simplify
+  (truth_xor (orop (truth_not @0) @1) (orop @0 (truth_not @1)))
+  (truth_xor @0 @1))
+ (simplify
+  (truth_xor (orop @1 (truth_not @0)) (orop @0 (truth_not @1)))
+  (truth_xor @0 @1))
+ (simplify
+  (truth_xor (orop (truth_not @0) @1) (orop (truth_not @1) @0))
+  (truth_xor @0 @1))
+ (simplify
+  (truth_xor (orop @1 (truth_not @0)) (orop (truth_not @1) @0))
+  (truth_xor @0 @1)))
+#endif
+
 /* ((x & y) - (x | y)) - 1 -> ~(x ^ y) */
 (simplify
  (plus (nop_convert1? (minus@2 (nop_convert2? (bit_and:c @0 @1))
but in addition to it being lengthy (as one can't use :c on andop or orop
because truth_andif and truth_orif aren't commutative), it doesn't really work
here, because e.g. fold_truth_andor_1 optimizes that x || y into (x | y) != 0
before we can optimize it.
Another option is to code it in fold_truth_andor or fold_truth_andor_1.

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

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

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

--- Comment #13 from Martin Liška  ---
I've got a patch candidate, testing right now.

[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2021-01-12
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please attach a pre-processed source file and output of --verbose?

[Bug fortran/98638] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) since r11-6411-gae99b315ba5b9e1c

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
Summary|ICE: Segmentation fault (in |[11 Regression] ICE:
   |lookup_page_table_entry)|Segmentation fault (in
   ||lookup_page_table_entry)
   ||since
   ||r11-6411-gae99b315ba5b9e1c
 Target|powerpc-*-linux-gnu |powerpc-*-linux-gnu,
   ||x86_64-linux-gnu
  Known to work||10.2.0
   Target Milestone|--- |11.0
   Last reconfirmed||2021-01-12
 Ever confirmed|0   |1
  Known to fail||11.0

--- Comment #1 from Martin Liška  ---
Confirmed on x86_64-linux-gnu with --param=ggc-min-expand=0
--param=ggc-min-heapsize=0. Started with r11-6411-gae99b315ba5b9e1c.

[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context

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

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 49953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49953&action=edit
Preprocessed test-case

[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context

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

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 49954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49954&action=edit
Output of passing --verbose

Command line option used to compile:
../arm-stage1-build/gcc/xgcc -B ../arm-stage1-build/gcc 
-mfp16-format=alternative test.c -S -save-temps  --verbose >verbose_output.txt
2>&1

[Bug fortran/64290] [F03] No finalization at deallocation of LHS

[drikosev at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Ev Drikos  ---


Hello,

There are some open PRs related to elemental finalisers. Having seen
how you reallocate arrays, I'd the impression that the functionality
for polymorphic entities would had a similar design. As one may also
need ie to reset at least the '_len' field, ie class(*) x; x='a';

Which in turn may not cause regressions to "finalize_25.f90" and I see
that this test counts some finalisation calls. Of course I don't doubt
that finalization may be partially implemented as you say. Admittedly
the interpretation of 10.2.1.3 & 7.5.6.3 seems to be a herculean task.

To my understanding, an outcome of the discussion in c.l.f is that the
reallocation takes place if the LHS & RHS have different runtime types,
at least this seems to be a criterion for no rank polymorphic entities.


Hope this helps,
Ev. Drikos

[Bug fortran/98638] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) since r11-6411-gae99b315ba5b9e1c

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

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

--- Comment #2 from Richard Biener  ---
SSA name in some TYPE/DECL_SIZE tree?

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-6612-ge91910d3576eeac714c93ec25ea3b15012007903
Author: Martin Liska 
Date:   Tue Jan 12 13:20:18 2021 +0100

options: properly compare string arguments

Similarly to 7f967bd2a7ba156ede3fbb147e66dea5fb7137a6, we need to
compare string with strcmp.

gcc/ChangeLog:

PR c++/97284
* optc-save-gen.awk: Compare also n_target_save vars with
strcmp.

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #15 from Martin Liška  ---
Fixed.

[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context

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

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

--- Comment #4 from Martin Liška  ---
Thanks, with cross compiler I only see the error (not the internal compiler
error).
Anyway, can you please test it with g:e91910d3576eeac714c93ec25ea3b15012007903?

[Bug fortran/98638] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) since r11-6411-gae99b315ba5b9e1c

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

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

--- Comment #3 from Martin Liška  ---
Reduced test-case:

module shape_mod
  type rectangle
 end type 
  type, extends (rectangle) :: square
 real, allocatable :: r(:)
  end type 
end  
use shape_mod
  logical results(8)
  class(rectangle),allocatable :: r
  class(rectangle),allocatable :: r2
  allocatable rr(:)
  select type(o=>r)
  class is (square)
 allocate(rr,source=o%r)
 select type(r2)
 class is (square)
results = or .eq. rr
 end select
  end select
end

[Bug fortran/98638] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) since r11-6411-gae99b315ba5b9e1c

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

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

--- Comment #4 from Richard Biener  ---
Fortran lang_decl has

struct GTY(()) lang_decl {
  /* Dummy variables.  */
  tree saved_descriptor;

and that eventually contains _121->r (SSA names which refer to def stmts
which refer to BBs).  The decl is reachable via an abstract origin.

I suppose the saved_descriptor has a tree sharing "issue" with sth
gimplified.

[Bug fortran/98638] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) since r11-6411-gae99b315ba5b9e1c

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
Note not releasing SSA names but ggc_freeing basic-block will also increase the
"attack surface" to the existing VLA missing DECL_EXPR issues which also cause
SSA names to leak into size fields of decls and types.  So one "fix" might be
to make sure to release SSA names (which will NULL their def_stmt field)
when we free the CFG.

[Bug gcov-profile/98631] exception hit once reported twice

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-01-12

--- Comment #1 from Martin Liška  ---
Thank you Marek for the report, I can confirm it.
What happens:

$ g++ pr98631.C --coverage -fdump-ipa-profile-details-lineno
...
int main ()
{
  struct S s;
  int D.2411;
  void * _1;
  int _11;

   :
  [pr98631.C:14:7] S::S ([pr98631.C:14:7] &s);

   :
  s ={v} {CLOBBER};

   :
  [pr98631.C:19:1] _11 = 0;

   :
:
  [pr98631.C:19:1] return _11;

   :
:
  s ={v} {CLOBBER};
  resx 2

   :
:
  [pr98631.C:16:3] eh_dispatch 1

   :
:
  [pr98631.C:16:9] _1 = __builtin_eh_pointer (1);
  [pr98631.C:16:9] __cxa_begin_catch (_1);

   :
  [pr98631.C:17:22] __builtin_puts (&"caught"[0]);

   :
  [pr98631.C:16:9] __cxa_end_catch ();
  goto ; [INV]

   :
:
  [pr98631.C:16:9] __cxa_end_catch ();

   :
  resx 4

}

-:   15:  }
2:   16:  catch(...) {
1:   17:__builtin_printf ("caught\n");
-:   18:  }

In my case line 16 is present in BB 7, 8, 10 and 11.

$ gcov a-pr98631.C -t --debug

source_info: pr98631.C
  function_info: main
block_info id=0, count=1
block_info id=1, count=1
block_info id=2, count=1
block_info id=3, count=0
block_info id=4, count=1
block_info id=5, count=1
block_info id=6, count=1
block_info id=7, count=1
block_info id=8, count=1
block_info id=9, count=1
block_info id=10, count=1
block_info id=11, count=0
block_info id=12, count=0

as seen, bb_9 is executed and that's the place where we "leave" line 16,
enter line 17 and then again enter 16 in bb_10. That's why we see the line
being executed twise.

It's not easy to fix :/
Btw. started with r5-7298-g3b445b24ddadf8a9.

[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
@Honza: Can you please judge here?

@David: Can you really reproduce that on x86_64-linux-gnu (I can't for some
reason)?

[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context

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

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
Hi,
Unfortunately I am still getting the same ICE with
g:e91910d3576eeac714c93ec25ea3b15012007903.

Thanks,
Prathamesh

[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context

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

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

--- Comment #6 from Martin Liška  ---
I see. Is the 'error: selected fp16 options are incompatible' valid or not in
this case?

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

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

https://gcc.gnu.org/g:52a170b1a1818b7521c25e76271638a448b3f630

commit r11-6613-g52a170b1a1818b7521c25e76271638a448b3f630
Author: Richard Biener 
Date:   Tue Jan 12 11:17:33 2021 +0100

tree-optimization/98550 - fix BB vect unrolling check

This fixes the check that disqualifies BB vectorization because of
required unrolling to match up with the later exact_div we do.  To
not disable the ability to split groups that do not match up
exactly with a choosen vector type this also introduces a soft-fail
mechanism to vect_build_slp_tree_1 which delays failing to after
the matches[] array is populated from other checks and only then
determines the split point according to the vector type.

2021-01-12  Richard Biener  

PR tree-optimization/98550
* tree-vect-slp.c (vect_record_max_nunits): Check whether
the group size is a multiple of the vector element count.
(vect_build_slp_tree_1): When we need to fail because
the vector type choosen causes unrolling do so lazily
without affecting matches only at the end to guide group splitting.

* g++.dg/opt/pr98550.C: New testcase.

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/98635] ad-hoc requirement without semicolon creates internal compiler bug

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context

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

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #7 from prathamesh3492 at gcc dot gnu.org ---
I think the error is correct.
CCing Kyrill -- could you please confirm if the error is valid for
above case ?
Thanks!

[Bug c/98630] Seg-fault when using a goto after condition (if)

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

--- Comment #12 from Karine EM  ---
Yes, I could do that (comment #7). But I reduce manually the program and the
problem was indeed the scenario in comment #8 (not between functions, only
different blocks, but I assume it is pretty much the same).

If you add a new warning also to GCC at some point, it will be useful.

[Bug c++/98611] [concepts][10/11 Regression] ICE in get_underlying_template, at cp/pt.c:6494 since r10-3735-gcb57504a55015891

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

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

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

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

commit r11-6614-ge0bec6ceac47752616dd9fe0801344ed45db2fd3
Author: Patrick Palka 
Date:   Tue Jan 12 09:34:41 2021 -0500

c++: Fix ICE with CTAD in concept [PR98611]

This patch teaches cp_walk_subtrees to visit the template represented
by a CTAD placeholder, which would otherwise be not visited during
find_template_parameters.  The template may be a template template
parameter (as in the first testcase), or it may implicitly use the
template parameters of an enclosing class template (as in the second
testcase), and in either case we need to visit this tree to record the
template parameters used therein for later satisfaction.

gcc/cp/ChangeLog:

PR c++/98611
* tree.c (cp_walk_subtrees) : Visit
the template of a CTAD placeholder.

gcc/testsuite/ChangeLog:

PR c++/98611
* g++.dg/cpp2a/concepts-ctad1.C: New test.
* g++.dg/cpp2a/concepts-ctad2.C: New test.

[Bug c/98630] Seg-fault when using a goto after condition (if)

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

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

--- Comment #13 from Jakub Jelinek  ---
Then -Wjump-misses-init should warn even on the unreduced testcase...

[Bug c/98630] Seg-fault when using a goto after condition (if)

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

--- Comment #14 from Karine EM  ---
I did compile it that way: 
> gcc-10 -w -O2 r.c -pedantic -Wall -Wextra
but got no warnings at all. Should I add any flag?
Thanks!