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 #12 from ubizjak at gmail dot com 2007-06-01 06:42 ---
*** Bug 32123 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from ubizjak at gmail dot com 2007-06-01 06:42 ---
*** This bug has been marked as a duplicate of 26449 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #11 from ubizjak at gmail dot com 2007-06-01 06:42 ---
New test (from PR32123):
Standalone testcase, compile with -O2 -msse2 -mtune=k8:
--cut here--
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16)))
--- Comment #10 from ubizjak at gmail dot com 2007-06-01 06:39 ---
Not fixed, please look for the same failure at PR32123.
start_sequence ();
op = force_operand (SET_SRC (set), reg);
+ if (!op)
+ {
+ end_sequence ();
+ goto f
--- Comment #5 from eres at il dot ibm dot com 2007-06-01 06:24 ---
(In reply to comment #3)
> > *** This bug has been marked as a duplicate of 28684 ***
> Related, but a different issue.
I Agree. Bug 28684 mainly deals with the need to redefine
-funsafe-math-optimizations as IEEE com
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 #5 from jvdelisle at gcc dot gnu dot org 2007-06-01 04:06
---
It seems then the first step is to support both real 10 and real 16
simultaneously if available. Then implement the soft library for real 16
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
--- Comment #4 from kargl at gcc dot gnu dot org 2007-06-01 02:52 ---
(In reply to comment #3)
>
> What about rolling our own with mpfr? Or is that too difficult. :)
>
It could be done with mpfr, but note that at the moment gfortran
will provide either REAL(10) or REAL(16). This ha
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-01 02:20 ---
Fixed. Thanks for these reports.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
L PROTECTED]>
* gcc.c-torture/compile/20070531-1.c: New test.
PR tree-opt/32167
* gcc.c-torture/compile/20070531-2.c: New test.
2007-05-31 Andrew Pinski <[EMAIL PROTECTED]>
* tree-vrp.c (extract_range_from_binary_expr): Handle
MIN_EXPR/MAX_EXPR for pointers ty
--- Comment #5 from dj at redhat dot com 2007-06-01 01:08 ---
m32c still needs -L$$r/$(TARGET_SUBDIR)/libgloss/m32c to find r8c.ld in the
build directory. Your patch would only search in the source directory. Be
careful with -B vs -L, and $$r vs $$s.
You've also removed the special fl
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-01 00:53
---
FX, this library might do the trick. I have x86-64 machine here to help on
this.
What about rolling our own with mpfr? Or is that too difficult. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
--- 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
--- 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=gcc&view=rev&rev=125244
Log:
2007-05-31 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- 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 @@ chrec_fold_plus
--- 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=13642&action=view)
Patch v2 to add -L and -B as necessary
I believe I have covered boths cases of linker script placement.
The comments en
--- 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 dm-tools.adb:4
--- 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?
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/ieee754/?cvsro
--- 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 #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 th
--- 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 -mb
--- 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.
--
http://gcc.gnu.org/bugzilla/sh
--- 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:
What
--- 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 #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
S
--- 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=gcc&view=rev&rev=125241
Log:
2007-05-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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=gcc&view=rev&rev=125240
Log:
2007-05-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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 h
--- 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 #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 #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 |Adde
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 report,
--- 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=13641&action=view)
Patch to add -L and -B as necessary
This happens on all targets except m32c-*-*. I'm testing the attached patch.
--
--- 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 ***
--
pinsk
--- 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 #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 an
--- 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|
| Err
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 #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
--- 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 #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 #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 #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 #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 #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 ar
--- 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 #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"
ca
--- 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 #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"
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.
--- 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=13640&action=view)
from linux-2.6.20
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32169
--
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
Reported
--- 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
Status|ASSIGNE
--- 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
Status|ASSIGNED
--- 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
Status|ASSIGNED
--- 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=gcc&view=rev&rev=125235
Log:
2007-05-31 Paul Thomas <[EMAIL PROTECTED]>
backport fr
--- 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=gcc&view=rev&rev=125235
Log:
2007-05-31 Paul Thomas <[EMAIL PROTECTED]>
backport f
--- 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=gcc&view=rev&rev=125235
Log:
2007-05-31 Paul Thomas <[EMAIL PROTECTED]>
backport f
--- 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=gcc&view=rev&rev=125235
Log:
2007-05-31 Paul Thomas <[EMAIL PROTECTED]>
backport fr
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 -W
--- 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
--- 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 #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:11 ---
*** Bug 32168 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
[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;
}
voi
--- 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=13639&action=view)
from linux-2.6.20
--
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
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 include/li
--- 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
--- 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 gc
--- 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=gcc&view=rev&rev=125229
Log:
PR c++/31806
* decl.c (cp_finish_decl): Also clea
--- 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 #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=gcc&view=rev&rev=125228
Log:
PR tree-optimization/32160
* tree-predcom.c (
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
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 ::main
--- 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
(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 #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 einfo.adb:
--- 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 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:
http://gcc.gnu.org/ml/gcc-patc
--- 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 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
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known t
--- 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 dot
--- 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
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- 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
GCC build t
--- 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 not-f
--- 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 #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=13638&action=view)
Preprocessed source of the file that causes the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
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
-Wno-unused-par
--- 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
--- 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=gcc&view=rev&rev=125223
Log:
2007-05-31 Paolo Carlini <[EMAIL PROTECTED]>
PR c++/3
--- 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
struct C1 {};
struct C2 : C1 {
};
C1 c1;
C2 c2;
void f(C1);
template vo
--- 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
Status
--- 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 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 PROTEC
--- 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 #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
1 - 100 of 110 matches
Mail list logo
