http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #9 from Bernd Edlinger ---
Created attachment 32065
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32065&action=edit
possible fix
well, I don't know if the Finalize method are supposed
to be called in a sequential manner, which G
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #8 from Bernd Edlinger ---
(In reply to Eric Botcazou from comment #7)
> > could it be that the Finalize procedure is missing some sort of spin lock?
>
> There are already explicit delays in the test, so very likely not.
I added the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60080
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094
--- Comment #3 from Bernd Edlinger ---
trunk revision 207409
Well, in this case, I'll repeat this test next week.(In reply to ktkachov from
comment #2)
> Bernd, which revision is this?
> I thought this would have been fixed with r207418
trunk re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094
Bernd Edlinger changed:
What|Removed |Added
Target||armv7l-unknown-linux-gnueab
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7em-thumb.c
-fno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60093
Bernd Edlinger changed:
What|Removed |Added
Target||armv7l-unknown-linux-gnueab
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #6 from Bernd Edlinger ---
Eric,
could it be that the Finalize procedure is missing some sort of spin lock?
ed@w-ed:~/gnu/gcc-build/gcc/testsuite/ada/acats/tests/c7/c761007$ cat
c761007_0.adb
-- -- -- -- -- -- -- -- -- -- -- -- --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #54 from Bernd Edlinger ---
(In reply to Marek Polacek from comment #53)
> So fixed on the trunk?
yes, fixed on trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #2 from Bernd Edlinger ---
it's a real hardware (Altera CyloneV SoC Eva-Board)
with dual core ARMv7
running linux and eglibc
: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
,.,. C761007 ACATS 2.5 14-02-05 11:14:25^M
C761007 Check that if a finalize procedure invoked by a transfer of^M
control or selection of a terminate alternative attempts^M
to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59985
--- Comment #13 from Bernd Edlinger ---
(In reply to Richard Biener from comment #1)
> does it work if you configure with --without-build-config? (thus, disable
> bootstrap-debug)
Just for the recores, this configure option produces a usable gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59985
--- Comment #6 from Bernd Edlinger ---
Created attachment 31989
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31989&action=edit
compiler output for stage 2 and 3
here the used compiler options:
ed@w-ed:~/gnu$ cat test.sh
echo stage2
cd /h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59985
--- Comment #4 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #3)
> Can you just cut'n'paste from build log command line to compile
> lto-streamer-in.o and rerun it by hand with -fcompare-debug?
the build step from stage 3 (witho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59985
--- Comment #2 from Bernd Edlinger ---
(In reply to Richard Biener from comment #1)
> does it work if you configure with --without-build-config? (thus, disable
> bootstrap-debug)
Ok with this option, stage 2 is not compiled with -gtoggle, and th
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
I try to boot strap this on arm-linux-gnueabihf:
../gcc-4.9-20140126/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59691
--- Comment #7 from Bernd Edlinger ---
(In reply to Balaji V. Iyer from comment #6)
> Hi Jeff, Andrew and Bernd,
>Can you please try out the "possible fix" and
> see if that works for you?
>
> Thanks,
>
> Balaji V. Iyer.
Hi the patch works,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
Bernd Edlinger changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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 0x003623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #13 from Bernd Edlinger ---
(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 to do something either
> about the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #9 from Bernd Edlinger ---
Created attachment 31485
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31485&action=edit
change code generation for simple DO-loops
This not yet fully tested patch changes the DO-loop code generation
t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=57748
--- Comment #50 from Bernd Edlinger ---
(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. It was generating one too many
> move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #46 from Bernd Edlinger ---
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 for review:
http://gcc.gnu.or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #44 from Bernd Edlinger ---
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 think it is possible that the othe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38077
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #26 from Bernd Edlinger ---
(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.
> >
> > This avoids any n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Bernd Edlinger changed:
What|Removed |Added
Attachment #31145|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #23 from Bernd Edlinger ---
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 would be
struct S { unsigned char s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #18 from Bernd Edlinger ---
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 +0100
@@ -4582,7 +4582,8 @@ get_bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #17 from Bernd Edlinger ---
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;
}
another test case. so this is p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #15 from Bernd Edlinger ---
(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 is not necessary, because after th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #14 from Bernd Edlinger ---
(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) {...},
> > *offset can no lon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #12 from Bernd Edlinger ---
(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)
> > {
> >HOST_WIDE_IN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #10 from Bernd Edlinger ---
but this should'nt be neccessary then?
if (bitoffset > *bitpos)
{
HOST_WIDE_INT adjust = bitoffset - *bitpos;
-
gcc_assert ((adjust % BITS_PER_UNIT) == 0);
- gcc_assert (*offset !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #7 from Bernd Edlinger ---
(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 { unsigned char s : 1; };
>
> ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58964
--- Comment #2 from Bernd Edlinger ---
Created attachment 31140
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31140&action=edit
For a possible fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58964
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
--- Comment #8 from Bernd Edlinger ---
Created attachment 31137
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31137&action=edit
untested patch
targetm.set_current_function modifies this_fn_optabs->pat_enable[654]
to enable/disable CODE_FOR_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
--- Comment #7 from Bernd Edlinger ---
Created attachment 31136
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31136&action=edit
reduced test case
apparently this is not yet fixed...
reduced test case attached.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508
--- Comment #6 from Bernd Edlinger ---
(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=58508
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
--- Comment #4 from Bernd Edlinger ---
(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. Some global data are completely
spoi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #11 from Bernd Edlinger ---
(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:
> >
> > if strict_volatile_bitfields>0 and t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #9 from Bernd Edlinger ---
Eric,
there is one more thing to consider for your proposed patch,
that is the damned -fstrict-volatile-bitfields:
if strict_volatile_bitfields>0 and the BIT_FIELD access
is _volatile_ it does not respect t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #6 from Bernd Edlinger ---
(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 different fields of a structure, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #2 from Bernd Edlinger ---
Created attachment 30962
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30962&action=edit
for a possible fix
comments?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398
--- Comment #8 from Bernd Edlinger ---
How can I set this PR to "FIXED"?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #22 from Bernd Edlinger ---
(In reply to Richard Biener from comment #21)
> -fno-tree-loop-distribute-patterns is the reliable way to not transform loops
> into library calls.
Thanks!
Adding this fixed the generated code:
#pragma GC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #41 from Bernd Edlinger ---
(In reply to rguent...@suse.de from comment #40)
> The issue is that we added the movmisaling-on-component-ref path
> for _correctness_ reasons. Now, if all misaligned accesses end up
> being expanded using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #39 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #37)
> In order to use movmisalign_optab
> instructions when we can, we should probably only do it if tem is a
> structure with a zero sized array.
I do also see poss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #38 from Bernd Edlinger ---
Richard,
I've split up the patch as requested:
Part 1 was posted here, but not yet approved:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01292.html
Just for the record, part 1 has been bootstrapped and r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58230
--- Comment #1 from Bernd Edlinger ---
Created attachment 30845
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30845&action=edit
proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398
--- Comment #6 from Bernd Edlinger ---
OK, this patch was posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01260.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398
--- Comment #5 from Bernd Edlinger ---
(In reply to Jan Hubicka from comment #4)
> Yes, this seems OK. We probably do not want to be too ken about optimizing
> around ifuncs.
Yes, the problem is that the resolver function just looks
like an alia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #36 from Bernd Edlinger ---
Created attachment 30782
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30782&action=edit
Next try for a fix
OK, I removed the misalign code path completely,
and found a one-line fix for read side too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #35 from Bernd Edlinger ---
Well, this bug seems to have a symmetical twin on the read side.
In the above example, if I add this:
if (x->xx[0].b != 3.14F || x->xx[1].a != 0x123456789ABCDEF)
abort ();
this gets compiled:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #34 from Bernd Edlinger ---
Hmm, this was looking like a working example ((if it is valid C at all)),
but after some thougt, I saw now it exposes a data store race:
#include
#include
typedef long long V
__attribute__ ((vector_siz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #32 from Bernd Edlinger ---
Ok, now I dared to propose my patch on the gcc-patches list:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00363.html
as I can see now both tests fail even on gcc-4.6 (ubuntu 12.04)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #31 from Bernd Edlinger ---
(In reply to Richard Biener from comment #29)
> (In reply to Bernd Edlinger from comment #28)
> > (In reply to Richard Biener from comment #19)
> > > Barking up wrong trees. Hacky fix looks like:
> > >
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #28 from Bernd Edlinger ---
(In reply to Richard Biener from comment #19)
> Barking up wrong trees. Hacky fix looks like:
>
> Index: gcc/expr.c
> ===
> --- gcc/expr.c (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #27 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #22)
> Created attachment 30732 [details]
> Another attempt at a fix
>
> I simply moved the decision whether to go the misalignp path or not a
> bit down in the funct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #26 from Bernd Edlinger ---
(In reply to Richard Biener from comment #25)
> I think that
>
> tem = get_inner_reference (to, &bitsize, &bitpos, &offset, &mode1,
> &unsignedp, &volatilep, true);
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58298
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #24 from Bernd Edlinger ---
Created attachment 30743
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30743&action=edit
Yet another untested fix
Ok, this is somewhat similar to Martin's very first attempt
to fix this.
After starin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #23 from Bernd Edlinger ---
Martin, one of the errors with strict volatile bitfields
was with a structure like this.
struct S0 {
signed a : 7;
unsigned b : 28;
} __attribute__((packed));
here the member b is using SImode but th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #21 from Bernd Edlinger ---
Richard, I have one question:
does this code at expr.c line 4717 look right?
I mean does the code in the if block use the offset at all?
misalignp = true;
to_rtx = gen_reg_rtx (mode);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
--- Comment #15 from Bernd Edlinger ---
This patch was posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01733.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933
--- Comment #7 from Bernd Edlinger ---
Created attachment 30712
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30712&action=edit
fixed test case
Looking deeper into the matter it seems like this an example
where vectorisation is not supposed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #20 from Bernd Edlinger ---
(In reply to Richard Biener from comment #19)
> volatile bitfield case to be audited as well:
>
> /* If the bitfield is volatile, we want to access it in the
> field's mode, not the computed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933
--- Comment #6 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Bernd Edlinger from comment #4)
> The test case
> gcc.dg/vect/pr56933.c fails on a pentium II,
> because of invalid
> instruction.
>
> A fairly obvi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58227
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
Bernd Edlinger changed:
What|Removed |Added
Attachment #30693|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
--- Comment #12 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #11)
> No, that is wrong as well.
Because it is too destructive? Maybe.
I think this is a general problem here.
1. the undefined behavior warning may be triggered b
: libmudflap
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Hello,
multiple libmudflap tests fail because the test scripts use the
english warning text, but the compiler prints the german translation.
libmudflap.c/pass35-frag.c
libmudflap.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
Bernd Edlinger changed:
What|Removed |Added
Attachment #30681|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58113
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
--- Comment #9 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #8)
> That patch looks wrong, and would very likely penalize tons of code, this
> predicate is used in many places in the compiler and the operations don't
> trap.
yes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
--- Comment #7 from Bernd Edlinger ---
How can I set the status of this tracker to CONFIRMED ?
Should'nt the component be "tree-optimization" instead of "middle-end" ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
--- Comment #6 from Bernd Edlinger ---
Created attachment 30681
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30681&action=edit
possible fix
This seems to be a possible fix.
What do you think of it, Jan?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
--- Comment #5 from Bernd Edlinger ---
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=58143
--- Comment #5 from Bernd Edlinger ---
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. this seems to be an optimization!
BUT tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58105
--- Comment #4 from Bernd Edlinger ---
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=58105
--- Comment #3 from Bernd Edlinger ---
Patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00770.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
--- Comment #3 from Bernd Edlinger ---
Created attachment 30639
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30639&action=edit
possible fix
This seems to be a bug in the constant folding of constant
vector values at forwprop4.
Could some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58105
--- Comment #2 from Bernd Edlinger ---
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 @@
DECL_IGNORED_P (decl) = 0;
/*
801 - 900 of 958 matches
Mail list logo
