GCC4.3.3: Bootstrap comparison failure!
Hi everyone, I got a "Bootstrap comparison failure!" error when building gcc 4.3.3: Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs Bootstrap comparison failure! ./tree-cfg.o differs ./double-int.o differs ./gimple-low.o differs ./tree-into-ssa.o differs ./tree-ssa-loop-unswitch.o differs ...omit... ./langhooks.o differs ...omit... ./tree-dfa.o differs ./tree-nomudflap.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/bwdata/testuser/repo/build-gcc-4.3.3-by-gcc-3.3.3' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/bwdata/testuser/repo/build-gcc-4.3.3-by-gcc-3.3.3' make: *** [all] Error 2 My configuration is: -Linux gnode2 2.6.5-7.97-smp #1 SMP Fri Jul 2 14:21:59 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux -SUSE LINUX Enterprise Server 9 (x86_64) -gcc 3.3.3 -gmp 4.2.2, mpfr 2.3.0 the configure cmd is: ../gcc-4.3.3/configure --prefix=/home/testuser/tools/gcc-4.3.3 --with-gmp=/home/testuser/tools/gmp-4.2.2 --with-mpfr=/home/testuser/tools/mpfr-2.3.0/ --enable-languages=c,c++,fortran And I found a strange problem when I tried to use the stage1-gcc/xgcc to compile langhooks.c (langhooks.o differs at the final comparison) manually. I used the following command to compile it twice, and compare the two produced langhooks.o. To my surprise, the two langhooks.o were not identical: In directory stage2-gcc, I issued the following cmd to produce langhooks1.o. >/home/testuser/repo/build-gcc-4.3.3-by-gcc-3.3.3/stage1-gcc/xgcc >-B/home/testuser/repo/build-gcc-4.3.3-by-gcc -3.3.3/./stage1-gcc/ -B/home/testuser/tools/gcc-4.3.3/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwr ite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-lo ng -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.3.3/gcc -I../../gcc-4.3. 3/gcc/. -I../../gcc-4.3.3/gcc/../include -I../../gcc-4.3.3/gcc/../libcpp/include -I/home/testuser/tools/gmp-4.2.2/inc lude -I/home/testuser/tools/mpfr-2.3.0-by-gcc-3.3.3//include -I../../gcc-4.3.3/gcc/../libdecnumber -I../../gcc-4.3.3/ gcc/../libdecnumber/bid -I../libdecnumber ../../gcc-4.3.3/gcc/langhooks.c -o langhooks1.o then, I issued the same cmd to produce langhooks2.o >/home/testuser/repo/build-gcc-4.3.3-by-gcc-3.3.3/stage1-gcc/xgcc >-B/home/testuser/repo/build-gcc-4.3.3-by-gcc -3.3.3/./stage1-gcc/ -B/home/testuser/tools/gcc-4.3.3/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwr ite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-lo ng -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.3.3/gcc -I../../gcc-4.3. 3/gcc/. -I../../gcc-4.3.3/gcc/../include -I../../gcc-4.3.3/gcc/../libcpp/include -I/home/testuser/tools/gmp-4.2.2/inc lude -I/home/testuser/tools/mpfr-2.3.0-by-gcc-3.3.3//include -I../../gcc-4.3.3/gcc/../libdecnumber -I../../gcc-4.3.3/ gcc/../libdecnumber/bid -I../libdecnumber ../../gcc-4.3.3/gcc/langhooks.c -o langhooks2.o finally, I compared langhooks1.o langhooks2.o >cmp -i 16 langhooks1.o langhooks2.o langhooks1.o langhooks2.o differ: byte 76626, line 514 And I have successfully built gcc 4.0.0 and gcc 4.1.2 on the same machine, but failed to build gcc 4.2.4 with the same "Bootstrap comparison failure!" problem. I have also tried to use gcc 4.0.0 to build gcc 4.3.3 on the same machine, but also failed with the same problem. Any suggestions? Thanks in advance.
Re: [PATCH][RFC] Adjust the middle-end memory model
On Tue, 19 May 2009, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >> - The tree alias oracle got similar functionality, refs_anti_dependent
> >>and refs_output_dependent and the tree level data dependence
> >>analysis code makes use of these.
>
> Do we still use TBAA for the original motivating reason for adding it,
> e.g.,:
>
> void f(float *f, int *n) {
> for (int i = 0; i < *n; ++i) {
> f[i] *= 2;
> }
> }
>
> where here you want to know that "f[i]" does not modify "*n"?
>
> (Yes, that code is kinda hokey, in that real-world code would probably
> not pass n by-reference, but of course this happens with structures and
> such...)
Yes, for the purpose of hoisting the load of *n out of the loop (if
a store to f[i] would clobber *n then you wouldn't be allowed to read
it back as int). What matters for hoisting loads is whether there
is a true dependence between *n and f[i] which there is not, as we
still disambiguate using TBAA for true dependence queries.
The difference is if you want to sink a load from *n beyond the
store to f[i] - in which case you ask if there is an anti-dependence
which we cannot exclude in this case (no TBAA is allowed here).
The latter is to make placement new and friends work.
Richard.
Re: REC: gimplify - create a temp that is set at outermost block?
On Wed, May 20, 2009 at 12:47 AM, Gary Funck wrote:
> On 05/19/09 12:10:43, Andrew Pinski wrote:
>> Gary wrote:
>> > Is the __thread feature now more universally/portably
>> > supported?
>>
>> Yes, see emutls.c and the VAR_DECL case in expand_expr_addr_expr_1 and
>> expand_expr_real_1 in expr.c.
>> [...] for the emulated support which is
>> implemented on the target side in emutls.c.
>>
>> On the tree level __thread looks the same for both the emulated and
>> native supports.
>
> Experimenting with this __thread emulation, a bit, I found that
> the following configure options appear to enable TLS emulation:
> --enable-threads=posix -disable-tls
> (where --enable-threads is likely unnecessary on most
> modern x86/Linux targets)
>
> Trying the following simple test program:
>
> __thread volatile int x;
>
> int main ()
> {
> x = 1;
> return x;
> }
>
> The following code was generated:
>
> movl $__emutls_v.x, %edi
> call __emutls_get_address
> movl $1, (%rax)
> movl $__emutls_v.x, %edi
> call __emutls_get_address
> movl (%rax), %eax
> addq $8, %rsp
> ret
>
> Above, __emutls_get_address() is called twice, with
> the same argument. I was surprised to see that the optimizer
> (GCC 4.3.2) didn't notice this and use CSE to avoid the second
> redundant call, because emultls_get_address is defined as
> a "const" function:
>
> DEF_EXT_LIB_BUILTIN (BUILT_IN_EMUTLS_GET_ADDRESS, "__emutls_get_address",
> BT_FN_PTR_PTR, ATTR_CONST_NOTHROW_NONNULL)
>
> Back to the issue at hand, it may turn out that GCC's TLS emulation
> (thanks for pointing this out) will have acceptable performance
> I'm still interested in understanding how to create a gimple
> temporary that is set once upon entry to a function, so that its
> value is available within the function's body.
This is likely because the libcall lacks a REG_EQUAL note (or
we lack something to put there). Tree level CSE would catch
it, but it doesn't see these function calls.
Richard.
> thanks,
> - Gary
>
Re: grokdeclarator drops type qualifiers when -aux-info isn't asserted?
On Tue, 19 May 2009, Gary Funck wrote: > That aside, I wonder if it is an error to drop the qualifiers > as shown above? In the case of UPC, for example, dropping qualifiers Please read the code (and comment) immediately above that you quoted, which saves the qualifiers combined with those specified in the declaration, and the subsequent code applying them in the process of building up the type. The bug would probably be that it doesn't also drop them if flag_gen_aux_info. See the named address space patches for examples of adding extra type qualifiers. -- Joseph S. Myers jos...@codesourcery.com
[jba...@redhat.com: [PATCH 0/3] tracepoints: delay argument evaluation]
hi,
While working on some Linux kernel code, I've found that functions that
are declared as 'static inline' are having their arguments evaluated
well before they are used. For example I have a function:
static inline void trace(arg1, arg2)
{
if (unlikely(enabled)) {
}
}
If i call 'trace(ptr->arg1, ptr->arg2)', then the pointers are
dereferenced before the 'if' is executed. Is there any way to delay the
argument evaluation until they are used? Am I missing a compiler option?
I am used gcc 4.3.0.
thanks,
-Jason
Re: GCC4.3.3: Bootstrap comparison failure!
chenyang writes: > I got a "Bootstrap comparison failure!" error when building gcc 4.3.3: These kinds of issues are always difficult to debug. There have been a couple of patches to stabilize different sorts which I don't think are in 4.3.3. That could conceivably cause differences if address space randomization is turned on. I don't know of any specific bug reports, though. In any case, try turning off address space randomization (/proc/sys/kernel/randomize_va_space). > finally, I compared langhooks1.o langhooks2.o >>cmp -i 16 langhooks1.o langhooks2.o > langhooks1.o langhooks2.o differ: byte 76626, line 514 Try running your commands with the --save-temps options and compare the resulting .s files. Also, try running the commands with the -fdump-tree-all -fdump-rtl-all options and see where the dump files first differ. Ian
Re: [jba...@redhat.com: [PATCH 0/3] tracepoints: delay argument evaluation]
Jason Baron writes:
> While working on some Linux kernel code, I've found that functions that
> are declared as 'static inline' are having their arguments evaluated
> well before they are used. For example I have a function:
>
> static inline void trace(arg1, arg2)
> {
> if (unlikely(enabled)) {
>
> }
> }
>
> If i call 'trace(ptr->arg1, ptr->arg2)', then the pointers are
> dereferenced before the 'if' is executed. Is there any way to delay the
> argument evaluation until they are used? Am I missing a compiler option?
> I am used gcc 4.3.0.
This question is appropriate for gcc-h...@gcc.gnu.org, not
g...@gcc.gnu.org. Please take any followups to gcc-help.
The short answer is no, there are no such compiler options. From the
compiler's perspective, ptr->arg1 is evaluated before the function call,
so even the fact that the arguments are only used in an unlikely branch
isn't going to help. What you want is for the compiler to sink the load
into the only place where the result of the load is used. That seems
like a reasonable optimization, at least when the result is only used in
an unlikely branch. I recommend that you open a enhancement request at
http://gcc.gnu.org/bugzilla with a complete standalone test case.
Ian
[RFC] enabling -fshow-column by default
Hi folks. Before I merge the diagnostics branch I'd like to enable it on the testsuite to get us all in the habit of at least being aware of columns. Joseph Myers suggested enabling it in the compiler instead of the testsuite. Are there any big objections to this? Aldy
Re: [RFC] enabling -fshow-column by default
2009/5/20 Aldy Hernandez :
> Hi folks.
>
> Before I merge the diagnostics branch I'd like to enable it on the
> testsuite to get us all in the habit of at least being aware of columns.
>
> Joseph Myers suggested enabling it in the compiler instead of the
> testsuite. Are there any big objections to this?
My only worry is that the testsuite may confuse column and line
numbers and pass/fail tests because of it.
Index: gcc/testsuite/gcc.dg/bogus-column.c
===
--- gcc/testsuite/gcc.dg/bogus-column.c (revision 0)
+++ gcc/testsuite/gcc.dg/bogus-column.c (revision 0)
@@ -0,0 +1,11 @@
+/* This testcase checks that line numbers are not confused with column
+ numbers. */
+/* { dg-do compile } */
+/* { dg-options "-fshow-column -fms-extensions -pedantic" } */
+
+/* { dg-bogus "ISO C doesn't support unnamed" "bogus" { target *-*-* } 22 } */
+
+struct {
+ struct a { int x; }; /* { dg-warning "22:ISO C doesn't support unnamed" } */
+ int bar;
+} hot;
Cheers,
Manuel.
Re: [RFC] enabling -fshow-column by default
Aldy Hernandez writes: > Before I merge the diagnostics branch I'd like to enable it on the > testsuite to get us all in the habit of at least being aware of columns. > > Joseph Myers suggested enabling it in the compiler instead of the > testsuite. Are there any big objections to this? I agree in principle that we should enable -fshow-column by default. Obviously, it will break some existing scripts, but I tend to think that for something like this that is OK. Any scripts which break are already slightly broken in that preprocessor error messages already display a column number. If you haven't already done so, please check that the emacs next-error function is not affected by this. When we have good caret diagnostics it would also be nice to enable them by default. However, that is a much bigger change. Does anybody have an opinion on that? Ian
Re: [RFC] enabling -fshow-column by default
2009/5/20 Ian Lance Taylor : > When we have good caret diagnostics it would also be nice to enable them > by default. However, that is a much bigger change. Does anybody have > an opinion on that? Why don't have that discussion when (and if) caret diagnostics are available? I don't think anyone is actively working on it, so it will just be a waste of bandwidth. Cheers, Manuel.
Re: [RFC] enabling -fshow-column by default
On Wed, 20 May 2009, Ian Lance Taylor wrote: > When we have good caret diagnostics it would also be nice to enable them > by default. However, that is a much bigger change. Does anybody have > an opinion on that? Yes, that tripling the size of output in a cascade of diagnostics is a bad idea. Possibly disable them by default after the first few errors (or a larger number of warnings) if enabled by default (not explicitly) up to then? Also, work with the GNU Coding Standards maintainers on any conventions for caret diagnostics in GNU software. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] enabling -fshow-column by default
> "Ian" == Ian Lance Taylor writes: Ian> If you haven't already done so, please check that the emacs next-error Ian> function is not affected by this. This definitely works. Tom
Re: [PATCH][RFC] Adjust the middle-end memory model
On Wed, 20 May 2009, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >> void f(float *f, int *n) {
> >> for (int i = 0; i < *n; ++i) {
> >> f[i] *= 2;
> >> }
> >> }
>
> > The difference is if you want to sink a load from *n beyond the
> > store to f[i] - in which case you ask if there is an anti-dependence
> > which we cannot exclude in this case (no TBAA is allowed here).
>
> By "not allowed", you don't mean "would be an invalid optimization", but
> rather "will no longer be done by GCC", right?
Right, not invalid in the above case but nevertheless no longer being
done by GCC. This is to properly support
int i;
float f;
void foo()
{
int *p = (int *)malloc(sizeof(int));
*p = 1;
i = *p;
float *q = (float *)p;
*q = 2.0;
f = *q;
}
where we need to avoid scheduling the store via *q before the load
from *p. The above is valid as I read C99 6.5/6, it is an object
with no declared type (obtained via malloc) and has type int
due to the store via *p "for that access and for subsequent accesses
_that do not modify the stored value_." (emphasis mine). So for
objects without a declared type C can do "placement new" by simply
storing with a different type. In C++ we of course have the
usual placement new situations.
Richard.
Re: [RFC] enabling -fshow-column by default
On Wed, May 20, 2009 at 04:39:00PM +0200, Manuel L?pez-Ib??ez wrote: > 2009/5/20 Aldy Hernandez : > > Hi folks. > > > > Before I merge the diagnostics branch I'd like to enable it on the > > testsuite to get us all in the habit of at least being aware of columns. > > > > Joseph Myers suggested enabling it in the compiler instead of the > > testsuite. ?Are there any big objections to this? > > My only worry is that the testsuite may confuse column and line > numbers and pass/fail tests because of it. Janis has a patch for the testsuite to handle all this. I am testing her patch with some of my own testsuite changes as well, and we're basically down to no regressions.
Re: [PATCH][RFC] Adjust the middle-end memory model
Richard Guenther wrote:
>> void f(float *f, int *n) {
>> for (int i = 0; i < *n; ++i) {
>> f[i] *= 2;
>> }
>> }
> The difference is if you want to sink a load from *n beyond the
> store to f[i] - in which case you ask if there is an anti-dependence
> which we cannot exclude in this case (no TBAA is allowed here).
By "not allowed", you don't mean "would be an invalid optimization", but
rather "will no longer be done by GCC", right?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: grokdeclarator drops type qualifiers when -aux-info isn't asserted?
On 05/20/09 09:45:11, Joseph S. Myers wrote: > On Tue, 19 May 2009, Gary Funck wrote: > > > That aside, I wonder if it is an error to drop the qualifiers > > as shown above? In the case of UPC, for example, dropping qualifiers > > Please read the code (and comment) immediately above that you quoted, > which saves the qualifiers combined with those specified in the > declaration, and the subsequent code applying them in the process of > building up the type. > [...] See the named address space patches for > examples of adding extra type qualifiers. Thanks. We've generally gotten that part right by adding a few qualifier bits. We can't however encode UPC's "layout qualifier" into the qualifier bits and we have to maintain it separately. I do see now that the layout qualifier on an element type should be handled earlier along with the rest of the qualifiers in the section that you're referencing. > The bug would probably be that it doesn't also drop > them if flag_gen_aux_info. Agreed. Though presumably the flag_gen_aux_info logic will have to be adjusted as well.
alphapca56-unknown-linux-gnu built
alphapca56-unknown-linux-gnu Using built-in specs. Target: alphapca56-unknown-linux-gnu Configured with: ./configure --prefix=/usr/local/GCC4 AR_FOR_TARGET=ar AS_FOR_TARGET=as 'CC_FOR_TARGET= /root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/xgcc -B/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/bin/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/lib/ -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/include -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/sys-include' CFLAGS='-g -O2' CXXFLAGS='-g -O2' 'CXX_FOR_TARGET= /root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/g++ -B/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/ -nostdinc++ -L/root/gcc-4.4.0/alphapca56-unknown-linux-gnu/libstdc++-v3/src -L/root/gcc-4.4.0/alphapca56-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/bin/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/lib/ -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/include -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/sys-include' DLLTOOL_FOR_TARGET=dlltool 'GCJ_FOR_TARGET= /root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/gcj -B/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/bin/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/lib/ -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/include -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/sys-include' 'GFORTRAN_FOR_TARGET= /root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/gfortran -B/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/bin/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/lib/ -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/include -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/sys-include' LDFLAGS= LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDMC_FOR_TARGET=windmc WINDRES_FOR_TARGET=windres target_alias=alphapca56-unknown-linux-gnu --enable-languages=c,c++,fortran,java,objc,obj-c++ --no-create --no-recursion : (reconfigured) ./configure --prefix=/usr/local/GCC4 AR_FOR_TARGET=ar AS_FOR_TARGET=as 'CC_FOR_TARGET= /root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/xgcc -B/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/bin/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/lib/ -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/include -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/sys-include' CFLAGS='-g -O2' CXXFLAGS='-g -O2' 'CXX_FOR_TARGET= /root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/g++ -B/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/ -nostdinc++ -nostdinc++ -I/root/gcc-4.4.0/alphapca56-unknown-linux-gnu/libstdc++-v3/include/alphapca56-unknown-linux-gnu -I/root/gcc-4.4.0/alphapca56-unknown-linux-gnu/libstdc++-v3/include -I/root/gcc-4.4.0/libstdc++-v3/libsupc++ -I/root/gcc-4.4.0/libstdc++-v3/include/backward -I/root/gcc-4.4.0/libstdc++-v3/testsuite/util -L/root/gcc-4.4.0/alphapca56-unknown-linux-gnu/libstdc++-v3/src -L/root/gcc-4.4.0/alphapca56-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/bin/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/lib/ -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/include -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/sys-include' DLLTOOL_FOR_TARGET=dlltool 'GCJ_FOR_TARGET= /root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/gcj -B/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/bin/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/lib/ -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/include -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/sys-include' 'GFORTRAN_FOR_TARGET= /root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/gfortran -B/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/bin/ -B/usr/local/GCC4/alphapca56-unknown-linux-gnu/lib/ -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/include -isystem /usr/local/GCC4/alphapca56-unknown-linux-gnu/sys-include' LDFLAGS= LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDMC_FOR_TARGET=windmc WINDRES_FOR_TARGET=windres target_alias=alphapca56-unknown-linux-gnu --enable-languages=c,c++,fortran,java,objc,obj-c++ --no-create --no-recursion Thread model: posix gcc version 4.4.0 (GCC) Fedora Core 9 for HP/DEC Alpha release Linux 2.6.26.3-29.3axp.fc9.alpha #1 Wed Oct 22 20:14:13 EDT 2008 alpha alpha alpha GNU/Linux glibc-2.8.90-11.alpha Tests: === gcc Summary === # of expected passes49397 # of expected failures 129 # of unsupported tests 499 === g++ Summary === # of expected passes19045 # of expecte
Re: REC: gimplify - create a temp that is set at outermost block?
On 05/20/09 10:40:02, Richard Guenther wrote: > Gary wrote: > > Above, __emutls_get_address() is called twice, with > > the same argument. I was surprised to see that the optimizer > > (GCC 4.3.2) didn't notice this and use CSE to avoid the second > > redundant call, because emultls_get_address is defined as > > a "const" function. > > This is likely because the libcall lacks a REG_EQUAL note (or > we lack something to put there). Tree level CSE would catch > it, but it doesn't see these function calls. Understood. Do you/others happen to know who is the maintainer of the TLS emulation? I tried a simple test case that works with the native TLS support, but it SEGV's when using TLS emulation. Perhaps a cockpit error on my part, but I'd like to see if I can use the TLS emulation for our purposes, and a first step is to get the example to work. thanks, - Gary
Re: bitfields: types vs modes?
We seem to have dropped this discussion. I now have *two* customers asking for this functionality. Can we pick it up again? We need to decide: 1. If the functionality will be allowed in gcc at all 2. What info the target needs to be provided to make the choices it wants 3. What, if any, common code can be shared between the CPUs
Re: bitfields: types vs modes?
DJ Delorie writes: > We seem to have dropped this discussion. I now have *two* customers > asking for this functionality. Can we pick it up again? We need to > decide: > > 1. If the functionality will be allowed in gcc at all > > 2. What info the target needs to be provided to make the choices it wants > > 3. What, if any, common code can be shared between the CPUs Since the ARM ABI apparently specifies something about volatile bitfields, I think we ought to implement that. I continue to think that a sane programmer would use a different mechanism. C/C++ provides mechanisms for working with memory mapped hardware. Bitfields are not one of those mechanisms. Ian
Re: bitfields: types vs modes?
Ian Lance Taylor wrote: >> 1. If the functionality will be allowed in gcc at all >> >> 2. What info the target needs to be provided to make the choices it wants >> >> 3. What, if any, common code can be shared between the CPUs > > Since the ARM ABI apparently specifies something about volatile > bitfields, I think we ought to implement that. Yes, we should. I am aware of real user demand for this feature as well. It's a competitive disadvantage for GCC not to have this feature. > I continue to think that a sane programmer would use a different > mechanism. C/C++ provides mechanisms for working with memory mapped > hardware. Bitfields are not one of those mechanisms. I think the ARM specification is pretty sensible, and would make a good cross-platform approach. Using bit-fields may not be portable at present, but it would sure be nice if it was; it maps directly onto how people think about memory-mapped peripherals. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Object file for Module is too large
g95 sets DECL_COMMON on these variable decls (only for Darwin
targets). This seems like a hack to me (see below). The problem is
darwin-specific, not related to the front-end. On darwin:
$ cat a.c int x[999] = { 0 }; $ gcc -c a.c && ls -lh a.o -rw-r--
r-- 1 fx wheel 38M May 12 13:43 a.o $ size a.o __TEXT __DATA __OBJC
others dec hex 0 3996 0 0 3996 26259fc
while on x86_64-linux, I get:
$ cat a.c int x[999] = { 0 }; $ gcc -c a.c && ls -lh a.o -rw-r--
r-- 1 fx fx 959 May 12 13:44 a.o $ size a.o text data bss dec hex
filename 0 0 3996 3996 26259fc a.o
I'm CC'ing Andrew as he could give us a good idea of what needs to be
done.
Thanks,
FX
Index: trans-decl.c
===
--- trans-decl.c(revision 147744)
+++ trans-decl.c(working copy)
@@ -144,6 +144,8 @@ tree gfor_fndecl_convert_char4_to_char1;
tree gfor_fndecl_size0;
tree gfor_fndecl_size1;
tree gfor_fndecl_iargc;
+tree gfor_fndecl_clz128;
+tree gfor_fndecl_ctz128;
/* Intrinsic functions implemented in Fortran. */
tree gfor_fndecl_sc_kind;
@@ -524,6 +526,7 @@ gfc_finish_var_decl (tree decl, gfc_symb
/* This is the declaration of a module variable. */
TREE_PUBLIC (decl) = 1;
TREE_STATIC (decl) = 1;
+ DECL_COMMON (decl) = 1;
}
/* Derived types are a bit peculiar because of the possibility of
Re: bitfields: types vs modes?
> I think the ARM specification is pretty sensible, and would make a > good cross-platform approach. Could you distill it for us? If it's acceptable to my two customers, it would be a good starting point to define an API for the targets.
fixincludes & sed question
I have a question about the use of sed by fixincl and mkheaders and a change that was made between 4.3.* and 4.4.0. It involves this patch: 2008-09-06 Bruce Korb * fixincl.tpl (sed): make the program executable configurable. Some platforms have some rather oddball defaults. * config.h.in (SED_PROGRAM): define the default sed. * fixincl.x: regenerated * tests/base/internal/wchar_core.h: fix bad sample text * tests/base/math.h: fix bad sample text * configure.ac: search for working sed * inclhack.def (glibc_mutex_init): fix non-portable construct and re-order a few misordered entries. Prior to this patch, when a user ran mkheaders to fix up the GCC headers, mkheaders would call fixincl and fixincl would call sed. The sed that was called was found using the path you had when running mkheaders. After this patch, the sed used when building GCC is saved in a config file and that path to sed is used when you run mkheaders. This is a problem if mkheaders is run after the GCC build and the sed used is no longer available. I ran into this problem because when I build GCC I use a GNU sed that I have in my build environment along with GCC, bison, the auto* tools, etc. But then I package GCC up for users into a bundle which when installed will automatically run mkheaders on their system in order to make sure the GCC headers are in sync with their system headers which may or may not be identical to the ones on the system where I built GCC. They don't have my build environment available and so sed is not found and the mkheaders command fails. I am wondering if it is reasonable to require having the 'build sed' available anytime we want to run mkheaders? I can work around this by removing the sed from my build environment (causing it to use /usr/bin/sed) or should we could change fixincl to default to using path to find sed if the configured one can't be found? Steve Ellcey s...@cup.hp.com
Re: fixincludes & sed question
On Wed, May 20, 2009 at 2:47 PM, Steve Ellcey wrote: > I have a question about the use of sed by fixincl and mkheaders > and a change that was made between 4.3.* and 4.4.0. > After this patch, the sed used when building GCC is saved in a config > file and that path to sed is used when you run mkheaders. This is > a problem if mkheaders is run after the GCC build and the sed used > is no longer available. > > I ran into this problem because when I build GCC I use a GNU sed > that I have in my build environment along with GCC, bison, the > auto* tools, etc. But then I package GCC up for users into a > bundle which when installed will automatically run mkheaders on > their system in order to make sure the GCC headers are in sync > with their system headers which may or may not be identical to the > ones on the system where I built GCC. They don't have my build > environment available and so sed is not found and the mkheaders > command fails. > > I am wondering if it is reasonable to require having the 'build sed' > available anytime we want to run mkheaders? Hi Steve, The "mkheaders" command would need to know where to find a POSIX sed command. Unfortunately, the BSD command is not POSIX compatible and is the default sed command for BSD. The easiest solution is not completely obvious. Perhaps you can figure out a different POSIX sed to use for the build process? One that would be around? Later on, someone can train "mkheaders" to accept a parameter or environment variable to use, and further down the road perhaps we can get rid of "sed" style fixes altogether. Those won't happen today though. Sorry. - Bruce
Re: REC: gimplify - create a temp that is set at outermost block?
Gary Funck writes: > Do you/others happen to know who is the maintainer of the > TLS emulation? I tried a simple test case that works > with the native TLS support, but it SEGV's when using > TLS emulation. Perhaps a cockpit error on my part, but > I'd like to see if I can use the TLS emulation for our > purposes, and a first step is to get the example to work. It was written by Richard Henderson, Jakub Jelinek, and Alexandre Oliva. They all read this mailing list. If you have found a bug, the fastest way to address is probably to file a bug report. Or if you just want a sanity check, ask on the list. Ian
Re: REC: gimplify - create a temp that is set at outermost block?
On 05/20/09 17:13:23, Ian Lance Taylor wrote: > Gary Funck writes: > > > Do you/others happen to know who is the maintainer of the > > TLS emulation? > > [...] If you have found a bug, the fastest > way to address is probably to file a bug report. Doing a bit of research, it seems that the bug has already been been recently reported (against GCC 4.3, which the baseline we're using), http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024 (The suggested fix hasn't been committed to the head svn branch, however.) thanks, - Gary
nops
Under which conditions GCC generates nops? I noticed that with 4.4.0, gen_nop() is required, thing that wasn't with 4.3.3. Can I just define an empty insn for nop, of GCC requires a one-byte insn for its own alignment purposes? - Jamie
Re: [PATCH][RFC] Adjust the middle-end memory model
Richard Guenther wrote:
> int i;
> float f;
> void foo()
> {
> int *p = (int *)malloc(sizeof(int));
> *p = 1;
> i = *p;
> float *q = (float *)p;
> *q = 2.0;
> f = *q;
> }
Yes, I think that's a valid program too. I'm OK with giving up this
optimization; clearly we need to be correct first and foremost.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Issue on Solaris box
Hi, I'm running my C program on a Solaris machine with the following gcc version installed. >>gcc version 3.4.6 >>Thread model 3.4.6 >>/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/spec Issue: The same code seems to compile and execute fine on mingw running on Windows with gcc version 3.4.5 cygwin running on Windows with gcc version 3.4.4 The C program compiles fine but fails during execution in Solaris machine Is it possible for different version of gcc to behave unexpectedly. Is it a problem of different architecture? or a code bug? Could u give me a list of gcc version which is stable/compatible for Solaris env. Thanks Santosh
Re: nops
Jamie Prescott writes: > Under which conditions GCC generates nops? It depends entirely on the target. For many targets, gcc will never generate a nop instruction, except as a byproduct of alignment. > I noticed that with 4.4.0, gen_nop() is required, thing that wasn't with > 4.3.3. > Can I just define an empty insn for nop, of GCC requires a one-byte insn for > its > own alignment purposes? Normally gcc does alignment by issuing an assembler directive, and the assembler is responsible for generating nop instructions when necessary. Ian
Re: Issue on Solaris box
santosh k writes: > I'm running my C program on a Solaris machine with the following gcc version > installed. > >>>gcc version 3.4.6 >>>Thread model 3.4.6 >>>/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/spec > > Issue: > The same code seems to compile and execute fine on > mingw running on Windows with gcc version 3.4.5 > cygwin running on Windows with gcc version 3.4.4 > > The C program compiles fine but fails during execution in Solaris machine > Is it possible for different version of gcc to behave unexpectedly. > > Is it a problem of different architecture? or a code bug? > > Could u give me a list of gcc version which is stable/compatible for Solaris > env. This message is not appropriate for the gcc@gcc.gnu.org mailing list. It would be appropriate for the gcc-h...@gcc.gnu.org mailing list. Please take any followups to gcc-help. There are many many different reasons why a program might work fine on Windows but fail on Solaris. It is fairly unlikely to be a compiler problem. gcc 3.4.6 is stable on Solaris. Ian
-Wcast-qual and casting away
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts away
qualifiers
If I compile this program with gcc -Wcast-qual, I do not get any
warning.
Let's overlook the fact that the text of the g++ warning does not make
any sense--I am certainly not casting anything away. The warning is
conceptually plausible for the same reason that you can't assign a
char** variable to a const char** variable without a cast. At least, I
think one could make a argument that that is so. But it's not a *very*
strong argument, as -Wcast-qual is documented to warn about cases where
a type qualifier is removed, and that is manifestly not happening here.
-Wcast-qual is useful to catch certain programming errors; I don't think
anybody adding a const qualifier is actually making a mistake.
All that aside, I can't think of any reason that the C and C++ frontends
should be different in this regard. Does anybody want to make an
argument for which of these choices we should adopt?
1) Keep things the same: the C++ frontend warns, the C frontend doesn't.
Consistency is overrated.
2) Change the C frontend to also warn about this case, albeit with a
better message.
3) Change the C++ frontend to not warn about this case.
Of course in all cases the frontends should continue to warn about a
cast from const void** to void**.
Ian
Re: bitfields: types vs modes?
DJ Delorie wrote:
>> I think the ARM specification is pretty sensible, and would make a
>> good cross-platform approach.
>
> Could you distill it for us?
The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
The term "container" here means the declared type of the bit-field.
(There's a corner-case for C++ bit-fields that are bigger than their
declared type, but don't worry about that.) So "int i:6" has a 32-bit
container, whereas "char c:6" has an 8-bit container.
(In the ARM ABI, a bit-field never crosses a container boundary; "struct
{ char c1:6; char c2:3}" puts "c2" completely into the second byte, not
straddling the first two bytes. But, if those were int bit-fields, then
the second bit-field would straddle the two bytes. Packed structures
are outside the scope of the ABI.)
> When a volatile bit-field is read, its container must be read exactly
> once using the access width appropriate to the type of the container.
> When a volatile bit-field is written, its container must be read
> exactly once and written exactly once using the access width
> appropriate to the type of the container. The two accesses are not
> atomic.
> Multiple accesses to the same volatile bit-field, or to additional
> volatile bit-fields within the same container may not be merged. For
> example, an increment of a volatile bit-field must always be
> implemented as two reads and a write.
> Note the volatile access rules apply even when the width and
> alignment of the bit-field imply that the access could be achieved
> more efficiently using a narrower type. For a write operation the
> read must always occur even if the entire contents of the container
> will be replaced.
> If the containers of two volatile bit-fields overlap then access to
> one bit-field will cause an access to the other. For example, in
> struct S {volatile int a:8; volatile char b:2}; an access to a will
> also cause an access to b, but not vice-versa.
> If the container of a non-volatile bit-field overlaps a volatile
> bit-field then it is undefined whether access to the non-volatile
> field will cause the volatile field to be accessed.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
