http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #41 from Bill Schmidt ---
Thanks, Martin!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #39 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #38)
>> (In reply to Bernd Edlinger from comment #37)
>> this version fixes the warning:
> And I confirm that it still tests the bug. If you want to commit
> it yours
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #38 from Martin Jambor ---
(In reply to Bernd Edlinger from comment #37)
> this version fixes the warning:
And I confirm that it still tests the bug. If you want to commit it
yourself, go ahead, otherwise let me now and I'll do it be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #37 from Bernd Edlinger ---
this version fixes the warning:
--- ../gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c 2013-08-02
20:59:38.0 +0200
+++ pr58041.c 2013-08-06 18:30:51.0 +0200
@@ -3,8 +3,6 @@
typed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #36 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #35)
> (In reply to Bernd Edlinger from comment #34)
> by the way the initializer
> of "struct s a = "
> seems to generate warnings at -Wall, because some
> brackets a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #35 from Martin Jambor ---
(In reply to Bernd Edlinger from comment #34)
> by the way the initializer of "struct s a = "
> seems to generate warnings at -Wall, because some brackets are missing:
>
> changed that to
> struct s a = {0,{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #34 from Bernd Edlinger ---
by the way the initializer of "struct s a = "
seems to generate warnings at -Wall, because some brackets are missing:
changed that to
struct s a = {0,{{0,0},{0,0}}};
but somehow I wonder what forced us to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #33 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #31)
> I can't reproduce this with the -m32 flag on my x86_64... do
> you still have the compiler built on an i686? If so, could you try and make
> function foo stati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #32 from Martin Jambor ---
Author: jamborm
Date: Tue Aug 6 15:08:59 2013
New Revision: 201530
URL: http://gcc.gnu.org/viewcvs?rev=201530&root=gcc&view=rev
Log:
2013-08-06 Martin Jambor
PR middle-end/58041
* gimple-ssa-str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #31 from Martin Jambor ---
(In reply to Bernd Edlinger from comment #30)
> Hi Martin,
>
> I have bootstrapped this patch for i686-pc-linux-gnu and have
> seen some "excess errors" in your test script:
>
> /home/ed/gnu/gcc-4.9-2013072
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #30 from Bernd Edlinger ---
Hi Martin,
I have bootstrapped this patch for i686-pc-linux-gnu and have
seen some "excess errors" in your test script:
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c: In
function 'fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Martin Jambor changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #28 from Martin Jambor ---
Thanks, for testing, I have submitted the patch for a review:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00224.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #27 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #24)
> Created attachment 30594 [details]
> Proposed patch
I think it would be safe to put my initial test case
under gcc/testsuite/gcc.target/arm/pr58041.c
It passe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #26 from Bill Schmidt ---
Martin's patch bootstrapped on powerpc64-unknown-linux-gnu with no new
regressions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #25 from Bill Schmidt ---
Yep, that's terrific. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Martin Jambor changed:
What|Removed |Added
Assignee|wschmidt at gcc dot gnu.org|jamborm at gcc dot
gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #23 from Bill Schmidt ---
(In reply to Eric Botcazou from comment #22)
> We should be very wary of generating unaligned accesses during optimization
> for targets that define SLOW_UNALIGNED_ACCESS. And note that most
> architectures s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #21 from Bill Schmidt ---
My only comment on the patch would be to please add commentary indicating why
the change is being made, and referencing this PR. Something along the lines
of:
/* Ensure the memory reference carries the min
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #20 from Bill Schmidt ---
After thinking it over some more, I think you are right, Martin. We should go
ahead with the optimization with the corrected alignment attached to the type.
Please go ahead with your patch. I will run a rou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #19 from Martin Jambor ---
(In reply to Bill Schmidt from comment #15)
> Bernd, Mikael, Martin: Could you please test this on your respective
> targets?
Well, "my target" is x86_64 but yes, it works.
(In reply to Bill Schmidt from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #18 from Mikael Pettersson ---
(In reply to Bill Schmidt from comment #15)
> Bernd, Mikael, Martin: Could you please test this on your respective
> targets?
This patch eliminates the misalignment faults for me on both ARMv5TE and SPA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #17 from Bill Schmidt ---
Excellent! Thanks for the confirmation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #16 from Bernd Edlinger ---
(In reply to Bill Schmidt from comment #15)
> Bernd, Mikael, Martin: Could you please test this on your respective
> targets?
Congatulations!
it works.
If I compile with -mno-unaligned-access all accesse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #15 from Bill Schmidt ---
Bernd, Mikael, Martin: Could you please test this on your respective targets?
Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #14 from Bill Schmidt ---
(In reply to Bernd Edlinger from comment #13)
> Hi,
>
> just one question, how about the -m[no-]unaligned-access option?
>
> If -munaligned-access had been given the code was almost right,
> I mean AFAIK ldr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #13 from Bernd Edlinger ---
Hi,
just one question, how about the -m[no-]unaligned-access option?
If -munaligned-access had been given the code was almost right,
I mean AFAIK ldr/str should be handled in hardware but ldmia generates
a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #12 from Bill Schmidt ---
...which apparently is not quite right, since the candidates still appear in
the table. Hm. But you get the idea -- do the check earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #11 from Bill Schmidt ---
Hi Martin,
Your assumptions are correct, but I'm not sure this is the best place to handle
it. It looks like what you are doing is replacing one already correct memory
reference with another, both of which w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #10 from Martin Jambor ---
Created attachment 30587
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30587&action=edit
x86_64-linux testcase
To prove the point, this is an x86_64-linux testcase. I will
bootstrap and test the patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #9 from Martin Jambor ---
More specifically, if I am correct assuming that the MEM_REF
replace_ref builds always accesses exactly the same memory as the
previous access *expr does (and only the address is computed better)
and that *exp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #8 from Martin Jambor ---
I believe that you need to set alignment of the type of MEM_REFs you
create in replace_ref along the lines it is done in
build_ref_for_offset in tree-sra.c.
I wonder whether STRICT_ALIGNMENT has really any me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #6 from Bill Schmidt ---
I'll investigate. It may be a day or two before I can get to it, but this is
pretty clearly my issue.
Thanks,
Bill
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #5 from Mikael Pettersson ---
I see the exact same failure pattern on sparc64-linux: 4.7 generates working
code, 4.8 and 4.9 generate code that SIGBUS:es, failure starts with r190037,
-m32 or -m64 makes no difference.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Mikael Pettersson changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #2 from Bernd Edlinger ---
Sandra,
this seems to be unrelated to your strict-volatile-bitfields patch,
as it happens with or without that patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #1 from Bernd Edlinger ---
Created attachment 30579
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30579&action=edit
test case to show the bug
41 matches
Mail list logo
