--- Comment #1 from prj-bugzilla-gcc at multivac dot cwru dot edu
2005-12-21 07:11 ---
Created an attachment (id=10540)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10540&action=view)
3.4.5 bootstrap-lean build log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25511
bootstrap-lean fails for me with gcc 3.4.3-3.4.5. It looks like it goes
through the bootstrap, comparison, and deletion of stage2, but then tries to
use stage2 to build the runtime libraries.
--
Summary: bootstrap-lean fails
Product: gcc
Version: 3.4.5
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-12-21 06:56
---
This is now fixed for the specific test case. 4.1 and 4.2 are in sync. I plan
to go back and review for other possible cases of whitespace. Just want to
keep this synchronized.
--
http://gcc.gnu.org/bugzill
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2005-12-21 06:52
---
Subject: Bug 24268
Author: jvdelisle
Date: Wed Dec 21 06:52:38 2005
New Revision: 108900
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108900
Log:
2005-12-20 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2005-12-21 06:51
---
Subject: Bug 24268
Author: jvdelisle
Date: Wed Dec 21 06:51:02 2005
New Revision: 108899
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108899
Log:
2005-12-20 Jerry DeLisle <[EMAIL PROTECTED]>
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25382
--- Comment #2 from kazu at gcc dot gnu dot org 2005-12-21 05:58 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-12-21 05:58
---
Possible places to check. If the error is on actual file IO will leave it as
is:
io/file_pos.c: generate_error (&fpp->common, ERROR_OS, NULL);
io/file_pos.c: generate_error (&fpp->common, ERROR_OS, NULL);
io/f
--- Comment #1 from kazu at gcc dot gnu dot org 2005-12-21 05:58 ---
Subject: Bug 25382
Author: kazu
Date: Wed Dec 21 05:58:02 2005
New Revision: 108898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108898
Log:
gcc/
PR tree-optimization/25382.
* tree-vrp.c (extr
Need new error types to provide clearer messages rather that use ERROR_OS which
for internal problems reports a run-time error of 'Success'.
--
Summary: Add ERROR_INTERNAL and ERROR_INTERNAL_UNIT
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2005-12-21 05:09
---
Subject: Bug 25463
Author: jvdelisle
Date: Wed Dec 21 05:08:53 2005
New Revision: 108897
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108897
Log:
2005-12-20 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2005-12-21 04:50
---
Subject: Bug 25463
Author: jvdelisle
Date: Wed Dec 21 04:50:19 2005
New Revision: 108896
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108896
Log:
2005-12-20 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from law at redhat dot com 2005-12-21 04:44 ---
Definitely a type problem. The Obj-C front-end is playing it too lose with
types.
main (argc, argv)
{
char msg[100];
int status;
const unsigned char D.1189;
char * msg.0;
# BLOCK 0
# PRED: ENTRY (fallthru)
--- Comment #5 from law at redhat dot com 2005-12-21 04:33 ---
Was able to reproduce with gcc-4.0 branch sources. Investigating, looks like
we might have a type botch somewhere...
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25328
--- Comment #8 from mueller at kde dot org 2005-12-21 04:17 ---
> ok, lets assume that you meant with "can not be ignored" actually "must not >
> be ignored". now thats where the definitions in RFC2119 kick in:
Hmm, that wasn't meant so harsh than it sounds after rereading. sorry abo
--- Comment #7 from mueller at kde dot org 2005-12-21 04:02 ---
ok, lets assume that you meant with "can not be ignored" actually "must not be
ignored". now thats where the definitions in RFC2119 kick in:
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition
--- Comment #6 from joseph at codesourcery dot com 2005-12-21 03:55 ---
Subject: Re: can't voidify __attribute__((warn_unused_result))
On Wed, 21 Dec 2005, pinskia at gcc dot gnu dot org wrote:
> The reason why it is a glibc bug is that it is very over the top of adding the
> attribut
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-21 03:47 ---
Actually it is documented that this is acting the way it is acting, just not
with the docs of the attributes:
Warning when a non-void function value is ignored.
C contains many standard functions that return a value
--- Comment #4 from mueller at kde dot org 2005-12-21 03:35 ---
Care to explain how it is a glibc bug? its not documented that there shouldn't
be a way to suppress the warning.
I agree glibc is overly paranoid and pedantic, but that doesn't make it less of
a gcc issue.
--
mueller
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P3
Summary|[4.1/4.2 Regression] ld |ld segmentation fa
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-21 03:20 ---
This is a glibc bug and not a GCC bug then.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from smithj at rpath dot com 2005-12-21 02:51 ---
oh, and i also get this on 4.0.2, the 4.0 weekly snapshots, and the 4.2
snapshots (sorry, i meant to say that in the first post)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--- Comment #8 from reichelt at gcc dot gnu dot org 2005-12-21 02:49
---
Confirmed. Reduced testcase:
==
template struct A
{
void foo() {}
};
void bar(void (A::*)()) {}
template void baz()
{
bar(&A::foo);
}
int main()
{
baz<0>();
r
--- Comment #1 from smithj at rpath dot com 2005-12-21 02:49 ---
I have this issue as well, but only with x86_64; x86 configures and compiles
fine. x11 and gcc are both built with the same configure options between the
archs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--
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 #2 from mueller at kde dot org 2005-12-21 00:07 ---
background: glibc 2.3 CVS attributes "fwrite" and "write" with it, and it
causes a lot (in the hundreds/thousands) of false positives for bigger software
projects, because while it is indeed the case that they ignore the ret
--- Comment #1 from joseph at codesourcery dot com 2005-12-20 23:53 ---
Subject: Re: New: can't voidify __attribute__((warn_unused_result))
On Tue, 20 Dec 2005, mueller at kde dot org wrote:
> casting to (void) doesn't avoid the unused_result warning. testcase:
Why do you think thi
casting to (void) doesn't avoid the unused_result warning. testcase:
=== Cut ===
extern int foo() __attribute__((warn_unused_result));
int main()
{
(void) foo();
return 0;
}
=== Cut ===
g++ -Wall -W -O2 -c unused.cc
unused.cc: In function 'int main()':
unused.cc:4: warning: ignoring retur
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-12-20 21:53 ---
This looks very much related to PR 16269.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-20 21:50 ---
(In reply to comment #6)
> Re: comment #5:
>
> That is a similar testcase, but not an identical one. A better one would be
> something like:
Actually GCC gets the following testcase "correct":
typedef struct a
{
--- Comment #6 from sabre at nondot dot org 2005-12-20 21:47 ---
Re: comment #5:
That is a similar testcase, but not an identical one. A better one would be
something like:
void foo() {
if (...) {
std::pair = ..
...
}
if (...) {
std::pair = ..
...
}
if (.
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-20 21:44 ---
Small testcase:
typedef struct a
{
int f[1000];
} a;
a f(void);
int g(void)
{
f();
f();
}
Note that the C front-end has always produced bad stack usage.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from law at redhat dot com 2005-12-20 21:33 ---
I've been unable to reproduce this with the gcc-4.1 branch sources. IT's going
to be awful difficult to fix if I can't reproduce the problem.
At the very least I'll need the before-dom dumps and some analysis of whatever
tr
MULTILIB_OSDIRNAMES, as used in target makefile fragments t-*, is undocumented.
--
Summary: MULTILIB_OSDIRNAMES undocumented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
The command-line option -print-multi-os-directory is undocumented.
--
Summary: -print-multi-os-directory undocumented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
A
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-12-20 21:26
---
Working on a patch.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from laurent at guerby dot net 2005-12-20 21:19 ---
Bootstrap started to fail after the following patch:
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 108421)
+++ gcc/ChangeLog (revision 1
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-12-20 20:54
---
Zdenek, please apply to 4.1, too.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Salut !
Royal Contact a maintenant décidé d'orienter sa clientèle dans la tranche d'âge
entre 18 et 40 ans.
Une publicité sera faite dans les CEGEPS et Universités pour recrutter du
nouveau monde.
Si vous êtes dans cette tranche d'âge, Faites-vous une fiche sur le site et une
fois entré, cliq
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-20 20:20 ---
at -O2 -fno-schedule-insns on the mainline:
stwu r1,-17088(r1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-20 20:18 ---
3.3 at -O2 -fno-schedule-insns gave:
stwu r1,-4016(r1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-20 20:15 ---
At -O0 in 4.2.0, we have:
stwu r1,-7920(r1)
as the max. so that is 8k (I have not looked into why there is 8k).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from kazu at gcc dot gnu dot org 2005-12-20 19:58 ---
I've got a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unas
--- Comment #1 from sabre at nondot dot org 2005-12-20 19:57 ---
Created an attachment (id=10537)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10537&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
The SelectCode function requires a huge amount of stack space (over 20K on
darwin-PPC with GCC 4.x. With GCC 3.3 it only took 512 bytes of stack space.
-Chris
--
Summary: gcc uses way too much stack space for this code
Product: gcc
Version: unknown
--- Comment #4 from giles at xiph dot org 2005-12-20 18:46 ---
I think you misunderstood. This is not about rejecting C99 code, this about
warning about portability. I understand it is a C99 feature as well as an
long-standing gnu extension, and -pedantic doesn't reject the program, it j
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-20 18:26 ---
This is not really a bug:
-ansi
In C mode, support all ISO C90 programs. In C++ mode, remove GNU
extensions that
conflict with ISO C++.
The -ansi option does not cause non-I
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-20 18:23 ---
I should note that variable-sized arrays are part of C99.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25504
--- Comment #1 from giles at xiph dot org 2005-12-20 18:22 ---
Created an attachment (id=10536)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10536&action=view)
example which should trigger the warning behavior
Here's an example which triggers the warning (or lack thereof) we ran
I generally expect 'gcc -ansi -Wall' to catch non-portable code, but it does
not throw a warning about variable-size arrays.
'gcc -ansi -pedantic' does throw an appropriate warning. However, it appears
that MSVC still doesn't support this feature, and so I think it would be more
appropriate to thr
--- Comment #3 from pbrook at gcc dot gnu dot org 2005-12-20 18:15 ---
*** Bug 25136 has been marked as a duplicate of this bug. ***
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pbrook at gcc dot gnu dot org 2005-12-20 18:15 ---
Looks like a dup of PR23482
*** This bug has been marked as a duplicate of 23482 ***
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from kargl at gcc dot gnu dot org 2005-12-20 18:15 ---
Subject: Bug 25458
Author: kargl
Date: Tue Dec 20 18:15:19 2005
New Revision: 108861
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108861
Log:
2005-12-20 Steven G. Kargl <[EMAIL PROTECTED]>
Tobi
--- Comment #3 from rth at gcc dot gnu dot org 2005-12-20 18:00 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pbrook at gcc dot gnu dot org 2005-12-20 17:48 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01534.html
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rth at gcc dot gnu dot org 2005-12-20 17:40 ---
Subject: Bug 25240
Author: rth
Date: Tue Dec 20 17:40:17 2005
New Revision: 108859
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108859
Log:
PR preprocessor/25240
* directives.c (run_directive):
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-12-20 17:29
---
> Created an attachment (id=10535)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10535&action=view) [edit]
> fix the #ifndef -> use #ifdef instead
Much better! However:
stage1/xgcc -Bstage1/ -B/opt/build
--- Comment #9 from rguenth at gcc dot gnu dot org 2005-12-20 17:24 ---
Fixed on head and 4.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-20 17:23
---
Subject: Re: [4.0/4.1/4.2 Regression] Forward explicit intantiation
declaration doesn't mix well with static integral member
"fang at csl dot cornell dot edu" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-12-20 17:23 ---
Subject: Bug 24306
Author: rguenth
Date: Tue Dec 20 17:23:12 2005
New Revision: 108857
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108857
Log:
2005-12-20 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #11 from bonzini at gnu dot org 2005-12-20 17:22 ---
patch committed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from bonzini at gnu dot org 2005-12-20 17:06 ---
Subject: Bug 25115
Author: bonzini
Date: Tue Dec 20 17:06:14 2005
New Revision: 108855
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108855
Log:
2005-12-20 Roger Sayle <[EMAIL PROTECTED]>
Paolo Bonzi
--- Comment #22 from kargl at gcc dot gnu dot org 2005-12-20 17:01 ---
The testcase isn't needed and should not be committed.
As explained elsewhere, the problem was caused by merging
one line from a 4.1 patch into 4.0 that should not have
been committed. Jerry has fixed that problem.
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-20 16:44
---
This was discussed after I posted the patch. The GCC format-checking stuff
does not know about the Windows extensions. So, on MinGW, you should
--disable-werror. This bug should be reclassified as a diagnostic b
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-20 16:37 ---
Would be caused by:
2005-08-23 Mark Mitchell <[EMAIL PROTECTED]>
* hwint.h (HOST_WIDE_INT_PRINT): Use HOST_LONG_LONG_FORMAT.
2004-11-23 Mark Mitchell <[EMAIL PROTECTED]>
* hwint.h (HOST_LONG_LON
--- Comment #5 from fang at csl dot cornell dot edu 2005-12-20 16:27
---
Subject: Re: [4.0/4.1/4.2 Regression] Forward explicit
intantiation declaration doesn't mix well with static integral member
> --- Comment #3 from nicos at maunakeatech dot com 2005-12-20 09:20
> ---
>
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-12-20 16:20 ---
Subject: Bug 24306
Author: rguenth
Date: Tue Dec 20 16:20:27 2005
New Revision: 108854
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108854
Log:
2005-12-20 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #4 from bangerth at dealii dot org 2005-12-20 16:14 ---
Yes, you were wrong. This certainly can't be equivalent to the enum snippet
you posted since once can take the address of this static member, but can't
take the address of an enum member.
W.
--
http://gcc.gnu.org/b
--- Comment #14 from steven at gcc dot gnu dot org 2005-12-20 16:11 ---
The patch proposed in bug 25196 comment #8 indeed makes the test case from
comment #6 in this PR work (at least, it stops it from segfaulting).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--- Comment #26 from papadako at csd dot uoc dot gr 2005-12-20 16:07
---
I still can't profiledbootstrap gcc 4.1 branch. Stops with the following
message:
tage1/xgcc -Bstage1/ -B/usr/gcc_4_1/i486-slackware-linux/bin/ -c -O2 -g
-fomit-frame-pointer -fprofile-use -freorder-blocks-and-p
--- Comment #2 from bangerth at dealii dot org 2005-12-20 16:03 ---
Confirmed. The typedef is only rejected if it is actually used to define
a variable.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-20 15:58 ---
Gross. According to a comment in postreload.c:move2add_note_store(), we can
have pushes without REG_INC notes:
/* Some targets do argument pushes without adding REG_INC notes. */
So we need to go look for those {
--- Comment #7 from jakub at gcc dot gnu dot org 2005-12-20 15:40 ---
The problem is regrename pass.
replace_oldest_value_reg called indirectly from copyprop_hardreg_forward
doesn't validate the change, so if both old and new registers are in the same
class, but only the old one is valid
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-20 14:59 ---
Does not fail with trunk or the head of the gcc 4.1 branch. But it does fail
with gcc 4.0.2. I'm going to try it with the head of the gcc 4.0 branch now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
--- Comment #6 from jakub at gcc dot gnu dot org 2005-12-20 14:58 ---
Slightly less reduced testcase that doesn't have uninitialized variables:
// { dg-options "-O2 -funroll-loops" }
// { dg-do compile }
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
stru
--- Comment #7 from kazu at gcc dot gnu dot org 2005-12-20 14:48 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #6 from kazu at gcc dot gnu dot org 2005-12-20 14:47 ---
Subject: Bug 25501
Author: kazu
Date: Tue Dec 20 14:47:07 2005
New Revision: 108853
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108853
Log:
gcc/
PR tree-optimization/25501
* tree-cfgcleanup.c
--- Comment #21 from hjl at lucon dot org 2005-12-20 14:44 ---
Steven, see comment #1. I was talking about the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
--- Comment #9 from bonzini at gnu dot org 2005-12-20 14:15 ---
Created an attachment (id=10535)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10535&action=view)
fix the #ifndef -> use #ifdef instead
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #1 from d dot bonekaemper at rtsgroup dot net 2005-12-20 12:28
---
(Sorry, pressed return to early...)
g++ accepts the following code, which contains a typedef that's supposed to act
as a static assert.
--
--
Summary: g++ accepts invalid typedef in template code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
--- Comment #14 from jakub at gcc dot gnu dot org 2005-12-20 11:55 ---
This has been fixed on the trunk earlier with Joern's patch and now on
gcc-4_1-branch as well.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-12-20 11:35
---
Same problem for gcc/cfg.c, gcc/loop-unroll.c, gcc/loop-iv.c and others. Seems
like a definition problem with HOST_WIDEST_INT_PRINT_DEC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
On i686-pc-mingw32, configuring with the following:
../gcc/configure --prefix=/mingw --enable-languages=c,fortran
--with-gmp=$HOME/local --with-mpfr=$HOME/local --disable-libssp
--disable-libmudflap --disable-nls --with-ld=/mingw/bin/ld
--with-as=/mingw/bin/as
and running make gives:
cc1.exe: wa
--- Comment #6 from belyshev at depni dot sinp dot msu dot ru 2005-12-20
10:59 ---
*** Bug 23453 has been marked as a duplicate of this bug. ***
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #13 from belyshev at depni dot sinp dot msu dot ru 2005-12-20
10:59 ---
Marking as dup of bug 25196 because that bug contains simpler test case.
*** This bug has been marked as a duplicate of 25196 ***
--
belyshev at depni dot sinp dot msu dot ru changed:
Wh
--- Comment #12 from steven at gcc dot gnu dot org 2005-12-20 10:48 ---
Almost certainly a dup of PR25196
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-20 10:17 ---
Re. comment #4: but this new PR has a much simpler test case :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
--- Comment #3 from nicos at maunakeatech dot com 2005-12-20 09:20 ---
I was under the belief that out of class definitions of const static integral
members was optional for gcc and that static const N = k; was equivalent to
enum { N = k};, was I wrong ?
--
http://gcc.gnu.org/bugzil
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2005-12-20
09:17 ---
// short testcase, compile with "-m32 -march=i386 -O3 -fomit-frame-pointer"
extern void abort (void);
static int j;
static void __attribute__((noinline))
f1 (int a, int b, int c, int d, int e)
{
j =
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-12-20 08:48
---
Subject: Bug 21228
Author: mmitchel
Date: Tue Dec 20 08:48:13 2005
New Revision: 108851
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108851
Log:
PR c++/21228
* decl.c (use_eh_spec_block):
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-12-20 08:47
---
The problem is that directives.c:do_pragma says:
/* Squirrel away the pragma text. Pragmas are
newline-terminated. */
However, as this example shows, simply saving
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-12-20 08:30
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from anlauf at gmx dot de 2005-12-20 08:29 ---
(In reply to comment #0)
I have written a portable version of the module F90_UNIX,
which runs under several platforms but need to be configured
manually. It is available from:
http://home.arcor.de/harald.anlauf/f90_unix.tar
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-20 08:26
---
Subject: Bug 21228
Author: mmitchel
Date: Tue Dec 20 08:26:04 2005
New Revision: 108850
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108850
Log:
PR c++/21228
* decl.c (use_eh_spec_block):
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-20 08:24
---
Subject: Bug 21228
Author: mmitchel
Date: Tue Dec 20 08:24:10 2005
New Revision: 108849
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108849
Log:
PR c++/21228
* decl.c (use_eh_spec_block):
97 matches
Mail list logo
