DJ Delorie wrote:
>
> > Then, you will like the following kind of patches:
> >
> > + warning (0, "%H undefined behavior if loop runs for more than %qE
> > iterations",
> > + find_loop_location (loop), estimation);
>
> I think we would like them better if you could choose to silenc
On Wednesday 13 July 2005 04:29, Josh Conner wrote:
> > Finally, you've apparently used grep to find all the places where
> > PARAM_MAX_INLINE_INSNS_SINGLE and its friends are used, but you hve
> > missed the ones in opts.c and maybe elsewhere.
>
> Hmmm - I looked for all of the places where estima
On 7/13/05, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Wednesday 13 July 2005 04:29, Josh Conner wrote:
> > > Finally, you've apparently used grep to find all the places where
> > > PARAM_MAX_INLINE_INSNS_SINGLE and its friends are used, but you hve
> > > missed the ones in opts.c and maybe el
Hi all,
I have different assembler code and I notice that the gcc 3.3.3 add this
information in the asm code:
.section.rodata.str1.4,"aMS",%progbits,1
align 2
.LC0:
.ascii "filename\000"
Generated by gcc 2.95.2 19991024 (release) for ARM/elf
doesn't have this section
So when
Mark Mitchell wrote:
Kenneth Zadeck wrote:
The kludge to handle them is documented in cp/name-lookup.c around
line 670
Ugh.
IMO, the right thing here is that there should be only one
FUNCTION_DECL for a given function, ever, period. Default arguments
are not part of "the function" in C+
> Relational tests between pointers is only allowed by
> the ISO C standard if the two pointers point into the
> same array, or if a pointer points to exactly one byte
> beyond the array.
There actually is a way to compare arbitrary data pointers
within the C standards: you send the pointers throu
> Original Message
> >From: Joe Buck
> >Sent: 11 July 2005 20:07
>
> > On Mon, Jul 11, 2005 at 08:07:20PM +0200, Sylvester Diehl wrote:
> >> why doesn't gcc (-Wall -Wuninitalized -O) detect
> >> an uninialized variable passed by reference
> >> decleared as const * ?
> >
> > There are no
Dave Murphy wrote:
Chris Garrett wrote:
I built 4.0.0 last week and thought I would update to 4.0.1. While
building 401 I got the following error:
--
gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W
-Wall -Wwrite-st
> > I think we would like them better if you could choose to silence them,
> > especially when people use -Werror.
>
> How can I do this?
Create a -W* command line option for it. Pass the corresponding OPT_*
to warning(). Theen the -W option controls that warning.
> I have just mimicked one
Hi,
Why does the compilation of b.c fail, while that of a.c succeeds with
gcc-4.0.0 or later? Compilaton with gcc-3.4.4 both failed.
% gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: ../gcc/configure --disable-nls --with-gmp=/usr/local
--with-mpfr=/usr/local
Thread mo
On Jul 11, 2005, at 6:18 PM, Daniel Jacobowitz wrote:
On Mon, Jul 11, 2005 at 06:11:58PM -0700, Jason Molenda wrote:
Yeah, Devang didn't present what we're doing here on the debug side
too well. We're giving up a bit of information from within gdb --
it won't know what constructors and destr
> What do others think about this patch? If people think, it is OK
> to have one additional knob for users then I'll test and submit
> formal patch.
>
> I'll treat silence as, this idea is not OK for FSF GCC. I'd like to
> give Jason and our customers compiler with such fix ASAP. And if
> it is c
Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> Are you saying that if I wait til the front end is finished that I do
> not have to worry about the default args problem you mention above?
Yes. The middle-end does not know anything about default arguments: they are
used only internally by the C++ fron
> Why does the compilation of b.c fail, while that of a.c succeeds with
> gcc-4.0.0 or later?
Because the call to isinf is optimized away even at -O0 in the latter case
(isinf being a pure function), but not in the former. That could be deemed
a little questionable though. The gap is eliminate
On Jul 13, 2005, at 11:44 AM, Eric Christopher wrote:
I think it's useful
To put real life numbers on it, for some, it translates into a
savings of around 150 megs worth of debug information, and the time
it takes to compile, assemble and link it. For linking for example,
it can take us
> Would be nice if someone could approve it.
>
It's not in a state that could be approved yet, but hopefully after some
cleanup it will be.
-eric
Nicholas Nethercote wrote:
Hi,
I've been looking at the gcc.c-torture tests, it seems some of them rely
on undefined behaviour. For example, 920612-1.c looks like this:
f(j)int j;{return++j>0;}
main(){if(f((~0U)>>1))abort();exit(0);}
AIUI, this passes the largest possible positive integ
may go up and down the next few hours while i attempt to figure out what
is going on.
It looks like some of the actual data got very out of whack with the
mysql indexes when we ran out of space on sourceware, and while the data
is still fine, every time someone changes a bug, it seems to cause the
On Jul 13, 2005, at 12:39 PM, Eric Christopher wrote:
Would be nice if someone could approve it.
It's not in a state that could be approved yet, but hopefully after
some
cleanup it will be.
Remove the APPLE LOCAL markers, which, is obvious. Anything else?
If not, Ok with that change?
On Tue, 12 Jul 2005, Franz Fritsche wrote:
> The page http://gcc.gnu.org/releases.html should be updated.
> - Entries of recent releases GCC 4.0.0 and GCC 4.0.1 are missing.
>
> In addition the headline of the table should be changed to:
> "Please refer to our development plan for releases past 4.
On Wed, Jul 13, 2005 at 01:28:14AM +0200, Falk Hueffner wrote:
> You're missing my point; size_t was just an example, whoever does this
> will know what the correct type is for their system. All I'm saying
> is that we shouldn't go to the trouble to document and kick along some
> language extensio
On Wed, 2005-07-13 at 14:05 -0700, Mike Stump wrote:
> On Jul 13, 2005, at 12:39 PM, Eric Christopher wrote:
> >> Would be nice if someone could approve it.
> >
> > It's not in a state that could be approved yet, but hopefully after
> > some
> > cleanup it will be.
>
> Remove the APPLE LOCAL mar
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> Why does the compilation of b.c fail, while that of a.c succeeds with
>> gcc-4.0.0 or later?
>
> Because the call to isinf is optimized away even at -O0 in the latter case
> (isinf being a pure function), but not in the former. That could be deemed
>
> > Because the call to isinf is optimized away even at -O0 in the latter
> > case (isinf being a pure function), but not in the former. That could be
> > deemed a little questionable though. The gap is eliminated at -O1.
>
> Thank you for explication. Is it gcc's expected behavior?
It is valid
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> The configure script which is included in rrdtool[1] checks whether
>> the system has isinf() as below.
>>
>> #include
>> int
>> main ()
>> {
>> float f = 0.0; isinf(f)
>> ;
>> return 0;
>> }
>
> The test is clearly fragile. Assigning the return v
On Thu, Jul 14, 2005 at 08:16:07AM +0900, Hiroshi Fujishima wrote:
> Eric Botcazou <[EMAIL PROTECTED]> writes:
>
> >> The configure script which is included in rrdtool[1] checks whether
> >> the system has isinf() as below.
> >>
> >> #include
> >> int
> >> main ()
> >> {
> >> float f = 0.0; isinf
On Jul 13, 2005, at 4:29 PM, Joe Buck wrote:
On Thu, Jul 14, 2005 at 08:16:07AM +0900, Hiroshi Fujishima wrote:
Eric Botcazou <[EMAIL PROTECTED]> writes:
The configure script which is included in rrdtool[1] checks whether
the system has isinf() as below.
#include
int
main ()
{
float f = 0.0;
Joe Buck <[EMAIL PROTECTED]> writes:
>> >> The configure script which is included in rrdtool[1] checks whether
>> >> the system has isinf() as below.
>> >>
>> >> #include
>> >> int
>> >> main ()
>> >> {
>> >> float f = 0.0; isinf(f)
>> >> ;
>> >> return 0;
>> >> }
>> >
>> > The test is clearl
> " ... A computation involving unsigned operands can never overflow, because
> a result that cannot be represented by the resulting unsigned integer type
> is reduced modulo the number that is one greater than the largest value that
> can be represented by the resulting type."
Although I don't i
I committed this as obvious to gcc to get the new FSF address. The rest
are whitespace changes.
The src directory currently is version 2.0 instead of 2.1 for
COPYING.LIB. Should the license file be upgraded on src?
2005-07-14 Kelley Cook <[EMAIL PROTECTED]>
* COPYING.LIB: Update fr
> The src directory currently is version 2.0 instead of 2.1 for
> COPYING.LIB. Should the license file be upgraded on src?
Changing licensing terms is usually a question for the FSF, not the
maintainers.
Plus, you should at least bring this up on the binutils/gdb/newlib
lists ;-)
Paul Schlie wrote:
Although I don't intend to extend the debate; doesn't anyone find it curious
that given this hard requirement, combined with the fact that all current
machine architectures rely on 2's complement signed integer representation
to eliminate the otherwise necessity for distinct s
> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> Although I don't intend to extend the debate; doesn't anyone find it curious
>> that given this hard requirement, combined with the fact that all current
>> machine architectures rely on 2's complement signed integer representation
>
> Oops, the configure script compiling with -O2 optimization.
Clearly not the best option for this kind of tests.
> The compilation of the following code still suceesss.
>
> #include
>
> int a;
>
> int
> main ()
> {
> float f = 0.0;
> a = isinf (f);
> return 0;
> }
The compiler knows the
I'm seeing the following two instances of the same ICE
building a large app with gcc-4.1-20050702 for i686-linux:
bits/stl_list.h:396: internal compiler error: in force_decl_die, at
dwarf2out.c:12618
ext/rope:1469: internal compiler error: in force_decl_die, at dwarf2out.c:12618
If it still hap
I'm seeing the following ICE
building a large app with gcc-4.1-20050702 for i686-linux:
ext/mt_allocator.h:450: internal compiler error: in write_template_arg_literal,
at cp/mangle.c:2228
If it still happens with the next snapshot, I'll
submit a bug (unless someone tells me not to bother).
- Da
Eric Botcazou wrote on 14/07/2005 08:59:53:
> The compiler knows the answer of isinf (0) so it again optimizes away the
> call. Try something like:
>
> int a;
>
> int
> main (int argc, char *argv[])
> {
> a = isinf ((double) argc);
> return 0;
> }
This may work today, but and still br
37 matches
Mail list logo
