On Mon, May 5, 2008 at 7:42 PM, Jim Wilson [EMAIL PROTECTED] wrote:
Pranav Bhandarkar wrote:
GCC 4.3 does fine here except when the operator is logical and (see
attached. test.c uses logical and and test1.c uses plus)
Logical and generates control-flow instructions, i.e. compares,
On Tue, May 6, 2008 at 8:11 AM, Richard Guenther
[EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 7:42 PM, Jim Wilson [EMAIL PROTECTED] wrote:
Pranav Bhandarkar wrote:
GCC 4.3 does fine here except when the operator is logical and (see
attached. test.c uses logical and and test1.c
On Tue, May 6, 2008 at 9:28 AM, Ramana Radhakrishnan [EMAIL PROTECTED] wrote:
On Tue, May 6, 2008 at 8:11 AM, Richard Guenther
[EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 7:42 PM, Jim Wilson [EMAIL PROTECTED] wrote:
Pranav Bhandarkar wrote:
GCC 4.3 does fine here except
Hi all,
g++ always add -lstdc++ -lm before any other libraries at link
time. I want to link the libraries after libc.so. but I haven't found
where to change the order in gcc sources. so could you provide any
helpful hints on it? thanks in advance.
--
Best wishes!
Yours,
Lijuan Hai
_ _
Lijuan Hai [EMAIL PROTECTED] writes:
g++ always add -lstdc++ -lm before any other libraries at link
time. I want to link the libraries after libc.so. but I haven't found
where to change the order in gcc sources. so could you provide any
helpful hints on it? thanks in advance.
I am investigating a bad code generation bug on the 64 bit HPPA platform
with GCC 4.3.0 and would like some help and/or ideas on how to analyze
and fix it. The failing test is the SPEC 2000 GCC benchmark (version
2.7.2.2) and I have been unable to create a smaller test case so far.
What I have
A recent committ caused the following build failure with the
x86_64-pc-mingw32 target:
make[4]: Entering directory
`/var/tmp/build/gcc-svn/build-x86_64-pc-linux/x86_64-pc-mingw32/libstdc++-v3/src'
/bin/sh ../libtool --tag CXX --mode=compile
/var/tmp/build/gcc-svn/build-x86_64-pc-linux/./gcc/xgcc
Thanks for reporting this. I believe these 3 errors to be fixed as of
revision 135015. Can you check?
best,
-benjamin
Build in progress
On 5/6/08, Benjamin Kosnik [EMAIL PROTECTED] wrote:
Thanks for reporting this. I believe these 3 errors to be fixed as of
revision 135015. Can you check?
best,
-benjamin
On 5/6/08, Benjamin Kosnik [EMAIL PROTECTED] wrote:
Thanks for reporting this. I believe these 3 errors to be fixed as of
revision 135015. Can you check?
x86_64-pc-mingw32 now compiles. Thanks!!
Steve Ellcey wrote:
I am investigating a bad code generation bug on the 64 bit HPPA platform
with GCC 4.3.0 and would like some help and/or ideas on how to analyze
and fix it. The failing test is the SPEC 2000 GCC benchmark (version
2.7.2.2) and I have been unable to create a smaller test case
GCC version:
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
It is really hard to reproduce and goes away even with minimal code changes.
Happens in a unit test.
Host is x86_64: model name : Intel(R) Core(TM)2 CPU 6300 @
1.86GHz from /proc/cpuinfo.
The following snippets might be
--- Comment #1 from dino at concisoft dot com 2008-05-06 07:19 ---
The same code works fine with -O1 and -O3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-05-06 08:00 ---
Subject: Bug 36118
Author: hubicka
Date: Tue May 6 07:59:54 2008
New Revision: 134975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134975
Log:
PR tree-optimization/36118
* passes.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-06 08:23 ---
How is LC defined?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-06 09:29 ---
Created an attachment (id=15585)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15585action=view)
files (.f .gcda .mod) needed to reproduce the ICE and a README
attached the files needed to trigger the
It could be useful if gcc colorizes its output. Colors allow easier to
distinguish errors and warnings from makefile commands and etc... Currently
there exist a separate script like colorgcc which colorizes output of compiler
but it does not works with localized bugs.gentoo.org/168709 output so
Compiling the following code fails with g++ 4.2.1 (also with 4.1.3 and 4.3.0
but works with 4.0.1 and 4.0.2)
--
templateclass T class A
{
public:
T operator*() { return *m; }
T *m;
};
templateclass T class B
{
public:
T operator*() { return *m; }
T *m;
};
class X
--- Comment #6 from rguenther at suse dot de 2008-05-06 10:22 ---
Subject: Re: [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
On Tue, 6 May 2008, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-06 04:15
---
Oh we don't
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
The tests gcc.dg/vect/vect-reduc-1short.c and vect-reduc-9.c fail at revision
134957 with:
/var/tmp//ccTL0QBh.s:61:invalid character '' in mnemonic
/var/tmp//ccTL0QBh.s:65:invalid character '' in mnemonic
The assembly file vect-reduc-9.s contains at line 47:
psat_plusminus_mnemonicw
Use of an optional kind parameter on a call to the intrinsic size was added in
Fortran 2003, and is essential to avoid overflow when dealing with arrays
bigger than huge(0). The following example provides test code and demonstrates
this.
gfortran should warn that this is non-standard fortran 90/95
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-06 11:12
---
Is that a clean build? The symbol is new and I think sometimes dependencies
don't get updated fine. I saw that one at some point, but a clean build made it
disappear.
--
fxcoudert at gcc dot gnu dot org
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-05-06 12:00
---
(In reply to comment #1)
Is that a clean build? The symbol is new and I think sometimes dependencies
don't get updated fine. I saw that one at some point, but a clean build made
it
disappear.
Next time you
--- Comment #4 from jv244 at cam dot ac dot uk 2008-05-06 12:08 ---
older gcc versions (tested 4.2.3 and 4.3.0) seem to work fine
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-06 12:08
---
(In reply to comment #2)
Next time you see such an issue, can you please try to note as many details as
possible, open a PR and Cc: me?
I will, sorry. I was really more in a hurry of getting my patch
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-05-06 12:14
---
Subject: Re: selected_char_kind_1.f90 undefined
reference with -m32
* fxcoudert at gcc dot gnu dot org wrote on Tue, May 06, 2008 at 02:08:59PM
CEST:
I can only see that happening with
--- Comment #1 from dominiq at lps dot ens dot fr 2008-05-06 12:17 ---
It seems to be fixed at (or before) revision 134981.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36152
I'm encountering an internal compiler error with the gcc 4.3.0 release. I don't
think this is a duplicate of any other bugs.
Here is the command and subsequent output:
powerpc-eabispe-gcc -I../ -I/home/patrick/src/e7/prex
-I/home/patrick/src/e7/prex/usr/include
--- Comment #1 from patrick at motec dot com dot au 2008-05-06 12:46
---
Created an attachment (id=15586)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15586action=view)
preprocessed source
preprocessed source for the file that causes the bug, as required by bug
writing
--- Comment #3 from ubizjak at gmail dot com 2008-05-06 12:55 ---
This is due to this code snippet from i386.c, ix86_expand_binop_builtin ():
--cut here--
/* ??? Using ix86_fixup_binary_operands is problematic when
we've got mismatched modes. Fake it. */
xops[0] = target;
--- Comment #3 from dino at concisoft dot com 2008-05-06 14:18 ---
templateclass Y static LINK* LC(Y* X) {
return static_castLINK*(X);
}
templateclass Y static const LINK* LCC(Y* X) {
return static_castconst LINK*(X);
}
--
--- Comment #5 from ian at airs dot com 2008-05-06 14:23 ---
I introduced DECL_BASED_ON_RESTRICT_P because the conversion to SSA discarded
almost all information about restrict qualifiers. The compiler was tracking
restrict qualifiers on the original variable, but not on the GIMPLE
This patch
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00275.html
breaks UTF tests on Linux. Does check_effective_target_4byte_wchar_t
really work? I got
bash-3.2$ cat w.c
#if 0
#include wchar.h
#endif
int
main ()
{
int dummy[sizeof (wchar_t) = 4 ? 1 : -1];
return 0;
}
bash-3.2$ gcc -c w.c
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-06 14:43 ---
Confirmed. Note: Using -std=f95 the kind= is properly rejected.
==16567== Invalid read of size 4
==16567==at 0x4605FD: gfc_resolve_expr (resolve.c:2310)
==16567==by 0x465625: resolve_code (resolve.c:6195)
Revision 134973
http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00133.html
breaks gfortran.dg/fmt_t_7.f on Linux/ia32 and Linux/Intel64.
--
Summary: gfortran.dg/fmt_t_7.f failed
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
The following subroutine produces a segfault when compiled with the 05/02/08
snapshot of gfortran 4.4.0 under FreeBSD i386. I believe it is related to Bugs
36139 and 36140. This test case is just like the first one in Bug 36139 except
that the PARAMETER statement is omitted.
SUBROUTINE mnbrak
Fortran 2008 (PR 33197) supports the BESSEL_* functions. However, for BESSEL_*N
there are two versions:
A) An elemental function BESSEL_YN(N, X) and BESSEL_JN(N,X)
B) An transformational function BESSEL_YN(N1,N2,X) and BESSEL_JN(N1,N2,Y)
(B) Is currently not supported:
The result of BESSEL_JN
--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-06 15:17 ---
The problem arises because fortran/trans-intrinsics.c and
libgfortran/intrinsics/size.c were not updated to deal with
the addition of the KIND keyword. If you change the code to
use size(array, dim=1, kind=long),
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 15:23 ---
This looks like you are violating C/C++ aliasing rules from that definition.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36154
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 15:26 ---
*** Bug 36152 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-06 15:26 ---
*** This bug has been marked as a duplicate of 36144 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 15:28 ---
I don't think we should do this. There is already a secondary program that
does the coloring too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
--- Comment #12 from hjl at gcc dot gnu dot org 2008-05-06 15:41 ---
Subject: Bug 35657
Author: hjl
Date: Tue May 6 15:41:08 2008
New Revision: 134987
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134987
Log:
2008-05-06 H.J. Lu [EMAIL PROTECTED]
PR target/35657
--- Comment #5 from dino at concisoft dot com 2008-05-06 15:42 ---
Are we missing a const, or would you care to give a bit more specific comment?
I see that:
templateclass Y static const LINK* LCC(Y* X) {
return static_castconst LINK*(X);
}
could be missing a const in
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 15:44 ---
This is correct behavior.
templateclass T void bar( T v ) { v.foo(); }
templateclass T void bar( BT x ) { bar( *x ); }
templateclass T void bar( AT x ) {
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-05-06 15:45 ---
As I mentioned it looks like you are violating aliasing rules. Basically you
are accessing one type as another. But without a full testcase I cann't be
sure. Also Does -O2 -fno-strict-aliasing work?
--
[EMAIL PROTECTED] tmp]$ cat a.cc
#include stdio.h
#include emmintrin.h
struct A {
public:
__m128i m;
void init() { m = _mm_setzero_si128(); }
};
int main()
{
A * a = new A;
printf(Address of A: %p\n, a);
a-init();
delete a;
return 0;
}
[EMAIL
--- Comment #20 from hjl dot tools at gmail dot com 2008-05-06 16:10
---
It is a bug in testcase. But g++ doesn't diagnose it properly. I opened
PR 36159 for it.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 16:11 ---
Actually we (Sony) have come up with a solution but not much as come about with
it though.
If you read Trevor's proposal, you would have found we did come up with one.
--
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-06 16:28 ---
Trevor, can you scale down your original proposal just to issue an
error when there is no class-specific operator new for a type with
an alignment greater than what malloc() guarantees? It will be
programmer's
--- Comment #7 from dino at concisoft dot com 2008-05-06 16:54 ---
-O2 -fno-strict-aliasing does work.
I think the LC and LLC functions always cast from a derived class to a base
class. That shouldn't cause aliasing problems, but I need to learn more about
that.
Thanks.
--
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-06 17:07 ---
Subject: Bug 36117
Author: burnus
Date: Tue May 6 17:06:54 2008
New Revision: 134988
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134988
Log:
2008-05-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2008-05-06 17:09 ---
FIXED on the trunk (4.4.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-06 17:11 ---
I think this is side effect of reverting the patch of PR 34974 (which caused
several regressions) without removing its now failing test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
--- Comment #3 from tromey at gcc dot gnu dot org 2008-05-06 17:15 ---
Subject: Bug 36088
Author: tromey
Date: Tue May 6 17:15:07 2008
New Revision: 134989
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134989
Log:
gcc/testsuite
PR preprocessor/35313, PR
--- Comment #3 from tromey at gcc dot gnu dot org 2008-05-06 17:15 ---
Subject: Bug 35313
Author: tromey
Date: Tue May 6 17:15:07 2008
New Revision: 134989
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134989
Log:
gcc/testsuite
PR preprocessor/35313, PR
--- Comment #2 from esigra at gmail dot com 2008-05-06 17:27 ---
I would definitely like GCC to produce colourized output. It can really improve
the readability. I miss that feature. It has my vote.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-06 17:35 ---
http://schlueters.de/colorgcc.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 17:37 ---
I rather not add too much complexity to gcc diagnostic output. Which means no
color. colorgcc could be extended to get the correct coloring for the
locazation.
See also
--- Comment #4 from esigra at gmail dot com 2008-05-06 18:00 ---
(In reply to comment #3)
2) Standards are not freely distributable, thus they are not widely available.
You say that as if it was a general fact, but it is certainly not. For example
the Ada reference manual is available
--- Comment #5 from pva at gentoo dot org 2008-05-06 18:07 ---
Andrew, it's very pity to see this bug closed as invalid so fast. Besides being
useful, people enjoy colors and people work with compilers...
I've already stated that, but I repeat. colorgcc does not work in case you have
--- Comment #4 from tromey at gcc dot gnu dot org 2008-05-06 18:09 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #4 from tromey at gcc dot gnu dot org 2008-05-06 18:10 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-06 18:12 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00333.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
print *, 'Hello World'wrong ! position is OK
1
Error: Syntax error in PRINT statement at (1)
print *, 'Hello W\xC3\xB6rld'wrong ! Position is misleading
1
Error: Syntax error in PRINT statement at (1)
(see proposition by Tobias at
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-06 18:21 ---
But seriously colorization should not be done in the compiler. Just like IDE
should not be part of the compiler ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
--- Comment #2 from hjl at gcc dot gnu dot org 2008-05-06 18:37 ---
Subject: Bug 36155
Author: hjl
Date: Tue May 6 18:37:03 2008
New Revision: 134994
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134994
Log:
2008-05-06 H.J. Lu [EMAIL PROTECTED]
PR testsuite/36155
--- Comment #6 from esigra at gmail dot com 2008-05-06 18:40 ---
(In reply to comment #4)
I rather not add too much complexity to gcc diagnostic output. Which means
no color.
We did not demand that you do it personally. We just think that it would be a
really good idea if someone
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-06 18:45
---
The mingw-w64 CRT were wrong, but have been fixed since then.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from esigra at gmail dot com 2008-05-06 18:47 ---
(In reply to comment #5)
But seriously colorization should not be done in the compiler. Just like IDE
should not be part of the compiler ...
Colorization of a message is part of the message. It should obviously be done
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-05-06 18:58 ---
Subject: Bug 36130
Author: bkoz
Date: Tue May 6 18:57:46 2008
New Revision: 134995
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134995
Log:
2008-05-06 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-05-06 19:02 ---
The compiler parts of this are done, or well along in terms of progress.
For the library, I think it makes sense to start with _GLIBCXX_USE_CHAR16_T and
_GLIBCXX_USE_CHAR32_T configury and macros, and then ease into
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-06 19:09
---
I xfailed it and forgot to commit it. I will do that tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
--- Comment #3 from vmakarov at redhat dot com 2008-05-06 19:11 ---
Thanks for decreasing the test case. The problem was in wrong mode of
save/restore stack slot when it was reused for another hard register. It
resulted in generation of wrong save/restore insn and after that in a
--- Comment #4 from vmakarov at gcc dot gnu dot org 2008-05-06 19:22
---
Subject: Bug 36028
Author: vmakarov
Date: Tue May 6 19:22:07 2008
New Revision: 134996
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134996
Log:
2008-05-06 Vladimir Makarov [EMAIL PROTECTED]
PR
The first argument of gfc_error seems to be a format string of the form tagged
with gcc-internal-format elsewhere in the po file. But it seems gfc_error
formats are instead tagged with no-c-format. This is somewhat dangerous, since
msgfmt will not discover mistakes in the translation, mistakes
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-05-06 20:47
---
Subject: Bug 35990
Author: tkoenig
Date: Tue May 6 20:46:41 2008
New Revision: 134999
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134999
Log:
2008-05-06 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-05-06 20:47 ---
Subject: Bug 35995
Author: tkoenig
Date: Tue May 6 20:46:41 2008
New Revision: 134999
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134999
Log:
2008-05-06 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-05-06 20:49 ---
Fixed on 4.3.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-05-06 20:50
---
Fixed on 4.3.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-05-06 20:53 ---
Hi Jerry,
did you commit the test case to make sure we don't
regress again?
Thomas
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-05-06 21:24 ---
Created an attachment (id=15587)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15587action=view)
Trial patch
Here's an attempt at a patch, which should do the
right thing at least for this case.
--
We need to escape non-printable characters when we read/write module files.
Otherwise, big bad ICE:
module m
character(*), parameter :: a ='H\0z'
end module m
use m
print *, a ! ICE
print *, ichar(a(1:1)), ichar(a(2:2)), ichar(a(3:3)) ! ICE
end
--
Summary: Non-ASCII character
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from brian at dessent dot net 2008-05-06 21:28 ---
Subject: Re: colorize output of gcc
esigra at gmail dot com wrote:
And seriously, what is more efficcent, adding a
colour code sequence to the string constans in GCC that says warning:,
error: etc or having a bunch
This code:
namespace name {
class foo {
public:
templateclass T
voidbaz(T t) { int i = t.dat; }
};
}
using namespace name;
class bar {
friend class foo;
int dat;
};
int main() {
bar b;
foo f;
f.baz(b);
}
gets you:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 21:31 ---
I don't think this is a bug, the friend class here is really ::foo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
--- Comment #3 from hjl at gcc dot gnu dot org 2008-05-06 21:36 ---
Subject: Bug 36155
Author: hjl
Date: Tue May 6 21:35:33 2008
New Revision: 135008
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135008
Log:
2008-05-06 H.J. Lu [EMAIL PROTECTED]
PR testsuite/36155
--- Comment #2 from igodard at pacbell dot net 2008-05-06 21:39 ---
Isn't ::foo the using'd class from name? If not, how does one befriend a class
that comes from a using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
--- Comment #8 from esigra at gmail dot com 2008-05-06 21:55 ---
(In reply to comment #7)
If you added escape sequences to the string constants in the gcc source
then it would only work for the C locale messages.
Adding escape sequences for colours would work as well with
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-06 21:58 ---
The other issue here is that people want different colors for each of their
warnings so why hardcode it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
--- Comment #10 from brian at dessent dot net 2008-05-06 22:06 ---
Subject: Re: colorize output of gcc
esigra at gmail dot com wrote:
printf(%s%s%s%s, warning_format_start, _(warning: ), _(the actual
message), warning_format_end);
But then that is not simply adding a colour code
--- Comment #6 from jakub at gcc dot gnu dot org 2008-05-06 22:56 ---
Created an attachment (id=15588)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15588action=view)
gcc44-pr36013.patch
Patch I've bootstrapped/regtested on x86_64-linux. Will you check this in, or
should I mail
A few routines seem to have disappeared from 4.0.0 to 4.2.1:
mrs2 $ nm /usr/lib/libstdc++.6.0.4.dylib | grep
__ZN9__gnu_cxx18stdio_sync_filebuf | c++filt
000252d2 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::file()
000252fc T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-07 00:12 ---
Was this ever supposed to be used external from libstdc++?
It is in the __gnu_cxx namespace. I don't think they are exported at all under
GNU/Linux with elf exports.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-07 00:18 ---
# __gnu_cxx::stdio_sync_filebuf
_ZTVN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EEE;
_ZN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EE4fileEv;
1 - 100 of 113 matches
Mail list logo
