--- Comment #6 from burnus at gcc dot gnu dot org 2009-05-15 06:57 ---
Fixed on the trunk (4.5). Thanks for reporting HJ and thanks to Steve E. for
providing an initial patch, which pointed into the right direction.
--
burnus at gcc dot gnu dot org changed:
What|Remo
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-15 06:53 ---
Subject: Bug 39352
Author: burnus
Date: Fri May 15 06:52:41 2009
New Revision: 147559
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147559
Log:
2009-05-15 Tobias Burnus
PR fortran/39352
*
--- Comment #4 from ramana at gcc dot gnu dot org 2009-05-15 06:28 ---
Doesn't work on 4.3 branch rev. 147478 .Works fine on trunk.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from bje at gcc dot gnu dot org 2009-05-15 05:55 ---
There is no problem with current GCC that I can see. The integer benchmarks
that fail to compile can be attributed to various C bugs such as mismatched
types between compilation units (eg. extern int foo in one file and
--- Comment #5 from peter dot kruse at lbbw dot de 2009-05-15 05:36 ---
(In reply to comment #4)
> > Thanks for the speed-of-light response. I'm just thinking, could it be
> > related
> > to the "-fPIC" argument (I found that in my CFLAGS)?
>
> Yes, please don't set CFLAGS when buildi
--- Comment #1 from bje at gcc dot gnu dot org 2009-05-15 05:35 ---
177.mesa and 188.ammp work with mainline. The remaining FP benchmarks do not
compile because -fwhole-program -combine is not supported for FORTRAN programs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26601
--- Comment #36 from hjl dot tools at gmail dot com 2009-05-15 04:32
---
Created an attachment (id=17871)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17871&action=view)
An updated patch
A few comments:
1. 3 branch limit is per 16byte page, not 16byte window.
2. We should allow
--- Comment #1 from bangerth at gmail dot com 2009-05-15 02:56 ---
Oh, should've said:
g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ -std=c++0x -c x.cc
x.cc:9: error: invalid conversion from 'int (*)(double)' to 'int (*)()'
x.cc:5: error: too many arguments to function 'int forward_c
I'm fairly sure this should compile but it doesn't:
-
template struct identity
{ typedef T type; };
template
int forward_call(RT (*) (A...), typename identity::type...);
int g (double);
int i = forward_call(&g, 0);
-
The problem is the
--- Comment #35 from hjl dot tools at gmail dot com 2009-05-15 02:23
---
Created an attachment (id=17870)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17870&action=view)
A patch
This patch limits 3 branches per 16byte page.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=399
r...@ryan:~/gcc/trunk/gcc/build/gcc$ ./xgcc -v
Using built-in specs.
Target: sh4-unknown-linux-gnu
Configured with: ../configure --build=i486-build_pc-linux-gnu
--host=i486-build_pc-linux-gnu --target=sh4-unknown-linux-gnu
--prefix=/home/ryan/crosstool-ng-1.3.1/targets/sh4-unknown-linux-gnu/build/g
--- Comment #18 from luisgpm at linux dot vnet dot ibm dot com 2009-05-15
02:19 ---
64-bit with -mcpu=power6
.L93:
fmul 20,11,13
fmul 19,11,0
addis 12,11,0xffe5
lfd 3,0(11)
addi 5,11,8
lfd 2,9472(12)
addis 14,5,0xffe5
fmad
--- Comment #17 from luisgpm at linux dot vnet dot ibm dot com 2009-05-15
02:16 ---
Actually, 64-bit is affected too, but not with the "power6x" tuning i was
using. With "-mcpu=power6" i can reproduce the problem.
The problem seems to be a couple load instructions that are being pushed
--- Comment #4 from cppljevans at suddenlink dot net 2009-05-15 01:19
---
Created an attachment (id=17869)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17869&action=view)
Much simpler code showing problem
Code has #defines which can be enabled or disabled to
show or hide bug.
--- Comment #6 from rakdver at gcc dot gnu dot org 2009-05-15 00:34 ---
(In reply to comment #5)
> It is number of iteration analysis that gets it wrong (I suppose it might get
> confused by the two exits of the loop?).
Sort of; # of iterations analysis assumes that pointers never wrap,
--- Comment #8 from bonzini at gnu dot org 2009-05-14 22:01 ---
Subject: Re: using RUNTESTFLAGS="--target_board
'foo{-mxyz,-mjkl,}'" screws up ieee.exp (and possibly others?)
> Paolo, is it possible that you're using a target triplet that doesn't match
> the
> checks in ieee.
Several versions of gcc (trunk, 4.4.0, 4.3.1 and 4.3.3) mis-compiled this test
case.
bug.c
/* compile with -Os -mthumb */
extern void abort (void);
static int llcmp(long long a, long long b);
struct info {
long unsigned ll;
};
int __attribute__((noinline))
cmp(const void *a, const voi
--- Comment #10 from billingd at gcc dot gnu dot org 2009-05-14 21:51
---
Patch is approved - http://gcc.gnu.org/ml/libstdc++/2009-05/msg00098.html
--
billingd at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from janis at gcc dot gnu dot org 2009-05-14 21:23 ---
I can't reproduce this on my x86 laptop. When I use the "make check" line
shown in comment #6, each compile for the ieee.exp tests uses -ffloat-store.
Paolo, is it possible that you're using a target triplet that doe
--- Comment #6 from bje at gcc dot gnu dot org 2009-05-14 21:12 ---
Not a bug.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from steven at gcc dot gnu dot org 2009-05-14 20:57 ---
http://gcc.gnu.org/viewcvs?view=rev&revision=147543
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from steven at gcc dot gnu dot org 2009-05-14 20:57 ---
Subject: Bug 40144
Author: steven
Date: Thu May 14 20:56:54 2009
New Revision: 147543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147543
Log:
PR driver/40144
* opts.c (common_handle_option)
--- Comment #17 from gustcr at yahoo dot com dot ar 2009-05-14 20:25
---
Unfortunately I failed to apply the patch to both version 4.4.0 and 4.3.0 so I
am stuck here. It was probably written for some specific version, but I don't
know which one
dirac:~/local/src/gcc-4.3.0/fixincludes$
--- Comment #3 from steven at gcc dot gnu dot org 2009-05-14 20:24 ---
FWIW:
-fstrength-reduce is a no-op
-fcse-follow-jumps is a no-op
-fcse-skip-blocks -is a no-op (the crash will be fixed before the day is over)
-fforce-addr isa no-op
The gnuboy maintainers should probably look into
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |inline-asm
h
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|steven at gcc dot gnu dot |
|org |
AssignedTo|
Compiler error message:
/usr/include/bits/mathinline.h: In function double acosh(double):
/usr/include/bits/mathinline.h:613: internal compiler error: Illegal
instruction
--
Summary: Illegal instruction in bits/mathinline.h:613
Product: gcc
Version: 4.4.1
--- Comment #6 from domob at gcc dot gnu dot org 2009-05-14 20:05 ---
Fixed (not addressing the "related" part in comment #2, but Janus promised to
work on it).
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from domob at gcc dot gnu dot org 2009-05-14 20:03 ---
Subject: Bug 40045
Author: domob
Date: Thu May 14 20:02:46 2009
New Revision: 147540
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147540
Log:
2009-05-14 Daniel Kraft
PR fortran/40045
* du
--- Comment #34 from vvv at ru dot ru 2009-05-14 19:43 ---
(In reply to comment #32)
> Please make sure that you only test nop paddings for branch insns,
> not nop paddings for branch targets, which prefer 16byte alignment.
Additional tests (for Core2) results:
1. Execution time don't d
--- Comment #33 from hjl dot tools at gmail dot com 2009-05-14 18:37
---
(In reply to comment #20)
> Instruction decoders generally operate on whole cache-lines, so 16-byte chunk
> very very likely refers to a cache-line.
>
That is true. For Intel CPUs, "16-bytes chunk" means memory r
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-14 18:26 ---
Likewise for tree-ssa-phiopt.c and reg-stack.c ones.
I think you need to look at the source instead of just doing a grep.
In fact these are all safe because they don't cross ggc_collect calls.
--
pinskia at gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-14 18:23 ---
I think the tree-ssa-sccvn.c and tree-ssa-pre.c ones are ok because they are
only used locally in that source and will not be used after the pass has run.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40151
There may be memory leaks in ggc:
tree-tailcall.c: static tree m_acc, a_acc;
tree-ssa-sccvn.c: tree VN_TOP;
c-typeck.c: static tree constructor_max_index;
tree-ssa-phiopt.c: static tree condstoretemp;
tree-ssa-pre.c:
static tree pretemp;
static tree storetemp;
static tree prephitemp;
combine.c:
--- Comment #1 from josh at freedesktop dot org 2009-05-14 18:00 ---
Created an attachment (id=17868)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17868&action=view)
Tarball of preprocessed source files to reproduce ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40150
$ cc -std=gnu99 -O3 -fwhole-program -combine lv2log.i sim-common.i
flight-computer.i physics.i pressure_sensor.i sensors.i resample-optimal.i
coord.i mat.i vec.i isaac.i random.i normal.i normal_tab.i polynomial.i
polynomial_tab.i -lm -o lv2log
ziggurat/polynomial_tab.c: In function main_chute:
z
--- Comment #6 from paolo dot carlini at oracle dot com 2009-05-14 17:59
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #5 from paolo at gcc dot gnu dot org 2009-05-14 17:56 ---
Subject: Bug 40123
Author: paolo
Date: Thu May 14 17:56:17 2009
New Revision: 147538
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147538
Log:
2009-05-14 Paolo Carlini
PR libstdc++/40123
*
--- Comment #1 from kargl at gcc dot gnu dot org 2009-05-14 17:46 ---
Fortran bug reports are never given a Severity of Blocker.
That value is reserved for problems with C/C++.
Please attach the smallest compilable example that
exhibits the problem and provide the exact command line
use
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-14 17:12
---
Indeed, very fishy: 1UL << 48. Patch forthcoming.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40123
Failed on assigning values to an array in a simple loop with the following
structure:
" IARRAY2 = 0
DO I = 2, 341
IARRAY2 = IARRAY2 + 1
PBLJARRAYPT(I,I,NCSP0) = IARRAY2
ENDDO
"
Is the length of variables still 6 nowadays?
--
Summary: variable
--- Comment #15 from janis at gcc dot gnu dot org 2009-05-14 16:50 ---
Fixed by the patches shown in comments 12 and 13.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-14 16:45 ---
Regressed with r145508 (PR39608).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #32 from hjl dot tools at gmail dot com 2009-05-14 15:58
---
(In reply to comment #30)
> Created an attachment (id=17863)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17863&action=view) [edit]
> Testing tool.
>
Please make sure that you only test nop paddings for br
--- Comment #6 from hjl dot tools at gmail dot com 2009-05-14 15:55 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #5 from hjl at gcc dot gnu dot org 2009-05-14 15:54 ---
Subject: Bug 40147
Author: hjl
Date: Thu May 14 15:54:19 2009
New Revision: 147537
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147537
Log:
2009-05-14 H.J. Lu
Backport from mainline:
2009-0
--- Comment #4 from hjl at gcc dot gnu dot org 2009-05-14 15:53 ---
Subject: Bug 40147
Author: hjl
Date: Thu May 14 15:52:58 2009
New Revision: 147536
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147536
Log:
2009-05-14 H.J. Lu
Backport from mainline:
2009-0
--- Comment #3 from hjl at gcc dot gnu dot org 2009-05-14 15:45 ---
Subject: Bug 40147
Author: hjl
Date: Thu May 14 15:45:32 2009
New Revision: 147535
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147535
Log:
2009-05-14 H.J. Lu
PR middle-end/40147
* ipa-util
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-05-14 15:29 ---
This looks like latent bug in dwarf2out. There is location list:
.LLST2:
.long .LVL0-.Ltext0 # Location list begin address (*.LLST2)
.long .LVL1-.Ltext0 # Location list end address (*.LLST2)
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-05-14 15:16
---
> Thanks for the speed-of-light response. I'm just thinking, could it be
> related
> to the "-fPIC" argument (I found that in my CFLAGS)?
Yes, please don't set CFLAGS when building GCC. I cannot reproduce.
-
--- Comment #31 from jakub at gcc dot gnu dot org 2009-05-14 15:15 ---
Some -O2 code size data from today's trunk bootstraps. The first .text line
is always vanilla bootstrap, the second one with
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00702.html
only, the third one with that patch
--- Comment #1 from kargl at gcc dot gnu dot org 2009-05-14 14:56 ---
Looks like a false positive.
REMOVE:kargl[230] cat kj.f90
program test
implicit none
integer i,j
i = 1234567899876
print *, i
end
REMOVE:kargl[231] gfc4x -o z kj.f90
kj.f90:4.23:
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-05-14 14:54
---
Richard, the subtype bounds removal patch will expose this on x86-64 as well.
Vectorization is not a priority in Ada for the time being so I'll go ahead, but
do you have an idea about the nature of the problem?
--- Comment #6 from bonzini at gnu dot org 2009-05-14 14:54 ---
Yes, indeed ieee.exp adds -ffloat-store so I was wrong yesterday in my first
report. However I can reproduce the problem with
make -k check RUNTESTFLAGS="--target_board
'unix{-march=i486,-march=pentium2,}'"
where testsu
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Priority|P3 |P5
http:/
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-14 14:50 ---
For 4.4 this was fixed by
2008-04-29 Richard Guenther
* tree-ssa-alias.c (finalize_ref_all_pointers): Remove.
(compute_may_aliases): Do not call finalize_ref_all_pointers.
(compute_flow_i
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-14 14:34 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00819.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-14 14:31 ---
Well with -DTEST1, the functions which were in the anonymous namespace are now
in the normal namespace which means they are going to be exported from the TU
which changes the inlining decisions.
--
http://gcc.gn
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40147
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
--- Comment #3 from peter dot kruse at lbbw dot de 2009-05-14 14:14 ---
(In reply to comment #2)
> This sounds really like a bug in solaris's as and you should be reporting it
> to
> Sun.
>
Thanks for the speed-of-light response. I'm just thinking, could it be related
to the "-fPIC"
--- Comment #1 from abel at gcc dot gnu dot org 2009-05-14 14:12 ---
Confirmed, I'll take a look. (Somehow my ispras.ru account didn't get any
mails about this bug.)
--
abel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-14 14:12 ---
This sounds really like a bug in solaris's as and you should be reporting it to
Sun.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from peter dot kruse at lbbw dot de 2009-05-14 14:03 ---
Created an attachment (id=17867)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17867&action=view)
sol2-c1.s
resulting .s file causing the failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40148
Hello,
trying to compile gcc 4.4.0 results in the following error:
---8<
/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/./gcc/xgcc
-B/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/./gcc/
-B/apps/local/gcc/4.
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-14 13:59 ---
Somehow, memory_identifier_string got garbage collected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40147
--- Comment #6 from domob at gcc dot gnu dot org 2009-05-14 13:49 ---
Created an attachment (id=17866)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17866&action=view)
ChangeLog for patch posted
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22552
--- Comment #5 from domob at gcc dot gnu dot org 2009-05-14 13:48 ---
Created an attachment (id=17865)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17865&action=view)
Latest patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22552
On Linux/ia32, revision 147436 failed to compile 483.xalancbmk in SPEC
CPU 2006:
gnu-33:pts/4[38]> /export/gnu/import/rrs/147454/usr/bin/gcc -m32 -c -o
DocumentImpl.o -DSPEC_CPU -DNDEBUG -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER
-I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl -Ixercesc/sax
-Ixerce
--- Comment #1 from caolanm at redhat dot com 2009-05-14 13:09 ---
Created an attachment (id=17864)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17864&action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
With some code (attached) using an anonymous namespace I get an unexplained
" is used uninitialized in this function" with -Wall, with no
indication of what is seen to be used uninitialized. Changing the namespace to
a named one removes the error, as does removing part of the body of a used
metho
Given the following code:
===
struct EditorInternalCommand { };
static void createCommandMap()
{
struct CommandEntry { EditorInternalCommand command; };
}
===
The structure createCommandMap()::CommandEntry is exported from a local-scope
(static) function. When compiling the code above with -
--- Comment #5 from joseph at codesourcery dot com 2009-05-14 12:01 ---
Subject: Re: spurious format string warnings
On Thu, 14 May 2009, bje at gcc dot gnu dot org wrote:
> Andrew wrote:
>
> "GCC can assume %qE means anything from just printing E in quotes"
>
> Can you explain th
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-05-14 11:26
---
Steven, that is probably fallout from your patch:
2009-04-27 Steven Bosscher
* dbgcnt.def (cprop1, cprop2, gcse, jump_bypass): Remove
(cprop, hoist, pre, store_motion): New debug counters.
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-05-14 11:20
---
Confirmed. The option -fcse-skip-blocks is the culprit.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from hp at gcc dot gnu dot org 2009-05-14 11:17 ---
patch posted after testing
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
UR
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-14 11:04 ---
Confirmed. That's the SMTs do not include ref-all stuff bug so DCE removes
the initialization.
extern void abort (void);
typedef int __m128 __attribute__((vector_size(16), may_alias));
typedef float floatA __attrib
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-14 10:55 ---
*** Bug 40143 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-14 10:55 ---
*** This bug has been marked as a duplicate of 35412 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ice in common_handle_option |[4.5 Regression] ice in
|
I just tried to compile the Suse Linux package gnuboy-1.0.3-1060.55
with the GNU g++ version 4.5 snapshot 20090507.
The compiler said
gcc -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector
-funwind-tables -fasynchronous-unwind-tables -pedantic -Wall -Wno-implicit
-Wno-long-long
The -ftrapv option doesn't appear to work as documented for GCC 4.4.0 on Debian
Linux 5.0/amd64. In the code below, the multiplication overflows an int, and
so I was expecting the program to be aborted. Instead, the program returned
normally with exit code 1.
Looking at the generated assembly, i
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-14 09:46 ---
Fixed with r147528. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-14 09:42 ---
Subject: Bug 39996
Author: janus
Date: Thu May 14 09:41:41 2009
New Revision: 147528
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147528
Log:
2009-05-14 Janus Weil
PR fortran/39996
* decl
Fortran code:
program test
implicit none
character*2 a(1)
character*24 trop
integer i,j
i=1
j=2
trop='b'//a(1)(i:j) ! fine
trop='b'//a(1)(1:2) ! warning
trop=a(1)(1:2)//'b' ! warning
trop=a(1)(1:2) ! fine
end
Compiled with:
Testcase:
#include
#include
typedef float floatA __attribute__((__may_alias__));
int main()
{
__m128 x = _mm_setzero_ps();
int i;
for (i = 0; i < 4; ++i) {
const float xx = ((floatA*)&x)[i];
if (xx != 0.f) {
printf("%d: %f\n", i, xx);
return
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40139
--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-14 09:07
---
Before dealing with this a middle-end, let me double check the implementation,
because I'm seeing something fishy...
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #30 from vvv at ru dot ru 2009-05-14 09:01 ---
Created an attachment (id=17863)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17863&action=view)
Testing tool.
Here is results of my testing.
Code:
align 128
test_cikl:
rept 14 ; 14 if SH=0, 15 if SH=1,
--- Comment #2 from paolo dot carlini at oracle dot com 2009-05-14 08:54
---
I tried to reproduce the equal.cc fail, for example, and it happens only at -O1
or above, as a "Floating point exception"...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40123
--- Comment #18 from ubizjak at gmail dot com 2009-05-14 08:25 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from uros at gcc dot gnu dot org 2009-05-14 08:23 ---
Subject: Bug 37179
Author: uros
Date: Thu May 14 08:23:31 2009
New Revision: 147522
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147522
Log:
PR target/37179
* config/i386/driver-i386.c (vendo
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-14 08:21
---
Assigning to Honza basing on a comment on the mailing list...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #55 from ubizjak at gmail dot com 2009-05-14 07:51 ---
(In reply to comment #54)
> I've started work on the binutils support for this. Work-in-progress patch at
> http://sourceware.org/ml/binutils/2009-05/msg00228.html
>
> Once that's complete, I could deal with the GCC end
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40140
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-05-14 07:17
---
Created an attachment (id=17862)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17862&action=view)
Testcase (about 90 lines)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40140
The attached valid code snippet triggers an ICE on the trunk when compiled with
"-O2 -ftree-parallelize-loops=2":
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report. [etc.]
--
Summary: [4.5 Regression] ICE with -ftree-parallelize-loops
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40139
The following invalid code snippet triggers an ICE since GCC 4.4.0:
===
template struct A
{
static int i;
};
template int A::i = { A::~A };
template class A<0>;
===
bug.cc: In instantiation of 'int A<0>::i':
bug.c
1 - 100 of 103 matches
Mail list logo
