Re: signed is undefined and has been since 1992 (in GCC)
In article <[EMAIL PROTECTED]> you write: >Both OpenSSL and Apache programmers did this, in carefully reviewed >code which was written in response to a security report. They simply >didn't know that there is a potential problem. The reason for this >gap in knowledge isn't quite clear to me. Well, it's reasonably clear to me. I've been reviewing code for the OpenBSD project, it's incredible the number of errors you can find in code which is supposed to - have been written by competent programmers; - have been reviewed by tens of people. Quite simply, formal code reviews in free software don't work. The `many eyes' paradigm is a fallacy. Ten persons can look at the same code and fail to notice a problem if they don't look for the right thing. A lot of people don't even think about overflows when they look at arithmetic, there are a lot of integer overflows out there. I still routinely find off-by-one accesses in buffers, some of them quite obvious. The only reasons I see them is because my malloc can put allocations on page boundaries, and thus the program barfs here, and not on other machines. A lot of people don't know about the peculiarities of C signed arithmetic. A lot of `portable' code that uses C arithmetic buries such peculiarities under tons of macros and typedefs such that it is really hard to figure out what's going on even if you understand the issues. >From past experience, both Apache and OpenSSL are very bad in that regards. Bottom-line is, if it passes tests on major architectures and major OSes, it's very unlikely that someone will notice something is amiss, and that the same someone will have the knowledge to fix it. If it passes all practical tests, but is incorrect, from a language point of view, it is even more unlikely.
Re: isinf
> 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.
You're too clever. :-)
union U {
int i;
double d;
};
volatile int a;
int
main (int argc, char *argv[])
{
union U u;
u.i = argc;
a = isinf (u.d);
return 0;
}
--
Eric Botcazou
Re: isinf
Eric Botcazou <[EMAIL PROTECTED]> wrote on 14/07/2005 10:05:50:
[...]
> union U {
> int i;
> double d;
> };
>
> volatile int a;
>
> int
> main (int argc, char *argv[])
> {
> union U u;
> u.i = argc;
> a = isinf (u.d);
> return 0;
> }
>
Doesn't the code display undefined behavior when sizeof(u.i)
profiledbootstrap insn-attrtab.c compile taking forever
As subject says - on x86_64 it takes a whopping 30 minutes to compile said with -fprofile-generate! And of course profiledbootstrap later fails with stage1/xgcc -Bstage1/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -fno-common -DHAVE_CONFIG_H-I. -I. -I/mnt/space/rguenther/src/gcc-clean/gcc -I/mnt/space/rguenther/src/gcc-clean/gcc/. -I/mnt/space/rguenther/src/gcc-clean/gcc/../include -I/mnt/space/rguenther/src/gcc-clean/gcc/../libcpp/include /mnt/space/rguenther/src/gcc-clean/gcc/tree-cfg.c -o tree-cfg.o /mnt/space/rguenther/src/gcc-clean/gcc/tree-cfg.c: In function ‘tree_find_edge_insert_loc’: /mnt/space/rguenther/src/gcc-clean/gcc/tree-cfg.c:2915: error: coverage mismatch for function ‘tree_find_edge_insert_loc’ while reading counter ‘arcs’ /mnt/space/rguenther/src/gcc-clean/gcc/tree-cfg.c:2915: error: number of counters is 39 instead of 41 Richard.
Re: isinf
Michael Veksler <[EMAIL PROTECTED]> writes:
> Maybe there is a simpler way? For example:
>
> volatile int a;
> volatile double b;
> int main ()
> {
>a = isinf (b);
>return 0;
> }
>
> This way the compiler must not assume anything about 'b',
> making it impossible to optimizes the call to isinf.
Why not just use AC_HAVE_FUNCS(isinf)? IIUC this is part of a configure
script, although whether it is autoconf generated is not clear so far.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: isinf
> Why not just use AC_HAVE_FUNCS(isinf)? IIUC this is part of a configure > script, although whether it is autoconf generated is not clear so far. Real men write their configure checks by hand, although whether the rrdtool maintainer is a male is not clear so far. ;-) -- Eric Botcazou
Re: isinf
Andreas Schwab <[EMAIL PROTECTED]> writes: > Why not just use AC_HAVE_FUNCS(isinf)? IIUC this is part of a configure > script, although whether it is autoconf generated is not clear so far. Though I don't know the why, rrdtool-1.2.10/configure.ac has the following macro. dnl HP-UX 11.00 does not have finite but does have isfinite as a macro so we need dnl actual code to check if this works AC_CHECK_FUNCS(fpclassify, , [AC_MSG_CHECKING(for fpclassify with ) AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], [[float f = 0.0; fpclassify(f)]])],[AC_MSG_RESULT(yes) AC_DEFINE(HAVE_FPCLASSIFY)],[AC_MSG_RESULT(no)])]) AC_CHECK_FUNCS(finite, , [AC_CHECK_FUNCS(isfinite, , [AC_MSG_CHECKING(for isfinite with ) AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], [[float f = 0.0; isfinite(f)]])],[AC_MSG_RESULT(yes) AC_DEFINE(HAVE_ISFINITE)],[AC_MSG_RESULT(no)])])]) AC_CHECK_FUNCS(isinf, , [AC_MSG_CHECKING(for isinf with ) AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], [[float f = 0.0; int x = isinf(f)]])],[AC_MSG_RESULT(yes) AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])]) -- Hiroshi Fujishima
Re: isinf
On Thu, Jul 14, 2005 at 06:27:06PM +0900, Hiroshi Fujishima wrote: > Andreas Schwab <[EMAIL PROTECTED]> writes: > > > Why not just use AC_HAVE_FUNCS(isinf)? IIUC this is part of a configure > > script, although whether it is autoconf generated is not clear so far. > > Though I don't know the why, rrdtool-1.2.10/configure.ac has the > following macro. > > dnl HP-UX 11.00 does not have finite but does have isfinite as a macro so we > need > dnl actual code to check if this works > AC_CHECK_FUNCS(fpclassify, , > [AC_MSG_CHECKING(for fpclassify with ) > AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], [[float f = 0.0; > fpclassify(f)]])],[AC_MSG_RESULT(yes) > AC_DEFINE(HAVE_FPCLASSIFY)],[AC_MSG_RESULT(no)])]) > AC_CHECK_FUNCS(finite, , > [AC_CHECK_FUNCS(isfinite, , > [AC_MSG_CHECKING(for isfinite with ) > AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], [[float f = 0.0; > isfinite(f)]])],[AC_MSG_RESULT(yes) > AC_DEFINE(HAVE_ISFINITE)],[AC_MSG_RESULT(no)])])]) > AC_CHECK_FUNCS(isinf, , > [AC_MSG_CHECKING(for isinf with ) > AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], [[float f = 0.0; > int x = isinf(f)]])],[AC_MSG_RESULT(yes) > AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])]) Guess that's because AC_HAVE_FUNCS(isinf) is wrong. isinf/isfinite/fpclassify are all documented as macros in ISO C99. So [AC_MSG_CHECKING(for isinf with ) AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include volatile int x; volatile float f;]], [[x = isinf(f)]])],[AC_MSG_RESULT(yes) AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])]) should be reasonably safe for now. Jakub
Re: isinf
Jakub Jelinek <[EMAIL PROTECTED]> writes: > Guess that's because AC_HAVE_FUNCS(isinf) is wrong. > isinf/isfinite/fpclassify are all documented as macros in ISO C99. > So >[AC_MSG_CHECKING(for isinf with ) > AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include > volatile int x; volatile float f;]], [[x = isinf(f)]])],[AC_MSG_RESULT(yes) >AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])]) > should be reasonably safe for now. Perhaps it should just check whether the macro isinf exists (but still use AC_CHECK_FUNCS(isinf) for pre-C99 hosts). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
addsi3 with set condition register
I'm writing a gcc back-end for a new RISC. This RISC has two kinds of add instructions, one updates condition register and one doesn't. ex. 1.) add <- add comp<- update condition register 2.) add_c <- add & update condition register But case 2 pattern is not used at all. The rtl generated by a sample program with -dr option is (insn 12 11 13 (set (reg:SI 168) (plus:SI (reg/v:SI 166 [ a ]) (reg/v:SI 167 [ b ]))) -1 (nil) (nil)) (insn 13 12 14 (set (reg:CC 33 cr1) (compare:CC (reg:SI 168) (const_int 0 [0x0]))) -1 (nil) (nil)) My pattern is (define_insn "..." [ (set (match_operand:SI 0 "register_operand" "=g") (plus:SI (match_operand:SI 1 "register_operand" "g") (match_operand:SI 2 "register_operand" "g")) ) (set (reg:CC CC_REGNUM) (compare:CC (match_dup 0) (const_int 0)))] Although I can use peephole/peephole2, but I think it's not a good approach? Thank you for your reading :)
Re: profiledbootstrap insn-attrtab.c compile taking forever
On 7/14/05, Richard Guenther <[EMAIL PROTECTED]> wrote: > > As subject says - on x86_64 it takes a whopping 30 minutes to > compile said with -fprofile-generate! It's caused by -frename-registers enabled by -funroll-loops. Compiling with -O2 -fno-unroll-loops -fprofile-generate compared to -O2 -fno-unroll-loops -fprofile-generate -frename-registers takes 14 minutes instead of 31. Please consider not enabling -frename-registers for -fprofile-generate. Thanks, Richard.
successful build of gcc 4.0.1 on i686-pc-cygwin, cohexist with gcc 3.4.1
/gcc/4.0/gcc-4.0.1/config.guess i686-pc-cygwin $ /work/install/bin/gcc -v Using built-in specs. Target: i686-pc-cygwin Configured with: /gcc/4.0/gcc-4.0.1/configure --verbose --prefix=/work/install --exec-prefix=/work/install --sysconfdir=/work/i nstall/etc --libdir=/work/install/lib --libexecdir=/work/install/lib --mandir=/work/install/man --infodir=/work/install/info -- enable-languages=c,c++ --enable-nls --without-included-gettext --with-system-zlib --disable-interpreter --enable-threads=posix --enable-sjlj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry Thread model: posix gcc version 4.0.1 Additional info: OS = WinXP Pro SP2 The cygwin version was 1.5.8. The original gcc release was 3.4.1. The orginal gcc -v output was: $ gcc -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.1/specs Configured with: /gcc/3.4/gcc-3.4.1-1/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,f77,java,objc --enable-nls --without-included-gettext --enable-libgcj --with-system-zlib --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enable-sjlj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry Thread model: posix gcc version 3.4.1 (cygming special) The exact sequence of steps involved in bootstrapping was: bzip2 -d /gcc-4.0.1.tar.bz2 mkdir /gcc mkdir /gcc/4.0 cd /gcc/4.0 tar xvf /gcc-4.0.1.tar mkdir /work mkdir /work/install mkdir /work/install/etc mkdir /work/install/lib mkdir /work/install/man mkdir /work/install/info mkdir /objdir cd /objdir /gcc/4.0/gcc-4.0.1/configure --verbose --prefix=/work/install --exec-prefix=/work/install --sysconfdir=/work/install/etc --libdir=/work/install/lib --libexecdir=/work/install/lib --mandir=/work/install/man --infodir=/work/install/info --enable-languages=c,c++ --enable-nls --without-included-gettext --with-system-zlib --disable-interpreter --enable-threads=posix --enable-sjlj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry make bootstrap make install make html gcc unbzip2ped is 200 MB objdir at the end is 350 MB the process takes about 1 h The original gcc 3.4.1 shipped with cygwin is now available on my system with: gcc -o hello.exe hello.c The 4.0.1 compiler can be invoked with: /work/install/bin/gcc Paolo Greppi http://www.3ip.it
gcc-4.1-20050702: ICE in write_template_arg_literal, at cp/mangle.c:2228
[resending - forgot to finish subject line before] 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
Why is libgnat defaulted to STATIC? (see gcc/ada/link.c)
Greetings: Can someone explain why libgnat is defaulted to STATIC? I would think that SHARED would be the desired default. Does SHARED cause problems when building cross compilers? Scott McConnell
Re: addsi3 with set condition register
> ibanez writes: ibanez> 2.) ibanez> add_c <- add & update condition register ibanez> But case 2 pattern is not used at all. ibanez> (define_insn "..." ibanez> [ (set (match_operand:SI 0 "register_operand" "=g") ibanez> (plus:SI (match_operand:SI 1 "register_operand" "g") ibanez> (match_operand:SI 2 "register_operand" "g")) ) ibanez> (set ibanez> (reg:CC CC_REGNUM) ibanez> (compare:CC (match_dup 0) (const_int 0)))] Try listing the compare first. Also, you might try listing the compare register as a match_operand with a constraint for the CC register instead of hard-coding the register. See rs6000.md add3_internal2 and add3_internal3 patterns for examples. David
gnuplot for mandrake 10.2
I have linux mandrake 10.2 on a PC but I cannot run gnuplot.I fact when I use the command gnuplot to call the program, the response is "not found". Please can someone indicate me where i can download gnuplot for linux?
RE: gnuplot for mandrake 10.2
Original Message >From: Alain Moïse Dikandé >Sent: 14 July 2005 16:17 > I have linux mandrake 10.2 on a PC but I cannot run gnuplot.I fact when I > use the command gnuplot to call the program, the response is "not found". > Please can someone indicate me where i can download gnuplot for linux? Wrong mailing list. We can tell you how to write define_insn patterns here. We don't know about gnuplot. Have you never heard of a thing called 'Google'? cheers, DaveK -- Can't think of a witty .sigline today
Re: gnuplot for mandrake 10.2
Alain Moïse Dikandé wrote: >I have linux mandrake 10.2 on a PC but I cannot run gnuplot.I fact when I use >the command gnuplot to call the program, the response is "not found". Please >can someone indicate me where i can download gnuplot for linux? > > gnuplot is a plotting package; its homepage is at > http://www.gnuplot.info > > It was neither developed by nor named for the GNU project; the name is > a coincidence. Paolo.
Splitting an immediate using define_expand
Hi,
I am trying to separate move immediates that require more than 16 bits
into two instructions that set the high and low 16 bits of a register
respectively. Here is my define_expand:
(define_expand "movsi"
[(set (match_operand:SI 0 "nonimmediate_operand" "")
(match_operand:SI 1 "general_operand" ""))]
""
{
if(GET_CODE(operands[0]) != REG){
operands[1] = force_reg(SImode, operands[1]);
}
else if(CONSTANT_P(operands[1])
&& (-0x8000 > INTVAL(operands[1]) || INTVAL(operands[1]) >
0x7FFF)){
emit_move_insn(gen_rtx_SUBREG(HImode, operands[0], 0),
gen_rtx_TRUNCATE(HImode, operands[1]));
emit_move_insn(gen_rtx_SUBREG(HImode, operands[0], 2),
gen_rtx_TRUNCATE(HImode, gen_rtx_LSHIFTRT(SImode,
operands[1],
16)));
DONE;
}
}
)
and here are the patterns I intend to match:
(define_insn "movsi_subreg0"
[(set (subreg:HI (match_operand:SI 0 "register_operand" "=r") 0)
(truncate:HI (match_operand:SI 1 "immediate_operand" "i")))]
""
"%0.l = #LO(%1)"
)
(define_insn "movsi_subreg1"
[(set (subreg:HI (match_operand:SI 0 "register_operand" "=r") 2)
(truncate:HI (lshiftrt:SI (match_operand:SI 1
"immediate_operand" "i")
(const_int 16]
""
"%0.h = #HI(%1)"
)
When I try to build, the cross compiler gives the following error:
./crtstuff.c: In function `__do_global_dtors_aux':
./crtstuff.c:261: internal compiler error: in expand_simple_unop, at
optabs.c:2291
Why does this not work? I think the truncate expression is the problem.
Is this not the way to use truncate?
Thank you,
Charles J. Tabony
Successful gcc 4.0.1 build on alphaev68-dec-osf5.1b Tru64 (c,c++,f95,objc,java,treelang)
Dear list, [EMAIL PROTECTED]:~/GNU/gcc-4.0.1/TEST5#gcc -v Using built-in specs. Target: alphaev68-dec-osf5.1b Configured with: ../configure --host=alphaev68-dec-osf5.1b --enable-threads=posix --enable-languages=c,c++,f95,objc,java,treelang --prefix=/usr/local --enable-version-specific-runtime-libs --enable-shared --enable-libgcj --enable-nls --enable-interpreter Thread model: posix gcc version 4.0.1 NOTE for f95: you need to install GMP. I have gmp-4.1.4 and I`ve configured/installed it with "./configure --enable-mpfr" and then "make install". NOTE for JAVA: Check "sysconfig -q proc" and put "sysconfig -r proc exec_disable_arg_limit=1" (Andrey Ivanov says the opposite [http://gcc.gnu.org/ml/gcc/2005-04/msg01668.html] but java cannot be compiled with exec_disable_arg_limit=0 because there is a linking step with zillions of arguments) Sincerely, Stefano Curtarolo -- Prof. Stefano Curtarolo Assistant Professor of Materials Science Duke University, Dept. Mechanical Engineering and Materials Science 144 Hudson Hall, Box 90300, Durham, NC 27708-0300 phone 919-660-5506 [EMAIL PROTECTED] http://alpha.mems.duke.edu -- The chief enemy of creativity is "good" sense -- Picasso
Re: [toplevel] Update COPYING.LIB from FSF
On Wed, Jul 13, 2005 at 09:56:19PM -0400, DJ Delorie wrote: > > > 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. The FSF already asked GNU projects to correct the address.
Re: [toplevel] Update COPYING.LIB from FSF
> On Wed, Jul 13, 2005 at 09:56:19PM -0400, DJ Delorie wrote: > > > > > 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. > > The FSF already asked GNU projects to correct the address. Correcting the address, yes. Changing to a different version of the LGPL though? Did they specifically say "Any sources using an old version of the LGPL should upgrade to the latest LGPL in order to get the corrected address"? Otherwise, IMHO the right solution is to simply edit the COPYING.LIB to just correct the address, without introducing any other licensing changes.
please update the gcj main page
Please update http://gcc.gnu.org/java/index.html and mention how much of the Java 1.5 spec that GCJ currently implements. When I refer folks to GCJ, the first thing they usually ask is, "does it support generics?" "autoboxing?" and so on. That info should be right up on the GCJ front page -- even if GCJ doesn't support those newer features. *Especially* if GCJ doesn't support those newer features. Thanks, :) ---John Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: addsi3 with set condition register
[EMAIL PROTECTED] wrote: (insn 12 11 13 (set (reg:SI 168) (plus:SI (reg/v:SI 166 [ a ]) (reg/v:SI 167 [ b ]))) -1 (nil) (nil)) (insn 13 12 14 (set (reg:CC 33 cr1) (compare:CC (reg:SI 168) (const_int 0 [0x0]))) -1 (nil) (nil)) My pattern is (define_insn "..." [ (set (match_operand:SI 0 "register_operand" "=g") (plus:SI (match_operand:SI 1 "register_operand" "g") (match_operand:SI 2 "register_operand" "g")) ) (set (reg:CC CC_REGNUM) (compare:CC (match_dup 0) (const_int 0)))] your pattern is not equivalent to the two instructions shown. (the pattern is a parallel, the insns are a sequence) nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Where does the C standard describe overflow of signed integers?
Paul Schlie wrote: >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. What about optimising x*2/2 to x? -M-
Re: Where does the C standard describe overflow of signed integers?
> "Matthew" == Matthew Woodcraft <[EMAIL PROTECTED]> writes: Matthew> Paul Schlie wrote: >> 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. Matthew> What about optimising x*2/2 to x? If that doesn't overflow then it's valid, and if overflow is undefined it's valid in that case, too. :-) Of course this would be an example where overflow isn't treated as 2s complement wrap... paul
Re: Where does the C standard describe overflow of signed integers?
> Matthew Woodcraft writes: >> Paul Schlie wrote: >>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. > > What about optimising x*2/2 to x? Given that "C" requires the above be evaluated as (x*2)/2, as the language specifies that the syntax defines the precedence of the operations, and that no optimization should alter the behavior as specified by the program; I'd say that unless it was known that the value range of x was between 0 and INT_MAX, the optimization is simply invalid. As programmers should know and often rely on the finite range of integers to intentionally specify algebraically inconsistent transforms; which is why various precision integers, and in the infinite precision libraries are available for use when such overflow ambiguities are not acceptable or desired; the complier should simply do what is asked, not pretend it knows better, because it doesn't. However it seems quite reasonable and desirable for the compiler to provide feedback to the programmer, indicating that the expression specified may be portably algebraically simplified to "x", if the negative value overflow behavior was not intentionally desired; thereby enabling the programmer to improve both the portability and performance of their specified program, rather than assuming that a value altering optimization is desirable (which in general it never is, and typically only leads to difficult to diagnose problems, as the program isn't actually doing an equivalent of what was specified).
Re: Where does the C standard describe overflow of signed integers?
Paul Schlie wrote: What about optimising x*2/2 to x? Given that "C" requires the above be evaluated as (x*2)/2, as the language specifies that the syntax defines the precedence of the operations, and that no optimization should alter the behavior as specified by the program; I'd say that unless it was known that the value range of x was between 0 and INT_MAX, the optimization is simply invalid. the optimization is indeed valid optimizations may most certainly alter behavior of undefined code. think about uninitialized local variables.
Re: Where does the C standard describe overflow of signed integers?
> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: >>> What about optimising x*2/2 to x? >> >> Given that "C" requires the above be evaluated as (x*2)/2, as the language >> specifies that the syntax defines the precedence of the operations, and that >> no optimization should alter the behavior as specified by the program; I'd >> say that unless it was known that the value range of x was between 0 >> and INT_MAX, the optimization is simply invalid. > > the optimization is indeed valid > > optimizations may most certainly alter behavior of undefined > code. think about uninitialized local variables. I don't contest that it may, I simply don't believe it should.
Re: Where does the C standard describe overflow of signed integers?
Paul Schlie wrote: I don't contest that it may, I simply don't believe it should. you can't seriously mean that with respect to uninitialized variables. this would mean you could not put local variables in registers. the effect on code quality woul be awful!
Big Classpath Merge warning
I'm finally ready to check in the big classpath merge, and I wanted to post a short warning before I went ahead with it. For those who don't know about this, there is a description here: http://gcc.gnu.org/ml/java/2005-05/msg00202.html I've tested this merge natively (including multilib) and with a cross build (x86->arm), and things seem to be working ok. However, it is a fairly large build restructuring, and I've probably made an undiscovered mistake or two. Please report these to me and I will fix them as quickly as possible. I'm planning to do the checkin tomorrow, after classpath 0.17 is released (I have one more classpath change which is needed but which must go in post-0.17). I've updated libjava/HACKING in my tree to reflect the new approach. Perhaps there is some better place to document this though. Tom
Re: Where does the C standard describe overflow of signed integers?
> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: > >> I don't contest that it may, I simply don't believe it should. > > you can't seriously mean that with respect to uninitialized > variables. this would mean you could not put local variables in > registers. the effect on code quality woul be awful! Why would anyone care about the performance of an access to an un-initialized variable? Rather than attempting to insure their diagnosis, and hopeful subsequent removal the specified code? Personally, see no value in producing faster garbage; although do see substantial value in producing compiled code which is strictly consistent with the specified program and native target behavior, regardless of its portability.
Re: Where does the C standard describe overflow of signed integers?
> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes: >> From: Robert Dewar <[EMAIL PROTECTED]> >>> Paul Schlie wrote: What about optimising x*2/2 to x? >>> Given that "C" requires the above be evaluated as (x*2)/2, as the >>> language specifies that the syntax defines the precedence of the >>> operations, and that no optimization should alter the behavior as >>> specified by the program; I'd say that unless it was known that >>> the value range of x was between 0 and INT_MAX, the optimization >>> is simply invalid. >> the optimization is indeed valid >> >> optimizations may most certainly alter behavior of undefined >> code. think about uninitialized local variables. Paul> I don't contest that it may, I simply don't believe it should. In that case you may want to stick with -O0. There are *lots* of things GCC does that alter undefined cases. How about the undefined behavior when aliasing rules are violated? Would you want to make -fno-strict-aliasing be the only supported setting? paul
GCC and types, a request for help
This past week I have been looking into type mismatch in simple cases in GCC. These simple cases include non compatible types on the two sides of the MODIFY_EXPR and comparisons. All the bugs I have found so far have been filed. They are all listed under the meta-bug, PR 22368. The summary is that all languages have problems. Here is the list of the bugs: Ada:22328^* 22381^ 22383^ 22418 22419 22420 C: 22371 C++:22358^* 22369 22374 22434& 22451 22487 22494 middle-end: 22370 22372 22373 22398&* java: 22460^ objc: 22474^ fortran:22375(questionable if this is fortran or fold_builtins bug) Ones marked with * have a patch. Ones marked with ^ block bootstrap with the extra checking. Ones marked with & cause regression noticeable other places. All of the above bugs have a small testcase for the type mismatch. It would be nice if someone from the language/middle-end maintainer could look into the bugs listed above and try to fix them for stage1 of 4.2. I know that the Ada folks are looking into theirs already, most of theirs cannot really cause any problems but I know at least one C++ one which compares between an int and a long which are different sizes on LP64 targets. The two patches in PR 22368 are used to find these type mismatches. In some cases it is only detectable on LP64 targets. Thanks, Andrew Pinski
How to make an application look somewhere other than /lib for ld-linux.so.2
Hello all I apologize if this is off topic for this list - I wasn't sure exactly where to ask but I thought this would be a good place to start: I'm trying to get myself a group of libraries that I can distribute with my program so that they'll run on any distro. I run into problems all the time when different distros have different versions of system libraries like libstdc++, libgcc, libc, etc. So, I built myself a new gcc-3.4.4 compiler and build a simple "hello world" program with it on a RH8 machine. An ldd on this program yields [EMAIL PROTECTED] helloworld]$ ldd a.out libstdc++.so.6 => /cdl/apps/.software/linux/gcc-3.4.4-x86-x86/lib/libstdc++.so.6 (0x40015000) libm.so.6 => /lib/i686/libm.so.6 (0x40102000) libgcc_s.so.1 => /cdl/apps/.software/linux/gcc-3.4.4-x86-x86/lib/libgcc_s.so.1 (0x40124000) libc.so.6 => /lib/i686/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED] helloworld]$ Note that ldd is using the libstdc++ library that got built when the compiler was built - this seems like a good thing to me. To make this application run on a Red Hat 7.3 machine, I grabbed the system libraries that a.out depends upon (libc, libm) and copied them into my application's directory and changed LD_LIBRARY_PATH to point there. Now ldd outputs: [EMAIL PROTECTED] helloworld]$ ldd a.out libstdc++.so.6 => /cdl/apps/.software/linux/gcc-3.4.4-x86-x86/lib/libstdc++.so.6 (0x40015000) libm.so.6 => ./libm.so.6 (0x400ee000) libgcc_s.so.1 => /cdl/apps/.software/linux/gcc-3.4.4-x86-x86/lib/libgcc_s.so.1 (0x4011) libc.so.6 => ./libc.so.6 (0x40119000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED] helloworld]$ Note that ldd now picks up my local copies of libc and libm, but not of ld-linux. This program runs like this OK on Red Hat 7.3 when built on a RH8 machine, but not on an RHEL linux machine because the run-time linker is trying to use /lib/ld-linux.so.2 with my local copy of libc.so.6. The exact error message is: [EMAIL PROTECTED] helloworld]$ ./a.out ./a.out: relocation error: ./libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference [EMAIL PROTECTED] helloworld]$ This makes sense to me - the version of ld-linux.so and libc must match. So - the question is: How do I do this? Even though LD_LIBRARY_PATH points to ./ as it's first entry, ldd still looks in /lib first for ld-linux.so.2. I've tried the rpath option to ld at link time, but that doesn't work either. It seems that thing is somehow hardcoded to look in /lib for this library. Is there a way to somehow configure gcc build executables that look elsewhere for ld-linux.so.2, or is what I'm trying to do simply not possible? I'd really like to have a set of libraries with my program so that it's binary compatible with other distros... there must be a way. If anyone has any tips or advice I'd appreciate it. Thanks Mark Mark Cuss, B. Sc. Real Time Systems Analyst System Administrator CDL Systems Ltd Suite 230 3553 - 31 Street NW Calgary, AB, Canada Phone: 403 289 1733 ext 226 Fax: 403 289 3967 www.cdlsystems.com
Re: Where does the C standard describe overflow of signed integers?
> From: Paul Koning <[EMAIL PROTECTED]> >> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes: >>> From: Robert Dewar <[EMAIL PROTECTED]> Paul Schlie wrote: > What about optimising x*2/2 to x? Given that "C" requires the above be evaluated as (x*2)/2, as the language specifies that the syntax defines the precedence of the operations, and that no optimization should alter the behavior as specified by the program; I'd say that unless it was known that the value range of x was between 0 and INT_MAX, the optimization is simply invalid. >>> the optimization is indeed valid >>> >>> optimizations may most certainly alter behavior of undefined >>> code. think about uninitialized local variables. > > Paul> I don't contest that it may, I simply don't believe it should. > > In that case you may want to stick with -O0. There are *lots* of > things GCC does that alter undefined cases. How about the undefined > behavior when aliasing rules are violated? Would you want to make > -fno-strict-aliasing be the only supported setting? - Isn't the purpose of "restrict" to explicitly enable the compiler to more aggressively optimize references which it may be not have been able to identify it as being strictly safe? (As opposed to it feeling compelled presume potentially disastrously otherwise, without explicit permission to do so?)
How to make an application look somewhere other than /lib for ld-linux.so.2
"Mark Cuss" <[EMAIL PROTECTED]> wrote: I'm trying to get myself a group of libraries that I can distribute > with my program so that they'll run on any distro. > I run into problems all the time when different distros have different versions of system libraries like libstdc++, libgcc, libc, etc. ... Is there a way to somehow configure gcc build executables that look elsewhere for ld-linux.so.2, or is what I'm trying to do simply not possible? I'd really like to have a set of libraries with my program so that it's binary compatible with other distros... there must be a way. If anyone has any tips or advice I'd appreciate it. There are two official ways to go: 1) Build static binaries. (If your apps use libnss*.a, you may want to configure your toolchain's glibc with --enable-static-nss; I'm doing that now for one project. Don't tell drepper.) 2) Build your apps with lsbcc. That will link to the LSB's frozen version of libstdc++, etc. #1 is doable right now. #2 is, too, but requires your users to install your distro's LSB runtime package. - Dan
Re: [toplevel] Update COPYING.LIB from FSF
On Thu, Jul 14, 2005 at 12:43:18PM -0400, DJ Delorie wrote: > > The FSF already asked GNU projects to correct the address. > > Correcting the address, yes. Changing to a different version of the > LGPL though? Did they specifically say "Any sources using an old > version of the LGPL should upgrade to the latest LGPL in order to get > the corrected address"? As I understand it, the only difference in the bumped version number is the address. Can anyone confirm this?
Re: [toplevel] Update COPYING.LIB from FSF
> As I understand it, the only difference in the bumped version number > is the address. Can anyone confirm this? A simple diff shows other changes, including the all-new shared library clause and the change of "Library" to "Lesser" in the name.
gcc-4.0-20050714 is now available
Snapshot gcc-4.0-20050714 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050714/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050714 You'll find: gcc-4.0-20050714.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050714.tar.bz2 C front end and core compiler gcc-ada-4.0-20050714.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050714.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050714.tar.bz2 C++ front end and runtime gcc-java-4.0-20050714.tar.bz2 Java front end and runtime gcc-objc-4.0-20050714.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050714.tar.bz2The GCC testsuite Diffs from 4.0-20050707 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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.
