https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846
--- Comment #8 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Wed Sep 10 04:45:32 2014
New Revision: 215101
URL: https://gcc.gnu.org/viewcvs?rev=215101root=gccview=rev
Log:
2014-09-10 Tony Wang tony.w...@arm.com
libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103
--- Comment #5 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Thu Aug 14 06:16:56 2014
New Revision: 213941
URL: https://gcc.gnu.org/viewcvs?rev=213941root=gccview=rev
Log:
2014-08-14 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103
--- Comment #4 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Wed Aug 13 09:37:41 2014
New Revision: 213899
URL: https://gcc.gnu.org/viewcvs?rev=213899root=gccview=rev
Log:
2014-08-13 Thomas Preud'homme thomas.preudho...@arm.com
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
Folding of bitfield in a union is incorrect on big endian targets. Consider the
testcase given in attachment, u.b would be folded to 0x45678 instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103
thopre01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103
--- Comment #2 from thopre01 at gcc dot gnu.org ---
I forgot to mention the flag to use: -O1 and whatever flag is necessary to
select a big endian target (for instance -mbig-endian if the target is arm
little endian by default).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103
--- Comment #3 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Tue Aug 12 02:36:37 2014
New Revision: 213846
URL: https://gcc.gnu.org/viewcvs?rev=213846root=gccview=rev
Log:
2014-08-12 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60070
thopre01 at gcc dot gnu.org changed:
What|Removed |Added
CC||thopre01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61375
--- Comment #2 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Fri Aug 1 08:56:17 2014
New Revision: 213426
URL: https://gcc.gnu.org/viewcvs?rev=213426root=gccview=rev
Log:
2014-08-01 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61375
--- Comment #3 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Fri Aug 1 09:46:47 2014
New Revision: 213436
URL: https://gcc.gnu.org/viewcvs?rev=213436root=gccview=rev
Log:
2014-08-01 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #49 from thopre01 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #48)
From what Thomas says in comment #46 it looks like for some unknown
reason a HI load from a 1-byte aligned address is emitted:
Yep that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #52 from thopre01 at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #51)
TARGET_MEM_REF is supposed to be a valid memory access for the target though
and, by definition, an unaligned access is not valid for a strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #53 from thopre01 at gcc dot gnu.org ---
(In reply to thopre01 from comment #52)
(In reply to Eric Botcazou from comment #51)
TARGET_MEM_REF is supposed to be a valid memory access for the target though
and, by definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306
--- Comment #11 from thopre01 at gcc dot gnu.org ---
Confirmed. This is because the compiler will detect that the result of (a 8)
depends on the sign of a and thus prevent the optimization. Before this check
incorrect code could be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #46 from thopre01 at gcc dot gnu.org ---
After expand, the newly created 16bit big endian load becomes:
(insn 688 687 689 (set (reg:HI 482)
(mem:HI (reg/v/f:SI 189 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2
A8])) /vol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61517
thopre01 at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306
--- Comment #8 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Mon Jun 30 01:58:45 2014
New Revision: 212133
URL: https://gcc.gnu.org/viewcvs?rev=212133root=gccview=rev
Log:
2014-06-30 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306
--- Comment #9 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Mon Jun 30 02:11:21 2014
New Revision: 212134
URL: https://gcc.gnu.org/viewcvs?rev=212134root=gccview=rev
Log:
2014-06-30 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #45 from thopre01 at gcc dot gnu.org ---
I only looked at differences in bswap so far and it all looks ok. It correctly
detects three patterns of 16bit big endian load and replace them by 16bit
unsigned loads and cast the results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #43 from thopre01 at gcc dot gnu.org ---
Thanks. In the stage before the one that fails, could you add
-fdump-tree-all-details -fdump-rtl-all-details to the command line when
compiling that jcf-parse.c file and send me an archive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559
thopre01 at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61517
--- Comment #3 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Wed Jun 18 10:43:50 2014
New Revision: 211778
URL: https://gcc.gnu.org/viewcvs?rev=211778root=gccview=rev
Log:
2014-06-18 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #40 from thopre01 at gcc dot gnu.org ---
Alright, change commited (r211778). Can you try another bootstrap with trunk to
see if your Bus error was this bug or another one still?
Thanks a lot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61517
--- Comment #2 from thopre01 at gcc dot gnu.org ---
I already got a patch for that which is currently under test. I checked against
this particular testcase and it indeed solves the problem. I'll add the
testcase to the patch and hopefully post
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61375
--- Comment #1 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Fri Jun 13 03:17:02 2014
New Revision: 211604
URL: http://gcc.gnu.org/viewcvs?rev=211604root=gccview=rev
Log:
2014-06-13 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #38 from thopre01 at gcc dot gnu.org ---
I've just wrote a patch that solve a bug that can lead to the kind of issue you
are running into. I'm doing more testing right now and will let you know when
it's commited if you don't mind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306
--- Comment #6 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Wed Jun 11 10:04:33 2014
New Revision: 211444
URL: http://gcc.gnu.org/viewcvs?rev=211444root=gccview=rev
Log:
2014-06-11 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306
thopre01 at gcc dot gnu.org changed:
What|Removed |Added
Known to work|4.9.0 |4.10.0
Known to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #35 from thopre01 at gcc dot gnu.org ---
Now that PR61306 and the bswap-2 test issue are fixed in trunk, could you try
again a bootstrap without any of the patch you applied locally? I would like to
see if this bug is a duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61328
--- Comment #5 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Tue Jun 3 09:29:06 2014
New Revision: 211166
URL: http://gcc.gnu.org/viewcvs?rev=211166root=gccview=rev
Log:
2014-06-03 Thomas Preud'homme thomas.preudho...@arm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54733
--- Comment #3 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Fri May 23 03:33:28 2014
New Revision: 210843
URL: http://gcc.gnu.org/viewcvs?rev=210843root=gccview=rev
Log:
2014-05-23 Thomas Preud'homme thomas.preudho...@arm.com
401 - 431 of 431 matches
Mail list logo
