https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789
--- Comment #3 from Kewen Lin ---
Bisection shows it started to fail from r11-205.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
--- Comment #16 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:3ae0cd94abc15e33dc06ca7a5f76f14b1d74129f
commit r11-2898-g3ae0cd94abc15e33dc06ca7a5f76f14b1d74129f
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96809
Bug ID: 96809
Summary: Duplicated module name in Fortran test cases
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96285
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:8ca43e4ea58ae436af4b5818916abc15b2fd8f49
commit r11-2891-g8ca43e4ea58ae436af4b5818916abc15b2fd8f49
Author: Göran Uddeborg
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
--- Comment #5 from joseph at codesourcery dot com ---
The way GCC actually behaves is that this constant is unsigned in the
preprocessor but signed outside the preprocessor. I'm not sure that's
exactly intent (though the preprocessor having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
--- Comment #4 from joseph at codesourcery dot com ---
IEEE 754 does not specify the choice of output NaN. None of the C
bindings to IEEE 754 specify the choice of output NaN. There are various
architecture differences in choice of output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96808
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96808
Bug ID: 96808
Summary: MMA built-in dies with incorrect sharing of tree nodes
error
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96807
Bug ID: 96807
Summary: Division by zero produces zero with gcc -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787
--- Comment #8 from Bill Schmidt ---
I'm working on a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796
--- Comment #5 from Alex Coplan ---
Started with this change:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8eaff6ef97836100801f7b40dc03f77fbebe03ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96806
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96802
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96802
--- Comment #3 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:8f1ea8ddccc34c28f72910d9f61bacd35cc73270
commit r11-2890-g8f1ea8ddccc34c28f72910d9f61bacd35cc73270
Author: H.J. Lu
Date: Wed Aug 26
684bcbf88-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200826 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96802
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805
--- Comment #2 from Marc Mutz ---
also in gcc version 10.2.1 20200826 (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96731
--- Comment #4 from Jonathan Wakely ---
Created attachment 49135
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49135=edit
Patch to relax std::uniform_int_distribution requirements
This patch allows a custom integer-like type to be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805
--- Comment #1 from Marc Mutz ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/d/gcc/10/libexec/gcc/x86_64-pc-linux-gnu/10.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/d/gcc/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805
Bug ID: 96805
Summary: ICE: Segmentation fault in instantiate_template /
pop_nested_class()
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96802
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
--- Comment #4 from Richard Smith ---
(In reply to Richard Smith from comment #3)
> such a literal "has no type" in C, which presumably results in undefined
> behavior
Ah, no, C11 6.4.4/2 makes this a constraint violation. But either way I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
--- Comment #3 from Richard Smith ---
In the mean time, what is GCC's intent here? Clang is following the behavior
described by GCC's diagnostic text, treating decimal integer literals that
don't fit in 'long long' but do fit in 'unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96803
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:5494edae83ad33c769bd1ebc98f0c492453a6417
commit r11-2887-g5494edae83ad33c769bd1ebc98f0c492453a6417
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96803
--- Comment #1 from Jonathan Wakely ---
This is not a regression, it's been wrong since I added uses-allocator
construction in r174443.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
--- Comment #3 from Paweł Bylica ---
Yes, you are right, that is not violation of IEEE 754 (I assumed wrongly
previously, sorry).
However, it still maybe undesired to get different binary results depending on
optimization enabled/disabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
H.J. Lu changed:
What|Removed |Added
URL||https://gitlab.com/x86-psAB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
--- Comment #2 from Marc Glisse ---
(In reply to Paweł Bylica from comment #0)
> This is a problem because when both arguments are NaNs, the result may be
> different than the one predicted by IEEE 754.
Could you quote the sentence in IEEE 754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
--- Comment #1 from Paweł Bylica ---
Created attachment 49133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49133=edit
Assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
Bug ID: 96804
Summary: Arguments are swapped in floating-point addition
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96803
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-08-26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96803
Bug ID: 96803
Summary: std::tuple chooses wrong constructor for
uses-allocator construction
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96802
Bug ID: 96802
Summary: [11 Regression] ICE in ix86_handle_option, at
common/config/i386/i386-common.c:338
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96801
Bug ID: 96801
Summary: Refactoring of LIM introduced possible bug
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796
--- Comment #3 from Alex Coplan ---
Adding -fcommon, I can reproduce this ICE on trunk. The default changed in GCC
10 (as of 6271dd984d7f920d4fb17ad37af6a1f8e6b796dc).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83258
Matthias Noack changed:
What|Removed |Added
CC||ma.noack.pr at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96800
seurer at gcc dot gnu.org changed:
What|Removed |Added
Target||powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96800
Bug ID: 96800
Summary: [11 regression] compilation error for
20_util/function_objects/searchers.cc after r11-2857
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
--- Comment #20 from Jason Merrill ---
This issue came up in the GCC/LLVM compatibility discussion today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96466
--- Comment #4 from Richard Biener ---
(In reply to Martin Liška from comment #3)
> It's the same store as PR96453: copyprop can eliminate that to:
>
> Folding statement: _3 = { 5 };
> Queued stmt for removal. Folds to: { 5 }
> Folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96698
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:2130efe6ac7beba72d289e3dd145daa10aeaed54
commit r11-2882-g2130efe6ac7beba72d289e3dd145daa10aeaed54
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71960
--- Comment #6 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:42fb390082b59c0b5af6a9f1e5a2e608ccb8e193
commit r9-8833-g42fb390082b59c0b5af6a9f1e5a2e608ccb8e193
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71960
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:85847fd421d7760f45f0e69c7ae3607f2f898bb8
commit r10-8676-g85847fd421d7760f45f0e69c7ae3607f2f898bb8
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71960
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:3eefb302d2bd8502cb3d8fe44e672b11092ccaf6
commit r11-2881-g3eefb302d2bd8502cb3d8fe44e672b11092ccaf6
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #12 from rguenther at suse dot de ---
On Wed, 26 Aug 2020, matz at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
>
> --- Comment #11 from Michael Matz ---
> (In reply to Jan Hubicka from comment #10)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96783
--- Comment #7 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:71b6257e3a90995e1c1d3d2716a0eec5eef243db
commit r11-2877-g71b6257e3a90995e1c1d3d2716a0eec5eef243db
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96783
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #11 from Michael Matz ---
(In reply to Jan Hubicka from comment #10)
> > We could also punt: when enable-link-mutex we could artificially up the job
> > number for make to account for the waiting link steps. I.e. when normally
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96766
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |9.4
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96766
--- Comment #6 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:9def04578cca8a0850e835eb095d9ff60097f691
commit r9-8832-g9def04578cca8a0850e835eb095d9ff60097f691
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96799
Bug ID: 96799
Summary: C and Ada frontends have a different interpretation of
double constants
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96766
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:4b6366f24890e25a07f9a045d15633c5b1fb80cb
commit r10-8675-g4b6366f24890e25a07f9a045d15633c5b1fb80cb
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798
Bug ID: 96798
Summary: Analyzer failures on Darwin
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #10 from Jan Hubicka ---
> We could also punt: when enable-link-mutex we could artificially up the job
> number for make to account for the waiting link steps. I.e. when normally -jN
> was given, the link step could be done under
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #9 from Michael Matz ---
We could also punt: when enable-link-mutex we could artificially up the job
number for make to account for the waiting link steps. I.e. when normally -jN
was given, the link step could be done under -j(N +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96565
--- Comment #10 from Richard Biener ---
Ah, no - error in my patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96565
--- Comment #9 from Richard Biener ---
OK, well - but the fix exposes (IIRC I ran into this at some time in the past
already) that GIMPLE_RESX does not have virtual operands but it needs to
represent a use of global memory at least in the case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96797
Bug ID: 96797
Summary: OpenACC fortran acc_get_cuda_stream
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Keywords: openacc
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #6 from Uroš Bizjak ---
Ehm...
2006-10-29 Richard Guenther
* config/i386/i386-protos.h (ix86_expand_floorceil): Declare.
(ix86_expand_floorceildf_32): Likewise.
* config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21146
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #8 from Martin Liška ---
There's graph when omitting link mutex:
https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/24409fcf099230dbc19ef50e193655c578d6d527/gcc-10-without-mutex-lock.svg
As seen, memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
Tomáš Trnka changed:
What|Removed |Added
CC||trnka at scm dot com
--- Comment #12 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #7 from rguenther at suse dot de ---
On Wed, 26 Aug 2020, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
>
> --- Comment #3 from Jan Hubicka ---
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796
Richard Biener changed:
What|Removed |Added
Target||aarch64
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-08-26
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86564
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #6 from Richard Biener ---
(In reply to Jan Hubicka from comment #1)
> > As seen
> > here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Known to work||10.1.1, 11.0, 8.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796
Bug ID: 96796
Summary: aarch64: ICE during RTL pass: reload
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #5 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
>
> --- Comment #4 from Martin Liška ---
> > > For jobserver they are still running even though they sleep.
> > Aha, so it is extra locking mechanizm we
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
>
> --- Comment #4 from Martin Liška ---
> > > For jobserver they are still running even though they sleep.
> > Aha, so it is extra locking mechanizm we add without jobserver
> > knowledge.
>
> It's unrelated to jobserver, one can enable it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #4 from Martin Liška ---
> > For jobserver they are still running even though they sleep.
> Aha, so it is extra locking mechanizm we add without jobserver
> knowledge.
It's unrelated to jobserver, one can enable it with configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #3 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
>
> --- Comment #2 from Martin Liška ---
> (In reply to Jan Hubicka from comment #1)
> > > As seen
> > >
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
>
> --- Comment #2 from Martin Liška ---
> (In reply to Jan Hubicka from comment #1)
> > > As seen
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84026
--- Comment #4 from Jonathan Wakely ---
Fixed testcase (so it doesn't define S1::E1 twice):
struct S1 {
enum class E1;
};
enum class S1::E1 {}; // OK
struct S2 {
enum class E2;
};
enum class ::S2::E2 {}; //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84026
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #2 from Martin Liška ---
(In reply to Jan Hubicka from comment #1)
> > As seen
> > here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96615
--- Comment #2 from Jan Hubicka ---
> Even not with -ffinite-loops. The reason is that finiteness of loops is
> determined by frontends now and recorded in loop->finite_p but the loop
> only appears after tail-recursion optimization. I guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #1 from Jan Hubicka ---
> As seen
> here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
>
> each blocking linking of a GCC front-end leads
> As seen
> here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
>
> each blocking linking of a GCC front-end leads to a wasted jobserver worker.
Hmm, I am not sure how to interpret the graph. I can see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795
Bug ID: 96795
Summary: MVE: issue with polymorphism and integer promotion
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12228
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-01-11 00:00:00 |2020-8-26
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #4 from Paweł Bylica ---
I missed some information:
This affects both double and float variants: __builtin_floor() and
__builtin_floorf().
This affects also usage of floor() C standard library function as the function
call usually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71975
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
Bug ID: 96794
Summary: --with-build-config=bootstrap-lto-lean with
--enable-link-mutex leads to poor LTRANS utilization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66900
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #3 from Paweł Bylica ---
Created attachment 49128
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49128=edit
Compiler invocation log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #1 from Paweł Bylica ---
Created attachment 49126
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49126=edit
Test source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #2 from Paweł Bylica ---
Created attachment 49127
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49127=edit
Assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
Bug ID: 96793
Summary: __builtin_floor produces wrong result when rounding
direction is FE_DOWNWARD
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52771
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52771
Jonathan Wakely changed:
What|Removed |Added
Keywords|accepts-invalid |
--- Comment #2 from Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
--- Comment #7 from Jonathan Wakely ---
It's "fixed" for C++11 because N::a is meaningful for scoped enums, and fails
to find it. But the code is invalid even in C++03.
Clang and EDG both reject this even in C++03 mode. We might want to do the
1 - 100 of 121 matches
Mail list logo
