On 10/07/10 21:24:18, Ian Lance Taylor wrote:
> -Warray-bounds, but that is one of the warnings which is unfortunately
> only available when optimizing. In this case it requires -O2.
Ian, thanks. I had thought optimization might be involved, but didn't try -O2.
> There was an attempt a couple o
On 10/03/10 12:03:44, Ian Lance Taylor wrote:
> You will need to try a sample implementation and see how much the
> compiler slows down and how much bigger it gets.
I began roughing out the required changes. This will be a background
project. If I can finish it to the point of running some timin
On Thu, Sep 23, 2010 at 9:53 AM, NightStrike wrote:
> On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn wrote:
>> On 21/09/2010 02:51, NightStrike wrote:
>>
>>> The toolchain is broken once again here:
>>>
>>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
>>> -I../../../build/mingw/mingw-w64-crt
>>> -m32
On 8 October 2010 16:56, NightStrike wrote:
>
> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
There are a lot of failures there, including quite a few tests which
don't look platform-dependent.
Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see
what's failing? A
2010/10/8 Jonathan Wakely :
> On 8 October 2010 16:56, NightStrike wrote:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
>
> There are a lot of failures there, including quite a few tests which
> don't look platform-dependent.
>
> Can you send me the libstdc++-v3/testsuite/libstd
On Fri, 8 Oct 2010 08:14:23 -0700
Gary Funck wrote:
> On 10/07/10 21:24:18, Ian Lance Taylor wrote:
> > -Warray-bounds, but that is one of the warnings which is unfortunately
> > only available when optimizing. In this case it requires -O2.
>
> Ian, thanks. I had thought optimization might be
On 10/08/10 18:38:29, Basile Starynkevitch wrote:
> I am not an expert on these optimizations, but why would you want that?
I routinely compile/build with "-O0 -g3" because the code is easier to debug. I
also admit that I compile/build with "-O0" because it is faster than
"-O2" or "-O3" for exam
On Fri, Oct 8, 2010 at 12:06 PM, Jonathan Wakely wrote:
> On 8 October 2010 16:56, NightStrike wrote:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
>
> There are a lot of failures there, including quite a few tests which
> don't look platform-dependent.
>
> Can you send me the
Gary Funck writes:
>> There was an attempt a couple of years ago to implement this warning
>> when not optimizing [...].
>
> Would it be possible to compute enough of the control flow graph
> to process warnings like this one, without running the
> actual optimizations, unless those optimizations
On Fri, 8 Oct 2010 09:54:07 -0700
Gary Funck wrote:
> On 10/08/10 18:38:29, Basile Starynkevitch wrote:
> > I am not an expert on these optimizations, but why would you want that?
>
> I routinely compile/build with "-O0 -g3" because the code is easier to debug.
> I
> also admit that I compile
Basile Starynkevitch writes:
> Howeer, I see a logic in needing -O2 to get some warnings.
> Optimizations are expensive, and they compute static properties of the
> source code, which are usable (& necessary and used) for additional
> warnings.
The problem that I think we've discovered over the
Most of the failing libstdc++ tests which shouldn't be
platform-dependent fail with this message:
sh: /usr/bin/stty: Bad address
libstdc++-v3/config/os/mingw32/error_constants.h is missing several
entries, causing failures in the 19_diagnostics tests.
There are a few failures in 23_containers/vec
On Fri, Oct 8, 2010 at 2:04 PM, Jonathan Wakely wrote:
> Most of the failing libstdc++ tests which shouldn't be
> platform-dependent fail with this message:
> sh: /usr/bin/stty: Bad address
This Bad address stuff is due to some conflict with cygwin. We really
need to work with cygwin folks to fi
On Fri, 08 Oct 2010 11:03:27 -0700
Ian Lance Taylor wrote:
> Basile Starynkevitch writes:
>
> > Howeer, I see a logic in needing -O2 to get some warnings.
> > Optimizations are expensive, and they compute static properties of the
> > source code, which are usable (& necessary and used) for addi
How about the following:
1) Default warnings are cheap, and work fine at -O0.
2) Expensive warnings (-Wall, -Warray-bounds, -Wuninitialized, -Wunused)
[not sure about the actual list] that require optimizations, will issue
a Warning when they are requested, but the appropriate optimization level
Gary Funck writes:
> 2) Expensive warnings (-Wall, -Warray-bounds, -Wuninitialized, -Wunused)
> [not sure about the actual list] that require optimizations, will issue
> a Warning when they are requested, but the appropriate optimization level
> has not been asserted, that is required for those w
On 10/08/10 13:22:46, Ian Lance Taylor wrote:
> I think both of those alternatives would be surprising and easily
> misunderstood behaviour for many compiler users. [...]
I find the following behavior to be surprising:
$ gcc -Warray-bounds -O0 -c t.c
$ gcc -Warray-bounds -O1 -c t.c
$ gcc -Warra
> The impact is that I may think that after I build my project at
> -O0 or -O1, with various warnings enabled, that there are
> potential surprises that await, when I perform a production build
> at -O2 and higher.
-Warray-bounds warnings can also be triggered only when using the aggressive
inlin
On Fri, 8 Oct 2010, NightStrike wrote:
> On Thu, Sep 23, 2010 at 9:53 AM, NightStrike wrote:
> > On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn
> > wrote:
> >> On 21/09/2010 02:51, NightStrike wrote:
> >>
> >>> The toolchain is broken once again here:
> >>>
> >>> x86_64-w64-mingw32-gcc -DHAVE_CONFI
On Fri, Oct 8, 2010 at 5:09 PM, Richard Guenther wrote:
> Please also post results for the 4.5 branch. I think it doesn't make
> any sense to include a target in the list of primary or secondary
> targets if it didn't work reasonably for at least one release.
>
> Thanks,
> Richard.
Ok. Does th
Gary Funck writes:
> On 10/08/10 13:22:46, Ian Lance Taylor wrote:
>> I think both of those alternatives would be surprising and easily
>> misunderstood behaviour for many compiler users. [...]
>
> I find the following behavior to be surprising:
>
> $ gcc -Warray-bounds -O0 -c t.c
> $ gcc -Warra
> Would it be possible to compute enough of the control flow graph
> to process warnings like this one, without running the
> actual optimizations, unless those optimizations are requested?
> Would the cost be too high?
It is possible to do it quite fast. Clang implements all warnings,
including W
On Fri, 8 Oct 2010, NightStrike wrote:
> On Fri, Oct 8, 2010 at 5:09 PM, Richard Guenther wrote:
>
> > Please also post results for the 4.5 branch. I think it doesn't make
> > any sense to include a target in the list of primary or secondary
> > targets if it didn't work reasonably for at least
On 08/10/2010 21:39, Gary Funck wrote:
> The impact is that I may think that after I build my project at
> -O0 or -O1, with various warnings enabled, that there are
> potential surprises that await, when I perform a production build
> at -O2 and higher.
The moral of the story is that you should
On 08/10/2010 19:10, NightStrike wrote:
> On Fri, Oct 8, 2010 at 2:04 PM, Jonathan Wakely wrote:
>> Most of the failing libstdc++ tests which shouldn't be
>> platform-dependent fail with this message:
>> sh: /usr/bin/stty: Bad address
>
> This Bad address stuff is due to some conflict with cygwin
On Oct 8, 2010, at 18:18, Manuel López-Ibáñez wrote:
> It is possible to do it quite fast. Clang implements all warnings,
> including Wuninitialized, in the FE using fast analysis and they claim
> very low false positives.
> However, there are various reasons why it has not been attempted in GCC:
26 matches
Mail list logo
