https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #16 from Bernd Edlinger ---
Sandra,
I am pretty sure it should exist,
can you check which git revision you are looking at?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #19 from Bernd Edlinger ---
Okay, forget my previous comment,
I overlooked that you say the .c.gcov is missing...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #1 from Bernd Edlinger ---
Hi,
I use a newer binutils versions FWIW, and buit GCC-10 from
a few days ago using those binutils.
$ readelf -version
GNU readelf (GNU Binutils) 2.32
Copyright (C) 2019 Free Software Foundation, Inc.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #3 from Bernd Edlinger ---
(In reply to Andrew Burgess from comment #2)
> Sorry for including the wrong DWARF dump output in the bug report. I too
> had seen the DW_AT_GNU_entry_view using a more recent binutils.
>
NP.
> When you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #4 from Bernd Edlinger ---
Can you please approve my patch now?
https://sourceware.org/pipermail/gdb-patches/2020-April/167385.html
Thanks
Bernd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #6 from Bernd Edlinger ---
Right,
#+BEGIN_EXAMPLE
0030 00400545 00400545 (start == end)
0030 00400549 00400553
0030 00400430 00400435
0030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #7 from Bernd Edlinger ---
> I don't understand why each range wouldn't need its own view number?
Each of the sub ranges end PC can be an exit point.
At least how I see it.
Please have a look at my patch.
It adds each of the ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #9 from Bernd Edlinger ---
Andrew,
please update the reproducer, and explain in more detail
what you would like to be changed.
I still do not understand your idea.
But I try hard to do so.
Please be patient with me.
Bernd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #11 from Bernd Edlinger ---
Andrew,
(In reply to Andrew Burgess from comment #10)
> Further, I've seen no mention of exit views anywhere, and I think they
> would also be needed.
>
Yes, that is also my idea, when I say the dwarf2 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #13 from Bernd Edlinger ---
Hi Andrew,
You are right about the instruction re-ordering, that is done in
a compiler pass, which simply re-orders RTL instruction lists.
But I think when the code motion happens, we just
have no easy acc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92365
--- Comment #4 from Bernd Edlinger ---
Created attachment 47180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47180&action=edit
possible fix
This seems to fix the issue,
although a fix in cxx_eval_constant_expression
might be preferrable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024
--- Comment #5 from Bernd Edlinger ---
(In reply to Arseny Solokha from comment #4)
> Is there a backport pending? I cannot reproduce this ICE on release branches.
Hmm, interesting, I would have expected this to ICE.
However this patch is not c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #31 from Bernd Edlinger ---
Yes, you usually need to make a full bootstrap / make check twice
which the same svn revision one with and one without your patch.
You also should make sure that the test case actually is able to fail
befor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #34 from Bernd Edlinger ---
(In reply to fdlbxtqi from comment #33)
> Created attachment 47574 [details]
> copy_backward bug fixed for the last patch
>
> going to further run testsuite
Your test does not contain any test cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024
--- Comment #7 from Bernd Edlinger ---
Yes, I guess so.
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
I build gcc with read only source tree,
this worked all the time, but now it does no longer:
../gcc-trunk-0/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
--- Comment #1 from Bernd Edlinger ---
git Revision c3ccce5b47f85d70127f5bb894bc5e83f8d2510e
If absolutely necessary that should only be done in maintainer mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
--- Comment #3 from Bernd Edlinger ---
Ah, thanks I will do that.
Apparently the git conversion is to blame :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This causes a crash in gcc:
$ cat test.c
#define impl_test(name) void test_##name() { }
impl_test(t1
) impl_test(t2)
$ gcc -ftest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #4 from Bernd Edlinger ---
Martin, in the gcc-8 branch
is the gcov working, or has it the
same issue as bug#88045 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #6 from Bernd Edlinger ---
openssl workaround is here:
https://github.com/openssl/openssl/pull/11246
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
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
--- 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 #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
Bernd Edlinger changed:
What|Removed |Added
Attachment #29465|0 |1
is obsolete|
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=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=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
--- 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
Bernd Edlinger changed:
What|Removed |Added
Attachment #29724|0 |1
is obsolete|
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=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=56997
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
++
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
--- 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
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 #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=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=57699
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
: 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=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
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=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=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=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=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=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 #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
: 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 ---
Created attachment 30579
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30579&action=edit
test case to show the bug
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 #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 #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=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
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 ---
Created attachment 30598
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30598&action=edit
test case
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 #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 #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=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 :-),
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=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=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 #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
--- 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 #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 #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 #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 #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=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=58048
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
: 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
--- 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 } */
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
: 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=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
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=58105
Bernd Edlinger changed:
What|Removed |Added
Target||i686*-*-*
Component|c++
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;
/*
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=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=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=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=58143
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
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=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=57904
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
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=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 #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=58113
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 #30681|0 |1
is obsolete|
: 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
--- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
Bernd Edlinger changed:
What|Removed |Added
Attachment #30693|0 |1
is obsolete|
1 - 100 of 960 matches
Mail list logo
