--- Comment #2 from bonzini at gnu dot org 2007-05-31 06:06 ---
I'm not sure we actually want to build libgcc stage1 optimized. But yes,
fixing 32009 will provide a way to fix this.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2007-05-31 06:26 ---
(In reply to comment #1)
Yes, it is indeed a regression, which was introduced between
2007-05-25-r125057 and 2007-05-29-r125159.
...and is almost certainly my doing - damn!
I am on to it
Paul
--
--- Comment #9 from bonzini at gnu dot org 2007-05-31 06:40 ---
Subject: Bug 32098
Author: bonzini
Date: Thu May 31 06:40:42 2007
New Revision: 125215
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125215
Log:
2003-05-31 Paolo Bonzini [EMAIL PROTECTED]
PR libjava/32098
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-31 07:46 ---
Subject: Bug 32103
Author: pault
Date: Thu May 31 07:45:50 2007
New Revision: 125216
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125216
Log:
2007-05-31 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-05-31 08:04
---
*** Bug 32159 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-05-31 08:04 ---
*** This bug has been marked as a duplicate of 20373 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tobi at gcc dot gnu dot org 2007-05-31 08:23 ---
I'll see if I can get access to x86-64 during the weekend.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from burnus at gcc dot gnu dot org 2007-05-31 08:32 ---
Other compilers give only a warning.
NAG f95 does for:
integer :: len
intrinsic len
Warning: yy.f90, line 9: Intrinsic function LEN explicitly typed
and for
real :: len
intrinsic len
Warning: yy.f90, line 9:
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2007-05-31 08:53
---
As mentioned by Andrew this is known issue.
*** This bug has been marked as a duplicate of 9085 ***
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mkuvyrkov at gcc dot gnu dot org 2007-05-31 08:53
---
*** Bug 31508 has been marked as a duplicate of this bug. ***
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from paolo at gcc dot gnu dot org 2007-05-31 08:58 ---
Subject: Bug 32158
Author: paolo
Date: Thu May 31 08:58:47 2007
New Revision: 125217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125217
Log:
gcc/cp
2007-05-31 Paolo Carlini [EMAIL PROTECTED]
PR
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #7 from mueller at gcc dot gnu dot org 2007-05-31 09:06 ---
PR 31806 is not fixed by this, and it contains a reference type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31809
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-31 09:19 ---
(In reply to comment #2)
Yes - it's r125088 that is responsible for the regression.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32156
--- Comment #7 from andrew dot stubbs at st dot com 2007-05-31 09:49
---
See here: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#197
It would appear that only koenig lookup is done for functions defined after the
template declaration. As the Intel statement says, koenig
--- Comment #8 from jakub at gcc dot gnu dot org 2007-05-31 10:00 ---
I saw was_readonly as well and wondered if it might be a problem or not, then
incorrectly assumed REFERENCE_TYPEs can't be an issue, but as PR31806 shows,
they apparently are.
2007-05-31 Jakub Jelinek [EMAIL
--- Comment #1 from rask at sygehus dot dk 2007-05-31 10:02 ---
The same thing happens when configuring with --target==mcore-unknown-elf, only
the startup file is crt0.c instead of sim-crt0.o.
--
rask at sygehus dot dk changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-31 10:19 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from andrew dot stubbs at st dot com 2007-05-31 10:57
---
Here's another issue in this area. Is it the same, or a separate bug? This code
is adapted from the example in DR197.
#include stdio.h
struct C1 {};
struct C2 : C1 {
};
C1 c1;
C2 c2;
void f(C1);
--- Comment #10 from paolo at gcc dot gnu dot org 2007-05-31 11:14 ---
Subject: Bug 32158
Author: paolo
Date: Thu May 31 11:13:57 2007
New Revision: 125223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125223
Log:
2007-05-31 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #11 from pcarlini at suse dot de 2007-05-31 11:15 ---
Fixed. Thanks again Michael for timely raising the issue.
--
pcarlini at suse dot de changed:
What|Removed |Added
Building NetBSD/sh3 soruce tree with stack protector enabled fails with
/usr/nb-ssp/tools/bin/shle--netbsdelf-gcc -O -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
--- Comment #1 from uwe at netbsd dot org 2007-05-31 11:37 ---
Created an attachment (id=13638)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13638action=view)
Preprocessed source of the file that causes the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
--- Comment #2 from uwe at netbsd dot org 2007-05-31 11:44 ---
Before failing to compile pic version of asprintf.o as reportde above,
non-pic version is successfully compiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-31 11:54
---
(In reply to comment #0)
In the following code, __gfortran_os_error is thrown as unresolved at link
time.
Is that a compiler you built from scratch, or did you build it, update the
source and rebuilt it
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-31 11:56
---
To have decent support for __float128 in gfortran, we need to provide a
__float128 math library. Do you happen to know any?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from KnowlesPJ at Cardiff dot ac dot uk 2007-05-31 11:58
---
The compiler was downloaded from the link in http://hpc.sourceforge.net/ .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32155
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-31 12:00
---
I don't think we should backport that to 4.2, as it's not a regression AFAICS.
Can you close it? (or, if you think it's worth backporting, ask for opinions on
the mailing-list?)
--
fxcoudert at gcc dot gnu
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-05-31 12:20 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg02138.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from P dot Schaffnit at access dot rwth-aachen dot de
2007-05-31 12:47 ---
More weird stuff with the following...
Philippe
subroutine Test ( Verbose, Position )
logical, intent(in) :: Verbose
integer, intent(in) :: Position
integer, parameter :: Anchor = 666, Cut_off
--- Comment #3 from razya at il dot ibm dot com 2007-05-31 12:57 ---
(In reply to comment #2)
(In reply to comment #1)
I get the same failure on powerpc64-linux-gnu.
I recreated it too, working on it. Thanks
Here's a patch that fixes the problems:
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-05-31 13:30 ---
I've confirmed that this fails with 4.1.2, 4.2.0 and 4.3.0
on sh4-unknown-linux-gnu. A reduced testcase is:
--
int foo ()
{
char *p;
char fext[128];
p = fext;
bar (p, (void *)0);
if (p)
free (p);
--- Comment #3 from ludovic at ludovic-brenta dot org 2007-05-31 14:51
---
Confirmed in Debian 4.1.1-22:
+===GNAT BUG DETECTED==+
| 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (x86_64-pc-linux-gnu) |
| Assert_Failure
(forwarded from the Debian bug tracking system)
package Pak1 is
type T1 is tagged null record;
function Eq(X, Y : T1) return Boolean renames =;
function Neq(X, Y : T1) return Boolean renames /=; -- line 4
end Pak1;
gnatmake pak1 yields:
gnatmake pak1
gcc-4.1 -c pak1.ads
--- Comment #1 from ludovic at ludovic-brenta dot org 2007-05-31 14:58
---
Same symptoms on i686-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32164
int
main ()
{
main();
}
Compiling this program at different optimisation levels gives different
results. Levels O3 and Os appear to be broken (with GCC 4.1.1).
$ g++ t.cxx -c -ansi -pedantic -O0
t.cxx: In function int main():
t.cxx:4: error: ISO C++ forbids taking address of function
Ive been working on a c program that does the error
condition check in the beginning as follows,
char *fun(str)
const char *str;
{
if (str == NULL) -- Error check, taking the const char variable directly.
printf(Null string \n);
..
}
But the code fails to perform the error
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-05-31 16:27 ---
Subject: Bug 32160
Author: rakdver
Date: Thu May 31 16:27:05 2007
New Revision: 125228
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125228
Log:
PR tree-optimization/32160
* tree-predcom.c
--- Comment #9 from mark at codesourcery dot com 2007-05-31 16:32 ---
Subject: Re: [4.1/4.2/4.3 Regression] sometimes TREE_READONLY
is still set for non read only variables causing wrong code
jakub at gcc dot gnu dot org wrote:
2007-05-31 Jakub Jelinek [EMAIL PROTECTED]
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-31 16:40 ---
Subject: Bug 31806
Author: jakub
Date: Thu May 31 16:40:12 2007
New Revision: 125229
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125229
Log:
PR c++/31806
* decl.c (cp_finish_decl): Also clear
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-31 16:35 ---
without a testcase it is hard to help you.
The char pointer might just point to some random memory which you might get a
crash.
Either hand us a testcase or use a debuger to debug your code more.
--
pinskia at
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-31 17:01 ---
Yes - it's r125088 that is responsible for the regression.
http://gcc.gnu.org/ml/gcc-cvs/2007-05/msg00788.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32156
Hello,
I get an ICE when compiling linux-2.6.20 with a host-gcc from today's
pointer_plus branch.
gcc -m32 -Wp,-MD,drivers/atm/.horizon.o.d -nostdinc -isystem
/home/mstein/host-gcc/pointer_plus-2007-05-31/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include
-D__KERNEL__ -Iinclude -include
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-05-31 17:53
---
Created an attachment (id=13639)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13639action=view)
from linux-2.6.20
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32167
[EMAIL PROTECTED] vect]$ cat x.c
typedef char vec_t;
extern __attribute__((aligned(16))) vec_t x [64];
extern __attribute__((aligned(16))) vec_t y [64];
extern __attribute__((aligned(16))) vec_t m [64];
void
foo1 ()
{
int i;
for (i = 0; i 64; i++)
m [i] = x [i] == y [i] ? 1 : 2;
}
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-31 18:11 ---
*** Bug 32168 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-31 18:11 ---
*** This bug has been marked as a duplicate of 21997 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-31 18:29 ---
Reduced testcase:
int f(void)
{
int *a = 0;
for(a = 0; a (int*)32767;a++)
;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-31 18:42 ---
The bug is in chrec_fold_plus somewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32167
Hello,
I get an ICE when compiling linux-2.6.20 with a host-gcc from today's
trunk.
gcc -m32 -Wp,-MD,sound/usb/.usbaudio.o.d -nostdinc -isystem
/home/mstein/host-gcc/pointer_plus-2007-05-31/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include
-D__KERNEL__ -Iinclude -include include/linux/autoconf.h
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-31 18:51 ---
Subject: Bug 31540
Author: pault
Date: Thu May 31 18:50:56 2007
New Revision: 125235
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125235
Log:
2007-05-31 Paul Thomas [EMAIL PROTECTED]
backport from
--- Comment #13 from pault at gcc dot gnu dot org 2007-05-31 18:51 ---
Subject: Bug 31867
Author: pault
Date: Thu May 31 18:50:56 2007
New Revision: 125235
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125235
Log:
2007-05-31 Paul Thomas [EMAIL PROTECTED]
backport from
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-31 18:51 ---
Subject: Bug 31994
Author: pault
Date: Thu May 31 18:50:56 2007
New Revision: 125235
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125235
Log:
2007-05-31 Paul Thomas [EMAIL PROTECTED]
backport from
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-31 18:51 ---
Subject: Bug 31483
Author: pault
Date: Thu May 31 18:50:56 2007
New Revision: 125235
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125235
Log:
2007-05-31 Paul Thomas [EMAIL PROTECTED]
backport from
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-31 18:51 ---
Fixed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-31 18:52 ---
Fixed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pault at gcc dot gnu dot org 2007-05-31 18:53 ---
Fixed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
Summary: string badly passed as function arguments
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-05-31 18:59
---
Created an attachment (id=13640)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13640action=view)
from linux-2.6.20
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32169
gcc segfaults on the code below (which is a simplified des.c from
nettle-1.15.tar.gz). '-ftree-loop-linear' seems to be the trigger,
at least -O1 is required too.
ICEs:
gcc version 4.2.1 20070531 (prerelease)
gcc version 4.1.3 20070519 (prerelease)
survives:
gcc version 4.0.4 20061113
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-05-31 19:00
---
$ export FILE=test
$ cat $FILE.f
program testchar
character(len=30), dimension(2) :: str1, str2
str1 = (/ string1, string2 /)
write(6,*) str1
write(str2(1),*) string1
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-05-31 19:04
---
$ export FILE=test2
$ cat $FILE.f
program testchar
character(len=30), dimension(2) :: str2
write(str2(1),*) string1
write(str2(2),*) string2
--- Comment #3 from mikael dot morin at tele2 dot fr 2007-05-31 19:18
---
$ export FILE=test3
$ cat $FILE.f
program testchar
character(len=30), dimension(2) :: str2
write(str2(1),*) string1
write(str2(2),*) string2
call
--- Comment #4 from mikael dot morin at tele2 dot fr 2007-05-31 19:26
---
$ export FILE=test6
$ cat $FILE.f
program testchar
character(len=30) :: str2
write(str2,*) string1
call test( str2 )
call test(string2)
--- Comment #5 from dominiq at lps dot ens dot fr 2007-05-31 19:33 ---
Compiled with g95, the code in comment #3 gives
In file pr32170_2.f90:10
call test( (/ string1, string2 /) )
In file pr32170_2.f90:16
subroutine test(chars)
2
Error: Passing array
--- Comment #6 from dominiq at lps dot ens dot fr 2007-05-31 19:34 ---
In the code in comment #4, you should use:
subroutine test(chars)
character(len=*) :: chars
write(6,*) chars
end subroutine
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
--- Comment #7 from dominiq at lps dot ens dot fr 2007-05-31 19:38 ---
subroutine test(chars)
character(len=*), dimension(2) :: chars
write(6,*) chars
end subroutine
for the code in comment #2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
--- Comment #1 from mikpe at it dot uu dot se 2007-05-31 19:48 ---
I cannot reproduce this on an armv5b-softvfp-linux machine, with either
gcc-3.3.6, gcc-4.0.4, gcc-4.1.2, or gcc-4.2.0 (all bootstrapped natively on the
arm machine).
However, I suspect your test case is wrong. Unpatched
--- Comment #3 from mikpe at it dot uu dot se 2007-05-31 20:01 ---
I can confirm this broken behaviour, including that it disappears if the 'c'
variable is renamed to 'xxc', with gcc-3.3.6, 4.0.4, 4.1.2, and 4.2.0, all
running natively on an armv5b-softvfp-linux machine.
--
mikpe at
--- Comment #2 from mikpe at it dot uu dot se 2007-05-31 20:35 ---
I cannot reproduce this bug with gcc-4.0.4, 4.1.2, or 4.2.0 on an
armv5b-softvfp-linux machine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26463
--- Comment #2 from laurent at guerby dot net 2007-05-31 20:37 ---
+===GNAT BUG DETECTED==+
| 4.2.0 (i686-pc-linux-gnu) Assert_Failure einfo.adb:853 |
| Error detected at pak1.ads:4:43
In http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01931.html
Andrew Pinski wrote:
On 5/28/07, Dominique Dhumieres [EMAIL PROTECTED] wrote:
So if I am not mistaken, -ffast-math does not obey the parentheses.
If you consider this is a bug, I'll fill a bug report.
-ffast-math enables
--- Comment #3 from laurent at guerby dot net 2007-05-31 20:39 ---
And still present on trunk from a few weeks ago:
+===GNAT BUG DETECTED==+
| 4.3.0 20070511 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure
einfo.adb:852|
|
--- Comment #12 from pault at gcc dot gnu dot org 2007-05-31 20:40 ---
I am not at all convinced that this is the fault of gfc_trans_array_transfer.
It is quite correctly producing (*(char[0:][1:1] as the output type. The
problem is the comaprison between an array of character(1)'s
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-31 20:55 ---
This behavior with -ffast-math is expected and is hoped for.
'a' and 'b' are not equal, but differ only by the round-off error.
That is PR 323.
*** This bug has been marked as a duplicate of 28684 ***
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-05-31 20:55
---
*** Bug 32172 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rask at sygehus dot dk 2007-05-31 21:01 ---
Created an attachment (id=13641)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13641action=view)
Patch to add -L and -B as necessary
This happens on all targets except m32c-*-*. I'm testing the attached patch.
--
On x86_ia64/fc5
[EMAIL PROTECTED] prs]# /svn-4.3/bin/gfortran $test/sizeof.f90
/svn/trunk/gcc/testsuite/gfortran.dg/sizeof.f90: In function check_int:
/svn/trunk/gcc/testsuite/gfortran.dg/sizeof.f90:3: internal compiler error: in
copy_to_mode_reg, at explow.c:645
Please submit a full bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-31 21:05 ---
*** This bug has been marked as a duplicate of 32148 ***
*** This bug has been marked as a duplicate of 32148 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-31 21:05 ---
*** Bug 32173 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-31 21:08 ---
sizeof has wrong types. might be fixed by one of my pending patches (I don't
see this failure).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dj at redhat dot com 2007-05-31 21:09 ---
Subject: Re: sim-crt0.o/crt0.o isn't found during configure due to missing -L
or -B
Note that m32c puts *.ld files in the *build* directory, not the
*source* directory, unlike most targets. The m32c source directory
only
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-31 21:12 ---
Subject: Bug 32156
Author: pault
Date: Thu May 31 21:12:10 2007
New Revision: 125241
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125241
Log:
2007-05-31 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-31 21:13 ---
Fixed as 'obvious'.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-31 21:15 ---
So, I believe this is fixed by r125242.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32148
--- Comment #4 from aaw at gcc dot gnu dot org 2007-05-31 21:18 ---
I've got a fix to this as part of my using directive / using declaration
cleanup. I'll disentangle this from the rest of my changes and submit a patch
soonish.
--
aaw at gcc dot gnu dot org changed:
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-31 21:18 ---
Note we do expand anint in this optimal way already (for x86 and SSE math).
Note
that we don't have infrastructure to obey paranthesis but only to not do
re-association at all.
--
--- Comment #2 from bigfoot at private dot dk 2007-05-31 21:22 ---
(In reply to comment #1)
However, I suspect your test case is wrong. Unpatched versions of gcc default
to little-endian mode on arm, even if you configure with
--target=arm${foo}b-${bar}.
Since you didn't pass
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-31 21:11 ---
Subject: Bug 32156
Author: pault
Date: Thu May 31 21:11:31 2007
New Revision: 125240
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125240
Log:
2007-05-31 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-31 21:31 ---
This behavior with -ffast-math is expected and is hoped for.
Yes indeed: I said I would like to see it at some level of -On.
That is PR 323.
If I understood correctly the PR, it deals with side effects to do the
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-31 21:34 ---
Note we do expand anint in this optimal way already (for x86 and SSE math).
I forgot to mention PPC (see comment #3) for which the implementation of
anint(x) and friends (mod(x), modulo(x)) are quite bad compared
--- Comment #4 from laurent at guerby dot net 2007-05-31 21:45 ---
ICE everywhere including trunk.
+===GNAT BUG DETECTED==+
| 3.4.6 (i686-pc-linux-gnu) Assert_Failure einfo.adb:459 |
| Error detected at
--- Comment #2 from ubizjak at gmail dot com 2007-05-31 21:44 ---
(In reply to comment #1)
To have decent support for __float128 in gfortran, we need to provide a
__float128 math library. Do you happen to know any?
--- Comment #4 from rask at sygehus dot dk 2007-05-31 22:37 ---
Created an attachment (id=13642)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13642action=view)
Patch v2 to add -L and -B as necessary
I believe I have covered boths cases of linker script placement.
The comments
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-31 22:43 ---
Simple fix:
Index: tree-chrec.c
===
--- tree-chrec.c(revision 125239)
+++ tree-chrec.c(working copy)
@@ -344,9 +344,9 @@
--- Comment #7 from paolo at gcc dot gnu dot org 2007-05-31 23:38 ---
Subject: Bug 31426
Author: paolo
Date: Thu May 31 23:37:56 2007
New Revision: 125244
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125244
Log:
2007-05-31 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-06-01 00:17 ---
In the faulty case, stack protector inserts PIC codes after the result
is set to R0 register. It looks like
rX = [EMAIL PROTECTED]
A = rX + r12
B = mem[A]
and combine optimization pass makes this turn into
1 - 100 of 107 matches
Mail list logo
