[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Rimvydas (RJ)  ---
With configure fixed in g:6d972f5183d8d476cfb008b85e224aa9b90e628d
only missing  header issue remains in netclient.cc and
netserver.cc:
g++ -std=c++11 -g -fno-enforce-eh-specs -fno-stack-protector
-fno-threadsafe-statics -fno-exceptions -fno-rtti
-fdebug-prefix-map=/data/gg/libcody/= -W -Wall -include config.h
-I/data/gg/libcody \
  -MMD -MP -MF netclient.d -c -o netclient.o /data/gg/libcody/netclient.cc
/data/gg/libcody/netclient.cc: In function 'int Cody::OpenInet6(const char**,
const char*, int)':
/data/gg/libcody/netclient.cc:114:3: error: 'sockaddr_in6' was not declared in
this scope
   sockaddr_in6 addr;
   ^~~~
/data/gg/libcody/netclient.cc:114:3: note: suggested alternative: 'sockaddr_un'
   sockaddr_in6 addr;
   ^~~~
   sockaddr_un
/data/gg/libcody/netclient.cc:115:12: error: 'addr' was not declared in this
scope
   memset (&addr, 0, sizeof (addr));

[Bug tree-optimization/98339] New: GCC could not vectorize loop with conditional reduced add and store

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

Bug ID: 98339
   Summary: GCC could not vectorize loop with conditional reduced
add and store
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wwwhhhyyy333 at gmail dot com
  Target Milestone: ---

For testcase

void foo(
int* restrict x,  
int n,
int start,   
int m,
int* restrict ret
)   
{
for (int i = 0; i < n; i++)
{
int pos = start + i;
if ( pos <= m)
ret[0] += x[i];
}
}

with -O3 -mavx2 it could not be vectorized because ret[0] += x[i] is zero step
MASK_STORE inside loop, and dr analysis failed for zero step store.

But with manually loop store motion

void foo2(
int* restrict x,  
int n,
int start,   
int m,
int* restrict ret
)   
{
int tmp = 0;

for (int i = 0; i < n; i++)
{
int pos = start + i;
if (pos <= m)
tmp += x[i];
}

ret[0] += tmp;
}

could be vectorized. 

godbolt: https://godbolt.org/z/Kcv8hP

There is no LIM between ifcvt and vect, and current LIM could not handle
MASK_STORE. Is there any possibility to vectorize foo, like by doing loop store
motion in ifcvt instead of creating MASK_STORE?

[Bug middle-end/93644] [10/11 Regression] spurious -Wreturn-local-addr with PHI of PHI

[noloader at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Jeffrey Walton  ---
On Wed, Dec 16, 2020 at 9:05 PM eggert at cs dot ucla.edu
 wrote:
> ...
> (B) there's no way to shut off the false alarm, not even with '# pragma GCC
> diagnostic ignored "-Wreturn-local-addr"'.

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

[Bug c/94722] implement __attribute__((no_stack_protector)) function attribute

[i at maskray dot me via Gcc-bugs]

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

Fangrui Song  changed:

   What|Removed |Added

 CC||i at maskray dot me

--- Comment #7 from Fangrui Song  ---
(In reply to Martin Liška from comment #6)
> Implemented.

#include 
void foo(const char *a) { char b[34]; strcpy(b, a); }
__attribute__((no_stack_protector))
void bar(const char *a) { foo(a); }


#include 
__attribute__((no_stack_protector))
void foo(const char *a) { char b[34]; strcpy(b, a); }
void bar(const char *a) { foo(a); }

In both cases, foo can be inlined.

In Clang, the recent resolution https://reviews.llvm.org/D91816 is that a ssp
function cannot be inlined into a nossp function and a nossp function cannot be
inlined into a ssp function.

I think one argument for the no-inline behavior is that ssp conveys the
security enforcement intention and the GCC behavior may degrade the security
hardening while inlining a ssp chunk.

Previously Clang upgraded the caller from nossp to ssp after inlining. However,
that behavior caused
https://lore.kernel.org/lkml/20200422192113.gg26...@zn.tnic/T/#t
(the caller may not have set up %gs and upgrading it to ssp can break it)

The new Clang behavior also disallows a nossp callee from being inlined into a
ssp caller. That makes the rules easier to explain but I haven't thought very
clearly about the implications though.

[Bug middle-end/93195] -fpatchable-function-entries : __patchable_function_entries should consider comdat groups

[i at maskray dot me via Gcc-bugs]

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

--- Comment #10 from Fangrui Song  ---
(In reply to Jakub Jelinek from comment #9)
> I believe this broke building the kernel, see
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561974.html
> for details.

For

> ld: .init.data has both ordered [`__patchable_function_entries' in 
> init/main.o] and unordered [`.init.data' in 
> ./drivers/firmware/efi/libstub/vsprintf.stub.o] sections

ld should be flexible in mixed SHF_LINK_ORDER & non-SHF_LINK_ORDER components
in an output section
https://sourceware.org/bugzilla/show_bug.cgi?id=26256

[Bug tree-optimization/88767] 'unroll and jam' not optimizing some loops

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

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

--- Comment #13 from Jiu Fu Guo  ---
Hi Richard，

As checking the changed code as in comment 9, it seems there is another
opportunity to improve the performance:  By improving locality of array A
usage.

Unroll and jam loop1 into loop4 (or unroll and jam loop1 into loop3 after
loop2/loop4 are unrolled completely), this would reduce memory access by
reusing elements of array A. 

It seems not hard to implement this improvement from the source code aspect (as
the example code shown in comment 9). 
While I'm thinking about how to implement this in GCC.

Some concerns are here.  It is not a `perfect nest` for these loops: there are
stmts/instructions that belong to the outer loop (loop1) but outside the inner
loop(loop4). 
And even delete loop2 (or distribute loop2 out) and unroll loop4, 'store to
array C: C[(l_n*10)+l_m] +=xx` is moved out of the inner loop (loop3), but
still inside the outer loop(loop1).  This is not in favor of 'unroll and jam'.

Thanks for any comments!

BR. 
Jiufu Guo

[Bug c++/98305] spurious -Wmismatched-new-delete on template instance

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

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

Martin Sebor  changed:

   What|Removed |Added

Summary|Incomprehensible|spurious
   |-Wmismatched-new-delete |-Wmismatched-new-delete on
   |warning |template instance
   Keywords||patch

--- Comment #2 from Martin Sebor  ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562141.html

[Bug middle-end/93644] [10/11 Regression] spurious -Wreturn-local-addr with PHI of PHI

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #12 from eggert at cs dot ucla.edu ---
There are really two bugs here:

(A) GCC emits the false alarm.

(B) there's no way to shut off the false alarm, not even with '# pragma GCC
diagnostic ignored "-Wreturn-local-addr"'.

Although this bug report's replies have been about (A), even fixing (B) would
be a real help with Gnulib.

Should I file a separate bug report for (B)? I assume (B)'s easier to fix.

[Bug middle-end/93644] [10/11 Regression] spurious -Wreturn-local-addr with PHI of PHI

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #11 from eggert at cs dot ucla.edu ---
Created attachment 49783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49783&action=edit
another instance of a -Wreturn-local-addr false alarm

I ran into a different instance of the bug today, while working on another
Gnulib source file lib/canonicalize.c. A stripped-down test case attached. To
reproduce the problem:

$ gcc -O2 -S return-local-addr.i 
return-local-addr.i: In function ‘canonicalize_filename_mode’:
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
return-local-addr.i:28:25: note: declared here
   28 |   struct scratch_buffer rname_buffer;
  | ^~~~

This is with GCC 10.2.1 20201125 (Red Hat 10.2.1-9) on x86-64.

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 49782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49782&action=edit
range-op.gcda

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 49781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49781&action=edit
range-op.ii.xz

[Bug bootstrap/98338] New: [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

Bug ID: 98338
   Summary: [11 Regression] profiledbootstrap failure on
x86_64-linux
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

r11-6148 fails profiledbootstrap on x86_64-linux, the error is:
during IPA pass: icf
../../gcc/range-op.cc:3444:1: internal compiler error: in compute_fn_summary,
at ipa-fnsummary.c:3138
0x1385f82 compute_fn_summary(cgraph_node*, bool)
../../gcc/ipa-fnsummary.c:3138
0x14092d3 ipa_merge_profiles(cgraph_node*, cgraph_node*, bool)
../../gcc/ipa-utils.c:750
0x28af067 ipa_icf::sem_function::merge(ipa_icf::sem_item*)
../../gcc/ipa-icf.c:1272
0x28b7290 ipa_icf::sem_item_optimizer::merge_classes(unsigned int, unsigned
int)
../../gcc/ipa-icf.c:3420
0x28b3b85 ipa_icf::sem_item_optimizer::execute()
../../gcc/ipa-icf.c:2460
0x28b7ab4 ipa_icf_driver
../../gcc/ipa-icf.c:3584
0x28ba37e ipa_icf::pass_ipa_icf::execute(function*)
../../gcc/ipa-icf.c:3631
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Reduced testcase:
.../cc1plus -fpreprocessed range-op.ii -quiet -dumpbase range-op.cc
-dumpbase-ext .cc -mtune=generic -march=x86-64 -g -grecord-gcc-switches -O2
-Wformat-security -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wsuggest-attribute=format -Woverloaded-virtual
-Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -version
-fno-PIE -fstack-clash-protection -fcf-protection=full -fprofile-use
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -o range-op.s

I'll attach range-op.ii and range-op.gcda

[Bug bootstrap/98323] current trunk won't build with clang

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

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

--- Comment #8 from Jakub Jelinek  ---
See also http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_496

[Bug bootstrap/98323] current trunk won't build with clang

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Nathan Sidwell from comment #2)
> > stupid underspecified offsetof
> 
> Is this related to bug 65254?

Is that a bug?
Looking at both C and C++, offsetof seems underspecified, it doesn't say what
exactly the member-designator is or can be.
C talks about
static type t;
and
&(t.member-designator)
but one can put there say foo.bar.baz or qux[2].corge in that expression.
C++ defers mostly to the C standard, and if type is say
struct S { int s; };
then in C++ with
static S t;
the following
&(t.S::s)
is valid expression and S::s designates the member.
So it is unclear on what makes clang think that anything but an identifier as
member-designator is non-standard.

[Bug tree-optimization/97750] [11 Regression] ICE in during GIMPLE pass: wrestrict since r11-4135-ge864d395b4e862ce

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Macleod  ---
The op1-range expression solving for the RHS of a cast of the form

low_precision_var = (low_precision) high_precision_var

doesnt support pointers properly.

It fills in possible bit/ranges in high_precision_var when calculating outgoing
edge ranges and
   a) doesnt work for pointers (thus this trap.. there is no PLUS on pointers,
only POINTER_PLUS)
   b) is also overkill for pointers where mostly we care about zero, non-zero
and varying.

SO, fix operator_cast::op1_range()  to handle pointers better...

potential change are in testing now.

[Bug bootstrap/98323] current trunk won't build with clang

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Nathan Sidwell from comment #2)
> stupid underspecified offsetof

Is this related to bug 65254?

[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization

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

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

--- Comment #9 from Jonathan Wakely  ---
Right, this actually has nothing to do with threads.

The behaviour is exactly the same as if file1.cc contained this instead:

  void threadfunc();  

  struct StaticThread {
  StaticThread() { threadfunc(); }
  };  

  static StaticThread thread1;

A global constructor calls threadfunc() before std::cout has been initialized.
It doesn't matter whether that happens in a separate thread or not, and in
either case the solution is to include  so that a std::ios_base::Init
object is constructed before your global.

[Bug target/89581] Unneeded stack alignment on windows x86

[gabravier at gmail dot com via Gcc-bugs]

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

Gabriel Ravier  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #2 from Gabriel Ravier  ---
I can reproduce this, the code generation seems to have gotten much worse,
here's what I get with -O3 -mavx2 :

f:
  vmovq QWORD PTR [rsp-40], xmm0
  vmovq QWORD PTR [rsp-32], xmm1
  vmovapd xmm5, XMMWORD PTR [rsp-40]
  vmovq QWORD PTR [rsp-24], xmm2
  vmovq QWORD PTR [rsp-16], xmm3
  vaddpd xmm4, xmm5, XMMWORD PTR [rsp-24]
  vmovapd XMMWORD PTR [rsp-40], xmm4
  vmovsd xmm1, QWORD PTR [rsp-32]
  vmovsd xmm0, QWORD PTR [rsp-40]
  ret

[Bug c/98047] assignment does not drop qualifier as observed by typeof

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:58a45ce44a9acf3d15fada265d2a391a8e1bc960

commit r11-6165-g58a45ce44a9acf3d15fada265d2a391a8e1bc960
Author: Martin Uecker 
Date:   Wed Dec 16 23:47:52 2020 +0100

C: Drop qualifiers of assignment expressions. [PR98047]

ISO C17 6.5.15.1 specifies that the result is the
type the LHS would have after lvalue conversion.

2020-12-16  Martin Uecker  

gcc/c/
PR c/98047
* c-typeck.c (build_modify_expr): Drop qualifiers.

gcc/testsuite/
PR c/98047
* gcc.dg/qual-assign-7.c: New test.

[Bug c/98260] volatile triggers incorrect warning "set but not used"

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r11-6164-gec13758ed41936bf803640f0dd8c259c034fe4b9
Author: Martin Uecker 
Date:   Wed Dec 16 23:43:42 2020 +0100

C: Avoid incorrect warning for volatile in compound expressions [PR98260]

2020-12-16  Martin Uecker  

gcc/c/
PR c/98260
* c-parser.c (c_parser_expression): Look into
nop expression when marking expressions as read.

gcc/testsuite/
PR c/98260
* gcc.dg/unused-9.c: New test.

[Bug tree-optimization/98337] New: Failure to optimize out on-stack array construction when unneeded

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 98337
   Summary: Failure to optimize out on-stack array construction
when unneeded
   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: ---

int f(int x) {
int a[] = {0, 1};
return a[x];
}

On AMD64, with -O3, this is generated :

f(int):
  mov rax, QWORD PTR .LC0[rip]
  movsx rdi, edi
  mov QWORD PTR [rsp-8], rax
  mov eax, DWORD PTR [rsp-8+rdi*4]
  ret
.LC0:
  .long 0
  .long 1


LLVM generates this :

f(int): # @f(int)
  movsxd rax, edi
  mov eax, dword ptr [4*rax + .L__const.f(int).a]
  ret
.L__const.f(int).a:
  .long 0 # 0x0
  .long 1 # 0x1

It seems to me like not copying the entire array on the stack makes for faster
code.

[Bug fortran/98336] New: [OOP] CLASS assignment to derived-type component does not use __copy/allocate

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

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

Bug ID: 98336
   Summary: [OOP] CLASS assignment to derived-type component does
not use __copy/allocate
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

I tried the following:

  forall (i=1:5) f(i)%f = b

but looking at the dump, I see:
   f[i.0 + -1].f = VIEW_CONVERT_EXPR(b);

EXPECTED: Memory allocation + __copy call.

Likewise with the DO loop.

(I started with this as I wondered whether I need to add a gfc_find_vtab call
to  gfc_resolve_assign_in_forall or not → PR fortran/92587.)


! { dg-do run }
!
! Cf. PR 86484:[OOP] Undefined symbol when using polymorphic intrinsic
assignment
! and PR fortran/92587
! 
program test_assign
  implicit none

  type :: foo_t
  end type
  type, extends (foo_t) :: bar_t
   integer :: j
  end type

  type t
 class(foo_t), allocatable :: f
  end type t
  type(t) :: f(5)
  type(bar_t)   :: b
  integer :: i
  b%j = 42 
! VARIANT 1
!  do i = 1, 5
!f(i)%f = b
!  end do
! VARIANT 2
  forall (i=1:5) f(i)%f = b

  do i = 1, 5
associate (x => f(i)%f)
  select type(x)
type is (bar_t)
  if (x%j /= 42) stop 1
  x%j = 10*i
class default
  stop 2
  end select
end associate
  end do

  do i = 1, 5
select type(x => f(i)%f)
  class is (bar_t)
if (x%j /= 10*i) stop 3
  class default
stop 4
end select
  end do
end

[Bug rtl-optimization/98335] New: [9/10/11 Regression] Poor code generation for partial struct initialization

[mcolavita at fb dot com via Gcc-bugs]

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

Bug ID: 98335
   Summary: [9/10/11 Regression] Poor code generation for partial
struct initialization
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcolavita at fb dot com
  Target Milestone: ---

Consider the following code:

  struct Data {
char a;
int b;
  };

  char c;

  Data val(int idx) {
return { c };
  }

On x86-64 (with sizeof(char) = 1 and sizeof(int) = 4), val() can be implemented
with a single mov to %rax. With -O3, g++ produces the following inefficient
output:

xorl%eax, %eax
movb$0, -18(%rsp)
movabsq $72057594037927935, %rdx
movw%ax, -20(%rsp)
movl$0, -24(%rsp)
andq-24(%rsp), %rdx
movq%rdx, %rax
salq$8, %rax
movbc(%rip), %al
ret

Similar outputs are seen for any level of optimization above O0 on GCC 9, 10,
and 11. The bug is not present in GCC 8.

Reasonable code is generated if the second field of the struct is explicitly
initialized to a constant, either in the struct definition or the initializer.

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/98297] [8/9/10/11 Regression] ICE in cp_parser_elaborated_type_specifier, at cp/parser.c:19653

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
8, 9 & 10 fixed

[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-December/055430.html

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

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #47 from abebeos at lazaridis dot com ---
Relevant news:

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562114.html

[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
I'm regtesting the following patch candidate:

diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index adc6b8fefb5..e35b2f9ed34 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -3951,7 +3951,8 @@ check_forall_dependencies (gfc_code *c, stmtblock_t *pre,
stmtblock_t *post)
  pointer components.  We therefore leave these to their
  own devices.  */
   if (lsym->ts.type == BT_DERIVED
-   && lsym->ts.u.derived->attr.pointer_comp)
+  && (lsym->ts.u.derived->attr.pointer_comp
+ || lsym->ts.u.derived->attr.alloc_comp))
 return need_temp;

   new_symtree = NULL;

[Bug fortran/98307] use "allocatable" instead of "pointer" (forall_3.f90)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
  Known to fail||10.2.1, 11.0, 8.4.1, 9.3.1
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-16

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

Enforcing the creation of a temporary in the forall fixes the issue.
Something is missing in the logic of check_forall_dependencies().

Reduced testcase:

program evil_forall
  implicit none
  type t
logical :: valid = .true.
integer :: s = 0
!integer, dimension(:), pointer :: p
integer, dimension(:), allocatable :: p
  end type
  type(t) :: v(2)
  integer :: i

  allocate (v(1)%p(8))
  allocate (v(2)%p(8))
  v(1)%s= 8
  v(2)%s= 6
  v(1)%p(:) = (/1, 2, 3, 4, 5, 6, 7, 8/)
  v(2)%p(:) = (/13, 14, 15, 16, 17, 18, 19, 20/)

  !forall (i=1:2, v(i)%valid)
  forall (i=1:2)
 v(i)%p(1:v(i)%s) = v(3-i)%p(1:v(i)%s)
  end forall

  if (any(v(2)%p(:) .ne. (/1, 2, 3, 4, 5, 6, 19, 20/))) stop 1
end program

[Bug bootstrap/98323] current trunk won't build with clang

[nathan at acm dot org via Gcc-bugs]

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

--- Comment #5 from Nathan Sidwell  ---
On 12/16/20 12:45 PM, dcb314 at hotmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98323
> 
> --- Comment #3 from David Binderman  ---
> (In reply to Nathan Sidwell from comment #2)
>> stupid underspecified offsetof
> 
> I did try commenting out the offending block of code and a re-build
> and got further errors ;-<
> 
> I don't know if you have access to clang, but if you don't,
> may I be so bold as to suggest you install a copy and, if
> you have the time, attempt a full build with clang ?

but, but, that'd require me to do actual work !

> 
> That should flush out all the gcc specific code in your recent changes.
> 
> Excellent compiler, BTW.

which, clang or GCC?  (why not both ¯\_(ツ)_/¯)

nathan

[Bug testsuite/98280] [11 regression] gcc.target/powerpc/fold-vec-logical-ors-char.c fails after t11-5958 with assembler output differences

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Edelsohn :

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

commit r11-6159-gcdb1c276560b26a9c3bc837340669962ef1b430a
Author: David Edelsohn 
Date:   Wed Dec 16 15:16:06 2020 -0500

testsuite: Adjust expected instruction count for PPC fold testcases.

commit r11-5958 changed the code generation for the vector logical fold
tests.  This patch updates the expected instruction counts for different
instructions.

gcc/testsuite/ChangeLog:

2020-12-16  David Edelsohn  

PR target/98280
* gcc.target/powerpc/fold-vec-logical-ors-char.c: Adjust count.
* gcc.target/powerpc/fold-vec-logical-ors-int.c: Adjust count.
* gcc.target/powerpc/fold-vec-logical-ors-longlong.c: Adjust count.
* gcc.target/powerpc/fold-vec-logical-ors-short.c: Adjust count.
* gcc.target/powerpc/fold-vec-logical-other-char.c: Adjust count.
* gcc.target/powerpc/fold-vec-logical-other-int.c: Adjust count.
* gcc.target/powerpc/fold-vec-logical-other-longlong.c: Adjust
count.
* gcc.target/powerpc/fold-vec-logical-other-short.c: Adjust count.

[Bug bootstrap/98324] [11 Regression] bootstrap broken with a LTO build configured with --enable-default-pie

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

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

--- Comment #1 from Nathan Sidwell  ---
need to copy some more libcpp configurey bits ...

[Bug c++/98297] [8/9/10/11 Regression] ICE in cp_parser_elaborated_type_specifier, at cp/parser.c:19653

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

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

--- Comment #3 from Nathan Sidwell  ---
Fixed trunk, 8d8bb85b486 2020-12-16 | c++: Fix template parm ICE [PR 98297]

backports to 10, 9, & 8 in progress

[Bug other/98328] [11 Regression] "make install-strip" failed by r11-6081

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||nathan at gcc dot gnu.org

--- Comment #1 from Nathan Sidwell  ---
fixed:
3f78c8cb7f0 2020-12-16 | c++tools: fix install-strip [PR 98328]

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

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

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

--- Comment #7 from Nathan Sidwell  ---
sorry for not getting this right sooner:

b7b6879f0b5: c++: Another solaris header use [PR 98315]

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

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

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

--- Comment #6 from Nathan Sidwell  ---
gah!  there was me thinking the only networking thing in cp is
mapper-client.cc.  (It's the only thing that cares about networking.  That
mapper-resolver.cc needed a tweak should have clued me in

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

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

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

--- Comment #11 from Martin Liška  ---
> which is miscompiled at -O2 -ftree-vectorize or -O3.

What a great reduction, can you please share knowledge how did you achieve
that?!

[Bug tree-optimization/98334] New: Failure to optimally optimize add loop to mul

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 98334
   Summary: Failure to optimally optimize add loop to mul
   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: ---

int f(int i, unsigned int n) {
int result = 0;
while (n > 0) {
result += i;
n -= 1;
}
return result;
}

GCC optimizes this function to code that effectively does `return (n == 0) ? 0
: (i - 1) * n + n;`. It could instead emit the more optimal `return (n == 0) ?
0 : i * n;`, or just `return i * n;` on platforms where multiplication is fast.
This transformation is done by LLVM, but not by GCC.

[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries

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

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

--- Comment #6 from Jozef Lawrynowicz  ---
I've posted a patch where the HAVE_GAS_SHF_GNU_RETAIN configure test has been
extended to check for SHF_GNU_RETAIN gold support:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562100.html

[Bug c++/98333] New: [10/11 Regression] ICE in check_qualified_type, at tree.c:6593

[gscfq--- via Gcc-bugs]

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

Bug ID: 98333
   Summary: [10/11 Regression] ICE in check_qualified_type, at
tree.c:6593
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190616 and 20190623, with an extra "()" :


$ cat z1.cc
struct T
{
  template  struct S
  { S () noexcept () {} };
  int a = __has_nothrow_constructor (S);
};


$ g++-11-20201213 -c z1.cc
z1.cc: In instantiation of 'T::S<  >::S() [with
 = int]':
z1.cc:5:44:   required from here
z1.cc:4:5: internal compiler error: Segmentation fault
4 |   { S () noexcept () {} };
  | ^
0xc8f5ff crash_signal
../../gcc/toplev.c:327
0xf00280 check_qualified_type(tree_node const*, tree_node const*, int)
../../gcc/tree.c:6593
0xf00384 get_qualified_type(tree_node*, int)
../../gcc/tree.c:6625
0xf0d6b3 build_qualified_type(tree_node*, int)
../../gcc/tree.c:6656
0x654566 strip_top_quals(tree_node*)
../../gcc/cp/call.c:1177
0x654566 standard_conversion
../../gcc/cp/call.c:1202
0x656c7a implicit_conversion_1
../../gcc/cp/call.c:2008
0x656c7a implicit_conversion
../../gcc/cp/call.c:2108
0x6669df build_converted_constant_expr_internal
../../gcc/cp/call.c:4369
0x6e5289 build_noexcept_spec(tree_node*, int)
../../gcc/cp/except.c:1234
0x775ce9 maybe_instantiate_noexcept(tree_node*, int)
../../gcc/cp/pt.c:25545
0x7759f8 maybe_instantiate_noexcept(tree_node*, int)
../../gcc/cp/pt.c:25481
0x79d235 trait_expr_value
../../gcc/cp/semantics.c:10246
0x7a7c6a finish_trait_expr(unsigned int, cp_trait_kind, tree_node*, tree_node*)
../../gcc/cp/semantics.c:10449
0x748dd7 cp_parser_trait_expr
../../gcc/cp/parser.c:10749
0x73f58c cp_parser_primary_expression
../../gcc/cp/parser.c:5777
0x741b75 cp_parser_postfix_expression
../../gcc/cp/parser.c:7491
0x751a35 cp_parser_unary_expression
../../gcc/cp/parser.c:8808
0x72b84f cp_parser_cast_expression
../../gcc/cp/parser.c:9712
0x72c082 cp_parser_binary_expression
../../gcc/cp/parser.c:9814

[Bug c++/98332] New: [10/11 Regression] ICE in unshare_constructor, at cp/constexpr.c:1527

[gscfq--- via Gcc-bugs]

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

Bug ID: 98332
   Summary: [10/11 Regression] ICE in unshare_constructor, at
cp/constexpr.c:1527
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190609 and 20190616 :


$ cat z1.cc
struct S { int a = 2147483647 + 1; };
struct { S b[2][1][1][1]; } c;


$ cat z2.cc
#include 
struct S { int a = INT_MAX + 1; };
struct { S b[2][1][1][1]; } c;


$ g++-11-20201213 -c z1.cc
z1.cc:1:31: warning: integer overflow in expression of type 'int' results in
'-2147483648' [-Woverflow]
1 | struct S { int a = 2147483647 + 1; };
  |~~~^~~
z1.cc:2:29:   in 'constexpr' expansion of 'c.::()'
z1.cc:2:29: internal compiler error: Segmentation fault
2 | struct { S b[2][1][1][1]; } c;
  | ^
0xc8f5ff crash_signal
../../gcc/toplev.c:327
0x67c3e8 unshare_constructor(tree_node*)
../../gcc/cp/constexpr.c:1527
0x68a51a cxx_eval_vec_init_1
../../gcc/cp/constexpr.c:4575
0x681d76 cxx_eval_vec_init
../../gcc/cp/constexpr.c:4599
0x681d76 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6584
0x6883c8 cxx_eval_store_expression
../../gcc/cp/constexpr.c:5406
0x6811ca cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6226
0x680737 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6609
0x680b8c cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6284
0x680cde cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6295
0x680d70 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6788
0x67f58f cxx_eval_call_expression
../../gcc/cp/constexpr.c:2701
0x680f5a cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6117
0x683eab cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:7126
0x686e7f maybe_constant_init_1
../../gcc/cp/constexpr.c:7578
0x6ea7b6 expand_default_init
../../gcc/cp/init.c:1998
0x6ea7b6 expand_aggr_init_1
../../gcc/cp/init.c:2101
0x6ec475 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/cp/init.c:1835
0x6cb20d build_aggr_init_full_exprs
../../gcc/cp/decl.c:6803
0x6cb20d check_initializer
../../gcc/cp/decl.c:6964

[Bug c++/98331] New: [9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845

[gscfq--- via Gcc-bugs]

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

Bug ID: 98331
   Summary: [9/10/11 Regression] ICE in haifa_luid_for_non_insn,
at haifa-sched.c:7845
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Following combination of options affects several files from
gcc/testsuite at -O2+, e.g. pr69589_0.C, builtin_unreachable-1.c,
devirt-52.C, ... (regression date depends on testfile) :


$ g++-11-20201213 -c pr69589_0.C -g -O2 -m32 -fopenmp -fprofile-generate
pr69589_0.C: In member function 'Z > C::m8() const':
pr69589_0.C:22:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   22 | }
  | ^
during RTL pass: sched2
pr69589_0.C:22:1: internal compiler error: in haifa_luid_for_non_insn, at
haifa-sched.c:7845
0x1556e06 haifa_luid_for_non_insn
../../gcc/haifa-sched.c:7845
0x155d809 sched_init_insn_luid(rtx_insn*)
../../gcc/haifa-sched.c:8977
0x155de2a sched_init_luids(vec)
../../gcc/haifa-sched.c:9006
0x155e0dc haifa_sched_init()
../../gcc/haifa-sched.c:7382
0xc46d1a schedule_insns()
../../gcc/sched-rgn.c:3514
0xc473fd schedule_insns()
../../gcc/sched-rgn.c:3508
0xc473fd rest_of_handle_sched2
../../gcc/sched-rgn.c:3746
0xc473fd execute
../../gcc/sched-rgn.c:3882

---

pr69589_0.C: In member function 'Z > C::m8() const':
pr69589_0.C:22:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   22 | }
  | ^
during RTL pass: expand
pr69589_0.C:22:1: internal compiler error: Segmentation fault
0xf86f4f crash_signal
../../gcc/toplev.c:327
0xaa7913 rtl_verify_bb_pointers
../../gcc/cfgrtl.c:2780
0xaa7913 rtl_verify_flow_info_1
../../gcc/cfgrtl.c:2832
0xaa84b2 rtl_verify_flow_info
../../gcc/cfgrtl.c:3076
0xa8879a verify_flow_info()
../../gcc/cfghooks.c:267
0x19920e6 checking_verify_flow_info
../../gcc/cfghooks.h:212
0x19920e6 try_optimize_cfg
../../gcc/cfgcleanup.c:3009
0x1992513 cleanup_cfg(int)
../../gcc/cfgcleanup.c:3174
0xa85841 execute
../../gcc/cfgexpand.c:6884

[Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900

[gscfq--- via Gcc-bugs]

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

Bug ID: 98330
   Summary: [11 Regression] ICE in compute_parm_map, at
ipa-modref.c:2900
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20201018 and 20201108, at -O1+ :


$ cat z1.cc
float a = __builtin_pow[1] (3.0, 2);


$ cat z2.cc
float f (float x)
{
  return __builtin_pow[1] (x, 2);
}


$ g++-11-20201213 -c z1.cc -O2
z1.cc:1:26: warning: pointer to a function used in arithmetic [-Wpointer-arith]
1 | float a = __builtin_pow[1] (3.0, 2);
  |  ^
during IPA pass: modref
z1.cc:1:36: internal compiler error: Segmentation fault
1 | float a = __builtin_pow[1] (3.0, 2);
  |^
0xc8f5ff crash_signal
../../gcc/toplev.c:327
0x8c75f2 symtab_node::ultimate_alias_target(availability*, symtab_node*)
../../gcc/cgraph.h:3182
0x8c75f2 cgraph_node::ultimate_alias_target(availability*, symtab_node*)
../../gcc/cgraph.h:3203
0x8c75f2 cgraph_node::function_or_virtual_thunk_symbol(availability*,
symtab_node*)
../../gcc/cgraph.c:3868
0xaa629a compute_parm_map
../../gcc/ipa-modref.c:2900
0xaa6961 compute_parm_map
../../gcc/ipa-modref.c:2891
0xaa6961 propagate_unknown_call
../../gcc/ipa-modref.c:3271
0xaa8757 modref_propagate_in_scc
../../gcc/ipa-modref.c:3425
0xaa8f7c execute
../../gcc/ipa-modref.c:3833

[Bug c++/98329] New: [11 Regression] ICE in cp_build_bit_cast, at cp/semantics.c:10730

[gscfq--- via Gcc-bugs]

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

Bug ID: 98329
   Summary: [11 Regression] ICE in cp_build_bit_cast, at
cp/semantics.c:10730
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Follow-up of pr98193, with test case derived from bit-cast7.C
(similar for other files bit-cast*.C).
Gives an ICE with modifications like "&from", "*from", "**from"
"-from", "--from", etc. at marker "///" :


$ cat z1.cc
template 
constexpr To
bit_cast (const From &from)
{
  return __builtin_bit_cast (To, &from); ///
}

struct J
{
  long int a, b : 11, h;
};

struct K
{
  long int a, b : 11, c;
  constexpr bool operator == (const K &x)
  {
return a == x.a && b == x.b && c == x.c;
  }
};

struct L
{
  long long int a, b : 11, h;
};
struct M
{
  long long int a, b : 11, c;
  constexpr bool operator == (const M &x)
  {
return a == x.a && b == x.b && c == x.c;
  }
};

static_assert (bit_cast  (J{}) == K{}, "");
static_assert (bit_cast  (L{0x0feedbacdeadbeefLL}) ==
M{0x0feedbacdeadbeefLL}, "");


$ g++-11-20201213 -c z1.cc
z1.cc: In instantiation of 'constexpr To bit_cast(const From&) [with To = K;
>From = J]':
z1.cc:35:33:   required from here
z1.cc:5:30: internal compiler error: Segmentation fault
5 |   return __builtin_bit_cast (To, &from); ///
  |  ^~
0xf86f4f crash_signal
../../gcc/toplev.c:327
0x911421 cp_build_bit_cast(unsigned int, tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:10730
0x89765f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20747
0x8bca30 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:19007
0x8bb83f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18084
0x8bc9ef tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18398
0x8a12c5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18059
0x8a12c5 instantiate_body
../../gcc/cp/pt.c:25728
0x8a2b8f instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26017
0x6e697c instantiate_cx_fn_r
../../gcc/cp/constexpr.c:6951
0x12dbc13 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:12095
0x12dc53d walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:12431
0x12dc478 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:12335
0x12dc53d walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:12431
0x12e0245 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
../../gcc/tree.c:12457
0x6f5858 instantiate_constexpr_fns
../../gcc/cp/constexpr.c:6971
0x6f5858 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:7125
0x6fa6b4 maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:7381
0x90f76d finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool)
../../gcc/cp/semantics.c:9932
0x82de02 cp_parser_static_assert
../../gcc/cp/parser.c:15365

[Bug c++/98305] Incomprehensible -Wmismatched-new-delete warning

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

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug other/98328] [11 Regression] "make install-strip" failed

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-16
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug other/98328] New: [11 Regression] "make install-strip" failed

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

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

Bug ID: 98328
   Summary: [11 Regression] "make install-strip" failed
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: nathan at acm dot org
  Target Milestone: ---

make[3]: Entering directory
'/export/users/hjl/build/gnu/tools-build/gcc-x32/build-x86_64-linux/c++tools'
# --enable-maintainer-mode to rebuild
/export/gnu/import/git/sources/gcc/c++tools/config.h.in, or make
MAINTAINER=touch
make[3]: *** No rule to make target 'install-strip'.  Stop.
make[3]: Leaving directory
'/export/users/hjl/build/gnu/tools-build/gcc-x32/build-x86_64-linux/c++tools'
make[2]: *** [Makefile:14422: install-strip-c++tools] Error 2
make[2]: Leaving directory
'/export/users/hjl/build/gnu/tools-build/gcc-x32/build-x86_64-linux'
make[1]: *** [Makefile:2635: install-strip] Error 2

[Bug c++/98305] Incomprehensible -Wmismatched-new-delete warning

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-16
   Target Milestone|--- |11.0
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The warning compares the mangled names of the operators and doesn't interpret
template instantiations quite correctly.

[Bug c++/98327] C++ Module ICE on Linux

[euloanty at live dot com via Gcc-bugs]

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

fdlbxtqi  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from fdlbxtqi  ---
module;
#include 
#include 
export module hello;
export inline void greeter (std::string_view name) noexcept
{
  std::cout << "Hello " << name << "!\n";
}

[Bug c++/98327] New: C++ Module ICE on Linux

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 98327
   Summary: C++ Module ICE on Linux
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

cqwrteur@Home-Server:~/w/working$ g++ -o hello hello.cc -std=c++20
-fmodules-ts
hello.cc:4:8: internal compiler error: Segmentation fault
4 | export module hello;
  |^~
0x10ab5cf crash_signal
../../gcc/gcc/toplev.c:327
0x9f8667 has_definition
../../gcc/gcc/cp/module.cc:11361
0xa0a867 depset::hash::make_dependency(tree_node*, depset::entity_kind)
../../gcc/gcc/cp/module.cc:12531
0xa0af44 depset::hash::add_dependency(tree_node*, depset::entity_kind)
../../gcc/gcc/cp/module.cc:12669
0xa11f9a trees_out::decl_node(tree_node*, walk_kind)
../../gcc/gcc/cp/module.cc:8569
0xa12702 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9132
0xa13131 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5990
0xa164d4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7124
0xa164d4 trees_out::tree_value(tree_node*)
../../gcc/gcc/cp/module.cc:8939
0xa12564 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9137
0xa13131 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5990
0xa164d4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7124
0xa164d4 trees_out::tree_value(tree_node*)
../../gcc/gcc/cp/module.cc:8939
0xa12564 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9137
0xa13131 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5990
0xa164d4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7124
0xa164d4 trees_out::tree_value(tree_node*)
../../gcc/gcc/cp/module.cc:8939
0xa12564 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9137
0xa13131 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5990
0xa164d4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7124
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
cqwrteur@Home-Server:~/w/working$

[Bug c++/98326] New: ICE: in create_tmp_var, at gimple-expr.c:482, converting stateless generic-lambda to function pointer

[leni536 at gmail dot com via Gcc-bugs]

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

Bug ID: 98326
   Summary: ICE: in create_tmp_var, at gimple-expr.c:482,
converting stateless generic-lambda to function
pointer
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leni536 at gmail dot com
  Target Milestone: ---

version: g++ (Compiler-Explorer-Build) 10.2.0
arguments: -O2 -std=c++17 -pedantic-errors

```
struct A {
A() = default;
A(const A&) {}
};

void (*fptr)(A) = [](auto){};
```

: In static member function 'static constexpr decltype
(((const*)0)->operator()(static_cast()))::_FUN(auto:1)
[with auto:1 = A]':
:6:28: internal compiler error: in create_tmp_var, at gimple-expr.c:482
6 | void (*fptr)(A) = [](auto){};
  |^


The ICE seems to happen when the by-value parameter's type is not trivially
copyable. It can also be reproduced with a non-trivial destructor.

If the copy-constructor is deleted then it fails to compile with a non-ice
error.

Related: PR 86943

In my understanding gcc tries to copy/move the by-value parameter in the free
function to pass it to `closure{}(args)`. I don't think that copying/moving the
by-value argument is correct. The effect of calling the resulting function
pointer should be equivalent to calling the operator() on the closure object,
it's not expressed in terms of forwarding the parameters:

https://timsong-cpp.github.io/cppwp/n4659/expr.prim.lambda.closure#8

It's more precisely spelled out in C++20, as there it can be expressed it in
terms of a default constructed object of the closure type:

http://eel.is/c++draft/expr.prim.lambda.closure#10.sentence-1

[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517

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

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

--- Comment #5 from seurer at gcc dot gnu.org ---
Still seeing this on powerpc64, too.

g:8379916b167de9bebc32401526b6f53d06dca349, r11-6152
make  -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/Wstringop-overflow-25.c"
FAIL: gcc.dg/Wstringop-overflow-25.c pr92814 (test for warnings, line 378)
# of expected passes51
# of unexpected failures1

[Bug bootstrap/98324] [11 Regression] bootstrap broken with a LTO build configured with --enable-default-pie

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

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

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Nathan Sidwell  ---
[...]
>> Unfortunately not: there are still two instances of the problem:
>
> There is another path to get to a poisoned bcopy.  Fixed thusly.
>
> gcc/cp/
>  * mapper-resolver.cc: #include sys/socket before system.h
>  due to poisoned bcopy use.

Thanks.  But doesn't gcc/cp/module.cc need a similar treatment to deal
with the second part?

In file included from /usr/include/sys/socket.h:25,
 from /vol/gcc/src/hg/master/local/gcc/../libcody/cody.hh:29,
 from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.h:26,
 from /vol/gcc/src/hg/master/local/gcc/cp/module.cc:232:
/usr/include/sys/uio.h:192:3: error: attempt to use poisoned "bzero"
   bzero(&(xuiop)->xu_hint, sizeof ((xuiop)->xu_hint)); \
   ^

[Bug c++/98322] optimizes to false instead true

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Jakub Jelinek  ---
.

[Bug bootstrap/98323] current trunk won't build with clang

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed 8379916b167

[Bug c++/98322] optimizes to false instead true

[sucicf1 at outlook dot com via Gcc-bugs]

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

Ivan Sučić  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #3 from Ivan Sučić  ---
Sorry for false report.

[Bug bootstrap/98323] current trunk won't build with clang

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to Nathan Sidwell from comment #2)
> stupid underspecified offsetof

I did try commenting out the offending block of code and a re-build
and got further errors ;-<

I don't know if you have access to clang, but if you don't,
may I be so bold as to suggest you install a copy and, if
you have the time, attempt a full build with clang ?

That should flush out all the gcc specific code in your recent changes.

Excellent compiler, BTW.

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

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

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

--- Comment #4 from Nathan Sidwell  ---
Another fix: 269e82d49e2

[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization

[i.hamsa at gmail dot com via Gcc-bugs]

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

--- Comment #8 from i.hamsa at gmail dot com ---
After re-reading the relevant parts of the standard, I have convinced myself
that the program is indeed not required to work unless  is included,
even in a single-threaded version. Even though the standard encourages
implementations to initialise the standard iostreams objects earlier than
required, it is not mandatory.

[Bug c++/98322] optimizes to false instead true

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, folding it to return false; is the right thing.
~a ^ b is ~(int) (a ^ b) in C++, so if a == b, it is ~0 (on two's complement
-1),
and if a != b, then it is ~1 (on two's complement -2).
1 != -1
and
0 != -2
so it is always false.

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

[nathan at acm dot org via Gcc-bugs]

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

--- Comment #3 from Nathan Sidwell  ---
On 12/16/20 12:26 PM, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98315
> 
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #1 from Nathan Sidwell  ---
>> I think this is fixed by
>> 6ff747f023c 2020-12-16 | c++: Fix (some) solaris breakage
>>
>> please let me know
> 
> Unfortunately not: there are still two instances of the problem:


There is another path to get to a poisoned bcopy.  Fixed thusly.

gcc/cp/
 * mapper-resolver.cc: #include sys/socket before system.h
 due to poisoned bcopy use.

pushed to trunk

[Bug testsuite/98325] New: [11 regression] gcc.dg/pr25376.c fails after r11-5027

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

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

Bug ID: 98325
   Summary: [11 regression] gcc.dg/pr25376.c fails after r11-5027
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:8270a7238ba1b535cc81848ef026d30e9d96447f, r11-5027

Does maybe this test case just need updating?

make  -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr25376.c"

FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple$ (found
.L.simple) has section ^my_named_section$ (found ".opd")
FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple$ (found
simple) has section ^my_named_section$ (found ".opd")

# of expected passes2
# of unexpected failures2

commit 8270a7238ba1b535cc81848ef026d30e9d96447f
Author: Matthew Glazar 
Date:   Fri Nov 13 23:59:05 2020 -0500

Simplify testing symbol sections

[Bug bootstrap/98323] current trunk won't build with clang

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
stupid underspecified offsetof

[Bug bootstrap/98324] New: [11 Regression] bootstrap broken with a LTO build configured with --enable-default-pie

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 98324
   Summary: [11 Regression] bootstrap broken with a LTO build
configured with --enable-default-pie
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with the trunk after the c++modules merge:

configured with:

 --enable-default-pie
 --enable-checking=yes,extra,rtl
 --with-build-config=bootstrap-lto-lean

/packages/gcc/11/gcc-11-11-20201216/build/./gcc/xg++
-B/packages/gcc/11/gcc-11-11-20201216/build/./gcc/ -nostdinc++ -nostdinc++
-I/packages/gcc/11/gcc-11-11-20201216/build/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu
-I/packages/gcc/11/gcc-11-11-20201216/build/x86_64-linux-gnu/libstdc++-v3/include
-I/packages/gcc/11/gcc-11-11-20201216/src/libstdc++-v3/libsupc++
-I/packages/gcc/11/gcc-11-11-20201216/src/libstdc++-v3/include/backward
-I/packages/gcc/11/gcc-11-11-20201216/src/libstdc++-v3/testsuite/util
-L/packages/gcc/11/gcc-11-11-20201216/build/x86_64-linux-gnu/libstdc++-v3/src
-L/packages/gcc/11/gcc-11-11-20201216/build/x86_64-linux-gnu/libstdc++-v3/src/.libs
-L/packages/gcc/11/gcc-11-11-20201216/build/x86_64-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/packages/gcc/11/gcc-11-11-20201216/build/x86_64-linux-gnu/libstdc++-v3/src/.libs
-B/packages/gcc/11/gcc-11-11-20201216/build/x86_64-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem
/usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include
-isystem /packages/gcc/11/gcc-11-11-20201216/build/sys-include -o
g++-mapper-server server.o resolver.o ../libcody/libcody.a ../gcc/version.o
../libiberty/libiberty.a
/usr/bin/x86_64-linux-gnu-ld: /tmp/cco6ffKB.ltrans0.ltrans.o: relocation
R_X86_64_32S against `.rodata.str1.1' can not be used when making a PIE object;
recompile with -fPIE
collect2: error: ld returned 1 exit status
make: *** [Makefile:83: g++-mapper-server] Error 1

[Bug bootstrap/98323] current trunk won't build with clang

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
git blame says

4efde6781bba (Nathan Sidwell 2020-12-14 11:40:44 -0800  4153)   /* Create
or extend the dump implementor.  */
4efde6781bba (Nathan Sidwell 2020-12-14 11:40:44 -0800  4154)   unsigned
current = dumps ? dumps->stack.length () : 0;
4efde6781bba (Nathan Sidwell 2020-12-14 11:40:44 -0800  4155)   unsigned
count = current ? current * 2 : EXPERIMENT (1, 20);
4efde6781bba (Nathan Sidwell 2020-12-14 11:40:44 -0800  4156)   size_t
alloc = (offsetof (impl, impl::stack)
4efde6781bba (Nathan Sidwell 2020-12-14 11:40:44 -0800  4157) +
impl::stack_t::embedded_size (count));
4efde6781bba (Nathan Sidwell 2020-12-14 11:40:44 -0800  4158)   dumps =
XRESIZEVAR (impl, dumps, alloc);
4efde6781bba (Nathan Sidwell 2020-12-14 11:40:44 -0800  4159)  
dumps->stack.embedded_init (count, current);

Adding Nathan.

[Bug bootstrap/98323] New: current trunk won't build with clang

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 98323
   Summary: current trunk won't build with clang
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Current trunk has hash 5098d35fb1997aa6.

I tried building it with clang version 11.0.0
and got this:

../../trunk.git/gcc/cp/module.cc:4156:43: error: expected ')'
  size_t alloc = (offsetof (impl, impl::stack)
  ^
../../trunk.git/gcc/cp/module.cc:4156:23: note: to match this '('
  size_t alloc = (offsetof (impl, impl::stack)
  ^
/usr/lib64/clang/11.0.0/include/stddef.h:104:42: note: expanded from macro
'offsetof'
#define offsetof(t, d) __builtin_offsetof(t, d)
 ^

For the record, it builds happily with recent gcc.

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

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

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Nathan Sidwell  ---
> I think this is fixed by 
> 6ff747f023c 2020-12-16 | c++: Fix (some) solaris breakage
>
> please let me know

Unfortunately not: there are still two instances of the problem:

In file included from /usr/include/sys/socket.h:25,
 from /vol/gcc/src/hg/master/local/gcc/../libcody/cody.hh:29,
 from
/vol/gcc/src/hg/master/local/gcc/cp/../../c++tools/resolver.h:25,
 from
/vol/gcc/src/hg/master/local/gcc/cp/../../c++tools/resolver.cc:23,
 from
/vol/gcc/src/hg/master/local/gcc/cp/mapper-resolver.cc:27:
/usr/include/sys/uio.h:192:3: error: attempt to use poisoned "bzero"
   bzero(&(xuiop)->xu_hint, sizeof ((xuiop)->xu_hint)); \
   ^
In file included from /usr/include/sys/socket.h:25,
 from /vol/gcc/src/hg/master/local/gcc/../libcody/cody.hh:29,
 from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.h:26,
 from /vol/gcc/src/hg/master/local/gcc/cp/module.cc:232:
/usr/include/sys/uio.h:192:3: error: attempt to use poisoned "bzero"
   bzero(&(xuiop)->xu_hint, sizeof ((xuiop)->xu_hint)); \
   ^

[Bug c++/98322] optimizes to false instead true

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||ktkachov at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I don't think that's true.
Note, that with -Wall you get the warning:
true.c: In function 'always_true':
true.c:3:29: warning: '~' on a boolean expression [-Wbool-operation]
3 | return (a == b) == (~a ^ b);
  | ^
true.c:3:29: note: did you mean to use logical not?
3 | return (a == b) == (~a ^ b);
  | ^
  |

[Bug c++/98322] New: optimizes to false instead true

[sucicf1 at outlook dot com via Gcc-bugs]

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

Bug ID: 98322
   Summary: optimizes to false instead true
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sucicf1 at outlook dot com
  Target Milestone: ---

bool always_true (bool a, bool b)
{
return (a == b) == (~a ^ b);
} 

is optimized to 

xorl%eax, %eax
ret

instead return 1.

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

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

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

--- Comment #10 from Alex Coplan  ---
Reduced to:

int c = 1705;
char a;
long f = 50887638;
unsigned long long *h(unsigned long long *k, unsigned long long *l) {
  return *k ? k : l;
}
void aa() {}
int main() {
  long d = f;
  for (char g = 0; g < (char)c - 10; g += 2) {
unsigned long long i = d, j = 4;
a = *h(&i, &j) << ((d ? 169392992 : 0) - 169392955LL);
  }
  if (a)
__builtin_abort();
}

which is miscompiled at -O2 -ftree-vectorize or -O3.

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

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

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

Marius Hillenbrand  changed:

   What|Removed |Added

 CC||mhillen at linux dot ibm.com

--- Comment #6 from Marius Hillenbrand  ---
I reproduced and bisected with the config shared by Matthias. The issue begins
with the introduction of ipa-modref. There is an inbetween range of commits
that fail with a different symptom, yet this commit is the first I found that
exactly fails as initially reported here:

commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka 
Date:   Sun Sep 20 07:25:16 2020 +0200

New modref/ipa_modref optimization passes

2020-09-19  David Cepelik  
Jan Hubicka  

* Makefile.in: Add ipa-modref.c and ipa-modref-tree.c.
* alias.c: (reference_alias_ptr_type_1): Export.
* alias.h (reference_alias_ptr_type_1): Declare.
* common.opt (fipa-modref): New.
* gengtype.c (open_base_files): Add ipa-modref-tree.h and
ipa-modref.h
* ipa-modref-tree.c: New file.
* ipa-modref-tree.h: New file.
* ipa-modref.c: New file.
* ipa-modref.h: New file.
* lto-section-in.c (lto_section_name): Add ipa_modref.
* lto-streamer.h (enum lto_section_type): Add
LTO_section_ipa_modref.
* opts.c (default_options_table): Enable ipa-modref at -O1+.
* params.opt (-param=modref-max-bases, -param=modref-max-refs,
-param=modref-max-tests): New params.
* passes.def: Schedule pass_modref and pass_ipa_modref.
* timevar.def (TV_IPA_MODREF): New timevar.
(TV_TREE_MODREF): New timevar.
* tree-pass.h (make_pass_modref): Declare.
(make_pass_ipa_modref): Declare.
* tree-ssa-alias.c (dump_alias_stats): Include ipa-modref-tree.h
and ipa-modref.h
(alias_stats): Add modref_use_may_alias, modref_use_no_alias,
modref_clobber_may_alias, modref_clobber_no_alias, modref_tests.
(dump_alias_stats): Dump new stats.
(nonoverlapping_array_refs_p): Fix formating.
(modref_may_conflict): New function.
(ref_maybe_used_by_call_p_1): Use it.
(call_may_clobber_ref_p_1): Use it.
(call_may_clobber_ref_p): Update.
(stmt_may_clobber_ref_p_1): Update.
* tree-ssa-alias.h (call_may_clobber_ref_p_1): Update.

[Bug fortran/98284] ICE in get_array_index

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11.

Thanks for the reduced testcase and for draft patch!

[Bug fortran/98284] ICE in get_array_index

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

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

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

https://gcc.gnu.org/g:5098d35fb1997aa6fd6d7e37d0fd4501a5fe2f9d

commit r11-6149-g5098d35fb1997aa6fd6d7e37d0fd4501a5fe2f9d
Author: Harald Anlauf 
Date:   Wed Dec 16 17:25:06 2020 +0100

PR fortran/98284 - ICE in get_array_index

Reject DATA elements with the ALLOCATABLE attribute also when they are
components of a derived type.

gcc/fortran/ChangeLog:

PR fortran/98284
* resolve.c (check_data_variable): Reject DATA elements with the
ALLOCATABLE attribute.

gcc/testsuite/ChangeLog:

PR fortran/98284
* gfortran.dg/pr98284.f90: New test.

[Bug ada/98312] [11 Regression] Broken Ada bootstrap

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

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

--- Comment #4 from pmderodat at gcc dot gnu.org ---
That’s a relief, thank you for the confirmation :)

[Bug target/98320] Parameter is malformed in the called function

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
You are clobbering the red zone.

[Bug ada/98312] [11 Regression] Broken Ada bootstrap

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

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

--- Comment #3 from Martin Liška  ---
Thank you for the fix, it works for me.

[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #7 from Jonathan Wakely  ---
I've reverted the change because it breaks the build for some targes.

So you'll just have to fix your code. The simplest way is to ensure you include
 before defining a global that wants to use std::cout.

[Bug ada/98312] [11 Regression] Broken Ada bootstrap

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

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

pmderodat at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pmderodat at gcc dot 
gnu.org
 CC||pmderodat at gcc dot gnu.org

--- Comment #2 from pmderodat at gcc dot gnu.org ---
Hello Martin,

Thank you for reporting this and sorry for the inconvenience! As discussed on
gcc-patches@, I suspect that my testing hasn’t detected this because of some
inconsistency with my incremental builds.

This should be fixed now that
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cbe22e189a355f19eb1344fcaf91bc2bb0b95f36
is pushed.

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

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

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

--- Comment #8 from Martin Liška  ---
(In reply to Martin Sebor from comment #4)
> Fixed in r11-6028.

Even the original test-case still ICEs after this revision. I'm testing
r11-6147 right now.

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

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

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

--- Comment #7 from Martin Liška  ---
New reduced test-case:

$ cat 1.ii
namespace xercesc_2_5 {
class MemoryManager;
class XMemory {
  void *operator new(unsigned long, MemoryManager *);
};
class MemoryManager {
public:
  virtual void *allocate();
};
void *XMemory::operator new(unsigned long, MemoryManager *manager) {
  long headerSize(sizeof(MemoryManager));
  void *block = manager->allocate();
  return block + headerSize;
}
} // namespace xercesc_2_5

$ cat 2.ii
namespace xercesc_2_5 {
class MemoryManager;
class XMemory {
public:
  void *operator new(unsigned long, MemoryManager *);
  void operator delete(void *, MemoryManager *);
};
class XMLPlatformUtils {
public:
  static MemoryManager *fgMemoryManager;
};
class ValueStackOf : public XMemory {
public:
  ValueStackOf(int, bool);
};
class XPathMatcherStack {
  XPathMatcherStack();
  ValueStackOf *fContextStack;
};
XPathMatcherStack::XPathMatcherStack()
: fContextStack(new (XMLPlatformUtils::fgMemoryManager)
ValueStackOf(8, XMLPlatformUtils::fgMemoryManager)) {}
} // namespace xercesc_2_5

$ g++ 1.ii 2.ii -O2 -flto=16 -shared
1.ii: In static member function 'static void* xercesc_2_5::XMemory::operator
new(long unsigned int, xercesc_2_5::MemoryManager*)':
1.ii:13:16: warning: pointer of type 'void *' used in arithmetic
[-Wpointer-arith]
   13 |   return block + headerSize;
  |  ~~^~~~
during RTL pass: expand
2.ii: In member function '__ct_base ':
2.ii:22:74: internal compiler error: Segmentation fault
   22 | ValueStackOf(8,
XMLPlatformUtils::fgMemoryManager)) {}
  |
 ^
0xcce44f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0x81da08 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3337
0x81da08 warn_dealloc_offset
/home/marxin/Programming/gcc/gcc/builtins.c:13413
0x836127 maybe_emit_free_warning(tree_node*)
/home/marxin/Programming/gcc/gcc/builtins.c:13586
0x84545e initialize_argument_information
/home/marxin/Programming/gcc/gcc/calls.c:2629
0x84545e expand_call(tree_node*, rtx_def*, int)
/home/marxin/Programming/gcc/gcc/calls.c:4009
0x978104 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:11276
0x8590cd expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:282
0x8590cd expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2831
0x8590cd expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3835
0x8590cd expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3999
0x85e5fa expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6036
0x8600b6 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6720
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [/tmp/cc3Mo9q4.mk:2: /tmp/ccFzg763.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 98160 Summary: [11 Regression] ICE in default_tree_printer at 
gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Martin Liška  ---
I can confirm that and I'm going to reduce that.

[Bug target/98321] New: [nvptx] 'atom.add.f32' for atomic add of 32-bit 'float'

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

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

Bug ID: 98321
   Summary: [nvptx] 'atom.add.f32' for atomic add of 32-bit
'float'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

Consider:

TYPE f(TYPE a, TYPE b)
{
  #pragma acc atomic update
  a += b;

  return a;
}

Compiling always with '-fopenacc', for '-DTYPE=int'/'-DTYPE=long' I do see the
expected 'atom.add.u32'/'atom.add.u64', but for '-DTYPE=float' I do not see the
expected 'atom.add.f32' but instead an 'atom.cas.b32' loop.  (I understand that
'-DTYPE=double': 'atom.add.f64' depends on PTX 5.0, SM 6.0 support.)

[Bug libstdc++/96083] Clang can't compile : error: use of undeclared identifier '__builtin_sprintf'

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

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

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

https://gcc.gnu.org/g:96d9670e88333d8896a5d2f2bb0403c1e2ad19ab

commit r11-6146-g96d9670e88333d8896a5d2f2bb0403c1e2ad19ab
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:50:34 2020 +

libstdc++: Only use __builtin_sprintf if supported [PR 96083]

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3

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

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

Rainer Orth  changed:

   What|Removed |Added

   Assignee|nathan at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
That's easiest, I guess.  With one minor addition (gcc/objcp/Make-lang.in needs
the same treatment), the Solaris 11.3 build completed successfully; make check
still running.

I'll try the patch on Solaris 11.4 and Linux/x86_64 tonight, then post it.

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

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

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

--- Comment #1 from Nathan Sidwell  ---
I think this is fixed by 
6ff747f023c 2020-12-16 | c++: Fix (some) solaris breakage

please let me know

[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3

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

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

--- Comment #3 from Nathan Sidwell  ---
Looks good, and separating out cc1plus' libraries from other executables is
goodness.

do you want to take this bug?

[Bug c/98311] libcody configure checking problem

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed 4be6c4e2a4d

[Bug ada/98312] [11 Regression] Broken Ada bootstrap

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |FIXED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-cvs/2020-December/33
   ||9290.html
 Status|NEW |RESOLVED

--- Comment #1 from Eric Botcazou  ---
.

[Bug bootstrap/98314] [11 Regression] Install fails with "install -C"

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Thanks, fixed by r11-6136.

[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

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

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

--- Comment #2 from Alex Coplan  ---
Adding -fno-tree-forwprop gives us an ICE in LRA instead:

$ aarch64-elf-gcc -c pr97141.c -O3 -march=armv8.2-a+sve -fno-tree-forwprop

during RTL pass: reload
pr97141.c: In function 'g':
pr97141.c:8:1: internal compiler error: maximum number of generated reload
insns per insn achieved (90)
8 | }
  | ^
0xc08d23 lra_constraints(bool)
/home/alecop01/toolchain/src/gcc/gcc/lra-constraints.c:5061
0xbeff49 lra(_IO_FILE*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:2329
0xba2af8 do_reload
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5802
0xba2af8 execute
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5988
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Originally noticed this LRA ICE with the related testcase:

int a;
void b() {
  a = 0;
  for (; a != -24; a = (short)a - 3) {
short *c;
*c |= 0 < b;
  }
}

[Bug c/98320] New: Parameter is malformed in the called function

[ypn00vb at gmail dot com via Gcc-bugs]

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

Bug ID: 98320
   Summary: Parameter is malformed in the called function
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ypn00vb at gmail dot com
  Target Milestone: ---

Created attachment 49779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49779&action=edit
main function

When compiling with the -m64 option, one of the parameters passed to the
function is damaged. When compiling with the -m32 option, there is no damage,
everything works.
PS. In the assembler listing, you can see that there is no instruction to move
the stack pointer with the -m64 option. Therefore, the assembler insertion of a
flag register push instruction overwrites the parameter in memory.

[Bug libstdc++/98319] LFTS headers give errors if included as C++11 or C++98

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

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/46447] std::atomic_flag slower than std::atomic_uchar

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Benjamin Kosnik from comment #3)
> I'd like to generalize this test case for the performance testsuite.

Done.

[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600

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

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

--- Comment #7 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section

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

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section

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

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

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

https://gcc.gnu.org/g:151d1347c99acfcf0f5bcd8caac36dcc7353816d

commit r11-6142-g151d1347c99acfcf0f5bcd8caac36dcc7353816d
Author: H.J. Lu 
Date:   Mon Dec 14 20:10:13 2020 -0800

Require .init_array/.fini_array support for SHF_GNU_RETAIN

Since SHF_GNU_RETAIN support doesn't work for crtstuff.c which switches
the output section directly with asm statement:

---
static void __attribute__((used))
__do_global_dtors_aux (void)
{
  static _Bool completed;

  if (__builtin_expect (completed, 0))
return;
  completed = 1;
}

static void __attribute__((__used__))
call___do_global_dtors_aux (void)
{
  asm ("\t.section\t.fini");
  __do_global_dtors_aux ();
  asm ("\t.section\t.text");
}
---

use SHF_GNU_RETAIN only if .init_array/.fini_array section is supported.

gcc/

PR target/98146
* defaults.h (SUPPORTS_SHF_GNU_RETAIN): New.
* varasm.c (get_section): Replace HAVE_GAS_SHF_GNU_RETAIN with
SUPPORTS_SHF_GNU_RETAIN.
(resolve_unique_section): Likewise.
(get_variable_section): Likewise.
(switch_to_section): Likewise.

gcc/testsuite/

PR target/98146
* lib/target-supports.exp
(check_effective_target_R_flag_in_section): Also check
HAVE_INITFINI_ARRAY_SUPPORT != 0.

[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section

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

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

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

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

commit r11-6141-g2a976020603589e897fcfa3276590ef50b489d34
Author: H.J. Lu 
Date:   Thu Dec 3 15:39:59 2020 -0800

Warn used and not used symbols in section with the same name

When SECTION_RETAIN is used, issue a warning when a symbol without used
attribute and a symbol with used attribute are placed in the section with
the same name, like

int __attribute__((used,section(".data.foo"))) foo2 = 2;
int __attribute__((section(".data.foo"))) foo1 = 1;

since assembler will put them in different sections with the same section
name.

gcc/

PR target/98146
* varasm.c (switch_to_section): Warn when a symbol without used
attribute and a symbol with used attribute are placed in the
section with the same name.

gcc/testsuite/

PR target/98146
* c-c++-common/attr-used-5.c: Updated.
* c-c++-common/attr-used-6.c: Likewise.
* c-c++-common/attr-used-7.c: Likewise.
* c-c++-common/attr-used-8.c: Likewise.

[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section

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

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

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

https://gcc.gnu.org/g:6175383249143309fdc780a02bea484f4450def7

commit r11-6140-g6175383249143309fdc780a02bea484f4450def7
Author: H.J. Lu 
Date:   Thu Dec 3 11:01:06 2020 -0800

Switch to a new section if the SECTION_RETAIN bit doesn't match

When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.

gcc/

PR target/98146
* output.h (switch_to_section): Add a tree argument, default to
nullptr.
* varasm.c (get_section): If the SECTION_RETAIN bit doesn't match,
return and switch to a new section later.
(assemble_start_function): Pass decl to switch_to_section.
(assemble_variable): Likewise.
(switch_to_section): If the SECTION_RETAIN bit doesn't match,
switch to a new section.

gcc/testsuite/

PR target/98146
* c-c++-common/attr-used-5.c: New test.
* c-c++-common/attr-used-6.c: Likewise.
* c-c++-common/attr-used-7.c: Likewise.
* c-c++-common/attr-used-8.c: Likewise.
* c-c++-common/attr-used-9.c: Likewise.