[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

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

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

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

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

commit r11-7968-gb680b9049737198d010e49cf434704c6a6ed2b3f
Author: Jakub Jelinek 
Date:   Sat Apr 3 10:03:15 2021 +0200

rs6000: Avoid -fpatchable-function-entry* regressions on powerpc64 be
[PR98125]

The SECTION_LINK_ORDER changes broke powerpc64-linux ELFv1.  Seems
that the assembler/linker relies on the symbol mentioned for the
"awo" section to be in the same section as the symbols mentioned in
the relocations in that section (i.e. labels for the patchable area
in this case).  That is the case for most targets, including powerpc-linux
32-bit or powerpc64 ELFv2 (that one has -fpatchable-function-entry*
support broken for other reasons and it doesn't seem to be a regression).
But it doesn't work on powerpc64-linux ELFv1.
We emit:
.section".opd","aw"
.align 3
_Z3foov:
.quad   .L._Z3foov,.TOC.@tocbase,0
.previous
.type   _Z3foov, @function
.L._Z3foov:
.section   
__patchable_function_entries,"awo",@progbits,_Z3foov
.align 3
.8byte  .LPFE1
.section.text._Z3foov,"axG",@progbits,_Z3foov,comdat
.LPFE1:
nop
.LFB0:
.cfi_startproc
and because _Z3foov is in the .opd section rather than the function text
section, it doesn't work.

I'm afraid I don't know what exactly should be done, whether e.g.
it could use
.section   
__patchable_function_entries,"awo",@progbits,.L._Z3foov
instead, or whether the linker should be changed to handle it as is, or
something else.

But because we have a P1 regression that didn't see useful progress over
the
4 months since it has been filed and we don't really have much time, below
is an attempt to do a targetted reversion of H.J's patch, basically act as
if HAVE_GAS_SECTION_LINK_ORDER is never true for powerpc64-linux ELFv1,
but for 32-bit or 64-bit ELFv2 keep working as is.
This would give us time to resolve it for GCC 12 properly.

2021-04-03  Jakub Jelinek  

PR testsuite/98125
* targhooks.h (default_print_patchable_function_entry_1): Declare.
* targhooks.c (default_print_patchable_function_entry_1): New
function,
copied from default_print_patchable_function_entry with an added
flags
argument.
(default_print_patchable_function_entry): Rewritten into a small
wrapper around default_print_patchable_function_entry_1.
* config/rs6000/rs6000.c
(TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY):
Redefine.
(rs6000_print_patchable_function_entry): New function.

* g++.dg/pr93195a.C: Skip on powerpc*-*-* 64-bit.

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

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

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

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

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

commit r11-7969-gcda41ce0e8414aec59e6b9fbe645d96e6e8193e2
Author: Jakub Jelinek 
Date:   Sat Apr 3 10:05:32 2021 +0200

rs6000: Fix up libgcc ABI when built with --with-long-double-format=ieee
[PR97653]

__floatunditf and __fixtfdi and a couple of other libgcc{.a,_s.so}
entrypoints for backwards compatibility should mean IBM double double
handling (i.e. IFmode), gcc emits such calls for that format and
form IEEE long double emits *kf* instead.
When gcc is configured without --with-long-double-format=ieee ,
everything is fine, but when it is not, we need to compile those
libgcc sources with -mno-gnu-attribute -mabi=ibmlongdouble.
The following snippet in libgcc/config/rs6000/t-linux was attempting
to ensure that, and for some routines it works fine (e.g. for _powitf2).
But, due to 4 different types of bugs it doesn't work for most of those
functions, which means that in --with-long-double-format=ieee
configured gcc those *tf* entrypoints instead handle the long double
arguments as if they were KFmode.

The bugs are:
1) the first few objs properly use $(objext) as suffix, but
   several other contain a typo and use $(object) instead,
   which is a variable that isn't set to anything, so we don't
   add .o etc. extensions
2) while unsigned fix are properly called _fixuns*, unsigned float
   are called _floatun* (without s), but the var was using there
   the extra s and so didn't match
3) the variable didn't cover any of the TF <-> TI conversions,
   only TF <-> DI conversions
4) nothing in libgcc_s.so was handled, as those object files are
   called *_s.o rather than *.o and IBM128_SHARED_OBJS used wrong
   syntax of the GNU make substitution reference, which should be
   $(var:a=b) standing for $(patsubst a,b,$(var)) but it used
   $(var:a:b) instead

2021-04-03  Jakub Jelinek  

PR target/97653
* config/rs6000/t-linux (IBM128_STATIC_OBJS): Fix spelling, use
$(objext) instead of $(object).  Use _floatunditf instead of
_floatunsditf.  Add tf <-> ti conversion objects.
(IBM128_SHARED_OBJS): Use proper substitution reference syntax.

[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba

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

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

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

https://gcc.gnu.org/g:9c7473688e78dc41fd4312a983453df195dd7786

commit r11-7970-g9c7473688e78dc41fd4312a983453df195dd7786
Author: Jakub Jelinek 
Date:   Sat Apr 3 10:07:09 2021 +0200

dse: Fix up hard reg conflict checking in replace_read [PR99863]

Since PR37922 fix RTL DSE has hard register conflict checking
in replace_read, so that if the replacement sequence sets (or typically
just
clobbers) some hard register (usually condition codes) we verify that
hard register is not live.
Unfortunately, it compares the hard reg set clobbered/set by the sequence
(regs_set) against the currently live hard register set, but it then
emits the insn sequence not at the current insn position, but before
store_insn->insn.
So, we should not compare against the current live hard register set,
but against the hard register live set at the point of the store insn.
Fortunately, we already have that remembered in
store_insn->fixed_regs_live.

In addition to bootstrapping/regtesting this patch on x86_64-linux and
i686-linux, I've also added statistics gathering and it seems the only
place where we end up rejecting the replace_read is the newly added
testcase (the PR37922 is no longer effective at that) and fixed_regs_live
has been always non-NULL at the if (store_insn->fixed_regs_live) spot.
Rather than having there an assert, I chose to just keep regs_set
as is, which means in that hypothetical case where fixed_regs_live wouldn't
be computed for some store we'd still accept sequences that don't
clobber/set any hard registers and just punt on those that clobber/set
those.

2021-04-03  Jakub Jelinek  

PR rtl-optimization/99863
* dse.c (replace_read): Drop regs_live argument.  Instead of
regs_live, use store_insn->fixed_regs_live if non-NULL,
otherwise punt if insns sequence clobbers or sets any hard
registers.

* gcc.target/i386/pr99863.c: New test.

[Bug tree-optimization/99882] [11 Regression] ICE in bswap_view_convert, at gimple-ssa-store-merging.c:988 since r11-7946-g5b9a65ecbeb22ef6

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

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

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

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

commit r11-7971-ga40015780f8cc49476741b6914bd5ee97bd10f1d
Author: Jakub Jelinek 
Date:   Sat Apr 3 10:08:08 2021 +0200

bswap: Fix up bswap_view_convert after the recent change [PR99882]

Martin reported that my recent change to allow pointer types in bswap
broke valgrind.  The bswap_view_convert function used for the
initialization
of vector CONSTRUCTOR from the identity or byte-swapped pieces
unfortunately
didn't handle pointer types.  The following patch handles it there.

2021-04-03  Jakub Jelinek  

PR tree-optimization/99882
* gimple-ssa-store-merging.c (bswap_view_convert): Handle val with
pointer type.

* gcc.dg/pr99882.c: New test.

[Bug target/99888] New: Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

Bug ID: 99888
   Summary: Add powerpc ELFv2 support for
-fpatchable-function-entry*
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: amodra at gmail dot com, hjl.tools at gmail dot com,
jakub at gcc dot gnu.org, marxin at gcc dot gnu.org,
seurer at gcc dot gnu.org, unassigned at gcc dot gnu.org
Depends on: 98125
  Target Milestone: ---
  Host: powerpc64*-linux-gnu
Target: powerpc64*-linux-gnu
 Build: powerpc64*-linux-gnu

+++ This bug was initially created as a clone of Bug #98125 +++

As mentioned in PR98125, for ELFv2 the patchable nops need to be added after
the first two insns of the function rather than before it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
[Bug 98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has
excess errors

[Bug target/99889] New: Add powerpc ELFv1 support for -fpatchable-function-entry* with "o" sections

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

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

Bug ID: 99889
   Summary: Add powerpc ELFv1 support for
-fpatchable-function-entry* with "o" sections
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: amodra at gmail dot com, hjl.tools at gmail dot com,
jakub at gcc dot gnu.org, marxin at gcc dot gnu.org,
seurer at gcc dot gnu.org, unassigned at gcc dot gnu.org
Depends on: 98125, 99888
  Target Milestone: ---
  Host: powerpc64*-linux-gnu
Target: powerpc64*-linux-gnu
 Build: powerpc64*-linux-gnu

+++ This bug was initially created as a clone of Bug #99888 +++

+++ This bug was initially created as a clone of Bug #98125 +++

As mentioned in PR98125, for 64-bit ELFv1 GCC 11 has a workaround where
compiler pretends linker doesn't support "o" section flag.
It would be good to find out how it can be supported in presence of .opd
section symbols, and either fix it on the assembler/linker side, or on the
compiler side or both.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
[Bug 98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has
excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
[Bug 99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #20 from Jakub Jelinek  ---
Regression is now fixed.  Clones filed for GCC 12.

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

Bug 98125 Summary: [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 
has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125

   What|Removed |Added

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

[Bug target/99889] Add powerpc ELFv1 support for -fpatchable-function-entry* with "o" sections

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

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

Bug 98125 Summary: [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 
has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125

   What|Removed |Added

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

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #18 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug rtl-optimization/99863] [10 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] wrong|[10 Regression] wrong code
   |code with -O|with -O -fno-tree-forwprop
   |-fno-tree-forwprop  |-mno-sse2 since
   |-mno-sse2 since |r10-7268-g529ea7d9596b26ba
   |r10-7268-g529ea7d9596b26ba  |

--- Comment #19 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/99882] [11 Regression] ICE in bswap_view_convert, at gimple-ssa-store-merging.c:988 since r11-7946-g5b9a65ecbeb22ef6

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/99890] New: The -mstrict-aglign doesn't support the ARM targets

[zmin1 at avic dot com via Gcc-bugs]

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

Bug ID: 99890
   Summary: The -mstrict-aglign doesn't support the ARM targets
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmin1 at avic dot com
  Target Milestone: ---

When I use the PowerPC targets, the -mstrict-align options is very useful, it
can force the structs and datas to align with 4bytes rules。
But why the ARM targets doesn't support this options？

[Bug target/99890] The -mstrict-aglign doesn't support the ARM targets

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
Because it is a target specific option.
What exactly are you trying to do?

most instructions in ARMv7+ support unaligned data.

[Bug c/99891] New: Can GCC 4.8.1 Support TI c6x taregts?

[zmin1 at avic dot com via Gcc-bugs]

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

Bug ID: 99891
   Summary: Can GCC 4.8.1 Support TI c6x taregts?
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmin1 at avic dot com
  Target Milestone: ---

GCC 4.8.1 lists the support for Ti C6x series processors, but there are the
following problems:

1. The processor types listed do not include the most commonly used ti c6678
processor.

2. There is a great difference between the binary code compiled by Ti compiler
and the object code compiled by Ti compiler.

3. Is GCC deficient in supporting Ti chip?

[Bug libgomp/99892] New: Does GCC 4.8.1 really support OpenMP?

[zmin1 at avic dot com via Gcc-bugs]

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

Bug ID: 99892
   Summary: Does GCC 4.8.1 really support OpenMP?
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmin1 at avic dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

In GCC's version specification, version 4.8.1 supports OpenMP 3.1.
The method used is the - fopenmp option, which implies the - pthread option.
However, in version 4.8.1, only a few processors such as PowerPC support -
pthread option, and the more commonly used arm and x86 processors do not
support this option.
Does this mean that version 4.8.1 does not support OpenMP for arm and x86
processors?

[Bug c++/99893] New: C++20 unexpanded parameter packs falsely not detected (lambda is involved)

[bisqwit at iki dot fi via Gcc-bugs]

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

Bug ID: 99893
   Summary: C++20 unexpanded parameter packs falsely not detected
(lambda is involved)
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

GCC produces false error message:

bug1.cc: In function ‘consteval void VerifyHash()’:
bug1.cc:20:70: error: operand of fold expression has no unexpanded parameter
packs
   20 |   [](){static_assert(hash(s.data(), s.size()) == expected_hash);}()
  |   ~~~^~

On this code:

#include  // copy_n and size_t
static constexpr unsigned hash(const char* s, std::size_t length)
{
s=s;
return length;
}
template
struct fixed_string
{
constexpr fixed_string(const char (&s)[N]) { std::copy_n(s, N, str); }
consteval const char* data() const { return str; }
consteval std::size_t size() const { return N-1; }
char str[N];
};
template
static consteval void VerifyHash()
{
(
  [](){static_assert(hash(s.data(), s.size()) == expected_hash);}()
,...);
// ^ Falsely reports that there are no unexpanded parameter packs,
//   while there definitely is ("s" is used).
}
void foo()
{
VerifyHash<5, "khaki", "plums">();
}


Compiler version:
g++-10 (Debian 10.2.1-6) 10.2.1 20210110

[Bug c/99894] New: Does GCC 4.8.1 support OpenCL?

[zmin1 at avic dot com via Gcc-bugs]

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

Bug ID: 99894
   Summary: Does GCC 4.8.1 support OpenCL?
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmin1 at avic dot com
  Target Milestone: ---

Does GCC 4.8.1 support OpenCL?
If yes, what parameters are needed to configure GCC?
What parameters are needed when using gcc?

[Bug c/99894] Does GCC 4.8.1 support OpenCL?

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
NO.

[Bug libgomp/99892] Does GCC 4.8.1 really support OpenMP?

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
4.8.x is now over 6 years old.
OpenMP has been tested on arm, PowerPC and x86 (and aarch64 and others).

[Bug c++/99895] New: Function parameters generated wrong in call to member of non-type template parameter in lambda

[bisqwit at iki dot fi via Gcc-bugs]

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

Bug ID: 99895
   Summary: Function parameters generated wrong in call to member
of non-type template parameter in lambda
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

GCC produces false error message:

bug1.cc: In instantiation of ‘consteval void VerifyHash() [with unsigned int
expected_hash = 5; fixed_string<...auto...> ...s = {fixed_string<6>{"khaki"},
fixed_string<6>{"plums"}}]’:
bug1.cc:24:37:   required from here
bug1.cc:19:41: error: no matching function for call to
‘fixed_string<6>::data(const fixed_string<6>*)’
   19 |   [](auto){static_assert(hash(s.data(), s.size()) ==
expected_hash);}(s)
  |   ~~^~
bug1.cc:11:27: note: candidate: ‘consteval const char* fixed_string::data()
const [with long unsigned int N = 6]’
   11 | consteval const char* data() const { return str; }
  |   ^~~~
bug1.cc:11:27: note:   candidate expects 0 arguments, 1 provided

On this code:

#include  // copy_n and size_t
static constexpr unsigned hash(const char* s, std::size_t length)
{
s=s;
return length;
}
template
struct fixed_string
{
constexpr fixed_string(const char (&s)[N]) { std::copy_n(s, N, str); }
consteval const char* data() const { return str; }
consteval std::size_t size() const { return N-1; }
char str[N];
};
template
static consteval void VerifyHash()
{
(
  [](auto){static_assert(hash(s.data(), s.size()) == expected_hash);}(s)
,...);
// The compiler mistakenly translates s.data() into s.data(&s)
// and then complains that the call is not valid, because
// the function expects 0 parameters and 1 "was provided".
}
void foo()
{
VerifyHash<5, "khaki", "plums">();
}


Compiler version:
g++-10 (Debian 10.2.1-6) 10.2.1 20210110

[Bug target/99891] Can GCC 4.8.1 Support TI c6x taregts?

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andreas Schwab  ---
GCC 4.8 is out of support.

[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186

[gscfq--- via Gcc-bugs]

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

--- Comment #4 from G. Steinmetz  ---

> Have you ever tried to put a tent up in a storm?
... geez, how difficult and lengthy ...

The number of bug reports is admittedly increasing,
but the number of still unknown bugs is decreasing, isn't it?

And my impression is indeed that the number of
unfixed/unknown bugs in gfortran is now roughly limited
to huge(1_alpha), with alpha=~1.5 ;-)

The bug reproduction rate is likely less than one :-)

[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Can this be closed as invalid? The program can't compile because it tries to
use something that doesn't exist, which is not a GCC bug.

(In reply to Jeffrey Walton from comment #7)
> I thought I was allowed to use documented functions; and I was not supposed
> to use undocumented ones. Yeah, this seems to be turned on its head :)

Many built-in functions are documented so that authors of other compilers and
other tools (like static analysis checkers) can implement the same thing in a
compatible way. That doesn't mean users are supposed to use them directly.

[Bug c++/96645] [9/10/11 Regression] std::variant default constructor

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jason Merrill from comment #8)
> Any opinions on what our behavior should be?  Should there be an LWG issue?

Yes, we want an LWG issue. That might then result in a new core issue too, if
we can't reasonably do the right thing.

[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-7972-gfc27115d6107f219e6f3dc610c99210005fe9dc5
Author: Paul Thomas 
Date:   Sat Apr 3 12:49:50 2021 +0100

Fortran: Fix ICE on wrong code [PR99818].

2021-04-03  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/99818
* interface.c (compare_parameter): The codimension attribute is
applied to the _data field of class formal arguments.

gcc/testsuite/ChangeLog

PR fortran/99818
* gfortran.dg/coarray_48.f90: New test.

[Bug driver/99896] New: g++ drops -lc

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

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

Bug ID: 99896
   Summary: g++ drops -lc
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Spinoff from gdb PR https://sourceware.org/bugzilla/show_bug.cgi?id=27681 . ]

Consider the following test-case, consisting of:
...
$ cat main.c 
#include 
#include 

#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif
#include 

extern void foo (void);

int
main (void)
{
  regex_t re;

  int res = regcomp (&re, "bla", 0);
  assert (res == 0);

  int res2 = regexec (&re, "bla", 0, NULL, 0);
  assert (res2 == 0);

  regoff_t res3 = re_search (&re, "bla", 3, 0, 3, NULL);
  assert (res3 == 0);

  foo ();

  return 0;
} 
...
and:
...
$ cat foo.c 
#include 
#include 

#include 

extern void foo (void);

void
foo (void)
{
  regex_t re;

  int res = pcre2_regcomp (&re, "bla", 0);
  assert (res == 0);

  int res2 = pcre2_regexec (&re, "bla", 0, NULL, 0);
  assert (res2 == 0);
}
...

We can compile with gcc and run like this:
...
$ gcc main.c -lc foo.c -lpcre2-posix
$ ./a.out 
$
...

likewise, with clang:
...
$ clang main.c -lc foo.c -lpcre2-posix
$ ./a.out 
$ 
...

likewise, with clang++:
...
$ clang++ -x c++ main.c -lc foo.c -lpcre2-posix
$ ./a.out 
$
...

but with g++:
...
$ g++ -x c++ main.c -lc foo.c -lpcre2-posix
$ ./a.out 
Segmentation fault (core dumped)
$
...

Using -v, we can see what goes wrong.  With gcc, we have:
...
collect2 ... main.o -lc foo.o -lpcre2-posix ...
...

With g++, we have instead:
...
collect2 ... main.o foo.o -lpcre2-posix ...
...

Workaround: use -Wl:
...
$ g++ -x c++ main.c -Wl,-lc foo.c -lpcre2-posix
$ ./a.out 
$
...

[Bug translation/90183] ambiguous diagnostics "only available with"

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

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

--- Comment #3 from Roland Illig  ---
In the German translation of GCC I consistently use "available since".

[Bug target/99891] Can GCC 4.8.1 Support TI c6x taregts?

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

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

--- Comment #2 from Jonathan Wakely  ---
This seems like something you should ask on the mailing list, it's not a bug.

[Bug target/99891] Can GCC 4.8.1 Support TI c6x taregts?

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

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

--- Comment #3 from Jonathan Wakely  ---
And if you're comparing a recent Ti compiler with GCC 4.8.1, I hope you realise
that GCC 4.8.1 is eight years old.

[Bug c/99894] Does GCC 4.8.1 support OpenCL?

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

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

--- Comment #2 from Jonathan Wakely  ---
This is not a bug report. lease use the gcc-help mailing list for basic
question about GCC, don't report bugs to ask questions.

[Bug driver/99896] g++ drops -lc

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Tom de Vries from comment #0)
> With g++, we have instead:
> ...
> collect2 ... main.o foo.o -lpcre2-posix ...
> ...

It isn't dropped, it's moved to the end:

main.o foo.o -lpcre2-posix -lstdc++ -lm -lc -lgcc_s -lgcc -lc -lgcc_s -lgcc

If you need it before foo.o then -Wl,-lc seems like the right workaround for
me.

Why is it needed there anyway though?

[Bug translation/90183] ambiguous diagnostics "only available with"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libgomp/99892] Does GCC 4.8.1 really support OpenMP?

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to ZhangMin from comment #0)
> However, in version 4.8.1, only a few processors such as PowerPC support -
> pthread option, and the more commonly used arm and x86 processors do not
> support this option.

That's not true. GCC 4.8.1 for x86 does support that option. I haven't checked,
but I think GCC 4.8.1 for arm does too. The option isn't listed in the manual
for all targets, but it is supported. The manual was wrong, which was fixed as
PR 16519.

Anyway, stop using bug reports to ask questions.

[Bug c++/91217] [8/9/10 Regression] Returning std::array from lambda results in an extra copy step on return

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |Returning std::array from   |Returning std::array from
   |lambda results in an extra  |lambda results in an extra
   |copy step on return |copy step on return

--- Comment #6 from Jason Merrill  ---
Fixed for GCC 11 so far.

[Bug c++/99897] New: ICE Segmentation fault when operator appear in template parameter-list

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99897
   Summary: ICE Segmentation fault when operator appear in
template parameter-list
   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/fjx8cG995

template  struct A {};
template  struct S { void foo(S<+a>); };


:2:40: internal compiler error: Segmentation fault
2 | template  struct S { void foo(S<+a>); };
  |^
0x1cfd119 internal_error(char const*, ...)
???:0
0x6c4475 resolve_args(vec*, int)
???:0
0x9093b1 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x929803 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x97ff1d finish_template_type(tree_node*, tree_node*, int)
???:0
0x8e140d c_parse_file()
???:0
0xa606f2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #15 from Martin Uecker  ---
I do not think the C standard can be read in a way where reading a variable can
yield a different value each time (except if the access is UB). For unspecified
values it talks about "the value chosen in each instance" not about "the value
chosen for each read of a variable". The C standard also takes care to specify
the exact time points when a variable takes on an unspecified value (and where
a value is chosen in the abstract machine). 

There was a lot of talk about introducing "wobbly values" but this never led to
any changes in the standard. I also do not think this would be a good idea. It
is impossible to reason about "wobbly values" and harmless transformations can
turn inconsistent assumptions about the value into nonsense.

[Bug lto/99898] New: Possible LTO object incompatibility on gcc-10 branch

[ohaiziejohwahkeezuoz at xff dot cz via Gcc-bugs]

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

Bug ID: 99898
   Summary: Possible LTO object incompatibility on gcc-10 branch
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ohaiziejohwahkeezuoz at xff dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I'm trying gcc (releases/gcc-10 branch with the last commit  Fri Oct 23
10:11:41 2020 +0200 - Fix up plugin header install)

And I'm seeing an ICE cross-compiling glib library when linking with 

i686-linux-musl-gcc  -o gio/gresource gio/gresource.p/gresource-tool.c.o
-L/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib
-Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -static -Wl,--start-group
gio/libgio-2.0.a glib/libglib-2.0.a gobject/libgobject-2.0.a
gmodule/libgmodule-2.0.a
/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib/libz.a
/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib/libmount.a
/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib/libblkid.a
-pthread -liconv -lm
/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib/libffi.a
-Wl,--end-group
lto1: internal compiler error: in lto_read_decls, at lto/lto-common.c:1956
Please submit a full bug report,
with preprocessed source if appropriate.

I'm compiling with fat LTO objects, and this only happens when mixing LTO
object files compiled with previous version of gcc on the tip of gcc-10 branch.
(and only with i686 target so far) Sorry I don't have precise version of the
previous compiler, but it was probably something close to 10.2 judging by the
dates on the object files.

Recompiling all dependencies with the same version of the compiler doesn't lead
to this ICE.

Maybe LTO version needs a bump prior to 10.3 release?

[Bug c++/99643] [8/9/10/11 Regression] internal compiler error in build_over_call, involving array new and copy elision

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug driver/99896] g++ drops -lc

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

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

--- Comment #2 from Tom de Vries  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Tom de Vries from comment #0)
> > With g++, we have instead:
> > ...
> > collect2 ... main.o foo.o -lpcre2-posix ...
> > ...
> 
> It isn't dropped, it's moved to the end:
> 
> main.o foo.o -lpcre2-posix -lstdc++ -lm -lc -lgcc_s -lgcc -lc -lgcc_s -lgcc
> 

I don't understand. AFAICT, it's dropped.  It's not moved to the end, because
-lc is already at the end without specifying -lc. 

> If you need it before foo.o then -Wl,-lc seems like the right workaround for
> me.
> 

Um, for my understanding, does that mean you agree this is a bug in g++?

> Why is it needed there anyway though?

main.o is intended to use regcomp from glibc.  Foo.o is intended to use
pcre2_regcomp from pcre2-posix (which is also accessible using plain regcomp). 
When -lc is droppend, regcomp from pcre2-posix is used by main instead, which
is incompatible with using re_search from glibc.

[Bug libfortran/98301] random_init() is broken

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #49770|0   |1
is obsolete||
  Attachment #49791|0   |1
is obsolete||
  Attachment #49816|0   |1
is obsolete||

--- Comment #8 from kargl at gcc dot gnu.org ---
Created attachment 50502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50502&action=edit
Patch to supersedes all previous patches.

This patch supersedes all previous patches.  It now contains a sham
implementation for -fcoarray=lib and -fcoarray=shared.

[Bug c++/99874] [11 Regression] ICE Segmentation fault when declared variable template of template lambda

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
(In reply to Marek Polacek from comment #1)
> Confirmed.  G++10:
> 
> 99874.C:2:45: error: expected ‘(’ before ‘{’ token
> 2 | auto l = [] requires requires { x; } {};
>   | ^
>   | (
> 
> ICE started with r11-3261.  I suppose it's a P1 then?

Probably -- if we add an empty parameter list to the lambda then G++10 accepts.
 Looking into it.

[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #16 from Vincent Lefèvre  ---
(In reply to Martin Uecker from comment #15)
> I do not think the C standard can be read in a way where reading a variable
> can yield a different value each time (except if the access is UB). For
> unspecified values it talks about "the value chosen in each instance" not
> about "the value chosen for each read of a variable".

But any instance of what? There is no context in the definition (possibly
except the operation that yields the value).

[Bug lto/99898] Possible LTO object incompatibility on gcc-10 branch

[ohaiziejohwahkeezuoz at xff dot cz via Gcc-bugs]

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

--- Comment #1 from ohaiziejohwahkeezuoz at xff dot cz ---
I figured object files contain the version of the compiler, so the previous
version was GCC: (GNU) 10.2.1 20201110 (built from releases/gcc-10 at that
date)

[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #17 from Martin Uecker  ---
(In reply to Vincent Lefèvre from comment #16)
> (In reply to Martin Uecker from comment #15)
> > I do not think the C standard can be read in a way where reading a variable
> > can yield a different value each time (except if the access is UB). For
> > unspecified values it talks about "the value chosen in each instance" not
> > about "the value chosen for each read of a variable".
> 
> But any instance of what?

Instance of the unspecified value. 

Every time the standard says "a padding byte takes an unspecified value" 
or "the function returns an unspecified value" or something "stores an
unspecified value" a specific value is chosen. 

If it wanted to say that a read of an uninitialized variable yields an new
value each time it read, there would be a sentence in the paragraph about
lvalue conversion such as "an lvalue of an uninitialized object is converted to
an unspecified value". Then "each instance" would be new unspecified value
produced during each lvalue conversion. But it does not says this.

> There is no context in the definition (possibly
> except the operation that yields the value).

The operation that yields the value is the when the object is initialized (or
would be initialized if it had an initializer). This is in 6.2.4p6 where it
says "...; otherwise, the value becomes indeterminate each time the declaration
is reached."  An indeterminate value is either a trap representation or an
unspecified value. If the type does not have trap representations, then this is
the same as "...; otherwise, the value becomes and unspecified value each time
the declaration is reached". So the point in time where the value has to be
chosen is defined by the C standard.

[Bug c++/99899] New: ICE: in do_auto_deduction, at cp/pt.c:29630

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99899
   Summary: ICE: in do_auto_deduction, at cp/pt.c:29630
   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: ---

This is a small variant of fixed PR 99815, PR 99869.

https://godbolt.org/z/zrnPqdenx

template  concept C = true;

struct S { int a, b; };

template 
auto bar(Ts...) { C auto [a, b] = S{}; }


: In function 'auto bar(Ts ...)':
:6:44: internal compiler error: in do_auto_deduction, at cp/pt.c:29630
6 | auto bar(Ts...) { C auto [a, b] = S{}; }
  |^
0x1cfd119 internal_error(char const*, ...)
???:0
0x6baa1b fancy_abort(char const*, int, char const*)
???:0
0x90a8c4 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x7b1e34 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x8e140d c_parse_file()
???:0
0xa606f2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug driver/99896] g++ drops -lc

[schwab--- via Gcc-bugs]

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

--- Comment #3 from Andreas Schwab  ---
regcomp and re_search are always incompatible.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[levraiphilippeblain at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Philippe Blain  ---
Patch posted: 
- https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567650.html
(gcc-patches) 
- https://gcc.gnu.org/pipermail/libstdc++/2021-April/052291.html (libstdc++)

[Bug c/99900] New: feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS

[adrelanos at whonix dot org via Gcc-bugs]

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

Bug ID: 99900
   Summary: feature request: 16-bit x86 C compiler / support
compilation of (VirtualBox) BIOS
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrelanos at whonix dot org
  Target Milestone: ---

"Oracle VM VirtualBox, the world's most popular open source, cross-platform,
virtualization software"

According to the VirtualBox developers it is not possible to build the
VirtualBox BIOS with gcc or any other Free Software compiler.

Quote VirtualBox developer https://www.virtualbox.org/ticket/12011

"We would be glad to fix this, but we lack the resources to do so as our BIOS
code has simply outgrown what bcc (which we were using before and which was
always very limiting) can do. We have failed to find another free 16-bit x86 C
compiler up to the job,"

"generating 16-bit code is one thing, but supporting e.g. far/near pointers"

It is currently compiled using the Open Watcom compiler which is under the
Sybase Open Watcom Public License license. That license is not FSF approved.

https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License

Even stated it being a nonfree license.

https://www.gnu.org/licenses/license-list.html#Watcom

The VirtualBox BIOS source code can be found here:

* https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS
* https://github.com/mirror/vbox/tree/master/src/VBox/Devices/PC/BIOS

feature request: Could you please develop a 16-bit x86 C compiler that supports
compilation of VirtualBox BIOS / any BIOS?

[Bug target/99900] feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
> Could you please develop a 16-bit x86 C compiler that supports compilation of
> VirtualBox BIOS / any BIOS?

A bug bounty might be useful here since I highly doubt this will be done
otherwise.

[Bug driver/99896] g++ drops -lc

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Tom de Vries from comment #2)
> I don't understand. AFAICT, it's dropped.  It's not moved to the end,
> because -lc is already at the end without specifying -lc. 

OK, it's dropped because it's always present at the end.

This is similar to adding -I/usr/include which gets ignored, because it's
already going to be searched anyway as a system header directory. Quoting the
manual:

"If a standard system include directory, or a directory specified with
-isystem, is also specified with -I, the -I option is ignored."


> Um, for my understanding, does that mean you agree this is a bug in g++?

No.

> > Why is it needed there anyway though?
> 
> main.o is intended to use regcomp from glibc.  Foo.o is intended to use
> pcre2_regcomp from pcre2-posix (which is also accessible using plain
> regcomp).  When -lc is droppend, regcomp from pcre2-posix is used by main
> instead, which is incompatible with using re_search from glibc.

Ohhh, this issue. It's clearly a bug in pcre2. Providing symbols with the same
names as the ones in libc, but with different ABI, is madness.

[Bug c++/91416] ICE in cp_check_const_attributes, at cp/decl2.c:1408

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

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

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

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

commit r11-7975-ga809d8a737da1ccebcd93065fc57fc0f4d94894a
Author: Marek Polacek 
Date:   Fri Apr 2 17:11:32 2021 -0400

c++: GC during late parsing collects live data [PR91416]

Coming back to
:

This is a crash that points to a GC problem.  Consider this test:

  __attribute__ ((unused)) struct S {
S() { }
  } s;

We're parsing a simple-declaration.  While parsing the decl specs, we parse
the attribute, which means creating a TREE_LIST using ggc_alloc_*.

A function body is a complete-class context so when parsing the
member-specification of this class-specifier, we parse the bodies of the
functions we'd queued in cp_parser_late_parsing_for_member.  This then
leads to this call chain:
cp_parser_function_definition_after_declarator -> expand_or_defer_fn ->
expand_or_defer_fn_1 -> maybe_clone_body -> expand_or_defer_fn ->
cgraph_node::finalize_function -> ggc_collect.

In this test, the ggc_collect call collects the TREE_LIST we had
allocated, and a crash duly ensues.

I couldn't do what Richard suggested, that is, attach the attribute list
to struct S, because we don't pass decl_specs from cp_parser_type_specifier
down to cp_parser_class_specifier.  Therefore I've attempted to do "push
the
decl_specifiers onto a vec that is a GC root", except I couldn't really
push
the decl_specifiers, because first I'd have to mark cp_decl_specifier_seq
with
GTY(()) and even that wouldn't be enough for me to be able to create

  static GTY(()) vec

But here we only care about cp_decl_specifier_seq::attributes, so the
patch is just this.  I've also extended the test so now we test a nested
class too.

gcc/cp/ChangeLog:

PR c++/91416
* parser.c: Create a GC root for attributes in a decl specifier.
(cp_parser_type_specifier): Push/pop ->attributes onto/from it.

gcc/testsuite/ChangeLog:

PR c++/91416
* g++.dg/other/gc7.C: New test.

[Bug driver/99896] g++ drops -lc

[schwab--- via Gcc-bugs]

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

--- Comment #5 from Andreas Schwab  ---
The bug is in gdb because re_search cannot be paired with regcomp.

[Bug c++/99901] New: static const class var implemented with constexpr doesn't emit symbols in C++17 mode

[tellowkrinkle at gmail dot com via Gcc-bugs]

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

Bug ID: 99901
   Summary: static const class var implemented with constexpr
doesn't emit symbols in C++17 mode
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tellowkrinkle at gmail dot com
  Target Milestone: ---

The following code fails to output any symbols when compiled with `-std=c++17`:

struct A {
static const int a;
};
constexpr int A::a = 5;

Godbolt link: https://gcc.godbolt.org/z/13efnK4x4

You can run this in a way that results in a linker error with the following:

a.h:
#pragma once
struct A { static const int a; };

a.cpp:
#include "a.h"
constexpr int A::a = 0;

main.cpp:
#include "a.h"
int main() { return A::a; }

Works fine when compiled with `g++ main.cpp a.cpp`
Fails when compiled with `g++ -std=c++17 main.cpp a.cpp`

[Bug c++/99897] ICE Segmentation fault when operator appear in template parameter-list

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Another dup of 93383.

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

[Bug c++/93383] ICE on accessing field of a structure which is non-type template parameter, -std=c++2a

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

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

[Bug c++/93383] ICE on accessing field of a structure which is non-type template parameter, -std=c++2a

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

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

--- Comment #11 from Marek Polacek  ---
template  struct A {};
template  struct S { void foo(S<+a>); };

[Bug c++/99643] [8/9/10/11 Regression] internal compiler error in build_over_call, involving array new and copy elision

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

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

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

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

commit r11-7980-gc3d3bb0f03dbd02512ab46979088ee8e22520c24
Author: Jason Merrill 
Date:   Sat Apr 3 16:17:29 2021 -0400

c++: array new initialized from a call [PR99643]

Here the get_foo() call results in a TARGET_EXPR, which we strip in
massage_init_elt, but then when build_vec_init tries to use it to
initialize
the array element we crash because build_aggr_init expects a class rvalue
to
have a TARGET_EXPR.  So don't strip it.

The stripping was added in r206639 for PR59659, so I checked that removing
it didn't significantly increase compile time or memory usage for that
testcase; compile time was unaffected, memory usage increased by 0.4%.

gcc/cp/ChangeLog:

PR c++/99643
* typeck2.c (massage_init_elt): Don't strip TARGET_EXPR.

gcc/testsuite/ChangeLog:

PR c++/99643
* g++.dg/cpp0x/initlist-new5.C: New test.

[Bug c++/99643] [8/9/10 Regression] internal compiler error in build_over_call, involving array new and copy elision

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |internal compiler error in  |internal compiler error in
   |build_over_call, involving  |build_over_call, involving
   |array new and copy elision  |array new and copy elision

--- Comment #3 from Jason Merrill  ---
Fixed for GCC 11 so far.

[Bug driver/99896] g++ drops -lc

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

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

Tom de Vries  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #6 from Tom de Vries  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Tom de Vries from comment #2)
> > I don't understand. AFAICT, it's dropped.  It's not moved to the end,
> > because -lc is already at the end without specifying -lc. 
> 
> OK, it's dropped because it's always present at the end.
> 
> This is similar to adding -I/usr/include which gets ignored, because it's
> already going to be searched anyway as a system header directory. Quoting
> the manual:
> 
> "If a standard system include directory, or a directory specified with
> -isystem, is also specified with -I, the -I option is ignored."
> 
>  
> > Um, for my understanding, does that mean you agree this is a bug in g++?
> 
> No.
> 

OK, so here ( https://gcc.gnu.org/onlinedocs/gcc/Invoking-GCC.html#Invoking-GCC
) I read:
...
Also, the placement of the -l option is significant. 
...

So, if the documentation of gcc says that placement of the -l option is
significant, then why does g++ decide to mess with that?  ISTM g++ violates
documented behaviour.

[Bug c++/99902] New: Deduced return type of lambda in default template argument takes return type from variable template

[jason.e.cobb at gmail dot com via Gcc-bugs]

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

Bug ID: 99902
   Summary: Deduced return type of lambda in default template
argument takes return type from variable template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.e.cobb at gmail dot com
  Target Milestone: ---

In the following code:

[BEGIN EXAMPLE]

template
struct foo {};

template
inline constexpr auto foo_v = foo<>{};

auto x = foo_v;

[END EXAMPLE]

On Compiler Explorer: https://godbolt.org/z/nor57d4Ke

GCC believes the return type of the lambda to be long, even though the return
type should be deduced as void. This is apparent from the error message that
GCC rejects with:

[BEGIN ERROR]

: In instantiation of 'constexpr const auto foo_v':
:7:10:   required from here
:1:26: error: return-statement with no value, in function returning
'long int' [-fpermissive]
1 | template
  |  ^~
:5:23: error: conversion from 'long int (*)()' to 'void (*)()' in a
converted constant expression
5 | inline constexpr auto foo_v = foo<>{};
  |   ^
:5:23: error: could not convert '{}'
from '' to 'void (*)()'
Compiler returned: 1

[END ERROR]

GCC rejects with a similar error message in the following case with an alias
template instead of a variable template:

[BEGIN EXAMPLE]

template
struct foo {};

template
using foo_t = foo<>;

using some_foo = foo_t;

[END EXAMPLE]

In the case where foo_t or foo_v has multiple template arguments, the first is
taken to be the return type.

In the case where the first template parameter foo_t or foo_v is a non-type
template parameter, GCC ICEs:

[BEGIN EXAMPLE]

template
struct foo {};

template
using foo_t = foo<>;

using some_foo = foo_t<12>;

[END EXAMPLE]

On Compiler Explorer: https://godbolt.org/z/MoPEGzYP7

This results in the following error:

[BEGIN ERROR]

: In substitution of 'template > using foo_t = foo<>
[with int  = 12]':
:7:26:   required from here
:1:22: internal compiler error: in tsubst, at cp/pt.c:15578
1 | template
  |  ^
0x1cfd119 internal_error(char const*, ...)
???:0
0x6baa1b fancy_abort(char const*, int, char const*)
???:0
0x9182c1 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x916211 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x949897 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x941fc6 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x91658d tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x916637 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x94ce32 instantiate_template(tree_node*, tree_node*, int)
???:0
0x916b31 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x92a38e lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x97ff1d finish_template_type(tree_node*, tree_node*, int)
???:0
0x8e140d c_parse_file()
???:0
0xa606f2 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.

[END ERROR]

On Compiler Explorer: https://godbolt.org/z/713js5aq7

[Bug target/99890] The -mstrict-aglign doesn't support the ARM targets

[zmin1 at avic dot com via Gcc-bugs]

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

--- Comment #2 from ZhangMin  ---
(In reply to Andrew Pinski from comment #1)
> Because it is a target specific option.
> What exactly are you trying to do?
> 
> most instructions in ARMv7+ support unaligned data.

Although armv7 + supports non aligned data access, our application requires
data aligned access.
On PowerPC, we can achieve the goal well by using - mstrict align option, but
not on arm.
Is there any other way to solve this problem?

[Bug target/99890] The -mstrict-aglign doesn't support the ARM targets

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
What exactly are you looking for? What does the code look like and what exact
target are you using?

Also GCC 4.8.1 is over 6 years old, can you try a newer GCC?

[Bug lto/99898] Possible LTO object incompatibility on gcc-10 branch

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

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

--- Comment #2 from Andrew Pinski  ---
This is not the first time versioning of LTO objects have come up with respect
to the bug fix releases.

[Bug other/99903] New: 32-bit x86 frontends randomly crash while reporting timing on Windows

[izbyshev at ispras dot ru via Gcc-bugs]

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

Bug ID: 99903
   Summary: 32-bit x86 frontends randomly crash while reporting
timing on Windows
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izbyshev at ispras dot ru
  Target Milestone: ---
  Host: i686-w64-mingw32
Target: i686-w64-mingw32
 Build: i686-w64-mingw32

Created attachment 50503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50503&action=edit
A reproducer

Running cc1 from i686-w64-mingw32-gcc[1] with timing report enabled (e.g.
without `-quiet` or with `-ftime-report`) may randomly crash on Windows.

A reproducer script is attached (tested on two Windows 10 1909 x64 machines).
The time to reproduce varied from seconds to half an hour. Running multiple cc1
to increase load appears to help, but is not required; just running a single
cc1 in a loop is enough too. The crash manifests as silent exit with code
3221225477 (0xc005; EXCEPTION_ACCESS_VIOLATION). Debugging showed the
following.

The eventual crash is actually a nested one. It happens at [2] while reporting
an ICE because `context->printer` is NULL (which, by itself, looks like a
separate bug).

The initial crash is triggered by `gcc_unreachable()` in
`timer::validate_phases()`[3].

#0  0x0125be91 in pp_format(pretty_printer*, text_info*) ()
#1  0x0125146b in diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) ()
#2  0x01251bd7 in diagnostic_impl(rich_location*, diagnostic_metadata const*,
int, char const*, char**, diagnostic_t)
()
#3  0x012521b8 in internal_error(char const*, ...) ()
#4  0x01528a96 in fancy_abort(char const*, int, char const*) ()
#5  0x014f9e9c in timer::validate_phases(_iobuf*) const [clone .cold] ()
#6  0x009400d3 in timer::print(_iobuf*) ()
#7  0x00942422 in toplev::~toplev() ()
#8  0x01526003 in main ()

And `gcc_unreachable()` is reached because `phase_user > total->user *
tolerance` is true. GCC doesn't print anything when run from `repro.py` because
of output buffering, but I extracted one message from memory:

Timing error: total of phase timers exceeds total time.
user1.734723475976807094e-18 > 8.673617379884035472e-19

I couldn't reproduce this with 64-bit x86 GCC.

[1]
https://github.com/msys2/MINGW-packages/tree/5d82e17a56a3216a54dbb5924b92c96284ae5c97/mingw-w64-gcc
[2]
https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/diagnostic.c;h=ed52bc03d17afa2d7ac3419beb73e8f59b6f392b;hb=releases/gcc-10.2.0#l1077
[3]
https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/timevar.c;h=a3a882d32040db6503260ab51ee4bf338c4aa2b5;hb=releases/gcc-10.2.0#l628