Re: basic VRP min/max range overflow question
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 silence them, > especially when people use -Werror. How can I do this? > Please avoid passing 0 to > warning() for new warnings; especially if there's no other way to > control them. I have just mimicked one of the other uses of warning without paying much attention to the parameters (that are by the way not documented). /* A warning. Use this for code which is correct according to the relevant language specification but is likely to be buggy anyway. */ void warning (int opt, const char *gmsgid, ...)
Re: RFC: improving estimate_num_insns
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 estimate_num_insns was
> called. I still don't see anything in opts.c -- can you give me a
> little more of a hint?
From opts.c:decode_options()
if (optimize_size)
{
/* Inlining of very small functions usually reduces total size. */
set_param_value ("max-inline-insns-single", 5);
set_param_value ("max-inline-insns-auto", 5);
flag_inline_functions = 1;
(...)
}
You didn't update those two.
Gr.
Steven
Re: RFC: improving estimate_num_insns
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 elsewhere.
> >
> > Hmmm - I looked for all of the places where estimate_num_insns was
> > called. I still don't see anything in opts.c -- can you give me a
> > little more of a hint?
>
> From opts.c:decode_options()
>
> if (optimize_size)
> {
> /* Inlining of very small functions usually reduces total size. */
> set_param_value ("max-inline-insns-single", 5);
> set_param_value ("max-inline-insns-auto", 5);
> flag_inline_functions = 1;
>
> (...)
> }
>
> You didn't update those two.
Note that I'd rather change these to set the inline-unit-growth to zero
for -Os. I even have a patch for this laying around. Though it will
no longer apply :)
Also rather than making estimate_num_insns target dependent, we should
maybe conditionalize the results on whether we are optimizing for size
(which is what I think the current metric should do) or for speed (where we
really should drop the costs for all the real multiplication/division stuff).
An important invariant is, that we do not grow the size of a forwarder
function like int foo(int i) { return i; } int bar(int i) { return
foo(i); } whether
foo is inlined or not. I don't remember if I added testcases to verify this
in the last round of adjustments.
Finally, CSiBE is your friend for all size checks, certain C++ testcases
from PRs, like Geralds testcase, for compile-time (and runtime, if available).
And of course compiling gcc itself. Remember, it's hard work to get overall
improvements, especially if you consider embedded targets (I didn't ;)).
Richard.
optimize_size
Description: Binary data
.rodata gcc 3.3.3 gcc 2.95.2
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 I build the library from different object I have char array not align. It is possible to remove at compilation time? Regards Michael
Re: more on duplicate decls
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++; they are an aspect of particular declarations of the function. The problem we're having is that we associate them with the FUNCTION_DECL, rather than with the bindings (mappings from names to FUNCTION_DECLs). Unfortunately, fixing that properly is a rather large change. It seems like a better way is to build a table of merges that need to be done and find some place after the c++ front end is finished but before the cgraph gets built and do one scan of the code and replace all of the offending decls. After the C++ front end is done, it would be OK to canoanicalize all FUNCTION_DECLs with a single UID into one. A stupid way of doing that would be to just walk the entire translation unit, and whenever you find a reference to a non-canonical copy of the FUNCTION_DECL, re-point it at the right one. The C++ front end always operates in unit-at-a-time mode, so, yes, you could do this when the C++ front end is finished. 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? Should I fix it this simple way or should I let a c++ front end person fix it as the decls are created? kenny
Re: Pointers in comparison expressions
> 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 through a printf- type function using "%p" and strcmp the results. That'll give you some kind of ordering, though not necessarily the obvious one. (No, I am not serously suggesting that anyone in their right mind you actually do so. Why does this keyboard have a smiley key?) Note, btw., that such use of %p also rules out using a garbage collector for C and C++. It simply cannot work if some of your pointers have been sent off by email to the other end of the world. At the very least you would have to consider any pointer that made it through %p to be live forever. Morten
Re: attribute initialized
> 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 uninitialized variables in your program. For the
> > kind of access checking you seem to be asking for, you'll need
> > something like valgrind or mudflap.
> >
> >> int foo(int const *p)
> >> {
> >>static int sum = 0;
> >>
> >>sum += *p;
> >>return sum;
> >> }
> >
> > it happens that the memory that p points to is unitialized, but
> > that is not what -Wuninitialized does. Similarly, in
> >
> >> int main(int argc, char **argv)
> >> {
> >>int k;
> >>
> >>return printf("%d\n", foo(&k));
> >> }
> >
> > there are no uninitialized variables, as the address of k is
> > perfectly well defined.
>
> Indeed so, but I think Sylvester's point is that given that foo takes a
> const pointer, the compiler could theoretically know that foo cannot
> legitimately make any use of (dereference) the pointer value being passed
> and could perhaps issue a warning.
My inital point was a function which gets parameters as pointers
and this pointers have to point to something initalized.
Passing the values gives me the expected warning.
However it's more efficent to refer big data structures
to a function with a pointer.
Now i was looking for a posibility to clearify this the compiler.
I didn't find an adequate attribute.
The use of const was a trial to issue a warning.
I favored an attribute.
cheers,
Sylvester
>
> Myself, I was surprised that the inliner didn't catch on to what was going
> on and complain. I would have expected that, but it didn't even at O3.
>
> cheers,
> DaveK
Re: Error building 4.0.1: input.h: No such file...
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-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild -I/d/developer/src/gcc-4.0.1/gcc -I/d/developer/src/gcc-4.0.1/gcc/build -I/d/developer/src/gcc-4.0.1/gcc/../include -I/d/developer/src/gcc-4.0.1/gcc/../libcpp/include -I/usr/local/gmp-4.1.4/include \ -o build/gengtype-yacc.o /d/developer/src/gcc-4.0.1/gcc/gengtype-yacc.c gcc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition-DHAVE_CONFIG_H -DGENERATOR_FILE -s -o build/gengtype.exe \ build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o \ build/errors.o ../build-i686-pc-mingw32/libiberty/libiberty.a build/gengtype.exe /d/developer/src/gcc-4.0.1/gcc/input.h: No such file or directory make[2]: *** [s-gtype] Error 1 make[2]: Leaving directory `/d/developer/projects/chinook_lib/gcc/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/d/developer/projects/chinook_lib/gcc/build/gcc' make: *** [bootstrap] Error 2 -- The file exists in that location so I'm not sure what to do with this. I'm building on winxp pro, GCC 3.4.1 using Msys. Config line: -- ../gcc-4.0.1/configure \ --prefix=/mingw \ --with-gcc \ --with-gnu-ld \ --with-gnu-as \ --enable-threads \ --disable-shared \ --disable-nls \ --enable-languages=c,c++,f95 \ --disable-win32-registry \ --with-gmp=/usr/local/gmp-4.1.4 Make cmd: -- make \ CFLAGS="-O2 -march=i686 -fomit-frame-pointer" \ CXXFLAGS="-mthreads -O2 -march=i686 -fomit-frame-pointer" \ LIBCFLAGS="-O2" \ LIBCXXFLAGS="-O2 -fno-implicit-templates" \ LDFLAGS="-s" \ bootstrap this patch should sort you out Index: gcc/c-incpath.c === RCS file: /cvs/gcc/gcc/gcc/c-incpath.c,v retrieving revision 1.21 diff -c -3 -p -r1.21 c-incpath.c *** gcc/c-incpath.c23 Jan 2005 15:05:27 -1.21 --- gcc/c-incpath.c23 Feb 2005 19:39:49 - *** add_path (char *path, int chain, int cxx *** 331,343 cpp_dir *p; #if defined (HAVE_DOS_BASED_FILE_SYSTEM) ! /* Convert all backslashes to slashes. The native CRT stat() ! function does not recognize a directory that ends in a backslash ! (unless it is a drive root dir, such "c:\"). Forward slashes, ! trailing or otherwise, cause no problems for stat(). */ ! char* c; ! for (c = path; *c; c++) ! if (*c == '\\') *c = '/'; #endif p = xmalloc (sizeof (cpp_dir)); --- 331,348 cpp_dir *p; #if defined (HAVE_DOS_BASED_FILE_SYSTEM) ! /* Remove unnecessary trailing slashes. On some versions of MS ! Windows, trailing _forward_ slashes cause no problems for stat(). ! On newer versions, stat() does not recognise a directory that ends ! in a '\\' or '/', unless it is a drive root dir, such as "c:/", ! where it is obligatory. */ ! int pathlen = strlen (path); ! char* end = path + pathlen - 1; ! /* Preserve the lead '/' or lead "c:/". */ ! char* start = path + (pathlen > 2 && path[1] == ':' ? 3 : 1); ! ! for (; end > start && IS_DIR_SEPARATOR (*end); end--) ! *end = 0; #endif p = xmalloc (sizeof (cpp_dir)); I applied this patch last night and the same error still ocurrs. Any other hints? Thank you Chris
Re: basic VRP min/max range overflow question
> > 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 of the other uses of warning without paying > much attention to the parameters (that are by the way not documented). Yeah, that's why I had my procmail flag these for me. I've just been mentioning it when I thought it made sense to.
isinf
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 model: posix gcc version 4.0.2 20050707 (prerelease) % gcc a.c % gcc b.c Undefined first referenced symbol in file isinf /tmp/ccSOxuGb.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status a.c Description: Binary data b.c Description: Binary data -- Hiroshi Fujishima
Re: Reducing debug info for C++ ctors/dtors
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 destructors a class has defined -- for a large savings in debug info (this can be over 20% of an application's debug info when lots of templates are in heavy use). Because the FUN stabs are still present, gdb knows about the constructors; it can step into them, it can set breakpoints on them. For most developers, this isn't a worthwhile tradeoff, but for a certain class of appliations the stabs debug info is enormous and this helps to ameloriate that by giving up a small bit of gdb functionality. This won't be enabled by default even within Apple, but it is a useful option to have available. Thanks for the explanation. That makes more sense. 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 considered good idea for FSF GCC then I'd like to iron out small details (e.g. name of switch, stabs specific or general for all dbg format etc..), in the beginning. Thanks, - Devang
Re: Reducing debug info for C++ ctors/dtors
> 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 considered good idea for FSF GCC then I'd like to iron out > small details (e.g. name of switch, stabs specific or general for > all dbg format etc..), in the beginning. I think it's useful, probably in the same vein as the -feliminate-dwarf-dup etc switches. Probably should use the same type of naming convention too. -eric
Re: more on duplicate decls
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++ frontend. When the trees enter the middle-end, the FUNCTION_DECLs do not need the default arguments, the CALL_EXPR are filled correctly, and the programmer errors have been already reported. > Should I fix it this simple way or should I let a c++ front end person > fix it as the decls are created? I believe the simple way is faster for you to continue with you work. The proper fix does not look easy at all. -- Giovanni Bajo
Re: isinf
> 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 eliminated at -O1. -- Eric Botcazou
Re: Reducing debug info for C++ ctors/dtors
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 from being 10x slower to being 7.5x slower than the competition, this improve turn-around time when doing edit->compile- >debug... This is not just a 1% savings, this is a 25% savings. Would be nice if someone could approve it.
Re: Reducing debug info for C++ ctors/dtors
> 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
Re: Some tests in gcc.c-torture rely on undefined behaviour?
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 integer to f(), which
then increments it, causing signed overflow, the result of which is
undefined. The test passes if signed overflow wraps.
930529-1.c is similar -- again the maximum positive integer is incremented.
i think it is fine 2 have these tests. ant gcc version failing them is
suspicious
Bugzilla
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 mysql table index files to break again :( I'm trying some of the more "powerful" recovery options, and if that doesn't work, i'll simply mysqldump the tables and reload them completely.
Re: Reducing debug info for C++ ctors/dtors
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?
Re: Homepage: Update of page "Releases"
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.0.1 and future > releases." The current wording is intentional: we decided not to have that many redundant instances of information on releases, so indeed GCC 4.0.0 and later will not be listed on releases.html. Gerald
Re: Pointers in comparison expressions
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 extension, maybe even miss some optimization because of it, > when there's a perfectly fine alternative to it for the user. Having the user add stupid, potentially breakable casts which decrease readability just because the standard says the compiler is allowed to be a prick is not necessarily a good idea. I don't really see the point of breaking or even warning on pretty much every memory management or garbage collection code out there. OG.
Re: Reducing debug info for C++ ctors/dtors
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 markers, which, is obvious. Anything else? > If not, Ok with that change? I can't approve it for sure. Comments would be useful, as well as standardizing on an option name to turn it on. The -feliminate-stabs- was what I suggested. -eric
Re: isinf
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
> a little questionable though. The gap is eliminated at -O1.
Thank you for explication. Is it gcc's expected behavior?
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;
}
If above compilation is success, the configure script defines
HAVE_ISINF macro. The prior version to gcc-4.0.0 above compilation
fails, so below isinf macro is defined. But gcc-4.0.0 or later it
succeeds, so below isinf macro is not defind though the system doesn't
have isinf().
/* Solaris */
#if (! defined(HAVE_ISINF) && defined(HAVE_FPCLASS))
# define HAVE_ISINF 1
# define isinf(a) (fpclass(a) == FP_NINF || fpclass(a) == FP_PINF)
#endif
Is this gcc's problem? Or should I contact rrdtool's developer?
Regards.
[1] http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/>
--
Hiroshi Fujishima
Re: isinf
> > 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 to eliminate calls to pure functions whose return value is not
used, as they have no "external" effects. GCC 3.x doesn't do it at -O0,
whereas 4.x does.
> 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 value of isinf to a
variable should be sufficient for 4.0.x at -O0.
--
Eric Botcazou
Re: isinf
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 value of isinf to a
> variable should be sufficient for 4.0.x at -O0.
Yes, I contact rrdtool maintainer. Thank you.
--
Hiroshi Fujishima
Re: isinf
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(f)
> >> ;
> >> return 0;
> >> }
> >
> > The test is clearly fragile. Assigning the return value of isinf to a
> > variable should be sufficient for 4.0.x at -O0.
>
> Yes, I contact rrdtool maintainer. Thank you.
Best to make it a global variable, to guard against dead code elimination.
Re: 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; isinf(f)
;
return 0;
}
The test is clearly fragile. Assigning the return value of isinf to
a
variable should be sufficient for 4.0.x at -O0.
Yes, I contact rrdtool maintainer. Thank you.
Best to make it a global variable, to guard against dead code
elimination.
Volatile would be even better. It's valid to eliminate stores into
globals
if you can determine the value isn't used thereafter, which we can here,
at least theoretically.
Re: isinf
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 clearly fragile. Assigning the return value of isinf to a
>> > variable should be sufficient for 4.0.x at -O0.
>
> Best to make it a global variable, to guard against dead code elimination.
Oops, the configure script compiling with -O2 optimization. The
compilation of the following code still suceesss.
#include
int a;
int
main ()
{
float f = 0.0;
a = isinf (f);
return 0;
}
Do I misunderstand? Since I am the newbie of C, I consulted this page:
http://www.phim.unibe.ch/comp_doc/c_manual/C/SYNTAX/glo_int_vars.html
--
Hiroshi Fujishima
RE: Where does the C standard describe overflow of signed integers?
> " ... 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 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 signed integer arithmetic operations; that by extension unsigned and signed integer arithmetic operations are behaviorally equivalent all current machine implementations (as well as likely future implementations for the same reasons); therefore seemingly irrational and counter productive to presume otherwise, regardless of the standard's presently relatively ambiguous position on the subject for apparently largely historical reasons. As optimization seems to be a non-argument, as by analogy all optimizations which are available for unsigned arithmetic are correspondingly available for signed integer operations; as any signed value may then be thought of as being unsigned for the purposes of computation and/or comparison. i.e.: signed: 0 .. INT_MAX INT_MIN ..-10 ... unsigned: 0 ..UINT_MAX/2.. UINT_MAX 0 ...
[toplevel] Update COPYING.LIB from FSF
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 from fsf.org. Index: COPYING.LIB === RCS file: /cvs/gcc/gcc/COPYING.LIB,v retrieving revision 1.4 diff -p -u -d -u -r1.4 COPYING.LIB --- COPYING.LIB 29 Jan 2001 13:30:01 - 1.4 +++ COPYING.LIB 14 Jul 2005 01:36:40 - @@ -1,8 +1,9 @@ - GNU LESSER GENERAL PUBLIC LICENSE - Version 2.1, February 1999 + + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. @@ -10,7 +11,7 @@ as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] - Preamble +Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public @@ -22,7 +23,8 @@ specially designated software packages-- Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better -strategy to use in any particular case, based on the explanations below. +strategy to use in any particular case, based on the explanations +below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that @@ -87,9 +89,9 @@ libraries. However, the Lesser license special circumstances. For example, on rare occasions, there may be a special need to -encourage the widest possible use of a certain library, so that it becomes -a de-facto standard. To achieve this, non-free programs must be -allowed to use the library. A more frequent case is that a free +encourage the widest possible use of a certain library, so that it +becomes a de-facto standard. To achieve this, non-free programs must +be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. @@ -112,7 +114,7 @@ modification follow. Pay close attentio former contains code derived from the library, whereas the latter must be combined with the library in order to run. - GNU LESSER GENERAL PUBLIC LICENSE + GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other @@ -136,8 +138,8 @@ included without limitation in the term "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated -interface definition files, plus the scripts used to control compilation -and installation of the library. +interface definition files, plus the scripts used to control +compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of @@ -146,7 +148,7 @@ such a program is covered only if its co on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. - + 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an @@ -303,10 +305,10 @@ of these things: the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. -c) Accompany the work with a written offer, valid for at -least three years, to give the same user the materials -specified in Subsection 6a, above, for a charge no more -than the cost of performing this distribution. +c) Accompany the work with a written offer, valid for at least +three years, to give the same user the materials specified in +Subsection 6a, above, for a charge no more than the cost of +performing this distribution. d) If distribution of the work is made by offering
Re: [toplevel] Update COPYING.LIB from FSF
> 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 ;-)
Re: Where does the C standard describe overflow of signed integers?
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 signed integer arithmetic operations; that by extension unsigned and signed integer arithmetic operations are behaviorally equivalent all current machine implementations (as well as likely future implementations for the same reasons); nonsense! -1/1 = 0 signed, -1 unsigned -1 < 1 signed, -1>1 unsigned
Re: Where does the C standard describe overflow of signed integers?
> 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 >> to eliminate the otherwise necessity for distinct signed integer arithmetic >> operations; that by extension unsigned and signed integer arithmetic >> operations are behaviorally equivalent all current machine implementations >> (as well as likely future implementations for the same reasons); > > nonsense! -1/1 = 0 signed, -1 unsigned Actually as -1(signed) == UINT_MAX(unsigned) there's no problem, as 1..1/0..1 == 1..1. Although suspect you meant something like 1/-1. However as 2's complement division typically presumes the effective conversion of signed values to their absolute unsigned values (which is the form in which the division typically takes place, which is itself often further decomposed to conditional modulo unsigned subtractions, and then sign corrected afterward), I don't view this as a discrepancy; but do agree signed division is typically a distinct operation, which wraps sign correction around a fundamentally unsigned division operation; which itself tends to rely on modulo unsigned subtraction at it's core. > -1 < 1 signed, -1>1 unsigned Agreed, however as above, comparison operations are essentially composed of an unsigned modulo subtraction, who's result's high order virtual sign bit determines the logical result of the operation as a function of the xor of it's operand's virtual sign bits. So essentially again just an wrapper over an unsigned modulo subtraction operation. 1..1 - 0..1 == 1..0 => true (signed), false (unsigned) So overall, it seems pretty clear that even these two arguable exceptions actually themselves tend to rely on modulo unsigned arithmetic at their core in all typical implementations of these signed operations.
Re: isinf
> 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 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;
}
or additionally compile with -fno-builtin.
--
Eric Botcazou
gcc-4.1-20050702: ICE in force_decl_die, at dwarf2out.c:12618
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 happens with the next snapshot, I'll submit a bug (unless someone tells me not to bother). - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
gcc-4.1-20050702: ICE
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). - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: isinf
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 break in the future. This
will not work (possibly) years from now when gcc will start
doing VRP on math functions like isinf.
MIN_INT <= argc <= MAX_INT falls well into representable
values of double (assuming 32 bit int or less). This means
that the compiler may deduce that isinf((double)argc) always
returns false, without ever calling the function.
>
> or additionally compile with -fno-builtin.
That may help.
