Dear GCC development team,
We've been trying to build reproducibly the minimal NixOS image, and
gcc was one of the last issues we had.
We found that disabling profiled bootstrap compilation of GCC allowed
us to get a reproducible build of gcc.
Our efforts can be followed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99881
Bug ID: 99881
Summary: Regression compare -O2 -ftree-vectorize with -O2 on
SKX/CLX
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Paul,
This looks OK to me for Trunk. I believe 10 is in freeze so it may have
to wait or get release manager approval.
Jerry
On 4/1/21 6:44 AM, Paul Richard Thomas via Fortran wrote:
This one is trivial. The wrong error message was transformed by my patch
for PR98897 into an ICE. This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99880
Bug ID: 99880
Summary: ICE in maybe_set_vectorized_backedge_value, at
tree-vect-loop.c:9161
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
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 20210401 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859
--- Comment #12 from Tobias Schlüter ---
Because I posted 32bit code before, here is what the trunk does with -m32
func34(m34):
fld DWORD PTR [esp+8]
mov eax, DWORD PTR [esp+4]
fstpQWORD PTR [eax]
fld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859
--- Comment #11 from Tobias Schlüter ---
Works on trunk now but not 10.2. Compiler explorer link:
https://godbolt.org/z/1zbh4YM4W
On the trunk we get the following. I'm guessing that one could enhance the
read pattern by using more registers,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99878
Bug ID: 99878
Summary: -use-ld=gold says "could not find ld" instead of
"could not find gold"
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80824
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80681
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2017-08-23 00:00:00 |2021-4-1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 80147, which changed state.
Bug 80147 Summary: missing maybe-uninitialized warning on variable with no side
effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147
Martin Sebor changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976
Bug 89976 depends on bug 79658, which changed state.
Bug 79658 Summary: [-Wuninitialized] referencing uninitialized field of POD
struct should warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 79658, which changed state.
Bug 79658 Summary: [-Wuninitialized] referencing uninitialized field of POD
struct should warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938
--- Comment #3 from Jason Merrill ---
Reduced more:
template
int sink(Args&&... args) { return 2; }
template
auto fwd(const T1& t1) {
return
[] (auto&&... ts1) {
return
[...ts1 = ts1] () {
return sink(ts1...);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
Snapshot gcc-8-20210401 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20210401/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993
Martin Sebor changed:
What|Removed |Added
Known to fail|4.1.0, 5.3.0, 6.2.0, 7.0|10.2.0, 11.0, 5.5.0, 6.4.0,
Various places iterate through all of the saved_diagnostics to find
just the ones that are at a given enode. This patch adds a per-enode
record of the diagnostics that are at each node, to save iterating
through all of the diagnostics each time.
Successfully bootstrapped & regrtested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
Jason Merrill changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
> If RMS had ever done the same (pretty unlikely, Fortran isnt't his
> thing), I would have done the same without thinking twice about it.
I agree with that sentiment. The fact that somebody has a certain
role doesn't necessarily mean that the question is asked with that hat
on: it may be
I bootstrap built and tested for powerpc 64 on power 7 and 8 BE and
power 8, 9, and 10 LE and I saw nothing unexpected.
On 4/1/21 7:35 AM, Richard Biener wrote:
The first release candidate for GCC 10.3 is available from
https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/
ftp
On 01.04.21 22:33, Joseph Myers wrote:
And while in that case RMS probably learned of modules and libcody through
the SC mailing list, in general he has this habit of asking GNU package
developers random questions related to their packages.
I've been asked a few questions about gfortran by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] ICE: in |[10 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
--- Comment #10 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:6a60ffc297b9d4903543a25538e62e7fb39420a9
commit r11-7954-g6a60ffc297b9d4903543a25538e62e7fb39420a9
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99877
--- Comment #1 from Carl Nettelblad ---
Created attachment 50500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50500=edit
Preprocessed source file
Fully preprocessed sources. Compressed only to fit bugzilla limit.
I would very much like to get all the details right on my next submission.
I'm submitting this query for feedback before I do the full submission.
Most changes requested require obvious fixes. One has me confused about
the best action to take.
- - - -
On the issue of alloca vs XALLOCAVEC, I
On 4/1/21 4:09 PM, Patrick Palka wrote:
In the testcase below, during ahead-of-time deduction of a constrained
auto from do_range_for_auto_deduction, we trip over the assert inside
do_auto_deduction that expects the deduction context to be
adc_return_type or adc_variable_type, but the context in
On 4/1/21 5:12 PM, Marek Polacek wrote:
On Thu, Apr 01, 2021 at 03:09:44PM -0400, Jason Merrill wrote:
On 4/1/21 2:15 PM, Marek Polacek wrote:
Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99874
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority|P3
On Thu, Apr 01, 2021 at 03:09:44PM -0400, Jason Merrill wrote:
> On 4/1/21 2:15 PM, Marek Polacek wrote:
> > Here we crash in reshape_init because we're accessing ggc_freed
> > & poisoned data: since r277865 in defaulted_late_check we call
> > synthesize_method here:
> >
> >if (kind ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86169
--- Comment #5 from Jonathan Wakely ---
Oh dear, this should have removed the 'noexcept' from the non-const data(),
since it might now fail to allocate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
--- Comment #5 from Jonathan Wakely ---
It would have worked if it used std::as_const(_M_pathname).data() or
_M_pathname.c_str() instead of _M_pathname.data(). It's only the non-const
data() added in C++17 which reallocates (since r261642
On 4/1/21 10:33 PM, Joseph Myers wrote:
RMS once asked me about the status of fused multiply-add support in glibc.
I don't know why. He wasn't asking for any changes or objecting to
anything the glibc maintainers had done. I'd hope that future Chief
GNUisances won't try to get involved in
On Thu, Apr 01, 2021 at 08:49:19PM +0100, Jonathan Wakely via Gcc wrote:
> On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote:
> >
> > Richard Biener wrote:
> >
> > > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou
> > > wrote:
> > >>> I have so far bootstrapped and tested the release candidate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 78915, which changed state.
Bug 78915 Summary: missing -Wuninitialized accessing allocated memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78915
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78915
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99877
Bug ID: 99877
Summary: Crash in GIMPLE pass:sanopt in huge function using
OpenMP
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
On Thu, Apr 1, 2021 at 10:47 PM H.J. Lu wrote:
>
> On Thu, Apr 1, 2021 at 1:28 PM Jan Hubicka wrote:
> >
> > > On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
> > > >
> > > > Since uiret should be used only for user interrupt handler return, don't
> > > > generate uiret in interrupt handler
On Thu, Apr 1, 2021 at 1:28 PM Jan Hubicka wrote:
>
> > On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
> > >
> > > Since uiret should be used only for user interrupt handler return, don't
> > > generate uiret in interrupt handler return with -mcmodel=kernel even if
> > > UINTR is enabled.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
--- Comment #4 from Jonathan Wakely ---
Wow, this is tricksy.
The bug happens when parsing the string into a path. The path is split into
components and the offset of each component from the beginning of the string is
stored, so that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2017-07-20 00:00:00 |2021-4-1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -65,19 +65,12 @@ namespace posix = std::filesystem::__gnu_posix;
fs::path
fs::absolute(const path& p)
{
-#ifdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-04-01
On Thu, 1 Apr 2021, Ian Lance Taylor via Gcc wrote:
> > 2) Last year, I asked for libcody to be added as a subcomponent, with
> > its Apachev2 license intact. AFAICT RMS was involved in that licensing
> > discussion, /for which I never received a response/. He was not at the
> > FSF then, so he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On Thu, 1 Apr 2021 at 21:08, Richard Biener wrote:
>
> On April 1, 2021 9:49:19 PM GMT+02:00, Jonathan Wakely via Gcc
> wrote:
> >On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote:
> >>
> >> Richard Biener wrote:
> >>
> >> > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou
> >> > wrote:
> >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99096
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:3a2dc91d7574d1b03b4e5a8ce4098afb62145c35
commit r10-9653-g3a2dc91d7574d1b03b4e5a8ce4098afb62145c35
Author: Jonathan
> On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
> >
> > Since uiret should be used only for user interrupt handler return, don't
> > generate uiret in interrupt handler return with -mcmodel=kernel even if
> > UINTR is enabled.
>
> NAK, -mcmodel should not affect ISAs, in the same way it doesn't
In the testcase below, during ahead-of-time deduction of a constrained
auto from do_range_for_auto_deduction, we trip over the assert inside
do_auto_deduction that expects the deduction context to be
adc_return_type or adc_variable_type, but the context in this case is
adc_unspecified.
We could
On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
>
> Since uiret should be used only for user interrupt handler return, don't
> generate uiret in interrupt handler return with -mcmodel=kernel even if
> UINTR is enabled.
NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584
--- Comment #5 from Jason Merrill ---
*** Bug 99583 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99583
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
On April 1, 2021 9:49:19 PM GMT+02:00, Jonathan Wakely via Gcc
wrote:
>On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote:
>>
>> Richard Biener wrote:
>>
>> > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou
>> > wrote:
>> >>> I have so far bootstrapped and tested the release candidate on
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99583
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:0cf4813202f19768e31666f6aa82bde4dce4065a
commit r11-7953-g0cf4813202f19768e31666f6aa82bde4dce4065a
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:0cf4813202f19768e31666f6aa82bde4dce4065a
commit r11-7953-g0cf4813202f19768e31666f6aa82bde4dce4065a
Author: Jason Merrill
Date:
The tree-walk looking for parameter packs didn't find this one because we
weren't stepping into TYPE_RAISES_EXCEPTIONS.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/99583
PR c++/99584
* tree.c (cp_walk_subtrees) [FUNCTION_TYPE]: Walk into
On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote:
>
> Richard Biener wrote:
>
> > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou
> > wrote:
> >>> I have so far bootstrapped and tested the release candidate on
> >>> x86_64-linux. Please test it and report any issues to bugzilla.
>
> On x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
Bug ID: 99876
Summary: std::filesystem::absolute is inefficient
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
L
On Thu, Apr 1, 2021, 2:08 PM Bernhard Reutner-Fischer
wrote:
> On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer <
> rep.dot@gmail.com> wrote:
> >On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote:
> >>Change the preprocessor logic so RTEMS uses utime().
> >>gcc/ada/
> >>
Richard Biener wrote:
On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou
wrote:
I have so far bootstrapped and tested the release candidate on
x86_64-linux. Please test it and report any issues to bugzilla.
On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails.
On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell wrote:
>
> You, the SC, have chosen to fix this as a clerical error. The most
> do-nothing response, other than actually doing nothing.
>
> I am profoundly disappointed that you have not even acknowledged the
> harm RMS has caused. Using passive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875
Iain Sandoe changed:
What|Removed |Added
Target||x86_64-darwin, i686-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875
Bug ID: 99875
Summary: [10 Regression] experimental filesystem fails on
Darwin
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
On 4/1/21 2:15 PM, Marek Polacek wrote:
Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:
if (kind == sfk_comparison)
{
/* If the function was declared constexpr, check that the
On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer
wrote:
>On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote:
>>Change the preprocessor logic so RTEMS uses utime().
>>gcc/ada/
>> * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
>
>RTEMS probably doesn't care alot about
On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote:
>Change the preprocessor logic so RTEMS uses utime().
>gcc/ada/
> * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
RTEMS probably doesn't care alot about accurate time, from the looks. Otherwise
it would not mandate use of
On 1 April 2021 20:31:13 CEST, Bernhard Reutner-Fischer
wrote:
>On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches"
> wrote:
>>Since uiret should be used only for user interrupt handler return,
>>don't
>>generate uiret in interrupt handler return with -mcmodel=kernel even
>if
>>UINTR is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99874
Bug ID: 99874
Summary: ICE Segmentation fault when declared variable template
of template lambda
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
Change the preprocessor logic so RTEMS uses utime().
gcc/ada/
* adaint.c (__gnat_copy_attribs): RTEMS should use utime().
---
gcc/ada/adaint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index 0a90c92402c..d3b83f61076 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches"
wrote:
>Since uiret should be used only for user interrupt handler return,
>don't
>generate uiret in interrupt handler return with -mcmodel=kernel even if
>UINTR is enabled.
>
>gcc/
>
> PR target/99870
> * config/i386/i386.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873
Bug ID: 99873
Summary: [11 Regression] GCC no longer makes as much use of ST3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726
--- Comment #9 from José Rui Faustino de Sousa ---
Hi Paul!
This seems to fix the ICE generated by using -ftrapv -fcheck=bounds
Fixes "nelems" type and adds an optional assert to make sure it stays fixed.
Best regards,
José Rui
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #9 from Marek Polacek
Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:
if (kind == sfk_comparison)
{
/* If the function was declared constexpr, check that the definition
qualifies. Otherwise we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99868
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
Jonathan Wakely changed:
What|Removed |Added
Known to fail||10.2.0, 11.0, 9.3.0
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871
--- Comment #1 from Jonathan Wakely ---
I wonder if there's a reason we don't just put the visibility on the namespace
the way we do elsewhere:
namespace std _GLIBCXX_VISIBILITY(default)
I will do that, or just move the pragma after the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584
Jason Merrill changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #2 from
On 01/04/21 18:47 +0200, Eric Botcazou wrote:
Thanks, pushed.
I can confirm that the build failure we had is now gone, thanks!
Eric, are you building the RC with --enable-maintainer-mode maybe? Or
regenerating the autoconf files yourself?
The latter, we have local configure changes so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
On 01/04/2021 17:11, Alex Coplan via Gcc-patches wrote:
Hi all,
This patch fixes PR99748 which shows us trying to pass the argument to
__aeabi_f2iz in the VFP register s0 when the library function is
expecting to use the GPR r0. It also fixes the __aeabi_f2uiz case which
was broken in the
On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou
wrote:
>> I have so far bootstrapped and tested the release candidate on
>> x86_64-linux. Please test it and report any issues to bugzilla.
>
>It does not build for Windows:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567582.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872
Bug ID: 99872
Summary: [11 Regression] optimizations sometimes lead to
missing asm prefixes
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: critical
On 4/1/21 10:30 AM, Patrick Palka wrote:
In the below testcase, during finish_compound_literal for A{},
type_uses_auto finds and returns the CTAD placeholder for B{V}, which
tricks us into attempting CTAD on A{} and leads to bogus errors.
AFAICT 'type' will always be a bare 'auto' in the CTAD
On 3/31/21 2:27 PM, David Edelsohn via Gcc wrote:
[I previously sent this from another email account, but it seems to be
lost. I am sending this on behalf of the GCC Steering Committee.]
In 2012 RMS was added to the GCC Steering Committee web page
based on his role in the GNU Project, though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871
Bug ID: 99871
Summary: #includes inside push visibility scope
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Since uiret should be used only for user interrupt handler return, don't
generate uiret in interrupt handler return with -mcmodel=kernel even if
UINTR is enabled.
gcc/
PR target/99870
* config/i386/i386.md (interrupt_return): Don't generate uiret
for -mcmodel=kernel.
> Thanks, pushed.
I can confirm that the build failure we had is now gone, thanks!
> Eric, are you building the RC with --enable-maintainer-mode maybe? Or
> regenerating the autoconf files yourself?
The latter, we have local configure changes so we regenerate the script.
--
Eric Botcazou
ping
> [Changes from V4:
> - Rebased to latest master.
> - Support for DATASEC in BTF.
> - Bug fixes in the CTF support.
> - Be more silent: do not inform() the user anymore if -gctf is used
> along with a frontend for which there is no CTF support. Ignore
> the request instead.
> - Got
1 - 100 of 221 matches
Mail list logo
