Is there a reason why you top-post? Usually for email lists
top-posting is discouraged as it makes it harder to understand which
part of the email you are replying to.
http://en.wikipedia.org/wiki/Posting_style has some good information
about the different posting styles. I think the best quote
On 2008-08-07 10:51:20 -0700, MeMooMeM wrote:
H.J. Lu-30 wrote:
-ffast-math?
Oh, I just found the other thread on this issue. In my first search
I used 'subnormal' as the keyword, that's why I couldn't find the
tread.
Thank you, I think this option will do it!
This is a very bad
SITEYE UCRETSIZ UYE OLUP, ICERIKLERE, VIDEOLARA, LINKLERE, SIIRLERE,
TURKULERE, ANKETLERE KATILABILIRSINIZ. GULERDUMAN FM ESLIGINDE,
GUZEL TURKULERLE SITEYI GEZEBILIRSINIZ. SITEMIZDE KISA BIR SURE SONRA,
GULER DUMAN VE DIGER SANATCILAR ICIN SIZLERIN DE DESTEGIYLE WALPAPERLER,
ANIMASYONLAR VE
Jay wrote:
4.2.3 insn-attrtab.c takes a long time to
compile on djgpp (build=host=target=i586-pc-msdosdjgpp, bootstrapping
from 4.2.3) with the default -g -O2.
It did not take forever to build it for me, but it takas some time (for
the mentioned target). For DJGPP I had similar problems with
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-08-09
06:33 ---
The proposed patch eliminated the previous failures but I am now see some
additional ones in current gcc trunk...
FAIL: gcc.target/i386/incoming-1.c scan-assembler andl[\\t ]*\\$-16,[\\t ]*%esp
FAIL:
--- Comment #11 from schilds at sun dot ac dot za 2008-08-09 07:27 ---
Jeez! After reading what all of you have said ... I see this code does actually
do something as crazy (and simple) as set the logical unit number for a file to
6, in a subroutine (when I had thought they had only
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-09 12:38 ---
Subject: Bug 17880
Author: manu
Date: Sat Aug 9 12:37:32 2008
New Revision: 138904
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138904
Log:
2008-08-09 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
In the following code, adapted from gmpxx, the output is HELLO2. If however I
change the order of the two partial specializations, the output becomes HELLO1.
At least one other compiler I tried outputs HELLO1 in both cases. I know that I
can remove the template and overload the function instead of
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-09 13:09 ---
Fixed in the C front-end, broken in the C++ front-end. I also have a patch for
this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-09 14:12 ---
(In reply to comment #3)
The proposed patch eliminated the previous failures but I am now see some
additional ones in current gcc trunk...
FAIL: gcc.target/i386/incoming-1.c scan-assembler andl[\\t
The following code is producing false results with -O2 optimization (-O1 and O3
are correct):
---
#include stdio.h
#define BLOCK_SIZE 10
int main()
{
int i;
float block_f[BLOCK_SIZE];
int d_phase = 0;
int d_phase_inc = 0x10;
for (i = 0; i BLOCK_SIZE; i++){
block_f[i]
Executing on host:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/
../libtool --silent --tag=GCJ --mode=link /test/gnu/gcc/objdir/gcc/gcj
-B/test/g
nu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/test/gnu/gcc/objdir/gcc/
--encod
ing=UTF-8
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-09 15:15 ---
It doesn't work on gcc.dg/pch/valid-1b.c since it explicitly tests -g vs -g0:
[EMAIL PROTECTED] testsuite]$ cat gcc.dg/pch/valid-1b.c
/* { dg-options -I. -Winvalid-pch -g0 } */
#include valid-1b.h
int x;
[EMAIL
--- Comment #1 from paolo dot carlini at oracle dot com 2008-08-09 15:40
---
I think something has to be updated / extended on the target-specific bits for
darwin when i686-apple-darwin9 is involved, because the normal (meaning,
default) one is absolutely fine for me (to wit,
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-09
15:49 ---
Subject: Re: ctype_members.cc:137: error: redefinition of 'bool
std::ctypewchar_t::do_is(lo ng unsigned int, wchar_t)
I think something has to be updated / extended on the target-specific bits for
--- Comment #3 from paolo dot carlini at oracle dot com 2008-08-09 15:49
---
To confirm that something is going wrong when forcing this different config, at
line 137 of the darwin-specific ctype_members.cc there is *no* do_is function!
For some reason, the generic locale model (thus
--- Comment #4 from paolo dot carlini at oracle dot com 2008-08-09 15:51
---
Please investigate why you are compiling the generic ctype_members.cc instead
of the darwin-specific one. In the library nothing changed in this area
recently, for sure.
--
--- Comment #5 from paolo dot carlini at oracle dot com 2008-08-09 16:16
---
(In reply to comment #0)
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Note: configuring with the gnu clocale certainly is a bad idea on darwin,
*cannot* work. The only remaining mystery
--- Comment #6 from paolo dot carlini at oracle dot com 2008-08-09 16:18
---
(In reply to comment #2)
This did work http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg01872.html.
So, the regression is recent.
And here, you didn't have the --enable-clocale=gnu. Really no mystery ;)
--- Comment #1 from Jay dot St dot Pierre at Colorado dot EDU 2008-08-09
16:34 ---
Created an attachment (id=16049)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16049action=view)
config.log from the sparc-sun-solaris2.10/libgcc directory
--
FAIL: gcc.dg/pr36901-4.c #include_next (test for errors, line )
Success with trunk revision 138883
Failed with trunk revision 138904
--
Summary: [4.4 Regression] FAIL: gcc.dg/pr36901-4.c #include_next
(test for errors, line )
Product: gcc
--- Comment #6 from eric dot weddington at atmel dot com 2008-08-09 17:15
---
Your fix causes a regression on the AVR:
FAIL: gcc.dg/pr36901-4.c #include_next (test for errors, line )
Success with trunk revision 138883
Failed with trunk revision 138904
--
eric dot weddington at
--- Comment #1 from eric dot weddington at atmel dot com 2008-08-09 17:16
---
*** This bug has been marked as a duplicate of 36901 ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #7 from eric dot weddington at atmel dot com 2008-08-09 17:16
---
*** Bug 37069 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36901
--- Comment #8 from manu at gcc dot gnu dot org 2008-08-09 17:30 ---
I don't have AVR so I cannot know what exactly is going on or test a fix.
However, I guess that the limits.h used by AVR do not use #include_next. So you
could try by adding #include_next in pr36901-system.h, that is:
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-09 18:01 ---
This works for me as far as I can see (you didn't specify the expected
output, and certainly if the loop doesn't run as often as you want you
may print uninitialized memory). Anyway, if it doesn't work then it is
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-09 18:06 ---
Well, the switch conversion pass should create a locally binding (and hidden)
object to store the values. If it does not then this certainly is a bug.
Though in this case it looks like it needs to build a table of
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-08-09 19:05
---
I did commit these fixes but reversed two digits in the PR number in the change
log so they did not record here. Fix follows.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-08-09 19:13
---
Subject: Bug 36582
Author: jvdelisle
Date: Sat Aug 9 19:12:04 2008
New Revision: 138913
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138913
Log:
2008-07-26 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2008-08-09 19:18
---
Subject: Bug 36582
Author: jvdelisle
Date: Sat Aug 9 19:17:24 2008
New Revision: 138914
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138914
Log:
2008-07-22 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2008-08-09 19:19
---
Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from eric dot weddington at atmel dot com 2008-08-09 19:34
---
You're right in that limits.h for the AVR does not use #include_next. The
limits.h that the AVR toolchain uses is installed by gcc.
Unfortunately your suggestion makes the situation worse. There are now 4
--- Comment #2 from stefan dot bruens at rwth-aachen dot de 2008-08-09
20:37 ---
The expected output is quite clear - 69f0 6a00 - but output is 69f0
0.
The loop should run 10 times, as i does not overflow.
d_phase does overflow after 2048 steps, but this should not
--- Comment #10 from manu at gcc dot gnu dot org 2008-08-09 20:38 ---
Yeah, silly me, it obviously fails because there is no next pr36901.h to
include.
Since we include limits.h, we are at the mercy of the contents of the limits.h
that is found. This isn't very reliable. We just need
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-09 20:42 ---
The loop should run 10 times, as i does not overflow.
i does not overflow but d_phase_inc does ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37067
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-09 20:43 ---
As I said - it works for me (i686, gcc (Debian 4.3.1-8) 4.3.1). Still the
overflow invokes undefined behavior and thus _can_ affect the loop.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-09 20:46 ---
The loop should run 10 times, as i does not overflow.
i does not overflow but d_phase does ...
2046 7ff0
2047 8000
That is an overflow.
So is:
4094 fff0
4095 0
--
--- Comment #6 from stefan dot bruens at rwth-aachen dot de 2008-08-09
20:56 ---
So is there any possibility to flag a variable to be expected to overflow and
wrap around? I think there is a lot of code in the wild assuming the loop to
run 10 times and d_phase to overflow all the
--- Comment #7 from brian at dessent dot net 2008-08-09 21:00 ---
Subject: Re: gcc creating wrong code with -O2
Just make it unsigned since unsigned overflow is always defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37067
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-08-09 21:07 ---
You can use -fwrapv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37067
--- Comment #5 from hjl at gcc dot gnu dot org 2008-08-09 21:48 ---
Subject: Bug 37055
Author: hjl
Date: Sat Aug 9 21:47:28 2008
New Revision: 138916
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138916
Log:
2008-08-09 Jan Hubicka [EMAIL PROTECTED]
PR target/37055
--- Comment #12 from gerald at pfeifer dot com 2008-08-09 22:20 ---
This also breaks the bootstrap of the 4.3 branch on i386-unknown-freebsd6.3
without Ada being involved.
--
gerald at pfeifer dot com changed:
What|Removed |Added
gcc 4.3.0 generates the bogus warning below (4.4.0 behaves the same):
$ cat -n t.C g++ -v g++ -c -Wunreachable-code t.C
1 void f ()
2 {
3 throw 0;
4 }
5
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/sebor/gcc/trunk/configure
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-09 22:31 ---
I don't think this is really bogus as the expression inside a throw cannot
throw so GCC is able to optimize away the catch inside that throw.
[t.cc : 3] try
{
[t.cc : 3] D.2413 = (int *) D.2410;
--- Comment #2 from sebor at roguewave dot com 2008-08-09 22:51 ---
I'm not sure what you're trying to say but it sure looks like a bug to me.
How else is one supposed to throw an exception without triggering this
warning?
Btw., the argument of a throw expression can throw, and when it
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-09 22:59 ---
t.C: In function void bar():
t.C:2: warning: will never be executed
I don't get that warning in either the trunk or in 4.0.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37070
--- Comment #7 from manu at gcc dot gnu dot org 2008-08-09 23:24 ---
Testing the following patch. Not as good as ICC's diagnostic but close.
Index: gcc/testsuite/g++.dg/parse/pr20118.C
===
---
--- Comment #4 from sebor at roguewave dot com 2008-08-10 02:23 ---
My gcc is yesterday's build:
gcc version 4.4.0 20080808 (experimental) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37070
--- Comment #11 from eric dot weddington at atmel dot com 2008-08-10 03:13
---
(In reply to comment #10)
Since we include limits.h, we are at the mercy of the contents of the limits.h
that is found. This isn't very reliable. We just need to a pedantic warning in
the header. This
--- Comment #2 from Jay dot St dot Pierre at Colorado dot EDU 2008-08-10
03:14 ---
I was able to build gcc-4.2.4 using the Sun Studio 12 compiler. However, I was
unable to compile gcc-4.3.1 with gcc-4.2.4, albeit with different errors than
when I tried to use Sun's gcc. This time I
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-10 04:55 ---
Fixed, sorry this too so long to fix, there were other failures that were
blocking me to commit this patch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-10 04:56 ---
Subject: Bug 36238
Author: pinskia
Date: Sun Aug 10 04:54:37 2008
New Revision: 138924
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138924
Log:
2008-08-09 Andrew Pinski [EMAIL PROTECTED]
PR
52 matches
Mail list logo
