--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-21
08:14 ---
The test cases from the original description
and from commen #5 work correctly at -O0, -O1,
-O2 and -O3 on ia64-unknown-linux-gnu with the
20050116 snapshot.
Thomas
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
08:14 ---
(In reply to comment #2)
The error message shows 'using-declaration' while it
is actually an 'access-declaration' (section 11.3 in
the standard).
But it looks like GCC does not differentiate between
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
08:16 ---
(In reply to comment #3)
But it looks like GCC does not differentiate between them when reporting a
bug.
s/bug/error/
A way to have GCC to differeentiate them is to add an argument to
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-21 08:18 ---
Subject: Re: [4.0 Regression] gcc-4.0.0 bloats code by 31%
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
07:57 ---
I think one of the problems is
--- Additional Comments From niki dot waibel at gmx dot net 2005-01-21
08:55 ---
--with-pic when building the db lib (that is what i currently try to compile on
all platforms), or when building gcc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19545
--- Additional Comments From niki dot waibel at gmx dot net 2005-01-21
09:00 ---
i get exactly the same error if i use --with-pic when configuring db-4.3.27.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19545
--- Additional Comments From niki dot waibel at gmx dot net 2005-01-21
09:05 ---
comping gcc again using --with-pic. just saw the option in gcc-3.4.3/libstdc++-
v3/configure ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19545
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
09:10 ---
Your test case in comment #2 has syntax errors. Please provide something
that does compile.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
09:13 ---
The test case in comment #1 I mean, of course.
You also did not specify how you compiled the test. This bug report
misses basically *all* the information we need to do anything useful
for you. Please
--- Additional Comments From niki dot waibel at gmx dot net 2005-01-21
09:20 ---
YES! everything fine now. compiling gcc using --with-pic solved the problem.
thanks a lot for that hint!
niki
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19545
--- Additional Comments From gj at pointblue dot com dot pl 2005-01-21
09:43 ---
procedure was simple. The distro I am using on my amd64 is PLD
(www.pld-linux.org).
I got their openssl.spec, changed .rpmmacros to use gcc-4.0 for compilaition.
gcc was prepared from sources, I do
--
What|Removed |Added
Target Milestone|3.4.4 |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-21
10:02 ---
Subject: Bug 17115
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2005-01-21 10:02:31
Modified files:
gcc:
--- Additional Comments From giovannibajo at libero dot it 2005-01-21
10:03 ---
This is now fixed in GCC 3.3.6, GCC 3.4.3 and GCC 4.0.0. Thanks for your report
Markus!
--
What|Removed |Added
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-21
10:04 ---
(In reply to comment #2)
commit was not there so I would assume this could clarify as obvious.
OK, thanks.
However, one thought:
In gcc 3.4 CPP_OS_RTEMS_SPEC had been part of svr4.h.
What do you think
--- Additional Comments From gj at pointblue dot com dot pl 2005-01-21
10:07 ---
unsigned long bn_add_words (unsigned long *rp, unsigned long *ap, unsigned long
*bp,int n)
{ unsigned long ret,i;
if (n = 0) return 0;
asm (
subq%2,%2
With the option -foptimize-sibling-calls tail recursion is
performed. Adding -g destroys this optimization. In my opinion,
adding compiler option -g should not change the behaviour of
the compiled program.
Environment:
System: SunOS rungner.nada.kth.se 5.9
When compiling the following code with current gfortan, the resulting executable
produces the following output:
number, derived = 2
number, simple = 1
number, simple = *
The (IMO) correct output would be
number, derived = 2
number, simple = 1
number, simple = 1
--
What|Removed |Added
Keywords||wrong-code
Known to fail||4.0.0
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-21
10:47 ---
Fixed in GCC 3.4.3 by
2004-09-14 Richard Henderson [EMAIL PROTECTED]
* sibcall.c (call_ends_block_p): Fix thinko finding the
last real insn in a block.
Thanks for the bug report.
--
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
10:57 ---
Created an attachment (id=8029)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8029action=view)
Disable some expensive passes at -O1
I'm running a SPECint comparison between GCC-hammer-branch and
This code does not compile:
#include map
using namespace std;
typedef mapint,int Map;
int main()
{
Map::reverse_iterator a;
Map::const_reverse_iterator b;
return a==b;
}
--
Summary: reverse_iterator comparison
Product: gcc
Version: 4.0.0
--- Additional Comments From pcarlini at suse dot de 2005-01-21 11:34
---
*** This bug has been marked as a duplicate of 11729 ***
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-01-21 11:34
---
*** Bug 19562 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
11:38 ---
Looks like a reload problem (of course).
In the .lreg dump we have this:
(insn:HI 100 99 101 9 (set (reg/v/f:SI 64 [ all_ovr_obj ])
(reg/f:SI 87)) 41 {*movsi_1} (nil)
(nil))
In the
--- Additional Comments From gj at pointblue dot com dot pl 2005-01-21
12:11 ---
0.9.7d crashes too.
Please try it on your machines.If you have some amd64 computer.
From the backtrace:
...
0x2ad71ecd bn_add_words+13: data16
0x2ad71ece bn_add_words+14: data16
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
12:25 ---
This can be fixed at the tree level without any gcse or ra hacking:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01462.html
--
What|Removed |Added
I just tried to abuse autoconf's --program-suffix feature (../configure
--program-suffix=-4.0) to have gcc 3.4.x and 4.0 in the same directory
without conflicts.
Looks like the configure option is completely ignored -- the resulting
binaries are named as usual.
--
Summary:
Hello
I have looked at the implementation of complex arithmetic in gcc.
I see tree problems with naive formulas for multiplication and
division that are currently in use.
1. Problems with special values. For example (infinity+ i*NaN)^2
should be (infinity + i*0) according to IEC 60559 and
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-01-21 12:39 ---
(In reply to comment #15)
I will note for the record that disabling local-alloc will resolve
this problem. A patch for that is in the audit trail of another bug,
for unrelated reasons:
I have looked at the implementation of complex arithmetic in gcc.
We are already aware of this issue, since you have already reported
it ;) The relevant PR is middle-end/18902.
Indeed, our plan involves enabling the (*already available*) algorithm
due to Smith. There are still some open issues,
Paolo Carlini wrote:
We are already aware of this issue, since you have already reported
it ;) The relevant PR is middle-end/18902.
Forgot to add: for other issues, related in particular to multiplication,
not only division, please file appropriate Bugzilla PRs.
Thanks!
Paolo.
--- Additional Comments From uros at kss-loka dot si 2005-01-21 12:51
---
Similar problems as described in comment #2 happens for -mfpmath=sse -mno-80387.
However, a patch at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01464.html is
needed, otherwise compilation fails.
--
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
12:51 ---
With my patch I get almost perfect code for amd64:
.globl f
.type f, @function
f:
.LFB2:
decl%edi
je .L6
movlr5(%rip), %r9d
movlr4(%rip),
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-01-21
13:03 ---
Confirmed on Cygwin and RH9
In an attempt to reduce this a bit, I have produced a slightly more startling
error:
$ cat point.f90
module mpoint
type :: mytype
integer :: i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
13:07 ---
Is this just the Ada's programs that don't get transformed or all.
If it is just Ada, then this is a dup of bug 864.
Otherwise, this was fixed even longer before 3.4.0 by:
2001-11-08 Andreas Franck [EMAIL
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
13:18 ---
No, tree-ssa-live is quite right. ivtmp.3_12 and ivtmp.3_20 are defined
and live at some common statements, so they conflict:
# BLOCK 1
# PRED: 0 [88.4%] (true,exec) 1 [89.0%]
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-21 13:22 ---
Subject: Re: [4.0 Regression] out of ssa causing loops to have more than one BB
No, tree-ssa-live is quite right. ivtmp.3_12 and ivtmp.3_20 are defined
and live at some common
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
13:27 ---
Correctemundo Zdenek!
Before dom3:
# BLOCK 2
# PRED: 1 [100.0%] (fallthru) 2 [89.0%] (dfs_back,false,exec)
# ivtmp.3_12 = PHI 0(1), ivtmp.3_20(2);
# __BLNK___2 = PHI __BLNK___8(1),
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
13:28 ---
Not an out-of-ssa problem. This is a DOM problem.
--
What|Removed |Added
--- Additional Comments From mmikucionis at gmail dot com 2005-01-21 13:37
---
I have very similar situation but with even worse results:
struct foo {
int i;
char* s[];
} arr[] = {
{
1, { first, second }
},
{
2, { third, fourth }
}
};
gcc (GCC) 3.3.5 (Debian
g++ generates less warnings when using -Wparentheses than gcc. For instance
gcc warns about
if (a0 b0)
...
(warning: suggest parentheses around comparison in operand of ) but g++ does
not. And gcc warns about
char a = 1024;
(warning: overflow in implicit constant
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
13:46 ---
Mark, can we move the milestone on this one please? There is no way
this will be fixed for GCC 4.0.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
13:47 ---
(From update of attachment 7380)
already applied
--
What|Removed |Added
Attachment #7380
--- Additional Comments From falk at debian dot org 2005-01-21 13:55
---
(In reply to comment #17)
And IMHO this shoul be perfectly
valid, since the operands to the asm construction are all marked as m (!!!),
so no registers should be needed for that!
Huh? The memory operands are
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
14:00 ---
For the test case from comment #1 I get the following for AMD64:
GCC 4.0 (20050121):
textdata bss dec hex filename
24689 0 0 246896071 t.O2.o
20728 0
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
14:02 ---
(FWIW, the GCC 4.0 I tested has my patch for PR19454 applied, which makes
quite a difference for -m32 -O2, but not for -Os...).
That'd be PR19464 ;-)
--
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
14:04 ---
This actually looks like a duplicate of PR19038 now.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
14:06 ---
Zdenek, is this still a regression, or are your suggestions from
comment #12 only enhancements?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-01-21 14:10 ---
(In reply to comment #18)
Huh? The memory operands are not at a compile time constant address, so of
course
you need a register to hold them. Of course, you need only one register for
all of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
14:11 ---
(In reply to comment #0)
g++ generates less warnings when using -Wparentheses than gcc. For instance
gcc warns about
if (a0 b0)
...
This because this warning is only in the C
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
14:12 ---
Note here is the testcase:
int f(int a, int b)
{
if (a0 b0) /* { dg-warning } */
return 210;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19564
--- Additional Comments From mmikucionis at gmail dot com 2005-01-21 14:31
---
my last comment was close to this bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18926
sorry
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19435
g++ does not warn if there occurs an overflow in conversion. For instance, gcc
does not warn about
char a = 1024;
but gcc does.
--
Summary: g++ does not warn about overflow in conversion but gcc
does
Product: gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
14:32 ---
Hmm, adding -fno-builtin fixes the failure, maybe this is libcall problem
then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
14:36 ---
(In reply to comment #2)
I have very similar situation but with even worse results:
The C++ problem is recorded in a different bug (that might have been my fault
for not testing the C++
front-end), see
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
14:38 ---
Confirmed.
--
What|Removed |Added
Severity|normal |minor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
14:42 ---
(In reply to comment #3)
(In reply to comment #2)
commit was not there so I would assume this could clarify as obvious.
OK, thanks.
What do you think about moving CPP_OS_RTEMS_SPEC into rs6000/rtems.h,
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-21
14:48 ---
Testcase invokes undefined behaviour.
http://gcc.gnu.org/ml/fortran/2005-01/msg00234.html
--
What|Removed |Added
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-21
14:57 ---
My bad, this is in fact legal and well defined.
--
What|Removed |Added
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From falk at debian dot org 2005-01-21 15:05
---
Reporter says in PR 11203 this does happen even at -O2, so it's not a duplicate
of PR 11203.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
15:15 ---
It still a dup of bug 11203 and here is why, the a gets placed in different
register for the inline-asm at
-O0 but -O1 and above, we use the same register/offset but PR 11203 has a
testcase where it does
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
15:15 ---
*** Bug 19549 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
--- Additional Comments From ncm-nospam at cantrip dot org 2005-01-21
15:22 ---
This is a real bug, but easily fixed, and (I think) without breaking ABI.
The problem is in basic_string.h, where it says
struct _Rep : _Rep_base
{
// Types:
typedef typename _Alloc::template
--- Additional Comments From gdr at integrable-solutions dot net
2005-01-21 15:33 ---
Subject: Re: New: reverse_iterator comparison
kunert at physik dot tu-dresden dot de [EMAIL PROTECTED] writes:
| This code does not compile:
|
| #include map
| using namespace std;
|
| typedef
--- Additional Comments From ncm-nospam at cantrip dot org 2005-01-21
15:37 ---
Hmm, it's a little more complicated than I said, although it might be
academic. There's an implicit assumption in the code that any type
on which basic_string might be instantiated has no stricter
--- Additional Comments From pcarlini at suse dot de 2005-01-21 15:41
---
Thanks Nathan, I will implement what you are suggesting. The last issue,
actually
is filed as libstdc++/8670 and in the audit trail we agreed to fix it using a
suited __attribute__(aligned), which however,
--- Additional Comments From arend dot bayer at web dot de 2005-01-21
15:43 ---
Subject: Re: [4.0 Regression] ICE with
-march=pentium-m (during bootstrap)
I verified it still ICEs as of today (2005-01-21).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19556
--- Additional Comments From pcarlini at suse dot de 2005-01-21 15:43
---
By the way, I understand that tr1/aligned_storage co facilities cannot be
directly used for implementing the current std, since we cannot pollute the
std namespace.
--
--
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-21 15:46
---
-fno-builtin only matters in not adding pure attribute to csqrtf.
If you start the #5 testcase with
_Complex float csqrtf(_Complex float) __attribute__((pure));
instead, it fails even with -fno-builtin.
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-01-21 15:49 ---
OK, sorry, the Bug 19549 testcode passes with -O1 and above, but the original,
that it was stripped from (maybe too much stripped) doesn't:
-- test2.c -
extern
--- Additional Comments From falk at debian dot org 2005-01-21 15:50
---
(In reply to comment #3)
It still a dup of bug 11203 and here is why, the a gets placed in different
register for the inline-asm at
-O0 but -O1 and above, we use the same register/offset but PR 11203 has a
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-21
16:03 ---
Patch for 3.4 and 4.0 submitted:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01491.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14479
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-21
16:04 ---
Patch for 3.4 and 4.0 submitted:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01491.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19487
The x86_64 compiler (verified in gcc 3.4.3, configured for
x86_64-redhat-linux)
chooses a different parameter passing method when passing a struct value,
depending upon whether a contained 16 bit bit field is declared as either
an 'int' or a 'short int'.
Given the following test case:
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-01-21 16:07 ---
Experimenting with SRA inside loop together with cleanup passes after
cunroll/sra didn't reveal anything good - even with loop cfg_cleanup patched in.
See thread starting at
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-21 16:13
---
Simplified testcase:
extern void abort ();
__attribute__((pure)) _Complex float
foo (int x)
{
_Complex float r;
__real r = x + 1;
__imag r = x - 1;
return r;
}
void
bar (float *f)
{
*f = foo (5);
--- Additional Comments From bero at arklinux dot org 2005-01-21 16:19
---
It's not just ada, it's everything including gcc and g++
Looks like it reappeared somewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19563
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-21
16:22 ---
Subject: Bug 19510
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-01-21 16:21:40
Modified files:
libstdc++-v3 :
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-21
16:23 ---
Regtesting patch for 3.3 branch.
--
What|Removed |Added
Keywords|diagnostic,
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-21
16:25 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From falk at debian dot org 2005-01-21 16:33
---
(In reply to comment #21)
Or do you consider this also invalid?
It doesn't seem invalid to me. But it is basically impossible to write the
register allocator such that it finds a register allocation for every
--- Additional Comments From ncm-nospam at cantrip dot org 2005-01-21
16:39 ---
I agree that 8670 is a separate bug.
The referenced test 2.cc can be made to fail more reliably with
the following changes:
First, leave enough space for alignment adjustments, even on 128-bit
machines:
-
--- Additional Comments From gary at intrepid dot com 2005-01-21 16:40
---
change from bug/c to bug/target
--
What|Removed |Added
Component|c
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-01-21 16:48 ---
(In reply to comment #22)
It doesn't seem invalid to me. But it is basically impossible to write the
register allocator such that it finds a register allocation for every
situation
where it's
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 16:49
---
A build with GCC CVS LAST_UPDATED Fri Jan 21 03:20:28 UTC 2005
also fails in the same way. I don't have a pressing need to get
this fixed, as my bootstrap-test needs are covered by native
tools, but if wanted,
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 17:09
---
Following up on comment #18, no GNU ld *is* used, it's just that
adding -print-prog-name=ld to the failing link says /usr/ccs/bin/ld.
An otherwise harmless bug, likely a WONTFIX. :-) But that's another bug.
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 17:11
---
(Oops, I meant comment #15 in comment #16.
It's my bug list that's 18. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19461
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21
17:12 ---
I'm going to go a step further and mark this INVALID.
Since we already do the right thing at -Os, and there's no evidence that we're
actually generating slower code at -O2, I'm not worried about this
--
Bug 5738 depends on bug 15559, which changed state.
Bug 15559 Summary: [3.3/3.4/4.0 Regression] misses opportunity for hoisting an
expression that would simplify control flow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15559
What|Old Value |New Value
--
Bug 16996 depends on bug 15559, which changed state.
Bug 15559 Summary: [3.3/3.4/4.0 Regression] misses opportunity for hoisting an
expression that would simplify control flow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15559
What|Old Value |New Value
Please note this is not a duplicate of #4993, because I am using RTLD_GLOBAL and
-Wl,-E.
This test project demonstatrates a problem when using dynamic_cast from inside a
shared object to attempt to convert a base class (interface) to a derived class
(another interface) whose definitions are in
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-21
17:27 ---
A build with GCC CVS LAST_UPDATED Fri Jan 21 03:20:28 UTC 2005
also fails in the same way. I don't have a pressing need to get
this fixed, as my bootstrap-test needs are covered by native
tools, but
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21
17:28 ---
m68k is not a primary or secondary platform; removing target milestone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21
17:29 ---
This will never be a release-critical issue; removing the target milestone.
--
What|Removed |Added
--- Additional Comments From daveregs at rsaisp dot com 2005-01-21 17:29
---
Created an attachment (id=8032)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8032action=view)
Example program that demonstrates the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19567
--- Additional Comments From daveregs at rsaisp dot com 2005-01-21 17:30
---
Tested on fedora core 2 and 3, results are the same.
more info: fc2: gcc version 3.3.3 20040412
Works on windows 3.4.2 (mingw-special) most likely because of the lack of
support for weak symbols.
--
1 - 100 of 177 matches
Mail list logo
