--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P4
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38682
dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
] Missed FRE because of VIEW_CONVERT_EXPR
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-06 21:33 ---
Related to PR38747.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38750
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-06 22:35 ---
Hm, we actually already do that?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-06 23:29 ---
No, the issue is that A.3 is not in gimple_addressable_vars () and thus is
considered non-aliased. The easiest thing to do is to re-compute addressable
vars after the vectorizer.
--
http://gcc.gnu.org/bugzilla
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38752
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-07 10:59 ---
Investigating.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-07 11:07 ---
Subject: Bug 38301
Author: rguenth
Date: Wed Jan 7 11:07:46 2009
New Revision: 143153
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143153
Log:
2009-01-07 Richard Guenther
PR tree-opti
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-07 11:08 ---
Fixed on the alias-improvements branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-07 11:09 ---
Mine anyway.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-07 10:53 ---
Subject: Bug 38751
Author: rguenth
Date: Wed Jan 7 10:53:30 2009
New Revision: 143152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143152
Log:
2009-01-07 Richard Guenther
PR middle-e
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-07 12:14 ---
We insist on finding an overlapping SFT even though it might possibly not
exist (as in this case where we do an access clearly outside of the object
boundary). The fix is to just ignore that and let the operand
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-07 13:12 ---
Subject: Bug 38752
Author: rguenth
Date: Wed Jan 7 13:12:17 2009
New Revision: 143155
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143155
Log:
2009-01-07 Richard Guenther
PR tree-opti
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-07 13:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-07 14:36 ---
You need an external definition of f.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-07 14:38 ---
See 6.7.4, especially the example in paragraph 7 and the explanation in 8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38754
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-08 12:50 ---
I suggest filing a problem report with Comeau. EDG accepts both in
-strict_ansi mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38764
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-08 12:29 ---
Subject: Bug 38721
Author: rguenth
Date: Thu Jan 8 12:29:46 2009
New Revision: 143185
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143185
Log:
2009-01-07 Richard Guenther
PR tree-opti
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-08 14:59 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-08 22:56
---
Neither for GCC 4.4. Re-targeting for GCC 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-08 22:58
---
Thus fixed. No need to fix accepts-invalid bugs on release branches (IMHO
we should never do that).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|4.4.0 |4.3.3
http
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-08 23:01
---
Huh, the regression state of this bug looks weird. So we have a patch applied
on trunk, but known-to-fail is both 4.3.3 and 4.4.0 - but 4.3.2 works? And
the target milestone is 4.4.0? If it is really a
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-01-08 23:02
---
So, only the ICE is a regression, not the memory-hog, correct?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking, wrong-code
Priority|P3
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-09 10:33 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-09 10:34 ---
Try -fno-strict-aliasing -fno-strict-overflow. This is likely a program bug.
Hard to say without a testcase though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38777
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-09 10:39 ---
I can't see the light with all these options, but a quick test with GCC 4.2.4
yields the same output with -O3 -ftree-loop-linear as with -O0. On
x86_64-linux
and x86_64-linux with -m32.
Turning r
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-09 12:25 ---
Subject: Bug 38721
Author: rguenth
Date: Fri Jan 9 12:25:00 2009
New Revision: 143200
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143200
Log:
2009-01-09 Richard Guenther
Revert
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-09 15:37 ---
That is a too weird situation. For 4.2 anyway, which is nearly
out-of-maintainance.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-09 15:55 ---
Testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-09 17:59 ---
It's indeed partial-PRE that performs these insertions. Steven has some
patches
to tune down regular insertion that may also apply to partial insertion.
See also PR38401.
--
rguenth at gcc dot gnu do
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-09 21:51 ---
I wouldn't consider this a bug. It's similar to
inline void foo(int i) { if (__builtin_constant_p (i)) you_loose(); }
void bar()
{
foo (1);
foo (2);
}
where the code is duplicated twice and both
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-09 22:57 ---
Ok, I'm convinced. That jump-threading is really weird. But only because
__builtin_constant_p isn't a regular function that is executed on a path
of the CFG, it really is supposed to be evaluating
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.4 Regression]|[4.4 Regression]
|__builtin_constant_p appears
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-10 22:47 ---
This is how it should behave.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-11 14:29 ---
This hits tramp3d a lot, we end up with
D.919534 = VIEW_CONVERT_EXPR(D.919509.D.78313.D.78008).D.78313.D.78008.domain_m[0].D.77181.D.47055.D.46936.domain_m;
vs. D.919509.D.78313.D.78008...
the following fixes it
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-11 14:41 ---
I can even see things like
SR.20836 = VIEW_CONVERT_EXPR(VIEW_CONVERT_EXPR(this->domain_m.D.115040.D.114739.domain_m[1].D.111565.D.45708.D.45522).D.45708.D.45522).D.45708.D.45522.domain_m[0];
in final clea
UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38806
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-11 16:56 ---
I have a patch, for alias-improvements branch sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-11 17:11 ---
Mine. We have to XFAIL gcc.dg/tree-ssa/20030807-7.c again though.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-11 17:19 ---
Hm, it looks like we might exclude that now. From invoke.texi:
"
Similarly, access by taking the address, casting the resulting pointer
and dereferencing the result has undefined behavior, even if the cast
u
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-11 20:05 ---
Ok, good. I'll make sure to fixup unclear comments in GCC code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-12 09:42 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-12 09:57 ---
Confirmed. The following fails with -O2 -m32:
typedef unsigned long ULONG;
void iwos_ErrorMessage(long error, const char * const file_name,
ULONG line_num, const char * const message);
class
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-12 13:54 ---
I can't seem to compile the preprocessed source:
In file included from ./sys-headers/boost/mpl/int.hpp:21,
from
./sys-headers/boost/type_traits/detail/template_arity_spec
.h
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-12 14:25
---
This isn't really a warning from system headers:
test.cpp:14: warning: dereferencing pointer '__x.13' does break strict-aliasing
rules
the location for the dereference is in test.cpp (if that is
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-01-12 14:51
---
Ok, how about -Wstrict-aliasing=3 warning only if both the dereference and the
declaration are not from system-headers (this is then the default for -Wall)
and with -Wstrict-aliasing=2 (or =1) warn if either of
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-13 09:29 ---
I think the best solution is to explore the possibility of lowering the call
to what it will look like in the end - pass return values of variable size
by reference. Hopefully all targets will end up doing this
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-13 09:33 ---
Or, can we make that invalid GNU C please? ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-13 09:51 ---
It should be ok with -fnon-call-exceptions.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-01-13 11:03
---
Smaller testcase for the possible libstdc++ / C++ FE issue, build with
-O2 -finline-functions -Wstrict-aliasing -Wsystem-headers
#include
class test
{
test();
void bar(int ci);
std::set foo;
};
void
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-01-13 12:14
---
There is only a conditional path through the program that violates aliasing
rules,
likely never executed. We do not detect this fact because of a points-to
solver
issue, PR38826.
--
rguenth at gcc dot gnu dot
dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38826
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-13 12:34 ---
It is interesting to see how taking the address of &s.q makes it a pointer
variable. The fundamental issue seems to be that eliminating non-pointers
and their edges conflicts with field-sensitive anal
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-13 14:37 ---
In fact, field-sensitive points-to analysis is probably not improving things
anyway - a testcase where it does is certainly welcome! - simply due to the
fact that the points-to analysis would need to be more clever
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-13 15:07 ---
I don't see how this changes could cause more branch misses. If you do the
same .palign for the 4.4 code does the regression vanish? I would suspect
that the loop-stream detector catches one but not the other
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-13 15:08 ---
Try -frename-registers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38825
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-13 15:15 ---
Note that your testcase has moved the load _mm_load_ps(in+4); before the
store _mm_store_ps(out, result); which the compiler cannot do itself because
they may alias.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-13 15:44 ---
-frename-registers does make a difference for me,
.L2:
movaps %xmm0, %xmm2
movaps %xmm0, %xmm1
addps (%rsi,%rax), %xmm2
movaps %xmm2, (%rdi,%rax)
addps 16(%rsi,%rax
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-13 16:37 ---
Yes, the alias sets are not properly transfered to RTL:
;; MEM[base: out, index: ivtmp.58] = result;
(insn 22 21 0 /usr/lib64/gcc/x86_64-suse-linux/4.4/include/xmmintrin.h:951 (set
(mem:V4SF (plus:DI (reg/v/f:DI
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-13 22:41
---
Fixed for GCC 4.4 (with unit-at-a-time being always on).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-13 22:49 ---
i?86 expands it to
(insn 39 38 40 t.i:39 (set (reg:SI 85)
(subreg:SI (reg:SF 65 [ D.1268 ]) 0)) -1 (nil))
(insn 40 39 41 t.i:39 (set (reg:QI 84)
(subreg:QI (reg:SI 85) 0)) -1 (nil))
(insn 41 40 42
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38835
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-01-14 16:45
---
Subject: Bug 38477
Author: rguenth
Date: Wed Jan 14 16:45:22 2009
New Revision: 143374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143374
Log:
2009-01-14 Richard Guenther
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-14 16:45 ---
Subject: Bug 38826
Author: rguenth
Date: Wed Jan 14 16:45:22 2009
New Revision: 143374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143374
Log:
2009-01-14 Richard Guenther
PR tree-opti
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-14 16:45 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-01-14 16:47
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-01-14 16:48 ---
I just installed a fix - can you verify if all the annoying warnigns are gone?
Thx!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Summary|[4.4 regression] performance
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-14 21:05 ---
I cannot even compile or link this in any obvious way.
gcc -o t t.c -DDOUBLE
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main&
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-14 21:46 ---
>From a first look Max should be found during argument-dependent name-lookup.
EDG
confirms this theory. gcc 4.1 accepts this code.
--
rguenth at gcc dot gnu dot org changed:
What|Remo
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-14 22:25 ---
You need to do some work to reduce this to a testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-15 09:45 ---
This is the frame-pointer setup code. You can get the same code as x86_64 with
-momit-leaf-frame-pointer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 14:35 ---
Thus invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 14:37 ---
IMHO it's unwanted to remove the frame setup for empty functions without
-momit-leaf-frame-pointer. Debuggers may need it to do backtraces from
within that function.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-15 14:37 ---
It is not. You are violating C++ aliasing rules. Use memcpy or a union.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38554
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38748
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38789
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-15 16:00 ---
Maybe not really P1, but we certainly should investigate why tree-ssa broke
this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:03 ---
Honza, can you please have a look here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38850
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-15 16:05 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:08 ---
Works for me with checking disabled. Not worth fixing on the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-15 16:08 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:09 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 16:10 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 16:10 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:12 ---
Fixed for GCC 4.4. Works for me on the branch with checking disabled.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
901 - 1000 of 15085 matches
Mail list logo
