http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58105
Bernd Edlinger changed:
What|Removed |Added
Target||i686*-*-*
Component|c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58111
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
--- Comment #1 from Bernd Edlinger ---
Hi Sriraman,
I'm putting you on CC since you are the author of that test case:
I am not sure if the test case should use -msse2 instead of -msse,
but running on an assertion is certainly to be avoided in any
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target: i386-pc-linux-gnu
Build: gcc-4.9-20130728
this test case fails on i686-pc-linux with internal error.
intrinsics_4.c: In function 'foo':
intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #11 from Bernd Edlinger ---
hmm, this test compiles correctly if -msse2 is used.
gcc -O2 -msse2 -mno-avx -S intrinsics_4.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #10 from Bernd Edlinger ---
(In reply to Vladimir Makarov from comment #9)
so this test case has no chance to pass on a target without avx.
maybe this should be added to the test case then?
/* { dg-require-effective-target avx } */
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
the following test cases fail on i686-*:
g++.dg/ext/mv2.C
g++.dg/ext/mv5.C
g++.dg/ext/mv12.C
The code is OK on -O0, -O1, but fails on -O2 and -O3.
The problem seems to be that for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #7 from Bernd Edlinger ---
Patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00350.html
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 #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 #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 #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=58070
--- Comment #2 from Bernd Edlinger ---
(In reply to Andreas Schwab from comment #1)
> This is target dependent.
OK, my target is --target=arm-eabi
What exactly is target dependent?
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
ty: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
The -fomit-frame-pointer is now (since 4.6) the default at -O3.
Therefore I would suggest to change that to test
"-O3" and "-O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #16 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #15)
> Anyway, the policy of GCC
> seems to be that the default of MALLOC_ABI_ALIGNMENT is ultra-safe and
> targets should override it. So I would suggest, again :-),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #4 from Bernd Edlinger ---
Created attachment 30601
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30601&action=edit
Proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #3 from Bernd Edlinger ---
Created attachment 30600
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30600&action=edit
correct compiler output with patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #2 from Bernd Edlinger ---
Created attachment 30599
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30599&action=edit
compiler output without this patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #1 from Bernd Edlinger ---
Created attachment 30598
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30598&action=edit
test case
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target: arm*-*-*
the ARM target architecture does not define the MALLOC_ABI_ALIGNMENT,
therefore the default is used as BITS_PER_WORD, 32 in this case.
This produces sometimes suboptimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #14 from Bernd Edlinger ---
Martin,
Your patch is of course OK, but the MALLOC_ABI_ALIGNMENT is probably wrong too.
At least in targets with neon processor it should be raised to 64 bits.
If the malloc would really return 4 byte alig
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 #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 #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
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
the attached test case shows unaligned accesses can be generated
on arm architecture, despite the -mno-unaligned-access option.
This does not happen at -O0 and -Og,
but it always happens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #12 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #11)
>> Well, I believe this
>> unaligned arrays are generally broken.
>>
>> consider this example:
> With or
> without the patch? If without the patch and you are r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #8 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #7)
> In any event, it is clear that
> the code in expand_assignment cannot cope with unaligned tem and non-NULL
> offset. So currently I'm considering the following p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #6 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #5)
> expand_assignment, offset as filled in get_inner_reference is the same,
> however get_object_alignment (tem) used to return 64, and now only returns
> 32 which th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #7 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Bernd Edlinger from comment #5)
> > Well, if a portable O/S like eCos would need such special treatment,
>
> eCos doesn't need it
Of course. In t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #5 from Bernd Edlinger ---
Well, if a portable O/S like eCos would need such special treatment,
the NO_IMPLICIT_EXTERN_C should not be bound to the target architecture,
it would be far more appropriate to define the NO_IMPLICIT_EXTERN_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57837
--- Comment #2 from Bernd Edlinger ---
(In reply to Ramana Radhakrishnan from comment #1)
> mine.
fixed with revision 201240 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #15 from Bernd Edlinger ---
(In reply to Mikael Pettersson from comment #14)
> Your example is invalid C. Referring to WG14 n1494.pdf (there may be more
> recent C1x documents, but it's the one I had available right now):
>
> - you v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #13 from Bernd Edlinger ---
Created attachment 30431
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30431&action=edit
another example of wrong compilation
This is another example where the optimization can
go wrong.
The attached
: boehm-gc
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Created attachment 30410
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30410&action=edit
Proposed patch to fix this defect.
usually this code is not used, but if the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #10 from Bernd Edlinger ---
incredibly...
gcc 4.3.7 was the last version that did only write 5 bytes in foo().
starting with gcc 4.4 all variants read/write 8 bytes in foo().
that applies only to the arm code.
the x86 code does not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #9 from Bernd Edlinger ---
1. you should never touch memory that lies outside the struct.
2. if you have to generate multiple accesses you should generate
code as if "volatile" was not used at all.
3. if -mno-unaligned-access is give
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691
--- Comment #9 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Paolo Carlini from comment #4)
> > ... by the way, I'm *very* surprised that nobody noticed this over the
> > years: the freestanding atexit is dec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #7 from Bernd Edlinger ---
aehmm sorry, the object "g" from above code is actually from PR#48784
#pragma pack(1)
volatile struct S0 {
signed a : 7;
unsigned b : 28;
} g = {0,-1};
=> sizeof(g) = 5
but the code from this example
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Created attachment 30349
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30349&action=edit
Proposed fix for this problem
Hello,
I want to compile the gcc-4.8.1 in a frees
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #11 from Bernd Edlinger ---
Created attachment 30248
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30248&action=edit
another example of the alignment faults
Hello Sandra,
good that you continue to work on that bug again.
I agr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #9 from Bernd Edlinger
2013-03-27 10:36:48 UTC ---
Hello GCC-Maintainers,
what do you think? Should'nt this patch be in the 4.6.4 release?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
Bernd Edlinger changed:
What|Removed |Added
Attachment #29724|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
--- Comment #5 from Bernd Edlinger
2013-03-26 06:15:52 UTC ---
Created attachment 29724
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29724
backport of the above mentioned fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
--- Comment #4 from Bernd Edlinger
2013-03-26 06:13:55 UTC ---
(In reply to comment #2)
> Works for me with 4.7/4.8/4.9, and 4.5 and older, but fails with 4.6.
> The bug was fixed for 4.7.0 by r180700; that change has no BZ PR entry, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
Bug #: 56712
Summary: constuctor function is called twice
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
Bernd Edlinger changed:
What|Removed |Added
Attachment #29506|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
Bernd Edlinger changed:
What|Removed |Added
Attachment #29465|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #6 from Bernd Edlinger
2013-02-18 18:41:55 UTC ---
hhmm...
could some one give an example where packedp would be false but the value
is packed or unaligned?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #3 from Bernd Edlinger
2013-02-15 14:46:39 UTC ---
(In reply to comment #2)
> The test case causes alignment exceptions for me on armv5tel-linux-gnueabi,
> when compiled with any one of gcc 4.8, 4.7, or 4.6. Was Sandra's patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #1 from Bernd Edlinger
2013-02-15 13:12:56 UTC ---
Created attachment 29465
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29465
proposed patch
attached is a patch for gcc-4.6.3 that should resolve this issue.
volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
Bug #: 56341
Summary: GCC produces unaligned data access
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Pri
901 - 958 of 958 matches
Mail list logo
