https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393
--- Comment #10 from David Binderman ---
(In reply to Martin Liška from comment #9)
> I've got a patch candidate for it.
Ping Martin. Anything happened with that patch ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
Bug ID: 91964
Summary: Wrong -Wint-in-bool-context warning for enum constant
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91957
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Wed Oct 2 07:37:10 2019
New Revision: 276440
URL: https://gcc.gnu.org/viewcvs?rev=276440&root=gcc&view=rev
Log:
[LRA] Don't make eliminable registers live (PR91957)
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91949
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91952
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91954
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91956
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91957
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #1 from Richa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #15 from Jonathan Wakely ---
For the record, this has moved to
https://gcc.gnu.org/ml/gcc-help/2019-10/msg2.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
--- Comment #1 from Jonathan Wakely ---
(In reply to Jörg Richter from comment #0)
> I think all warnings are wrong because nowhere is a enum constant in a
> boolean context.
The warning is documented as diagnosing "using non-boolean integer con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #24 from ktkachov at gcc dot gnu.org ---
Thanks. Unfortunately I still see the ICE building 507.cactuBSSN_r on aarch64
with -flto in the same place:
995 gcc_assert (TYPE_NAME (t1)
996 && TREE_CODE (TYPE_NAME (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963
--- Comment #2 from Thomas Koenig ---
(In reply to Richard Biener from comment #1)
> But is it valid fortran?
I had to check, but yes.
LOGICAL is an elemental type conversion function, which has only constant
arguments, so it should be simplifi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
--- Comment #2 from Jörg Richter ---
The only boolean context I see is the if(...).
The if() is never used with enum constants/types, but only bool-s and int-s.
So according to the warning name (int-in-bool-context) the warning can
be expected in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #25 from Jan Hubicka ---
> --- Comment #24 from ktkachov at gcc dot gnu.org ---
> Thanks. Unfortunately I still see the ICE building 507.cactuBSSN_r on aarch64
> with -flto in the same place:
> 995 gcc_assert (TYPE_NAME (t1)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
Jonathan Wakely changed:
What|Removed |Added
CC||edlinger at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
--- Comment #4 from Jonathan Wakely ---
The warning was introduced for PR 77434 and the current behaviour by the fix
for PR 77700.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91940
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Wed Oct 2 10:18:50 2019
New Revision: 276442
URL: https://gcc.gnu.org/viewcvs?rev=276442&root=gcc&view=rev
Log:
PR tree-optimization/91940
* tree-vect-patterns.c: Include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91940
--- Comment #7 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> The loop with the rotate is vectorized, while the one with __builtin_bswap16
> is not.
It is a bit surprising that we do not canonicalize one to the other somewher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947
Jonathan Wakely changed:
What|Removed |Added
Depends on||81091
--- Comment #2 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #16 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #15)
> For the record, this has moved to
> https://gcc.gnu.org/ml/gcc-help/2019-10/msg2.html
Thanks, I also would like to apologize to Joseph for
not following h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
Stas Sergeev changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91606
--- Comment #12 from Richard Biener ---
Author: rguenth
Date: Wed Oct 2 10:54:10 2019
New Revision: 276448
URL: https://gcc.gnu.org/viewcvs?rev=276448&root=gcc&view=rev
Log:
2019-10-02 Richard Biener
PR c++/91606
* decl.c (b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91606
Richard Biener changed:
What|Removed |Added
Known to work||10.0
Summary|[9/10 regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #0)
> libstdc++ seems to lack AC_SYS_LARGEFILE in configury and thus uses
> fopen/open
> in fstream and friends that can fail not only because of large files but
> f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091
--- Comment #4 from Richard Biener ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Richard Biener from comment #0)
> > libstdc++ seems to lack AC_SYS_LARGEFILE in configury and thus uses
> > fopen/open
> > in fstream and friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
--- Comment #5 from Jörg Richter ---
There needs to be at least a way to suppress the warning with a cast
or some other construct (not pragma).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630
--- Comment #11 from Zavadovsky Yan ---
>We can set it as a default behavior for all FPU-capable SH4 variants,
>but that will pessimize it for everything.
>The other option is to enable this only for your specific CPU (ST-40),
>which would req
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #26 from ktkachov at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #25)
> > --- Comment #24 from ktkachov at gcc dot gnu.org ---
> > Thanks. Unfortunately I still see the ICE building 507.cactuBSSN_r on
> > aarch64
> > wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947
--- Comment #3 from Fregl ---
In out product we use 32 bit toolchain, but work with large files.
So there is only solution to use direct stat call insted fs::file_size?
It seems this is firm limitation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Huh, I thought I'd already fixed this a while ago.
I was thinking of Bug 85632 which is different.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947
--- Comment #4 from Jonathan Wakely ---
(In reply to Fregl from comment #3)
> It seems this is firm limitation.
It's a bug, you just have to wait for it to be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91965
Bug ID: 91965
Summary: missing simplification for (C - a) << N
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #27 from Jan Hubicka ---
Author: hubicka
Date: Wed Oct 2 12:41:36 2019
New Revision: 276454
URL: https://gcc.gnu.org/viewcvs?rev=276454&root=gcc&view=rev
Log:
PR c++/91222
* ipa-devirt.c (warn_types_mismatch): Fix co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #28 from Jan Hubicka ---
> Thanks! That fixes the benchmark build (and the rest of SPEC builds fine with
> -flto). It also bootstraps and tests on aarch64-none-linux-gnu fine.
Thanks! My testing concluded independently so I went ahead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
--- Comment #6 from Bernd Edlinger ---
(In reply to Jörg Richter from comment #5)
> There needs to be at least a way to suppress the warning with a cast
> or some other construct (not pragma).
That is simple: if ( C != A ) ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
--- Comment #7 from Jörg Richter ---
Yes, I changed our code already to
if( C != Enum() )
But I still think that an explicit cast should always silence this warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
--- Comment #5 from Guillaume ---
I think I found a work-around for the time being.
If you define your packed structs with the 'volatile' qualifier, the bug
doesn't seem to show up. May not be completely ideal, but it appears to work,
and the re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91716
--- Comment #8 from Bernd Edlinger ---
Author: edlinger
Date: Wed Oct 2 13:22:37 2019
New Revision: 276458
URL: https://gcc.gnu.org/viewcvs?rev=276458&root=gcc&view=rev
Log:
2019-10-02 Bernd Edlinger
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91716
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91606
--- Comment #13 from m.cencora at gmail dot com ---
You can remove my_array from the test case. I put there only to show that using
it instead of std::array allows to workaround the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963
--- Comment #4 from Steve Kargl ---
On Wed, Oct 02, 2019 at 02:03:21PM +, kargl at gcc dot gnu.org wrote:
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #1)
> > But is it valid fortran?
>
> Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91966
Bug ID: 91966
Summary: pack expansion for Cartesian product breaks if
certain indirections are involved
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630
Oleg Endo changed:
What|Removed |Added
Attachment #46987|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91967
Bug ID: 91967
Summary: gtest from google generates incorrect assembly code on
x86 solaris
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91967
--- Comment #1 from bob wilkinson ---
Created attachment 46990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46990&action=edit
output of g++ with save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91842
--- Comment #3 from Martin Jambor ---
Author: jamborm
Date: Wed Oct 2 15:09:37 2019
New Revision: 276465
URL: https://gcc.gnu.org/viewcvs?rev=276465&root=gcc&view=rev
Log:
[PR testsuite/91842] Skip gcc.dg/ipa/ipa-sra-19.c on power
2019-10-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91842
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #17 from Stas Sergeev ---
Created attachment 46991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46991&action=edit
the fix
Attached is the patch that I think is correct.
It also seems to work properly, i.e. the full
build proc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #14 from Alexander Monakov ---
Author: amonakov
Date: Wed Oct 2 15:37:12 2019
New Revision: 276466
URL: https://gcc.gnu.org/viewcvs?rev=276466&root=gcc&view=rev
Log:
ifcvt: improve cost estimation (PR 87047)
PR rtl-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65438
Thomas Schwinge changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|cesar at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
Alexander Monakov changed:
What|Removed |Added
Summary|[7/8/9/10 Regression] |[7/8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91968
Bug ID: 91968
Summary: DW_AT_low_pc missing for DW_TAG_label with LTO
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: deb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91653
Liu Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #5 from Li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91969
Bug ID: 91969
Summary: Compiling testsuite/g++.dg/ipa/pr85421.C with
-fdump-ipa-inline ICEs
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
Bug ID: 91970
Summary: arm: 64bit int to double conversion does not respect
rounding mode
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971
Bug ID: 91971
Summary: Profile directory concatenated with object file path
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91972
Bug ID: 91972
Summary: Bootstrap should use -Wmissing-declarations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963
--- Comment #5 from Steve Kargl ---
On Wed, Oct 02, 2019 at 07:07:08AM -0700, Steve Kargl wrote:
> On Wed, Oct 02, 2019 at 02:03:21PM +, kargl at gcc dot gnu.org wrote:
> > --- Comment #3 from kargl at gcc dot gnu.org ---
> > (In reply to Ric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
Bug ID: 91973
Summary: gcc failed for Multiple level macro expansion
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90839
Dmitrij Pochepko changed:
What|Removed |Added
CC||dpochepk at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91974
Bug ID: 91974
Summary: function not sequenced before function argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #1 from nsz at gcc dot gnu.org ---
floating-point exceptions are also missing for the same reason.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89012
--- Comment #10 from Oleg Endo ---
(In reply to Rich Felker from comment #9)
> I think it's actually just a matter of removing the patterns for generating
> bsrf, but I may be mistaken. Generating jsr should be what happens "by
> default" in some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #2 from Andreas Schwab ---
Don't you need #pragma STDC FENV_ACCESS?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91943
--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct 2 17:01:30 2019
New Revision: 276471
URL: https://gcc.gnu.org/viewcvs?rev=276471&root=gcc&view=rev
Log:
2019-10-02 Steven G. Kargl
PR fortran/91943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91942
--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct 2 17:04:57 2019
New Revision: 276472
URL: https://gcc.gnu.org/viewcvs?rev=276472&root=gcc&view=rev
Log:
2019-10-02 Steven G. Kargl
PR fortran/91942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91965
--- Comment #1 from Alexander Monakov ---
On a related thought, I wonder if we can canonicalize (x << CST) to (x * CST')
where CST' is 1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91785
--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct 2 17:09:45 2019
New Revision: 276473
URL: https://gcc.gnu.org/viewcvs?rev=276473&root=gcc&view=rev
Log:
2019-10-02 Steven G. Kargl
PR fortran/91785
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91816
sudi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #3 from nsz at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #2)
> Don't you need #pragma STDC FENV_ACCESS?
yes, for iso c conformance you need it, but gcc does not
handle it anyway, instead it requires -frounding-math.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91784
--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct 2 17:17:55 2019
New Revision: 276474
URL: https://gcc.gnu.org/viewcvs?rev=276474&root=gcc&view=rev
Log:
2019-10-02 Steven G. Kargl
PR fortran/91784
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91974
--- Comment #1 from Andrew Pinski ---
I dont think this is well defined. A call and its arguments are not sequence
points. Yes there is a sequence point between the assignment and 0 but nothing
else. Note c++17 does change the rules and I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91965
--- Comment #2 from Marc Glisse ---
(In reply to Alexander Monakov from comment #0)
> Do we want to handle this early on via match.pd? Perhaps also applies to
> simplifying (a +- C) << N.
What exact transformation do you want? Canonicalize the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91974
--- Comment #2 from Barry Revzin ---
C++17 does change this rule. expr.call/8:
The postfix-expression is sequenced before each expression in the
expression-list and any default argument. The initialization of a parameter,
including every associa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963
--- Comment #7 from Steve Kargl ---
On Wed, Oct 02, 2019 at 06:10:48PM +, tkoenig at gcc dot gnu.org wrote:
>
> You're right, Steve, the problem lies in the simplification
> of the implied DO loop (the error message is a catch-all
> which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90839
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91965
--- Comment #3 from Alexander Monakov ---
(In reply to Marc Glisse from comment #2)
> What exact transformation do you want? Canonicalize the constant C to
> something like C % (1 << (bitsize - N))?
I'm thinking (C << N) >>> N where '>>>' is sig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91975
Bug ID: 91975
Summary: worse code for small array copy using pointer
arithmetic than array indexing
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91976
Bug ID: 91976
Summary: [10 regression] RTL check: expected code 'const_int',
have 'reg' in emit_block_move_hints, at expr.c:1627
Product: gcc
Version: 10.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91976
--- Comment #1 from Dmitry G. Dyachenko ---
FAIL: configure --enable-checking=yes,rtl --enable-languages=c,c++,lto
--disable-multilib
PASS: configure --enable-checking=yes --enable-languages=c,c++,lto
--disable-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91974
--- Comment #3 from Andrew Pinski ---
Just to make sure, you are using -std=c++17 or -std=gnu++17 (or
-fstrong-eval-order)? Because it is not obvious from this report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91976
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #18 from joseph at codesourcery dot com ---
No, --with-build-time-tools definitely should not override newly built
tools.
For example, in some bootstrap configurations you have to build GCC more
than once. If you're also installin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91976
--- Comment #3 from Jakub Jelinek ---
I think
--- gcc/expr.c.jj 2019-10-02 16:35:20.977451346 +0200
+++ gcc/expr.c 2019-10-02 21:47:54.900724874 +0200
@@ -1624,16 +1624,18 @@ emit_block_move_hints (rtx x, rtx y, rtx
set_mem_size (y,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #4 from joseph at codesourcery dot com ---
The libgcc2.c functions for conversions that get used by default on most
architectures should respect the rounding mode if the underlying
single-word-to-floating-point instruction does so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #19 from Stas Sergeev ---
OK, but the setup when you want to override
the newly-built gcc, is also needed. Like, when
you want to build the "destdir" gcc with the one
installed directly into prefix (and therefore
working fine on host)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Joseph S. Myers from comment #1)
> This is not a bug in GCC, it's how the preprocessor is defined to work.
So, this is an user error? is there any C language rules on this?
why icc wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #20 from joseph at codesourcery dot com ---
The only case where the newly built GCC should be overridden is the
Canadian cross case, and while that does use a pre-installed tool from the
PATH, it's best to use "make all-host" in tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
--- Comment #3 from joseph at codesourcery dot com ---
Macro replacement for function-like macros is defined in C17 6.10.3.
Note in paragraph 10 the words "the function-like macro name followed by a
( as the next preprocessing token". In your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91087
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179
--- Comment #18 from Iain Sandoe ---
I'm testing regularly on macOS 10.14 (darwin18) - which I assume is the version
you meant?
Also on 8.3 and 9.2 .. (the results are posted to @testresults).
There was a PCH fixed (but that only manifested wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #14 from Iain Sandoe ---
other than the desire to locate /usr/local/include in some automatic way, is
this still a current issue?
I've built (with the workaround for missing __has_x()) on 10.14 using the
10.15 XC11.0 command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82920
Iain Sandoe changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27221
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 123 matches
Mail list logo