--- Additional Comments From janis at gcc dot gnu dot org 2005-02-26 00:15
---
My command line in the previous comment should have said "-o libx.so".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20199
The attached preprocessed source code is an example of a recent regresion of
the C++ frontend which totally *kills* Boost: test rate dropped from 90% to 9%
because of this! This used to work like 2 weeks ago...
--
Summary: [4.0/4.1 Regression] Rejecting invalid template code,
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Target Milestone|---
--- Additional Comments From giovannibajo at libero dot it 2005-02-26
00:46 ---
Created an attachment (id=8288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8288&action=view)
Preprocessed source (to be reduced)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20220
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26
00:55 ---
Easy reduction:
template class b {};
template class a
{
static const T value = i;
b(value+1) > next;
};
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26
00:58 ---
This worked with 4.0.0 20050113 but fails with 20050210.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20220
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26
01:13 ---
Confirmed, nice catch.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26
01:24 ---
Hmm, from the elf spec:
If different visibility attributes are specified for distinct references to or
definitions of a symbol, the
most constraining visibility attribute must be propagated to the resolvin
--- Additional Comments From bonniot at users dot sf dot net 2005-02-26
01:35 ---
After some investigation, I think I understand what is going wrong. It seems
like readResolve is only called if it is declared in the deserialized object's
class. However, it should also be searched for in
--- Additional Comments From hjl at lucon dot org 2005-02-26 01:42 ---
It is a gcc bug where gcc failed to mark "foo" as hidden with
gcc -O -g -fPIC -c -o bar.o bar.c
foo is defined in foo2.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26
02:00 ---
Huh, foo is defined in a different TU (module in elf terms).
Where in the elf documention says this what you said should happen?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--- Additional Comments From hjl at lucon dot org 2005-02-26 02:30 ---
>From the elf spec:
If different visibility attributes are specified for distinct references to or
definitions of a symbol, the
most constraining visibility attribute must be propagated to the resolving
symbol in the
--- Additional Comments From dir at lanl dot gov 2005-02-26 03:28 ---
I looked into the fortran source code and found a quick fix for the the
backspace bugs that were stopping my programs. In source file backspace.c.
1). changed
new = file_position (current_unit->s) - *p - length;
to
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-26 06:28
---
Dale,
I believe Bud Davis or Thomas Koening are the logical people
to look at your patch. If either one doesn't pursue your patch
within the next week drop me an email.
One thing to keep in mind. The patch
101 - 114 of 114 matches
Mail list logo
