https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96559
--- Comment #1 from Ulrich Weigand ---
> [...] as __clzdi2 points to the very same place as _Z11CeilingLog2v.
How do you get to that conclusion? Nothing in that assembler source sets
__clzdi2 to point to the same place as _Z11CeilingLog2v. The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184
--- Comment #5 from Ulrich Weigand 2013-02-06
19:27:31 UTC ---
Depending on configure tests of the installed (cross-)assembler, the ICE may
not occur. In those cases, I'm now able to reliably reproduce the ICE by using
-fno-section-anchor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184
Ulrich Weigand changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49443
--- Comment #7 from Ulrich Weigand 2012-08-10
13:26:51 UTC ---
Author: uweigand
Date: Fri Aug 10 13:26:44 2012
New Revision: 190296
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190296
Log:
ChangeLog:
Backport from mainline
2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54739
--- Comment #3 from Ulrich Weigand 2012-10-01
12:16:53 UTC ---
It seems all three of those targets have an "iordi3" pattern that triggers even
for 32-bit compiles. In this case, the lower-subreg pass now no longer splits
the register, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54957
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47179
Summary: [4.5/4.6 Regression] SPU: errno misoptimization around
malloc call
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
.*,
|sparc-sun-solaris2.*, |sparc-sun-solaris2.*,
|alpha-dec-osf5.1b, |alpha-dec-osf5.1b,
|mips-sgi-irix6.5|mips-sgi-irix6.5, spu-elf
CC||uweigand at gcc dot gnu.org
--- Comment #4 from Ulrich
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47299
Summary: Widening multiply optimization generates bad code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47179
--- Comment #4 from Ulrich Weigand 2011-01-18
20:13:59 UTC ---
Author: uweigand
Date: Tue Jan 18 20:13:56 2011
New Revision: 168961
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168961
Log:
PR tree-optimization/47179
* config/spu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47179
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46021
--- Comment #6 from Ulrich Weigand 2011-01-19
12:56:19 UTC ---
Author: uweigand
Date: Wed Jan 19 12:56:16 2011
New Revision: 168990
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168990
Log:
PR tree-optimization/46021
* gcc.dg/tre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45342
--- Comment #3 from Ulrich Weigand 2011-01-19
13:09:56 UTC ---
Author: uweigand
Date: Wed Jan 19 13:09:51 2011
New Revision: 168992
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168992
Log:
PR testsuite/45342
* gcc.dg/tls/thr-cse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47401
Summary: Support for must-not-throw regions with SJLJ
exceptions broken
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47401
--- Comment #1 from Ulrich Weigand 2011-01-21
16:33:43 UTC ---
Created attachment 23064
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23064
Proposed fix
Patch from http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01406.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47401
Ulrich Weigand changed:
What|Removed |Added
Attachment #23064|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47401
Ulrich Weigand changed:
What|Removed |Added
Attachment #23066|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47401
--- Comment #5 from Ulrich Weigand 2011-01-22
21:24:57 UTC ---
Author: uweigand
Date: Sat Jan 22 21:24:54 2011
New Revision: 169134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169134
Log:
PR middle-end/47401
* except.c (sjlj_as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47401
Ulrich Weigand changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47621
Summary: Missed dependencies in address-taken optimization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283
--- Comment #16 from Ulrich Weigand 2011-02-17
23:24:45 UTC ---
I tested the patch from comment #12 on spu-elf with no regressions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50305
Bug #: 50305
Summary: Inline asm reload failure when building Linux kernel
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-c
||2011-09-06
AssignedTo|unassigned at gcc dot |uweigand at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Ulrich Weigand 2011-09-06
17:06:45 UTC ---
Created attachment 25205
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50307
Bug #: 50307
Summary: SSA checking ICE when building Linux kernel
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50307
--- Comment #2 from Ulrich Weigand 2011-09-07
18:33:30 UTC ---
I've confirmed that this is a regression introduced by rev. 178386
http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg01405.html
So it does seem like this is another duplicate of PR 50287 / PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50305
--- Comment #3 from Ulrich Weigand 2011-10-06
11:50:35 UTC ---
Author: uweigand
Date: Thu Oct 6 11:50:26 2011
New Revision: 179603
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179603
Log:
gcc/
PR target/50305
* config/arm/a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50305
Ulrich Weigand changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50310
--- Comment #16 from Ulrich Weigand 2011-10-19
12:17:41 UTC ---
Author: uweigand
Date: Wed Oct 19 12:17:35 2011
New Revision: 180184
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180184
Log:
PR target/50310
* config/spu/spu.c (sp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #4 from Ulrich Weigand 2011-11-08
16:00:36 UTC ---
It seems to me (part of) the problem is that the operand constraint is too
generic here:
(define_insn "*lea_4_zext"
[(set (match_operand:DI 0 "register_operand" "=r")
(zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #8 from Ulrich Weigand 2011-11-09
18:52:16 UTC ---
(In reply to comment #7)
> Redefining "j" constraint as "define_address_constraint" results in:
Yes, it needs to be define_address_constraint.
> pr50762.c:48:1: error: unrecognizabl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #10 from Ulrich Weigand 2011-11-10
10:10:04 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
>
> > The zero_extend is a fixed part of the insn pattern in question:
> >
> > (define_insn "*lea_4_zext"
> > [(set (match_ope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #16 from Ulrich Weigand 2011-11-10
14:04:42 UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > Is this with your patch from comment 6? You really can't have a CONST_INT
> > inside a zero_extend; the abort is justified.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #21 from Ulrich Weigand 2011-11-10
18:22:50 UTC ---
(In reply to comment #20)
>
> The documentation is wrong, so following patch removes all the blurb about
> handling of constants.
>
> Index: doc/md.texi
> =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #24 from Ulrich Weigand 2011-11-11
13:04:02 UTC ---
(In reply to comment #22)
> Yeah, this is also what I thought at the first sight. But please don't forget
> that additional c-code test effectively creates
>
> (and (match_operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
--- Comment #3 from Ulrich Weigand 2012-05-04
12:46:14 UTC ---
Author: uweigand
Date: Fri May 4 12:46:04 2012
New Revision: 187158
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187158
Log:
gcc/
PR tree-optimization/52633
* t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
--- Comment #6 from Ulrich Weigand 2012-05-04
14:56:52 UTC ---
Author: uweigand
Date: Fri May 4 14:56:48 2012
New Revision: 187162
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187162
Log:
2012-05-04 Ulrich Weigand
Backport fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870
--- Comment #6 from Ulrich Weigand 2012-05-04
14:56:52 UTC ---
Author: uweigand
Date: Fri May 4 14:56:48 2012
New Revision: 187162
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187162
Log:
2012-05-04 Ulrich Weigand
Backport fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
Ulrich Weigand changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
--- Comment #2 from Ulrich Weigand 2012-05-04
16:03:35 UTC ---
Why do you consider this a reload/RA problem? Code before ira looks like:
(insn 2 4 3 2 (set (reg/v:DI 62 [ i ])
(mem/c:DI (reg/f:SI 16 argp) [2 i+0 S8 A32])) test.i:6 63
{*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
--- Comment #4 from Ulrich Weigand 2012-05-04
16:56:59 UTC ---
(In reply to comment #3)
> However, reload should notice that memory could be propagated into bswap.
Since register allocation already assigned a hard reg to the pseudo, reload is
ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44141
--- Comment #16 from Ulrich Weigand 2012-05-07
17:17:06 UTC ---
Reload inheritance generally gives up on handling subregs of pseudos, mostly
because there is no mechanism to track invalidation of parts of pseudos.
Now, in this particular case wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53636
Bug #: 53636
Summary: SLP may create invalid unaligned memory accesses
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
P
||2012-06-11
AssignedTo|unassigned at gcc dot |uweigand at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53636
--- Comment #1 from Ulrich Weigand 2012-06-15
13:30:40 UTC ---
Author: uweigand
Date: Fri Jun 15 13:30:36 2012
New Revision: 188661
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188661
Log:
gcc/
PR tree-optimization/53636
* t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53636
--- Comment #2 from Ulrich Weigand 2012-06-15
15:11:51 UTC ---
Now fixed on mainline; still fails on 4.7.
(While the bug is probably latent even earlier, this particular test case does
not crash on 4.6.)
||2012-06-20
AssignedTo|unassigned at gcc dot |uweigand at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Ulrich Weigand 2012-06-20
15:22:45 UTC ---
The problem is that SLP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53636
--- Comment #3 from Ulrich Weigand 2012-06-26
09:05:56 UTC ---
Author: uweigand
Date: Tue Jun 26 09:05:48 2012
New Revision: 188979
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188979
Log:
PR tree-optimization/53729
PR tree-opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53729
--- Comment #2 from Ulrich Weigand 2012-06-26
09:05:55 UTC ---
Author: uweigand
Date: Tue Jun 26 09:05:48 2012
New Revision: 188979
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188979
Log:
PR tree-optimization/53729
PR tree-opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53729
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854
--- Comment #2 from Ulrich Weigand 2012-07-04
17:17:22 UTC ---
The problem with this is that there was a reason why I originally supported
only a single constant pool reference per instruction: there needs to be an
upper bound on the number of by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52181
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52181
--- Comment #5 from Ulrich Weigand 2012-02-14
17:22:23 UTC ---
Thanks for the quick fix! Are you planning to backport to 4.6 as well?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52298
--- Comment #8 from Ulrich Weigand 2012-02-28
23:40:37 UTC ---
Author: uweigand
Date: Tue Feb 28 23:40:32 2012
New Revision: 184645
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184645
Log:
Partially revert:
2012-02-20 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52686
Bug #: 52686
Summary: SLP crashes with WIDEN_LSHIFT_EXPR
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52686
--- Comment #2 from Ulrich Weigand 2012-03-23
15:42:00 UTC ---
Created attachment 26968
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26968
Handle WIDEN_LSHIFT_EXPR in vect_get_smallest_scalar_type
The attached patch fixes the ICEs for me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52686
Ulrich Weigand changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
||2012-03-23
CC||uweigand at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |uweigand at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52686
--- Comment #3 from Ulrich Weigand 2012-03-26
13:13:14 UTC ---
Author: uweigand
Date: Mon Mar 26 13:13:07 2012
New Revision: 185795
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185795
Log:
gcc/
PR tree-optimization/52686
* t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52686
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870
Bug #: 52870
Summary: ICE during SLP pattern matching
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
||2012-04-04
AssignedTo|unassigned at gcc dot |uweigand at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Ulrich Weigand 2012-04-04
15:56:06 UTC ---
It seems the problem is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870
--- Comment #2 from Ulrich Weigand 2012-04-06
18:31:58 UTC ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00360.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #18 from Ulrich Weigand 2012-04-08
17:32:23 UTC ---
According to Vlad's comment #4, the validity check fails because a reload insn
contains a spilled pseudo that will later be replaced by a MEM.
However, recog.c contains in various p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870
--- Comment #3 from Ulrich Weigand 2012-04-10
10:56:17 UTC ---
Author: uweigand
Date: Tue Apr 10 10:56:11 2012
New Revision: 186272
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186272
Log:
gcc/
PR tree-optimization/52870
* t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #21 from Ulrich Weigand 2012-04-10
12:16:36 UTC ---
(In reply to comment #19)
> and the matching alternative would be (f, Q) with
>
> ;; Note that while this accepts mem, it only accepts non-volatile mem,
> ;; and so cannot be "fixe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51819
--- Comment #6 from Ulrich Weigand 2012-04-16
15:19:47 UTC ---
Author: uweigand
Date: Mon Apr 16 15:19:43 2012
New Revision: 186498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186498
Log:
2012-04-16 Ulrich Weigand
PR target/518
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
--- Comment #2 from Ulrich Weigand 2012-04-24
16:52:59 UTC ---
Some more details on what's going on here:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01486.html
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: uweigand at gcc dot gnu.org
Building the following test case (reduced from Python 2.7.5) with -O2 -g:
extern void *memmove (void *, const void *, __SIZE_TYPE__);
extern void *memset (void *, int, __SIZE_TYPE__);
typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
--- Comment #9 from Ulrich Weigand ---
Author: uweigand
Date: Fri Nov 15 23:39:50 2013
New Revision: 204870
URL: http://gcc.gnu.org/viewcvs?rev=204870&root=gcc&view=rev
Log:
gcc:
2013-11-15 Ulrich Weigand
Backport from mainline r201750.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363
Ulrich Weigand changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85075
--- Comment #3 from Ulrich Weigand ---
Maybe I'm confused, but: How does this even build?
_Float128 is a C-only extension, this type is not supposed to be available at
all in C++ mode as far as I know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69286
--- Comment #2 from Ulrich Weigand ---
Yes, it does appear I checked in this code, but the tpf-unwind.h changes were
actually provided by Jim Johnston on the IBM TPF team:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02104.html
In any case, fee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #64 from Ulrich Weigand ---
I'm seeing the same error on spu-elf when building newlib with GCC revision
255614. In case this isn't fixed by more recent changes already, here's a
reduced test case (build with -O -g):
const char *
tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86807
--- Comment #1 from Ulrich Weigand ---
Author: uweigand
Date: Mon Aug 6 14:40:56 2018
New Revision: 263335
URL: https://gcc.gnu.org/viewcvs?rev=263335&root=gcc&view=rev
Log:
[spu, commit] Define TARGET_HAVE_SPECULATION_SAFE_VALUE
The SPU proce
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |uweigand at gcc dot
gnu.org
--- Comment #2 from Ulrich Weigand ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86807, which changed state.
Bug 86807 Summary: spu port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86807
What|Removed |Added
--
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: uweigand at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Target: s390x-ibm-linux
Created attachment 43828
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43
,
||dje at gcc dot gnu.org,
||uweigand at gcc dot gnu.org
--- Comment #1 from Ulrich Weigand ---
Hmm. For some reason, the gnulib definition of LDBL_MAX differs from GCC's
definition. With gnulib, we get:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
--- Comment #4 from Ulrich Weigand ---
(In reply to Alan Modra from comment #3)
> > while with GCC, we get:
> >
> > high double: 7FEF
> > low double: 7C8F FFFE
>
> Right. This is 0x1.f78p+1023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
--- Comment #7 from Ulrich Weigand ---
Ah, OK. I did't realize this value didn't fit into a 106-bit mantissa.
I agree that it probably doesn't make sense to change the internal
representation to allow larger mantissas. First of all, there's no
: major
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: uweigand at gcc dot gnu.org
CC: amodra at gcc dot gnu.org, dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
--- Comment #1 from Ulrich Weigand ---
Created attachment 37925
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37925&action=edit
Patch to add retval vs. newval overlap check
This patch fixes the problem for me with the GCC 5 branch. Not f
gcc dot
gnu.org
--- Comment #3 from Ulrich Weigand ---
Patch posted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
--- Comment #4 from Ulrich Weigand ---
Author: uweigand
Date: Thu Mar 10 23:58:44 2016
New Revision: 234126
URL: https://gcc.gnu.org/viewcvs?rev=234126&root=gcc&view=rev
Log:
PR target/70168
* config/rs6000/rs6000.c (rs6000_expan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
--- Comment #5 from Ulrich Weigand ---
Author: uweigand
Date: Thu Mar 10 23:59:20 2016
New Revision: 234127
URL: https://gcc.gnu.org/viewcvs?rev=234127&root=gcc&view=rev
Log:
PR target/70168
* config/rs6000/rs6000.c (rs6000_expan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: uweigand at gcc dot gnu.org
Target Milestone: ---
Compiling the following test case with g++ -Os -fpic on s390x-ibm-linux results
in abort() being called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #22 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #21)
> Could libsanitizer call __tls_get_offset instead, after setting %r12 or
> whatever else is needed for it to make work and then perhaps adjust the
> result if n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #48 from Ulrich Weigand ---
s390(x) has -fasynchronous-unwind-tables on by default anyway, and .eh_frame
based DWARF unwinding is the only way to create stack backtraces that always
works.
However, I understood that asan deliberately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #59 from Ulrich Weigand ---
(In reply to Dominik Vogt from comment #57)
> libsanitizer miscalculates the Pcs in the backtrace:
>
> #0 0x1000839 in NullDeref
> #1 0x10006c1 in main
> #2 0x3fff6e23069 in __libc_start_main
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #60 from Ulrich Weigand ---
... well, as Florian said as well :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #71 from Ulrich Weigand ---
(In reply to Dominik Vogt from comment #70)
> If funny line information is the only consequence, no. Is it safe to assume
> that libsanitizer won't crash or produce garbege because of this?
Why should lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82960
--- Comment #3 from Ulrich Weigand ---
I'll have a look. I still need to get my SPU build environment back up and
running, the build currently fails due to unrelated issues.
I remember looking at this a few years back:
https://gcc.gnu.org/ml/g
1 - 100 of 177 matches
Mail list logo
