Re: gcc-current: badly worded warning?
Hey Eyal, > I see two kinds of warnings: > warning: logical '||' with non-zero constant will always evaluate as > true > warning: logical '&&' with non-zero constant will always evaluate as > true > > The first statement is true, the second false. You're right. Can you please file a PR for this? Thanks, Ben
libstdc++ is having "out of memory" string
Hi All, I am getting "out of memory" strings error log of our product. It seems that error message "out of memory" doesn't have our common error format. We suspect that GCC library libstdc++.a is giving this error code. #strings libstdc++.a | egrep "out of memory" out of memory Can you please clarify this? Regards Sanjeevi
Re: libstdc++ is having "out of memory" string
I am getting "out of memory" strings error log of our product. It
seems that error message "out of memory" doesn't have our common error
format.
This is most probably coming from:
include/backward/defalloc.h
where:
template
inline _Tp* allocate(ptrdiff_t __size, _Tp*) {
set_new_handler(0);
_Tp* __tmp = (_Tp*)(::operator new((size_t)(__size * sizeof(_Tp;
if (__tmp == 0) {
cerr << "out of memory" << endl;
exit(1);
}
return __tmp;
}
This function, and this file, are deprecated. It is recommended that
you use std::allocator instead.
-benjamin
RFI: g++(templates): confusing error messages.
Hello,
$ g++ -c err.cc
err.cc:7: error: prototype for 'void C::foo(const int&)' does not match
any in class 'C'
err.cc:3: error: candidate is: void C::foo(const T&) [with T = int]
err.cc:7: error: template definition of non-template 'void C::foo(const
int&)'
$
Note that substituting 'int' for 'T' in the only candidate (reported in
error line 2) gives exactly the prototype in error line 1. Yes, the
third error line gives a clue, but the natural way to read error
messages is top-to-bottom, and the first two lines are really
puzzling. It'd be much better if the first two lines of the error
messages were not output at all, I think.
$ cat err.cc
template
struct C {
void foo(T const&) {}
};
template
void C::foo(int const&) {}
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: [...]
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
$
-- Sergei.
RFI: g++(classes): inconsistent error messages.
Hello,
The same programming error gives very different diagnostic using member
function and stand-alone function:
$ cat err1.cc
struct C {
static void f(char const*& p);
};
void b(char* p) {
C::f(const_cast(p));
}
$ cat err2.cc
extern void f(char const*& p);
void b(char* p) {
f(const_cast(p));
}
$ g++ -c err1.cc
err1.cc: In function 'void b(char*)':
err1.cc:6: error: no matching function for call to 'C::f(const char*)'
err1.cc:2: note: candidates are: static void C::f(const char*&)
$ g++ -c err2.cc
err2.cc: In function 'void b(char*)':
err2.cc:4: error: invalid initialization of non-const reference of type 'const
char*&' from a temporary of type 'const char*'
err2.cc:1: error: in passing argument 1 of 'void f(const char*&)'
$
I think the error message for member function is too difficult to
understand, whereas those for stand-alone function is crystal-clear.
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: [...]
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
$
-- Sergei.
Re: A reload inheritance bug
Bernd Schmidt wrote: insn 5301: (set (reg/f:SI 4082) (reg/f:SI 3275)) insn 5291 (set (reg:DF 4078]) (mem/s:DF (plus:SI (reg/f:SI 3275) (reg:SI 3812 REG_DEAD 3275 insn 5314 (set (reg:DF 4096) (mem/s:DF (plus:SI (reg/f:SI 4082) (reg:SI 4084 After reload we end up with the following. I've added dividers to show the correspondence with the insns above. insn 5301 (set (mem/f/c:SI (plus:SI (reg/f:SI 13 sp) (const_int 12))) (reg/f:SI 9 r9 [3275])) --- insn 6675 (set (reg:SI 9 r9) (plus:SI (reg/f:SI 9 r9 [3275]) (reg:SI 10 sl [3812]))) insn 5291 (set (reg:DF 75 s12 [4078]) (mem/s:DF (reg:SI 9 r9))) --- insn 6680 (set (reg:SI 1 r1) (const_int 4928)) insn 6681 (set (reg:SI 1 r1) (plus:SI (reg/f:SI 9 r9 [3275]) (reg:SI 1 r1))) insn 5314 (set (reg:DF 75 s12 [4096]) (mem/s:DF (reg:SI 1 r1))) We see here how pseudo 3275 was allocated to r9 and pseudo 4082 was spilled to the stack. At insn 5291, r9 has been allocated [*] as the reload register since pseudo 3275 dies in that instruction; at insn 5314 we see the then-incorrect use of r9 (in instruction 6681) for the value of pseudo 4082. Note also how the dump shows that the compiler thinks r9 still holds the value of pseudo 3275 at insn 6681. Presumably this is one thing that is mildly unusual - R9 being chosen in find_reloads already. This wouldn't happen later, since it's in reg_used_in_insn and therefore disallowed. Sorry for the delay in replying -- hectic week! As you say, one unusual thing about this situation must be the fact that the reload register is getting chosen by the code in push_reload heralded by "If this is an input reload and the operand contains a register that dies in this insn and is used nowhere else, see if it is the right class to be used for this reload. Use it if so." etc. I suspect it is the conjunction of this code and the behaviour of reload in choosing r9 for pseudo 4082 in insn 5314 above that causes the problem. I don't entirely follow your example below... Still, assume a similar sequence insn 5301: (set (reg/f:SI 4082) (reg/f:SI 3275)) insn 5291 (set (reg:DF 4078]) (unspec:DF (mem/s:DF (plus:SI (reg/f:SI 3275) (reg:SI 3812))) (reg:SI 3275))) REG_DEAD 3275 insn 5314 (set (reg:DF 4096) (mem/s:DF (plus:SI (reg/f:SI 4082) (reg:SI 4084 Here, we wouldn't use R9 as reload register in 5291 ...since here, as far as I understand it, the clause mentioned above in push_reload wouldn't select r9 to use as a reload register for 5291. My gut feeling is that this example will work as a consequence. (Perhaps you're getting at the fact that the decision procedure leading us to choose r9 for pseudo 4082 in insn 5314 might be at fault instead? Even if so, I still suspect it's the reuse of a hard reg in an insn with a REG_DEAD note for the corresponding pseudo that is the real cause because it upsets the later code -- that's what my patch was trying to correct.) Mark
bootstrap problem with trunk on i386-mingw32: target multi-do in libiberty
Bootstrapping today's trunk (rev. 125180) on i386-mingw32 (native)
leads me to the following error at the end of stage3:
make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
libiberty/testsuite'
make[3]: Entering directory `/home/coudert/ibin/i386-pc-mingw32/
libiberty'
make[3]: *** No rule to make target `multi-do'. Stop.
make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
libiberty'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
libiberty'
make[1]: *** [all-target-libiberty] Error 2
make[1]: Leaving directory `/home/coudert/ibin'
make: *** [all] Error 2
It is true that ${builddir}/i386-pc-mingw32/libiberty/Makefile
doesn't have a multi-do rule, while the Makefiles for libgfortran and
libssp do have one. Does someone have an idea how this is triggered?
What can I post to help people debug this? (I have kept the build
directory intact for further debugging, I just don't know what to do
and where to start fishing.)
FX
Re: gcc-current: badly worded warning?
Eyal Lebedinsky wrote: > I see two kinds of warnings: > warning: logical '||' with non-zero constant will always evaluate as true > warning: logical '&&' with non-zero constant will always evaluate as true > > The first statement is true, the second false. It can say (if the case is > such) warning: logical '&&' with zero constant will always evaluate as > false and even warn of > warning: logical '&&' with non-zero constant will have no effect That depends, if the non-zero constant is the LHS of the && operator the warning is IMHO correct. Lothar
Re: bootstrap problem with trunk on i386-mingw32: target multi-do in libiberty
FX Coudert <[EMAIL PROTECTED]> writes:
> Bootstrapping today's trunk (rev. 125180) on i386-mingw32 (native)
> leads me to the following error at the end of stage3:
>
> > make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
> > libiberty/testsuite'
> > make[3]: Entering directory `/home/coudert/ibin/i386-pc-mingw32/
> > libiberty'
> > make[3]: *** No rule to make target `multi-do'. Stop.
> > make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
> > libiberty'
> > make[2]: *** [all] Error 2
> > make[2]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
> > libiberty'
> > make[1]: *** [all-target-libiberty] Error 2
> > make[1]: Leaving directory `/home/coudert/ibin'
> > make: *** [all] Error 2
>
> It is true that ${builddir}/i386-pc-mingw32/libiberty/Makefile
> doesn't have a multi-do rule, while the Makefiles for libgfortran and
> libssp do have one. Does someone have an idea how this is triggered?
> What can I post to help people debug this? (I have kept the build
> directory intact for further debugging, I just don't know what to do
> and where to start fishing.)
The multi-do rule is normally added to Makefile by config-ml.in at the
top level. config-ml.in is normally run by the libiberty configure
script.
Ian
Re: gcc-current: badly worded warning?
Lothar Werzinger <[EMAIL PROTECTED]> writes: > Eyal Lebedinsky wrote: > >> I see two kinds of warnings: >> warning: logical '||' with non-zero constant will always evaluate as true >> warning: logical '&&' with non-zero constant will always evaluate as true >> >> The first statement is true, the second false. It can say (if the case is >> such) warning: logical '&&' with zero constant will always evaluate as >> false and even warn of >> warning: logical '&&' with non-zero constant will have no effect > > That depends, if the non-zero constant is the LHS of the && operator the > warning is IMHO correct. 1 && 0 is still 0. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
RE: gcc-current: badly worded warning?
On 30 May 2007 18:05, Andreas Schwab wrote: > Lothar Werzinger writes: > >> Eyal Lebedinsky wrote: >> >>> I see two kinds of warnings: >>> warning: logical '||' with non-zero constant will always evaluate as true >>> warning: logical '&&' with non-zero constant will always evaluate as true >>> >>> The first statement is true, the second false. It can say (if the case is >>> such) warning: logical '&&' with zero constant will always evaluate as >>> false and even warn of warning: logical '&&' with non-zero constant will >>> have no effect >> >> That depends, if the non-zero constant is the LHS of the && operator the >> warning is IMHO correct. > > 1 && 0 is still 0. But the 0 will never be evaluated. It's more significant in a case such as " && ". cheers, DaveK -- Can't think of a witty .sigline today
Re: gcc-current: badly worded warning?
"Dave Korn" <[EMAIL PROTECTED]> writes: > On 30 May 2007 18:05, Andreas Schwab wrote: > >> Lothar Werzinger writes: >> >>> Eyal Lebedinsky wrote: >>> I see two kinds of warnings: warning: logical '||' with non-zero constant will always evaluate as true warning: logical '&&' with non-zero constant will always evaluate as true The first statement is true, the second false. It can say (if the case is such) warning: logical '&&' with zero constant will always evaluate as false and even warn of warning: logical '&&' with non-zero constant will have no effect >>> >>> That depends, if the non-zero constant is the LHS of the && operator the >>> warning is IMHO correct. >> >> 1 && 0 is still 0. > > But the 0 will never be evaluated. Sure it will. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
RE: gcc-current: badly worded warning?
On 30 May 2007 18:12, Andreas Schwab wrote: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> On 30 May 2007 18:05, Andreas Schwab wrote: >> >>> Lothar Werzinger writes: >>> Eyal Lebedinsky wrote: > I see two kinds of warnings: > warning: logical '||' with non-zero constant will always evaluate as > true warning: logical '&&' with non-zero constant will always evaluate > as true > > The first statement is true, the second false. It can say (if the case > is such) warning: logical '&&' with zero constant will always evaluate > as false and even warn of warning: logical '&&' with non-zero constant > will have no effect That depends, if the non-zero constant is the LHS of the && operator the warning is IMHO correct. >>> >>> 1 && 0 is still 0. >> >> But the 0 will never be evaluated. > > Sure it will. Yeh, I misread it, sorry. cheers, DaveK -- Can't think of a witty .sigline today
Re: gcc-current: badly worded warning?
Andreas Schwab wrote: > 1 && 0 is still 0. > > Andreas. Oops my bad. Didn't think (long enough) before posting ;-) Lothar
AspeCt-oriented C (ACC) Release V 0.6
Hi, We are pleased to announce the release of AspeCt-oriented C (ACC) V 0.6. The ACC 0.6 release includes some experimental features and a new script "tacc" for automatically integrating aspect-compilation in building large C-based software projects. For more details and download, please visit http://www.aspectc.net. Highlights of ACC V 0.6 include: 1. preturn() statement inside advice, allowing advice functions to return immediately from the function containing the matched join point 2. try() pointcut, catch() advice and throw() statment, allowing the adding of exception handling to the core systems via aspects 3. support for "fileName" and "targetName" to the thisJoinPoint structure. 4. introduce a new set of compiler tools, including "tacc" and "accmake". We appreciate feedback and support for AspeCt-oriented C. Additional slides for presenting and promoting ACC are available from our web site. Finally, with ACC V0.6, ACC is able to bootstrap itself. Regards, ACC Team ( www.aspectc.net ) May 30, 2007
Re: fixinclude, math.h and Darwin???
On May 29, 2007, at 6:11 PM, Jack Howarth wrote: I am wondering if it is possible that our problem with these long double calls in gfortran on Darwin PPC could be as simple as gfortran not using this fixed math header on Darwin PPC. No.
gcc-4.2-20070530 is now available
Snapshot gcc-4.2-20070530 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070530/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 125202 You'll find: gcc-4.2-20070530.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20070530.tar.bz2 C front end and core compiler gcc-ada-4.2-20070530.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20070530.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20070530.tar.bz2 C++ front end and runtime gcc-java-4.2-20070530.tar.bz2 Java front end and runtime gcc-objc-4.2-20070530.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20070530.tar.bz2The GCC testsuite Diffs from 4.2-20070523 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Option ordering
http://gcc.gnu.org/PR32102 is about the fact that -Wall -Wstrict-overflow is not the same as -Wstrict-overflow -Wall (i.e., the order of the options matter). The reason is that -Wall sets warn_strict_overflow to 1 and -Wstrict-overflow sets warn_strict_overflow to 2. It is normal and expected that if you specify the same option twice, the later one takes precedence. But it is, perhaps, less expected that a general option like -Wall changes the behaviour of a specific option like -Wstrict-overflow. This of course also applies to the optimization options: -fno-tree-vrp -O2 will cause the -fno-tree-vrp option to be ignored. Does anybody have an opinion on whether the current behaviour is good or bad? The documention suggests that the order of different options does not matter, so if the current behaviour is good, we should fix the documentation. Ian
Re: Option ordering
On Wed, May 30, 2007 at 03:48:05PM -0700, Ian Lance Taylor wrote: > http://gcc.gnu.org/PR32102 is about the fact that -Wall > -Wstrict-overflow is not the same as -Wstrict-overflow -Wall (i.e., > the order of the options matter). The reason is that -Wall sets > warn_strict_overflow to 1 and -Wstrict-overflow sets > warn_strict_overflow to 2. > > It is normal and expected that if you specify the same option twice, > the later one takes precedence. But it is, perhaps, less expected > that a general option like -Wall changes the behaviour of a specific > option like -Wstrict-overflow. This of course also applies to the > optimization options: -fno-tree-vrp -O2 will cause the -fno-tree-vrp > option to be ignored. > > Does anybody have an opinion on whether the current behaviour is good > or bad? The documention suggests that the order of different options > does not matter, so if the current behaviour is good, we should fix > the documentation. I think it's bad; users will not expect that the option order matters, and the typical way that warnings get set up in Makefiles (often as the concatenation of several options variables) would cause problems for users. How about: have -Wall still set warn_strict_overflow to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow -Wall *or* just -Wstrict-overflow set it to 2? The only change would be to prevent -Wall from *decreasing* the value.
Re: Option ordering
Joe Buck <[EMAIL PROTECTED]> writes:
> How about: have -Wall still set warn_strict_overflow
> to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow -Wall
> *or* just -Wstrict-overflow set it to 2? The only change would be
> to prevent -Wall from *decreasing* the value.
Sure, makes sense.
But, consider:
case OPT_Wall:
...
warn_char_subscripts = value;
warn_missing_braces = value;
warn_parentheses = value;
warn_return_type = value;
warn_sequence_point = value; /* Was C only. */
...
warn_switch = value;
...
warn_address = value;
warn_strict_overflow = value;
or
if (optimize >= 2)
{
flag_thread_jumps = 1;
flag_crossjumping = 1;
flag_optimize_sibling_calls = 1;
flag_forward_propagate = 1;
flag_cse_follow_jumps = 1;
flag_gcse = 1;
flag_expensive_optimizations = 1;
flag_ipa_type_escape = 1;
flag_rerun_cse_after_loop = 1;
flag_caller_saves = 1;
flag_peephole2 = 1;
...
If we want to fix this issue, it seems to me we should fix it
everywhere.
Ian
Re: POINTER_PLUS branch status?
On Tue, 2007-05-29 at 16:13 -0700, Andrew Pinski wrote: > On 5/29/07, Jeffrey Law <[EMAIL PROTECTED]> wrote: > > I haven't followed PTR_PLUS development at all -- what specifically > > spurred you to hack on this Andrew? > > Since we lose a > lot of alignment in 4.0 after > http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00020.html Ah. OK. There were easier things you could have done rather than make PTR_PLUS work. Obviously I'm happy that you've taken the harder path as it's clearly more correct than some of the other hacks that could have been done. > Which actually mention you were working on this before (but it looks > it was dropped by you). Correct. It was going to be a mess and other things became a priority. > > The next step is to see if that patch is no longer needed for hppa > (well and fixing the hppa back-end). I would expect you can kill that patch; I don't think you can "fix" the PA backend because RTL passes can muck this stuff up pretty badly (even if you have a solid definition of what REG_POINTER really means -- see the archives from the late 1990s and early 2000s) *If* you're going to twiddle the PA backend, then I would strongly suggest some checking code to verify that REG_POINTER is never set on both register operands in a reg+reg or reg + scale * index address. One of the things you might also want to look at is RTL propagation of REG_POINTER -- I'm pretty sure it's not all that good and with the lowering and mucking addresses that happens in RTL I'd be surprised if we're not missing any registers that can/should be marked with REG_POINTER. Jeff
Re: POINTER_PLUS branch status?
On 5/30/07, Jeffrey Law <[EMAIL PROTECTED]> wrote: On Tue, 2007-05-29 at 16:13 -0700, Andrew Pinski wrote: > The next step is to see if that patch is no longer needed for hppa > (well and fixing the hppa back-end). I would expect you can kill that patch; I don't think you can "fix" the PA backend because RTL passes can muck this stuff up pretty badly (even if you have a solid definition of what REG_POINTER really means -- see the archives from the late 1990s and early 2000s) What I had meant by fixing the PA back-end was for Pointer Plus. Changes are needed in reloc_needed and hppa_gimplify_va_arg_expr and not fixing the use of REG_POINTER :) Sorry if I was not clear there. Thanks, Andrew Pinski
Re: Option ordering
On 30 May 2007 16:12:12 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: Joe Buck <[EMAIL PROTECTED]> writes: > How about: have -Wall still set warn_strict_overflow > to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow -Wall > *or* just -Wstrict-overflow set it to 2? The only change would be > to prevent -Wall from *decreasing* the value. Sure, makes sense. But, consider: [snip] If we want to fix this issue, it seems to me we should fix it everywhere. I was going to submit a formal proposal about options handling (with patches). Since this was raised before I had time to think it through properly, it may have some flaws. Two kinds of options: group options (-Wall, -Wextra, -O1, -O2) and simple options (-fpeephole, -Waddress, -Wstrict-overflow). * Group options can only affect default values of simple options. So a group option will not change the settings of a explicit simple option no matter their order in the command-line. So, "-Wno-address -Wall" == "-Wall -Wno-address" * Options are evaluated according to their order in the command-line. So, "-Wno-address -Waddress" will turn on -Waddress, while "-Waddress -Wno-address" will turn it off. Both rules combined mean that you can do: "-Wall -Wno-all" disabling "-Wall" warnings. However, if you do "-Waddress -Wall -Wno-all", you still get -Waddress. You will need an explicit -Wno-address to disable it. I think this corresponds to the principle of least surprise. Bad idea? Manuel.
Re: Option ordering
On 5/30/07 7:07 PM, Joe Buck wrote: > How about: have -Wall still set warn_strict_overflow > to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow -Wall > *or* just -Wstrict-overflow set it to 2? The only change would be > to prevent -Wall from *decreasing* the value. Yes. My idea was along similar lines. Given an umbrella option like -Wall or -Ox, it should only set specific options iff those options are not present in the command line. That means that we have to have presence bits for each option.
