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=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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
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
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=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
> >
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
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=91606
Richard Biener changed:
What|Removed |Added
Known to work||10.0
Summary|[9/10
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=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
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=gcc=rev
Log:
2019-10-02 Richard Biener
PR c++/91606
* decl.c
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=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
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=gcc=rev
Log:
PR c++/91222
* ipa-devirt.c (warn_types_mismatch): Fix conditional
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=gcc=rev
Log:
2019-10-02 Bernd Edlinger
Backport from mainline
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91606
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
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=gcc=rev
Log:
[LRA] Don't make eliminable registers live (PR91957)
One effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #1 from
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
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
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
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
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=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
Bug ID: 91963
Summary: Logical function does not simplify
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
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=91956
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
Target
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=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
Jonathan Wakely changed:
What|Removed |Added
CC||edlinger at gcc dot gnu.org
---
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=gcc=rev
Log:
PR tree-optimization/91940
* tree-vect-patterns.c: Include
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=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
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=91606
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=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=91947
Jonathan Wakely changed:
What|Removed |Added
Depends on||81091
--- Comment #2 from Jonathan
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
---
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=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=91966
Bug ID: 91966
Summary: pack expansion for Cartesian product breaks if
certain indirections are involved
Product: gcc
Version: unknown
Status: UNCONFIRMED
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=65438
Thomas Schwinge changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|cesar at
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
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
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 #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?
>
>
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:
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=91967
--- Comment #1 from bob wilkinson ---
Created attachment 46990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46990=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=gcc=rev
Log:
[PR testsuite/91842] Skip gcc.dg/ipa/ipa-sra-19.c on power
2019-10-02 Martin
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=edit
the fix
Attached is the patch that I think is correct.
It also seems to work properly, i.e. the full
build process
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=gcc=rev
Log:
ifcvt: improve cost estimation (PR 87047)
PR
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90839
Dmitrij Pochepko changed:
What|Removed |Added
CC||dpochepk at gmail dot com
---
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:
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=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=gcc=rev
Log:
2019-10-02 Steven G. Kargl
PR fortran/91942
* io.c
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=gcc=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=91963
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=gcc=rev
Log:
2019-10-02 Steven G. Kargl
PR fortran/91943
* match.c
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
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=gcc=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
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
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
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=91970
--- Comment #2 from Andreas Schwab ---
Don't you need #pragma STDC FENV_ACCESS?
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=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
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
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
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=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=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
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
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
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:
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=91087
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91974
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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:
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=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
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
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|---
1 - 100 of 124 matches
Mail list logo
