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 wa
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 cha
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
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/m
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 sen
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 -Wstri
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 tha
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
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.
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 vis
Andreas Schwab wrote:
> 1 && 0 is still 0.
>
> Andreas.
Oops my bad. Didn't think (long enough) before posting ;-)
Lothar
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
"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 n
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
>>>
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
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
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) warni
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]: *
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
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
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 '
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)
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
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
24 matches
Mail list logo
