Hi,
On Sun, Mar 13, 2005 at 03:01:00PM +0200, Kai Henningsen wrote:
Most of the rest of the error handling in this project is concerned with
the absence of the feature I loved in the IBM PL/I compilers under the
name SNAP; - putting out a stack backtrace (the usual idiom for abort()
was
On Tue, 2005-03-15 at 09:59, Clifford Wolf wrote:
Hi,
On Sun, Mar 13, 2005 at 03:01:00PM +0200, Kai Henningsen wrote:
Most of the rest of the error handling in this project is concerned with
the absence of the feature I loved in the IBM PL/I compilers under the
name SNAP; - putting
Hi,
On Fri, Mar 11, 2005 at 03:28:19PM -0500, Richard Stallman wrote:
Currently, I believe, GCC combines various calls to abort in a single
function, because it knows that none of them returns.
afaics it is more generic. It merges them because it knows that it doesn't
make any difference. This
Consider the following:
static inline int a() __attribute((always_inline));
static inline int b() __attribute((always_inline));
static inline int b() { a(); }
static inline int a() { }
int c() { b(); }
This compiles fine at -O2. At -O0 we get the baffling error
sorry, unimplemented: inlining
However, the idea that users could search for previous bug reports is
new to me. That might be an additional reason for using fancy_abort.
It's not just users, but first level tech-support. There, it can help
in suggesting a workaround to the user and knowing which file the abort
is in
Dale Johannesen [EMAIL PROTECTED] writes:
It seems undesirable for -O options to affect which programs will
compile.
Agreed. Perhaps we should run the inliner at -O0 if we see
always_inline attributes, just for those functions?
We do; the problem is that it makes only 1 pass, so tries to
Rajesh Babu wrote:
I am working with gcc-3.3.3, and I want to insert my module after
construction of AST and before RTL generation.
gcc-3.3 is not interesting for work like this. This stuff has already
been obsoleted in current gcc sources. But if you insist on using out
dated sources, look
This program should generate an error; it's illogical. If the alignment
of the element is greater than the element size, then arrays of such a
type should be disallowed. Otherwise, stuff in either the compiler or
the program itself could make the justified assumption that things of
that
Hi,
in March 2004 we added to many libstdc++-v3 testcases lines similar to
#if !__GXX_WEAK__ _MT_ALLOCATOR_H
// Explicitly instantiate for systems with no COMDAT or weak support.
template class __gnu_cxx::__mt_allocstd::_List_nodeint ;
#endif
AFAIK, only in order to avoid spurious failures on
Steve Ellcey wrote:
Most of the gcc.dg/vect/* tests contain something like:
typedef float afloat __attribute__ ((__aligned__(16)));
afloat a[N];
It looks like what is really intended here is to apply the alignment to
the array type. The point is that the entire array has to be
Paolo Carlini [EMAIL PROTECTED] writes:
Hi,
in March 2004 we added to many libstdc++-v3 testcases lines similar to
#if !__GXX_WEAK__ _MT_ALLOCATOR_H
// Explicitly instantiate for systems with no COMDAT or weak support.
template class __gnu_cxx::__mt_allocstd::_List_nodeint ;
#endif
Geoffrey Keating wrote:
Darwin now has weak/comdat support, so it doesn't need or use this any more.
Ah, great, I suspected that...
However, AIX does need them, I think.
Humpf, forgot AIX! David Edelsohn?!?
Thanks,
Paolo.
The gcc.dg/compat/struct-layout problems seem to stem from
struct-layout-1_generate.c. In generate_fields() it generates random
types, some of these are arrays of some base type. Then based on
another random number we might add an attribute like alignment. There
is no check to ensure
Joe Buck wrote:
On Tue, Mar 15, 2005 at 04:42:03PM -0800, Steve Ellcey wrote:
The simplest solution would probably be to ignore __aligned__ attributes
completely when we have an array. Or to do the change you suggested for
the vector tests and have the attribute attached to the array and not
the
On Mar 15, 2005, at 7:35 PM, Paolo Carlini wrote:
Geoffrey Keating wrote:
Darwin now has weak/comdat support, so it doesn't need or use this
any more.
Ah, great, I suspected that...
However, AIX does need them, I think.
Humpf, forgot AIX! David Edelsohn?!?
There are other targets other than aix
Andrew Pinski wrote:
There are other targets other than aix that still need them too.
Almost all non elf targets (and there might be some elf targets too).
AIX 5.1 supports weak symbols (IIRC) and should work without the hack
but older AIX still should be supported.
Thanks Andrew for the info.
Dave Korn [EMAIL PROTECTED] writes:
I very strongly feel that this optimisation should be placed under user
control rather than just disabled, and that it should remain enabled by
default at -Os; but I wouldn't go to the ropes over whether or not it's
included in -Os as long as there's a -f
Paolo Carlini writes:
However, AIX does need them, I think.
Paolo Humpf, forgot AIX! David Edelsohn?!?
AIX probably needs this support indefinitely. If I remember
correctly, the new allocator does not work on AIX due to ELF-like
assumptions about the order of global constructors.
The best option is a clean grammar in Yacc/Bison!.
GCC had such parsers for over a decade, and yet they are being replaced.
Bison remains a good solution in many cases, especially for languages
specifically designed to be easy to parse with an LALR parser (that is,
languages
| http://gcc.gnu.org/gcc-4.1/changes.html
|
| New Languages and Language specific improvements
| C and Objective-C
|
| * The old Bison-based C and Objective-C parser has been replaced
|by a new, faster hand-written recursive-descent parser.
|
| Hahahahaha, WRONG!!
|
On Wed, Mar 16, 2005 at 03:22:26AM +0100, [EMAIL PROTECTED] wrote:
Do you demonstrate that C++ is not LALR(1)?
I'll leave that to you as a homework assignment. Actually, C++ is not
LALR(N) for any N. Get out the C++ grammar and figure it out, it's an
easy proof. Come back when you have proved
, for a couple of reasons. One, I
don't know if they are necessary when using mt_alloc circa 20050315. I'm
thinking that they are not, just due to design changes. Two, mt_alloc is
not the default allocator for darwin, or for other platforms that are
hostile to weak symbols.
For full details on Darwin and weak
| Do you demonstrate that C++ is not LALR(1)?
|
| I'll leave that to you as a homework assignment. Actually, C++ is not
| LALR(N) for any N. Get out the C++ grammar and figure it out, it's an
| easy proof. Come back when you have proved it to your own satisfaction,
| and please refrain from
i am studing RTL that is gcc front-end
insn RTX has seven elements
ex) (insn id prev next pattern code log_links reg_notes)
(insn 12 10 14 (set (reg:QI 12 A0) (reg:QI 1 R1) -1 (nil) (nil))
where i get the impormation about code, log_links,
On Wed, 2005-03-16 at 04:56 +0100, [EMAIL PROTECTED]
| | Bison remains a good solution in many cases, especially for languages
| | specifically designed to be easy to parse with an LALR parser (that is,
| | languages that don't look like C).
|
| Why don't we develop a LR(k) / k small
On Tue, 2005-03-15 at 23:41 -0500, Daniel Berlin wrote:
On Wed, 2005-03-16 at 04:56 +0100, [EMAIL PROTECTED]
| | Bison remains a good solution in many cases, especially for languages
| | specifically designed to be easy to parse with an LALR parser (that
is,
| | languages that don't
[EMAIL PROTECTED] writes:
| Do you demonstrate that C++ is not LALR(1)?
|
| I'll leave that to you as a homework assignment. Actually, C++ is not
| LALR(N) for any N.
Nor is it LR(N) nor LL(N).
| Get out the C++ grammar and figure it out, it's an easy proof.
| Come back when you have
| It's possible that C++ doesn't require unbounded lookahead
|
| No, it's not.
| In fact, if you'd read the language grammar definition, you'd discover
| you could pretty produce the anti-program with some work.
| That given any k, it produces a C++ program that cannot be parsed with
| an LR(k)
| | Do you demonstrate that C++ is not LALR(1)?
| |
| | I'll leave that to you as a homework assignment. Actually, C++ is not
| | LALR(N) for any N.
|
| Nor is it LR(N) nor LL(N).
|
| | Get out the C++ grammar and figure it out, it's an easy proof.
| | Come back when you have proved it
| | Do you demonstrate that C++ is not LALR(1)?
| |
| | I'll leave that to you as a homework assignment. Actually, C++ is not
| | LALR(N) for any N.
|
| Nor is it LR(N) nor LL(N).
|
| | Get out the C++ grammar and figure it out, it's an easy proof.
| | Come back when you have proved it
Hi,
I'm writing a new gcc port, and having problems making reload work.
Say I've got a mov instruction that only works via an accumulator A, and
a two-operand add instruction. r regclass includes regs A,X,Y, and
a regclass only includes reg A.
So mov has constraints like: 0 = g,a 1 = a,gi
stage1/xgcc -Bstage1/ -B/usr/local/sparc-linux/bin/ -c -g -O2
-gnatpg -gnata -g -O1 -fno-inline \
-I- -I. -Iada -I/usr/local/src/trunk/gcc/gcc/ada
/usr/local/src/trunk/gcc/gcc/ada/a-except.adb -o ada/a-except.o
unhandled expression in get_expr_operands():
error_mark 0x7018fda0
This is
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-03-15
08:15 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01377.html
--
What|Removed |Added
Test listed below fails when compiled with -02 optimization at IA64. It appears
that instruction scheduler misses dependency between two assignments in
the 'set_code' routine and falsely reorders them.
$ cat test.c
typedef struct s_t {
short a;
short b;
} *ps;
void set_code (ps obj, short
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-15
08:28 ---
You are violating C89/C99/C++ aliasing rules so this is undefined.
--
What|Removed |Added
Hi,
write (*,10) 0.0
10 format (ES12.3)
end
prints
0.000E-01
instead of
0.000E+00
as it should.
Cheers,
-ha
--
Summary: libfortran: formatted write, ES edit descriptor
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Additional Comments From giovannibajo at libero dot it 2005-03-15
10:04 ---
Roger explains what else needs to be done here:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01386.html
Right now, after his patch, mainline generates this code:
pushl %edi
pushl %esi
--- Additional Comments From giovannibajo at libero dot it 2005-03-15
10:07 ---
Uros did some additional comments:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01427.html
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-03-15
10:10 ---
CC'ing reload guru
--
What|Removed |Added
CC|
--- Additional Comments From irar at il dot ibm dot com 2005-03-15 11:37
---
This problem was solved in autovect branch (http://gcc.gnu.org/ml/gcc-
patches/2005-03/msg00754.html). This patch will be submitted to mainline in
stage 2.
--
--- Additional Comments From bernds_cb1 at t-online dot de 2005-03-15
11:44 ---
Interesting problem. I was temporarily confused by rth's mention of secondary
reloads; it's actually secondary memory that we allocate here. What happens is
1. Notice none of the alternatives fit as-is
2.
--- Additional Comments From giovannibajo at libero dot it 2005-03-15
12:23 ---
But a peephole solution would fix a single backend, whilst I assume any kind of
reload fix could improve code generation with multiple backends at the same
time.
--
--- Additional Comments From uros at kss-loka dot si 2005-03-15 12:34
---
(In reply to comment #6)
But a peephole solution would fix a single backend, whilst I assume any kind
of
Also, every insn pattern that accepts memory input would need an appropriate
peephole2 pattern...
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
12:39 ---
Subject: Bug 20291
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 12:39:06
Modified files:
gcc: ChangeLog combine.c
Log message:
(1) This example compiles with ibm xlf compiler, and (2) I could not
find any reference to RAN intrinsic in the last draft standard.
hadas:~% cat 1000d_linpack.f
double precision function ran( iseed )
integer iseed(4)
ran = 0.0
end
program linpack_test
--
What|Removed |Added
CC||leehod at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20481
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-03-15 13:25 ---
As far as I know, this regression is only present in mainline, but not on the
4.0 branch; but the title and Known to fail line of this report say the
regression is also in 4.0.
Could someone with
--- Additional Comments From schwab at suse dot de 2005-03-15 13:30 ---
The ICE is also reproducible on the 4.0 branch.
--
What|Removed |Added
CC|
--prefix=/home/tow/root/gcc
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050315 (experimental)
parabrisas:~/test% ~/root/gcc/bin/gfortran -c m_wxml_buffer.f90
In file m_wxml_buffer.f90:19
character(len=1), dimension(len(s)) :: s_a
1
Error
--- Additional Comments From tow21 at cam dot ac dot uk 2005-03-15 13:46
---
Created an attachment (id=8390)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8390action=view)
testcase
Testcase attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20482
--- Additional Comments From giovannibajo at libero dot it 2005-03-15
13:48 ---
Confirmed.
Please, could the autovect people remember to confirm bugs when they look at
them? If you have troubles with Bugzilla privileges and e-mail accounts,
contact me in private.
Another thing:
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-15
14:07 ---
Fixed in mainline with patch applied today.
--
What|Removed |Added
Status|NEW
--
Bug 17652 depends on bug 20291, which changed state.
Bug 20291 Summary: combine throws away clobbers before trying to split
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20291
What|Old Value |New Value
Don't know if this is related to 12840 - submitting it anyway.
parabrisas:~/test% cat char.f90
subroutine add_to_buffer_escaping_markup(s)
character(len=*), intent(in) :: s
character(len=1), dimension(len(s)) :: s_a
call add_to_buffer(transfer(s,s_a))
end subroutine
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
14:44 ---
Subject: Bug 18668
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 14:44:13
Modified files:
gcc: ChangeLog
gcc/config/i386:
--- Additional Comments From uros at kss-loka dot si 2005-03-15 14:53
---
Patch is comitted to 4.1 mainline. For the testcase in description '-O2
-march=prescott' now generates:
oof:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
fldl8(%ebp)
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-03-15 15:24 ---
Add external ran to your program. RAN is an intrinsic
procedure because it was an intrinsic procedure in g77.
Or add -std=f95 to your command line.
--
Example:
template typename T
T const max1(T const a, T const b)
{ return a b ? b : a; }
template typename T
T const max2(T const a, T const b)
{ return a b ? b : a; }
struct Test
{ static int const A = 1; };
int main()
{
#if 0
max1(Test::A, 2); // OK.
#else
max2(Test::A, 2); //
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
15:54 ---
Subject: Bug 13470
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 15:53:11
Modified files:
gcc/ada: a-stunau.ads a-stunau.adb
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
16:00 ---
Subject: Bug 19140
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 15:59:55
Modified files:
gcc/ada: decl.c gigi.h utils.c trans.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
16:00 ---
Subject: Bug 20255
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 15:59:55
Modified files:
gcc/ada: decl.c gigi.h utils.c trans.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
16:00 ---
Subject: Bug 19900
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 15:59:55
Modified files:
gcc/ada: decl.c gigi.h utils.c trans.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
16:00 ---
Subject: Bug 19408
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 15:59:55
Modified files:
gcc/ada: decl.c gigi.h utils.c trans.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
16:00 ---
Subject: Bug 19900
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 15:59:55
Modified files:
gcc/ada: decl.c gigi.h utils.c trans.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
16:03 ---
Subject: Bug 20344
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 16:02:28
Modified files:
gcc/ada: misc.c lang.opt
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
16:03 ---
Subject: Bug 20226
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 16:02:28
Modified files:
gcc/ada: misc.c lang.opt
Log message:
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-15
16:03 ---
Fixed on mainline.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-15
16:03 ---
Actually it was not g77 intrinsic but rather an hp extension intrinsic which I
had filed (PR 14993),
adding what Steve recommends fixes the problem.
--
What|Removed
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-15
16:05 ---
Fixed on mainline.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-15
16:05 ---
Fixed on mainline.
--
What|Removed |Added
Status|NEW
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-15
16:06 ---
Fixed on mainline.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 19408 depends on bug 19900, which changed state.
Bug 19900 Summary: [4.0/4.1 Regression] ACATS c391002 c432002 ICE
categorize_ctor_elements_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19900
What|Old Value |New Value
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-15
16:07 ---
Fixed on mainline.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
16:11 ---
Subject: Bug 6852
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 16:10:23
Modified files:
gcc/ada: Makefile.in
Log message:
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-15
16:11 ---
Marking as fixed.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-15
16:12 ---
You need to declare space for the variable still like so:
int const Test::A;
This is invalid.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
16:13 ---
Subject: Bug 15608
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 16:12:59
Modified files:
gcc/ada: sem_util.adb
Log message:
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-15
16:09 ---
Fixed on mainline.
--
What|Removed |Added
Target Milestone|---
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-15
16:17 ---
Fixed on mainline.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-15
16:18 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01475.html.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-15
16:25 ---
Fixed on mainline.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-15
16:28 ---
*** This bug has been marked as a duplicate of 17298 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-15
16:28 ---
*** Bug 20483 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-15
16:32 ---
Adding nathanael in cc:
Nathanel, could you have a look at the comment #10 about passing
GCC_FOR_TARGET down to libada/Makefile ?
Arno
--
What|Removed |Added
Source available at http://www.bodi-klinke.dk/parser.ii
$ /usr/local/bin/g++ -g -Wall -Werror -O1 -c parser.ii
parser.hh: In member function `bool
parser::Parser::parse_simple_declaration(parser::Environment*,
parser::Parser::DeclEnv, const parser::Parser::fun_env_t, bool,
parser::DeclStatement*,
--- Additional Comments From micis at gmx dot de 2005-03-15 17:04 ---
I got this ICE only with gcc 4.1.0
Michael Cieslinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-15
17:07 ---
Note this code is partly invalid (and will be rejected in 4.0) but fixing that
invalidness, still gets the error
in 3.4.x. Basically friend support in 4.0 and above is closer to what the
standard says
--
What|Removed |Added
Known to fail||3.4.0 4.0.0
Known to work||3.3.3 4.0.0 4.1.0
--
What|Removed |Added
Known to fail|3.4.0 4.0.0 |3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20485
--
What|Removed |Added
Summary|executables created with - |[3.4/4.0/4.1 Regression]
|fprofile-arcs -ftest- |executables created with -
With this patch:
http://gcc.gnu.org/ml/java-patches/2005-q1/msg00753.html
I fixed the Socket read returns EOF when count == 0 problem for POSIX. A
similar patch should be made to Win32 code.
--
Summary: Win32 needs Socket read returns EOF when count == 0 fix
Product: gcc
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-15
18:08 ---
A patch against 4.0 20050218 is here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01612.html
discover_flags_reg also needs to be updated to understand INSNs.
--
--- Additional Comments From bangerth at dealii dot org 2005-03-15 18:15
---
Created an attachment (id=8393)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8393action=view)
Preprocessed sources, not reduced
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20485
--- Additional Comments From pthaugen at us dot ibm dot com 2005-03-15
18:22 ---
Ditto here, except added additional call to negate_expr_p(arg2) to make sure it
was ok to flip the expression back to it's original form. Not sure if that was
necessary, was assuming I'd get comments when I
--- Additional Comments From dopheide at fmf dot nl 2005-03-15 18:46
---
You are correct. I was wrong.
I thought, because of consistency reasons, that
1) both should link, or
2) both shouldn't link.
(And I choose 1) for the bug-report.)
As I now understand it, the static int const A =
On Mar 15, 2005, at 1:46 PM, dopheide at fmf dot nl wrote:
It stills /looks/ inconsistent though.
That is because there is an optimization going on here which is allowed
by the standard.
-- Pinski
--- Additional Comments From pinskia at physics dot uc dot edu 2005-03-15
18:50 ---
Subject: Re: No proper linkage created for in class initialized static const
On Mar 15, 2005, at 1:46 PM, dopheide at fmf dot nl wrote:
It stills /looks/ inconsistent though.
That is because there
--- Additional Comments From fitzsim at redhat dot com 2005-03-15 19:09
---
I couldn't reproduce this on my machine. Can you try out Jakub's patch? If it
solves your problem we can close this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
This bug was detected in gcc 3.3.1 and is still here in gcc-3.4.3 and gcc-4.0.0
The bug is not in gcc-3.2.2
-O2 and -Os produces bad code.
Switching optimization level to something less than -O2 produces a valid code.
Using -O2 -fno-schedule-insns2 also produces valid code.
./g++-mainline-4.0
1 - 100 of 171 matches
Mail list logo
