--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 06:39 ---
Inside fold_builtin_unordered_cmp, cmptype is NULL.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36128
The following invalid code snippet triggers an ICE on mainline:
void foo()
{
__builtin_isless (foo, 0);
}
bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug re
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 06:19 ---
I don't see why we want C++ compatibility here since the C99 standard is clear
that the type of SomeConstant is still int.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 06:17 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-05-05 06:14
---
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00102.html .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-05 06:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-05 06:06 ---
(In reply to comment #1)
> > ERF, ERFC, GAMMA, and LOG_GAMMA returned NaN for REAL*10 inputs in
> > my test. EXPONENT returned garbage for REAL*10 and FRACTION
>
> There is another thing which has to be addressed. On
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35547
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:55 ---
The assembler is crashing and not GCC. So this is best to file this bug to
binutils project.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:54 ---
I don't think this is a real bug. Also patches should be off of the trunk and
submitted to [EMAIL PROTECTED]
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:51 ---
Actually it does not make sense to have any other value than 3 here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35501
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnosti
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 05:50 ---
I don't think this is true any more. The tuples branch should now be able to
bootstrap without any issues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 05:49 ---
We have a predict_expr.
*** This bug has been marked as a duplicate of 35736 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:49 ---
*** Bug 35893 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-05 05:46 ---
(In reply to comment #2)
> The problem is that we set ila1 to a null pointer if its
> size is zero: [...]
> It isn't clear to me why we do this (maybe as a debugging aid?).
Well, if we don't assign anything, the memo
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:42 ---
IIRC -fobjc-gc is only useful for the NeXT runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35996
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 05:40 ---
Sorry I mean:
[t.c : 24] D.1191_5 = sel.enabled;
[t.c : 24] iftmp.1_6 = D.1191_5 != 42;
As far as I can tell this warning is correct.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:38 ---
The warning looks fine for me, it is saying selog_on(&sel) will never be
executed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35973
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:36 ---
This is expected behavior. We no longer error out about an unkown warning
option unless there is an error/warning already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36095
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36007
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3/4.4 regression]Used|[4.3/4.4 regression] Used
|function interface bug
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36009
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36053
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-05-05 05:28 ---
As mentioned in the other bug report, it is hard to handle the -fabi-version=2
version of the mangled string. We handle correctly the correctly mangled
already.
So closing as won't fix.
--
pinskia at gcc dot gn
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-05 05:28 ---
> ERF, ERFC, GAMMA, and LOG_GAMMA returned NaN for REAL*10 inputs in
> my test. EXPONENT returned garbage for REAL*10 and FRACTION
There is another thing which has to be addressed. On Windows there seems to be
no "l
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:27 ---
The std:: namespace is supposed to be exposed and is marked as such in the
libstdc++ headers.
So I don't think this is a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 05:22 ---
This is not a bug, the names are in the reserved implementation namespace.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36011
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:20 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:13 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35999
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:10 ---
Even if the code assembled for 3.3.6 or 3.4.x, the weak reference was not being
emitted. So this is not a regression really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-05 05:05 ---
*** Bug 36092 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-05 05:05 ---
*** This bug has been marked as a duplicate of 36111 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.4
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:03 ---
If we had put the size in pointer to the array type, then this gets foldded.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36084
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 04:59 ---
Here is a further reduced testcase:
typedef struct {
int lock;
int pad0_;
} mutex_t;
static mutex_t main_arena;
void __malloc_check_init()
{
for(;;)
__asm__ __volatile__ ("": "+m"(main_arena.lock) );
}
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 04:50 ---
This is most likely a dup of bug 33887 and has been fixed for GCC 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36122
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Target Milestone|--- |4.4.0
http:/
--- Comment #3 from astrange at ithinksw dot com 2008-05-05 02:13 ---
Created an attachment (id=15580)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15580&action=view)
and at -Os
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
--- Comment #2 from astrange at ithinksw dot com 2008-05-05 02:12 ---
Created an attachment (id=15579)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15579&action=view)
compiled at -O3 on darwin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
--
astrange at ithinksw dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
--- Comment #1 from astrange at ithinksw dot com 2008-05-05 02:12 ---
Created an attachment (id=15578)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15578&action=view)
source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
> /usr/local/gcc44/bin/gcc -v
[..]
gcc version 4.4.0 20080503 (experimental) (GCC)
> gcc -O3 -mfpmath=sse -fno-pic -fno-tree-vectorize -S himenoBMTxps.c
With -O2/-O3, the inner loop in jacobi() in this program ends containing a lot
of this:
movss _p-4(%edi,%edx,4), %xmm0
movl
--- Comment #8 from hutchinsonandy at gcc dot gnu dot org 2008-05-05 01:15
---
The following information from Kenny Zadeck, shows why the solution does not
work. This limitation is not avoidable at the present time without causing
compilation time/memory regressions on other targets. S
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 00:12 ---
Both a and a.143 are marked as addressable. Interesting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from nightstrike at gmail dot com 2008-05-04 23:35 ---
Created an attachment (id=15577)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15577&action=view)
Preprocessed source
This is the preprocessed source that is used in the compilations mentioned in
the PR.
--
$ gcc -O1 -c -o vc1.o vc1.i
In file included from E:/msys/1.0/usrc/ffmpeg/src/libavcodec/mpegvideo.h:33,
from E:/msys/1.0/usrc/ffmpeg/src/libavcodec/vc1.c:31:
E:/msys/1.0/usrc/ffmpeg/src/libavcodec/bitstream.h: In function 'decode012':
E:/msys/1.0/usrc/ffmpeg/src/libavcodec/bitstre
--- Comment #5 from sam at gcc dot gnu dot org 2008-05-04 23:03 ---
Yes, I've seen this, but I expect an answer to another one very soon, which
would make the test case pass (I think the test case has the error message at
the right place), that's why I haven't fixed it yet.
--
http:
--- Comment #3 from danglin at gcc dot gnu dot org 2008-05-04 21:43 ---
(gdb) p debug_tree (rhs)
unit size
align 64 symtab 20 alias set 29 canonical type 60340e80 precision 128
pointer_to_this reference_to_this
>
addressable used TF file
/test/gnu/gcc/gcc/
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-05-04 21:29 ---
The problem is that we set ila1 to a null pointer if its
size is zero:
D.647 = size.6 * 4;
if (D.647 < 0)
{
_gfortran_runtime_error (&"Attempt to allocate a negative amount of
memory."[1]{lb: 1
--- Comment #33 from tkoenig at gcc dot gnu dot org 2008-05-04 20:57
---
Subject: Bug 32770
Author: tkoenig
Date: Sun May 4 20:56:30 2008
New Revision: 134936
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134936
Log:
2008-05-04 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #8 from cyprien+gccbug at cypou dot net 2008-05-04 20:13
---
On some embedded machines, the SDRAM lays on 0x address. So it is not
so meaningless to increment or decrement from/to NULL pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
--- Comment #27 from dje at gcc dot gnu dot org 2008-05-04 20:08 ---
I was planning to add asserts in print_operand_address ensuring that the
operand was the TOC SYMBOL_REF.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #26 from jakub at gcc dot gnu dot org 2008-05-04 19:47 ---
Created an attachment (id=15576)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15576&action=view)
gcc44-pr36090.patch
Patch I've bootstrapped on 4.3 branch on {i386,x86_64,ppc,ppc64}-linux, no
regressions.
Not
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-05-04 19:08 ---
Fixed on trunk.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-05-04 19:08 ---
Subject: Bug 35995
Author: tkoenig
Date: Sun May 4 19:07:28 2008
New Revision: 134934
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134934
Log:
2008-05-04 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-04 18:47 ---
Closing as fixed then.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2008-05-04 18:43 ---
Note that this was fixed by:
2007-05-02 Eric Christopher <[EMAIL PROTECTED]>
* expr.c (num_div_op): Don't overflow if the result is
zero.
This is in 4.3.
--
tromey at gcc dot gnu dot org chang
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-05-04 18:11 ---
sum, product etc are also affected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35995
--- Comment #2 from danglin at gcc dot gnu dot org 2008-05-04 18:03 ---
Breakpoint 1, verify_gimple_expr (expr=0x7ae94318)
at ../../gcc/gcc/tree-cfg.c:3962
3962 gcc_unreachable ();
(gdb) bt
#0 verify_gimple_expr (expr=0x7ae94318) at ../../gcc/gcc/tree-cfg.c:3962
#1 0x003cf
--- Comment #7 from cyprien+gccbug at cypou dot net 2008-05-04 17:31
---
it's right, using --foo unstead of foo-- gives a better result.
But it does not make me happy (about the possibility of a bug)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
--- Comment #1 from danglin at gcc dot gnu dot org 2008-05-04 17:15 ---
27_io/basic_istream/extractors_arithmetic/char/9555-ia.cc and
27_io/basic_istream/extractors_arithmetic/wchar_t/9555-ia.cc
also fail with the same error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++
-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/o
pt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/g
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-05-04 17:09 ---
>Now, this code should not rely on undefined behaviour:
It does because incrementing or decrementing to a NULL Pointer is undefined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
--- Comment #5 from cyprien+gccbug at cypou dot net 2008-05-04 17:03
---
Now, this code should not rely on undefined behaviour:
extern void func(int,void*);
void test()
{
register long *foo = (long*) (4*sizeof(*foo)) - 1;
register int index;
for(index=0;index<4;index++)
--- Comment #4 from kargl at gcc dot gnu dot org 2008-05-04 17:01 ---
(In reply to comment #2)
> shouldn't gcc report a warning in this case ?
>
> because silently entering an infinite loop is not very kind...
>
If your code invokes undefined behavior, how is gcc going
to read your mi
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-04 16:45 ---
(In reply to comment #2)
> shouldn't gcc report a warning in this case ?
Maybe, but really depending on undefined behavior is bad too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
--- Comment #2 from cyprien+gccbug at cypou dot net 2008-05-04 16:41
---
shouldn't gcc report a warning in this case ?
because silently entering an infinite loop is not very kind...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-04 16:34 ---
Pointers types overflow is undefined which is what you are seeing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Hi,
It seems to have some regression in gcc 4.3, visible on arm targets as well as
x86_64.
I originally already reported it to Debian bugtracking system
[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472867]
I tested it against the latest gcc snapshot:
gcc (GCC) 4.3.1 20080501 (prerelease)
gcc dislikes this prefix to a program depending on C99 integer division:
$ cat bug.c
#if 1/-2 || (-1)/2
# error "integer division rounding away from zero not supported"
#endif
$ gcc-4.2.2 -fsyntax-only bug.c
bug.c:1:12: warning: integer overflow in preprocessor expression
bug.c:1:21: warning: inte
--- Comment #9 from hjl dot tools at gmail dot com 2008-05-04 15:35 ---
*** Bug 36118 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-04 15:35 ---
*** This bug has been marked as a duplicate of 36100 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-04 15:27 ---
Fixed by
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00206.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hjl at gcc dot gnu dot org 2008-05-04 15:22 ---
Subject: Bug 36121
Author: hjl
Date: Sun May 4 15:22:05 2008
New Revision: 134932
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134932
Log:
2008-05-04 H.J. Lu <[EMAIL PROTECTED]>
PR target/36121
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-05-04 14:46 ---
Created an attachment (id=15575)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15575&action=view)
proposed patch
Testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35995
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-05-04 12:58
---
A testcase is difficult since it cannot be isolate from other optimisations.
The the problem is "obvious". It can be seen by doing RTL dump and looking at
preferred register classes.
Any source operand that
--- Comment #11 from rguenther at suse dot de 2008-05-04 12:41 ---
Subject: Re: [4.4 regression] internal compiler
error: in vectorizable_assignment, at tree-vect-transform.c:3671
On Sun, 4 May 2008, irar at il dot ibm dot com wrote:
>
>
> --- Comment #10 from irar at il dot ib
The program shows a problem where the compiler
seems to do 16-bit arithmetic on a 15-bit field.
In the program below,
None of the 'false' conditions within a 'doRead'
should be generated by the arguments passed but
when compiled with -O2 the tests yield false
but when compiled with -O work fine.
--- Comment #10 from irar at il dot ibm dot com 2008-05-04 12:26 ---
(In reply to comment #9)
> Can you give the patch bootstrap & test? I'll pre-approve
> it here.
Sure, for both trunk and 4.3.1, I guess.
Ira
>
> Thanks,
> Richard.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #9 from rguenther at suse dot de 2008-05-04 12:22 ---
Subject: Re: [4.4 regression] internal compiler
error: in vectorizable_assignment, at tree-vect-transform.c:3671
On Sun, 4 May 2008, irar at il dot ibm dot com wrote:
> --- Comment #8 from irar at il dot ibm dot co
--- Comment #8 from irar at il dot ibm dot com 2008-05-04 12:07 ---
(In reply to comment #7)
> It does - and the loop is vectorized. But it looks like a hack ;)
It is not. We actually do this in all vectorizable_...() that support SLP.
SLP currently does not support multiple types (I
--- Comment #7 from rguenther at suse dot de 2008-05-04 11:53 ---
Subject: Re: [4.4 regression] internal compiler
error: in vectorizable_assignment, at tree-vect-transform.c:3671
On Sun, 4 May 2008, irar at il dot ibm dot com wrote:
> --- Comment #6 from irar at il dot ibm dot co
--- Comment #6 from irar at il dot ibm dot com 2008-05-04 11:49 ---
(In reply to comment #5)
> Created an attachment (id=15574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574&action=view) [edit]
> vectorizer dump
>
> Attached.
Thanks!
> The last line indeed hints at SLP:
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-04 11:24 ---
Created an attachment (id=15574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574&action=view)
vectorizer dump
Attached. The last line indeed hints at SLP:
t.f90:14: note: -->vectorizing SLP node star
--- Comment #5 from d at domob dot eu 2008-05-04 11:23 ---
Now I believe I found out where the problem might be; as far as I can tell,
gfc_array_ctor_strlen in trans-array.c is the point where we determine the
length of the elements of a character array constructor; in the loop over all
--- Comment #4 from irar at il dot ibm dot com 2008-05-04 11:21 ---
If it is really a try to SLP, I think this patch will fix the ICE:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 134926)
+++ t
--- Comment #3 from irar at il dot ibm dot com 2008-05-04 11:13 ---
In my dump this stmt is vectorized ok:
bug.F:14: note: -->vectorizing statement: D.1055_23 = ((D.1054_22))
bug.F:14: note: transform statement.
bug.F:14: note: vect_is_simple_use: operand ((D.1054_22))
bug.F:14: not
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-04 10:47 ---
I can reproduce this on i686 with -O3 -mfpmath=sse -msse2 (r134902):
#1 0x086d592d in vectorizable_assignment (stmt=0xb7c9dcb0, bsi=0xbff3b824,
vec_stmt=0xbff3b7c0, slp_node=0xab9ca08)
at /home/richard/src
--- Comment #9 from tkoenig at netcologne dot de 2008-05-04 10:15 ---
Subject: Re: run-time abort for PACK of run-time zero
sized array
On Sun, 2008-05-04 at 09:59 +, dominiq at lps dot ens dot fr wrote:
>
> --- Comment #7 from dominiq at lps dot ens dot fr 2008-05-0
1 - 100 of 107 matches
Mail list logo
