https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #17 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #16)
> Yes, after the problem occurred, I did a completely clean new build of gmp,
> mpfr, mpc, gcc (configured with ../configure --prefix=/usr/local/
> --with-gmp=/usr/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88758
--- Comment #5 from Martin Liška ---
What about this:
$ cat 11.i
void PreEvaluate(void);
int main() { PreEvaluate(); return 0; }
$ cat 22.i
cat 22.i
extern int a[];
int b;
int c;
void PreEvaluate(void) {
b = 0;
for (; b < 8; b++)
a[b]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752
Matthias Kretz changed:
What|Removed |Added
Attachment #45376|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #24 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, dongjianqiang2 at huawei dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> --- Comment #23 from John Dong ---
> diff -urp a/gcc/expr.c b/gcc/expr.c
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #19 from Richard Biener ---
(In reply to Richard Biener from comment #18)
> So for find_base_term to compute sth conservative we'd need to track
> RTX_SURELY_NON_POINTER (what RTX is surely _not_ based on a pointer
> and thus can be i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #18 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #14)
does the application use exceptions?
> This one is failing:
> gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o
> static_1.exe .libs/static_1.ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88204
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed Jan 9 09:37:34 2019
New Revision: 267757
URL: https://gcc.gnu.org/viewcvs?rev=267757&root=gcc&view=rev
Log:
PR libstdc++/88204 disable std::complex tests
The IBM128 long double for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88761
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88758
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #1 from Richard Biener ---
So LLVM unrolls 4 times while GCC (always) unrolls 8 times. The unrolled body
for GCC (x86_64 this time) is
.L4:
movl(%rdx), %ecx
vmovsd (%rax), %xmm8
addq$32, %rdx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
--- Comment #15 from Jakub Jelinek ---
Author: jakub
Date: Wed Jan 9 10:16:10 2019
New Revision: 267758
URL: https://gcc.gnu.org/viewcvs?rev=267758&root=gcc&view=rev
Log:
PR rtl-optimization/88331
* function.c (assign_stack_loca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #22 from Jonathan Wakely ---
Author: redi
Date: Wed Jan 9 10:17:10 2019
New Revision: 267759
URL: https://gcc.gnu.org/viewcvs?rev=267759&root=gcc&view=rev
Log:
PR libstdc++/87855 fix optional for types with non-trivial copy/move
Ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88756
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> For the user, it's somewhat confusing that this passes with warning when
> compiling as C++, and fails to execute when compiling as C.
> I wonder why we don't do t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88758
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Wed Jan 9 10:24:43 2019
New Revision: 267760
URL: https://gcc.gnu.org/viewcvs?rev=267760&root=gcc&view=rev
Log:
PR middle-end/88758
* tree.c (initializer_each_zero_or_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
Bug ID: 88766
Summary: [9 Regression] Rejects valid? C code since r259641
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88758
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Created attachment 45386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45386&action=edit
aarch64-llvm output with -Ofast -mcpu=cortex-a57
I'm attaching the full LLVM aarch64 output.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #19 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #18)
> (In reply to Jürgen Reuter from comment #14)
>
> does the application use exceptions?
No exceptions, only a poor man's C signal catcher.
>
> > /usr/local/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #3 from Richard Biener ---
(In reply to ktkachov from comment #2)
> Created attachment 45386 [details]
> aarch64-llvm output with -Ofast -mcpu=cortex-a57
>
> I'm attaching the full LLVM aarch64 output.
>
> The output you quoted is w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #20 from Jürgen Reuter ---
Created attachment 45387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45387&action=edit
DYLD_PRINT output non-working example
DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./static_1.exe >
non_workin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #21 from Jürgen Reuter ---
Created attachment 45388
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45388&action=edit
DYLD_PRINT output working example
DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./static_1.exe > working_output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
Bug ID: 88767
Summary: 'unroll and jam' not optimizing some loops
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #22 from Jürgen Reuter ---
This is the output from the lldb command (but this was not a debug build of gcc
yet):
$ lldb ./static_1.exe
(lldb) target create "./static_1.exe"
Current executable set to './static_1.exe' (x86_64).
(lldb) r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #20 from Richard Biener ---
For stage3/gcc/*.o statistics show we perform 21051052 base_alias_check calls
and in the end 706852 times it is the one that would have disambiguated
things compared to if we remove it (thus as if we do bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #21 from Richard Biener ---
Created attachment 45389
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45389&action=edit
statistic patch
patch I added to record statistics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #23 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #22)
> This is the output from the lldb command (but this was not a debug build of
> gcc yet):
> $ lldb ./static_1.exe
> (lldb) target create "./static_1.exe"
> Current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88204
--- Comment #3 from Jonathan Wakely ---
Fixed for GNU/Linux and AIX. Please reopen if it's still failing on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #24 from Richard Biener ---
(In reply to Iain Sandoe from comment #23)
> (In reply to Jürgen Reuter from comment #22)
> > This is the output from the lldb command (but this was not a debug build of
> > gcc yet):
> > $ lldb ./static_1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768
Bug ID: 88768
Summary: Derived type io in conjunction with allocatable
component and recursion fails
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #25 from Jürgen Reuter ---
(In reply to Richard Biener from comment #24)
> (In reply to Iain Sandoe from comment #23)
> > (In reply to Jürgen Reuter from comment #22)
>
> Indeed - somehow you didn't get a statically linked executabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684
--- Comment #8 from Martin Liška ---
I created upstream patch candidate:
https://reviews.llvm.org/D56485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #1 from Jakub Jelinek ---
Reduced testcase:
struct S { int s; };
void
foo (void)
{
void *p = &(struct S) { 0 };
void *q = &({ (struct S) { 0 }; });
}
The p initializer is accepted, q is rejected.
By my reading this is invalid,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #2 from Marius Messerschmidt ---
Sorry but I do not fully understand what you mean. Do you suggest using
different command line arguments?
So far I tried:
-fdump-tree-all
-fdump-tree-unswitch
and
-fopt-info-all-optall
But none of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88751
--- Comment #2 from Andreas Krebbel ---
(In reply to Richard Biener from comment #1)
...
> Would be interesting to know the sparseness of regs / BBs for your testcase
> at the point of LRA and whether compacting regs (do we ever do that?) might
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #22 from Richard Biener ---
Things we fail to disambiguate are
(mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0 S16 A8])
vs.
(mem/c:TF (plus:SI (reg/f:SI 19 frame)
(const_int -16 [0xfff0])) [1 S16 A128])
or
(mem:SI (pre_dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #25 from Wilco ---
(In reply to rguent...@suse.de from comment #17)
> On Tue, 8 Jan 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
> >
> > --- Comment #16 from Wilco ---
> > I think w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #29 from Sebastian Huber ---
Just for reference some numbers for GCC 7.4.0 and GCC 9.0.0 20190104:
sparc-rtems5-gcc --version
sparc-rtems5-gcc (GCC) 7.4.0 20181206 (RTEMS 5, RSB
ddba5372522da341fa20b2c75dfe966231cb6790, Newlib
df6915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #26 from Richard Biener ---
(In reply to Wilco from comment #25)
> (In reply to rguent...@suse.de from comment #17)
> > On Tue, 8 Jan 2019, wilco at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #27 from Wilco ---
(In reply to Eric Botcazou from comment #22)
> > Is it really pure RTL, therefore not used in tree? So the above patch using
> > BITS_BIG_ENDIAN for tree stuff would be incorrect to use it?
>
> I wouldn't say incor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88769
Bug ID: 88769
Summary: Call to sin() optimized away, disregarding possible
side-effect (errno)
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #26 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #25)
> (In reply to Richard Biener from comment #24)
> > (In reply to Iain Sandoe from comment #23)
> > > (In reply to Jürgen Reuter from comment #22)
>
> >
> > Indeed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88770
Bug ID: 88770
Summary: Redundant load opt. or CSE pessimizes code
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #28 from Richard Biener ---
(In reply to Wilco from comment #27)
> (In reply to Eric Botcazou from comment #22)
> > > Is it really pure RTL, therefore not used in tree? So the above patch
> > > using
> > > BITS_BIG_ENDIAN for tree st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #29 from Wilco ---
(In reply to Richard Biener from comment #26)
> Did anybody test the patch? Testing on x86_64 will be quite pointless...
Well that generates _18 = BIT_FIELD_REF <_2, 16, 14>; and becomes:
ubfxx1, x20, 2, 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #30 from Eric Botcazou ---
> That said, the docs also refer to 'bit-field instructions' but do not
> elaborate further -- I guess zero_extract is such but I'd have guessed
> BIT_FIELD_REF (on trees) is as well. But yes, RTL expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #4 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #3 from Marius Messerschmidt ---
Sorry but I do not fully understand what you mean. Do you suggest using
different command line arguments?
So far I tried:
-fdump-tree-all
-fdump-tree-unswitch
and
-fopt-info-all-optall
But none of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
--- Comment #3 from Michael Matz ---
I don't see anything to improve either (as far as unroll-and-jam is concerned).
It's quite possible that cunrolli is harming more than helping in this case,
but with it disabled it seems the code is as it shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #31 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, wilco at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> --- Comment #29 from Wilco ---
> (In reply to Richard Biener from comment #26)
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
--- Comment #4 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
>
> Bill Schmidt changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
--- Comment #5 from Bill Schmidt ---
From the original reporter:
Partially unrolling the outermost loop in the innermost loop body enables data
reuse for array A (see source) thereby improving the mem-ops/compute ratio and
providing the performa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #32 from Richard Biener ---
(In reply to rguent...@suse.de from comment #31)
> On Wed, 9 Jan 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
> >
> > --- Comment #29 from Wilco ---
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
--- Comment #6 from Bill Schmidt ---
Yes, we don't want to encourage disabling cunrolli by hand for production use.
This test case is interesting because it shows a tension between complete
unrolling of inner loops and classical HPC loop optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88770
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization, ra
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
--- Comment #7 from Bill Schmidt ---
(In reply to Michael Matz from comment #3)
> I don't see anything to improve either (as far as unroll-and-jam is
> concerned).
> It's quite possible that cunrolli is harming more than helping in this case,
> b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88769
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #5 from Wilco ---
(In reply to Wilco from comment #4)
> (In reply to ktkachov from comment #2)
> > Created attachment 45386 [details]
> > aarch64-llvm output with -Ofast -mcpu=cortex-a57
> >
> > I'm attaching the full LLVM aarch64 ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
--- Comment #8 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
>
> --- Comment #7 from Bill Schmidt ---
> (In reply to Michael Matz from comment #3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
Bug ID: 88771
Summary: [9 Regression] Misleading -Werror=array-bounds error
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2019-1-9
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #6 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, wilco at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
>
> --- Comment #5 from Wilco ---
> (In reply to Wilco from comment #4)
> > (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88769
--- Comment #2 from Per Zetterlund ---
The POSIX standard describes domain error conditions for sin() :
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sin.html .
I guess there is a discrepancy between the C standard and the POSIX stan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #2 from Martin Liška ---
Created attachment 45390
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45390&action=edit
original test-case
Original test that fails just with -m32:
$ gcc om-original.i -c -O2 -Werror=array-bounds -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #3 from Martin Liška ---
Original test-case started to produce the warning since r263662.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #7 from Wilco ---
(In reply to rguent...@suse.de from comment #6)
> On Wed, 9 Jan 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
> >
> > --- Comment #5 from Wilco ---
> > (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
Bug ID: 88772
Summary: Exception handling configured mode does not match the
one finally used
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #16 from Jakub Jelinek ---
The following patch does that. Guess the issues reported in this PR might go
away with that, but it is really just an attempt to fix inefficiency in the
generated code rather than fix the wrong-code issue w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #23 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Things we fail to disambiguate are
>
> (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0 S16 A8])
> vs.
> (mem/c:TF (plus:SI (reg/f:SI 19 frame)
> (const_int -16 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #14 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Jan 9 14:34:20 2019
New Revision: 267771
URL: https://gcc.gnu.org/viewcvs?rev=267771&root=gcc&view=rev
Log:
PR target/84010
* config/sparc/sparc.c (sparc_legitim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #33 from Wilco ---
(In reply to Richard Biener from comment #32)
> >
> > Index: gcc/expr.c
> > ===
> > --- gcc/expr.c (revision 267553)
> > +++ gcc/expr.c (working co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #15 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Jan 9 14:39:18 2019
New Revision: 267772
URL: https://gcc.gnu.org/viewcvs?rev=267772&root=gcc&view=rev
Log:
PR target/84010
* config/sparc/sparc.c (sparc_legitim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #16 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Jan 9 14:41:55 2019
New Revision: 267773
URL: https://gcc.gnu.org/viewcvs?rev=267773&root=gcc&view=rev
Log:
PR target/84010
* config/sparc/sparc.c (sparc_legitim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #17 from James Clarke ---
Ah, great, thanks, that's indeed a nicer way of writing the patterns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #19 from Eric Botcazou ---
> Ah, great, thanks, that's indeed a nicer way of writing the patterns.
You're welcome. Don't hesitate to ping next time I drop the ball for so long.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #20 from James Clarke ---
(In reply to Eric Botcazou from comment #19)
> > Ah, great, thanks, that's indeed a nicer way of writing the patterns.
>
> You're welcome. Don't hesitate to ping next time I drop the ball for so
> long.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88769
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80042
Eric Gallager changed:
What|Removed |Added
CC||per at pz dot se
--- Comment #6 from Eri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #30 from Gary Mills ---
A build of gcc-7 on SPARC just completed successfully with a much larger
configuration:
$
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure
CC=/usr/gcc/4.9/bin/gcc CX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #17 from Jakub Jelinek ---
Though, the more I look at it, the more I'm for reversion of the patch + deal
with it in the assign_stack_local caller that needs that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #18 from Jakub Jelinek ---
Created attachment 45391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45391&action=edit
gcc9-pr88450.patch
Untested patch that does that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #10 from Alexander Monakov ---
As discussed with Andrew offline, the real problem is creating a path where
stack pointer is decremented twice - that is really not supposed to happen (so
the issue could appear even in absence of REG_AR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88539
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #13 from Will Wray ---
Re-reviewing, I notice that the patch I posted in comment #9
now rejects nested empty-brace scalar init:
int i{{}};
which was previously accepted. So we'll need a decision on this too.
Clang rejects with -p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #4 from Martin Sebor ---
The warning is triggered by the excessive size argument in the strncpy call.
The excessive size makes the call invalid regardless of the values of the two
pointer arguments.
This happens both with the reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #5 from Martin Sebor ---
That said, the size range in the warning output is wrong. It should be just
4294967295. The warning should probably also be changed to -Wstringop-overflow
which diagnoses both out-of-bounds writes and reads.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #2 from joseph at codesourcery dot com ---
Yes, I think that (a) a statement expression is not an lvalue and (b) if
it were (or if the code were changed to move the unary '&' inside the
statement expression), the code would be takin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #4 from David Malcolm ---
(In reply to Marius Messerschmidt from comment #3)
> Sorry but I do not fully understand what you mean. Do you suggest using
> different command line arguments?
I believe Richard is referring to the internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
--- Comment #2 from Andoni ---
(In reply to Eric Botcazou from comment #1)
> What's the result of the configure check of libgcc for SJLJ? It should be
> visible in the config.log file in the libgcc build directory:
>
> whether the compiler is c
1 - 100 of 183 matches
Mail list logo
