https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #12 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #11)
> (In reply to Wilco from comment #8)
> > mov r4, r0
> > cmp r4, #0
>
> Why does it copy r0 to r4 and then compare r4? On more modern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #11 from Segher Boessenkool ---
(In reply to Wilco from comment #8)
> push{r4, lr}
> mov r4, r0
> cmp r4, #0
Why does it copy r0 to r4 and then compare r4? On more modern machines it
is faster to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #19 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #18)
> Hmm, so if we'd have numbered stmts in an EBB we could check the
> distance between set and use and not combine when that gets too big?
Yeah. Or we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #41 from Segher Boessenkool ---
Seeing that the code in your examples can be expressed as a bitfield insert
requires that combine sees that only the low 8 bits of reg 93 can be non-zero,
by the way. It usually does not know this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #40 from Segher Boessenkool ---
You'll get much better results if you don't use insv in your machine
description; writing it with the input and output separate (and then
using a "0" constraint) is much friendlier to the optimisers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
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=84382
--- Comment #6 from Steve Kargl ---
On Fri, Apr 05, 2019 at 11:15:30PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> We could add
>
> #define GFC_STD_OPT_GNU03 (GFC_STD_OPT_F03 | GFC_STD_GNU)
> #define GFC_STD_OPT_GNU08
PRE-LAUNCHPROMOTIONAL PRICE 10 Units
only !!!BUY BACK OPTION - 7 % GUARANTEE FOR 15 YEARS
Rental Guarantee condition:Special promotion 7% NET (subject to WHT) rental
guarantee -NO monthly fee-NO electricity-NO maintenance-NO sinking fundFor 15
years !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89993
Bug ID: 89993
Summary: Inconsistent incoming stack boundary
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
On Sat, 6 Apr 2019 at 02:55, Ville Voutilainen
wrote:
> Just in case that cast looks scary: the implicit conversion is also
> deep down in __visit_invoke, so
> we do actually require implicit convertibility as we are supposed to.
> If that's still too scary,
> we can just do
>
> - return
On Sat, 6 Apr 2019 at 02:48, Ville Voutilainen
wrote:
> and
>
> - return __do_visit(std::forward<_Visitor>(__visitor),
> - std::forward<_Variants>(__variants)...);
> + return (_Res)
> +__do_visit(std::forward<_Visitor>(__visitor),
> +
On Sat, 6 Apr 2019 at 02:19, Ville Voutilainen
wrote:
> And this patch fixes the existing visitation so that we don't
> over-eagerly cast to void. The main gist of it is
>
> -else if constexpr (is_same_v<_Result_type, void>)
> +else if constexpr (!__same_return_types &&
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89986
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On 4/5/19 12:21 PM, Marek Polacek wrote:
On Fri, Apr 05, 2019 at 10:45:59AM -0600, Martin Sebor wrote:
The change committed yesterday to handle the C++ 2a string literals
as non-type template arguments treats empty string initializers for
trailing pointer array elements as zero. That's of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968
--- Comment #4 from Martin Sebor ---
The alignment is respected for members of other types than char so the order of
the attributes doesn't seem to matter here (it does matter in pr89950):
$ cat pr89968-2.c && gcc -S -O2 -Wall
On Sat, 6 Apr 2019 at 01:55, Ville Voutilainen
wrote:
>
> On Fri, 5 Apr 2019 at 23:29, Jonathan Wakely wrote:
> >
> > On 05/04/19 19:06 +0100, Jonathan Wakely wrote:
> > > * doc/xml/manual/status_cxx2020.xml: Update status.
> > > * include/std/variant (visit): Define for C++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382
--- Comment #5 from Steve Kargl ---
On Fri, Apr 05, 2019 at 10:24:15AM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382
>
> --- Comment #4 from janus at gcc dot gnu.org ---
> (In reply to kargl from
On 4/5/19 4:02 PM, Jeff Law wrote:
On 4/5/19 3:37 PM, Martin Sebor wrote:
On 4/5/19 3:29 PM, Jeff Law wrote:
On 4/5/19 2:50 PM, Eric Botcazou wrote:
Say if the first bootstrap succeeds and I then change a single
GCC .c file and rerun make bootstrap, am I guaranteed to see
the same fallout of
On 05/04/2019 16:53, Andrea Corallo wrote:
>
> Richard Earnshaw (lists) writes:
>
>> On 29/03/2019 11:01, Andrea Corallo wrote:
>>> Hi all,
>>> simple patch addressing minor style issue into
>>> gcc/config/aarch64/cortex-a57-fma-steering.c.
>>>
>>> make BOOT_CFLAGS='-mcpu=cortex-a57' bootstrap
On Fri, 5 Apr 2019 at 23:29, Jonathan Wakely wrote:
>
> On 05/04/19 19:06 +0100, Jonathan Wakely wrote:
> > * doc/xml/manual/status_cxx2020.xml: Update status.
> > * include/std/variant (visit): Define for C++2a (P0655R1).
> > * testsuite/20_util/variant/visit_r.cc: New test.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
>From d95934a0f325e0934ada829378c3c0dfd6b3628c Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Fri, 5 Apr 2019 15:27:35 -0700
Subject: [PATCH] Replace direct PSTL uses of assert() with a macro
This also replaces calls to __TBB_ASSERT so that there are two macro
definitions provided by
Snapshot gcc-8-20190405 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190405/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
On 4/5/19 3:37 PM, Martin Sebor wrote:
> On 4/5/19 3:29 PM, Jeff Law wrote:
>> On 4/5/19 2:50 PM, Eric Botcazou wrote:
Say if the first bootstrap succeeds and I then change a single
GCC .c file and rerun make bootstrap, am I guaranteed to see
the same fallout of the change as I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Jeffrey A. Law changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89992
Bug ID: 89992
Summary: Vectorizer is very sensitive to function calls
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On 4/5/19 3:29 PM, Jeff Law wrote:
On 4/5/19 2:50 PM, Eric Botcazou wrote:
Say if the first bootstrap succeeds and I then change a single
GCC .c file and rerun make bootstrap, am I guaranteed to see
the same fallout of the change as I would if I did a pristine
build in a clean directory?
No,
On 4/5/19 2:50 PM, Eric Botcazou wrote:
>> Say if the first bootstrap succeeds and I then change a single
>> GCC .c file and rerun make bootstrap, am I guaranteed to see
>> the same fallout of the change as I would if I did a pristine
>> build in a clean directory?
>
> No, this would imply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145
Marek Polacek changed:
What|Removed |Added
Summary|[7/8/9 Regression] Implicit |[7/8 Regression] Implicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145
--- Comment #9 from Marek Polacek ---
Author: mpolacek
Date: Fri Apr 5 21:22:40 2019
New Revision: 270178
URL: https://gcc.gnu.org/viewcvs?rev=270178=gcc=rev
Log:
PR c++/87145 - bogus error converting class type in template arg list.
On 4/5/19 4:50 PM, Marek Polacek wrote:
On Fri, Apr 05, 2019 at 12:12:11AM -0400, Jason Merrill wrote:
On 4/4/19 5:18 PM, Marek Polacek wrote:
On Thu, Mar 28, 2019 at 03:54:30PM -0400, Jason Merrill wrote:
On 3/20/19 4:12 PM, Marek Polacek wrote:
The fix for 77656 caused us to call
On Fri, Apr 05, 2019 at 12:12:11AM -0400, Jason Merrill wrote:
> On 4/4/19 5:18 PM, Marek Polacek wrote:
> > On Thu, Mar 28, 2019 at 03:54:30PM -0400, Jason Merrill wrote:
> > > On 3/20/19 4:12 PM, Marek Polacek wrote:
> > > > The fix for 77656 caused us to call convert_nontype_argument even for
>
> Say if the first bootstrap succeeds and I then change a single
> GCC .c file and rerun make bootstrap, am I guaranteed to see
> the same fallout of the change as I would if I did a pristine
> build in a clean directory?
No, this would imply deleting the stage2 and stage3 compilers and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925
--- Comment #2 from Neil Carlson ---
Right, when I said it failed on 8, I had misunderstood my colleague; he had
only tried 9.
On 05/04/19 19:06 +0100, Jonathan Wakely wrote:
* doc/xml/manual/status_cxx2020.xml: Update status.
* include/std/variant (visit): Define for C++2a (P0655R1).
* testsuite/20_util/variant/visit_r.cc: New test.
This implementation is wrong, the conversions to R need to
On Fri, Apr 5, 2019 at 12:55 PM Martin Sebor wrote:
>
> Is it safe to rerun make bootstrap after changing GCC source?
>
> Say if the first bootstrap succeeds and I then change a single
> GCC .c file and rerun make bootstrap, am I guaranteed to see
> the same fallout of the change as I would if I
Is it safe to rerun make bootstrap after changing GCC source?
Say if the first bootstrap succeeds and I then change a single
GCC .c file and rerun make bootstrap, am I guaranteed to see
the same fallout of the change as I would if I did a pristine
build in a clean directory?
I have been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Component|bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #1 from t.sprodowski at web dot de ---
Created attachment 46095
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46095=edit
Source file
Source file to illustrate this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980
--- Comment #10 from Martin Sebor ---
Author: msebor
Date: Fri Apr 5 19:49:38 2019
New Revision: 270177
URL: https://gcc.gnu.org/viewcvs?rev=270177=gcc=rev
Log:
PR bootstrap/89980 - pointer initialization with empty string folded to zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
Bug ID: 89991
Summary: Complex numbers: Calculation of imaginary part is not
correct
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
On 4/5/19 7:11 AM, Paolo Carlini wrote:
Hi,
this error-recovery regressions is mostly another case - similar to
c++/89488 - where we want to check that maybe_instantiate_noexcept
actually succeeds before calling a function that asserts
!DEFERRED_NOEXCEPT_SPEC_P, nothrow_spec_p this time. I
On 4/5/19 2:25 PM, Martin Sebor wrote:
On 4/5/19 10:45 AM, Martin Sebor wrote:
The change committed yesterday to handle the C++ 2a string literals
as non-type template arguments treats empty string initializers for
trailing pointer array elements as zero. That's of course wrong
because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981
--- Comment #3 from Thomas Koenig ---
Reduced test case:
program main
call bar(i)
end program main
subroutine foo
entry bar(i)
end subroutine foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
Andrew Pinski changed:
What|Removed |Added
Depends on||88058
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
--- Comment #11 from tkoenig at netcologne dot de ---
Am 05.04.19 um 18:20 schrieb dominiq at lps dot ens.fr:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
>
> --- Comment #10 from Dominique d'Humieres ---
>> Testing the updated patch
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #4 from Tom Honermann ---
(In reply to Florian Weimer from comment #3)
> But the precedent with wchar_t is that the type of the format string
> determines the type of the %s arguments. I'm not sure if that's a good
> precedent, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
--- Comment #2 from Andrew Pinski ---
https://gcc.gnu.org/gcc-9/porting_to.html
-fsantizier=address is able to find these uses after escaping the scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
--- Comment #1 from Eric Blake ---
Other references to compound initializers going out of scope and causing
problems:
https://stackoverflow.com/questions/47691857/lifetime-of-a-compound-literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
Bug ID: 89990
Summary: request warning: Use of out of bound compound
initialised struct
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
On 4/5/19 10:45 AM, Martin Sebor wrote:
The change committed yesterday to handle the C++ 2a string literals
as non-type template arguments treats empty string initializers for
trailing pointer array elements as zero. That's of course wrong
because addresses of literals are non-zero.
The
On Fri, Apr 05, 2019 at 10:45:59AM -0600, Martin Sebor wrote:
> The change committed yesterday to handle the C++ 2a string literals
> as non-type template arguments treats empty string initializers for
> trailing pointer array elements as zero. That's of course wrong
> because addresses of
We still need to document PSTL in the libstdc++ manual, but this adds
it to the release notes.
Committed to CVS.
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.57
* doc/xml/manual/status_cxx2020.xml: Update status.
* include/std/variant (visit): Define for C++2a (P0655R1).
* testsuite/20_util/variant/visit_r.cc: New test.
Tested powerpc64le-linux, committed to trunk.
commit 60c01065cfdda4f93bd140b0ea37be16f537877c
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89989
Bug ID: 89989
Summary: missed devirtualization opportunity on final function
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On 03/04/19 17:25 +0100, Jonathan Wakely wrote:
Avoid creating arbitrarily large objects on the stack when creating
temporaries in order to provide the strong exception-safety guarantee.
Also implement Antony Polukhin's suggestion to whitelist specific types
that can be efficiently
PR libstdc++/89986
* config/abi/pre/gnu.ver: Add missing exports.
* testsuite/27_io/filesystem/iterators/directory_iterator.cc: Test
increment member.
Tested powerpc64le-linux, committed to trunk.
commit 0043393da0a00cfd04867ec63873ed42d0db23a7
Author: Jonathan
Implement the proposed resolution of LWG 2708 by moving the _M_options
and _M_pending members out of the recursive_directory_iterator into the
shared _Dir_stack object. Because _Dir_stack is an opaque type, the
member functions that access the _M_options and _M_pending variables
cannot be inline.
The equality operators for directory iterators are not explicitly
specified in the standard, they're only required to meet the iterator
requirements. This means we don't need to declare them at namespace
scope and can implement them as hidden friends.
Also add 'noexcept' to directory_iterator's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89986
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Fri Apr 5 16:56:27 2019
New Revision: 270174
URL: https://gcc.gnu.org/viewcvs?rev=270174=gcc=rev
Log:
PR libstdc++/89986 export directory_iterator::increment
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431
--- Comment #19 from Jonathan Wakely ---
Author: redi
Date: Fri Apr 5 16:56:09 2019
New Revision: 270170
URL: https://gcc.gnu.org/viewcvs?rev=270170=gcc=rev
Log:
PR libstdc++/87431 re-adjust never-valueless optimizations
Avoid creating
We need to handle DT_UNKNOWN earlier, not only during directory
recursion, so that the cached file_type value in the directory_entry
won't be used.
* src/c++17/fs_dir.cc (_Dir::advance(bool, error_code&)): Handle
d_type == DT_UNKNOWN immediately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89922
--- Comment #4 from Antony Polukhin ---
> Was the testcase just an artificial one or does it appear (in this
> isolated form!) in a real application/benchmark?
I was not investigating a particular benchmark or real world application at
first.
The standard says "If *this and p are the same object, has no effect."
Previously we ended up clearing the path.
* include/bits/fs_path.h (path::operator=(path&&)): Check for self
assignment.
* src/c++17/fs_path.cc (path::operator=(const path&)): Likewise.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #9 from Martin Sebor
The change committed yesterday to handle the C++ 2a string literals
as non-type template arguments treats empty string initializers for
trailing pointer array elements as zero. That's of course wrong
because addresses of literals are non-zero.
The attached tweak constrains the trimming of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980
Dominique d'Humieres changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89988
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89988
Bug ID: 89988
Summary: [9 regression] bootstrap build fails with segfault
starting with r270155
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980
--- Comment #7 from Andreas Schwab ---
It fails everywhere.
Hello,
On Fri, 5 Apr 2019, Jozef Lawrynowicz wrote:
> Some setjmp/longjmp tests[1] depend on the value of an auto set before setjmp
> to to be retained after returning from the longjmp. As I understand, this
> behaviour is actually undefined, according to the gccint manual.
>
> Section 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980
--- Comment #6 from H.J. Lu ---
(In reply to Martin Sebor from comment #5)
> Thanks for the small test case.
>
> The affected x86 targets are presumably limited to i386. My x86_64
> bootstrap was successful.
It also failed on x86-64 with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
--- Comment #10 from Dominique d'Humieres ---
> Testing the updated patch
The patch retested cleanly, but so far does not show a noticeable compilation
speed up (pr55585 being fixed since some time).
> Ugh, this looks like a very bad idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980
--- Comment #5 from Martin Sebor ---
Thanks for the small test case.
The affected x86 targets are presumably limited to i386. My x86_64 bootstrap
was successful.
On 2019-04-05 6:25 a.m., Richard Biener wrote:
> On Wed, 3 Apr 2019, nick wrote:
>
>>
>>
>> On 2019-04-03 7:30 a.m., Richard Biener wrote:
>>> On Mon, 1 Apr 2019, nick wrote:
>>>
On 2019-04-01 9:47 a.m., Richard Biener wrote:
> On Mon, 1 Apr 2019, nick wrote:
>
>>
Richard Earnshaw (lists) writes:
> On 29/03/2019 11:01, Andrea Corallo wrote:
>> Hi all,
>> simple patch addressing minor style issue into
>> gcc/config/aarch64/cortex-a57-fma-steering.c.
>>
>> make BOOT_CFLAGS='-mcpu=cortex-a57' bootstrap
>>
>> Okay for trunk?
>>
>> Bests
>> Andrea
>>
>>
>>
When not using -fdata-sections or when there is no containing name,
GCC falls back to a default section name. Because AIX uses XCOFF, it
always has generated it's own section (CSECT) names (based on the
filename) and not using the GCC defaults.
unicode.org icu code has elicited behavior from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
This patch fixes stray notes emitted by -Waddress-of-packed-member when
disabled via -w.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to trunk as r270169.
gcc/c-family/ChangeLog:
PR c/89985
* c-warn.c (check_address_or_pointer_of_packed_member): Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985
--- Comment #1 from David Malcolm ---
Author: dmalcolm
Date: Fri Apr 5 15:15:37 2019
New Revision: 270169
URL: https://gcc.gnu.org/viewcvs?rev=270169=gcc=rev
Log:
Guard notes for -Waddress-of-packed-member on warning emission (PR c/89985)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #16 from Christophe Lyon ---
Author: clyon
Date: Fri Apr 5 15:10:12 2019
New Revision: 270168
URL: https://gcc.gnu.org/viewcvs?rev=270168=gcc=rev
Log:
[testsuite] PR71598: Fix testcases again
2019-04-05 Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89973
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89973
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Fri Apr 5 14:56:53 2019
New Revision: 270166
URL: https://gcc.gnu.org/viewcvs?rev=270166=gcc=rev
Log:
PR c++/89973 - -Waddress-of-packed-member ICE with invalid conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89987
Bug ID: 89987
Summary: ICE on GCC trunk and GCC 8 on arm-none-linux-gnueabihf
target with “-O1” option
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #30 from 康 珊 ---
(In reply to Martin Liška from comment #29)
> > Thanks for your reminder. Currently I found there were 3 ways to solve the
> > issue.
> > 1.Remove “enable-lto” in configure and open “fno-strict-aliasing”.
> > 2.Add
Joern Rennecke writes:
> On Fri, 5 Apr 2019 at 11:07, Richard Sandiford
> wrote:
>
>
>> > 2019-04-04 Joern Rennecke
>> >
>> > * sched-deps.c (sched_macro_fuse_insns): Check return value of
>> > targetm.fixed_condition_code_regs.
>>
>> OK, thanks.
>
> Thanks for the review.
>
> Is
On Fri, 5 Apr 2019 at 11:07, Richard Sandiford
wrote:
> > 2019-04-04 Joern Rennecke
> >
> > * sched-deps.c (sched_macro_fuse_insns): Check return value of
> > targetm.fixed_condition_code_regs.
>
> OK, thanks.
Thanks for the review.
Is that OK restricted to delayed applying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #7 from Martin Liška ---
I take it base. Makes sense to behave exactly as for non-intermediate format
mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #6 from Martin Liška ---
(In reply to Cristian Morales Vega from comment #5)
> OK, trying to catch you here, from my gcc-8.3.1.
> So with gcc 9 "--intermediate-format" is gone and we now have
> "--json-format" (keeping the "-i"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #29 from Martin Liška ---
> Thanks for your reminder. Currently I found there were 3 ways to solve the
> issue.
> 1.Remove “enable-lto” in configure and open “fno-strict-aliasing”.
> 2.Add “__attribute__((noipa))” to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #5 from Cristian Morales Vega ---
OK, trying to catch you here, from my gcc-8.3.1.
So with gcc 9 "--intermediate-format" is gone and we now have "--json-format"
(keeping the "-i" version)?
The "--intermediate-format" documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89986
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89986
Bug ID: 89986
Summary: [9 Regression] missing export for
directory_iterator::increment
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: link-failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #28 from 康 珊 ---
(In reply to Martin Liška from comment #27)
> (In reply to 康 珊 from comment #26)
> > I found the previous build log is like "g++ -o
> > /builddir/build/BUILD/node-v10.15.3/out/Release/cctest -pthread -rdynamic
> >
}
]
},
{
"file": "auto/foo.h",
"functions": [
{
"blocks": 2,
"blocks_executed": 0,
"demangled_name": "foo",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985
Bug ID: 89985
Summary: [9 Regression] Stray notes from
OPT_Waddress_of_packed_member with -w
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #12 from H.J. Lu ---
(In reply to Martin Liška from comment #11)
> Agree with Nick, one should be able to have clones with specific AVX512
> flavors.
> I can prepare patch for it, only issues is the priority as I already
> mentioned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89984
Bug ID: 89984
Summary: Extra register move
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
1 - 100 of 180 matches
Mail list logo
