http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398
--- Comment #8 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
How can I set this PR to FIXED?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30962
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30962action=edit
for a possible fix
comments?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Eric Botcazou from comment #5)
I think we just want to copy the following from
nonoverlapping_component_refs_p:
/* If we're left with accessing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Eric,
there is one more thing to consider for your proposed patch,
that is the damned -fstrict-volatile-bitfields:
if strict_volatile_bitfields0 and the BIT_FIELD access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #11 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Eric Botcazou from comment #10)
there is one more thing to consider for your proposed patch,
that is the damned -fstrict-volatile-bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
--- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Sriraman Tallam from comment #3)
Hmm...
This bug seems to be connected to PR57756.
A lot of __attribute__((target(..))) get parsed,
before this error occurs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508
--- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Cong Hou from comment #5)
I guess I should add
/* { dg-require-effective-target vect_int } */
to the test case. It is right?
Yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
--- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 31136
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31136action=edit
reduced test case
apparently this is not yet fixed...
reduced test case attached.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
--- Comment #8 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 31137
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31137action=edit
untested patch
targetm.set_current_function modifies this_fn_optabs-pat_enable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58964
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58964
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 31140
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31140action=edit
For a possible fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #6)
That doesn't look safe, negative rbitpos is not necessarily undefined
behavior.
Can't you get the same with say
struct S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #10 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
but this should'nt be neccessary then?
if (bitoffset *bitpos)
{
HOST_WIDE_INT adjust = bitoffset - *bitpos;
-
gcc_assert ((adjust % BITS_PER_UNIT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #11)
(In reply to Bernd Edlinger from comment #10)
but this should'nt be neccessary then?
if (bitoffset *bitpos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #14 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #13)
(In reply to Bernd Edlinger from comment #12)
I meant the change here is not necessary, because after the
if (*bitpos 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #15 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Bernd Edlinger from comment #14)
(In reply to Jakub Jelinek from comment #13)
(In reply to Bernd Edlinger from comment #12)
I meant the change here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #17 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
struct T {
unsigned char b : 8;
unsigned char s : 1;
};
struct S {
char x;
struct T t[1];
};
void function(int x, struct S *p)
{
if (x == -1)
p-t[x].s = 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #18 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Well, how about this version?
Does'nt it look like a much smaller change?
--- expr.c.jj2013-10-31 14:57:05.0 +0100
+++ expr.c2013-11-04 12:51:55.013931114
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #23 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
hmm...
all examples I can see, where bitpos is negative,
or less than the representative's bitoffset with offset=NULL,
are just blandtly invalid.
The only valid example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
Attachment #31145|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #26 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #25)
(In reply to Bernd Edlinger from comment #24)
Created attachment 31169 [details]
Another (better) attempt at fixing this ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38077
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #44 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Hi Richard,
this 59143 issue is very similar to what Sandra encountered with her patch.
but it is not volatile in that example.
I can not reproduce that on the ARM.
But I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #46 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Note:
a) the patch will should be OK for 4.8 but not for 4.7.
b) the read-side does not ICE but will likely generate invalid code.
= a patch for the read-side is sill pending
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #50 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Paulo J. Matos from comment #49)
I noticed that enabling misaligned moves have created a few test failures on
my port. Namely: execute.exp=20051113-1.c
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
,.,. C52102A ACATS 2.5 13-11-30 19:14:40^M
C52102A CHECK THAT THE ASSIGNMENT OF OVERLAPPING SOURCE AND TARGET ^M
VARIABLES (INCLUDING ARRAYS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 31485
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31485action=edit
change code generation for simple DO-loops
This not yet fully tested patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #12)
But you can always create testcases (in C/C++ etc.) that will hit this
warning, so while the FE change is possible, we need
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Almost all cilk-plus execution tests fail due to invalid instruction
on PENTIUM2.
Core was generated by `./fib.exe'.
Program terminated with signal 4, Illegal instruction.
#0 0x0036237a
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de
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
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
Attachment #29465|0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
Attachment #29506|0
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
--- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
--- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de
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
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
Attachment #29724|0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de
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=56341
--- Comment #11 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30248
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30248action=edit
another example of the alignment faults
Hello Sandra,
good that you continue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
++
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=30349action=edit
Proposed fix for this problem
Hello,
I want to compile the gcc-4.8.1 in a freestanding environment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691
--- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #10 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
: 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=30410action=edit
Proposed patch to fix this defect.
usually this code is not used, but if the define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30431
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30431action=edit
another example of wrong compilation
This is another example where
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #15 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57837
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Ramana Radhakrishnan from comment #1)
mine.
fixed with revision 201240 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #8 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
: 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=58041
--- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30579
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30579action=edit
test case to show the bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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 #13 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #16 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #14 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
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=58065
--- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30598
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30598action=edit
test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30599
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30599action=edit
compiler output without this patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30600
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30600action=edit
correct compiler output with patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30601
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30601action=edit
Proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #16 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
: 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 -O3 -fno-omit-frame-pointer instead.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #27 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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 #30 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #33 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #34 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #36 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #37 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #39 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00350.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #10 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #11 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
hmm, this test compiles correctly if -msse2 is used.
gcc -O2 -msse2 -mno-avx -S intrinsics_4.c
: 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':
intrinsics_4.c:15:1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
--- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58111
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58105
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
Target||i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58105
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
OK, this seems seems to be a possible fix:
--- i386.c.jj 2013-07-23 17:56:37.0 +0200
+++ i386.c 2013-08-11 01:41:38.0 +0200
@@ -29830,7 +29830,7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
--- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30639
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30639action=edit
possible fix
This seems to be a bug in the constant folding of constant
vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58105
--- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00770.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58105
--- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Sorry to bother you...
With Richard's E-mail today he approved this patch.
Could you as i386-port maintainer please do the check-in for me?
Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
--- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Summary:
tree-ssa-loop-im.c moves code, out of an if statement inside the loop
it it can not cause side effects or faults, but it does not care of integer
overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
--- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
OK, a slightly improved patch was posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01099.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC
1 - 100 of 947 matches
Mail list logo
