https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #14 from Ulrich Weigand ---
(In reply to Georg-Johann Lay from comment #13)
> Also I don't have a test case for your scenario. I can reproduce the bug
> back to v5 on avr and maybe it is even older. As it appears, this PR lead
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #9 from Ulrich Weigand ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Ulrich Weigand from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > What is done on other arches?
> >
> > That depends on the pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #8 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #5)
> Though, relying on DW_OP_entry_value is not reliable, if e.g. tail calls are
> (or could be) involved, then GDB needs to punt.
The only way a tail call could h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #4 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #3)
> What is done on other arches?
That depends on the platform ABI. On some arches, including x86/x86_64 and
arm/aarch64, the ABI requires the generated code relo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #22 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #15)
> PowerPC I think does, not sure about s390.
For s390x see here:
https://github.com/IBM/s390x-abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970
--- Comment #2 from Ulrich Weigand ---
The patch did not handle flag_excess_precision correctly. I've reverted for
now and will look into a proper fix. Sorry for the breakage.
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
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=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
--
|--- |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=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
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.
-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
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=82960
Ulrich Weigand changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82960
--- Comment #5 from Ulrich Weigand ---
Author: uweigand
Date: Fri Dec 8 11:33:09 2017
New Revision: 255508
URL: https://gcc.gnu.org/viewcvs?rev=255508&root=gcc&view=rev
Log:
gcc/
PR target/82960
* config/spu/spu.c (pad_bb): Onl
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
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=79341
--- Comment #60 from Ulrich Weigand ---
... well, as Florian said as well :-)
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 #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 #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
: 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=77359
--- Comment #19 from Ulrich Weigand ---
I've been looking into this a bit with Dominik, and here's what I understand of
the problem so far:
- It really all starts with emit-rtl.c:init_emit doing:
REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
--- 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
gcc dot
gnu.org
--- Comment #3 from Ulrich Weigand ---
Patch posted.
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
: 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=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
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
,
||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=69464
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759
--- Comment #6 from Ulrich Weigand ---
FYI, two patches to fix this issue have just been committed to powerpc-next:
https://git.kernel.org/powerpc/c/2e50c4bef77511b42cc226865d
https://git.kernel.org/powerpc/c/a61674bdfc7c2bf909c4010699
||2015-12-07
CC||amodra at gcc dot gnu.org,
||dje.gcc at gmail dot com
Assignee|unassigned at gcc dot gnu.org |uweigand at gcc dot
gnu.org
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759
--- Comment #1 from Ulrich Weigand ---
I've tried to reproduce this, but with no success so far. This is primarily
because I cannot manage to get a current mainline Linux kernel built with
allyesconfig for powerpc64le in the first place (various
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
--- Comment #14 from Ulrich Weigand ---
Building the following reduced test case with
-O2 -ftree-vectorize -fcx-fortran-rules
with an spu-elf cross-cc1 shows the ICE.
void
test (_Complex float *dest,
_Complex float scale, int count)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
Ulrich Weigand changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062
--- Comment #8 from Ulrich Weigand ---
(In reply to Richard Biener from comment #7)
> I think there was some inconsistencies in C vs. C++ FEs in this area (but as
> usual I don't remember exactly but I remember Uli complaining about it again
> at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68231
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
--- Comment #6 from Ulrich Weigand ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> Testing a patch. It involves tightening the mode of the rtx returned
> by rtl_for_decl_location, as well as new asserts, so some fallout is
> likely...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
--- Comment #1 from Ulrich Weigand ---
A bit of debugging shows that what's going on here is this:
add_const_value_attribute is called with the following constant RTL:
(const_wide_int 0x8000)
The routine then does:
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: uweigand at gcc dot gnu.org
Target Milestone: ---
Compiling the following test case:
__uint128_t test(void)
{
static const __uint128_t two127 = ((__uint128_t) 1) << 127;
return two127;
}
on x86_64-lin
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: uweigand at gcc dot gnu.org
CC: amodra at gcc dot gnu.org, bergner at gcc dot gnu.org,
meissner at gcc dot gnu.org
Target: powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |uweigand at gcc dot
gnu.org
--- Comment #14 from Ulrich Weigand ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
--- Comment #13 from Ulrich Weigand ---
Since this has been in mainline for two weeks without reported issues, and it
should in general be a safe change, I've backported the patch to 4.9 now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
--- Comment #12 from Ulrich Weigand ---
Author: uweigand
Date: Wed Dec 17 15:07:28 2014
New Revision: 218821
URL: https://gcc.gnu.org/viewcvs?rev=218821&root=gcc&view=rev
Log:
2014-12-17 Ulrich Weigand
Backport from mainline
2014-12-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160
--- Comment #4 from Ulrich Weigand ---
The ususal test in such scenarios involves reg_overlap_mentioned_p:
/* Nonzero if modifying X will affect IN. [...] */
int
reg_overlap_mentioned_p (const_rtx x, const_rtx in)
which also handles cases lik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
--- Comment #11 from Ulrich Weigand ---
Hi Nick,
I've checked this in to mainline now. I'd like to wait for a couple of days to
see if anything breaks before backporting ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
--- Comment #10 from Ulrich Weigand ---
Author: uweigand
Date: Wed Dec 3 21:59:10 2014
New Revision: 218335
URL: https://gcc.gnu.org/viewcvs?rev=218335&root=gcc&view=rev
Log:
PR rtl-optimization/64010
* reload.c (push_reload): Before re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
--- Comment #5 from Ulrich Weigand ---
Created attachment 34170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34170&action=edit
Do not clobber function argument registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115
--- Comment #8 from Ulrich Weigand ---
Author: uweigand
Date: Tue Dec 2 14:33:00 2014
New Revision: 218275
URL: https://gcc.gnu.org/viewcvs?rev=218275&root=gcc&view=rev
Log:
PR target/64115
* config/rs6000/rs6000.c (rs6000_delegitimize_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115
--- Comment #7 from Ulrich Weigand ---
Author: uweigand
Date: Tue Dec 2 14:30:47 2014
New Revision: 218274
URL: https://gcc.gnu.org/viewcvs?rev=218274&root=gcc&view=rev
Log:
PR target/64115
* config/rs6000/rs6000.c (rs6000_delegitimize_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115
--- Comment #6 from Ulrich Weigand ---
Author: uweigand
Date: Tue Dec 2 14:27:46 2014
New Revision: 218273
URL: https://gcc.gnu.org/viewcvs?rev=218273&root=gcc&view=rev
Log:
PR target/64115
* config/rs6000/rs6000.c (rs6000_delegitimize_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115
Ulrich Weigand changed:
What|Removed |Added
CC||dje.gcc at gmail dot com
--- Comment #3
||2014-12-01
Assignee|unassigned at gcc dot gnu.org |uweigand at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Ulrich Weigand ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63952
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63952
--- Comment #4 from Ulrich Weigand ---
Author: uweigand
Date: Fri Nov 21 15:33:27 2014
New Revision: 217929
URL: https://gcc.gnu.org/viewcvs?rev=217929&root=gcc&view=rev
Log:
PR rtl-optimization/63952
* optabs.c (prepare_cmp_insn): Do no
||uweigand at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |uweigand at gcc dot
gnu.org
--- Comment #3 from Ulrich Weigand ---
I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63748
--- Comment #6 from Ulrich Weigand ---
I guess I can see why there might be an abnormal edge starting at bb 3, or at
least, that the compiler might not be easily able to deduce that it isn't
necessary.
However, I do not understand why any of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63748
--- Comment #4 from Ulrich Weigand ---
(In reply to Andrew Pinski from comment #3)
> I think this is hard warning to avoid in the compiler as we don't know if
> foo calls longjmp or not. Note we don't know if alloc_jmp_buf does a push
> somewher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63748
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854
--- Comment #9 from Ulrich Weigand ---
I just noticed that this bug has disappeared on mainline. Binary search showed
that this happens with rev. 211007, which checks in this patch:
https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01263.html
which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61920
--- Comment #8 from Ulrich Weigand ---
Author: uweigand
Date: Mon Jul 28 14:33:20 2014
New Revision: 213128
URL: https://gcc.gnu.org/viewcvs?rev=213128&root=gcc&view=rev
Log:
PR libobjc/61920
* encoding.c (rs6000_special_adjust_field_ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61920
--- Comment #7 from Ulrich Weigand ---
Author: uweigand
Date: Mon Jul 28 14:32:13 2014
New Revision: 213127
URL: https://gcc.gnu.org/viewcvs?rev=213127&root=gcc&view=rev
Log:
PR libobjc/61920
* encoding.c (rs6000_special_adjust_field_ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61920
--- Comment #6 from Ulrich Weigand ---
Since we didn't backport the actual ABI change to the branches, only the
warning, I think it would be consistent to use something like this on the
branches:
#define rs6000_special_adjust_field_align_p(FIELD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
--- Comment #12 from Ulrich Weigand ---
(In reply to Sandra Loosemore from comment #9)
> I've been looking at this a little bit more.
>
> DWARF_FRAME_REGNUM is specifically documented to take a hard register number
> as its operand, so the asser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60870
--- Comment #5 from Ulrich Weigand ---
(In reply to Ian Lance Taylor from comment #4)
> I don't have a PPC system. Can you see if the attached patch to
> gcc/go/gofrontend/expressions.cc fixes the problem?
Yes, this makes bug296.go PASS again on
||2014-04-17
CC||uweigand at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Ulrich Weigand ---
Confirmed.
This commit seems to have reverted the effects of the bug fix here:
http://gcc.gnu.org/ml/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363
Ulrich Weigand changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
CC||uweigand at gcc dot gnu.org
--- Comment
-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=56184
Ulrich Weigand changed:
What|Removed |Added
CC||vmakarov 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||uweigand at gcc dot gnu.org
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=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=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=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=53729
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
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=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=53706
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
||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=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.)
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
||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
Bug #: 53636
Summary: SLP may create invalid unaligned memory accesses
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
P
1 - 100 of 177 matches
Mail list logo
