[Bug fortran/99711] Crash when reading an allocated character array in namelist

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #10 from Steve Kargl  ---
On Wed, Mar 24, 2021 at 05:35:31AM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> What does -ftree-dump-original show?  I wonder if gfortran is doing a
> re-allocation on assignment when it shouldn't.
> 

Nope.  It looks like a counting problem.  Here's a modified
testcase.

   program allocnml
   implicit none
   character(len=:), dimension(:), allocatable :: cbulist_ru
   integer :: iluseg
   namelist /nam_bu_ru/ cbulist_ru
   allocate( character(len=10) :: cbulist_ru(4) )
   cbulist_ru = 'abc'
   print *, size(cbulist_ru), len(cbulist_ru(1))
   open(newunit=iluseg, file='list.nml', status='old')
   read(unit=iluseg, nml=nam_bu_ru)
   print *, size(cbulist_ru), len(cbulist_ru(1))
   print *, cbulist_ru
   print *, '>'//cbulist_ru(1)//'<'
   print *, '>'//cbulist_ru(2)//'<'
   print *, '>'//cbulist_ru(3)//'<'
   print *, '>'//cbulist_ru(4)//'<'
   close(unit=iluseg)
   end program allocnml

I get

% gfcx -o z -O a.f90 && ./z
   4  10
   4  10
 VTURB abc   abc   abc   
 >VTURB <
 >abc   <
 >abc   <
 >abc   <

which suggests that during the READ, the individual array
elements aren't assigned.  That is, the array index is 
never incremented from 1 to 4.

[Bug fortran/99711] Crash when reading an allocated character array in namelist

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #9 from Steve Kargl  ---
On Wed, Mar 24, 2021 at 02:41:08AM +, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
> 
> --- Comment #7 from Jerry DeLisle  ---
> Digging further within gfc_resolve_dt which is resolving the READ statement,
> one can find:
> 
> (gdb) p *e->symtree.n.sym.ts.u.cl
> $31 = {length = 0x0, next = 0x0, length_from_typespec = false, backend_decl =
> 0x0, 
>   passed_length = 0x0, resolved = 1}
> 
> e is the gfc_expr for cbulist_ru in the test case
> 
> I have checked both the gfc_expr itself and it's symtree and in all cases the
> character length is NULL, not being intialized.  I suspect it is getting 
> missed
> in the resolution of the allocate statement.  At this point in gfc_resolve_dt
> it is marked as having been resolved.
> 

What does -ftree-dump-original show?  I wonder if gfortran is doing a
re-allocation on assignment when it shouldn't.

[Bug c++/99745] New: ICE when parameter pack not expanded in bit field

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99745
   Summary: ICE when parameter pack not expanded in bit field
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/dz1bcxhYf

template 
struct S { 
  int a : sizeof(Ts); 
};

S s;


:3:11: internal compiler error: in dependent_type_p, at cp/pt.c:26775
3 |   int a : sizeof(Ts);
  |   ^~
0x1cfa409 internal_error(char const*, ...)
???:0
0x6ba5f7 fancy_abort(char const*, int, char const*)
???:0
0x8f91c8 dependent_type_p(tree_node*)
???:0
0x9c3a1f cxx_sizeof_or_alignof_type(unsigned int, tree_node*, tree_code, bool,
bool)
???:0
0x9164a7 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x95a1a6 instantiate_class_template(tree_node*)
???:0
0x7b2bd0 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x8e111d c_parse_file()
???:0
0xa5f9c2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/99711] Crash when reading an allocated character array in namelist

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

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

--- Comment #8 from Jerry DeLisle  ---
I see nowhere in resolve.c (resolve_allocate_expr) any attempt to resolve the
chraracter length. I think it has been missed.  I have cc'ed Paul to see if he
has any thoughts.

[Bug target/99744] New: __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

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

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

Bug ID: 99744
   Summary: __attribute__ ((target("general-regs-only"))) doesn't
work with GPR intrinsics
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, ubizjak at gmail dot com
  Target Milestone: ---
Target: x86-64,i386

[hjl@gnu-cfl-2 uintr-2]$ cat x.c
#include 

extern unsigned long long int curr_deadline;
extern void bar (void);

__attribute__ ((target("general-regs-only")))
void
foo (void)
{
  if (__rdtsc () < curr_deadline)
return; 
  bar ();
}
[hjl@gnu-cfl-2 uintr-2]$ /usr/gcc-11.0.0-x32/bin/gcc -S x.c
In file included from
/usr/gcc-11.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/x86gprintrin.h:27,
 from
/usr/gcc-11.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/x86intrin.h:27,
 from x.c:1:
x.c: In function ‘foo’:
/usr/gcc-11.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/ia32intrin.h:112:1:
error: inlining failed in call to ‘always_inline’ ‘__rdtsc’: target specific
option mismatch
  112 | __rdtsc (void)
  | ^~~
x.c:10:7: note: called from here
   10 |   if (__rdtsc () < curr_deadline)
  |   ^~
[hjl@gnu-cfl-2 uintr-2]$ ls
foo.c  Makefile  x.c
[hjl@gnu-cfl-2 uintr-2]$ 

ix86_can_inline_p failed since caller disabled SSE and MMX, but __rdtsc had
SSE and MMX enanbled.  However GPR intrinsics don't need SSE nor MMX.

[Bug fortran/99711] Crash when reading an allocated character array in namelist

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

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

--- Comment #7 from Jerry DeLisle  ---
Digging further within gfc_resolve_dt which is resolving the READ statement,
one can find:

(gdb) p *e->symtree.n.sym.ts.u.cl
$31 = {length = 0x0, next = 0x0, length_from_typespec = false, backend_decl =
0x0, 
  passed_length = 0x0, resolved = 1}

e is the gfc_expr for cbulist_ru in the test case

I have checked both the gfc_expr itself and it's symtree and in all cases the
character length is NULL, not being intialized.  I suspect it is getting missed
in the resolution of the allocate statement.  At this point in gfc_resolve_dt
it is marked as having been resolved.

[Bug c++/99743] New: ICE Segmentation fault when use lambda init-capture in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99743
   Summary: ICE Segmentation fault when use lambda init-capture in
requires clause
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

static_assert(requires { [x = 0]{}; });

https://godbolt.org/z/n9KE4z7P6

I don't know whether this code is well-form or not.
Maybe related/duplicate to PR 99538, PR 99465, PR 99546 since they are the same
form.

[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits

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

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

--- Comment #4 from luoxhu at gcc dot gnu.org ---
Thanks, Jakub. It tested pass on both m32/m64, is this a reasonable fix?
@segher, will make it a patch if so.


git diff
diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index 859af75..0a5cae2 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -1920,6 +1920,12 @@
   return address_is_prefixed (XEXP (op, 0), mode, NON_PREFIXED_DEFAULT);
 })

+;; Return true if m64 on p8v and above for vec_set with variable index.
+(define_predicate "vec_set_index_operand"
+ (if_then_else (match_test "TARGET_P8_VECTOR && TARGET_DIRECT_MOVE_64BIT")
+  (match_operand 0 "reg_or_cint_operand")
+  (match_operand 0 "const_int_operand")))
+
 ;; Return true if the operand is a valid memory operand with a D-form
 ;; address that could be merged with the load of a PC-relative external
address
 ;; with the PCREL_OPT optimization.  We don't check here whether or not the
diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
index e5191bd..3446b03 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -1227,7 +1227,7 @@
 (define_expand "vec_set"
   [(match_operand:VEC_E 0 "vlogical_operand")
(match_operand: 1 "register_operand")
-   (match_operand 2 "reg_or_cint_operand")]
+   (match_operand 2 "vec_set_index_operand")]
   "VECTOR_MEM_ALTIVEC_OR_VSX_P (mode)"
 {
   rs6000_expand_vector_set (operands[0], operands[1], operands[2]);

[Bug c++/99742] New: Parameter packs not expanded with nested requirements

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99742
   Summary: Parameter packs not expanded with nested requirements
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

template 
concept C = (requires { requires B; } && ...);

static_assert(C);


gcc rejects this code.
https://godbolt.org/z/c6sEq5KEs

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #31 from Worx  ---
I use this Gentoo configuration :

CHOST="i586-pc-linux-gnu"
CFLAGS="-march=c3 -m3dnow -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

Here you are a comment shared in the below link : 
Warning: Do not use any stages or packages containing i686 instructions (such
as cmov) with the Samuel 2 and Ezra versions of the C3.

The Ezra doesn't have any special instructions that you could optimize for,
just consider it a K6-3 - basically a Pentium 2 with 3DNow.

http://wikigentoo.ksiezyc.pl/Safe_Cflags.htm#C3_Nehemiah_.28C5X.2FC5XL.2FC5P.29_.28VIA.29

So, How can i run a make bootstrap with GCC source directly, How can i setup
this configuration ?

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #30 from Worx  ---
(In reply to H.J. Lu from comment #28)
> (In reply to Worx from comment #27)
> > (gdb) disass/r (0x0804f547 - 2), +32
> > Dump of assembler code from 0x804f545 to 0x804f565:
> >0x0804f545:  00 00   add%al,(%eax)
> > => 0x0804f547:  0f 44 44 24 14  cmove  0x14(%esp),%eax
> 
> This is CMOV which is in i686.  Please configure GCC with
> i586-pc-linux-gnu, instead of i686-pc-linux-gnu.

Ok, it's well configure at the system level, in my Gentoo OS :

c3eden ~ # LANG=en_US.utf8 gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i586-pc-linux-gnu/9.3.0/lto-wrapper
Target: i586-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-9.3.0-r2/work/gcc-9.3.0/configure
--host=i586-pc-linux-gnu --build=i586-pc-linux-gnu --prefix=/usr
--bindir=/usr/i586-pc-linux-gnu/gcc-bin/9.3.0
--includedir=/usr/lib/gcc/i586-pc-linux-gnu/9.3.0/include
--datadir=/usr/share/gcc-data/i586-pc-linux-gnu/9.3.0
--mandir=/usr/share/gcc-data/i586-pc-linux-gnu/9.3.0/man
--infodir=/usr/share/gcc-data/i586-pc-linux-gnu/9.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/i586-pc-linux-gnu/9.3.0/include/g++-v9
--with-python-dir=/share/gcc-data/i586-pc-linux-gnu/9.3.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 9.3.0-r2 p4' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --disable-fixed-point --with-arch=i586
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-systemtap --enable-vtable-verify --enable-lto --without-isl
--enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 9.3.0 (Gentoo 9.3.0-r2 p4)

But when i launch a "make bootstrap" based on GCC git source code, it's
launched as an i686. Do I need to run a configure with a specfic option ? 

I raised this point when i had this second error. 

Sorry again for the dumb questions...

[Bug target/99733] darwin: missing ':' in error message about munmap

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #3 from Roland Illig  ---
(In reply to Iain Sandoe from comment #2)
> Personally, I would have preferred "'pch_address_space' : " but that
> triggers another warning about punctuation in diagnostics. So I left the
> colon out (on purpose, it was not an accident ;) ).

It should have been as simple as writing % instead of
'pch_address_space'.  Wasn't the diagnostic clear enough?  Martin Sebor did put
a lot of work into making the diagnostics uniform in style in 2019.

>From c-format.c:
> inform (format_string_loc,
> "if avoiding the apostrophe is not feasible, enclose "
> "it in a pair of %qs and %qs directives instead",
> "%<", "%>");

[Bug target/97329] POWER9 default cache and line sizes appear to be wrong

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

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

--- Comment #10 from Segher Boessenkool  ---
GCC 11 stage 4 will be fine.

I doubt you can ever measure a difference, but you can try :-)

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #29 from Jakub Jelinek  ---
I think not i586 but i486, at least unless processor_alias_table is inaccurate.
c3 with mmx/3dnow and not sse is
  {"c3", PROCESSOR_I486, CPU_NONE, PTA_MMX | PTA_3DNOW, 0, P_NONE},

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #28 from H.J. Lu  ---
(In reply to Worx from comment #27)
> (gdb) disass/r (0x0804f547 - 2), +32
> Dump of assembler code from 0x804f545 to 0x804f565:
>0x0804f545:  00 00   add%al,(%eax)
> => 0x0804f547:  0f 44 44 24 14  cmove  0x14(%esp),%eax

This is CMOV which is in i686.  Please configure GCC with
i586-pc-linux-gnu, instead of i686-pc-linux-gnu.

[Bug libfortran/99740] floating point exception in rand() in gfortran

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4
 Resolution|--- |INVALID

--- Comment #2 from kargl at gcc dot gnu.org ---
It is not rand().   Modifying your code gives

  program rantest
  implicit none
  integer*4 i
  real*4 x
  do i = 1, 7372933
write(11,*) -log(rand(0))
  end do
  x = rand(0)
  write(*,*) x
  end

% gfcx -o z -O -ffpe-trap=zero,invalid -g a.f && ./z
   0.

log() is from your math library, which likely documents that log(0) returns
divide-by-zero exception.  Nothing here to fix.

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() since r11-7526

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

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r11-7807-gbe70bb5e4babdf9d3d33e8f4658452038407fa8e
Author: Vladimir N. Makarov 
Date:   Tue Mar 23 17:51:21 2021 -0400

[PR99581] Use relaxed memory for more aarch64 memory constraints

The original patch for PR99581 resulted in GCC testsuite regression as
some constraints were not declared as relaxed memory ones.  This patch
fixes this.

gcc/ChangeLog:

PR target/99581
* config/aarch64/constraints.md (Utq, UOb, UOh, UOw, UOd, UOty):
Use define_relaxed_memory_constraint for them.

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #27 from Worx  ---
(gdb) disass/r (0x0804f547 - 2), +32
Dump of assembler code from 0x804f545 to 0x804f565:
   0x0804f545:  00 00   add%al,(%eax)
=> 0x0804f547:  0f 44 44 24 14  cmove  0x14(%esp),%eax
   0x0804f54c:  c7 04 24 18 00 00 00movl   $0x18,(%esp)
   0x0804f553:  89 44 24 44 mov%eax,0x44(%esp)
   0x0804f557:  8d 84 24 84 00 00 00lea0x84(%esp),%eax
   0x0804f55e:  89 44 24 04 mov%eax,0x4(%esp)
   0x0804f562:  e8 09 43 03 00  call   0x8083870
End of assembler dump.

[Bug libfortran/99740] floating point exception in rand() in gfortran

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2021-03-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from anlauf at gcc dot gnu.org ---
rand(3f) is not a Fortran standard function but provided by your Linux system.

The man page says:

   rand and drand return values in the range 0.0 through 1.0.

So rand may return 0. and an FP exception is not surprising.

If you agree we close your report as invalid.

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #26 from Worx  ---
worx@c3eden ~ $ grep "^flags" /proc/cpuinfo | head -1
flags   : fpu de tsc msr cx8 mtrr pge mmx 3dnow cpuid

[Bug target/99727] [11 Regression] MVE: ICE (segfault) in arm_print_operand at -O3 since r11-6616-g25bef689

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

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

Christophe Lyon  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-23
 Ever confirmed|0   |1

--- Comment #2 from Christophe Lyon  ---
Looks like a constraint problem: I kept the Um constraint as used by Neon,
while MVE needs Ux.

This patch fixes the ICE:
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 440fd6a..1351863 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -10858,7 +10858,7 @@ (define_insn "arm_vcx3q_p_v16qi"
 )

 (define_insn "*movmisalign_mve_store"
-  [(set (match_operand:MVE_VLD_ST 0 "neon_permissive_struct_operand"   
"=Um")
+  [(set (match_operand:MVE_VLD_ST 0 "neon_permissive_struct_operand"   
"=Ux")
(unspec:MVE_VLD_ST [(match_operand:MVE_VLD_ST 1 "s_register_operand" "
w")]
 UNSPEC_MISALIGNED_ACCESS))]
   "((TARGET_HAVE_MVE && VALID_MVE_SI_MODE (mode))
@@ -10871,7 +10871,7 @@ (define_insn "*movmisalign_mve_store"

 (define_insn "*movmisalign_mve_load"
   [(set (match_operand:MVE_VLD_ST 0 "s_register_operand"  
 "=w")
-   (unspec:MVE_VLD_ST [(match_operand:MVE_VLD_ST 1
"neon_permissive_struct_operand" " Um")]
+   (unspec:MVE_VLD_ST [(match_operand:MVE_VLD_ST 1
"neon_permissive_struct_operand" " Ux")]
 UNSPEC_MISALIGNED_ACCESS))]
   "((TARGET_HAVE_MVE && VALID_MVE_SI_MODE (mode))
 || (TARGET_HAVE_MVE_FLOAT && VALID_MVE_SF_MODE (mode)))

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #25 from H.J. Lu  ---
(In reply to Worx from comment #24)
> worx@c3eden ~ $ gdb ./sample.bin
> GNU gdb (Gentoo 10.1 vanilla) 10.1
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "i586-pc-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./sample.bin...
> (No debugging symbols found in ./sample.bin)
> (gdb) run
> Starting program: /home/worx/sample.bin
> 
> Program received signal SIGILL, Illegal instruction.
> 0x0804f547 in ?? ()
> (gdb)

Please try different N (between 2 and 20) with "disass/r (0x0804f547 - N), +32"
under gdb until you can figure out what Illegal instruction is.

[Bug c/99741] dllexport attribute is not compatible with c99 inline

[aladjev.andrew at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Andrew Aladjev  ---
PS https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088 is another issue that may
be related to this one.

[Bug c/99741] New: dllexport attribute is not compatible with c99 inline

[aladjev.andrew at gmail dot com via Gcc-bugs]

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

Bug ID: 99741
   Summary: dllexport attribute is not compatible with c99 inline
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aladjev.andrew at gmail dot com
  Target Milestone: ---

Created attachment 50466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50466=edit
fit.tar.gz

Hello, please review the following cmake issue here
https://gitlab.kitware.com/cmake/cmake/-/issues/21940#note_925715.

I am trying to create cross platform application, than I need to compile it
using MSVC. MSVC requires mandatory dllexport and dllimport attributes for all
functions including C99 inline functions. Clang is completely ignoring these
attributes in GNU env and it is always successful
https://github.com/llvm/llvm-project/commit/606bd6dcc547cf2f9fd7387321db79419bf60041.
GCC ignores only dllimport attribute, but fails with dllexport attribute.

Please review simplified project: a1.h, a1.c, a2.c and CMakeLists.txt attached.
You can try to build it on windows using:

CC="gcc" cmake -G "Unix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=1 . && make
CC="clang" cmake -G "Unix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=1 . && make

GCC provides error: multiple definition of func. I can't understand the reason
of this error: maybe dllexport converted C99 inline declaration into C89?

Workaround for this issue is to remove dllexport attribute for windows platform
+ gcc on makefile generator layer (cmake/etc).

PS this issue is indirectly related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90161

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #24 from Worx  ---
worx@c3eden ~ $ gdb ./sample.bin
GNU gdb (Gentoo 10.1 vanilla) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i586-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./sample.bin...
(No debugging symbols found in ./sample.bin)
(gdb) run
Starting program: /home/worx/sample.bin

Program received signal SIGILL, Illegal instruction.
0x0804f547 in ?? ()
(gdb)

[Bug target/99724] [11 Regression] CE in in extract_insn, at recog.c:2770

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

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

--- Comment #6 from Christophe Lyon  ---
Looks good to me, thanks

[Bug libfortran/99740] New: floating point exception in rand() in gfortran

[pvoytas at gmail dot com via Gcc-bugs]

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

Bug ID: 99740
   Summary: floating point exception in rand() in gfortran
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pvoytas at gmail dot com
  Target Milestone: ---

Possible bug in gfortran rand() function?

Included code fails with IEEE divide by zero signalling. 
When I request a backtrace, it is from a line with "-log(rand(0))". 

Last output to the file for code included below is 0.183492497 on line 7372837.
If I just write the rand(0) to file (not taking the log), the code finishes
with no errors and the values near line 7372837 don't seem to have any weird
values that would account for the error.

Code runs with out errors either way if I use "call random_number(x)" to
generate random numbers. Since I'm porting old code, the backward compatibility
of rand(0) is needed.

(note: Code compiles and runs successfully with either g77 or gfortran on
Centos 6.x machine with distro default gcc)

gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/ohpc/pub/compiler/gcc/8.3.0/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib
--enable-languages=c,c++,fortran --prefix=/opt/ohpc/pub/compiler/gcc/8.3.0
--disable-static --enable-shared
Thread model: posix
gcc version 8.3.0 (GCC)

Distro:
Oracle Linux (7.9): uname -a gives:
Linux  5.4.17-2011.6.2.el7uek.x86_64 #2 SMP Thu Sep 3 14:09:14 PDT
2020 x86_64 x86_64 x86_64 GNU/Linux

compile command:
gfortran -ffpe-trap=zero -g rantest.f

compiles with no errors

runtime errors:
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:
#0  0x7fc09a5113ff in ???
#1  0x7fc09ad330bc in ???
#2  0x4008cf in rantest
at /home/pvoytas/ps_cp/accidentals/time_series/rantest.f:10
#3  0x400968 in main
at /home/pvoytas/ps_cp/accidentals/time_series/rantest.f:13
Floating exception (core dumped)

code:
  program rantest
  implicit none
  integer*4 i
  real*8 x

  do i=1,1000
c   call random_number(x)
c   write(11,*)x
c   write(11,*)rand(0)
   write(11,*)-log(rand(0))
  enddo
  stop
  end

[Bug tree-optimization/99739] New: [11 Regression] missing optimization of a repeated conditional

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

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

Bug ID: 99739
   Summary: [11 Regression] missing optimization of a repeated
conditional
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Prior to r11-5805 both ff() and gg() in the test case below resulted in optimal
code.  With the change, the second conditional in g() is no longer recognized
as equivalent to the first and so the function isn't optimized as expected.

Incidentally, the same regression was also introduced once before: in r235653.

$ cat x.c && gcc -O1 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
static inline int f (int i, int j, int k)
{
  int x = 1;

  if (i && j && k)
x = 2;

  if (i && j && k)
return x;

  return -1;
}

void ff (int i, int j, int k)
{
  int x = f (i, j, k);
  if (x == 1)
__builtin_abort ();
}


static inline int g (int i, int j, int k)
{
  int x = 1;

  if (i && j && k)
x = 2;

  if (i && k && j)
return x;

  return -1;
}

void gg (int i, int j, int k)
{
  int x = g (i, j, k);
  if (x == 1)
__builtin_abort ();
}

;; Function ff (ff, funcdef_no=1, decl_uid=1951, cgraph_uid=2, symbol_order=1)

void ff (int i, int j, int k)
{
   [local count: 1073741824]:
  return;

}



;; Function gg (gg, funcdef_no=3, decl_uid=1963, cgraph_uid=4, symbol_order=3)

Removing basic block 6
Removing basic block 7
void gg (int i, int j, int k)
{
  _Bool _7;
  _Bool _8;
  _Bool _11;
  _Bool _14;
  _Bool _16;

   [local count: 1073741824]:
  _7 = i_2(D) != 0;
  _8 = j_3(D) != 0;
  _14 = k_4(D) != 0;
  _11 = _7 & _14;
  _16 = _8 & _11;
  if (_16 != 0)
goto ; [94.27%]
  else
goto ; [5.73%]

   [local count: 1012175616]:
  if (k_4(D) != 0)
goto ; [100.00%]
  else
goto ; [0.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}

[Bug analyzer/99716] -Wanalyzer-double-fclose when fclose is called inside a loop

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

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

--- Comment #4 from David Malcolm  ---
(In reply to David Malcolm from comment #2)
> Also, I think we're missing a warning about "fp" possibly being NULL, for
> the case where the fopen fails.

I've filed this as bug 99738.

[Bug analyzer/99738] New: RFE: analyzer should complain about unchecked FILE *

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

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

Bug ID: 99738
   Summary: RFE: analyzer should complain about unchecked FILE *
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In PR 99716 I noted we don't complain about the fprintf in:

FILE *fp = fopen ("/tmp/test", "w");
fprintf (fp, "hello");
fclose (fp);

This becomes the following at the gimple ssa level:

  fp_7 = fopen ("/tmp/test", "w");
  __builtin_fwrite ("hello", 1, 5, fp_7);
  fclose (fp_7);

and we have:
DEF_LIB_BUILTIN  (BUILT_IN_FWRITE, "fwrite", 
  BT_FN_SIZE_CONST_PTR_SIZE_SIZE_FILEPTR, ATTR_NONNULL_LIST)

so we should have complained due to the ATTR_NONNULL_LIST due to fp_7 being in
the "unchecked" state in the "file" state machine.

Turns out that sm-file.cc doesn't yet implement checks for the "unchecked"
state, and probably should (or somehow be merged with sm-malloc.cc).

Filing this here as it's probably a bit late to be adding this for GCC 11.

[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

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

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

--- Comment #3 from Segher Boessenkool  ---
The only such __SIZEOF_* macro that is not about a standards-required type
is for int128.  Not the best example ;-)

There are not predefines for __SIZEOF_FLOAT128__ etc. either.

In an ideal world the user can just assume those types exist always.  In a
less ideal world, use autoconf?  You have to anyway, if you want to support
older compilers at all.

[Bug c++/99737] New: [modules] malloc(): smallbin double linked list corrupted

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Bug ID: 99737
   Summary: [modules] malloc(): smallbin double linked list
corrupted
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.lelyakin at googlemail dot com
  Target Milestone: ---

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header sstream
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstring
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header numeric
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header limits
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string_view
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cuchar
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header filesystem

malloc(): smallbin double linked list corrupted
In file included from /usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:53,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/bits/fs_path.h:46,
 from /usr/local/include/c++/11.0.1/filesystem:45:
/usr/local/include/c++/11.0.1/bits/allocated_ptr.h:58:66: internal compiler
error: Aborted
   58 |typename _Req = _Require>>
  |  ^~
0x110107f crash_signal
../../gcc/gcc/toplev.c:327
0x1d46680 xrealloc
../../gcc/libiberty/xmalloc.c:179
0xa6d283 void va_heap::reserve(vec*&, unsigned int, bool)
../../gcc/gcc/vec.h:290
0xa6d283 vec::reserve(unsigned int, bool)
../../gcc/gcc/vec.h:1778
0xa6d283 vec::safe_push(tree_node* const&)
../../gcc/gcc/vec.h:1887
0xa6d283 trees_in::post_process(tree_node*)
../../gcc/gcc/cp/module.cc:2956
0xa6d283 trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11495
0xa6f3e1 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14855
0xa6fa5d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18117
0xa6fb1f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18778
0xa72d37 lazy_load_pendings(tree_node*)
../../gcc/gcc/cp/module.cc:18871
0xb2237f lookup_template_class_1
../../gcc/gcc/cp/pt.c:9799
0xb23f4c lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:10237
0xb4c28b finish_template_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:3563
0xabe061 cp_parser_template_id
../../gcc/gcc/cp/parser.c:17458
0xabe24b cp_parser_class_name
../../gcc/gcc/cp/parser.c:24685
0xab57ba cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:7002
0xab57ba cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6684
0xacaf34 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:18851
0xaa9cdd cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:18509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
----
g++ (GCC) 11.0.1 20210323 (experimental)
Copyright (C) 2021 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++/99479] [modules] ICE Aborted signal terminated program cc1plus

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #4 from Alexander Lelyakin  ---
There is a shorter sequence:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstdalign
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ranges
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string_view
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header atomic
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header filesystem

corrupted double-linked list
corrupted double-linked list
g++: internal compiler error: Aborted signal terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

g++ (GCC) 11.0.1 20210323 (experimental)
Copyright (C) 2021 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++/97848] [missed optimization] tls init function check emitted for consinit thread_local variables (C++20)

[avi--- via Gcc-bugs]

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

--- Comment #1 from Avi Kivity  ---
Still bad on trunk. Clang gets this right:

foo_good():   # @foo_good()
movqx@GOTTPOFF(%rip), %rax
movl%fs:(%rax), %eax
retq
set_foo(int):# @set_foo(int)
movqx@GOTTPOFF(%rip), %rax
movl%edi, %fs:(%rax)
retq

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

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

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

Bug 99733 Summary: darwin: missing ':' in error message about munmap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99733

   What|Removed |Added

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

[Bug target/99733] darwin: missing ':' in error message about munmap

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Sandoe  ---
(In reply to Roland Illig from comment #0)
> config/host-darwin.c says:
> > could not unmap % %m
> 
> There is a ':' missing before the '%m'.

(I changed this to avoid a diagnostic about "unquoted identifier or keyword".)

Personally, I would have preferred "'pch_address_space' : " but that triggers
another warning about punctuation in diagnostics. So I left the colon out (on
purpose, it was not an accident ;) ).

However, I have not a strong feeling about it - and if it helps translation to
leave it in all OK with me.

So we have now got "'pch_address_space': "

> Plus, there is a unit test missing to demonstrate this typo.
> Granted, this error message may be hard to produce anyway.

Yeah, I don't know a reasonable way to do that.

As noted in the commit message for the change I am not sure that the message is
really a worthwhile end-user one, since there's nothing that they can do about
it - however, fixing that is not something for stage 4.

[Bug target/99724] [11 Regression] CE in in extract_insn, at recog.c:2770

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Full patch I'm going to bootstrap/regtest.

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

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

Please run this and upload its output.  If it fails to run, please
show me the output of

$ grep "^flags" /proc/cpuinfo | head -1

[Bug target/99733] darwin: missing ':' in error message about munmap

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:7af8ec508f8105a4c4ea94246c1c4c25596cf6a5

commit r11-7805-g7af8ec508f8105a4c4ea94246c1c4c25596cf6a5
Author: Iain Sandoe 
Date:   Tue Mar 23 19:42:36 2021 +

Darwin : Address a translation comment.

Add a ':' to make the diagnostic read 'pch_address_space': xxx.

gcc/ChangeLog:

PR target/99733
* config/host-darwin.c (darwin_gt_pch_use_address): Add a
colon to the diagnostic message.

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[tunagul29 at icloud dot com via Gcc-bugs]

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

--- Comment #7 from Tuna Gül  ---
I guess i can post a workaround here

This code doesnt compile:
"""
int main() {
({
unsigned int len = 10;
struct {
int array[len];
} new_object;
new_object;
});
}
"""

But this does:

"""
unsigned int foo(unsigned int rv) { return rv; }

int main() {
({
unsigned int len = 10;
struct {
int array[foo(len)];
} new_object;
new_object;
});
}
"""

[Bug middle-end/99736] Statement expression (gcc extension) cannot return struct with variable length array

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
Summary|Statement expression (gcc   |Statement expression (gcc
   |extension) cannot return|extension) cannot return
   |struct (with variable   |struct with variable length
   |length array) object|array
   Keywords||ice-on-valid-code
  Component|c   |middle-end

--- Comment #2 from Andrew Pinski  ---
Dup of bug 29970.

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

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tunagul29 at icloud dot com

--- Comment #6 from Andrew Pinski  ---
*** Bug 99736 has been marked as a duplicate of this bug. ***

[Bug c/99736] Statement expression (gcc extension) cannot return struct (with variable length array) object

[tunagul29 at icloud dot com via Gcc-bugs]

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

--- Comment #1 from Tuna Gül  ---
Sorry for wrong compiler output
This should be the compiler output
(I dont know how to edit the original description)
"""
test.c: In function ‘main’:
test.c:2:3: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:2755
2 |  ({
  |  ~^
3 |   unsigned int length = 10;
  |   ~
4 |   struct {
  |   
5 |int array[length];
  |~~
6 |   } new_object;
  |   ~
7 |   new_object;
  |   ~~~
8 |  });
  |  ~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
"""

[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608

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

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

--- Comment #7 from Nathan Sidwell  ---
found while reducing testcase

* bd71889b901 2021-03-23 | c++: Note duplicates in symbol table [PR 99283]

[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #32 from Jürgen Reuter  ---
Ready for merge?

[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r11-7804-gbd71889b9017751e1a06970d20b28b9fe9479bdc
Author: Nathan Sidwell 
Date:   Tue Mar 23 12:23:30 2021 -0700

c++: Note duplicates in symbol table [PR 99283]

I ran into this reducing 99283, we were failing to mark binding
vectors when the current TU declares a duplicate decl (as opposed to
an import introduces a duplicate).

PR c++/99283
gcc/cp/
* name-lookup.c (check_module_override): Set global or partition
DUP on the binding vector.
gcc/testsuite/
* g++.dg/modules/pr99283-1_a.H: New.
* g++.dg/modules/pr99283-1_b.H: New.

[Bug c/99736] New: Statement expression (gcc extension) cannot return struct with variable length array

[tunagul29 at icloud dot com via Gcc-bugs]

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

Bug ID: 99736
   Summary: Statement expression (gcc extension) cannot return
struct with variable length array
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tunagul29 at icloud dot com
  Target Milestone: ---

Created attachment 50463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50463=edit
C file which contains the bug

Statement Expressions cannot return an anonymous struct with variable length
array object. I attached the file but here is the bug:

"""
int main() {
({
unsigned int length = 10;
struct {
int array[length];
} new_object;
new_object;
});
}
"""

I conpiled it with mingcw and gcc 9.3 on wsl, both failed.

I am using gcc 9.3.0 wich gives the output: 
"""
test2.c: In function ‘main’:
test2.c:7:3: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:2755
7 |  ({
  |  ~^
8 |   unsigned int length = foo();
  |   
9 |   struct {
  |   
   10 |int array[length];
  |~~
   11 |   } new_object;
  |   ~
   12 |   new_object;
  |   ~~~
   13 |  });
  |  ~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
"""
with -Wall and -Wextra flags.

gcc -v output:

"""
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
"""

[Bug target/99733] darwin: missing ':' in error message about munmap

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||iains at gcc dot gnu.org
 Blocks||40883
   Severity|normal  |trivial


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug 40883] [meta-bug] Translation breakage with trivial fixes

[Bug c++/99729] Tweak -Wdeprecated-declarations with namespaces

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79078,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=43797

--- Comment #1 from Eric Gallager  ---
See also bug 79078 and bug 43797 for other bugs about the "deprecated"
attribute infecting entities other that the one originally declared to be
deprecated

[Bug testsuite/99731] g++.dg/modules/alias-1_a.H: error: failed to read compiled module: No such file or directory

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-03-23
 Status|UNCONFIRMED |NEW

--- Comment #2 from H.J. Lu  ---
(In reply to Nathan Sidwell from comment #1)
> How repeatable is this?

Close to 100%.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #55 from Jakub Jelinek  ---
Created attachment 50462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50462=edit
gcc11-pr98860-2.patch

And the noisy variant this.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #50460|0   |1
is obsolete||

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

So the non-noisy version of the patch could be this.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #53 from Jakub Jelinek  ---
Comment on attachment 50460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50460
Slightly adjusted patch to fix errors

Thanks for fixing my bugs, but there is another one:
if (TARGET_PECOFF && opts_set->x_dwarf_version)
should have been really
if (TARGET_PECOFF && !opts_set->x_dwarf_version)
The intent was to make -gdwarf-4 the default for broken linker,
but still support -gdwarf-5 in the hope that when using it explictly, the user
has updated his linker.
Another option is to issue a warning or inform for the
#ifdef HAVE_LD_BROKEN_PE_DWARF5
if (TARGET_PECOFF && opts_set->x_dwarf_version && opts->x_dwarf_version >= 5)
case and reset it to -gdwarf-4.

[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble

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

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

--- Comment #9 from Jonathan Wakely  ---
[test@ibm-p8-cluster-02 ~]$ cat 97653.c
int printf(const char*, ...);

const unsigned long k = 256;

int main()
{
  long double r[] = { 0.1L, 0.2L, 0.5L, 0.9L };
  for (int i = 0; i < 4; ++i)
  {
unsigned long j = k * r[i];
printf("%lu * %Lf = %lu\n", k, r[i], j);
  }
}
[test@ibm-p8-cluster-02 ~]$ ~/gcc/ieee/bin/gcc 97653.c  -mno-gnu-attribute
-mabi=ibmlongdouble  -Wall -static-libgcc -v  && ./a.out
Using built-in specs.
COLLECT_GCC=/home/test/gcc/ieee/bin/gcc
COLLECT_LTO_WRAPPER=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /home/test/src/gcc/configure --prefix=/home/test/gcc/ieee
--disable-multilib --disable-bootstrap --enable-languages=c++ --disable-pch
--disable-nls --without-isl --with-long-double-format=ieee : (reconfigured)
/home/test/src/gcc/configure --prefix=/home/test/gcc/ieee --disable-multilib
--disable-bootstrap --enable-languages=c++ --disable-pch --disable-nls
--without-isl --with-long-double-format=ieee
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210323 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a-'
 /home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/cc1
-quiet -v 97653.c -quiet -dumpdir a- -dumpbase 97653.c -dumpbase-ext .c
-mno-gnu-attribute -mabi=ibmlongdouble -Wall -version -o /tmp/ccNHNZzj.s
GNU C17 (GCC) version 11.0.1 20210323 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 11.0.0 20210225 (Red Hat 11.0.0-0), GMP
version 6.2.0, MPFR version 4.1.0-p9, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../../powerpc64le-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/include
 /usr/local/include
 /home/test/gcc/ieee/include
 /home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/include-fixed
 /usr/include
End of search list.
GNU C17 (GCC) version 11.0.1 20210323 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 11.0.0 20210225 (Red Hat 11.0.0-0), GMP
version 6.2.0, MPFR version 4.1.0-p9, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: ab29af0a0f73449cd280c2751cbad267
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a-'
 as -v -a64 -mpower8 -mlittle -o /tmp/cc4MmQYf.o /tmp/ccNHNZzj.s
GNU assembler version 2.35.1 (ppc64le-redhat-linux) using BFD version version
2.35.1-41.fc34
COMPILER_PATH=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/
LIBRARY_PATH=/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a.'
 /home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/collect2
-plugin
/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/liblto_plugin.so
-plugin-opt=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccwamb6Q.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh
--eh-frame-hdr -V -m elf64lppc -dynamic-linker /lib64/ld64.so.2
/lib/../lib64/crt1.o /lib/../lib64/crti.o
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/crtbegin.o
-L/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1
-L/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../..
/tmp/cc4MmQYf.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/crtend.o
/lib/../lib64/crtn.o
GNU ld version 2.35.1-41.fc34
  Supported emulations:
   elf64lppc
   elf32lppc
   elf32lppclinux
   elf32lppcsim
   elf64ppc
   elf32ppc
   elf32ppclinux
   elf32ppcsi

[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Reopening as I'm still seeing this (or it's returned).

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #52 from jyong at gcc dot gnu.org ---
Oops I need retest with optimizations enabled to see the debug sections
emitted.
On the other hand, the new adjusted patch detects the binutils bug fine, tested
with new and old binutils.

[Bug testsuite/99731] g++.dg/modules/alias-1_a.H: error: failed to read compiled module: No such file or directory

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Nathan Sidwell  ---
How repeatable is this?

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

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

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

--- Comment #8 from Jakub Jelinek  ---
I wonder about:

--- gcc/dwarf2cfi.c.jj  2021-03-02 11:25:47.217727061 +0100
+++ gcc/dwarf2cfi.c 2021-03-23 17:34:58.240281522 +0100
@@ -2705,12 +2705,15 @@ scan_trace (dw_trace_info *trace, bool e
  dwarf2out_flush_queued_reg_saves ();
}
  else if (!NONJUMP_INSN_P (insn)
-  || clobbers_queued_reg_save (insn)
   || find_reg_note (insn, REG_CFA_FLUSH_QUEUE, NULL))
dwarf2out_flush_queued_reg_saves ();
  any_cfis_emitted = false;

  add_cfi_insn = insn;
+
+ if (queued_reg_saves.length () && clobbers_queued_reg_save (insn))
+   dwarf2out_flush_queued_reg_saves ();
+
  scan_insn_after (insn);
  control = insn;
}

For calls or REG_CFA_FLUSH_QUEUE I can understand wanting to flush queued
register saves after the previous instruction, but for clobbers_queued_reg_save
cases I don't understand that.
This is about the:
pushq %rbp
movq %rsp, %rbp
case.  On pushq %rbp we queue the DW_CFA_expression for %rbp (but use %rbp in
the expression), then see clobbers_queued_reg_save (insn) on the movq %rsp,
%rbp
returning true because that instruction overwrites it.  But as it isn't really
a call, I believe at least the libgcc unwinder for async signals evaluates all
FDE instructions until the current pc inclusive.
pushq %rbp doesn't really change %rbp and CFA is computed from %r10 at that
point, and when we are at the start of movq %rsp, %rbp, we still haven't
changed %rbp.  As it is not a call, it doesn't have a separate byte abused for
in the middle of the instruction and so the only other possibility is after
that instruction.

[Bug c++/99735] New: [modules] in system headers: non-template type ‘rebind_alloc’ used as a template

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

emplate type
‘rebind_alloc’ used as a template
 1133 |   basic_string, _Alloc2>
__str(__a);
  |  ^
/usr/local/include/c++/11.0.1/bits/fs_path.h:1133:66: error: non-template type
‘rebind_alloc’ used as a template
/usr/local/include/c++/11.0.1/bits/fs_path.h: In instantiation of
‘std::__cxx11::basic_string<_CharT, _Traits, _Allocator>
std::filesystem::__cxx11::path::generic_string(const _Allocator&) const [with
_CharT = char32_t; _Traits = std::char_traits; _Allocator =
std::allocator]’:
/usr/local/include/c++/11.0.1/bits/fs_path.h:1189:37:   required from here
/usr/local/include/c++/11.0.1/bits/fs_path.h:1131:13: error: non-template type
‘rebind_alloc’ used as a template
 1131 |   using _Alloc2 = typename allocator_traits<_Allocator>::template
  | ^~~
/usr/local/include/c++/11.0.1/bits/fs_path.h:1133:66: error: non-template type
‘rebind_alloc’ used as a template
 1133 |   basic_string, _Alloc2>
__str(__a);
  |  ^
/usr/local/include/c++/11.0.1/bits/fs_path.h:1133:66: error: non-template type
‘rebind_alloc’ used as a template
/usr/local/include/c++/11.0.1/filesystem: warning: not writing module
‘/usr/local/include/c++/11.0.1/filesystem’ due to errors

g++ (GCC) 11.0.1 20210323 (experimental)
Copyright (C) 2021 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++/99730] gcc cannot choose the best overload resolution with constrained function

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #3 from 康桓瑋  ---
Really appreciate your reply and explanation.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

jyong at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #50459|0   |1
is obsolete||

--- Comment #51 from jyong at gcc dot gnu.org ---
Created attachment 50460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50460=edit
Slightly adjusted patch to fix errors

Adjust the patch to deal with xyes and silent result issues. Testing with older
binutils worked, -gdwarf-5 ignored, not sure if intentional.

[Bug c++/99732] gcc accepts overload a member function without ref-qualifier with a member function with a ref-qualifier

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-23

[Bug target/99733] darwin: missing ':' in error message about munmap

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-03-23
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW

[Bug c++/99734] [modules] ICE in most_specialized_instantiation

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Alexander Lelyakin  ---
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header filesystem

In file included from /usr/local/include/c++/11.0.1/bits/locale_classes.h:857,
 from /usr/local/include/c++/11.0.1/locale:39,
 from /usr/local/include/c++/11.0.1/bits/fs_path.h:37,
 from /usr/local/include/c++/11.0.1/filesystem:45:
/usr/local/include/c++/11.0.1/bits/locale_classes.tcc:275:44: internal compiler
error: in most_specialized_instantiation, at cp/pt.c:24830
  275 | use_facet >(const locale&);
  |^
0x725070 most_specialized_instantiation(tree_node*)
../../gcc/gcc/cp/pt.c:24830
0xb2e1e9 determine_specialization
../../gcc/gcc/cp/pt.c:2457
0xb3418c determine_specialization
../../gcc/gcc/cp/pt.c:2156
0xb3418c check_explicit_specialization(tree_node*, tree_node*, int, int,
tree_node*)
../../gcc/gcc/cp/pt.c:3121
0x9d481e grokfndecl
../../gcc/gcc/cp/decl.c:10064
0x9db1f3 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:13910
0xac82c1 cp_parser_explicit_instantiation
../../gcc/gcc/cp/parser.c:18240
0xad8840 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14096
0xad80e9 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14159
0xad80e9 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:13947
0xad8582 cp_parser_namespace_body
../../gcc/gcc/cp/parser.c:20447
0xad8582 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:20425
0xad8cd8 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14110
0xad952c cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14159
0xad952c cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4942
0xad952c c_parse_file()
../../gcc/gcc/cp/parser.c:45250
0xbfd51d c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

g++ (GCC) 11.0.1 20210323 (experimental)
Copyright (C) 2021 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 analyzer/99716] -Wanalyzer-double-fclose when fclose is called inside a loop

[rjones at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Richard W.M. Jones  ---
FYI the original code is:
https://github.com/libguestfs/libguestfs/blob/e0a11061035d47b118c95706240bcc17fd576edc/tests/mount-local/test-parallel-mount-local.c#L299-L335

[Bug c++/99734] New: [modules] ICE in most_specialized_instantiation

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Bug ID: 99734
   Summary: [modules] ICE in most_specialized_instantiation
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.lelyakin at googlemail dot com
  Target Milestone: ---

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header system_error
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header future

In file included from /usr/local/include/c++/11.0.1/bits/locale_classes.h:857,
 from /usr/local/include/c++/11.0.1/bits/ios_base.h:41,
 from /usr/local/include/c++/11.0.1/ios:42,
 from /usr/local/include/c++/11.0.1/ostream:38,
 from /usr/local/include/c++/11.0.1/bits/unique_ptr.h:42,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:59,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/condition_variable:43,
 from /usr/local/include/c++/11.0.1/future:39:
/usr/local/include/c++/11.0.1/bits/locale_classes.tcc:275:44: internal compiler
error: in most_specialized_instantiation, at cp/pt.c:24830
  275 | use_facet >(const locale&);
  |^
0x725070 most_specialized_instantiation(tree_node*)
../../gcc/gcc/cp/pt.c:24830
0xb2e1e9 determine_specialization
../../gcc/gcc/cp/pt.c:2457
0xb3418c determine_specialization
../../gcc/gcc/cp/pt.c:2156
0xb3418c check_explicit_specialization(tree_node*, tree_node*, int, int,
tree_node*)
../../gcc/gcc/cp/pt.c:3121
0x9d481e grokfndecl
../../gcc/gcc/cp/decl.c:10064
0x9db1f3 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:13910
0xac82c1 cp_parser_explicit_instantiation
../../gcc/gcc/cp/parser.c:18240
0xad8840 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14096
0xad80e9 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14159
0xad80e9 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:13947
0xad8582 cp_parser_namespace_body
../../gcc/gcc/cp/parser.c:20447
0xad8582 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:20425
0xad8cd8 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14110
0xad952c cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14159
0xad952c cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4942
0xad952c c_parse_file()
../../gcc/gcc/cp/parser.c:45250
0xbfd51d c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

g++ (GCC) 11.0.1 20210323 (experimental)
Copyright (C) 2021 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 target/99733] New: darwin: missing ':' in error message about munmap

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99733
   Summary: darwin: missing ':' in error message about munmap
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

config/host-darwin.c says:
> could not unmap % %m

There is a ':' missing before the '%m'.
Plus, there is a unit test missing to demonstrate this typo.
Granted, this error message may be hard to produce anyway.

[Bug c++/99730] gcc cannot choose the best overload resolution with constrained function

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

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

--- Comment #2 from Jonathan Wakely  ---
See https://wg21.link/p2113 which was implemented in r11-1571

[Bug c++/99730] gcc cannot choose the best overload resolution with constrained function

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Constraints are only used as a tie-breaker for equivalent overloads. These
overloads are not the same.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #50 from jyong at gcc dot gnu.org ---
I'll try testing it out over the next few days, thanks for the patch.

[Bug analyzer/99716] -Wanalyzer-double-fclose when fclose is called inside a loop

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

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from David Malcolm  ---
Confirmed.

Loop body is:
  fp_7 = fopen ("/tmp/test", "w");
  __builtin_fwrite ("hello", 1, 5, fp_7);
  fclose (fp_7);
  i_10 = i_1 + 1;

We're not transitioning fp_7 from "unchecked" back to "opened" at the 2nd
fopen.

Also, I think we're missing a warning about "fp" possibly being NULL, for the
case where the fopen fails.

[Bug c++/99732] New: gcc accepts overload a member function without ref-qualifier with a member function with a ref-qualifier

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99732
   Summary: gcc accepts overload a member function without
ref-qualifier with a member function with a
ref-qualifier
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

struct S {
  constexpr auto f(auto...) &&{ return false; }
  constexpr auto f(auto...) requires true { return true;  }
};

static_assert(S{}.f());

gcc accepts this code.

https://godbolt.org/z/7rdWEsrfv

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

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

In that case this completely untested patch which could work, but no way to
really test it myself properly (nor have time to do that).
It needs testing both with bad and good binutils.

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #22 from H.J. Lu  ---
(In reply to Worx from comment #21)
> Sorry about the dumb question, but how to know ?

Run it under gdb and disassemble.  It should show which instruction caused
the problem.

[Bug testsuite/99731] New: g++.dg/modules/alias-1_a.H: error: failed to read compiled module: No such file or directory

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

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

Bug ID: 99731
   Summary: g++.dg/modules/alias-1_a.H: error: failed to read
compiled module: No such file or directory
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: nathan at acm dot org
  Target Milestone: ---

On x86-64 machine with 112 processors,

$ make -j 56 check RUNTESTFLAGS="--target_board='unix{-m32,}'"

leads to

In module imported at
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_b.C:5:1:
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: error:
failed to read compiled module: No such file or directory
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: note:
compiled module file is
'gcm.cache/./export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H.gcm'
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: note:
imports must be built before being imported
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: fatal
error: returning to the gate for a mechanical issue
compilation terminated.
compiler exited with status 1
FAIL: g++.dg/modules/alias-1_b.C -std=c++17 (test for excess errors)
Excess errors:
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: error:
failed to read compiled module: No such file or directory
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: fatal
error: returning to the gate for a mechanical issue
compilation terminated.

FAIL: g++.dg/modules/dir-only-2_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/dir-only-2_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/dir-only-2_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/cpp-6_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/cpp-6_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/cpp-6_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++17  scan-lang-dump-times module "CMI
is " 1
FAIL: g++.dg/modules/alias-1_d.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/alias-1_d.C module-cmi kevin (gcm.cache/kevin.gcm)
FAIL: g++.dg/modules/alias-1_e.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/alias-1_f.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++2a  scan-lang-dump-times module "CMI
is " 1
FAIL: g++.dg/modules/alias-1_d.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/alias-1_d.C module-cmi kevin (gcm.cache/kevin.gcm)
FAIL: g++.dg/modules/alias-1_e.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/alias-1_f.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++2b  scan-lang-dump-times module "CMI
is " 1
FAIL: g++.dg/modules/alias-1_d.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/alias-1_d.C module-cmi kevin (gcm.cache/kevin.gcm)
FAIL: g++.dg/modules/alias-1_e.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/alias-1_f.C -std=c++2b (test for excess errors)

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #21 from Worx  ---
Sorry about the dumb question, but how to know ?

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #20 from H.J. Lu  ---
(In reply to Worx from comment #19)
> It's seems that the patch fix the issue. 
> 
> Unfortunately, I have another error, but it's maybe i do not proper
> configure "-march=c3"
> 
> 
> 
> make[3]: Leaving directory '/opt/gcc/host-i686-pc-linux-gnu/libdecnumber'
> make[3]: Entering directory '/opt/gcc/host-i686-pc-linux-gnu/gcc'
> build/gengtype  \
> -S ../.././gcc -I gtyp-input.list -w tmp-gtype.state
> /bin/sh ../.././gcc/../move-if-change tmp-gtype.state gtype.state
> build/gengtype  \
> -r gtype.state
> make[3]: *** [Makefile:2786: s-gtype] Illegal instruction

Which instruction is Illegal instruction?

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #48 from jyong at gcc dot gnu.org ---
Now that's an interesting trick I never thought of.

There's LLVM based mingw, but I have never used nor do I know if it is relevant
here. Gold is ELF only as far as I know, so it would never be used. That should
leave only BFD ld.

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #19 from Worx  ---
It's seems that the patch fix the issue. 

Unfortunately, I have another error, but it's maybe i do not proper configure
"-march=c3"



make[3]: Leaving directory '/opt/gcc/host-i686-pc-linux-gnu/libdecnumber'
make[3]: Entering directory '/opt/gcc/host-i686-pc-linux-gnu/gcc'
build/gengtype  \
-S ../.././gcc -I gtyp-input.list -w tmp-gtype.state
/bin/sh ../.././gcc/../move-if-change tmp-gtype.state gtype.state
build/gengtype  \
-r gtype.state
make[3]: *** [Makefile:2786: s-gtype] Illegal instruction
make[3]: Leaving directory '/opt/gcc/host-i686-pc-linux-gnu/gcc'
make[2]: *** [Makefile:4822: all-stage2-gcc] Error 2
make[2]: Leaving directory '/opt/gcc'
make[1]: *** [Makefile:25993: stage2-bubble] Error 2
make[1]: Leaving directory '/opt/gcc'
make: *** [Makefile:26213: bootstrap] Error 2

[Bug c++/99730] New: gcc cannot choose the best overload resolution with constrained function

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99730
   Summary: gcc cannot choose the best overload resolution with
constrained function
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

auto f(auto&&...) {}
auto f(auto...) requires true {}

int main() {
  f();
}


gcc reject with:

:5:5: error: call of overloaded 'f()' is ambiguous
5 |   f();
  | ^

https://godbolt.org/z/e8jas5frc

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

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

https://gcc.gnu.org/g:6b1f841ce0ccf30eda7896ba5ab0aa94c72307b2

commit r11-7799-g6b1f841ce0ccf30eda7896ba5ab0aa94c72307b2
Author: Jakub Jelinek 
Date:   Tue Mar 23 16:29:47 2021 +0100

Add forgotten attribution on PR target/99593 testcase.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #47 from Jakub Jelinek  ---
Does mingw/cygwin always use GNU binutils?
At least for ld.bfd, a quick and reliable test could be
$gcc_cv_ld --verbose 2>&1 | grep -q
'\.debug_loclists.*BLOCK.*__section_alignment__.*NOLOAD.*:'
&& $gcc_cv_ld --verbose 2>&1 | grep -q
'\.debug_rnglists.*BLOCK.*__section_alignment__.*NOLOAD.*:'
or so in configure.ac (for mingw/cygwin only, and AC_DEFINE a macro in that
case).

[Bug c++/99729] Tweak -Wdeprecated-declarations with namespaces

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-03-23
 Ever confirmed|0   |1
   Keywords||diagnostic

[Bug c++/99729] New: Tweak -Wdeprecated-declarations with namespaces

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

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

Bug ID: 99729
   Summary: Tweak -Wdeprecated-declarations with namespaces
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

namespace [[deprecated]] N { struct S { }; }
using namespace N;
S s;

we should warn about the using-directive, but not also the declaration 
of 's'.

(From https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567148.html.)

[Bug c++/99728] code pessimization when using wrapper classes around SIMD types

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

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

--- Comment #8 from Jonathan Wakely  ---
It's landed r11-6935 aka g:2bcceb6fc59fcdaf51006d4fcfc71c2d26761396

[Bug c++/99318] [10 Regression] -Wdeprecated-declarations where non-should be?

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11 Regression]  |[10 Regression]
   |-Wdeprecated-declarations   |-Wdeprecated-declarations
   |where non-should be?|where non-should be?

--- Comment #3 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/99318] [10/11 Regression] -Wdeprecated-declarations where non-should be?

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

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

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

https://gcc.gnu.org/g:831f9f768eb1fbf9a31d9a89591188b1487b6376

commit r11-7789-g831f9f768eb1fbf9a31d9a89591188b1487b6376
Author: Marek Polacek 
Date:   Tue Mar 9 19:23:48 2021 -0500

c++: Fix bogus warning in deprecated namespace [PR99318]

In GCC 10, I introduced cp_warn_deprecated_use_scopes so that we can
handle attribute deprecated on a namespace declaration.  This
function walks the decl's contexts so that we warn for code like

  namespace [[deprecated]] N { struct S { }; }
  N::S s;

We call cp_warn_deprecated_use_scopes when we encounter a TYPE_DECL.
But in the following testcase we have a TYPE_DECL whose context is
a deprecated function; that itself is not a reason to warn.  This
patch limits for which entities we call cp_warn_deprecated_use;
essentially it's what can follow ::.

I noticed that we didn't test that

  struct [[deprecated]] S { static void fn(); };
  S::fn();

produces the expected warning, so I've added gen-attrs-73.C.

gcc/cp/ChangeLog:

PR c++/99318
* decl2.c (cp_warn_deprecated_use_scopes): Only call
cp_warn_deprecated_use when decl is a namespace, class, or enum.

gcc/testsuite/ChangeLog:

PR c++/99318
* g++.dg/cpp0x/attributes-namespace6.C: New test.
* g++.dg/cpp0x/gen-attrs-73.C: New test.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #46 from jyong at gcc dot gnu.org ---
Is there a machine parsable output from objdump? I'm not sure if using gawk
would be OK. Such a test also won't work in build != host conditions.

I'm considering just having a notice in the gcc-11 release note to the
particular binutils commit/patch, so that anyone rolling their own toolchain
would be aware of it and try to apply the patch on binutils, since no released
version has the patch yet.

[Bug fortran/93660] Decl mismatch between fndecl TYPE and used arglist / ICE in ipa_simd_modify_function_body, at omp-simd-clone.c:993

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:212f4988f37ccf788c8c72b1dc952980bc9be3b7

commit r11-7788-g212f4988f37ccf788c8c72b1dc952980bc9be3b7
Author: Tobias Burnus 
Date:   Tue Mar 23 15:45:36 2021 +0100

Fortran: Fix func decl mismatch [PR93660]

gcc/fortran/ChangeLog:

PR fortran/93660
* trans-decl.c (build_function_decl): Add comment;
increment hidden_typelist for caf_token/caf_offset.
* trans-types.c (gfc_get_function_type): Add comment;
add missing caf_token/caf_offset args.

gcc/testsuite/ChangeLog:

PR fortran/93660
* gfortran.dg/gomp/declare-simd-coarray-lib.f90: New test.

[Bug middle-end/99714] warn about alloca/dealloc mismatches based on calls with same object in different functions

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

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|dmalcolm at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
  Component|analyzer|middle-end
   Keywords|documentation   |diagnostic

--- Comment #2 from Martin Sebor  ---
The C test case (corrected below) is meant to allocate and deallocate the the
member pointer, just like the C++ test case.

I also raise this as an enhancement for the -Wmismatched-dealloc and
Wmismatched-new-delete warnings (hence Changing component back to middle-end),
although I think it would be worthwhile improvement to the analyzer as well. 
I'm not sure what the best way is to track enhancements to both kinds of
warnings.  Clone one to the other?

struct A { int *p; };

void dealloc (void*);
__attribute__ ((malloc (dealloc))) void* alloc (int);

void init (struct A *p, int n) { p->p = alloc (n * sizeof *p); }
void fini (struct A *p)
{
  __builtin_free (p->p);  // missing -Wmismatched-dealloc
}

#endif

[Bug c++/99728] code pessimization when using wrapper classes around SIMD types

[martin--- via Gcc-bugs]

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

--- Comment #7 from Martin Reinecke  ---
Thanks!

(BTW, I'm aware your code and will immediately switch to it once it lands in
gcc! But for the time being I try to make do with my poor man's version to
avoid the external dependency.)

[Bug c++/99728] code pessimization when using wrapper classes around SIMD types

[kretz at kde dot org via Gcc-bugs]

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

--- Comment #6 from Matthias Kretz (Vir)  ---
> I guess I need it for unaligned loads/stores, correct? Otherwise __v4df 
> should work everywhere.

1. You can freely reinterpret_cast by value between all the different
[[gnu::vector_size(N)]] types (with equal N).

2. I use std::memcpy for loads and stores. Use __builtin_assume_aligned to get
aligned loads & stores.

[Bug c++/99728] code pessimization when using wrapper classes around SIMD types

[martin--- via Gcc-bugs]

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

--- Comment #5 from Martin Reinecke  ---
(In reply to Matthias Kretz (Vir) from comment #4)
> FWIW, using std::experimental::native_simd also does not hoist the
> stores out of the loop. However, if you pass d by value and return d, the
> issue goes away. So I guess this is an aliasing pessimization.

This is an interesting data point ... In my first test case (attached to
https://gcc.gnu.org/pipermail/gcc-help/2021-March/139976.html), I explicitly
make a local copy of d and copy back at the end of the function, and this
didn't help. Strange.

> Even though
> you added __restrict__. In any case __m256 has the problem that it is
> declared with the may_alias attribute. I recommend to just never use __m256
> unless you have no other choice.

I guess I need it for unaligned loads/stores, correct? Otherwise __v4df should
work everywhere.

[Bug target/99727] [11 Regression] MVE: ICE (segfault) in arm_print_operand at -O3 since r11-6616-g25bef689

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org
Summary|[11 Regression] MVE: ICE|[11 Regression] MVE: ICE
   |(segfault) in   |(segfault) in
   |arm_print_operand at -O3|arm_print_operand at -O3
   ||since r11-6616-g25bef689

--- Comment #1 from Alex Coplan  ---
Started with r11-6616-g25bef68902f42f414f99626cefb2d3df81de7dc8:

commit 25bef68902f42f414f99626cefb2d3df81de7dc8 (refs/bisect/bad)
Author: Christophe Lyon 
Date:   Tue Jan 12 16:47:27 2021

arm: Add movmisalign patterns for MVE (PR target/97875)

[Bug target/99582] No intrinsics to access rcl or rcr instruction on x86_64

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
(In reply to Alexander Monakov from comment #3)
> RCL and RCR are supported via microcode sequencer on Intel and involve many
> (9) uops on modern AMD, so they are quite slow in comparison to simple
> shifts/rotates. Would library developers still want to use them despite the
> poor performance? Equivalent code with "classic" shifts should be more
> efficient.
> 
> https://uops.info/html-instr/RCL_R64_CL.html

here they want is to get the carry flag from rcl/rcr

[Bug target/99582] No intrinsics to access rcl or rcr instruction on x86_64

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
RCL and RCR are supported via microcode sequencer on Intel and involve many (9)
uops on modern AMD, so they are quite slow in comparison to simple
shifts/rotates. Would library developers still want to use them despite the
poor performance? Equivalent code with "classic" shifts should be more
efficient.

https://uops.info/html-instr/RCL_R64_CL.html

[Bug c++/99728] code pessimization when using wrapper classes around SIMD types

[kretz at kde dot org via Gcc-bugs]

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

--- Comment #4 from Matthias Kretz (Vir)  ---
FWIW, using std::experimental::native_simd also does not hoist the
stores out of the loop. However, if you pass d by value and return d, the issue
goes away. So I guess this is an aliasing pessimization. Even though you added
__restrict__. In any case __m256 has the problem that it is declared with the
may_alias attribute. I recommend to just never use __m256 unless you have no
other choice. Note that `s0data_s<__m256d>` warns "ignoring attributes on
template argument '__m256d' [-Wignored-attributes]", meaning it drops the
may_alias attribute.

Reduced test case (https://godbolt.org/z/PW98Wsfoj):
#include 

struct Tvsimple {
  __m256d v;
};

struct s0data_s {
  Tvsimple lam1, lam2;
};
struct s0data_s_intrin {
  __m256d lam1, lam2;
};

template 
void foo(T &__restrict__ d, size_t l, size_t lmax) {
  while (l <= lmax) {
d.lam1 = d.lam2;
l += 2;
  }
}

// hoists load out of the loop but loops over the store
template void foo<>(s0data_s &__restrict__ d, size_t l, size_t lmax);

// turns loop into a single branch
template void foo<>(s0data_s_intrin &__restrict__ d, size_t l, size_t lmax);

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #45 from Jakub Jelinek  ---
I have tried the mingw gcc/binutils crosses we have in Fedora (gcc 10.2.1) and
get:
i686-w64-mingw32-objdump -h ./pr98860.exe 

./pr98860.exe: file format pei-i386

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .debug_loclists 002a      0448  2**0
  CONTENTS, READONLY, DEBUGGING
  1 .debug_rnglists 0013      0648  2**0
  CONTENTS, READONLY, DEBUGGING
  2 .text 17d4  00401000  00401000  0a00  2**4
  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  3 .data 0034  00403000  00403000  2200  2**2
  CONTENTS, ALLOC, LOAD, DATA
  4 .rdata08ec  00404000  00404000  2400  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .eh_frame 08d0  00405000  00405000  2e00  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .bss  0408  00406000  00406000    2**5
  ALLOC
  7 .idata0588  00407000  00407000  3800  2**2
  CONTENTS, ALLOC, LOAD, DATA
  8 .CRT  0034  00408000  00408000  3e00  2**2
  CONTENTS, ALLOC, LOAD, DATA
  9 .tls  0008  00409000  00409000  4000  2**2
  CONTENTS, ALLOC, LOAD, DATA
 10 .debug_aranges 0078  0040a000  0040a000  4200  2**3
  CONTENTS, READONLY, DEBUGGING
 11 .debug_info   3530  0040b000  0040b000  4400  2**0
  CONTENTS, READONLY, DEBUGGING
 12 .debug_abbrev 063e  0040f000  0040f000  7a00  2**0
  CONTENTS, READONLY, DEBUGGING
 13 .debug_line   0795  0041  0041  8200  2**0
  CONTENTS, READONLY, DEBUGGING
 14 .debug_frame  0038  00411000  00411000  8a00  2**2
  CONTENTS, READONLY, DEBUGGING
 15 .debug_str0360  00412000  00412000  8c00  2**0
  CONTENTS, READONLY, DEBUGGING
 16 .debug_loc039d  00413000  00413000  9000  2**0
  CONTENTS, READONLY, DEBUGGING
 17 .debug_ranges 00d8  00414000  00414000  9400  2**0
  CONTENTS, READONLY, DEBUGGING
so in that case it seems that .debug_{loclists,rnglists} etc. should use
non-zero VMA/LMA like other debug sections rather than zero like they currently
do.

[Bug target/99540] [10/11 Regression] ICE: Segmentation fault in aarch64_add_offset

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-7787-gd7cea7ceff9a2be7436108030c598628c51fba0f
Author: Richard Sandiford 
Date:   Tue Mar 23 14:02:03 2021 +

aarch64: Make aarch64_add_offset work with -ftrapv [PR99540]

aarch64_add_offset uses expand_mult to multiply the SVE VL by an
out-of-range constant.  expand_mult takes an argument to indicate
whether the multiplication is signed or unsigned, but in this
context the multiplication is effectively signless and so the
choice seemed arbitrary.

However, one of the things that the signedness input does is
indicate whether signed overflow should be trapped for -ftrapv.
We don't want that here, so we must treat the multiplication
as unsigned.

gcc/
2021-03-23  Jakub Jelinek  

PR target/99540
* config/aarch64/aarch64.c (aarch64_add_offset): Tell
expand_mult to perform an unsigned rather than a signed
multiplication.

gcc/testsuite/
2021-03-23  Richard Sandiford  

PR target/99540
* gcc.dg/vect/pr99540.c: New test.

[Bug analyzer/99714] warn about alloca/dealloc mismatches based on calls with same object in different functions

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

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

--- Comment #1 from David Malcolm  ---
The C case in comment #0 doesn't look like what I think you meant to write, and
the analyzer (correctly IMHO) complains about a leak:

: In function 'init':
:22:61: warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]
   22 | void init (struct A *p, int n) { p = alloc (n * sizeof *p); }
  | ^
  'init': events 1-2
|
|   22 | void init (struct A *p, int n) { p = alloc (n * sizeof *p); }
|  |  ^  ~
|  |  |  |
|  |  |  (2)
'p' leaks here; was allocated at (1)
|  |  (1) allocated here
|
Compiler returned: 0


If I fix it up thus:

struct A { int *p; };

void dealloc (void*);
__attribute__ ((malloc (dealloc))) void* alloc (int);

void init (struct A *a, int n) { a->p = alloc (n * sizeof *a->p); }
void fini (struct A *a)
{
  __builtin_free (a->p);  // missing -Wmismatched-dealloc
}

void test (void)
{
struct A a;
init (, 5);
fini ();
}
/* to provide an example of usage, otherwise the analyzer doesn't "know" about
the connection between init and fini */

then -fanalyzer warns about it:

: In function 'fini':
:27:3: warning: 'a.p' should have been deallocated with 'dealloc' but
was deallocated with 'free' [CWE-762] [-Wanalyzer-mismatching-deallocation]
   27 |   __builtin_free (a->p);  // missing -Wmismatched-dealloc
  |   ^
  'test': events 1-2
|
|   30 | void test (void)
|  |  ^~~~
|  |  |
|  |  (1) entry to 'test'
|..
|   33 | init (, 5);
|  | 
|  | |
|  | (2) calling 'init' from 'test'
|
+--> 'init': events 3-4
   |
   |   24 | void init (struct A *a, int n) { a->p = alloc (n * sizeof
*a->p); }
   |  |  ^~~~  

   |  |  |  |
   |  |  |  (4) allocated here
(expects deallocation with 'dealloc')
   |  |  (3) entry to 'init'
   |
<--+
|
  'test': events 5-6
|
|   33 | init (, 5);
|  | ^~~~
|  | |
|  | (5) returning to 'test' from 'init'
|   34 | fini ();
|  | ~
|  | |
|  | (6) calling 'fini' from 'test'
|
+--> 'fini': events 7-8
   |
   |   25 | void fini (struct A *a)
   |  |  ^~~~
   |  |  |
   |  |  (7) entry to 'fini'
   |   26 | {
   |   27 |   __builtin_free (a->p);  // missing -Wmismatched-dealloc
   |  |   ~
   |  |   |
   |  |   (8) deallocated with 'free' here; allocation at (4)
expects deallocation with 'dealloc'
   |
Compiler returned: 0