--- Additional Comments From zhr_buaa at 263 dot net 2005-06-27 06:13
---
this is my command line to compile the source file. then, i change the option -c
to -E and option -o, to generate the dsputil.i. wish this can help u.
arm-linux-gcc -I../libvo -I../../libvo -pipe -mcpu=iwmmxt -g
--- Additional Comments From zhr_buaa at 263 dot net 2005-06-27 06:19
---
the following is printed by command 'arm-linux-gcc -v'. hope it useful!
Reading specs from /opt/arm-linux/bin/../lib/gcc/arm-linux/3.4.3/specs
Configured with:
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-27
06:38 ---
As you can see from those numbers Dan Kegel posted, this kind of test case
is very sensitive to the intermediate representation presented to the inliner
and to inliner heuristics. Personally, I don't
--- Additional Comments From dank at kegel dot com 2005-06-27 06:59 ---
I just reproduced this on two flavors of pentium 4 using -O3 -mtune=pentium.
The regression is worse, sometimes much worse, with -fPIC.
Times for gcc-2.95.3, gcc-3.4.3, gcc-4.0.0, gcc-4.1-20050603:
test run 1:
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-27
07:41 ---
For gcc4, the no-PIC case looks pretty good to me ;-)
--
What|Removed |Added
Known to
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-27
07:59 ---
Dan, can you show the assembler output for 2.95.3 and 4.0 (why is 4.1 n/a??)
for the -fPIC case?
--
What|Removed |Added
--- Additional Comments From oliverst at online dot de 2005-06-27 09:32
---
OK, I got a more recent version of the binutils and I know get this:
91 C:\cvs\STLport\stlport\stl\_new.h [Warning] visibility attribute not
supported in this configuration; ignored
Guess this can be closed
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27
09:49 ---
Created an attachment (id=9156)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9156action=view)
Proposed patch.
--
What|Removed |Added
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27
09:51 ---
(From update of attachment 9156)
The patch was for the wrong bug report *sigh*.
--
What|Removed |Added
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27
09:53 ---
Created an attachment (id=9157)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9157action=view)
Patch fixing the issue with overwriting the target array.
--
What|Removed
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From bruno at clisp dot org 2005-06-27 11:50
---
Indeed, the result is much better now, nearly optimal.
As you say, the only further optimization possible is that a better
register allocation could get rid of the
movl%edx, %esi
and
movl
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27
12:02 ---
This is missing:
*** eoshift3.m4 2005-06-27 14:05:51.0 +0200
--- /home/zfkts/gcc-maint/libgfortran/m4/eoshift3.m42005-06-27
11:47:13.0 +0200
***
*** 136,142
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27
12:11 ---
Actually, the patch should be the other way around.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22142
Compile this code with -O2 -Wall on 4.0.x or mainline:
-
struct testme {
int testval;
int unusedval;
};
extern void forget (struct testme forgotten);
int main () {
struct testme testarray[1];
struct testme testvar;
testvar.testval =
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
13:31 ---
but isn't that the same as (except it is an aggregate in the case in comment
#1):
void g(int);
void f(void)
{
int i;
g(i);
}
because g might not look at the agrument value?
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
13:38 ---
Reduced testcase:
int rd8x8_c( int stride)
{
unsigned long long __attribute__ ((aligned (4))) aligned_bak[stride];
unsigned char * const bak= (unsigned char*)aligned_bak;
}
Confirmed, only happens
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
13:39 ---
So closing as invalid.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From oakad at yahoo dot com 2005-06-27 13:43
---
I also have this bug with gcc-4.0.0 (powerpc-eabi on cygwin). It always happens
when msdata flag is present (eabi or sysv - same result). It is caused by the
attempt to initialize a global float/double variable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
13:49 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From matz at suse dot de 2005-06-27 13:50 ---
Hmm, sort of. The call of g(i) also warns with is used, although I
think it might deserve only a may be used. But anyway I think that
this nevertheless has different causes. It's not the call creating
the
--- Additional Comments From schwab at suse dot de 2005-06-27 13:57 ---
In the case of g(i) you have an initialisation of the parameter variable which
already constitutes a use of the value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22197
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
14:10 ---
This fails at -O0 also on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18818
--
What|Removed |Added
GCC build triplet|powerpc-apple-darwin7.7.0 |
GCC host triplet|powerpc-apple-darwin7.7.0 |
GCC target triplet|powerpc*-*-*
--- Additional Comments From marc dot price at rd dot bbc dot co dot uk
2005-06-27 14:31 ---
Has this bug been fixed yet? Would really like to upgrade my linux box, but
can't because this bug prevents me from compiling a vital suite of software.
Can we bump-up the priority?
TIA
Marc
The attached code is OK with gcc 3.3.6 debian and gcc 4.0 without -O2 but does
not generate pmaddw
instruction with gcc 4.0 and -O2.
The compile line is
/usr/local/bin/gcc -save-temps -msse2 -Wall -O2 -o bug-report bug-report.c
and the values are NOT initialized in the gcc 4.0 -O2 setup.
--
--
What|Removed |Added
Component|c |target
Keywords||wrong-code
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-06-27
15:03 ---
Created an attachment (id=9160)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9160action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
$ cat labs.c
extern long int labs (long int __x) __attribute__ ((__const__));
int main()
{
int a,b;
foo(a, b);
if (labs(a) b)
return 1;
else
return 0;
}
is translated with
$ gcc -O3 -fdump-tree-optimized -S labs.c
into
bb 0:
foo (a, b);
return (int)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:06 ---
Does -fno-strict-aliasing help as you are violating C aliasing rules:
a128 = _mm_load_si128((__m128i *)a_storage);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-06-27
15:14 ---
Well, ld do segfault now...
To be honest I don't know about C aliasing rules ;-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:17 ---
A better example as on 32bit targets long and int are the same size which
removes the casts:
extern long long int llabs (long long int __x) __attribute__ ((__const__));
int main()
{
int a,b;
GCC does not have a proper modulo overflow semantics for signed
integral types.
1. The loop optimizer seems to assume that signed overflow does
not happen (or is undefined).
2. On x86 INT_MAX/-1 seems to trap (instead of implementing
modulo semantics).
In that case
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:21 ---
INT_MAX/-1 is undefined.
and signed overflow is undefined.
Why file this bug when the comments on the list say this is not a bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:23 ---
*** This bug has been marked as a duplicate of 21920 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:23 ---
*** Bug 22198 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
15:33 ---
This is a bug because std::numeric_limitssigned::is_modulo
should be true only if singed overflow is defined.
This is not the case with gcc, because gcc does not have the
extension signed oveflow == module
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:40 ---
I think we need to read:
ISO/IEC 10967-1 Language Independent Arithmetic, part 1 since that is what
the standard references
for is_modulo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-06-27
15:45 ---
Sorry, no segfault of ld. My mistake - wrong compilation options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 16:06 ---
Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| INT_MAX/-1 is undefined.
| and signed overflow is undefined.
|
| Why
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
16:07 ---
Actually it is modulo for all operations.
and INT_MAX/-1 does not raise a trap.
--
What|Removed |Added
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 16:09 ---
Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| I think we need to read:
| ISO/IEC 10967-1 Language Independent
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-27 16:21
---
(In reply to comment #1)
INT_MAX/-1 is undefined.
and signed overflow is undefined.
Why file this bug when the comments on the list say this is not a bug?
(In reply to comment #5)
Actually it is modulo
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Actually it is modulo for all operations.
But then do read the comment as far as the loop optimizer is
concerned. It does not seem like it understands that it is modulo
arithmetic.
| and INT_MAX/-1 does not raise a trap.
It that is
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 16:25 ---
Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Actually it is modulo for all operations.
But then do read the
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-27
16:25 ---
mine
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-27
16:32 ---
(In reply to comment #1)
Why file this bug when the comments on the list say this is not a bug?
It's for the potentially long debate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
16:35 ---
In Comment #5 Andrew Pinski writes:
Actually it is modulo for all operations.
and INT_MAX/-1 does not raise a trap.
That was a typo on my part.
It was supposed to be INT_MIN/-1
INT_MAX/-1 does not
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-27
16:36 ---
Subject: Bug 22102
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-27 16:35:51
Modified files:
libstdc++-v3 : ChangeLog
--- Additional Comments From pcarlini at suse dot de 2005-06-27 16:37
---
N.B. This first part will go also in 4_0-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22102
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27
16:52 ---
The problem here is that the code in patch_binop that
converts URSHIFT_EXPR to RSHIFT_EXPR modifies the type and
code of the tree in place -- but that is incorrect as it misses
the final cast back to a
On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote:
| Actually it is modulo for all operations.
But then do read the comment as far as the loop optimizer is
concerned. It does not seem like it understands that it is modulo
arithmetic.
But that is because overflow is
--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-27
16:53 ---
Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc
On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote:
| Actually it is modulo for all operations.
But then
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27
16:59 ---
I'm testing a fix.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-27
17:05 ---
(In reply to comment #12)
Why does ivcanon/tree-ssa-loop-niter gets this correct (at 128) but VRP
cannot.
Wrong. scev fails to tell us that this variable may wrap around.
--
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-06-27 17:09 ---
Subject: Re: [4.0/4.1 Regression] avr dwarf-2 support is broken for head
4.0/4.1
Hi Andrew,
One question about gcc policy: There exists a patch resolving 19885 since a
couple of weeks. The latest
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:13 ---
Here is a reduced testcase:
MODULE module1
TYPE type1
INTEGER TYP1
END TYPE type1
END MODULE
MODULE module2
TYPE type2
INTEGER TYP2
END TYPE type2
END MODULE
MODULE mymodule
CONTAINS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:13 ---
*** Bug 21986 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:21 ---
This is a regression and shows up every where.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:29 ---
(In reply to comment #7)
Andrew --
You do not seem to understand this PR. Please DO NOT close it.
Your eagerness to close PRs is doing harms -- that was already debated
last couple o weeks and I do
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:34 ---
Invalid as the C++ standard says:
True if the type is modulo.203) A type is modulo if it is possible to add two
positive numbers and
have a result that wraps around to a third number that is less.
--- Additional Comments From schlie at comcast dot net 2005-06-27 18:00
---
(In reply to comment #13)
Invalid as the C++ standard says:
True if the type is modulo.203) A type is modulo if it is possible to add
two positive numbers and
have a result that wraps around to a third
In the po files for version 4.0.1-b20050607 there are two strings from
params.def:
how much can given compilation unit grow because of the inlining (in percent)
and
expense of call operation relative to ordinary aritmetic operations
All other description strings in this context begin with a
--
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
18:08 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 18:19 ---
Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc
pinskia at physics dot uc dot edu [EMAIL PROTECTED] writes:
| Subject: Re: numeric_limitssigned::is_modulo is inconsistend with
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 18:23 ---
Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| --- Additional Comments From pinskia at gcc dot gnu dot org
The description of the parameter max-variable-expansions-in-unroller in
param.def contains a lot of white space between of and times and between
expanded and during. It should just be a single space there I suppose.
--
Summary: Superfluous space in description of max-variable-
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-27 18:25
---
Andrew is being silly.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 18:27 ---
Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| --- Additional Comments From pinskia at gcc dot gnu dot org
The followign program should not abort on PPC because PPC has no trapping
instructions integer
division instruction.
#include limits
extern C void abort(void);
int main(void)
{
if ( std::numeric_limitsint::traps)
abort ();
}
--
Summary: std::numeric_limitsint::traps is wrong
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
18:34 ---
(In reply to comment #16)
Thanks, I'm the author of limits. For all useful purposes, please
Andrew go back and read the link I gave to RTH's message.
Yes and RTH's comment about trapping is wrong,
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-27
18:40 ---
Subject: Bug 13788
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-27 18:40:17
Modified files:
libjava: ChangeLog
gcc/java :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-27
18:40 ---
Subject: Bug 21540
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-27 18:40:17
Modified files:
libjava: ChangeLog
gcc/java :
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27
18:41 ---
I checked this in to cvs trunk.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27
18:41 ---
I checked in the fix on cvs trunk.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 18:46 ---
Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| --- Additional Comments From pinskia at gcc dot gnu dot org
--- Additional Comments From p dot obry at wanadoo dot fr 2005-06-27 18:50
---
Danny,
(In reply to comment #10)
The patch that was committed to fix this is wrong.
#ifdef TARGET_DLLIMPORT_DECL_ATTRIBUTES is always true. It is defined to 0
for
non-dll targets in defaults.h.
I
Please see attached file for information specified in the bug reporting
instructions
--
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
--- Additional Comments From pplppp at gmail dot com 2005-06-27 19:24
---
Created an attachment (id=9161)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9161action=view)
information specified in the bug reporting instructions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
--
What|Removed |Added
GCC target triplet||i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
--
What|Removed |Added
Keywords||ice-on-valid-code
Summary|internal compiler error:|[4.0/4.1 Regression] [repo]
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-27
19:41 ---
Testing patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
On systems without weak, debug mode tests will fail. This causes some
unpleasantness on AIX, for instance.
This can be verified on x86/linux using -fno-weak.
What needs to happen is that the debug mode tests should be smart enough to tell
if the underlying system doesn't support weak, so that
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-27 19:47
---
Created an attachment (id=9162)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9162action=view)
libstdc++.log for AIX, demonstrating issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
Hi,
Has anyone seen this?
When a prototyped function of var-arg is called without any arguments
to the variable part, crxor 6,6,6 is not generated. -O0
-mno-prototype does NOT resolve the problem either.
test.c
int test(const char *a, ...);
void test1(const char *a)
{ test(a,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
20:22 ---
Reduced testcase:
#include typeinfo
templateint
struct function1
{
function1(void (*f)(void))
{
typeid(int (*)(char));
}
};
void inputclassifier(void){}
function11 b(inputclassifier) ;
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
20:28 ---
(In reply to comment #13)
Invalid as the C++ standard says:
True if the type is modulo.203) A type is modulo if it is possible to add
two positive numbers and
have a result that wraps around to a third
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
20:28 ---
we get this ICE:
t.cc:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
And
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
20:30 ---
And another testcase, this time with an array:
#include typeinfo
templateint
struct function1
{
function1()
{
typeid(int[100]);
}
};
function11 b;
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
21:02 ---
(In reply to comment #21)
1. Sometimes using undefined simplifies the compiler and improves
generated code.
2. (OTOH) Undefind situations are unhelpful the the users, they complicate
debugging,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
21:59 ---
This is a regression in that you no longer can use the debug mode with
-fno-weak.
--
What|Removed |Added
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
22:00 ---
(In reply to comment #22)
(In reply to comment #21)
2. (OTOH) Undefind situations are unhelpful the the users, they complicate
debugging, and make programming harder. Reducing rules that imply
--- Additional Comments From dje at gcc dot gnu dot org 2005-06-27 22:01
---
AIX 5.2 does support weak, so I believe that there is something wrong with the
analysis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
--- Additional Comments From masse_nicolas at yahoo dot fr 2005-06-27
22:02 ---
h well. I made an include at the end of my file... it works now. But this is
not a nice solution I find.
Well, I'll continue that way for now, and wait for the export method to be
implemented. I will
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
22:03 ---
Actually if you look into the email which David sent, you would see:
# 0 built-in
#define __GXX_WEAK__
Which means there is weak support.
--
What|Removed |Added
gcc-3.4.3 fails to accept this valid program:
namespace Fwk {
int valueToStrep( char const * ) { return 100;}
}
using Fwk::valueToStrep;
namespace Foo {
int valueToStrep( int ) { return 200; }
int foo2() { return valueToStrep( hello ); }
}
If you comment out the second valueToStrep
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
23:07 ---
This is invalid code but I don't have the time to explain why except to say
that when inside a
namespace, you look into the inner most namespace first and if it does not find
any then the outer for
The following reduced test case causes spurious -Wuninitialized warnings, but
only with -O2:
-
#include vector
#include string
class OptionSet
{
public:
OptionSet ();
std::vectorstd::string const nonOptions() const;
private:
std::vectorstd::string nonoptions;
};
1 - 100 of 124 matches
Mail list logo
