should_duplicate_loop_header_p and volatile asm statements
In the following test case (based on gcc.dg/tree-ssa/copy-headers.c),
the volatile asm statement is duplicated:
extern int foo (int);
void bla (void)
{
int i, n = foo (0);
for (i = 0; (({{ __asm__ volatile ("foo_label:"); }}), i < n); i++)
foo (i);
}
In this case, this is problematic because it contains a label, which
means that assembly will fail. (In other cases, there might be some
other magic that is adversely affected.)
The documentation of the asm keyword does not explicitly say that a
volatile asm statement may be duplicated by the compiler, but of
course it is to be expected in some cases (inlining, for example).
However, for consistency, it might be better to document that the
compiler may introduce duplicates in general (making my example
invalid).
What do you think?
Re: should_duplicate_loop_header_p and volatile asm statements
On Nov 14, 2005 10:31 AM, Florian Weimer <[EMAIL PROTECTED]> wrote: > > What do you think? I thought labels can't appear in an asm statement...? Gr. Steven
Mainline bootstrap broken
Hi, current mainline boostrap breaks (at least for me) on i686-pc-linux-gnu. configure flags : --quiet --prefix=$DESTDIR --enable-languages=c++,fortran --with-gmp=/afs/mpa/data/martin/mygmp /scratch/gcc>make bootstrap [...] stage1/xgcc -Bstage1/ -B/afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -Icp -I/scratch/gcc/gcc -I/scratch/gcc/gcc/cp -I/scratch/gcc/gcc/../include -I/scratch/gcc/gcc/../libcpp/include -I/afs/mpa/data/martin/mygmp/include /scratch/gcc/gcc/cp/parser.c -o cp/parser.o cc1: warnings being treated as errors /scratch/gcc/gcc/cp/parser.c:79: warning: initialization makes integer from pointer without a cast /scratch/gcc/gcc/cp/parser.c:83: warning: braces around scalar initializer /scratch/gcc/gcc/cp/parser.c:83: warning: (near initialization for 'eof_token.value') /scratch/gcc/gcc/cp/parser.c:83: warning: excess elements in scalar initializer /scratch/gcc/gcc/cp/parser.c:83: warning: (near initialization for 'eof_token.value') /scratch/gcc/gcc/cp/parser.c:85: warning: missing initializer /scratch/gcc/gcc/cp/parser.c:85: warning: (near initialization for 'eof_token.location') make[2]: *** [cp/parser.o] Error 1 make[2]: Leaving directory `/scratch/ogcc/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/scratch/ogcc/gcc' make: *** [bootstrap] Error 2 Cheers, Martin
Change in order of evaluation in 4.0.2
Hi, I've had a report from a friend that a program that I had written was crashing running a basic test which ran fine on my machine. He noted that he was using gcc 4.0.1, whereas I am running 3.4.1 (Mandrake 10.1) so I suspected a compiler bug might be the case. I use the gcc compiler a lot, but don't know enough to be able to install the new relase as a 'test' version in parallel with 3.4.1 so I was reluctant to download/install 4.0.1 to test this. After a couple of remote gdb runs, I still hadn't tracked down the problem, so I asked him to e-mail me a statically linked executable. Running this under gdb quickly established the cause of the problem - it was not a compiler bug, but a significant change in the order of evaluation of expressions. The statement in question was basically: a = b - c(); but the routine c() has the side effect of changing b. I had made the assumption that routines are always evaluated before a 'simple' operand would be loaded, which would be the case if I had written the compiler. However, it was clear that under 4.0.1, the value of 'b' was being loaded into a register before 'c' was invoked and the result was therefore different. I appreciate that this is quite valid according to the ANSI C standard and the team are within their rights to change this, but I am curious to know the reasoning behind the change which seems to me to make the object code less optimal. Bill -- +---+ | Bill Purvis, Amateur Mathematician| | email: [EMAIL PROTECTED] | | http://bil.members.beeb.net | +---+
Re: should_duplicate_loop_header_p and volatile asm statements
* Steven Bosscher: > On Nov 14, 2005 10:31 AM, Florian Weimer <[EMAIL PROTECTED]> wrote: >> >> What do you think? > > I thought labels can't appear in an asm statement...? Of course, you can put pretty much what you want into asm statements, the compiler does not look at them. Jumping from one asm statement to another doesn't work reliably, though, and is mentioned in the documentation.
Re: Change in order of evaluation in 4.0.2
On 11/14/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I appreciate that this is quite valid according to the ANSI C > standard and the team are within their rights to change this, > but I am curious to know the reasoning behind the change which > seems to me to make the object code less optimal. This is more like pure luck that it worked in the first place. And maybe bad luck for you now. But this "change" is surely just a side-effect of a different change, maybe even just a change in the amount of good/bad luck you're experiencing. Richard.
Re: Change in order of evaluation in 4.0.2
[EMAIL PROTECTED] wrote: > I appreciate that this is quite valid according to the ANSI C > standard and the team are within their rights to change this, > but I am curious to know the reasoning behind the change which > seems to me to make the object code less optimal. It is not a deliberate change. GCC 4.0 feature more than 40 new optimization passes, which rearrange and optimize your code in different ways. They all know that they can freely change the order of evaluation of operands within sequence points, so it's totally casual what the order ends up to be. As for the code being less or more optimal, this is a totally orthogonal issue. I suggest you inspect the assembly code to see if there is really a pessimization. In this case, feel free to file a bugreport in Bugzilla about it. -- Giovanni Bajo
Re: Mainline bootstrap broken
On Nov 14, 2005 12:52 PM, Martin Reinecke <[EMAIL PROTECTED]> wrote: > Hi, > > current mainline boostrap breaks (at least for me) on > i686-pc-linux-gnu. Known problem, someone checked in a bad patch. See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00946.html Gr. Steven
Re: cross builds to avr fail
I didn't realize that we had a target with BITS_PER_UNIT == 8 && UNITS_PER_WORD == 1. I see that for the AVR POINTER_SIZE is 16, which suggests that this code should use POINTER_SIZE or GET_MODE_BITSIZE (Pmode) rather than BITS_PER_WORD. But restricting it to BITS_PER_WORD >= 32 should also be fine. You may like to warn about "char a[4];" in embedded code, so I like the GET_MODE_BITSIZE (Pmode) solution better. It's more self explanatory. Paolo
Re: cross newlib builds on svn head
Laurent GUERBY wrote: On Thu, 2005-11-03 at 17:43 +0100, Paolo Bonzini wrote: Joel Sherrill <[EMAIL PROTECTED]> wrote: Hi, I have been trying to build sparc-rtems4.7 on the head using newlib's head for a few days now. I have finally narrowed the behavior down. If I configure for sparc I am configuring for sparc-rtems4.7 with c and c++, it builds fine. The build process uses xgcc for newlib as one would expect. If I add ada to the --enable-languages then newlib fails to build because it picks a non-existent compile (sparc-rtems4.7-cc) to build with. Can you try the attached patch? Paolo Hi Paolo, any chance to get this patch in SVN? This patch worked for me and I have gotten much farther with it. Laurent: Is there any chance of getting a fix for the Ada problem that is acceptable to put into CVS? It was an issue on at least arm and mips as I recall. --joel
arm sof float
Hi all, I have this function defined twice. One in the libgcc2.c file and one in gcc/config/arm/ieee754-df.S __floatdisf I have problem during compilation of a arm soft float toolchain. Is there any fix? Regards Michael
Re: arm sof float
On Mon, 2005-11-14 at 16:52, Michael Trimarchi wrote: > Hi all, > I have this function defined twice. One in the libgcc2.c file and one in > gcc/config/arm/ieee754-df.S > __floatdisf > > I have problem during compilation of a arm soft float toolchain. Is > there any fix? > Regards Michael The build system should only be using the latter. What configuration are you using? And what version of gcc? R.
Add revision number to gcc version?
The current "gcc --version" prints out gcc (GCC) 4.1.0 20051113 (experimental) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Can we change it to something like gcc (GCC) 4.1.0 20051113 (revision 106863) (experimental) or gcc (GCC) 4.1.0 revision 106863 (experimental) H.J.
Re: arm sof float
Richard Earnshaw wrote: On Mon, 2005-11-14 at 16:52, Michael Trimarchi wrote: Hi all, I have this function defined twice. One in the libgcc2.c file and one in gcc/config/arm/ieee754-df.S __floatdisf I have problem during compilation of a arm soft float toolchain. Is there any fix? Regards Michael The build system should only be using the latter. What configuration are you using? And what version of gcc? R. /home/luigi/crosstool-0.38/build/arm-9tdmi-linux-gnu/gcc-4.0.1-glibc-2.3.5/gcc-4.0.1/configure --target=arm-9tdmi-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-9tdmi-linux-gnu --with-float=soft --with-cpu=arm9tdmi --enable-cxx-flags=-mcpu=arm9tdmi --with-headers=/opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-9tdmi-linux-gnu/arm-9tdmi-linux-gnu/include --with-local-prefix=/opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-9tdmi-linux-gnu/arm-9tdmi-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-shared --enable-c99 --enable-long-long --with-gcc-version-trigger=/home/luigi/crosstool-0.38/build/arm-9tdmi-linux-gnu/gcc-4.0.1-glibc-2.3.5/gcc-4.0.1/gcc/version.c --enable-languages=c,c++ Linking error libgcc/./_floatdidf_s.o: In function `__floatdidf': libgcc2.c:(.text+0x0): multiple definition of `__floatdidf' libgcc/./_addsubdf3_s.o:/home/luigi/crosstool-0.38/build/arm-9tdmi-linux-gnu/gcc-4.0.1-glibc-2.3.5/gcc-4.0.1/gcc/config/arm/ieee754-df.S:474: first defined here/opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-9tdmi-linux-gnu/arm-9tdmi-linux-gnu/bin/ld: Warning: size of symbol `__floatdidf' changed from 108 in libgcc/./_addsubdf3_s.o to 140 in libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o: In function `__floatdisf': libgcc2.c:(.text+0x0): multiple definition of `__floatdisf' libgcc/./_addsubsf3_s.o:/home/luigi/crosstool-0.38/build/arm-9tdmi-linux-gnu/gcc-4.0.1-glibc-2.3.5/gcc-4.0.1/gcc/config/arm/ieee754-sf.S:315: first defined here/opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-9tdmi-linux-gnu/arm-9tdmi-linux-gnu/bin/ld: Warning: size of symbol `__floatdisf' changed from 172 in libgcc/./_addsubsf3_s.o to 252 in libgcc/./_floatdisf_s.o collect2: ld returned 1 exit status Regards Michael
Re: arm sof float
On Mon, 2005-11-14 at 17:17, Michael Trimarchi wrote: > Richard Earnshaw wrote: > > >On Mon, 2005-11-14 at 16:52, Michael Trimarchi wrote: > > > > > >>Hi all, > >>I have this function defined twice. One in the libgcc2.c file and one in > >>gcc/config/arm/ieee754-df.S > >>__floatdisf > >> > >>I have problem during compilation of a arm soft float toolchain. Is > >>there any fix? > >>Regards Michael > >> > >> > > > >The build system should only be using the latter. What configuration > >are you using? And what version of gcc? > > > >R. > > > > > > > > > /home/luigi/crosstool-0.38/build/arm-9tdmi-linux-gnu/gcc-4.0.1-glibc-2.3.5/gcc-4.0.1/configure > > --target=arm-9tdmi-linux-gnu --host=i686-host_pc-linux-gnu > --prefix=/opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-9tdmi-linux-gnu > --with-float=soft --with-cpu=arm9tdmi --enable-cxx-flags=-mcpu=arm9tdmi > --with-headers=/opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-9tdmi-linux-gnu/arm-9tdmi-linux-gnu/include > > --with-local-prefix=/opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-9tdmi-linux-gnu/arm-9tdmi-linux-gnu > > --disable-nls --enable-threads=posix --enable-symvers=gnu > --enable-__cxa_atexit --enable-shared --enable-c99 --enable-long-long > --with-gcc-version-trigger=/home/luigi/crosstool-0.38/build/arm-9tdmi-linux-gnu/gcc-4.0.1-glibc-2.3.5/gcc-4.0.1/gcc/version.c > > --enable-languages=c,c++ FSF gcc distributions aren't set up to do soft-float on arm-linux by default, so this must be a problem with the cross-tool patches. You'll need to talk to the cross-tool authors (try [EMAIL PROTECTED]). R.
Re: Null pointer check elimination
On Sun, Nov 13, 2005 at 04:29:26AM -0500, Robert Dewar wrote: > Richard Guenther wrote: > > >And this is why there seemed to be consensus to merge the two in the > >middle-end and preserve debug-info somehow differently. Like with > >a "frontend type-id" on the decl. That would allow lowering of f.i. > >integral types to their modes at some point, too. > > It seems a clear mistake to me to tie debug information so closely > to the actual gcc type information, and this is another example > of it causing unnecessary trouble. It seems that there are two separate attributes that distinguish reference types from pointer types ... 1) auto-dereferencing: debuggers interpret a.field, where a is a reference, as dereference(a).field. This is a feature that both C++ and Fortran want. 2) in C++, references are assumed never to be null. My Fortran is very rusty (I wrote vast amounts of Fortran in the 80s, but those brain cells are mostly gone), but I had naively assumed that the same was true in Fortran-land, however there appear to be some cases where it is not true. But even in Fortran, it seems there are many cases where we know that references cannot be null. (There may be other implicit attributes as well). Maybe the middle end should only have one pointer type, but with at least two attributes, one to tell the debugger to auto-dereference, one to mark those pointers that cannot point to null. This might enable more optimization.
Re: Null pointer check elimination
On Sat, Nov 12, 2005 at 04:01:07PM -0500, Andrew Pinski wrote:
> Was there an example of:
>
> int f(int &);
>
> int g(void)
> {
> int *a = 0;
> return f(*a);
> }
>
>
> Yes this would be undefined code but so what.
In a case like this, gcc could emit an error (since we can already
detect that a reference is always initialized to a null pointer).
If it did so, I can almost guarantee that some free software package
will be flagged (I recall writing such code myself 10+ years ago, before I
knew better), but it still might be a good thing.
Of course, it's not hard to hide the fact that a reference is null from
the compiler, and the compiler might then do optimizations based on the
assumption that the argument to f is a non-null reference. That would
be valid according to the standard.
Re: Null pointer check elimination
On Sat, Nov 12, 2005 at 10:47:33AM -0800, Per Bothner wrote: > Per Bothner wrote: > >A "function-never-returns-null" attribute doesn't seem like > >the right mechanism. Instead, there should be a "never-null" > >attribute on pointer types. A "function-never-returns-null" is > >just a function whose return-type has the "never-null" attribute. > > Gabriel Does Reis wrote: > >We already have such mechanism: a reference type -- which morally is > >implemented as a pointer type. > > Andrew Pinski wrote: > >That was mentioned a way ago as being wrong. A reference type can be NULL. > > There are other differences, at least in C++: If you assign to a > pointer, you change the pointer, while if you assign to a reference > you modify the referenced object. I.e. if a variable has reference > type, then the reference itself is constant. That's two separate features: the first is about how the source code is interpreted (and that corresponds to informing the debugger that the object is auto-dereferenced). The second corresponds to declaring that a pointer is itself const. So a C++ reference could be represented as a middle-end pointer type, provided that it is marked as auto-dereferencing, never null, and constant.
Re: cross builds to avr fail
Eric Botcazou wrote:
Building a --target=avr compiler currently fails because
/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/
-B/opt/cross/avr/bin/ -B/opt/cross/avr/lib/ -isystem
/opt/cross/avr/include -isystem /opt/cross/avr/sys-include -O2 -O2 -O2
-fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -U_FORTIFY_SOURCE
-DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF
-Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -DL_ashrdi3 -c ../../gcc/libgcc2.c -o
libgcc/./_ashrdi3.o ../../gcc/libgcc2.c: In function '__muldi3':
../../gcc/libgcc2.c:511: error: total size of local objects too large
which does not make any sense. The above is for a x86_64 host, but I
see this errors everywhere.
I guess the sanity check I've added doesn't apply to micro-controllers. Try
the attached patch.
avr-rtems4.7 fails differently and apparently further along (gcc head,
newlib 1.13.0, binutils 2.16.1)
home/joel/gcc-work/head/b-avr-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b-avr-rtems4.7/./gcc/ -nostdinc
-B/home/joel/gcc-work/head/b-avr-rtems4.7/avr-rtems4.7/avr3/newlib/
-isystem
/home/joel/gcc-work/head/b-avr-rtems4.7/avr-rtems4.7/avr3/newlib/targ-include
-isystem /home/joel/gcc-work/head/gcc-head-test/newlib/libc/include
-B/home/joel/gcc-41-test//avr-rtems4.7/bin/
-B/home/joel/gcc-41-test//avr-rtems4.7/lib/ -isystem
/home/joel/gcc-41-test//avr-rtems4.7/include -isystem
/home/joel/gcc-41-test//avr-rtems4.7/sys-include -mmcu=avr3
-DPACKAGE=\"newlib\" -DVERSION=\"1.13.0\" -I.
-I../../../../../../gcc-head-test/newlib/libc/misc -Os
-DPREFER_SIZE_OVER_SPEED -mcall-prologues -DHAVE_GETTIMEOFDAY
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DMISSING_SYSCALL_NAMES
-DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_OPENDIR -DNO_EXEC
-DHAVE_FCNTL -fno-builtin -O2 -g -O2 -mmcu=avr3 -c
../../../../../../gcc-head-test/newlib/libc/misc/init.c
../../../../../../gcc-head-test/newlib/libc/misc/init.c: In function
'__libc_fini_array':
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error:
unable to find a register to spill in class 'BASE_POINTER_REGS'
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error: this
is the insn:
(insn 64 31 32 2
../../../../../../gcc-head-test/newlib/libc/misc/init.c:56 (set
(mem/c:HI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [5 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: internal
compiler error: in spill_failure, at reload1.c:1890
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Re: inline-unit-growth tweek
On 13 Nov 2005 21:36:02 -0800, Ian Lance Taylor wrote: > Jan Hubicka <[EMAIL PROTECTED]> writes: > > > in testsuite there are few reduced testcases where unit growth (an > > inliner limit - inliner is allowed to inline as long as the unit don't > > grow by given percentage, set to 50%) is too strict. > > Out of curiousity, have you considered permitting inlining larger > functions if one or more of the actual arguments are constants, on the > theory that sometimes constant folding will bring the size back down > again? Yes, we thought about that. But, no - how would you estimate the effect of one constant parameter out of two for an estimated function size N? There would be as much bad as good effects, if not more, if we try to do this. On ipa branch with ssa inlining, inlining after ipcp will automatically do this, though. Richard.
Re: Null pointer check elimination
Joe Buck wrote:
On Sat, Nov 12, 2005 at 04:01:07PM -0500, Andrew Pinski wrote:
Was there an example of:
int f(int &);
int g(void)
{
int *a = 0;
return f(*a);
}
Yes this would be undefined code but so what.
In a case like this, gcc could emit an error (since we can already
detect that a reference is always initialized to a null pointer).
If it did so, I can almost guarantee that some free software package
will be flagged (I recall writing such code myself 10+ years ago, before I
knew better), but it still might be a good thing.
Of course, it's not hard to hide the fact that a reference is null from
the compiler, and the compiler might then do optimizations based on the
assumption that the argument to f is a non-null reference. That would
be valid according to the standard.
Excuse me. IANALL nor am I a compiler expert but ...
what kind of optimization might be done with the information
that a reference *should* never be null? Especially within
the server code (the implementation of "int f(int& a)" in this case.)
Perhaps incorrectly, but I tend to use a (C++) reference when I
require the caller/client to supply a non-null "pointer" to a
single object (as opposed to an array of objects.) Client code
is free to dereference a pointer to an object (perhaps allocated
in the heap) and invoke the operation.
And what is the meaning of code that does this:
int foo(int& a)
{
int*b = &a;
if(b ==0)
{
a();
}
else
{
b();
}
}
Not that this example makes any sense, nor would
I intentionally code this way ... but...
Is function a() invoked?
Is function b() invoked?
Or (most likely) am I just one of those people
that hasn't groked the subtleties of the C++ standard
despite having used it for more years than I care to
remember ;-)
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Re: Null pointer check elimination
On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote: > Excuse me. IANALL nor am I a compiler expert but ... > what kind of optimization might be done with the information > that a reference *should* never be null? Especially within > the server code (the implementation of "int f(int& a)" in this case.) There are several examples. One is converting from a derived class to a base class when there is multiple inheritance. An offset must be subtracted, unless it is a null pointer. Another is the "delete" operator. It must first check that the argument is null; it only calls the underlying memory allocator if it is not.
Re: should_duplicate_loop_header_p and volatile asm statements
On Nov 14, 2005, at 1:31 AM, Florian Weimer wrote:
The documentation of the asm keyword does not explicitly say that a
volatile asm statement may be duplicated by the compiler, but of
course it is to be expected in some cases (inlining, for example).
However, for consistency, it might be better to document that the
compiler may introduce duplicates in general (making my example
invalid).
What do you think?
We should enhance the documentation that currently says (extend.texi):
--
If you want to test the condition code produced by an assembler
instruction, you must include a branch and a label in the @code{asm}
construct, as follows:
@smallexample
asm ("clr %0\n\tfrob %1\n\tbeq 0f\n\tmov #1,%0\n0:"
: "g" (result)
: "g" (input));
@end smallexample
@noindent
This assumes your assembler supports local labels, as the GNU assembler
and most Unix assemblers do.
Speaking of labels, jumps from one @code{asm} to another are not
supported. The compiler's optimizers do not know about these jumps, and
therefore they cannot take account of them when deciding how to
optimize.
--
to state that normal labels don't work in asms, as they can be
duplicated for any reason by the compiler, for example, inlining and
that local labels (0: 0f in assembly) should be used instead. In
addition, there is a unique number generated by the compiler that can
be used to form unique labels (md.texi):
@samp{%=} outputs a number which is unique to each instruction in the
entire compilation. This is useful for making local labels to be
referred to more than once in a single template that generates multiple
assembler instructions.
that should be referenced from the other part of the documentation.
Re: Null pointer check elimination
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| And what is the meaning of code that does this:
|
| int foo(int& a)
| {
| int*b = &a;
|
| if(b ==0)
| {
| a();
| }
| else
| {
| b();
| }
According to the standard, the compiler can assume that the test is
always false, therefore rewrite the if-else as an unconditional call to
b(). GCC already does some null-pointer check deleting.
-- Gaby
Re: Add revision number to gcc version?
On Nov 14, 2005, at 9:14 AM, H. J. Lu wrote: Can we change it to something like gcc (GCC) 4.1.0 20051113 (revision 106863) (experimental) Doesn't work, unless you also have the branch name. Further, the substitutions that svn can do, doesn't allow for the above, and they don't want to `fix' svn to do it (see the FAQ). (I think I'd like it too.)
Re: Null pointer check elimination
Joe Buck wrote: On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote: Excuse me. IANALL nor am I a compiler expert but ... what kind of optimization might be done with the information that a reference *should* never be null? Especially within the server code (the implementation of "int f(int& a)" in this case.) There are several examples. One is converting from a derived class to a base class when there is multiple inheritance. An offset must be subtracted, unless it is a null pointer. Why does it matter if the pointer is null? It is an error in the program if it uses the result, but the same is true for using null pointers. Do we try to do something if the reference is to another invalid address (e.g. 0x01)? Do we want to hide the error by not crashing? Why not just do the math and keep running? This seems like a run-time check that is not a part of the C/C++ language as I understand it. Another is the "delete" operator. It must first check that the argument is null; it only calls the underlying memory allocator if it is not. I have a similar problem with this. Neither of these appear to be optimizations. As far as I know there is nothing that requires an implementation to do this kind of run-time checking even if we are dealing with pointers instead of references. Of course ... I *could* be wrong ;-) Perhaps I am not understanding (most likely), but I am still interested... Sorry if I'm just way off course. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Re: Null pointer check elimination
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| And what is the meaning of code that does this:
|
| int foo(int& a)
| {
| int*b = &a;
|
| if(b ==0)
| {
| a();
| }
| else
| {
| b();
| }
According to the standard, the compiler can assume that the test is
always false, therefore rewrite the if-else as an unconditional call to
b(). GCC already does some null-pointer check deleting.
Wow. I'm sure there is sound reasoning for this ... but I can't
understand what that might be given a client module could intentionally
(if ill-adviseadly) simply invoke the function:
void bar()
{
int* z=0;
foo(*z);
}
In short this is "surprising" to clearly under-informed me.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Re: Null pointer check elimination
"Michael N. Moran" <[EMAIL PROTECTED]> writes: [...] | Do we want to hide the error by not crashing? Why not just do the | math and keep running? This seems like a run-time check that | is not a part of the C/C++ language as I understand it. defined by which standards? -- Gaby
Re: Null pointer check elimination
Joe Buck wrote:
On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
Excuse me. IANALL nor am I a compiler expert but ...
what kind of optimization might be done with the information
that a reference *should* never be null? Especially within
the server code (the implementation of "int f(int& a)" in this case.)
There are several examples. One is converting from a derived class
to a base class when there is multiple inheritance. An offset must
be subtracted, unless it is a null pointer.
Another is the "delete" operator. It must first check that the
argument is null; it only calls the underlying memory allocator if it is
not.
It's also surprising to me that the delete operator can
be used on a reference when the new operator returns a pointer
and the only way to get that (possibly null) pointer to be
used as a reference is to dereference it and then apply
delete on the pointer formed by the address-of operator on
the resulting reference
void buzz(Abc& b)
{
delete &b;
}
void baz()
{
Abc& a = * new Abc();
buzz(a);
}
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Re: Null pointer check elimination
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | And what is the meaning of code that does this:
| > | | int foo(int& a)
| > | {
| > | int*b = &a;
| > | | if(b ==0)
| > | {
| > | a();
| > | }
| > | else
| > | {
| > | b();
| > | }
| > According to the standard, the compiler can assume that the test is
| > always false, therefore rewrite the if-else as an unconditional call to
| > b(). GCC already does some null-pointer check deleting.
|
| Wow. I'm sure there is sound reasoning for this ... but I can't
| understand what that might be given a client module could intentionally
| (if ill-adviseadly) simply invoke the function:
then it gets what it deserves. Check out GCC manual for null-pointer
check.
-- Gaby
Re: Null pointer check elimination
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
| > On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
| >
| >>Excuse me. IANALL nor am I a compiler expert but ...
| >>what kind of optimization might be done with the information
| >>that a reference *should* never be null? Especially within
| >>the server code (the implementation of "int f(int& a)" in this case.)
| > There are several examples. One is converting from a derived class
| > to a base class when there is multiple inheritance. An offset must
| > be subtracted, unless it is a null pointer.
| > Another is the "delete" operator. It must first check that the
| > argument is null; it only calls the underlying memory allocator if it is
| > not.
|
| It's also surprising to me that the delete operator can
| be used on a reference when the new operator returns a pointer
| and the only way to get that (possibly null) pointer to be
| used as a reference is to dereference it and then apply
| delete on the pointer formed by the address-of operator on
| the resulting reference
|
| void buzz(Abc& b)
| {
| delete &b;
| }
|
| void baz()
| {
| Abc& a = * new Abc();
If no memory is available, the new-expression throws an exception so
the dereference never occurs. Check out C++ manuals.
-- Gaby
Re: Null pointer check elimination
Gabriel Dos Reis wrote: "Michael N. Moran" <[EMAIL PROTECTED]> writes: [...] | Do we want to hide the error by not crashing? Why not just do the | math and keep running? This seems like a run-time check that | is not a part of the C/C++ language as I understand it. defined by which standards? At this point, I am entirely out of my league. As I said in my initial post, IANALL, I am simply one who has lurked on this list for years because of my interest in GCC as it applies to C/C++ . I freely admit to my ignorance on issues of the standards, but this behavior is surprising to me. You guys do a great job, and I depend on your compiler. I *want* GCC to be standards compliant, so I am not complaining. Its just that given the systems programming roots of C/C++ and the "you don't pay for what you don't use" and the "least surprise" maxims, I feel a bit confused. Sorry, I'll shut-up or go complain to the standards bodies ... yikes! ;-) -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Re: Null pointer check elimination
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| void buzz(Abc& b)
| {
| delete &b;
| }
|
| void baz()
| {
| Abc& a = * new Abc();
If no memory is available, the new-expression throws an exception so
the dereference never occurs. Check out C++ manuals.
As a systems programmer (embedded), I frequently use "-fno-exceptions".
What behavior can I expect under these circumstances?
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Re: Null pointer check elimination
Gabriel Dos Reis wrote: "Michael N. Moran" <[EMAIL PROTECTED]> writes: | Wow. I'm sure there is sound reasoning for this ... but I can't | understand what that might be given a client module could intentionally | (if ill-adviseadly) simply invoke the function: then it gets what it deserves. Check out GCC manual for null-pointer check. From info gcc: `-fdelete-null-pointer-checks' Use global dataflow analysis to identify and eliminate useless checks for null pointers. The compiler assumes that dereferencing a null pointer would have halted the program. If a pointer is checked after it has already been dereferenced, it cannot be null. The second sentence makes me question the difference between an actual dereferencing operation and the use of a dereferencing operator used to convert a pointer to a C++ reference. Clearly (to me anyway ;-) the conversion case does not actually cause an access to the object. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Re: Null pointer check elimination
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | void buzz(Abc& b)
| > | {
| > | delete &b;
| > | }
| > | | void baz()
| > | {
| > | Abc& a = * new Abc();
| > If no memory is available, the new-expression throws an exception so
| > the dereference never occurs. Check out C++ manuals.
|
| As a systems programmer (embedded), I frequently use "-fno-exceptions".
| What behavior can I expect under these circumstances?
You have to manually check the return value of new. There is no
substitute for that. At least, if you don't want to invoke that kind
of undefined behaviour.
-- Gaby
Re: Null pointer check elimination
"Michael N. Moran" <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | > "Michael N. Moran" <[EMAIL PROTECTED]> writes: | > | Wow. I'm sure there is sound reasoning for this ... but I can't | > | understand what that might be given a client module could intentionally | > | (if ill-adviseadly) simply invoke the function: | > then it gets what it deserves. Check out GCC manual for null-pointer | > check. | | From info gcc: | | `-fdelete-null-pointer-checks' | Use global dataflow analysis to identify and eliminate useless | checks for null pointers. The compiler assumes that dereferencing | a null pointer would have halted the program. If a pointer is | checked after it has already been dereferenced, it cannot be null. | | The second sentence makes me question the difference between an | actual dereferencing operation and the use of a dereferencing | operator used to convert a pointer to a C++ reference. Clearly | (to me anyway ;-) the conversion case does not actually cause | an access to the object. It is not a conversion. It is a dereference operation that is defined only for non-null operand. No ifs, no buts. -- Gaby
Re: Add revision number to gcc version?
On Mon, Nov 14, 2005 at 12:52:49PM -0800, Mike Stump wrote:
> On Nov 14, 2005, at 9:14 AM, H. J. Lu wrote:
> >Can we change it to something like
> >
> >gcc (GCC) 4.1.0 20051113 (revision 106863) (experimental)
>
> Doesn't work, unless you also have the branch name. Further, the
> substitutions that svn can do, doesn't allow for the above, and they
> don't want to `fix' svn to do it (see the FAQ). (I think I'd like it
> too.)
I was thinking to add a few lines like
rm -f info.$$
svn info > info.$$
revision=`grep Revision: info.$$ | awk '{ print $2 }'`
branch=`grep URL: info.$$ | sed -e "s,.*/,,g"`
{
echo branch: $branch
echo revision: $revision
}
rm -f info.$$
to contrib/gcc_update to put branch and revision into files so that
they can be used for gcc version.
H.J.
Re: Null pointer check elimination
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | void buzz(Abc& b)
| > | {
| > | delete &b;
| > | }
| > | | void baz()
| > | {
| > | Abc& a = * new Abc();
| > If no memory is available, the new-expression throws an exception so
| > the dereference never occurs. Check out C++ manuals.
|
| As a systems programmer (embedded), I frequently use "-fno-exceptions".
| What behavior can I expect under these circumstances?
You have to manually check the return value of new. There is no
substitute for that. At least, if you don't want to invoke that kind
of undefined behaviour.
Fine. I must relent and remain surprised.
Going back to the root of this discussion, however:
| Joe Buck wrote:
| > Another is the "delete" operator. It must first check that the
| > argument is null; it only calls the underlying memory allocator
| > if it is not.
I would simply expect the underlying memory allocator to be
invoked regardless of whether or not a pointer was null, but
honestly, in my line of work I rarely use the delete operator.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
[c++] stuff proposed for C++0x
Hello list. I've recently been toying with the "rref" patch found here: http://mndfck.org/~pedro.lamarao/projects/c++0x/ As part of my learning process I've modified it and broken it in three parts: new flags to activate c++0x syntax and semantics, "reference collapsing" as per DR #106 proposed resolution, and the "r-value references" proposal as in N1855. I'd like to also try and implement the new "auto" semantics as in N1894. These are online for your viewing pleasure here: http://mndfck.org/~pedro.lamarao/projects/c++0x/ Would any of this be acceptable for 4.2? -- Pedro Lamarão
Re: Null pointer check elimination
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| From info gcc:
|
| `-fdelete-null-pointer-checks'
| Use global dataflow analysis to identify and eliminate useless
| checks for null pointers. The compiler assumes that dereferencing
| a null pointer would have halted the program. If a pointer is
| checked after it has already been dereferenced, it cannot be null.
|
| The second sentence makes me question the difference between an
| actual dereferencing operation and the use of a dereferencing
| operator used to convert a pointer to a C++ reference. Clearly
| (to me anyway ;-) the conversion case does not actually cause
| an access to the object.
It is not a conversion. It is a dereference operation that is defined
only for non-null operand. No ifs, no buts.
I'm in over my head, but ... (oops there's a but ;-) here goes:
void bar(int& a);
void foo(int* a)
{
// dereference: conversion to reference
// Since there is not necessarily any object access,
// thus no assured SEGFAULT.
bar(*a);
// dereference: access to object
// If a is null, then SEGFAULT
*a = 0;
}
Sorry to drag this out. I'm sure its just one of those
"that's the way the language is defined Moran get over it"
issues, but (no ifs) ...
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Re: Null pointer check elimination
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | From info gcc:
| > | | `-fdelete-null-pointer-checks'
| > | Use global dataflow analysis to identify and eliminate useless
| > | checks for null pointers. The compiler assumes that dereferencing
| > | a null pointer would have halted the program. If a pointer is
| > | checked after it has already been dereferenced, it cannot be null.
| > | | The second sentence makes me question the difference between an
| > | actual dereferencing operation and the use of a dereferencing
| > | operator used to convert a pointer to a C++ reference. Clearly
| > | (to me anyway ;-) the conversion case does not actually cause
| > | an access to the object.
| > It is not a conversion. It is a dereference operation that is defined
| > only for non-null operand. No ifs, no buts.
|
| I'm in over my head, but ... (oops there's a but ;-) here goes:
|
| void bar(int& a);
|
| void foo(int* a)
| {
| // dereference: conversion to reference
| // Since there is not necessarily any object access,
| // thus no assured SEGFAULT.
| bar(*a);
SEGFAULT is not a behaviour defined by the language. It is *just* one
form of undefined behaviour. If you execute that function, it might
reformat your harddrive and that woud be fine -- though I know of no
compiler that does that on purpose. But, the point is that your
program in erring in the outer space.
| // dereference: access to object
| // If a is null, then SEGFAULT
| *a = 0;
Again, that may or may not happen.
| }
|
| Sorry to drag this out. I'm sure its just one of those
| "that's the way the language is defined Moran get over it"
| issues, but (no ifs) ...
Indeed.
-- Gaby
Re: Null pointer check elimination
On Mon, Nov 14, 2005 at 11:56:16PM +0100, Gabriel Dos Reis wrote: > "Michael N. Moran" <[EMAIL PROTECTED]> writes: > SEGFAULT is not a behaviour defined by the language. It is *just* one > form of undefined behaviour. If you execute that function, it might > reformat your harddrive and that woud be fine -- though I know of no > compiler that does that on purpose. But, the point is that your > program in erring in the outer space. > > | // dereference: access to object > | // If a is null, then SEGFAULT > | *a = 0; > > Again, that may or may not happen. Some operating systems load a page of zeroes at address zero, so the dereference of a null pointer has no visible effect; a different form of undefined behavior. DYNIX/ptx did that by default, and I think that HP-UX does it. I much prefer a segfault. Janis
Re: new operator in gcc-3.4
Lars Callenbach wrote: v = new double **[100]; operator new[]() -> operator new() -> malloc () -> _int_malloc() Without a testcase we can compile, we probably can't do anything except point out that a malloc failure is probably not due to a gcc problem. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: can DECL_RESULT be 0?
Rafael Ávila de Espíndola wrote: DECL_RESULT holds a RESULT_DECL node for the value of a function, or it is 0 for a function that returns no value. (C functions returning void have zero here.) I looked at gcc-1.42, and even there, a DECL_RESULT always holds a RESULT_DECL. It can never be zero. However, the DECL_RTL of this RESULT_DECL is zero for a function that returns no value. I'm not sure if this is a typo in the tree.def file, or whether perhaps an implementation change was made a very long time ago. Either way, this comment as written is wrong, and has been for a very long time. We could perhaps drop the comment about 0 values, or maybe expand it to say that the DECL_RTL of the RESULT_DECL is 0 for functions that return no value. aggregate_value_p doesn't look at DECL_RTL (DECL_RESULT (...)) so there is no problem there. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: strange result when compiling w/ -fpreprocessed but w/out -fdumpbase
Joern RENNECKE wrote: When you compile a file that contains a line directive, e.g.: using the -fpreprocessed option to cc1, but without -fdumpbase, the base filename of the line number directive us used both for the assembly output file and for debugging dumps from -da. This is probably a natural consequence of the fact that cpplib got split into a separate library. So now we need some way to communicate info from cpp to cc1, and this is done via a line directive. And at the least, the -fpreprocessed documentation is wrong when it states that this option is implicit when the file ends in .i; this effect of -fpreprocesed only appears when the option is actually passed to cc1. Try "touch tmp.i; ./xgcc -B./ -v tmp.i" and note that -fpreprocessed is passed by default to cc1. The docs aren't wrong here, you just missed the fact that there is a hidden option in the specs. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: [gfortran] Second try: Problem parsing hexadecimal constants?
Ioannis E. Venetis wrote: I sent this message about a week ago, but didn't get any response. So, I try again. My question is whether this is a bug of gfortran and if I should open a bug report about it. I haven't found this in Bugzilla. Yes, go ahead and create a bug report, and mention that this is a regression from f77. This list is primarily for developers, not for users, and hence isn't always "user friendly". You won't always get an answer to questions posted here. Also, check out the fortran mailing list mentioned on the gcc.gnu.org web site. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: arm-rtems Ada Aligned_Word compilation error
Joel Sherrill <[EMAIL PROTECTED]> wrote: s-auxdec.ads:286:13: alignment for "Aligned_Word" must be at least 4 Any ideas? I'm guessing this is because ARM sets STRUCTURE_SIZE_BOUNDARY to 32 instead of 8, and this confuses the Ada front end. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: [Treelang] flag_signed_char
Rafael Espíndola wrote: Why does treelang defines signedness of char with flag_signed_char? IMHO it would be better if it had a fixed definition of it. I have tried to use Signedness of char depends on the OS. If you want compatibility with C, and in particular, the standard C library, then you should use the OS default, which is obtained from flag_signed_char. flag_signed_char can also be overriden by user options, but this is not the main reason for using it. Did you try testing this on a system where "char" defaults to unsigned char? It is possible that the patch might work fine on a signed-char system, but fail on an unsigned-char system. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: fixincludes make check broken?
Andreas Jaeger wrote: Running make check in fixincludes on x86_64-gnu-linux I get the following failure: Just grepping for "_STRING_INCLUDED" it is easy to see the input rule in inclhack.def that defines this transformation, and the output rule in fixincl.x that actually does the transformation. This seems to be a generic problem. Anything using the "replace = " type rule is ending up with a missing newline on the last line. Looking at gcc-3.3.4, I see that the trailing newline is there in the fixincl.x file, but it isn't there in mainline. Offhand, I don't know what changed here. It could be that autogen changed, it could be that something in fixincluded changed, or it could even be that someone checked in the result of a broken autogen. If this is due to an autogen change, then perhaps the simplest fix is to change write_replacement in fixincl.c to emit the missing trailing newline after the fputs. I think the next step is to try to figure out if an autogen change broke this, or if a fixincludes change broke this. I'd suggest opening a PR to track this unless you want to volunteer to do this work. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: can DECL_RESULT be 0?
Jim Wilson <[EMAIL PROTECTED]> writes: | Rafael Ávila de Espíndola wrote: | > DECL_RESULT holds a RESULT_DECL node for the value of a function, | > or it is 0 for a function that returns no value. | > (C functions returning void have zero here.) | | I looked at gcc-1.42, and even there, a DECL_RESULT always holds a | RESULT_DECL. It can never be zero. However, the DECL_RTL of this | RESULT_DECL is zero for a function that returns no value. I'm not | sure if this is a typo in the tree.def file, or whether perhaps an | implementation change was made a very long time ago. Either way, this | comment as written is wrong, and has been for a very long time. We | could perhaps drop the comment about 0 values, or maybe expand it to | say that the DECL_RTL of the RESULT_DECL is 0 for functions that | return no value. aggregate_value_p doesn't look at DECL_RTL | (DECL_RESULT (...)) so there is no problem there. I was under the impression that the DECL_RESULT is nullified for a function that passes the named return-value optimization. -- Gaby
Re: Null pointer check elimination
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| void bar(int& a);
|
| void foo(int* a)
| {
| // dereference: conversion to reference
| // Since there is not necessarily any object access,
| // thus no assured SEGFAULT.
| bar(*a);
SEGFAULT is not a behaviour defined by the language.
Even *I* know that, in spite of my lack of legal expertise.
It is *just* one form of undefined behaviour.
Are you saying that this portion of the code *will*
invoke undefined behavior even if the pointer "a"
is valid?
Notice this example has nothing to do with null
pointers. It is a demonstration of the two kinds
of dereferences that I identified.
Perhaps the problem is that I am assuming the same
object code generated by this function is used for
all cases (e.g. null or valid values of "a",) and
that assumption falls apart in the presence of
optimizations such as inlining and inter procedural
optimizations.
If you execute that function, it might
reformat your harddrive and that woud be fine -- though I know of no
compiler that does that on purpose. But, the point is that your
program in erring in the outer space.
| // dereference: access to object
| // If a is null, then SEGFAULT
| *a = 0;
Again, that may or may not happen.
I understand that specifically a SEGFAULT may not happen,
but according to the excerpt from the GCC info page above,
"The compiler assumes that dereferencing a null pointer
would have halted the program."
In the first case, the result of the dereferencing *seems*
to be an address of the object in the form of a reference,
whereas the second case *seems* to clearly modify the object
(assuming the object is in memory ... whatever that means in
standardise).
FWIW, I appreciate your help, and realize that this is not
the forum for this kind of discussion. I apparently need to
get educated . Thank you for your patience.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Re: Null pointer check elimination
Maybe the middle end should only have one pointer type, but with at least two attributes, one to tell the debugger to auto-dereference, one to mark those pointers that cannot point to null. This might enable more optimization. That would certainly be my recommendation. It would also get rid of the TYPE_REFERENCE_TO field in types, which would save space. We originally had at most one POINTER_TYPE and at most one REFERENCE_TYPE pointing at each type. But that changed with code (partly mine) that allowed for a sort of "variant" of pointers, so that they could have a different mode and a "deref aliases all" flag. Added the suggested flags would just be an extension of this, would eliminate the question of "what's the difference between POINTER_TYPE and REFERENCE_TYPE" once and for all, and would simplify some code. Because build_reference_type would still exist, front end changes would be minimized.
Re: dwarf2 basic block start information
mathieu lacage wrote: Clearly, 0x11 is not a bb boundary so we have a bug. Looks like it could be the prologue end, but I don't see any obvious reason why this patch could do that. I suggest you try debugging your patch to see why you are getting the extra call with LINE_FLAG_BASIC_BLOCK set in this case. Using -p would make the diff more readable. We get complaints every time the debug info size increases. Since this is apparently only helpful to an optional utility, this extra debug info should not be emitted by default. There should be an option to emit it. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: dwarf2 basic block start information
On Mon, Nov 14, 2005 at 06:24:47PM -0800, Jim Wilson wrote: > mathieu lacage wrote: > >Clearly, 0x11 is not a bb boundary so we have a bug. > > Looks like it could be the prologue end, but I don't see any obvious > reason why this patch could do that. I suggest you try debugging your > patch to see why you are getting the extra call with > LINE_FLAG_BASIC_BLOCK set in this case. > > Using -p would make the diff more readable. > > We get complaints every time the debug info size increases. Since this > is apparently only helpful to an optional utility, this extra debug info > should not be emitted by default. There should be an option to emit it. I'd like to know what the size impact of including basic block information would be, first; a lot of tools, including GDB, could make use of it if it were available. -- Daniel Jacobowitz CodeSourcery, LLC
Re: dwarf2 basic block start information
On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote: > While the debugging output looks quite correct at -O0, the -O2 output > seems broken: > : > 0: 8d 4c 24 04 lea0x4(%esp),%ecx > 4: 83 e4 f0and$0xfff0,%esp > 7: ff 71 fcpushl 0xfffc(%ecx) > a: 55 push %ebp > b: 89 e5 mov%esp,%ebp > d: 53 push %ebx > e: 31 db xor%ebx,%ebx > 10: 51 push %ecx > 11: 83 ec 10sub$0x10,%esp > 14: 8d b6 00 00 00 00 lea0x0(%esi),%esi > With this list of basic block boundaries as reported by the debugging > information: > ad: 0x0 > ad: 0x11 > Clearly, 0x11 is not a bb boundary so we have a bug. Despite the fact No, not clear at all. Every place which could be the target of a jump will be the start of a basic block, but you are not guaranteed that all sequential basic blocks are combined. Probably either Jim's right and it's related to the end of the prologue, or it's a different basic block because of some artifact of inlining. This shouldn't present any problem for a tool using the basic block information. I'm afraid I don't have any useful comments on the patch, but I would like to see GCC generate this information. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Null pointer check elimination
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | void bar(int& a);
| > | | void foo(int* a)
| > | {
| > | // dereference: conversion to reference
| > | // Since there is not necessarily any object access,
| > | // thus no assured SEGFAULT.
| > | bar(*a);
| > SEGFAULT is not a behaviour defined by the language.
|
| Even *I* know that, in spite of my lack of legal expertise.
It is not really a matter of legal expertise. It is just hard to pin
down where you're driving at.
| > It is *just* one form of undefined behaviour.
|
| Are you saying that this portion of the code *will*
| invoke undefined behavior even if the pointer "a"
| is valid?
I'm saying that if you call foo with a null pointer, you get into
undefined behaviour territory. And GCC is founded to make
optimization based on that. And you -- as a user -- generally don't
know how and when GCC can apply that assumption. And it is already
doing so in known cases; it may do more in the future. I don't want
to go and give a long list of the specific cases; there is no point in
it. The transformation is general and will be applied where the
opportunity arises. Just don't count on dereferencing a null pointer
to result you or not result in a segfault in general.
-- Gaby
Re: can DECL_RESULT be 0?
On Mon, 2005-11-14 at 18:16, Gabriel Dos Reis wrote: > I was under the impression that the DECL_RESULT is nullified for a > function that passes the named return-value optimization. Just using grep, I don't see any obvious evidence of that. I don't know where to look for more info. I see a number of places in the front end that clear DECL_RESULT, but it appears that they are all clearing it so that it can be recomputed. Perhaps it is being nullified in some way other than setting the field to zero. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
New branch: ia64-improvements-branch
This branch will act as a repository for new optimizations mostly meant to improve code generation on IA-64. However, some of the work currently going on should help other targets as well. For now, this will help independent contributors to have a common code base to work with. The branch will be maintained by Robert Kidd. I will be co-maintainer, mostly to help with the mechanics of keeping the branch up-to-date. All the usual GCC contributing rules apply to the branch: - Patches must be submitted to gcc-patches for review. - Contributors must have a proper FSF copyright assignment on file. - Discussions on design and implementation issues are to be held on the main GCC development lists (gcc@ and gcc-patches@). - Messages discussing the branch should have [ia64-improvements] in the subject. Folks who need SVN write access and already have an FSF assignment, please contact me. The branch will follow mainline. Merges from mainline will happen at regular intervals. But only when mainline is in a sufficient stable state. To get a copy of the branch, you will need an SVN client. Some quick instructions: $ svn checkout svn://gcc.gnu.org/svn/gcc/branches/ia64-improvements-branch $ mkdir bld $ cd bld $ ../ia64-improvements-branch/configure --prefix=$HOME $ make all install The above will create a GCC binary in $HOME/bin. Gerald, is this patch OK for svn.html? Thanks. Index: svn.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v retrieving revision 1.10 diff -d -u -p -r1.10 svn.html --- svn.html 14 Nov 2005 23:36:25 - 1.10 +++ svn.html 15 Nov 2005 02:34:19 - @@ -253,7 +253,6 @@ generally of the form "gcc-X_Y [EMAIL PROTECTED]> and will be routinely merged with mainline. Patches should be marked with the tag [dataflow-branch] in the subject line. - Architecture-specific @@ -299,6 +298,17 @@ generally of the form "gcc-X_Y Patches should be marked with the tag [ia64-fp-model] in the subject line. + ia64-improvements-branch + The goal of this branch is to improve the performance of binaries + generated with GCC on the Itanium processor. Details of current + projects on this branch can be found at the http://gcc.gelato.org";>Gelato GCC wiki and at the IA-64 improvements page. This branch + is maintained by Robert Kidd <[EMAIL PROTECTED]> and + Diego Novillo. Patches and discussion related to this branch + should be marked with the tag [ia64-improvements] in + the subject line. The usual contribution and testing rules apply. Language-specific
Re: apps built w/ -fstack-protector-all segfault
Peter S. Mazinger wrote: -fno-stack-protector-all is not recognised/implemented You could just submit this as a bug report into bugzilla. apps built w/ -fstack-protector-all segfault You will have to give us more info. Most gcc developers probably don't have a copy of UClibc, and plus it sounds like you have made gcc changes that weren't included in your message. So there isn't much we can do here except ask for more details. Try debugging the problem. If you can identify a specific problem here, and give us details about it, we can probably help. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: New branch: ia64-improvements-branch
> > --Boundary-00=_dwUeD1M6OcgA542 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > > This branch will act as a repository for new optimizations mostly meant to > improve code generation on IA-64. However, some of the work currently > going on should help other targets as well. For now, this will help > independent contributors to have a common code base to work with. I don't see why this branch is need since really the patches will be independent and should be in good enough quality for stage1 which starts in like 5 days. -- Pinski
Re: Incorrect default options for h8300 target
Mike Lerwill wrote: #undef TARGET_DEFAULT_TARGET_FLAGS #define TARGET_DEFAULT_TARGET_FLAGS (MASK_QUICKCALL) This is mostly right, except that second line should be #define TARGET_DEFAULT_TARGET_FLAGS (TARGET_DEFAULT) Alternatively, we could delete the 2 lines defining TARGET_DEFAULT in h8300.h, and then we can define it the way you suggested. However, we then lose some configurability here, as then subtargets can't override the default. So probably better to do what I described. The patch needs to be tested before it can be checked in. I'll try a build and see what happens. Well, maybe not. My subversion check-out is screwed up, and I don't see how to fix it. An update failed because of a bug with my external diff program. I fixed that. I fumbled around a bit trying to find the right svn command I need to recover from this. Now I've got a locked working copy, and I'm getting errors from svn cleanup. I need something equivalent to "cvs update -A" here. I know my tree is screwed up, I just want svn to ignore everything I have in my working copy and give me the most recent copy of everything. I think I need to check out a new tree from scratch at this point. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: New branch: ia64-improvements-branch
On Mon, 2005-11-14 at 22:18 -0500, Andrew Pinski wrote: > > > > --Boundary-00=_dwUeD1M6OcgA542 > > Content-Type: text/plain; > > charset="us-ascii" > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > > > This branch will act as a repository for new optimizations mostly meant to > > improve code generation on IA-64. However, some of the work currently > > going on should help other targets as well. For now, this will help > > independent contributors to have a common code base to work with. > > I don't see why this branch is need since really the patches will be > independent > and should be in good enough quality for stage1 which starts in like 5 days. Maybe they are not targeting stage1 of 4.2? Also, stage1 lasts 3 months. They have time. If they want a branch, let them have a branch.
Re: apps built w/ -fstack-protector-all segfault
apps built w/ -fstack-protector-all segfault You will have to give us more info. Most gcc developers probably don't have a copy of UClibc, and plus it sounds like you have made gcc changes that weren't included in your message. So there isn't much we can do here except ask for more details. Try debugging the problem. If you can identify a specific problem here, and give us details about it, we can probably help. Also since __builtin_trap is used in the fail mechanism the comment above the trap instruction in i386.md might be useful: ;; We used to use "int $5", in honor of #BR which maps to interrupt vector 5. ;; That, however, is usually mapped by the OS to SIGSEGV, which is often ;; caught for use by garbage collectors and the like. Using an insn that ;; maps to SIGILL makes it more likely the program will rightfully die. ;; Keeping with tradition, "6" is in honor of #UD. So you may be seeing something mapped odd, or... -eric
Re: apps built w/ -fstack-protector-all segfault
On Mon, 14 Nov 2005, Jim Wilson wrote: > Peter S. Mazinger wrote: > > -fno-stack-protector-all is not recognised/implemented > > You could just submit this as a bug report into bugzilla. > > > apps built w/ -fstack-protector-all segfault > > You will have to give us more info. Most gcc developers probably don't > have a copy of UClibc, and plus it sounds like you have made gcc changes > that weren't included in your message. So there isn't much we can do sorry, the used gcc patches are those from http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/gcc/4.1.0/#dirlist (these are mostly needed due to gcc missing real uClibc support) > here except ask for more details. Try debugging the problem. If you can't really tell what is going on. I can only say, that I am using the stack protector since gcc 3.3.x in conjunction w/ uClibc (the "original" version), and now that I wanted to test it with newer gcc I have modified the guard setup part in uClibc so that it can both use the old (=gcc-4) guard style and fail (I have mimiced here the glibc non-TLS version for __stack_chk_guard). With gcc-3.4.4 it works well (as earlier), but gcc-4 (I have backported even *_chk and the ssp stuff to 4.0.2) fails. I have really hoped that someone here can duplicate it in any environment (because if fno-stack-protector-all does not even exist, then this part of the code wasn't even tested) There are 2 scenarios were it could behave the same: 1. Using newest glibc (2.3.6 is not enough), you need cvs, so it won't use libssp.so 2. Using any glibc in conjunction w/ libssp.so > can identify a specific problem here, and give us details about it, we > can probably help. what kind of details should I provide? Thanks, Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Mon, 14 Nov 2005, Eric Christopher wrote: > > > >> apps built w/ -fstack-protector-all segfault > > > > You will have to give us more info. Most gcc developers probably > > don't have a copy of UClibc, and plus it sounds like you have made > > gcc changes that weren't included in your message. So there isn't > > much we can do here except ask for more details. Try debugging the > > problem. If you can identify a specific problem here, and give us > > details about it, we can probably help. > > Also since __builtin_trap is used in the fail mechanism the comment > above the trap instruction in i386.md might be useful: This is only true is libssp.so is used, I am using "established, working" exit code, that worked w/ earlier ssp as well (when it was not integrated) I mentioned that I use it as integrated into libc (exactly like glibc-cvs does), glibc uses libc_message iirc for exit. this should also influence the -fstack-protector behaviour, but that seems to be OK. __builtin_trap is used as I can see only if a vulnerability is found, this happens though on a simple hello world. Thanks, Peter > > ;; We used to use "int $5", in honor of #BR which maps to interrupt > vector 5. > ;; That, however, is usually mapped by the OS to SIGSEGV, which is often > ;; caught for use by garbage collectors and the like. Using an insn > that > ;; maps to SIGILL makes it more likely the program will rightfully die. > ;; Keeping with tradition, "6" is in honor of #UD. > > So you may be seeing something mapped odd, or... > > -eric > > -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
this should also influence the -fstack-protector behaviour, but that seems to be OK. __builtin_trap is used as I can see only if a vulnerability is found, this happens though on a simple hello world. Aaah. You'll probably need to step through the program in a debugger then and find out where and why it segfaults. -eric
Re: dwarf2 basic block start information
On Mon, 2005-11-14 at 21:30 -0500, Daniel Jacobowitz wrote: > On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote: > > While the debugging output looks quite correct at -O0, the -O2 output > > seems broken: > > : > > 0: 8d 4c 24 04 lea0x4(%esp),%ecx > > 4: 83 e4 f0and$0xfff0,%esp > > 7: ff 71 fcpushl 0xfffc(%ecx) > > a: 55 push %ebp > > b: 89 e5 mov%esp,%ebp > > d: 53 push %ebx > > e: 31 db xor%ebx,%ebx > > 10: 51 push %ecx > > 11: 83 ec 10sub$0x10,%esp > > 14: 8d b6 00 00 00 00 lea0x0(%esi),%esi > > > With this list of basic block boundaries as reported by the debugging > > information: > > ad: 0x0 > > ad: 0x11 > > > Clearly, 0x11 is not a bb boundary so we have a bug. Despite the fact This was a bug in my dwarf2 reading code. I fixed it and this testcase works for me now. > No, not clear at all. Every place which could be the target of a jump > will be the start of a basic block, but you are not guaranteed that all > sequential basic blocks are combined. Probably either Jim's right and It would be nice if you could post an example where they are not combined. > it's related to the end of the prologue, or it's a different basic > block because of some artifact of inlining. This shouldn't present any > problem for a tool using the basic block information. Inlining or end-of-prologue do not seem to have an influence on this. It seems to actually work quite well. I will send an updated version of the patch in another email. Mathieu --
Re: Null pointer check elimination
Gabriel Dos Reis wrote: I'm saying that if you call foo with a null pointer, you get into undefined behaviour territory. And GCC is founded to make optimization based on that. And you -- as a user -- generally don't know how and when GCC can apply that assumption. And it is already doing so in known cases; it may do more in the future. I don't want to go and give a long list of the specific cases; there is no point in it. The transformation is general and will be applied where the opportunity arises. Just don't count on dereferencing a null pointer to result you or not result in a segfault in general. Perhaps not in general, but one unstated premise of this whole thread is that for some GCC targets (most Unix like operating systems) you *can* count on a SIGSEGV when you dereference a null pointer. The java front end takes advantage of this fact to eliminate explicit checks for dereferencing of null pointers. The Java Language Specification requires that NullPointerExceptions are thrown when calling a method via a null 'this'. But since a method call does not usually involve dereferencing 'this', an explicit check for null must be made when it cannot be proven that 'this' is not null. The original point of this thread was that some of these explicit checks may be eliminated based on a priori knowledge about the behavior of certain standard library methods. Which leads me to the (unrelated) thought that inserting an instruction that dereferences the pointer may be more efficient (from a code size point of view) than an explicit check for null and then branching around the code that creates and throws the exception. David Daney
Re: apps built w/ -fstack-protector-all segfault
On Mon, 14 Nov 2005, Eric Christopher wrote:
> >
> > this should also influence the -fstack-protector behaviour, but
> > that seems
> > to be OK.
> > __builtin_trap is used as I can see only if a vulnerability is
> > found, this
> > happens though on a simple hello world.
>
> Aaah. You'll probably need to step through the program in a debugger
> then and find out where and why it segfaults.
app:
#include
int main() {
printf("Hello\n");
return 0;
}
I don't really know gdb how to use, but
gdb run:
Program received signal SIGSEGV, Segmentation fault.
main () at tes.c:3
3 int main () {
>bt
#0 main () at tes.c:3
allowing it to core dump and running gdb against the core
#... 0x000 in ?? ()
finally
Error accessing memory address 0xc000: No such file or directory
The same built only w/ -fstack-protector is OK.
What else can I do to help finding the problem?
Apropos: there is another bug probably related to libssp.so use (does not
influence the case here, due to __stack_chk_guard being in libc), it
should write %{fstack-protector|fstack-protector-all: -lssp }, else for
-fstack-protector-all it won't link against libssp.so
Thanks, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
