[Bug tree-optimization/95768] [11 Regression] -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|c++ |tree-optimization
   Priority|P3  |P1

[Bug tree-optimization/95770] [11 Regression] ice during GIMPLE pass: slp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Will have a look.

[Bug ipa/95775] Command line argument for target_clones?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Component|target  |ipa
   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
But it will blow up code-size considerably.  Eventually with -flto and the
library constraining on what symbols it exports one could figure the
minimal set of functions with IFUNC relocations at least.  Using
profile-feedback
might also able to concentrate on interesting functions.

So without some major work I don't think simply slapping target_clones on
each function is going to fly in practice.

Eventually it should be possible to do sth like target_clones(auto) where
with a new option, the target (or the user) can define "default" targets
to clone for but the user still figures which are the important functions
to optimize [and GCC may, via IPA "spread" the cloned cgraph portion a bit].

[Bug c/95777] Allow specifying more than one target options at the same time in target and target_clones attribute

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Richard Biener  ---
I think multiple targets are allowed by means of providing multiple
declarations with different attribute parameters.  Martin?

[Bug ipa/95769] Constant expression in inline function not optimized

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
If we are going to optimize this at IPA time, I'll note we'd need a separate
middle-end IL evaluation code, because the FE one isn't usable for this (not
even through a langhook), because it relies on the IL being unfolded FE trees
and has all the language imposed restrictions etc.
I think I've mentioned IL evaluation as something useful for loops to be able
to evaluate all their side-effects and judge if they are small enough (not too
much overwritten memory, etc.) to replace the original loop, and if we have it,
using it for functions to whose arguments we propagate constants, perhaps using
the constexpr as a hint to try somewhat longer, could work.

[Bug tree-optimization/95810] New: Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN

[felix.von.s at posteo dot de]

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

Bug ID: 95810
   Summary: Spurious UBSan warning when computing the opposite of
the absolute value of INT_MIN
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.von.s at posteo dot de
  Target Milestone: ---

When the expression (x <= 0 ? x : -x) with x having type int is compiled with
-fsanitize=undefined -O3, setting (x = INT_MIN) triggers a spurious UBSan
warning about INT_MIN being negated.

Not sure if I should file this against tree-ssa or the frontend(s), because the
expression apparently becomes (-ABS_EXPR ) very early, even at -O0. I
checked this with C, C++ and D frontends.

[Bug ipa/95781] Missing dead code elimination when a recursive function is inlined.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||missed-optimization
  Component|other   |ipa
   Last reconfirmed||2020-06-22

--- Comment #1 from Richard Biener  ---
Confirmed.  The recursion is only removed late via tail-recursion but then
cgraph processing order is unfortunate in the sense that we don't have a
IPA phase pass after optimizations and thus dead functions are only
removed reliably outside of (original) cgraph cycles.

For multiple reasons we want to be able to separate actual assembly
output from assembly production thus eventually a per symtab node
assembler fragment and late "IPA" assembling of the assembler file
might help here.

[Bug target/95783] Inefficient use of the stack when a function takes the address of its argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-22
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/95799] Assumed conjunctions are not broken down into clauses if their pureness is checked first

[felix.von.s at posteo dot de]

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

--- Comment #1 from felix  ---
Created attachment 48767
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48767&action=edit
Sample program

I was pretty sure I attached this before. Never mind, here it is.

[Bug target/95784] Failure to optimize usage of __builtin_add_overflow with return statement properly

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
I wouldn't be surprised if a version with a branch is faster even with each
of the branches mispredicted.  cmovs are weird beasts but since they
are not dependent on each other their latency at least shouldn't add up here
so LLVMs two cmovs shouldnt be worse off than GCCs one cmov.  You'd need to
compare against a variant without any cmov.

[Bug ipa/95786] Too aggressive target indirection elimination

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|tree-optimization   |ipa
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
I guess bypassing the dispatcher is also not OK here.  Maybe the initial
cgraph looks semantically wrong already.

[Bug rtl-optimization/95787] Complete lack of optimization on assignment to some types when followed by

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-22

[Bug ipa/95790] Incorrect static target dispatch

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|WAITING |NEW

--- Comment #9 from Richard Biener  ---
I think "nested" MV should just work, we just have to be careful when
optimizing
dispatch between them.  Well, if I understand correctly what nested MV should
be
(calling a MV function from a MVed function with a different target).

[Bug tree-optimization/95792] Failure to optimize assignment of struct members to memset

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||compile-time-hog
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-22

--- Comment #2 from Richard Biener  ---
GCC doesn't try to do memcpy pattern detection when you manually produce such
kind of initialization.  In theory vectorizer dataref analysis figures it out
but then there's no "vectorize with memset" implemented ;)  store-merging
only merges up to word-size stores.

As expected most of the compile-time is spent funneling this through
optimizers before the very late attempts to optimize it.  Notably

 alias stmt walking :  35.95 ( 64%)   0.47 ( 65%)  36.60 ( 64%)
  0 kB (  0%)
 tree DSE   :  16.08 ( 29%)   0.14 ( 19%)  16.28 ( 28%)
  0 kB (  0%)

where the walking cut-off for DSE is likely too big (note the above is
for a -O0 optimized cc1 with -O1 -fno-checking).

[Bug other/95811] New: configure fails when crossing to x86_64: checking for CET support...configure: error: cannot run test program while cross compiling

[slyfox at inbox dot ru]

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

Bug ID: 95811
   Summary: configure fails when crossing to x86_64: checking for
CET support...configure: error: cannot run test
program while cross compiling
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
CC: hjl.tools at gmail dot com
  Target Milestone: ---

Initially reported by Aisha Tammy as https://bugs.gentoo.org/729074.

There attempt to cross-compile x86_64 to x86_64 with slightly different
tollchain prefix (to unshare defaults) fails as:

"""
$ .../configure --host=x86_64-UNREG-linux-gnu --target=x86_64-UNREG-linux-gnu
--build=x86_64-pc-linux-gnu ...

checking for CET support... configure: error: in
`/tmp/portage-tmpdir/portage/sys-devel/gcc-10.1.0-r1/work/build/libiberty':
configure: error: cannot run test program while cross compiling
See `config.log' for more details
make[1]: *** [Makefile:7996: configure-libiberty] Error 1
"""

Passing --disable-cet explicitly allows passing the condition. Should
AC_TRY_RUN default to --disable-cet automatically?

[Bug fortran/95812] New: [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[jakub at gcc dot gnu.org]

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

Bug ID: 95812
   Summary: [10/11 Regression] ICE in gfc_dep_resolver since
r10-2114
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Starting with r10-2114-g40e1ed26774b7b6c24d166489a715aa75843ab36 Fortran FE
ICEs with -O3 on:
module test
contains
  subroutine foo()
integer :: a(3)
a = 1
print *, matmul(1*reshape(a,(/3,1/)), reshape((/1,1,1/),(/1,3/)))
  end subroutine foo
  subroutine bar()
call foo()
  end subroutine bar
end module test

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||tkoenig at gcc dot gnu.org
   Last reconfirmed||2020-06-22
 Ever confirmed|0   |1
   Target Milestone|--- |10.2

[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I have a patch exploiting this but it faces some correctness issues in the
propagators where some of them instantiate the assumptions before simplifying
the stmts themselves.

[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero

[rguenth at gcc dot gnu.org]

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

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

Here is the WIP patch, work is suspended.  There may be a duplicate bug about
this.

[Bug tree-optimization/95804] ice in generate_code_for_partition, at tree-loop-distribution.c:1323

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-22
   Keywords||needs-bisection
  Component|target  |tree-optimization
 CC||amker at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We seem to end up with a reduction partition not in the last
position thus miss some required partition merging.

[Bug bootstrap/95805] [11 regression] gcc/recog.h:301:30: error: too many arguments to function call, expected 1, have 2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC|rsandifo at sources dot redhat.com |rsandifo at gcc dot 
gnu.org
   Keywords||build
   Target Milestone|--- |11.0
Version|unknown |11.0

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug bootstrap/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #7 from Sergei Trofimovich  ---
*** Bug 95811 has been marked as a duplicate of this bug. ***

[Bug other/95811] configure fails when crossing to x86_64: checking for CET support...configure: error: cannot run test program while cross compiling

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

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

--- Comment #1 from Sergei Trofimovich  ---
Was probably fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d17cdc17c90ce77cb90c569322c1f241d3530cec

which added cross_compiling case. My apologies for the noise.

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

[Bug middle-end/95810] Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end

--- Comment #1 from Andrew Pinski  ---
It should have became uabs instead.

[Bug bootstrap/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #8 from Richard Biener  ---
HJ, can you please backport?

[Bug tree-optimization/95804] ice in generate_code_for_partition, at tree-loop-distribution.c:1323

[amker at gcc dot gnu.org]

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

--- Comment #2 from bin cheng  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  We seem to end up with a reduction partition not in the last
> position thus miss some required partition merging.
Sorry for the breakage.

Whew, this part IS can of worms.  Will investigate it.

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[drikosev at gmail dot com]

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

Ev Drikos  changed:

   What|Removed |Added

 CC||drikosev at gmail dot com

--- Comment #3 from Ev Drikos  ---

Hello,

Perhaps, an additional check in file resolve.c might be necessary, or
one would have to adjust one-two "common*.f" test cases.

Hope this helps,
Ev. Drikos

--

   if (gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_COMMON)
+  gsym = gfc_find_gsymbol (gfc_gsym_root, csym->name);
+  if (gsym && gsym->type != GSYM_UNKNOWN)
+   gfc_error_now ("Global entity %qs at %L cannot appear in a "
+   "COMMON block at %L", gsym->name,
+   &gsym->where, &csym->common_block->where);
+

[Bug c++/95813] New: Making static member function a coroutine may cause "defined but not used" warning for destroy(frame*) function

[gleb at scylladb dot com]

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

Bug ID: 95813
   Summary: Making static member function a coroutine may cause
"defined but not used" warning for destroy(frame*)
function
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gleb at scylladb dot com
  Target Milestone: ---

Compiling the code below with -Wall emits:

warn.cc:37:5: warning: ^Xגvoid
xxx::_ZN3xxx4funcEv.destroy(xxx::func()::_ZN3xxx4funcEv.frame*)^Yג defined but
not used [-Wunused-function]

and if foo() is uncommented the code compiles fine.

If should be OK to have the static member function in a header without getting
the warning.

#include 
#include 
#include 
#include 

template 
class lazy {
T _v = 0;
public:
lazy() {}
bool await_ready() {return true;}
void await_suspend(auto x) noexcept {}
T await_resume() { return _v; }
};

namespace std {

template 
struct coroutine_traits, Args...> {
struct promise_type {
suspend_always initial_suspend() const { return {}; }
suspend_always final_suspend() const { return {}; }
void return_value(T val) {}
lazy get_return_object() {
return lazy();
}
void unhandled_exception() {
std::terminate();
}
};
};
}

struct xxx {
static lazy func() {
co_return 1;
}
};

#if 0
lazy foo() {
co_return co_await xxx::func();
}
#endif

[Bug middle-end/95810] Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Koenig  ---
I'll take a look.

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I think it is rejected at instanition time.
> 
> Hi, Andrew. Shouldn't it be rejected at compiling time?

It could be, but that is not required by the C++ standard.

> Is this case similar with bug.cc?

Yes. The ill-formed template is not diagnosed unless you instantiate it. That
is allowed by the standard.

[Bug middle-end/95810] Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 48769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48769&action=edit
gcc11-pr95810.patch

Untested fix.

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[haoxintu at gmail dot com]

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

--- Comment #4 from Haoxin Tu  ---
(In reply to Jonathan Wakely from comment #3)
>  The ill-formed template is not diagnosed unless you instantiate it.
> That is allowed by the standard.

Thank you Jonathan, thanks for your response.

As other major compilers reject this by default, I just suggest GCC should emit
a appropriate diagnostic message (maybe a warning is fine).

Just a suggestion, please understand if it is inappropriate ~

[Bug tree-optimization/95770] [11 Regression] ice during GIMPLE pass: slp

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1582-gcf07eea8429c923b7eb884ffc1b267c80a0a839c
Author: Richard Biener 
Date:   Mon Jun 22 12:14:54 2020 +0200

tree-optimization/95770 - fix SLP vectorized stmt placement compute

This fixes the vectorized stmt placement compute for the case of
external defs.

2020-06-22  Richard Biener  

PR tree-optimization/95770
* tree-vect-slp.c (vect_schedule_slp_instance): Also consider
external defs.

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

[Bug tree-optimization/95770] [11 Regression] ice during GIMPLE pass: slp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/95814] New: Failure to optimize __builtin_ia32_rsqrtss properly

[gabravier at gmail dot com]

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

Bug ID: 95814
   Summary: Failure to optimize __builtin_ia32_rsqrtss properly
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef float v4f32 __attribute__((vector_size(16)));

float f(float x)
{
return __builtin_ia32_rsqrtss((v4f32){x, 0, 0, 0})[0];
}

With -O3, LLVM outputs this :

f(float):
  rsqrtss xmm0, xmm0
  ret

GCC outputs this :

f(float):
  pxor xmm1, xmm1
  movss xmm1, xmm0
  movaps xmm0, xmm1
  rsqrtss xmm0, xmm1
  ret

[Bug demangler/95815] New: Infinite recursive error about "demangle_args" "demangle_nested_args" in libiberty when running cxxfilt

[ossecurity at iscas dot ac.cn]

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

Bug ID: 95815
   Summary: Infinite recursive error about "demangle_args"
"demangle_nested_args" in libiberty when running
cxxfilt
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ossecurity at iscas dot ac.cn
  Target Milestone: ---

Created attachment 48770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48770&action=edit
crash input of cxxfilt (cxxfilt < ./payload002040)

Hi, developers, we find an infinite recursive error of cxxfilt(Binutils-2.31
and earlier) when demangle malformed inputs(Generate by our modified version of
AFL). This bug seems to be fixed in 2.32 and it is not reported yet, is there
any patches for earlier version?


reproduce command: cxxfilt < payload002040

Compile:
obj-2.31$../binutils-2.31/configure --disable-shared --disable-gdb
--disable-libde
cnumber --disable-readline --disable-sim --disable-ld AR=llvm-ar
RANLIB=llvm-ranlib CC=clang


Any comments or suggestions are grateful.

Best regards,
Ke Yang 

==
Valgrind log(binutils-2.31):
obj-2.31/binutils$ valgrind -- ./cxxfilt < ./paload002040 
==24114== Memcheck, a memory error detector
==24114== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24114== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24114== Command: ./cxxfilt
==24114== 
__?__aTSY_]fS __t4__fm4d666T4]fS
__t4__fm4d6667666T4_Z���_

_%�'

��
77�

_( ( ( (void���FeFFF@FFK_(int255_t,  ( ( ( ( ( ( ( ( ( (
( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (void)))@FFK_(int255_t, 
( ( ( ( ( ( ( ( (double,  ( ( ( ( ( (���_

_%�

==24114== Stack overflow in thread #1: can't grow stack to 0xffe801000
==24114== 
==24114== Process terminating with default action of signal 11 (SIGSEGV)
==24114==  Access not within mapped region at address 0xFFE801FF0
==24114== Stack overflow in thread #1: can't grow stack to 0xffe801000
==24114==at 0x497BBA: string_init (cplus-dem.c:4935)
==24114==by 0x497BBA: do_type (cplus-dem.c:3628)
==24114==  If you believe this happened as a result of a stack
==24114==  overflow in your program's main thread (unlikely but
==24114==  possible), you can try to increase the size of the
==24114==  main thread stack using the --main-stacksize= flag.
==24114==  The main thread stack size used in this run was 8388608.
==24114== Stack overflow in thread #1: can't grow stack to 0xffe801000
==24114== 
==24114== Process terminating with default action of signal 11 (SIGSEGV)
==24114==  Access not within mapped region at address 0xFFE801FD8
==24114== Stack overflow in thread #1: can't grow stack to 0xffe801000
==24114==at 0x4A28680: _vgnU_freeres (in
/usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==24114==  If you believe this happened as a result of a stack
==24114==  overflow in your program's main thread (unlikely but
==24114==  possible), you can try to increase the size of the
==24114==  main thread stack using the --main-stacksize= flag.
==24114==  The main thread stack size used in this run was 8388608.
==24114== 
==24114== HEAP SUMMARY:
==24114== in use at exit: 1,091,324 bytes in 38,796 blocks
==24114==   total heap usage: 39,071 allocs, 275 frees, 1,103,917 bytes
allocated
==24114== 
==24114== LEAK SUMMARY:
==24114==definitely lost: 0 bytes in 0 blocks
==24114==indirectly lost: 0 bytes in 0 blocks
==24114==  possibly lost: 0 bytes in 0 blocks
==24114==still reachable: 1,091,324 bytes in 38,796 blocks
==24114== suppressed: 0 bytes in 0 blocks
==24114== Rerun with --leak-check=full to see details of leaked memory
==24114== 
==24114== For counts of detected and suppressed errors, rerun with: -v
==24114== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault

GDB log:

Program received signal SIGSEGV, Segmentation fault.
0x7788ab9a in _int_malloc (av=av@entry=0x77bcdb20 , 
bytes=bytes@entry=32) at malloc.c:3319
3319malloc.c: No such file or directory.
(gdb) bt
#0  0x7788ab9a in _int_malloc (av=av@entry=0x77bcdb20 , 
bytes=bytes@entry=32) at malloc.c:3319
#1  0x7788d184 in __GI___libc_malloc (bytes=32) at malloc.c:2913
#2  0x004bda45 in xmalloc (size=32) at
../../binutils-2.31/libiberty/xmalloc.c:147
#3  0x004a58eb in string_need (s=, n=32)
at ../../binutils-2.31/libiberty/cplus-dem.c:4906
#4  string_append (p=, s=)
at ../../binutils-2.31/libiberty/cplus-dem.c:4961
#5  demangle_args (work=0x7fffdc30, mangled=0x7fffdbd0,
declp=0x7f7ff100)
at ../../binutils-2.31/libiberty/cplus-dem.c:4578
#6  0x00498711 in demangle_nested_args (work=0x7fff

[Bug target/95816] New: Aarch64 jumps between Hot/Cold sections use possibly clobbered registers x16/x17

[matmal01 at gcc dot gnu.org]

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

Bug ID: 95816
   Summary: Aarch64 jumps between Hot/Cold sections use possibly
clobbered registers x16/x17
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matmal01 at gcc dot gnu.org
  Target Milestone: ---
Target: AArch64

When splitting a function into two different sections (hot/cold).

The assembler produces a relocation on jumps between the two sections.

The linker is permitted to use a veneer to implement such a relocated jump.

The registers x16 and x17 are reserved for use in those veneers.

Hence the registers x16 and x17 should be treated as clobbered when jumping
between the hot/cold sections in a function.

This is not done.

We can use the testcase below to demonstrate this (modified from predict-22.c
in the testsuite).

-
$ aarch64-none-linux-gnu-gcc \  
>predict-22.c \
>-O2 -w -fPIC -freorder-blocks-and-partition \
>-c -o predict-22.o

-
volatile int v;
void bar (void) __attribute__((leaf, cold));
void baz (int *);
void alt (long long);

void
foo (int x, int y, int z)
{
  static int f __attribute__((section ("mysection")));
  register long long k asm ("x16");
  __asm__ ("mov\t%0, 10" : "=r" (k) : "0" (k));
  f = 1;
  if (__builtin_expect (x, 0))
  if (__builtin_expect (y, 0))
  if (__builtin_expect (z, 0))
{
  f = 2;
  k *= 13;
  bar ();
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += k;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  f = 3;
  __builtin_abort ();
}
  f = k;
  baz (&f);
}



This produces an object file which is dumped below.
The dump below demonstrates that there is a R_AARCH64_JUMP26 relocation on the
jump between the hot/cold sections, and that the value stored in x16 is used
after that jump.



$  aarch64-none-linux-gnu-objdump -dr predict-22.o  
predict-22.o: file format elf64-littleaarch64


Disassembly of section .text:

 :
   0:   713fcmp w1, #0x0
   4:   7a401844ccmpw2, #0x0, #0x4, ne  // ne = any
   8:   7a401804ccmpw0, #0x0, #0x4, ne  // ne = any
   c:   d2800150mov x16, #0xa   // #10
  10:   54a1b.ne24   // b.any
  14:   9001adrpx1, 0 
14: R_AARCH64_ADR_PREL_PG_HI21  .bss
  18:   9120add x0, x1, #0x0
18: R_AARCH64_ADD_ABS_LO12_NC   .bss
  1c:   b930str w16, [x1]
1c: R_AARCH64_LDST32_ABS_LO12_NC.bss
  20:   1400b   0 
20: R_AARCH64_JUMP26baz
  24:   a9bd7bfdstp x29, x30, [sp, #-48]!
  28:   910003fdmov x29, sp
  2c:   a90153f3stp x19, x20, [sp, #16]
  30:   f90013f5str x21, [sp, #32]
  34:   1400b   0# Here is the
relocation.
34: R_AARCH64_JUMP26.text.unlikely

Disassembly of section .text.unlikely:

 :
   0:   9015adrpx21, 0 
0: R_AARCH64_ADR_PREL_PG_HI21   .bss
   4:   52800053mov w19, #0x2   // #2
   8:   aa1003f4mov x20, x16# Here we try
and use the clobbered x16 register.
   c:   b90002b3str w19, [x21]
c: R_AARCH64_LDST32_ABS_LO12_NC .bss
  10:   9400bl  0 
10: R_AARCH64_CALL26bar
  14:   9000adrpx0, 4 
14: R_AARCH64_ADR_GOT_PAGE  v
  18:   d28001a3mov x3, #0xd// #13
  1c:   52800062mov w2, #0x3// #3
  20:   f940ldr x0, [x0]
20: R_AARCH64_LD64_GOT_LO12_NC  v

[Bug target/95798] [10/11 Regression] Initialization code --- suboptimal

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|Initialization code --- |[10/11 Regression]
   |suboptimal  |Initialization code ---
   ||suboptimal
   Last reconfirmed||2020-06-22
 CC||jakub at gcc dot gnu.org,
   ||rdapp at gcc dot gnu.org
   Target Milestone|--- |10.2
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
The 9 -> 10 regression started with
r10-2806-gdf7d46d925c7baca7bf9961aee900876d8aef225
since which the IL is much larger and the resulting code less efficient.
The testcase as written is just weird, it is an expensive check whether the
program is called with multiple of 128 arguments >= 1024 arguments (otherwise
it invokes UB).

Adjusted testcase that is more meaningful:
void bar (unsigned long long *, int);

void
foo (int y, unsigned long long z)
{
  unsigned long long x[1024];
  unsigned long long i = y % 127;
  __builtin_memset (x, -1, sizeof (x));
  x[i] = 0;
  x[i + 1] = 0;
  x[i + 2] = 0;
  x[i + 3] = 0;
  x[i + 4] = 0;
  x[i + 5] = 0;
  x[i + 6] = 0;
  x[i + 7] = 0;
  bar (x, y);
}

[Bug target/95798] [10/11 Regression] Initialization code --- suboptimal

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Perhaps the change should be guarded on single_use?

[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

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

commit r11-1583-gd57bf2315e024ada3393ad967e8f632121383c9c
Author: Mark Eggleston 
Date:   Wed Jun 10 11:41:56 2020 +0100

Fortran  : Missing gcc-internal-format PR42693

Messages in gfc_arith_error contain gcc internal format specifiers
which should be enclosed in G_() in order to be correctly translated.

2020-06-22  Mark Eggleston  

gcc/fortran/

PR fortran/42693
* arith.c (gfc_arith_error): Enclose strings in G_() instead
of _().

[Bug tree-optimization/95792] Failure to optimize assignment of struct members to memset

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
store-merging could do this, just rewrite it into MEM[whatever] = {}; if it is
large and let the expansion deal with it.

[Bug tree-optimization/95817] New: Failure to optimize shift with constant to compare

[gabravier at gmail dot com]

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

Bug ID: 95817
   Summary: Failure to optimize shift with constant to compare
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(int a)
{
return (!(a >> 7));
}

This can be optimized to `return !((unsigned)a > 127);`. This transformation is
done by LLVM, but not by GCC.

[Bug bootstrap/94998] [10 Regression] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

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

commit r10-8336-g2c7ae01349f779f1d4e66d8831052ee59f9c948b
Author: H.J. Lu 
Date:   Tue May 12 10:39:42 2020 -0700

Enable CET in cross compiler if possible

Don't perform CET run-time check for host when cross compiling.  Instead,
enable CET in cross compiler if possible so that it will run on both CET
and non-CET hosts.

config/

PR bootstrap/94998
* cet.m4 (GCC_CET_HOST_FLAGS): Enable CET in cross compiler if
possible.

libiberty/

PR bootstrap/94998
* configure: Regenerated.

lto-plugin/

PR bootstrap/94998
* configure: Regenerated.

(cherry picked from commit d17cdc17c90ce77cb90c569322c1f241d3530cec)

[Bug bootstrap/94998] [10 Regression] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #10 from H.J. Lu  ---
Fixed for GCC 11 and GCC 10.2.

[Bug fortran/95585] ICE in gfc_check_reshape, at fortran/check.c:4751

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

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

commit r11-1584-gd9aed5f1ccffc019ddf980e349caa3d092755cb4
Author: Mark Eggleston 
Date:   Thu Jun 11 06:42:36 2020 +0100

Fortran  : ICE in gfc_check_reshape PR95585

Issue an error where an array is used before its definition
instead of an ICE.

2020-06-22  Steven G. Kargl  

gcc/fortran/

PR fortran/95585
* check.c (gfc_check_reshape): Add check for a value when
the symbol has an attribute flavor FL_PARAMETER.

2020-06-22  Mark Eggleston  

gcc/testsuite/

PR fortran/95585
* gfortran.dg/pr95585.f90: New test.

[Bug target/95791] Unnecessary vzeroupper when only using zmm16 through zmm31

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:9302421e71e85b4d3766a534ed9e1c4ae1e7a6ca

commit r11-1585-g9302421e71e85b4d3766a534ed9e1c4ae1e7a6ca
Author: H.J. Lu 
Date:   Sat Jun 20 16:02:42 2020 -0700

x86: Skip EXT_REX_SSE_REG_P for vzeroupper optimization

Skip EXT_REX_SSE_REG_P for vzeroupper optimization since upper 16 vector
registers don't trigger SSE <-> AVX transition penalty.

gcc/

PR target/95791
* config/i386/i386.c (ix86_dirflag_mode_needed): Skip
EXT_REX_SSE_REG_P.

gcc/testsuite/

PR target/95791
* gcc.target/i386/pr95791.c: New test.

[Bug c/95818] New: wrong "used uninitialized" warning

[ferruh.yigit at intel dot com]

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

Bug ID: 95818
   Summary: wrong "used uninitialized" warning
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ferruh.yigit at intel dot com
  Target Milestone: ---

gcc (GCC) 11.0.0 20200621 (experimental)

Sorry, I couldn't able to reproduce with test code, I will copy-paste the real
code that causes the warning hoping it helps.

Warning [1] and code that causes it [2], struct in question [3].

As you can see all the fields of the struct has been set before used, so not
sure why giving used uninitialized warning.



[1]
.../drivers/net/iavf/iavf_ethdev.c: In function ‘iavf_dev_link_update’:
.../drivers/net/iavf/iavf_ethdev.c:641:6: error: ‘new_link’ is used
uninitialized [-Werror=uninitialized]
  641 |  if (rte_atomic64_cmpset((uint64_t *)&dev->data->dev_link,
  |  ^
  642 | *(uint64_t *)&dev->data->dev_link,
  | ~~
  643 | *(uint64_t *)&new_link) == 0)
  | ~~~
.../drivers/net/iavf/iavf_ethdev.c:596:22: note: ‘new_link’ declared here
  596 |  struct rte_eth_link new_link;
  |  ^~~~
cc1: all warnings being treated as error



[2]
iavf_dev_link_update(struct rte_eth_dev *dev,
__rte_unused int wait_to_complete)
{
struct rte_eth_link new_link;
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);

/* Only read status info stored in VF, and the info is updated
 *  when receive LINK_CHANGE evnet from PF by Virtchnnl.
 */
switch (vf->link_speed) {
case 10:
new_link.link_speed = ETH_SPEED_NUM_10M;
break;
case 100:
new_link.link_speed = ETH_SPEED_NUM_100M;
break;
case 1000:
new_link.link_speed = ETH_SPEED_NUM_1G;
break;
case 1:
new_link.link_speed = ETH_SPEED_NUM_10G;
break;
case 2:
new_link.link_speed = ETH_SPEED_NUM_20G;
break;
case 25000:
new_link.link_speed = ETH_SPEED_NUM_25G;
break;
case 4:
new_link.link_speed = ETH_SPEED_NUM_40G;
break;
case 5:
new_link.link_speed = ETH_SPEED_NUM_50G;
break;
case 10:
new_link.link_speed = ETH_SPEED_NUM_100G;
break;
default:
new_link.link_speed = ETH_SPEED_NUM_NONE;
break;
}

new_link.link_duplex = ETH_LINK_FULL_DUPLEX;
new_link.link_status = vf->link_up ? ETH_LINK_UP :
 ETH_LINK_DOWN;
new_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
ETH_LINK_SPEED_FIXED);

if (rte_atomic64_cmpset((uint64_t *)&dev->data->dev_link,
*(uint64_t *)&dev->data->dev_link,
*(uint64_t *)&new_link) == 0)
return -1;

return 0;
}



[3]
struct rte_eth_link {
uint32_t link_speed;/**< ETH_SPEED_NUM_ */
uint16_t link_duplex  : 1;  /**< ETH_LINK_[HALF/FULL]_DUPLEX */
uint16_t link_autoneg : 1;  /**< ETH_LINK_[AUTONEG/FIXED] */
uint16_t link_status  : 1;  /**< ETH_LINK_[DOWN/UP] */
} __rte_aligned(8);  /**< aligned for atomic64 read/write */

[Bug c/95818] wrong "used uninitialized" warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||24639
   Last reconfirmed||2020-06-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
please provide complete preprocessed source


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug target/95798] [10/11 Regression] Initialization code --- suboptimal

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Partially related, using the following -O2 -fno-ipa-icf:
void
foo (int x, int *p)
{
  p[x + 1] = 1;
}

void
bar (int x, int *p)
{
  p[x + 1UL] = 1;
}

void
baz (int x, int *p)
{
  unsigned long l = x;
  l++;
  p[l] = 1;
}

void
qux (int x, int *p)
{
  unsigned long l = x + 1;
  p[l] = 1;
}
we get the same 3 insn functions for the first 3 cases and 4 insn for the last
one.  I'm surprised that we treat foo and qux differently, as x + 1 has
undefined overflow, so (unsigned long) (x + 1) can be implemented with x + 1UL
and when used in address arithmetics it should be beneficial like that (so
shall e.g. expansion optimize it, or ivopts, or isel)?

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2020-06-22

--- Comment #5 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #4)
> As other major compilers reject this by default, I just suggest GCC should
> emit a appropriate diagnostic message (maybe a warning is fine).

What practical impact does this have on any real world code?

Why should we spend time on that, rather than the million other things we have
to fix?

Obviously in an ideal world GCC would be perfect, but the majority of your bug
reports are asking for time to be spent on things that just don't matter.

If you really want it fixed, you can always do it yourself:
https://gcc.gnu.org/contribute.html

[Bug ipa/95775] Command line argument for target_clones?

[yyc1992 at gmail dot com]

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

--- Comment #2 from Yichao Yu  ---
> But it will blow up code-size considerably.
> So without some major work I don't think simply slapping target_clones on 
> each function is going to fly in practice.

I mean, it'll blow up not much more than the number of targets. I do agree this
is not something that the compiler should just do automatically and especially
not for big libraries and the user has to ask for it.

However, I don't believe code side consumes most memory on any modern desktop
or server systems and when using shared library different process won't even
consume much more memory anyway. It's for sure still the user's choice but OTOH
I think the compiler shouldn't have to make this choice for the user.

Additionally, there are some libraries, like math heavy ones, where virtually
every single functions could benefit from this. Those are the ones that I would
like to apply this option too. I'm also hoping, and I forgot to mention this in
the first post, that this can just work on gfortran as well...

> Eventually it should be possible to do sth like target_clones(auto) where 
> with a new option, the target (or the user) can define "default" targets to 
> clone for but the user still figures which are the important functions to 
> optimize

In julia I'm currently using a simple heuristic of detecting floating point
operation, vector operation and loops...

> [and GCC may, via IPA "spread" the cloned cgraph portion a bit].

and I do this in julia too.

[Bug c/95777] Allow specifying more than one target options at the same time in target and target_clones attribute

[yyc1992 at gmail dot com]

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

--- Comment #2 from Yichao Yu  ---
I only tested this with `target_clones` and it seems that I misread the
document for `target`. So this is only an issue with `target_clones` attribute.
`target` support this just fine.

So to be more clear, using an example from the doc, it seems impossible to do
the equivalent of `target("sse4.1,arch=core2")` using `target_clones`. Doing
`target_clones("sse4.1,arch=core2")` will create two functions instead of one.
(of course in reality what I might actually want is to make `target_clones` do
`target("sse4.1,arch=core2")` and target("default")).

[Bug target/95791] Unnecessary vzeroupper when only using zmm16 through zmm31

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 11.

[Bug c++/95262] Taking address of function pointer doesn't do full concept overload resolution

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-22
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Patrick Palka  ---
Confirmed.

[Bug c++/94260] Specific friend function inside c++20 concept-constrained class template triggers 'not usable in a constant expression' error

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-22
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Patrick Palka  ---
Thanks for the report.  I'm unable to reproduce this issue against GCC 10.1 or
current trunk.  Are you still able to reproduce?

[Bug c++/95054] internal compiler error while overloading class constructor using variadic templates constraint by c++20 concepts

[breyer.marcel at web dot de]

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

Marcel Breyer  changed:

   What|Removed |Added

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

--- Comment #1 from Marcel Breyer  ---
This has been fixed on the current GCC trunk.

https://godbolt.org/z/Lnh9d-

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[haoxintu at gmail dot com]

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

--- Comment #6 from Haoxin Tu  ---
(In reply to Jonathan Wakely from comment #5)

> What practical impact does this have on any real world code?
> Why should we spend time on that, rather than the million other things we
> have to fix?

Hi, Jonathan,
This is the question I am always thinking about. GCC is a big software somehow,
and that's impossible to treat every part equally when it has issues. 


> Obviously in an ideal world GCC would be perfect, but the majority of your
> bug reports are asking for time to be spent on things that just don't matter.

My team nowadays are focusing on improving the quality of mature compilers. We
just developed a tool to test them and then found those bugs. Our method might
not perfect now and it only found some issues in FE, and we are designing a
more effective approach to focus on the ME or BE parts (those parts might more
important for GCC), it still needs some time for us. So I totally agree with
that you said, and maybe later reports will be more useful for you.

> If you really want it fixed, you can always do it yourself:
> https://gcc.gnu.org/contribute.html

This is a really constructive suggestion for me. I will try to do this at some
time.

Anyway, thanks for your kind and helpful response!

[Bug c/95777] Allow specifying more than one target options at the same time in target and target_clones attribute

[yyc1992 at gmail dot com]

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

--- Comment #3 from Yichao Yu  ---
And for backward compatibility maybe
`target_clones("(sse4.1,arch=core2),default")` would work?

[Bug c++/95819] New: ICE: Segmentation fault signal terminated program cc1plus

[haoxintu at gmail dot com]

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

Bug ID: 95819
   Summary: ICE: Segmentation fault signal terminated program
cc1plus
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This case bug.cc, reduced by C-Reduce, makes GCC crashed.

$cat bug.cc
wchar_t  a  =  [] (struct  {


$g++ bug.cc
bug.cc:1:33: error: types may not be defined in parameter types
1 |  wchar_t  a  =  [] (struct  {
  | ^
bug.cc:2: error: expected ‘}’ at end of input
bug.cc:1:33: note: to match this ‘{’
1 |  wchar_t  a  =  [] (struct  {
  | ^
bug.cc:2: error: expected ‘,’ or ‘...’ at end of input
bug.cc:1:34: error: expected ‘)’ at end of input
1 |  wchar_t  a  =  [] (struct  {
  |~ ^
  |  )
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

My GCC version
$g++ --version
g++ (GCC) 11.0.0 20200605 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/95820] New: ICE in splice_late_return_type, at cp/pt.c:29034

[haoxintu at gmail dot com]

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

Bug ID: 95820
   Summary: ICE in splice_late_return_type, at cp/pt.c:29034
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This case bug.cc, reduced by C-Reduce, crashed GCC.

$cat bug.cc
constexpr (*a)()->bool,

$g++ -w -fpermissive small.cc
bug.cc:1:19: internal compiler error: in splice_late_return_type, at
cp/pt.c:29034
1 | constexpr (*a)()->bool,
  |   ^~~~
0x5cd1f6 splice_late_return_type(tree_node*, tree_node*)
../../gcc/cp/pt.c:29034
0x67db9a grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:12154
0x684228 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5231
0x70c8ce cp_parser_init_declarator
../../gcc/cp/parser.c:20817
0x6efcc2 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0x7159c6 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x7160b4 cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x7160b4 c_parse_file()
../../gcc/cp/parser.c:44034
0x7de74b c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

My GCC version is
$g++ --version
g++ (GCC) 11.0.0 20200605 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/95768] [11 Regression] -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Component|tree-optimization   |c++

--- Comment #3 from Martin Sebor  ---
This is the same case of the pretty printer not handling an expression as
pr95580, except this one is in the C++ front end (the code is duplicated almost
verbatim between the two).  tree-ssa-uninit.c calls:

  if (warning_at (location, OPT_Wuninitialized,
  "%G%qE is used uninitialized", stmt, rhs))

with this STMT and its RHS:

  b$4$g_7 = MEM  [(const struct m &)_6 + 4];

expr_to_string() in cp/error.c then does this with the RHS:

case MEM_REF:
  if (TREE_CODE (TREE_OPERAND (t, 0)) == ADDR_EXPR
  && integer_zerop (TREE_OPERAND (t, 1)))
dump_expr (pp, TREE_OPERAND (TREE_OPERAND (t, 0), 0), flags);
  else
{
  pp_cxx_star (pp);
  if (!integer_zerop (TREE_OPERAND (t, 1)))
{
  pp_cxx_left_paren (pp);
  if (!integer_onep (TYPE_SIZE_UNIT
 (TREE_TYPE (TREE_TYPE (TREE_OPERAND (t,
0))

but because the MEM_REF first operand is not a ADDR_EXPR the else branch trips
the ICE in integer_zerop() because because the RHS type is void* whose
TYPE_SIZE_UNIT is null that integer_zerop() is not prepared to handle.

[Bug c++/95820] ICE in splice_late_return_type, at cp/pt.c:29034

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu  ---
(In reply to Haoxin Tu from comment #0)

> $g++ -w -fpermissive small.cc

Here is a mistake, and it should be

$g++ -w -fpermissive bug.cc

[Bug c/95818] wrong "used uninitialized" warning

[ferruh.yigit at intel dot com]

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

--- Comment #2 from Ferruh YIGIT  ---
.i output [1] and .s output [2] below, please let me know if the request was
something else.

[1]
int
iavf_dev_link_update(struct rte_eth_dev *dev,
  __attribute__((__unused__)) int wait_to_complete)
{
 struct rte_eth_link new_link;
 struct iavf_info *vf = (&((struct iavf_adapter *)dev->data->dev_private)->vf);




 switch (vf->link_speed) {
 case 10:
  new_link.link_speed = 10;
  break;
 case 100:
  new_link.link_speed = 100;
  break;
 case 1000:
  new_link.link_speed = 1000;
  break;
 case 1:
  new_link.link_speed = 1;
  break;
 case 2:
  new_link.link_speed = 2;
  break;
 case 25000:
  new_link.link_speed = 25000;
  break;
 case 4:
  new_link.link_speed = 4;
  break;
 case 5:
  new_link.link_speed = 5;
  break;
 case 10:
  new_link.link_speed = 10;
  break;
 default:
  new_link.link_speed = 0;
  break;
 }

 new_link.link_duplex = 1;
 new_link.link_status = vf->link_up ? 1 :
  0;
 new_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
(1 << 0));

 if (rte_atomic64_cmpset((uint64_t *)&dev->data->dev_link,
*(uint64_t *)&dev->data->dev_link,
*(uint64_t *)&new_link) == 0)
  return -1;

 return 0;
}



[2]
.globl  iavf_dev_link_update
.type   iavf_dev_link_update, @function iavf_dev_link_update:
.LFB6034:
.cfi_startproc
movq24(%rdi), %rcx
movq96(%rcx), %rsi
movl476(%rsi), %edx
cmpl$2, %edx
je  .L5
jbe .L28
cmpl$5, %edx
je  .L5
jbe .L29
cmpl$10, %edx
movl$0, %eax
cmovne  %rax, %rdx
.L5:
movl112(%rcx), %eax
movzbl  473(%rsi), %esi
notl%eax
andl$1, %eax
sall$2, %esi
leal1(%rax,%rax), %eax
orl %esi, %eax
andl$7, %eax
salq$32, %rax
orq %rax, %rdx
movq104(%rcx), %rax
#APP
# 33 "/root/development/dpdk-next-net/build/include/rte_atomic_64.h" 1
lock ; cmpxchgq %rdx, 104(%rcx);sete %al;
# 0 "" 2
#NO_APP
cmpb$1, %al
sbbl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L29:
cmpl$25000, %edx
je  .L5
cmpl$4, %edx
je  .L5
.L11:
xorl%edx, %edx
jmp .L5
.p2align 4,,10
.p2align 3
.L28:
cmpl$1000, %edx
je  .L5
jbe .L30
cmpl$1, %edx
movl$0, %eax
cmovne  %rax, %rdx
jmp .L5
.p2align 4,,10
.p2align 3
.L30:
cmpl$10, %edx
je  .L5
cmpl$100, %edx
je  .L5
jmp .L11
.cfi_endproc
.LFE6034:
.size   iavf_dev_link_update, .-iavf_dev_link_update
.p2align 4

[Bug c++/95768] [11 Regression] -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
In fact, the same test case as for pr95580 triggers the C++ ICE as well:

$ gcc -O1 -S -Wall -fno-tree-dce -xc++
/src/gcc/trunk/gcc/testsuite/gcc.dg/pr95580.c
‘
during GIMPLE pass: uninit
In function ‘void foo(int)’:
Segmentation fault
8 | foo (int x)
  | ^~~
0x15c3040 crash_signal
/src/gcc/trunk/gcc/toplev.c:328
0x9559fc location_wrapper_p(tree_node const*)
/src/gcc/trunk/gcc/tree.h:4004
0x955a79 tree_strip_any_location_wrapper(tree_node*)
/src/gcc/trunk/gcc/tree.h:4016
0x1a04ede integer_onep(tree_node const*)
/src/gcc/trunk/gcc/tree.c:2573
0xa9878e dump_expr
/src/gcc/trunk/gcc/cp/error.c:2386
0xa9b4f4 expr_to_string(tree_node*)
/src/gcc/trunk/gcc/cp/error.c:3109
0xa9f1e7 cp_printer
/src/gcc/trunk/gcc/cp/error.c:4264
0x270616b pp_format(pretty_printer*, text_info*)
/src/gcc/trunk/gcc/pretty-print.c:1475
0x26df21d diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/src/gcc/trunk/gcc/diagnostic.c:1159
0x26df841 diagnostic_impl
/src/gcc/trunk/gcc/diagnostic.c:1309
0x26e00bd warning_at(unsigned int, int, char const*, ...)
/src/gcc/trunk/gcc/diagnostic.c:1446
0x1915da3 maybe_warn_operand
/src/gcc/trunk/gcc/tree-ssa-uninit.c:431
0x1916782 warn_uninitialized_vars
/src/gcc/trunk/gcc/tree-ssa-uninit.c:640
0x191b3e7 execute
/src/gcc/trunk/gcc/tree-ssa-uninit.c:2936
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++/95820] ICE in splice_late_return_type, at cp/pt.c:29034

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-22
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug tree-optimization/95804] ice in generate_code_for_partition, at tree-loop-distribution.c:1323

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to bin cheng from comment #2)
> Whew, this part IS can of worms.  Will investigate it.

Great. The testcase I provided came from a C source code generator
called ccg. 

Here is another C test case which produces the same compiler crash with -O3:

$ more bug625.c
int a, b, c, d, e, f;
void g() {
  short *h = d;
  char *i = &b;
  for (; e; e++) {
for (; f; f++) {
  b = 3;
  if ((c = 8) >= *i)
a = 5 ? *h : 0;
  h = g;
}
i = &c;
  }
}

[Bug fortran/95708] [9/10/11 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13002

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:647340c92a042e8e6f7d004637f07060dbde49c0

commit r11-1586-g647340c92a042e8e6f7d004637f07060dbde49c0
Author: Mark Eggleston 
Date:   Mon Jun 22 13:35:01 2020 +0100

Fortran  : ICE in resolve_fl_procedure PR95708

Now issues an error "Intrinsic procedure 'num_images' not
allowed in PROCEDURE" instead of an ICE.

2020-06-22  Steven G. Kargl  

gcc/fortran/

PR fortran/95708
* intrinsic.c (add_functions): Replace CLASS_INQUIRY with
CLASS_TRANSFORMATIONAL for intrinsic num_images.
(make_generic): Replace ACTUAL_NO with ACTUAL_YES for
intrinsic team_number.
* resolve.c (resolve_fl_procedure): Check pointer ts.u.derived
exists before using it.

2020-06-22  Mark Eggleston  

gcc/testsuite/

PR fortran/95708
* gfortran.dg/pr95708.f90: New test.

[Bug tree-optimization/95761] [11 regression] ICE during GIMPLE pass: slp verify_ssa failed

[dimhen at gmail dot com]

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

--- Comment #6 from Dmitry G. Dyachenko  ---
r11-1582 PASS for me x_2.i and original (non-reduced) compilation

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #6)
> My team nowadays are focusing on improving the quality of mature compilers.
> We just developed a tool to test them and then found those bugs. Our method
> might not perfect now and it only found some issues in FE, and we are
> designing a more effective approach to focus on the ME or BE parts (those
> parts might more important for GCC), it still needs some time for us. So I
> totally agree with that you said, and maybe later reports will be more
> useful for you.

OK, thanks for the background information.

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Mon, Jun 22, 2020 at 09:10:25AM +, drikosev at gmail dot com wrote:
> 
> --- Comment #3 from Ev Drikos  ---
> 
> Hello,
> 
> Perhaps, an additional check in file resolve.c might be necessary, or
> one would have to adjust one-two "common*.f" test cases.
> 
> Hope this helps,
> Ev. Drikos

Yes, indeed.  Some testcases may need to be updated to
account for the new error message or one may needs to
use the old testcase to adjust the conditional to not
trigger for the older testcase.  Also, note that I've
found invalid Fortran in testcases as I've fixed a 
bug.

When parsing a file, gfortran runs a series of matchers.
If a failure is detected in a matcher an error message
is queued, and then other matchers are run.  If no matcher
succeeds in matching a statement, the last queued error
message(s) is(are) emitted and gfortran will exit.  If a
matcher does match a statement, then the error queue is
cleared and the next statement is parsed.  Sometimes a
new patch will find invalid Fortran in the testsuite.

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Thanks for the pointers.  Putting the mangled name in a target-specific
attribute (like we do for SVE) seems to fix it.  It actually also keeps
the testcase in comment 4 “working”, which is unexpected (to me) and
seems a little dubious.  I guess it's good news for backporting though.

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

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

  Attachment #48723|0   |1
is obsolete||

--- Comment #29 from Rafael Avila de Espindola  ---
Created attachment 48771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48771&action=edit
Testcase without lambda coroutines

I modified the testcase to also build with clang and not depend on async
lambdas. This still reproduces the problem with gcc with undefined behaviour
sanitizer, but works with with clang and sanitizers and gcc with valgrind.

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

[iains at gcc dot gnu.org]

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

--- Comment #30 from Iain Sandoe  ---
(In reply to Rafael Avila de Espindola from comment #29)
> Created attachment 48771 [details]
> Testcase without lambda coroutines
> 
> I modified the testcase to also build with clang and not depend on async
> lambdas. This still reproduces the problem with gcc with undefined behaviour
> sanitizer, but works with with clang and sanitizers and gcc with valgrind.

thanks, I think I have a fix for this locally - but not ready to post just yet.

[Bug tree-optimization/95821] New: Failure to optimize strchr to use memchr for string constant

[gabravier at gmail dot com]

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

Bug ID: 95821
   Summary: Failure to optimize strchr to use memchr for string
constant
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

auto f(char c)
{
return strchr("123", c);
}

This can be optimized to `return memchr("123", c, 4)`. This transformation is
done by LLVM, but not by GCC.

[Bug tree-optimization/95821] Failure to optimize strchr to use memchr for string constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For -Os that is an undesirable change because it makes the code larger.  But
otherwise yes, seems useful.

[Bug c++/95822] New: [coroutines] compiler internal error with local object with noexcept false destructor

[victor.burckel at gmail dot com]

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

Bug ID: 95822
   Summary: [coroutines] compiler internal error with local object
with noexcept false destructor
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.burckel at gmail dot com
  Target Milestone: ---

It seems that when a coroutine contains a local object whose destructor is
marked as noexcept(false), gcc reaches an unexpected state and aborts.
When compiling the following code with gcc10.1.0 (-std=c++20 -fcoroutines), I
get a compiler internal error: 
> internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2830

Making the destructor noexcept fixes the error. I  got the error when using
boost log within a couroutine. It uses a record_pump whose destructor is not
noexcept.

I managed to reproduce with godbolt (both gcc10.1 and gcc trunk give me the
assertion)
https://godbolt.org/z/6JtKsU

#include 

struct task {
  struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_void() {}
task get_return_object() { return task{}; }
void unhandled_exception() noexcept {}
  };

  ~task() noexcept {}

  bool await_ready() const noexcept { return false; }
  void await_suspend(std::coroutine_handle<>) noexcept {}
  void await_resume() noexcept {}
};

struct Error {
  ~Error() noexcept(false) {}
};

task g();
task f() {
  Error error;
  co_await g();
}

[Bug c++/93788] Segfault caused by infinite loop in cc1plus

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||haoxintu at gmail dot com

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

[Bug c++/95819] ICE: Segmentation fault signal terminated program cc1plus

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Found a dup.

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

[Bug c++/95823] New: [coroutines] compiler internal error in captures_temporary,

[victor.burckel at gmail dot com]

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

Bug ID: 95823
   Summary: [coroutines] compiler internal error in
captures_temporary,
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.burckel at gmail dot com
  Target Milestone: ---

I get a compiler internal error when passing a value to a coroutine that is
retrieved through two inderections within smart pointers (I don't get the error
with raw pointers, that's the smallest piece of code I was able to produce).
> internal compiler error: in captures_temporary, at cp/coroutines.cc:2717

It can be easily worked around by making a local variable containing the value.
Of course the code would crash in runtime as the pointers are not initialized,
but I get the same error when initializing them.

I managed to reproduce with godbolt (both gcc10.1 and gcc trunk give me the
assertion)
https://godbolt.org/z/XarC_M

#include 
#include 

struct task {
  struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_void() {}
task get_return_object() { return task{}; }
void unhandled_exception() noexcept {}
  };

  ~task() noexcept {}

  bool await_ready() const noexcept { return false; }
  void await_suspend(std::coroutine_handle<>) noexcept {}
  void await_resume() noexcept {}
};

struct Id
{
std::unique_ptr value;
};

task g(int);

task f() {
std::unique_ptr id;
co_await g(*id->value);
}

[Bug c++/95824] New: [coroutines] compiler crash

[victor.burckel at gmail dot com]

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

Bug ID: 95824
   Summary: [coroutines] compiler crash
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.burckel at gmail dot com
  Target Milestone: ---

The following code sample makes the gcc 10.1.0 compiler crash with segmentation
fault (compiled with -std=c++20 -fcoroutines). Gcc trunk generates an assertion
> internal compiler error: tree check: expected function_type or method_type, 
> have pointer_type in captures_temporary, at cp/coroutines.cc:2690

That's the smallest piece of code I was able to reproduce on gcc 10.1.0
(removing the virtual from the makeId method or removing the virtual
inheritance from the exception fixes the issue). 
On gcc trunk the exception and base classes are not necessary to generate the
assertion.

I initially got this issue when invoking a virtual method to get a feed a
parameter to a coroutine, with boost::archive::archive_exception included,
which virtually inherits from std::exception.

I managed to reproduce with godbolt
https://godbolt.org/z/tBmRxJ

#include 

struct task {
  struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_void() {}
task get_return_object() { return task{}; }
void unhandled_exception() noexcept {}
  };

  ~task() noexcept {}

  bool await_ready() const noexcept { return false; }
  void await_suspend(std::coroutine_handle<>) noexcept {}
  void await_resume() noexcept {}
};

struct base
{
virtual ~base() = default;
};

class exception : public virtual base
{};

struct factory
{
virtual ~factory() = default;
virtual int makeId() const;
};

task g(int);

task f(factory& factory) {
co_await g(factory.makeId());
}

[Bug bootstrap/95805] [11 regression] gcc/recog.h:301:30: error: too many arguments to function call, expected 1, have 2

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Fixed by g:20a2e6afa82c165bcd1a8749478e9402a25088a4.

[Bug fortran/95587] ICE in gfc_target_encode_expr, at fortran/target-memory.c:362

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8337-gc00ca04ba7e46d2d59e5a4f95ee7121cdc4ba224
Author: Harald Anlauf 
Date:   Sat Jun 20 16:05:13 2020 +0200

PR fortran/95587 - ICE in gfc_target_encode_expr, at
fortran/target-memory.c:362

EQUIVALENCE objects are subject to constraints listed in the Fortran 2018
standard, section 8.10.1.1.  These constraints are to be checked
also for CLASS variables.

gcc/fortran/
PR fortran/95587
* match.c (gfc_match_equivalence): Check constraints on
EQUIVALENCE objects also for CLASS variables.

(cherry picked from commit 5eb947601bdce59f2ff26694327ad173c51c2724)

[Bug c/95818] wrong "used uninitialized" warning

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Richard said "complete", that is the whole .i file, not just one random
function. If we cannot reproduce the issue by copying your code and compiling
it, we can't do anything about your report.

[Bug fortran/95689] [8/9/10/11 Regression] ICE in check_sym_interfaces, at fortran/interface.c:2015

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8338-gece7b4d5f0cef0811ee1a0ebbf00ba41c5cf080c
Author: Harald Anlauf 
Date:   Sat Jun 20 16:09:45 2020 +0200

PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015

With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer.  We now check that we do not
exceed the enlarged buffer size.

gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.

(cherry picked from commit 62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6)

[Bug fortran/95688] ICE in gfc_get_string, at fortran/iresolve.c:70

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:9056a5f1874eb85c74e439c4058b1e5c936b

commit r10-8340-g9056a5f1874eb85c74e439c4058b1e5c936b
Author: Harald Anlauf 
Date:   Sat Jun 20 16:14:00 2020 +0200

PR fortran/95688 - ICE in gfc_get_string, at fortran/iresolve.c:70

With submodules, name mangling of character pointer declarations produces
long
internal symbols that overflowed a static internal buffer.  Adjust the
buffer
size.

gcc/fortran/
PR fortran/95688
* iresolve.c (gfc_get_string): Enlarge static buffer size.

(cherry picked from commit cd6546ac0e8fb2f4ff2a4bb2db2363ca02bdb7ba)

[Bug fortran/95687] ICE in get_unique_hashed_string, at fortran/class.c:508

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-8339-gf067cc55d382c256308f85575bca3e42fe215541
Author: Harald Anlauf 
Date:   Sat Jun 20 16:11:48 2020 +0200

PR fortran/95687 - ICE in get_unique_hashed_string, at fortran/class.c:508

With submodules and PDTs, name mangling of interfaces may result in long
internal symbols overflowing a previously static internal buffer.  We now
set the buffer size dynamically.

gcc/fortran/
PR fortran/95687
* class.c (get_unique_type_string): Return a string with dynamic
length.
(get_unique_hashed_string, gfc_hash_value): Use dynamic result
from get_unique_type_string instead of static buffer.

(cherry picked from commit ac932bfcd21e9523fa2b880ae8138aef79da7f54)

[Bug fortran/95707] ICE in finish_equivalences, at fortran/trans-common.c:1319

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-8341-g4dd2fd9c4350529947fffc6bf257b5e22379554b
Author: Harald Anlauf 
Date:   Sat Jun 20 16:15:16 2020 +0200

PR fortran/95707 - ICE in finish_equivalences, at
fortran/trans-common.c:1319

With submodules and equivalence declarations, name mangling may result in
long internal symbols overflowing internal buffers.  We now check that
we do not exceed the enlarged buffer sizes.

gcc/fortran/
PR fortran/95707
* gfortran.h (gfc_common_head): Enlarge buffer.
* trans-common.c (gfc_sym_mangled_common_id): Enlarge temporary
buffers, and add check on length on mangled name to prevent
overflow.

(cherry picked from commit 3345e74299687de6144b87c0632018cafd4ccf3b)

[Bug c++/95789] [10/11 Regression] Const method is allowed to return non-const reference on template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
This actually started with r10-7096-gd417b4f5414d9076300ab41974a14424f722688c
so mine.

[Bug c++/95825] New: [7/8/9/10/11 Regression] boost::optional -Wuninitialized

[nok.raven at gmail dot com]

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

Bug ID: 95825
   Summary: [7/8/9/10/11 Regression] boost::optional
-Wuninitialized
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

#include 

boost::optional get()
{
  return {};
}

boost::optional foo()
{
  return get();
}

// g++ -O3 -Wall -Wextra -fsanitize=address

: In function 'boost::optional foo()':
:5:11: warning:
'.boost::optional::.boost::optional_detail::tc_optional_base::m_storage'
is used uninitialized in this function [-Wuninitialized]
5 |   return {};
  |   ^

https://godbolt.org/z/PD_qan

Most likely related to bug 86465

[Bug c++/93976] Implement P2082R1, Fixing CTAD for aggregates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/95826] New: ICE in gfc_match_decl_type_spec, at fortran/decl.c:4290

[gs...@t-online.de]

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

Bug ID: 95826
   Summary: ICE in gfc_match_decl_type_spec, at
fortran/decl.c:4290
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Moving on, this happens between name length 60 (ok) and 61 (ICE) :


$ cat z1_60.f90
program p
   type t23456789012345678901234567890123456789012345678901234567890 &
   (a23456789012345678901234567890123456789012345678901234567890, &
b23456789012345678901234567890123456789012345678901234567890)
  integer, kind ::
a23456789012345678901234567890123456789012345678901234567890
  integer, len :: 
b23456789012345678901234567890123456789012345678901234567890
   end type
   integer, parameter ::
n23456789012345678901234567890123456789012345678901234567890 = 16
   type (t23456789012345678901234567890123456789012345678901234567890 &
  (n23456789012345678901234567890123456789012345678901234567890, :)), &
  allocatable ::
x23456789012345678901234567890123456789012345678901234567890
end


$ cat z1_61.f90
program p
   type t234567890123456789012345678901234567890123456789012345678901 &
   (a234567890123456789012345678901234567890123456789012345678901, &
b234567890123456789012345678901234567890123456789012345678901)
  integer, kind ::
a234567890123456789012345678901234567890123456789012345678901
  integer, len :: 
b234567890123456789012345678901234567890123456789012345678901
   end type
   integer, parameter ::
n234567890123456789012345678901234567890123456789012345678901 = 16
   type (t234567890123456789012345678901234567890123456789012345678901 &
  (n234567890123456789012345678901234567890123456789012345678901, :)), &
  allocatable ::
x234567890123456789012345678901234567890123456789012345678901
end


$ cat z1_63.f90
program p
   type t23456789012345678901234567890123456789012345678901234567890123 &
   (a23456789012345678901234567890123456789012345678901234567890123, &
b23456789012345678901234567890123456789012345678901234567890123)
  integer, kind ::
a23456789012345678901234567890123456789012345678901234567890123
  integer, len :: 
b23456789012345678901234567890123456789012345678901234567890123
   end type
   integer, parameter ::
n23456789012345678901234567890123456789012345678901234567890123 = 16
   type (t23456789012345678901234567890123456789012345678901234567890123 &
(n23456789012345678901234567890123456789012345678901234567890123, :)),
&
  allocatable ::
x23456789012345678901234567890123456789012345678901234567890123
end


$ gfortran-11-20200621 -c z1_60.f90
$
$ gfortran-11-20200621 -c z1_61.f90
f951: internal compiler error: in gfc_match_decl_type_spec, at
fortran/decl.c:4290
0x64849f gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:4290
0x6491dc gfc_match_data_decl()
../../gcc/fortran/decl.c:6124
0x6ad323 match_word
../../gcc/fortran/parse.c:65
0x6ad323 decode_statement
../../gcc/fortran/parse.c:376
0x6aed6a next_free
../../gcc/fortran/parse.c:1280
0x6aed6a next_statement
../../gcc/fortran/parse.c:1512
0x6b03bb parse_spec
../../gcc/fortran/parse.c:3923
0x6b318c parse_progunit
../../gcc/fortran/parse.c:5852
0x6b4869 gfc_parse_file()
../../gcc/fortran/parse.c:6393
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95827] New: ICE in gfc_get_string, at fortran/iresolve.c:70

[gs...@t-online.de]

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

Bug ID: 95827
   Summary: ICE in gfc_get_string, at fortran/iresolve.c:70
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Happens between name length 59 (ok) and 60 (ICE) :


$ cat z1_59.f90
module m2345678901234567890123456789012345678901234567890123456789
   interface
  module subroutine
s2345678901234567890123456789012345678901234567890123456789
  end
   end interface
end
submodule(m2345678901234567890123456789012345678901234567890123456789) &
   n2345678901234567890123456789012345678901234567890123456789
   integer :: x2345678901234567890123456789012345678901234567890123456789[*]
end


$ cat z1_60.f90
module m23456789012345678901234567890123456789012345678901234567890
   interface
  module subroutine
s23456789012345678901234567890123456789012345678901234567890
  end
   end interface
end
submodule(m23456789012345678901234567890123456789012345678901234567890) &
   n23456789012345678901234567890123456789012345678901234567890
   integer :: x23456789012345678901234567890123456789012345678901234567890[*]
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   interface
  module subroutine
s23456789012345678901234567890123456789012345678901234567890123
  end
   end interface
end
submodule(m23456789012345678901234567890123456789012345678901234567890123) &
   n23456789012345678901234567890123456789012345678901234567890123
   integer ::
x23456789012345678901234567890123456789012345678901234567890123[*]
end


$ gfortran-11-20200621 -c z1_59.f90 -fcoarray=lib
$
$ gfortran-11-20200621 -c z1_60.f90 -fcoarray=lib
f951: internal compiler error: identifier overflow: 200
0x695169 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x69688a gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x6be1d7 gfc_get_string(char const*, ...)
../../gcc/fortran/iresolve.c:70
0x773c16 gfc_build_qualified_array
../../gcc/fortran/trans-decl.c:994
0x7761bc gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1795
0x77a340 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5302
0x72ab12 do_traverse_symtree
../../gcc/fortran/symbol.c:4162
0x77ae1b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5801
0x748fc1 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2238
0x6f3831 translate_all_program_units
../../gcc/fortran/parse.c:6294
0x6f3831 gfc_parse_file()
../../gcc/fortran/parse.c:6546
0x74021f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95828] New: ICE in resolve_select_rank, at fortran/resolve.c:9774

[gs...@t-online.de]

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

Bug ID: 95828
   Summary: ICE in resolve_select_rank, at fortran/resolve.c:9774
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Happens between name length 58 (ok) and 59 (ICE) :


$ cat z1_58.f90
module m234567890123456789012345678901234567890123456789012345678
   type t234567890123456789012345678901234567890123456789012345678
   end type
contains
   subroutine s234567890123456789012345678901234567890123456789012345678 &
  (x234567890123456789012345678901234567890123456789012345678)
  type(t234567890123456789012345678901234567890123456789012345678) :: &
   x234567890123456789012345678901234567890123456789012345678(..)
  select rank (y234567890123456789012345678901234567890123456789012345678 &
=> x234567890123456789012345678901234567890123456789012345678)
  rank (2)
  rank (3)
  rank default
  end select
   end
end


$ cat z1_59.f90
module m2345678901234567890123456789012345678901234567890123456789
   type t2345678901234567890123456789012345678901234567890123456789
   end type
contains
   subroutine s2345678901234567890123456789012345678901234567890123456789 &
  (x2345678901234567890123456789012345678901234567890123456789)
  type(t2345678901234567890123456789012345678901234567890123456789) :: &
   x2345678901234567890123456789012345678901234567890123456789(..)
  select rank (y2345678901234567890123456789012345678901234567890123456789
&
=> x2345678901234567890123456789012345678901234567890123456789)
  rank (2)
  rank (3)
  rank default
  end select
   end
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123
   end type
contains
   subroutine s23456789012345678901234567890123456789012345678901234567890123 &
  (x23456789012345678901234567890123456789012345678901234567890123)
  type(t23456789012345678901234567890123456789012345678901234567890123) ::
&
   x23456789012345678901234567890123456789012345678901234567890123(..)
  select rank
(y23456789012345678901234567890123456789012345678901234567890123 &
=> x23456789012345678901234567890123456789012345678901234567890123)
  rank (2)
  rank (3)
  rank default
  end select
   end
end


$ gfortran-11-20200621 -c z1_58.f90
$
$ gfortran-11-20200621 -c z1_59.f90
f951: internal compiler error: Segmentation fault
0xbce57f crash_signal
../../gcc/toplev.c:328
0x6cb511 resolve_select_rank
../../gcc/fortran/resolve.c:9774
0x6cb511 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11973
0x6cc6f7 resolve_codes
../../gcc/fortran/resolve.c:17257
0x6cc62e resolve_codes
../../gcc/fortran/resolve.c:17240
0x6cc7be gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17292
0x6b46f2 gfc_parse_file()
../../gcc/fortran/parse.c:6448
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95829] New: Bogus error with additional blanks in type(*)

[gs...@t-online.de]

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

Bug ID: 95829
   Summary: Bogus error with additional blanks in type(*)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
subroutine s(x)
   type( * ) :: x
end


$ cat z2.f90
subroutine s (a, b, c, d, e, f, g)
   type(*) :: a
   type(* ) :: b
   type( *) :: c
   type( * ) :: d
   type(*  ) :: e
   type(  *) :: f
   type(  *  ) :: g
end


$ gfortran-11-20200621 -c z1.f90
z1.f90:2:4:

2 |type( * ) :: x
  |1
Error: Unclassifiable statement at (1)

[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Buclaw  ---
(In reply to Witold Baryluk from comment #3)
> > The main example to demonstrate the current behaviour is correct would be 
> > the following:
> 
> ```
> extern(C)
> private final int f() {
>   return 5;
> }
> 
> auto pubf()() {
>   return f();
> }
> ```
> 
> I see, I guess you are right. I don't know how would one go to fix this to
> work correctly with existing linkers and not break other code.
> 
> Thanks for clarifications.

To close this issue, I'll leave my thoughts on a similar topic that was touched
on the D ML (this time, regarding the linkage of inline functions).

I'm of the opinion that there is no concept of external (global) or internal
(local) linkage in D.  Rather there's language linkage and module linkage.

Language linkage as in `extern(C++)`, `extern(C)`, `extern(Objective-C)`...

Module linkage as in for a given declaration resolves to the same symbol across
all TUs that import its residing module, but otherwise not strictly visible
outside of that.

It might do well to familiarize yourself with C++2a modules as a primer.  But
even then, you'll have to unlearn a lot of things.

[Bug fortran/95826] ICE in gfc_match_decl_type_spec, at fortran/decl.c:4290

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-06-22
   Priority|P3  |P4
 CC||anlauf at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
This is fixed by:

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index c8a98537e87..fd4e1dc2322 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -4095,7 +4095,7 @@ match
 gfc_match_decl_type_spec (gfc_typespec *ts, int implicit_flag)
 {
   /* Provide sufficient space to hold "pdtsymbol".  */
-  char name[GFC_MAX_SYMBOL_LEN + 1 + 3];
+  char *name = XALLOCAVEC (char, GFC_MAX_SYMBOL_LEN + 1);
   gfc_symbol *sym, *dt_sym;
   match m;
   char c;
@@ -4286,8 +4286,10 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int
implicit_flag)
  gcc_assert (!sym->attr.pdt_template && sym->attr.pdt_type);
  ts->u.derived = sym;
  const char* lower = gfc_dt_lower_string (sym->name);
- size_t len = strnlen (lower, sizeof (name));
- gcc_assert (len < sizeof (name));
+ size_t len = strlen (lower);
+ /* Reallocate with sufficient size.  */
+ if (len > GFC_MAX_SYMBOL_LEN)
+   name = XALLOCAVEC (char, len + 1);
  memcpy (name, lower, len);
  name[len] = '\0';
}

[Bug fortran/95827] ICE in gfc_get_string, at fortran/iresolve.c:70

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P4
 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-22
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

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

diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index aa9bb328a0f..73769615c20 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -47,8 +47,8 @@ along with GCC; see the file COPYING3.  If not see
 const char *
 gfc_get_string (const char *format, ...)
 {
-  /* Provide sufficient space to hold "_F.symbol.symbol_MOD_symbol".  */
-  char temp_name[4 + 2*GFC_MAX_SYMBOL_LEN + 5 + GFC_MAX_SYMBOL_LEN + 1];
+  /* Provide sufficient space for "_F.caf_token__symbol.symbol_MOD_symbol". 
*/
+  char temp_name[15 + 2*GFC_MAX_SYMBOL_LEN + 5 + GFC_MAX_SYMBOL_LEN + 1];
   const char *str;
   va_list ap;
   tree ident;

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Fix looks simple enough:

diff --git a/gcc/fortran/dependency.c b/gcc/fortran/dependency.c
index f6c68409e68..7edd5d9010d 100644
--- a/gcc/fortran/dependency.c
+++ b/gcc/fortran/dependency.c
@@ -2031,10 +2031,12 @@ ref_same_as_full_array (gfc_ref *full_ref, gfc_ref
*ref)
 return false;
   if (full_ref->u.ar.type != AR_FULL)
 return false;
   if (ref->type != REF_ARRAY)
 return false;
+  if (ref->u.ar.type == AR_FULL)
+return true;
   if (ref->u.ar.type != AR_SECTION)
 return false;

   for (i = 0; i < ref->u.ar.dimen; i++)
 {