--- Comment #6 from patchapp at dberlin dot org 2006-04-28 08:00 ---
Subject: Bug number PR24813
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/msg01075.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-04-28 08:44 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01078.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from guillaume dot melquiond at ens-lyon dot fr 2006-04-28
09:03 ---
I tried setting the nonnull attribute, it indeed allowed the optimization. In
particular, codes containing dynamic casts are now straight lines. This is a
nice improvement. Unfortunately GCC was not able
--- Comment #3 from patchapp at dberlin dot org 2006-04-28 09:15 ---
Subject: Bug number PR27269
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/msg01079.html
--
http://gcc.gnu.org/bugzilla/sh
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-28 09:33 ---
VRP could extract this information just like it does for loads in
void bar(int);
int foo(int *i)
{
bar(*i);
return i == NULL;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
$ cat exp.cpp
template struct type_name { static char const name[]; };
template char const type_name::name[] = "";
template<> char const type_name::name[] = "int";
$ g++ -v exp.cpp
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--- Comment #2 from marc dot glisse at normalesup dot org 2006-04-28 10:33
---
(In reply to comment #1)
> Both libc and libstdc++ are considered part of the implementation which means
> both are valid to use this name space.
Which means both should take care not to use a name (in this
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-28 11:43
---
Subject: Bug 27218
Author: rguenth
Date: Fri Apr 28 11:43:43 2006
New Revision: 113343
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113343
Log:
2006-04-28 Andrew Pinski <[EMAIL PROTECTED]>
Rich
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-28 11:43 ---
Subject: Bug 27236
Author: rguenth
Date: Fri Apr 28 11:43:43 2006
New Revision: 113343
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113343
Log:
2006-04-28 Andrew Pinski <[EMAIL PROTECTED]>
Richar
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-28 11:43
---
Subject: Bug 26869
Author: rguenth
Date: Fri Apr 28 11:43:43 2006
New Revision: 113343
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113343
Log:
2006-04-28 Andrew Pinski <[EMAIL PROTECTED]>
Rich
If you use memcmp to compare strings, it does not stop reading when it
finds the terminating null byte of the shortest string, which can
trigger an attempt to read unallocated memory. I'd recommend
replacing instances of memcmp on strings with strncmp, which won't
attempt to read past the end of
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-28 12:11
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-28 12:11
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-28 12:12
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-28 13:33 ---
Confirmed. Regression with the new C++ parser.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-28 13:36 ---
In this particular case this should not happen as the memcmp is guarded by the
length comparison before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27348
--- Comment #3 from fnf at specifix dot com 2006-04-28 13:54 ---
Subject: Re: memcmp reads past end of strings
On Friday 28 April 2006 09:36, rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-28 13:36
> ---
> In this particu
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-28 14:06 ---
This is really because we do not decompose structs pointed to by parameters for
their elements, so a write to an int clobbers all of plan7_s.
With -O2 timings on i686 are for me (averages of three runs)
3.4.65.
--
Summary: Fortran function returns are not correct in c on X86_64
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
gcc3.4.4 on x86_64
When a c program calls a fortran function which returns a "real" value
the c program gets the wrong answer.
--
Summary: Fortran function returns are not correct in c on X86_64
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
--- Comment #1 from ray at ultramarine dot com 2006-04-28 14:25 ---
Created an attachment (id=11343)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11343&action=view)
All necessary files to produce the bug
go is a csh script that compiles the fortran, compiles the c, links and runs
I got
[EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gcc -ffixed-form
-ffixed-line-length-132 -O2 bifoag.f90 -c
bifoag.f90: In function âbifoagâ:
bifoag.f90:127: internal compiler error: in gfc_conv_array_transpose, at
fortran/trans-array.c:726
Please submit a full bug report,
with preprocessed sou
--- Comment #11 from patchapp at dberlin dot org 2006-04-28 14:35 ---
Subject: Bug number PR26726
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/msg01095.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-28 14:36
---
Subject: Bug 26826
Author: rguenth
Date: Fri Apr 28 14:36:14 2006
New Revision: 113348
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113348
Log:
2006-04-28 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-28 14:40
---
Subject: Bug 26826
Author: rguenth
Date: Fri Apr 28 14:40:51 2006
New Revision: 113349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113349
Log:
2006-04-28 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-28 14:46 ---
*** This bug has been marked as a duplicate of 27350 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-28 14:46 ---
*** Bug 27349 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27350
With the attached testcase, SecurityManager.checkPermission() is called three
times when it should only be called once. In genral, we make far too many
invocations of SecurityManager.checkPermission().
--
Summary: SecurityManager.checkPermission() called unnecessarily
Prod
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-28 15:02 ---
Confirmed with 3.3-hammer. Fortran returns as double if using xmm registers,
so your C prototype is wrong in this case. It is fixed with gfortran in 4.1.0
at least, and 3.4 is no longer maintained.
--
rguenth a
--- Comment #2 from Georg dot Baum at post dot rwth-aachen dot de
2006-04-28 15:05 ---
The patch at http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01084.html fixes the
problem for me. Now my code compiles without optimization, but with -O1 or
higher I get a different ICE without file loca
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-28 15:07 ---
One incremental fix for the global var case is:
--- omp-low.c.jj5 2006-04-28 13:29:49.0 +0200
+++ omp-low.c 2006-04-28 16:22:36.0 +0200
@@ -674,9 +674,6 @@ omp_copy_decl (tree var, copy_body_dat
--- Comment #1 from aph at gcc dot gnu dot org 2006-04-28 15:16 ---
Created an attachment (id=11344)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11344&action=view)
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27352
--- Comment #2 from aph at gcc dot gnu dot org 2006-04-28 15:18 ---
The output of this test should be something like:
java.lang.Throwable
at MySecurityManager.checkPermission(t.java:33)
at java.lang.Class.getClassLoader(Class.java:580)
at trial.x(trial.java:5)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 16:29 ---
(In reply to comment #3)
> Ok, you are right. it would be nice if g++ 4.1.0 acts as what g++ 3.3.4 does.
Use -fwrapv if you want defined wrapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-28 16:34 ---
We need a testcase, not every one has access to galgel.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-28 16:38 ---
Doesn't seem to be openmp specific:
struct A
!
{
template void foo();
};
template void A::foo<0>();
ICEs the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27315
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-28 16:39 ---
Doesn't seem to be openmp specific.
struct A {};
struct B : A
!
{};
struct B : A
!
{};
ICEs the same way.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from jakub at gcc dot gnu dot org 2006-04-28 16:42 ---
Neither of the testcases are openmp specific, after
s/#pragma omp parallel/!/g
they crash the same way without -fopenmp.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-28 16:44 ---
Then this is a regression since that testcase did not produce an ICE in 3.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from malitzke at metronets dot com 2006-04-28 16:46 ---
After compiling gcc-4.1.1 successfully on a powerpc and another pentium3
machine it appears that the problem reported was due to bit-rot in the server
and not caught by svn updates. This appears to be confirmed by era
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-28 16:46 ---
This does not ICE with checking turned off and it has failed since 3.4.0 (and I
don't have a checking build before the 3.4.0).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 16:48 ---
Confirmed, a regression from at least 3.4.0 (I have only a 4.0.0 right before
the branch of 4.0).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 16:57 ---
This is interesting because this might be a regression as people have run with
valgrind before.
It might also be a valgrind bug.
Or maybe just an off by one bug.
Anyways changing to use strncmp is not correct he
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-28 17:39 ---
This is a documentation regression as now, the builtins are inconstaint with
the source.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-28 17:41 ---
This is a dup of bug 25519. SSE3 (and when SSE4 support gets checked in, it
will also have the same issue).
*** This bug has been marked as a duplicate of 25519 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 17:41 ---
*** Bug 23218 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from hjl at lucon dot org 2006-04-28 17:52 ---
Failed:
gcc version 4.2.0 20060417 (experimental) [trunk revision 113003 clean]
Worked:
gcc version 4.2.0 20060416 (experimental) [trunk revision 112982 clean]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
--- Comment #21 from dberlin at gcc dot gnu dot org 2006-04-28 18:26
---
Subject: Bug 26626
Try this patch, it should work :)
--- Comment #22 from dberlin at gcc dot gnu dot org 2006-04-28 18:26
---
Created an attachment (id=11345)
--> (http://gcc.gnu.org/bugzilla/attachme
--- Comment #3 from hjl at lucon dot org 2006-04-28 18:32 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00537.html
causes this regression. But galgel doesn't fail on ia64 nor x86-64.
--
hjl at lucon dot org changed:
What|Removed |Ad
--- Comment #4 from hjl at lucon dot org 2006-04-28 18:38 ---
Even more interesting, gcc -m32 works fine on x86-64:
[EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gfortran-ffixed-form
-ffixed-line-length-132 -m32 -O2 bifoag.f90 -S
[EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/b
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-28 18:57 ---
Looks related to PR 26119 which is hard to reproduce.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-28 19:02 ---
Actually I thought you were using valgrind. Anyways this is a mudflap issue so
reopening since mudflap is part of GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from dnovillo at gcc dot gnu dot org 2006-04-28 19:02
---
(In reply to comment #0)
> The gimplifier should not be emitting errors.
>
Why, exactly? Some diagnostics are impossible to emit early enough. Is this a
documented requirement? What's the rationale?
--
ht
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-28 19:05 ---
(In reply to comment #1)
> Why, exactly? Some diagnostics are impossible to emit early enough. Is this
> a
> documented requirement? What's the rationale?
Read the comments in PR 24222 but basicially the gimpli
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-28 19:06 ---
Small testcase:
char a[] = "tree.h";
char b[] = "treelang";
int main(void)
{
return memcmp (a, b, strlen(b)) != 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-04-28 19:17
---
(In reply to comment #2)
> Read the comments in PR 24222 but basicially the gimplifier is not should not
> being doing any semantic anlyasis, that is the job of the front-end.
>
Well, some of the structural analy
>
>
>
> --- Comment #3 from dnovillo at gcc dot gnu dot org 2006-04-28 19:17
> ---
> Well, some of the structural analysis for which emit errors is done even later
> than that, so it would be naive to pretend that we can catch everything during
> parsing.
I don't understand why it is
--- Comment #4 from pinskia at physics dot uc dot edu 2006-04-28 19:20
---
Subject: Re: [4.2 Regression] Some OpenMP semantics are caught too late (in
the gimplifier)
>
>
>
> --- Comment #3 from dnovillo at gcc dot gnu dot org 2006-04-28 19:17
> ---
> Well, some of the st
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-28 19:26 ---
The code is invalid. Anybody knows a trick to have a POD storage for non-POD
n-"dimensional" object which individual elements can be accessed using a
specialized 1-"dimensional" non-POD object? POD storage to avoid
--- Comment #7 from sayle at gcc dot gnu dot org 2006-04-28 20:00 ---
Subject: Bug 25309
Author: sayle
Date: Fri Apr 28 19:59:57 2006
New Revision: 113355
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113355
Log:
PR c/25309
* c-typeck.c (struct spelling): Make
--- Comment #3 from pcarlini at suse dot de 2006-04-28 20:01 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Both libc and libstdc++ are considered part of the implementation which
> > means
> > both are valid to use this name space.
>
> Which means both should take care no
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-28 20:22 ---
Ok, this one does it, just for the curious:
template
struct Loc;
struct LocStorage
{
int x;
};
template <>
struct Loc<1> : public LocStorage
{
Loc() {}
Loc(int i) { this->x = i; }
Loc<1>& operator[](int)
--- Comment #4 from marc dot glisse at normalesup dot org 2006-04-28 20:43
---
(In reply to comment #3)
> Well, I think Andrew has a point: suppose we rename all those functions to
> _M_cos and co. Then, later, we discover that a third libc (not Solaris, not
> GNU) conflicts with those
--- Comment #5 from pcarlini at suse dot de 2006-04-28 21:18 ---
(In reply to comment #4)
> Convinced of what?
Of course convinced that before renaming and re-renaming (endlessly, in
principle) we should really give some serious tought to those issues, figure
out what we are trying to
--- Comment #6 from hjl at lucon dot org 2006-04-28 21:28 ---
It looks that either the Fortran patch has a memory leak or it triggers a
memory leak since
gfc_add_modify_expr (&se->pre,
gfc_conv_descriptor_dtype (dest),
gfc_conv_descriptor_
--- Comment #6 from marc dot glisse at normalesup dot org 2006-04-28 21:57
---
(In reply to comment #4)
> Should all those private classes and functions be declared in some
> specific namespace std::glibcxx_private to have a single point of failure?
Oups, I just noticed that was one o
--- Comment #7 from hjl at lucon dot org 2006-04-28 22:01 ---
I am not sure if I can post galgel source. I can't find a small testcase.
In gfc_conv_array_transpose, we first got
708 gfc_conv_expr_descriptor (&src_se, expr, src_ss);
(gdb) p src_ss
$40 = (gfc_ss *) 0x9871e10
(gdb)
I am using
gcc version 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)
on
Linux 2.6.15-gentoo-r1 #1 PREEMPT Tue Mar 21 18:53:15 CET 2006 Intel(R)
Pentium(R) M processor 1.60GH
Following code crashes gcc when compiled with
> gcc -O2 -msse2 -c test3.cpp
or
> gcc -O3 -msse2 -c test3.cpp
//
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-04-28 22:25
---
Here is valgrind report using allocate_zerosize.f90 as a testcase. This is
definitely a memory leak problem:
--4718-- supp: 13 dl_relocate_object
==4718== malloc/free: in use at exit: 21254 bytes in 131 blocks
Using valgrind:
valgrind -v --leak-check=full gfc -v
--snip--
==4758== 30 bytes in 1 blocks are definitely lost in loss record 1 of 6
==4758==at 0x1B909222: malloc (vg_replace_malloc.c:130)
==4758==by 0x805D708: make_relative_prefix (make-relative-prefix.c:361)
==4758==by 0x804D36C
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-04-28 22:34
---
I see that one of these leaks has nothing to do with gfortran.
So maybe I have not captured anything related to this bug.
See PR27354 which I just submitted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-04-28 22:36
---
The patch looks good to me, thanks, and should be small enough to
avoid the need for a copyright assignment. I'll apply it next week.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from hjl at lucon dot org 2006-04-28 22:47 ---
Does f951 call make_relative_prefix?
--
hjl at lucon dot org changed:
What|Removed |Added
Summar
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-28 22:49
---
First this is not a memory leak.
Second make_relative_prefix is inside the driver.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
I merged the source, gcc-4.1.0 on top of binutils-2.16.92 on top of
newlib-1.14.0, using cpio. (binutils-2.16.92 is the Release Candidate for
2.17.) I tried to bootstrap, using a GCC 3.4.3 as the starting point.
The bootstrap failed with:
[Condensing to $b, to $i, to $src,
and neatening a bit
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-04-28 23:55
---
Subject: Bug 27304
Author: jvdelisle
Date: Fri Apr 28 23:55:30 2006
New Revision: 113363
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113363
Log:
2006-04-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-04-29 00:02
---
Subject: Bug 27304
Author: jvdelisle
Date: Sat Apr 29 00:02:10 2006
New Revision: 113364
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113364
Log:
2006-04-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from janis at gcc dot gnu dot org 2006-04-29 00:02 ---
I tried the patch at http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01061.html on
powerpc64-linux and used the resulting compilers with "-O2 -fmodulo-sched" to
build SPEC CPU2000 and run with the small, test input, and a
--- Comment #8 from vapier at gentoo dot org 2006-04-29 00:17 ---
passes for me with 4.0.[123] but 4.2.0 fails (i'd update the Known fields but
lack the power)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23820
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-29 02:29 ---
Just for other people's referecne, the link to the binutils thread is:
http://sourceware.org/ml/binutils/2006-04/msg00383.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27355
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-29 03:29
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-29 03:35 ---
The problem I think is the non specialization is getting in the way in that:
template char const type_name::name[] = "";
is recording the size as 1.
Another testcase with a slightly different error:
emplate struct t
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-04-29 04:02
---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from zadeck at naturalbridge dot com 2006-04-29 04:23
---
Subject: Re: [4.2 Regression] ICE in add_deps_for_def
with -fmodulo-sched -maltivec
janis at gcc dot gnu dot org wrote:
> --- Comment #7 from janis at gcc dot gnu dot org 2006-04-29 00:02 ---
> I tried
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-04-29 04:27
---
Subject: Bug 20257
Author: jvdelisle
Date: Sat Apr 29 04:27:09 2006
New Revision: 113373
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113373
Log:
2006-04-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-29 04:42 ---
Fixed in 4.0.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-04-29 04:55
---
(In reply to comment #2)
> In addition to this, I'm not sure what exactly the standard requires say when
> firstprivate is used on a global var. The global var can be visible to the
> threads and they can modify
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-29 05:29 ---
This is a bug in Apple's asm.
The rtl which produces this asm is:
(insn:TI 45 44 47 (set (mem:SF (reg/v/f:SI 4 si [orig:75 res ] [75]) [10 S4
A32])
#(float_truncate:SF (reg:DF 8 st))) 91 {*truncdfsf_fast_i387
--- Comment #6 from vapier at gentoo dot org 2006-04-29 05:37 ---
i hit this same issue and the real error was being masked by the shell script:
if $compile -c tmp$$.f90 > /dev/null 2>&1; then
turns out the compile step was ICEing resulting in $largest_ctype not being
reset from "" ...
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-04-29 05:47
---
Fixed on Trunk and now 4.1 branch
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.5 |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27316
95 matches
Mail list logo
