--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 06:58 ---
if (TARGET_BIG_ENDIAN)\
{ \
builtin_define_std ("MIPSEB");\
builtin_
sunday-go-to-meeting Cutie doinng surpass blowjobb!
http://progblemasdefgo.com
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2006-10-12 04:51 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
On Wed, Oct 11, 2006 at 09:45:02PM -, dave at hiauly1 dot hia dot nrc dot
ca wrote:
>
> >
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-10-12 04:39
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-10-12 04:36
---
Subject: Bug 29175
Author: mmitchel
Date: Thu Oct 12 04:35:56 2006
New Revision: 117658
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117658
Log:
PR c++/29175
* decl.c (check_initializer):
--- Comment #8 from bangerth at dealii dot org 2006-10-12 04:27 ---
I don't believe the code is valid.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-12 04:13
---
Subject: Bug 28302
Author: pinskia
Date: Thu Oct 12 04:13:36 2006
New Revision: 117657
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117657
Log:
2006-10-11 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-12 04:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-12 04:09 ---
Confirmed, this is an user visable regression in that the code did not ICE in
3.2.3 even though the attribute is ignored.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-12 03:57
---
The problem is that we have not layouted out the type yet, if we had with
something like:
template < class T >
struct Rgb{};
Rgb t;
template < int>int Camera1 ()
{
sizeof (Rgb < int>);
}
We don't crash.
Something
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-12 03:48 ---
Also ICEs with 4.2.0 20061012 but did not with 4.2.0 20061002 (which I think
was built before PR 29226 came in).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-12 03:44 ---
I think this was caused by PR 29226.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-12 03:39 ---
Works in 4.0.4 20061011.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-12 03:37 ---
The code in comment # 5 is invalid but even if we make it valid like below, it
still ICEs:
template < class T > struct Rgb{};
template < int>int Camera1 ()
{
sizeof (Rgb < int>);
}
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-12 03:36 ---
Reduced testcase:
template < class T > struct Rgb;
template < int>int Camera1 ()
{
sizeof (Rgb < int>);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
--- Comment #3 from bangerth at dealii dot org 2006-10-12 02:06 ---
Forget this, the type of the rhs is of course an rvalue of type Base,
there is no need to copy the entire Derived object.
W.
--
bangerth at dealii dot org changed:
What|Removed |A
--- Comment #2 from bangerth at dealii dot org 2006-10-12 01:52 ---
It is infact: this is a cleaned up version of that PR, but actually handles
the thing that is wrong, whereas PR 28169 was talking about something that
wasn't a bug at all.
W.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #5 from bangerth at dealii dot org 2006-10-12 01:50 ---
gcc is correct. It is true that the result of the ?: operator is
a reference to the Base object of the Derived object created in the
second arm. However, the result is an rvalue, and a constant reference
is initialized w
--- Comment #3 from bangerth at dealii dot org 2006-10-12 01:49 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 01:49 ---
I think this is a dup of bug 28169.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29437
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:47 ---
I can confirm that this is apparently fixed now.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:45 ---
Confirmed. The template version doesn't compile, whereas the non-template
version does.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #1 from bangerth at dealii dot org 2006-10-12 01:43 ---
Confirmed. To make things more interesting, gcc presently gives me
the warning twice:
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc -Wall
x.cc: In function ‘int main()’:
x.cc:5: warning: null argument where non-nu
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:41 ---
Are there any plans to backport the fix to 4.0.x, or should this bug be
closed as a WONTFIX on that branch?
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #1 from bangerth at dealii dot org 2006-10-12 01:39 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
[decl.init.ref]/5 has the following text for initialization of
constant references with rvalues:
5 A reference to type "cv1 T1" is initialized by an expression of type
"cv2 T2" as follows:
[...]
-- If the initializer expression is an rvalue, with T2 a class
type, and "cv1 T
--- Comment #2 from acahalan at gmail dot com 2006-10-12 01:25 ---
Hey, I don't even need to use the types. The typedef alone
is enough to ICE gcc:
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
int main(int argc, char *argv[]){
--- Comment #4 from bangerth at math dot tamu dot edu 2006-10-12 01:25
---
Subject: Re: bad break/continue is not dectected until the
gimplifier
> Yes but this semantics anyalsis is done while gimplifing and not while
> parsing.
But I get the message also when using -fsyntax-only.
--- Comment #1 from acahalan at gmail dot com 2006-10-12 01:20 ---
Other ways to ICE gcc:
///
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
S_t *handler(void *vp)
{
cmonkey *cm = vp;
return c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-12 01:12 ---
(In reply to comment #2)
> What exactly is the problem here? I get this as an error message:
>
> g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
> x.cc: In function ‘void f()’:
> x.cc:3: error: break statement n
--- Comment #2 from bangerth at dealii dot org 2006-10-12 01:08 ---
What exactly is the problem here? I get this as an error message:
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In function ‘void f()’:
x.cc:3: error: break statement not within loop or switch
That seems ac
--
bangerth at dealii dot org changed:
What|Removed |Added
Known to work||4.2.0
Target Milestone|4.1.2 |4.2.0
http://gcc.
--- Comment #19 from bangerth at dealii dot org 2006-10-12 01:06 ---
Since this is solved on mainline and nobody seems to have been able to
ever reproduce it anyway, there doesn't seem to be a chance of this
being actively worked on on older release branches. I'll therefore close
it. We
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:03 ---
The operator== you want to call is used in a context in which the
template argument cannot be deduced (a "non-deduceable context").
If you want to use this construct, you will have to write something like
templated_
--- Comment #2 from bangerth at dealii dot org 2006-10-12 00:56 ---
Why exactly do you think that the empty base should not be located at
the same address as the simple_base base object?
W.
--
bangerth at dealii dot org changed:
What|Removed |Adde
$ cat ice.c
typedef struct S {
unsigned long flags;
}S_t;
struct dp {
S_t c;
};
typedef S_t __attribute__((__may_alias__)) cmonkey;
static void handler(void *vp)
{
struct dp *dp;
cmonkey *cm = vp;
dp->c = *cm;
}
$ gcc -m32 -std=gnu99 -W -Wall -g3 -c ice.c
ic
--- Comment #3 from bangerth at dealii dot org 2006-10-12 00:41 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #1 from bangerth at dealii dot org 2006-10-12 00:39 ---
> int array3[(const unsigned short) (20.5 * 3)];
>
> error message from compiler is:
> "error: array bound is not an integer constant"
>
> to me this is wrong because the expression "(const unsigned short) (20.5 * 3)"
--- Comment #7 from debian-gcc at lists dot debian dot org 2006-10-12
00:37 ---
fails with trunk 20061012 as well.
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
-
--- Comment #3 from patchapp at dberlin dot org 2006-10-12 00:15 ---
Subject: Bug number PR29371
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-10/msg00635.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from brooks at gcc dot gnu dot org 2006-10-12 00:07 ---
On a similar note, the following is legal code for which an error is
incorrectly reported:
>> $ cat pr20863a.f90
>> PURE FUNCTION give_next(i)
>> TYPE node_type
>>sequence
>>TYPE(node_type), POIN
--- Comment #4 from tbm at cyrius dot com 2006-10-11 23:19 ---
(gdb) where
#0 0x0045a5ce in cxx_sizeof_or_alignof_type (type=0x2b29cf3e6b00,
op=214, complain=1 '\001')
at /home/tbm/scratch/gcc-4.1/gcc/cp/typeck.c:1251
#1 0x0044a947 in cp_parser_unary_expression (par
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-11 23:05 ---
I think this is a sizeof issue:
sizeof (Rgb < XYindex >)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
--- Comment #2 from tbm at cyrius dot com 2006-10-11 23:02 ---
Ignore my comment about x86_64. I also see this on mips.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
--- Comment #1 from tbm at cyrius dot com 2006-10-11 23:01 ---
Created an attachment (id=12413)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12413&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
I get a segmentation fault compiling the attached testcase with gcc 4.1. 4.0
and 4.2 seem to work. 4.1.2 20060901 (Debian 4.1.1-13) also worked but
4.1.2 20061007 (Debian 4.1.1-16) fails, at least on x86_64.
(sid)1142:[EMAIL PROTECTED]: ~] g++-4.1 -c cinepaint-plugin_main.cpp
cinepaint-plugin
--
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 #1 from mmitchel at gcc dot gnu dot org 2006-10-11 22:30
---
This patch is OK, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-11 22:04
---
This is fixed now. Or was invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from brooks at gcc dot gnu dot org 2006-10-11 22:00 ---
As per discussion on the fortran@ mailing list, the answer returned by gfortran
and ifort (namely, that LBOUND(x%a) is the same as LBOUND(y)) is
standard-conforming, and g95 is in error.
--
http://gcc.gnu.org/bug
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-11 21:56 ---
Confirmed. Uses a lot of memory.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from laurent at guerby dot net 2006-10-11 21:53 ---
Confirmed.
$ gcc -c -gnat05 ada_3d-file_io-step_reader.adb
+===GNAT BUG DETECTED==+
| 4.2.0 20060922 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure
sinfo.adb:
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11
21:45 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
> Do you have scalbnf?
No. Just scalbn.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=294
--- Comment #28 from tromey at gcc dot gnu dot org 2006-10-11 21:06 ---
I doubt those configure warnings are very important.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
--- Comment #12 from dannysmith at users dot sourceforge dot net
2006-10-11 20:54 ---
(In reply to comment #4)
> - __gnu_cxx::__recursive_mutex static_mutex;
> + static __gnu_cxx::__recursive_mutex static_mutex;
I tried thaty before I submitted bug report. No dice.
(In reply to com
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-11 20:43 ---
Created an attachment (id=12412)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12412&action=view)
The correct fix for this PR
THis turns out to be completely specific to nullify, or to a pointer assign to
NULL()
--- Comment #11 from bkoz at gcc dot gnu dot org 2006-10-11 20:18 ---
Subject: Bug 29426
Author: bkoz
Date: Wed Oct 11 20:18:36 2006
New Revision: 117643
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117643
Log:
2006-10-11 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libst
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-10-11 19:43
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Ass
--- Comment #15 from mi at aldan dot algebra dot com 2006-10-11 19:38
---
Removing either the line 16037 or the 15167 in the loctest.ii gets rid of the
problem.
The lines both reference a string literal ("en_GB_EURO"), thus the bug, likely,
has something to do with how the identical li
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 19:36 ---
This takes 79% of my 2GB of memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
--- Comment #10 from echristo at apple dot com 2006-10-11 19:34 ---
Testing on darwin, the patch seems to get rid of the massive failures I was
seeing.
Thanks Ben.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-10-11 19:31
---
Subject: Bug 29024
Author: lmillward
Date: Wed Oct 11 19:31:33 2006
New Revision: 117641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117641
Log:
PR c++/29024
* cp-tree (struct cp_decl_s
--- Comment #3 from grayyoga at gmail dot com 2006-10-11 19:14 ---
Created an attachment (id=12411)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12411&action=view)
Command Line and Error Message
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
--- Comment #2 from grayyoga at gmail dot com 2006-10-11 19:13 ---
Created an attachment (id=12410)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12410&action=view)
gcc -V output
version and configuration information on the used gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
The following code (derived from alloc_comp_constructor_1.f90):
! { dg-do run }
! { dg-options "-fdump-tree-original" }
! Test constructors of derived type with allocatable components (PR 20541).
!
! Contributed by Erik Edelmann <[EMAIL PROTECTED]>
!and Paul Thomas <[EMAIL PROTECTED]
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-10-11 19:11 ---
Hmm. Eric, are you testing this on mingw32, or on darwin? If darwin, is this
the cause of the recent massive failures?
If so, I'll put this in immediately. If you can let me know in the next 2-3
hours I can get it in
--- Comment #1 from grayyoga at gmail dot com 2006-10-11 19:10 ---
Created an attachment (id=12409)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12409&action=view)
preprocessed source file
This is output of the compiler with the -save-temps switch. It's compressed
'cause there is
Here is a code which doesn't compile. It takes all swap space (around 2GB) and
all system memory(about 1GB), compiles around 15-20 minutes and then crashes
with the following message : "g++: Internal error: Killed (program cc1plus)"
--
Summary: Internal error while compiling code usin
--- Comment #3 from dominiq at lps dot ens dot fr 2006-10-11 18:31 ---
Subject: Re: ICE with allocatable
> Since I posted the patch, I had better take it unto myself!
Be my guest!-)
Dominique
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2006-10-11 18:30 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
> > Does youir OS have fabsf, frexpf, and ldexpf?
>
> Yes, no, no. It has frexp and ldexp.
>
--- Comment #8 from echristo at apple dot com 2006-10-11 18:24 ---
OK. Seems to be working (i.e. build succeeded and testing isn't blowing up).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #7 from echristo at apple dot com 2006-10-11 18:14 ---
I'm testing it now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11
17:57 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
> > Done. The error still occurs. I don't see the symbol in any of the
> > library .o files.
> >
>
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-11 17:42 ---
Since I posted the patch, I had better take it unto myself!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from mi at aldan dot algebra dot com 2006-10-11 17:15
---
Ok, the problem is triggered by the ``-march=pentium4'' flag:
c++ -O0 -g -c -fno-strict-aliasing -pipe -march=pentium4 loctest.ii
[EMAIL PROTECTED]:source/test/intltest (1127) nm loctest.o | grep LC
U .L
--- Comment #13 from eweddington at cso dot atmel dot com 2006-10-11 17:05
---
(In reply to comment #12)
> I can confirm that this bug still exists on with avr-gcc (GCC) 4.0.2 (running
> on Mac OS X 10.4.8/PPC, installed via Macports)
> Is there any news on this bug?
Sorry, no. Your
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-11 17:05 ---
Subject: Re: implicit type declaration and contained function
clash
tobi at gcc dot gnu dot org wrote:
>--- Comment #6 from tobi at gcc dot gnu dot org 2006-10-11 16:07 ---
>You're working too fast, Paul.
--- Comment #7 from patchapp at dberlin dot org 2006-10-11 17:00 ---
Subject: Bug number PR29373
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-10/msg00620.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2006-10-11 16:53 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
On Wed, Oct 11, 2006 at 04:30:20PM -, dave at hiauly1 dot hia dot nrc dot
ca wrote:
>
> D
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-11 16:47 ---
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
First, you should have reported it to redhat first.
Second I cannot reproduce this in 3.4.0, 4.0.0 or 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
Wha
The following code, when compiled using optimization (-O1, at least), produces
a segfault after several iterations of the loop. I have reproduced the bug on
two machines running the same OS and version of gcc:
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with:
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11
16:30 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
> --- Comment #1 from kargl at gcc dot gnu dot org 2006-10-10 22:34 ---
> Update your source d
--- Comment #6 from tobi at gcc dot gnu dot org 2006-10-11 16:07 ---
You're working too fast, Paul. Before I even got to read your answer you
already bring forward a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-10-11 16:06
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-10-11 16:05
---
Subject: Bug 28230
Author: rguenth
Date: Wed Oct 11 16:05:37 2006
New Revision: 117637
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117637
Log:
2006-10-11 Richard Guenther <[EMAIL PROTECTED]>
In fixing PR29373, I separated off the part to do with the function declaration
from that triggered by the constructor.
! { dg-do compile }
! Tests patch for PR29373, in which the implicit character
! statement messes up the function declaration because the
! requisite functions in decl.c were tol
--- Comment #4 from patchapp at dberlin dot org 2006-10-11 15:35 ---
Subject: Bug number PR27701
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-10/msg00615.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-11 14:56 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-11 14:55 ---
Subject: Bug 29002
Author: pinskia
Date: Wed Oct 11 14:55:07 2006
New Revision: 117635
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117635
Log:
2006-10-11 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-10-11 14:48 ---
Created an attachment (id=12408)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12408&action=view)
patch
Please try this and see if it works. If so, let me know.
-benjamin
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 14:44 ---
http://www.codecomments.com/archive263-2005-8-441109.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-11 14:28 ---
(In reply to comment #2)
> You need to look at preprocessed source. sig_atomic_t should have volatile
> qualifier on it.
It is not marked for glibc 2.4:
typedef int __sig_atomic_t;
typedef __sig_atomic_t sig_atomi
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-11 14:03 ---
Subject: Bug 29119
Author: rguenth
Date: Wed Oct 11 14:03:37 2006
New Revision: 117633
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117633
Log:
2006-10-11 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-11 14:03 ---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #3 from anlauf at gmx dot de 2006-10-11 13:58 ---
(In reply to comment #2)
> I'll note that the Portland, Intel and g95 compilers do not see this issue
> either.
Well, I get a bounds violation with current versions of g95 (0.91)
on both Linux and Cygwin:
% g95 -g -fbounds-c
--- Comment #6 from patchapp at dberlin dot org 2006-10-11 13:31 ---
Subject: Bug number PR29119
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-10/msg00612.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-11 13:17
---
I'll note that the Portland, Intel and g95 compilers do not see this issue
either. SunStudio does, at runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-11 13:12 ---
You need to look at preprocessed source. sig_atomic_t should have volatile
qualifier on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
1 - 100 of 123 matches
Mail list logo
