--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-30 06:01 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-30 06:06 ---
(In reply to comment #2)
It doesn't work for me, even with the updated cctools:
That is because the updated cctools did not include an updated ld64. Please
write an email to Geoff Keating about this issue.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-30 06:11 ---
Note the correct version of the inline-asm as far as I can tell is:
__asm__ __volatile__ ( : : m (__extension__
*({ struct { char x[n]; } *p = ptr;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26913
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-04-30 06:16
---
No feedback in 3 months.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Gcc 4.2 miscompiles binutils on Linux/x86 and Linux/x86-64. When gcc 4.2
is used, make check in binutils from CVS will have one failure in gas. The
problem is
more_than_enough_bits_for_digits
= (number_of_digits_to_use * 3321928 / 100 + 1);
around line 347 in gas/atof-generic.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 07:14 ---
Testcase? You know this is the nth bug you have filed without a testcase and
every time someone gets upset because you don't follow directions.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-30 07:25 ---
You are wrong.
When number_of_digits_to_use is 1, we get:
3321928 / 100
Which is equal to 3
And then add 1.
Try again please.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-30 07:33 ---
Actually I am wrong in saying it worked. I usually forget to test the return
value as I assume people use abort to signal a failure.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-30 07:35 ---
http://gcc.gnu.org/ml/gcc/2006-04/msg00577.html
I don't even see how you can get 37 in general in this case.
I can see 34 but not 37.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-30 07:37 ---
Well this works for me and others with the normal cctools so closing as
invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-30 07:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 07:44 ---
Confirmed, but since the Fortran compiler has some issues with creating DECLs
refering to the same function, it might become hard to fix this without a
front-end fix.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-30 07:47 ---
(In reply to comment #0)
[first testcase using nonconstant index]
does not warn about the use of uninitialized array buffer. While
[second testcase using constant index]
does. Likewise for C++.
In the
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 07:57 ---
I am thinking this is the ABI getting in the way of the C++ standard. In that
the secondary ~D() is getting in the way. The reason I say that is because it
worked with the old ABI in 2.95.3.
--
pinskia at gcc
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-30 08:02 ---
The testcase works for me as I don't have the STLport installed (and what is in
this bug is not enough to reproduce the bug).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-30 08:04 ---
This patch works for me (I have not fully test it yet though):
Index: c-common.c
===
--- c-common.c (revision 113388)
+++ c-common.c (working copy)
--- Comment #4 from yfw dot debian at gmail dot com 2006-04-30 09:09
---
I tried the gcc 4.1.1 snapshot 20060421. The bug still there. The assembly code
producted with -Os option is the same as gcc 4.1.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
--- Comment #4 from dirtyepic dot sk at gmail dot com 2006-04-30 09:59
---
Here is the testcase:
dirtyepic ~ $ cat pr27364.S
.tfloat 1.442695040888963407359924681002
dirtyepic ~ $ gcc pr27364.S
pr27364.S: Assembler messages:
pr27364.S:1: Fatal error: failed sanity check
This is
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-30 10:34
---
Subject: Bug 27278
Author: reichelt
Date: Sun Apr 30 10:34:05 2006
New Revision: 113389
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113389
Log:
PR c++/27278
* decl.c (grok_op_properties):
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-04-30 10:37
---
Subject: Bug 27278
Author: reichelt
Date: Sun Apr 30 10:37:24 2006
New Revision: 113390
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113390
Log:
PR c++/27278
* decl.c (grok_op_properties):
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-30 10:40
---
Subject: Bug 27278
Author: reichelt
Date: Sun Apr 30 10:40:18 2006
New Revision: 113391
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113391
Log:
PR c++/27278
* decl.c (grok_op_properties):
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-30 10:47
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-04-30 13:27 ---
Both patches (comment #7 and comment #8) are OK assuming they pass testing
(that is rather obvious).
Thanks,
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-04-30 13:33 ---
This is probably won't fix as well. The problem is that calls to builtins in
general can be produced arbitrarily late in the compilation process (before RTL
expansion).
We might try to do limited inliner pass
--- Comment #7 from hubicka at gcc dot gnu dot org 2006-04-30 13:35 ---
I should probably also note that IPA branch will get it right in the testcase
(and the other PR) via early inlining, but it sadly won't get it right in any
consistent manner...
Honza
--
--- Comment #2 from hubicka at gcc dot gnu dot org 2006-04-30 13:45 ---
Good point, I think I can do that easilly once mainline reopens.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hubicka at gcc dot gnu dot org 2006-04-30 13:48 ---
testing patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-04-30 13:56 ---
Concerning the comments, unit-at-a-time is not optimization, it is just way
overall compilation is driven.
I don't quite see reason for outputting unneeded static functions even at -O0
that it mostly just slows down
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-04-30 14:24 ---
Sorry, I've must missed the two pings and noticed the problem only now while
housekeeping.
There is no easy way to peek cfglayout about what decisions it will do in
future, so there is no easy
way to decide whether
--- Comment #5 from hjl at lucon dot org 2006-04-30 14:25 ---
Andrew, I tried my best to find a testcase. The best I can do so far is to
put a testcase in binutils so that when you build binutils with gcc 4.2 on
Linux/x86 and Linux/x86-64, you will get an make check failure in gas. I
--- Comment #8 from hubicka at gcc dot gnu dot org 2006-04-30 14:30 ---
Jakub,
adding a worklist and passing all variables to dwarf2out as last it quite easy
to do. However could you enlighten me a bit why the particular order is
needed?
Honza
--
hubicka at gcc dot gnu dot org
--- Comment #6 from hjl at lucon dot org 2006-04-30 15:33 ---
Hi Jeff,
It looks like your patch
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01386.html
causes gcc 4.2 miscompiles binutils on Linux/x86 and Linux/x86-64.
--
hjl at lucon dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-30 15:57 ---
Note I think Jeff's patch just exposed a bug.
Now since we don't have a testcase this is going to put into WAITING until we
have one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-30 16:25 ---
This works for me and many other people. You have to be doing something
different (and since you did not follow directions of supplying the configure
options it is hard to tell). Also you did not see if it passes
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 16:29 ---
Confirmed.
Janis, could you do a regression hunt on this bug?
Thanks.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from mark at codesourcery dot com 2006-04-30 16:50 ---
Subject: Re: no static definition at -O0
hubicka at gcc dot gnu dot org wrote:
I don't quite see reason for outputting unneeded static functions even at -O0
that it mostly just slows down the compilation
--- Comment #18 from mmitchel at gcc dot gnu dot org 2006-04-30 17:56
---
Andrew --
Thanks for investigating this, and for attempting to tolerate this bit of
weirdness from the front end.
-- Mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
--- Comment #8 from hjl at lucon dot org 2006-04-30 17:55 ---
Created an attachment (id=11350)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11350action=view)
A testcase
[EMAIL PROTECTED] gas]$
/export/build/gnu/gcc-last/build-x86_64-linux/./prev-gcc/xgcc
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-04-30 18:05
---
(In reply to comment #4)
Subject: Bug number PR27360
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-04/msg01152.html
--
hjl at lucon dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-30 18:17 ---
VRP is doing it:
D.2691_73 = number_of_digits_to_use_32 * 3321928;
D.2692_74 = D.2691_73 / 100;
more_than_enough_bits_for_digits_75 = D.2692_74 + 1;
D.2693_76 = more_than_enough_bits_for_digits_75 / 16;
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-04-30 18:21
---
Here is the reduced testcase:
int f(unsigned number_of_digits_to_use)
{
if (number_of_digits_to_use 1294)
return 0;
return (number_of_digits_to_use * 3321928 / 100 + 1) /16;
}
int main(void)
{
if
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-30 18:22
---
(In reply to comment #10)
Here is the reduced testcase:
And guess what that testcase also fails in 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
It would be nice to have some form of a builtin that shows that a portion of
the code is not reachable, and it generates no code in the binary.
gcc_unreachable() is used now in the gcc sources for this, but it will generate
assembly code that calls abort().
Another way to accomplish the same
--- Comment #28 from dann at godzilla dot ics dot uci dot edu 2006-04-30
19:25 ---
Just a note, fixing the problem in this PR would fix the only remaining failure
for cprop in Brigg's compiler benchmarks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 19:34 ---
Actually gcc_unreachable is to make sure that the compiler is constaint.
Really marking a path as unreachable is the same thing as using
__builtin_expect.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-04-30 19:44
---
The problem here is that 3321928 * 1294 wraps to 3607536 but VRP does not see
it because 3607536 3321928. Oh how I hate wrapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
--- Comment #9 from roger at eyesopen dot com 2006-04-30 19:52 ---
This bug is a duplicate of PR17104 which was fixed by Nathan Sidwell in
November 2004. If you read comment #4, you'll notice that the failure of
CSE to handle the rs6000's rs6000_emit_move's zero_extends is identical.
--- Comment #9 from roger at eyesopen dot com 2006-04-30 19:52 ---
*** Bug 13335 has been marked as a duplicate of this bug. ***
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-04-30 19:53
---
Subject: Bug 27360
Author: jvdelisle
Date: Sun Apr 30 19:53:41 2006
New Revision: 113396
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113396
Log:
2006-04-30 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-04-30 19:55
---
Fixed on 4.1 and 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-04-30 20:59
---
Subject: Bug 27304
Author: jvdelisle
Date: Sun Apr 30 20:59:08 2006
New Revision: 113397
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113397
Log:
2006-04-30 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-04-30 21:02
---
Subject: Bug 27304
Author: jvdelisle
Date: Sun Apr 30 21:02:10 2006
New Revision: 113398
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113398
Log:
2006-04-30 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-04-30 21:02
---
Fixed on 4.1 and 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from andreast at gcc dot gnu dot org 2006-04-30 21:09
---
This one works too, found by Dave.
--- configure.ac(revision 113252)
+++ configure.ac(working copy)
@@ -805,7 +805,7 @@
THREADLDFLAGS=-pthread
THREADSPEC=-lpthread
;;
-
marc dot glisse at normalesup dot org [EMAIL PROTECTED] writes:
| (In reply to comment #20)
| the
| very same source code would not be be portable across those targets. I don't
| think we would like that. Besides, more generally, I'm not at all sure that
| all the users would actually *like*
--- Comment #24 from gdr at integrable-solutions dot net 2006-04-30 23:05
---
Subject: Re: C-library symbols enter global namespace
marc dot glisse at normalesup dot org [EMAIL PROTECTED] writes:
| (In reply to comment #20)
| the
| very same source code would not be be portable
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-04-30 23:06
---
Suspending based on the Defect report being still open.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-30 23:21
---
Subject: Bug 27094
Author: mmitchel
Date: Sun Apr 30 23:21:38 2006
New Revision: 113399
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113399
Log:
PR c++/27094
* pt.c
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-04-30 23:25
---
Subject: Bug 27094
Author: mmitchel
Date: Sun Apr 30 23:25:44 2006
New Revision: 113400
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113400
Log:
PR c++/27094
* pt.c
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-04-30 23:29
---
Fixed in 4.1.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.1 |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-01 01:51 ---
(In reply to comment #2)
Does anyone oppose closing this report?
No objections in one month so I am assuming it is ok to close this as invalid.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-05-01 02:18
---
Subject: Bug 26534
Author: mmitchel
Date: Mon May 1 02:18:14 2006
New Revision: 113407
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113407
Log:
PR c++/26534
* cp-tree.h
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-05-01 02:18
---
Fixed in 4.1.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-01 02:28 ---
Do you have a shorter testcase? It is hard to figure out if this is valid code
(though it does look like it is).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu
|
--- Comment #3 from dave at boost-consulting dot com 2006-05-01 02:43
---
I'm afraid I don't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-01 03:46 ---
(In reply to comment #5)
It's not that we need special casing for a certain language: The TP robot is
generally broken (doesn't respond to translator's requests). I reported it
there several times, to no avail.
--- Comment #12 from ian at airs dot com 2006-05-01 04:51 ---
Can somebody please add a small standalone test case showing the problem here?
Thanks.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-05-01 05:45
---
The problem here is that we don't recongize the constant is resepentable with
vspltisw.
Hmm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-01 05:50
---
Hmm, maybe really this is just the RA playing tricks in that it should be able
to move
(insn 22 16 48 3 (set (reg:V4SI 126)
(vec_duplicate:V4SI (const_int 1 [0x1]))) 755 {altivec_vspltisw} (nil)
cygwin does not have the clearenv function, so ada compliation dies in
ada/env.c. Testing a patch to use unsetenv path.
--
Summary: ada build fails as cygwin does not have clearenv
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity:
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-05-01 05:58
---
(In reply to comment #12)
Can somebody please add a small standalone test case showing the problem here?
One is:
int g(int a, int b);
int f(int a, int b)
{
g(a, b);
return g(a, b);
}
--
78 matches
Mail list logo
