--- Comment #1 from fang at csl dot cornell dot edu 2006-03-13 07:25
---
Created an attachment (id=11037)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11037&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26662
The following code produces possibly wrong-code with -O2 on Apple's g++-3.3,
but I'm not sure if this is reproducible on other platforms. First, I'm
pasting the unpreprocessed source, will attach .ii momentarily. (Yes, I
realize 3.3 is closed, but I'd like to know if this is a known problem, or I
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-13 04:50
---
Created an attachment (id=11036)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11036&action=view)
Example data file to read.
Note: The error only occurs if there are no LF or CRLF on the last line of data
f
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-03-13 04:48
---
Created an attachment (id=11035)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11035&action=view)
Example showing read statement that fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26661
When reading sequential formatted files, and the last line of the file does not
contain an LF or CR, and EOF error occurs when there is available format
specifiers, but no data. Test case to follow.
--
Summary: Sequential formatted read goes too far
Product: gcc
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2006-03-13 04:36
---
Changing sunnary to reflect new case.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from patchapp at dberlin dot org 2006-03-13 04:35 ---
Subject: Bug number PR26509
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00724.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2006-03-13 04:22
---
Reopening, the new test case given in Comment #14 is a valid case. Will submit
patch shortly.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-13 02:42 ---
I am almost wanting to say this was caused by the openmp merge but I don't know
for sure.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-13 02:41 ---
Just a note the reason why this is ICE on valid and not just ICE on invalid is
because the source to t1.cc could also be:
#include "t.hh"
extern __inline__ int
stat (__const char *__path, struct stat *__statbuf) thro
--- Comment #3 from dje at gcc dot gnu dot org 2006-03-13 02:10 ---
AIX 4.2 configuration does not include aix64.opt to define 64BIT.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-13 01:41 ---
Related to PR 10591.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDepen
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-13 01:35 ---
[17:44] < pinskia> richi: it was this part which caused it:
[17:44] < pinskia> - align = DECL_ALIGN (exp);
[17:44] < pinskia> + align = MIN (align, DECL_ALIGN (exp));
[17:44] < pinskia> the alignm
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-13 00:53 ---
I should note I found this wil trying to figure out why a libstdc++ testcase
was failing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26660
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-13 00:52 ---
This worked with "4.1.0 20060208".
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
create an empty file called t.hh.
create a file called t1.cc with:
#include "t.hh"
extern __inline__ int
stat (__const char *__path, struct stat *__statbuf) throw ()
{
--
compile the PCH like:
g++ t.hh
and the source file with:
g++ t1.cc -save-temps --param ggc-min-expand=0 --param ggc-
--- Comment #7 from dominic dot quiet at gmail dot com 2006-03-12 22:26
---
Created an attachment (id=11034)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11034&action=view)
My new results without -marh=athlon-xp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26656
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-12 22:25 ---
This fails also on powerpc64-linux-gnu so this is not darwin specific.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from dominic dot quiet at gmail dot com 2006-03-12 22:25
---
Created an attachment (id=11033)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11033&action=view)
Fixed benchmark
I fixed my benchmark. You are right about the condition always being true after
127. I was
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-12 22:24 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenther at suse dot de
Target Milestone|---
gcc.target/powerpc/ppc-vector-memset.c fails on the mainline after one of the
follow patches:
+2006-03-10 Richard Guenther <[EMAIL PROTECTED]>
+
+ PR middle-end/26565
+ * builtins.c (get_pointer_alignment): Handle component
+ references for field alignment.
+
+2006-03-10 J"orn
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-12
22:05 ---
Subject: Re: 4.1.0 doesn't build in 64bit on PA-RISC
> (I tried to close this bug, but I got re-assign errors. Using Opera 9)
Don't. This is a regression. It's caused by the addition of EH exception
su
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-12 21:45 ---
Your benchmark is bad news as one rand is not a good randomizer for the lower
bits, oh after 127, the condition for your benchmark becomes always true which
is why it gets slower again.
--
pinskia at gcc dot gnu
--- Comment #4 from dominic dot quiet at gmail dot com 2006-03-12 21:41
---
Created an attachment (id=11032)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11032&action=view)
My results with -march=athlon-xp
The behavior of the ?: compared to without -march=athlon-xp may be a sign
--- Comment #7 from tbptbp at gmail dot com 2006-03-12 21:35 ---
For clarification i should say that rt::mono::ray_t which uses vec_t etc, isn't
a source of trouble, it's part of the single ray path where mostly scalar ops
are used.
There's a symmetrical set of structures in rt::packet
--- Comment #3 from dominic dot quiet at gmail dot com 2006-03-12 21:31
---
Created an attachment (id=11031)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11031&action=view)
My results without -march=athlon-xp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26656
--- Comment #2 from dominic dot quiet at gmail dot com 2006-03-12 21:23
---
Created an attachment (id=11030)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11030&action=view)
Benchmark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26656
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-12 21:12 ---
Confirmed. 3.4.5 requires -march=athlon-xp to inline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26658
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-12 21:07 ---
apart from visibility stuff, both preprocessed sources are equal and do not
contain inline memcpy/memset from glibc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #6 from tbptbp at gmail dot com 2006-03-12 21:03 ---
You're right, but that's a _mm_store_ss/movss asking for a 4 bytes alignment
(which is satisfied) and not a movaps with a 16 bytes constraint. The latter
are what are causing problems.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from nbkolchin at gmail dot com 2006-03-12 20:14 ---
Created an attachment (id=11029)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11029&action=view)
test_cmd-4.1.0.ii
-save-temps output from gcc 4.1.0 and gcc 4.0.2 (they are different only in
version numbers)
--
--- Comment #2 from nbkolchin at gmail dot com 2006-03-12 20:13 ---
Created an attachment (id=11028)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11028&action=view)
test_cmd-3.4.5.ii
-save-temps output from gcc 3.4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26658
--- Comment #1 from nbkolchin at gmail dot com 2006-03-12 20:12 ---
Created an attachment (id=11027)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11027&action=view)
test_cmd.cpp
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26658
During "bashmark" memory benchmark perfomance analyze, I found ~100x perfomance
regression between gcc 3.4.5 and gcc 4.X.
Compiler options: -march=athlon-xp -O3
test_cmd execution time:
- GCC 3.4.5: 0.43user 0.00system 0:00.44elapsed
- GCC 4.0.2: 34.83user 0.68system 0:36.09elapsed
- GCC 4.1.0: 3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-12 20:04 ---
I will take care of this once my current bootstrap/test has finished.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
-fopenmp use does not cause gcc to automatically link with gomp, this is
because Darwin defines its own LINK_COMMAND_SPEC which does not include the
following section from the generic version:
%{fopenmp:%:include(libgomp.spec)%(link_gomp)}
--
Summary: With -fopenmp, gcc does not link
--- Comment #4 from jonas dot mellin at his dot se 2006-03-12 19:58 ---
(In reply to comment #3)
> Your compiler simply runs out of memory.
The compiler gives an error message to leave a message on bugzilla when it runs
out of memory instead of saying that it ran out of memory. I gathe
--- Comment #9 from mtodorov at alu dot hr 2006-03-12 19:56 ---
Subject: Re: ICE in ix86_secondary_memory_needed, at
config/i386/i386.c:16446
> It is not a work around :). It is correcting the inline-asm.
Mais oui. :-)
M.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
--- Comment #7 from steven at gcc dot gnu dot org 2006-03-12 19:53 ---
Good luck Erik.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|In
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-12 19:44 ---
I should note that the diagnostic is produced in varasm.c while it really
should be produced in the front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-12 19:41 ---
it is not that slow at least on my two machines but it is still about 2x slower
than when java is disabled.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26640
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-12 19:35 ---
(In reply to comment #7)
> Confirmed. This workaround works.
It is not a work around :). It is correcting the inline-asm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
--- Comment #7 from mtodorov at alu dot hr 2006-03-12 19:33 ---
Subject: Re: ICE in ix86_secondary_memory_needed, at
config/i386/i386.c:16446
On Sun, 12 Mar 2006, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-12 18:58
>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-12 19:33 ---
Could you give a testcase which can be compiled?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26656
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-12 19:32 ---
Confirmed, not a regression, short testcase:
typedef unsigned long long int uint64_t;
uint64_t read_time(void)
{
uint64_t a, d;
asm volatile( "rdtsc\n\t" : "=a" (a), "=d" (d) );
}
--
pinskia at gcc dot gnu do
I'm on Gentoo Linux, my the use flags affecting GCC are "fortran" and "nls". I
have tried the following with -O2. If I write a piece of code that looks like
one of these :
example 1 : a = (b == 1 ? 1 : 0);
example 2 : a = (b == 1 ? 2 : 0);
example 3 : if( b == 1 )
a = 2;
--- Comment #5 from steven at gcc dot gnu dot org 2006-03-12 19:03 ---
Note that we should never ICE after an error. So this is still also a bug in
GCC itself.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-12 18:58 ---
This is invalid inline-asm:
static inline uint64_t read_time(void)
{
uint64_t a, d;
asm volatile( "rdtsc\n\t"
: "=a" (a), "=d" (d)
);
return (d << 32) | (a & 0x);
}
-
The correct way to implement t
--- Comment #3 from mtodorov at alu dot hr 2006-03-12 18:53 ---
Created an attachment (id=11026)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11026&action=view)
Created snow.i with -save-temps
gcc -O3 -g -Wall -Wno-switch -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64
-D_LARGEFI
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-12 18:46 ---
(In reply to comment #1)
> I don't know what to do (novice bug reporter).
There is a link called "Create a New Attachment" which you should be using.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
--- Comment #1 from mtodorov at alu dot hr 2006-03-12 18:45 ---
Subject: Re: ICE in ix86_secondary_memory_needed, at
config/i386/i386.c:16446
I am truly sorry, but resulting snow.i is 11389 lines, 325K long, so it
does not fit into comment.
I don't know what to do (novice bug repor
--- Comment #2 from dubos at lmd dot polytechnique dot fr 2006-03-12 18:42
---
(In reply to comment #1)
> This comes down to PR 19893.
>
Thanks for commenting on this. I fully agree that arrays of aint should be
rejected. The point is that there are no arrays here, only pointers.
The
--- Comment #8 from mtodorov at alu dot hr 2006-03-12 18:41 ---
Subject: Re: Wrong assembly generated with -O2, -O OK for
cinelerra source item
On Sun, 12 Mar 2006, steven at gcc dot gnu dot org wrote:
> --- Comment #7 from steven at gcc dot gnu dot org 2006-03-12 18:30
>
Summary: ICE in gcc
Version: gcc-4.2.0 20060304
Hardware: Athlon Thunderbird 1.33 GHz, 256 MB
OS: GNU/Linux Debian Knoppix kernel 2.6.11
Command Line:
gcc -O3 -g -Wall -Wno-switch -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o snow.o snow.c
snow.c
--- Comment #7 from steven at gcc dot gnu dot org 2006-03-12 18:30 ---
The problem is in your asm constraints. You allow GCC to do certain things
with the wrong constraints. Now, it may or may not do those things, depending
on what it thinks is best. Apparently it thinks one thing is
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-12 18:25 ---
(In reply to comment #5)
> IMHO this is a bug after all, since behavior is inconsitent (-O and -O2 do
> nto work the same), and code is generated that breaks later stage.
no it is not a bug as X in asm says any reg
--- Comment #5 from mtodorov at alu dot hr 2006-03-12 18:22 ---
Subject: Re: Wrong assembly generated with -O2, -O OK for
cinelerra source item
> Why then -O passes, and does it generate right code? Does 4.0.3 do the
> worng thing when compiling this without complaint?
>
> How can I
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot
|dot org
--- Comment #4 from mtodorov at alu dot hr 2006-03-12 18:06 ---
Subject: Re: Wrong assembly generated with -O2, -O OK for
cinelerra source item
On Sun, 12 Mar 2006, pinskia at gcc dot gnu dot org wrote:
> --- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-12 18:01
> --
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-12 18:01 ---
(In reply to comment #2)
> Any idea?
The inline-asm is just wrong. X means any register or memory which means it
could pick esp or xmm3 without caring that much.
Also the code is hiding all the mmx register uses f
--- Comment #2 from mtodorov at alu dot hr 2006-03-12 17:57 ---
Subject: Re: Wrong assembly generated with -O2, -O OK for
cinelerra source item
On Sun, 12 Mar 2006, hjl at lucon dot org wrote:
> --- Comment #1 from hjl at lucon dot org 2006-03-12 17:42 ---
> I don't think
>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-12 17:53 ---
This comes down to PR 19893.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26654
--- Comment #1 from hjl at lucon dot org 2006-03-12 17:42 ---
I don't think
__asm__ ( "ldmxcsr %0\n" : : "X" (trunc_mxcsr) );
will work well. Can you try
__asm__ ("ldmxcsr %0" : : "m" (*&trunc_mxcsr));
--
hjl at lucon dot org changed:
What|Removed
Compilation of the attached code (adapted from
http://gcc.gnu.org/projects/tree-ssa/vectorization.html
example3)
* works and vectorizes with gcc-4.0.1
g++ -O -msse -ftree-vectorizer -c vect.cpp
* works with gcc-4.1.0 and 4.2.0-20060311 if one of the above options is
omitted
(but does not or n
Exact version of GCC: gcc-4.2-20060304
Problem since: unknown (gcc-4.0.3-20060212 compiles OK both under -O2
and -O3)
Built with: ./configure --prefix=/usr/local; make bootstrap
Hardware: Athlon Thunderbird 1.33 GHz; 256 MB RAM
--- Comment #11 from pcarlini at suse dot de 2006-03-12 16:57 ---
Fixed for 4.1.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from paolo at gcc dot gnu dot org 2006-03-12 16:56 ---
Subject: Bug 26532
Author: paolo
Date: Sun Mar 12 16:56:08 2006
New Revision: 111979
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111979
Log:
2006-03-12 Paolo Carlini <[EMAIL PROTECTED]>
PR targe
--- Comment #5 from schwab at suse dot de 2006-03-12 15:45 ---
vec_t is a non-POD type because it has a user-defined copy assignment operator,
thus ray_t can't be a POD either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-12 14:52 ---
I don't think rays[0] is a POD so this might turn out to be a bug in your code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-12 14:50 ---
_mm_store_ss((float*)(((float*) &rays[0]) + 0), (pvx));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
int main()
{
#pragma omp parallel
{
#pragma omp for ordered
for(int i = 0; i < 1; i++)
;
}
}
produces 44 bytes memory leak because after the "omp for ordered"
gomp_work_share_start() gets called and allocs a struct gomp_work_share
which never gets freed because neither gomp_work_sh
--- Comment #17 from h dot m dot brand at xs4all dot nl 2006-03-12 12:26
---
Super! I moved binutil's ld out of the way, removed those two default CCFLAGS,
Conf/Build/Install worked fine.
r3:/pro/3gl/CPAN/perl-current 129 > /usr/local/pa20_64/bin/gcc --version
gcc (GCC) 4.1.0
Copyright
--- Comment #10 from pluto at agmk dot net 2006-03-12 09:14 ---
so, 4.1.0 was released with bootstrap blocker.
alpha-linux bootstrap is possible only with configure-hack.
-errors=`(${CC} -c conftest.adb) 2>&1 || echo failure`
+errors=`(${CC} -c conftest.adb) 2>/dev/null || echo failure`
75 matches
Mail list logo
