gnat -m31/-m32 broken on 64bit with gcc 4.x
Hi, 31bit Ada executables segfault when built on a 64bit system with gcc 4.x. The 31bit libgnat library is installed in /usr/lib. When I build an 31bit executable with -m31 using a 64bit gcc executing the result failes with a segfault in the gnatbind generated adainit function. Further debugging showed that the problem is caused by the System.Address type beeing 64bits wide in adainit. adainit calls the SetGlobals function in the 31bit libgnat. One of the parameters is &Restrictions which is passed as System.Address. The problems appears since the system.ads file got split into a 31bit and a 64bit version. On gcc 3.4.2 a single system.ads defines: Memory_Size : constant := 2 ** Standard'Address_Size; type Address is mod Memory_Size; and the 31bit executables are working with that. With gcc 4.x come two versions of system.ads (s390 and s390x) and only the 64bit version exists in the installation: Memory_Size : constant := 2 ** 64; I think the problem is not limited to s390. Without beeing able to test it I would say that x86 should have the same trouble (with -m32 of course). Returning to a single system.ads as before is not an option here because the split was done for a good reason: http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01835.html I'm afraid this is a fundamental problem with the ada build machinery. On multilib targets we need both versions of system.ads and should make gnatbind to choose. Could one of the Ada people have a look at this? Bye, -Andreas-
Re: gnat -m31/-m32 broken on 64bit with gcc 4.x
> Returning to a single system.ads as before is not an option here because the > split was done for a good reason: Right, definitely not an option. In particular since there are potentially many other files that will be different between configurations. Ada currently does not have built-in support for multilibs (there's a related PR I believe). Instead, it has another (similar but different) mechanism via the --RTS make/compile/bind switch, which require manual build/install of several gnatlib via calls to make -C gcc gnatlib with appropriate options. For instance to build a 64 bit run time with a 32 bits Solaris compiler: make -C gcc THREAD_KIND=m64 GNATLIBCFLAGS="-O2 -m64" gnatlib Connecting this capability with the multilib mechanism would be nice although nobody has done it so far (for either lack of interest or lack of knowledge of the gcc makefiles), and there are non trivial issues since there are some run-times that are supported by the Ada compiler (e.g. pthread run-time on Solaris, the gnatlib-sjlj and gnatlib-zcx targets) that have no corresponding multilib configuration, and vice-versa. Combining all the possibilities would simply create an explosion of run-time, which is also not desirable. Arno
Re: debug_hooks->end_prologue problem
> If you compile without optimization, then this is the same as the
> prologue end. If you compile with optimization, then the function body
> and the prologue overlap. Now the question is, do you really want to
> mark the beginning of the function body (which may be before the
> prologue end), or the end of the prologue (which may be after the
> function body beginning). Either way, it is likely that someone may not
> be happy. However, in general, the former (function body beginning) is
> more useful to end users, as otherwise they won't be able to debug all
> of the code in the function body. So the current code in final.c looks
> correct.
Yes, the code in final.c is OK. However, there is a bug pertaining to the
placement of the NOTE_INSN_FUNCTION_BEG note for parameterless functions.
void foo(void)
{
int i = 0;
}
In .flow2 at -O0:
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
;; Start of basic block 3, registers live: 6 [bp] 7 [sp] 16 [argp] 20 [frame]
(note 6 3 19 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn/f 19 6 20 3 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg/f:DI 6 bp)) -1 (nil)
(nil))
(insn/f 20 19 21 3 (set (reg/f:DI 6 bp)
(reg/f:DI 7 sp)) -1 (nil)
(nil))
(note 21 20 8 3 NOTE_INSN_PROLOGUE_END)
void bar(int par)
{
int i = 0;
}
(insn/f 20 6 21 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg/f:DI 6 bp)) -1 (nil)
(nil))
(insn/f 21 20 22 2 (set (reg/f:DI 6 bp)
(reg/f:DI 7 sp)) -1 (nil)
(nil))
(note 22 21 3 2 NOTE_INSN_PROLOGUE_END)
(insn 3 22 4 2 (set (mem/c/i:SI (plus:DI (reg/f:DI 6 bp)
(const_int -20 [0xffec])) [0 par+0 S4 A32])
(reg:SI 5 di [ par ])) 40 {*movsi_1} (nil)
(nil))
(note 4 3 9 2 NOTE_INSN_FUNCTION_BEG)
function.c:thread_prologue_and_epilogue_insns has code to fix up the order of
NOTE_INSN_FUNCTION_BEG and NOTE_INSN_FUNCTION_END notes for the epilogue, but
not for the prologue. We've found out in the meantime that it was the root
cause of Doug's problem and fixed it locally.
> Othogonal to this, there is the problem of what to do with these notes
> when instruction scheduling is enabled.
> [...]
> It isn't clear if this extra work is worthwhile.
Yes, the interaction with scheduling is another, more difficult problem. And
I don't think we really care about it for Doug's work.
Thanks for your feedback.
--
Eric Botcazou
Re: Bootstrap failure on trunk: x86_64-linux-gnu
[Sorry for the delay] > > That's an old problem, which has already been discussed IIRC: should > > TYPE_MAX_VALUE/TYPE_MIN_VALUE be constrained by TYPE_PRECISION and > > TYPE_UNSIGNED? > > My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should > represent the set of values that an object of the type may hold. > Any other definition effectively renders those values useless. > > ie, if an object can have the values 0..128 at runtime, then > TYPE_MIN_VALUE/TYPE_MAX_VALUE must cover that entire range. > 0..128. If TYPE_MIN_VALUE/TYPE_MAX_VALUE only cover 0..127, > then that's a bug. I was actually referring to explicit constraints on TYPE_MAX_VALUE and TYPE_MIN_VALUE derived from TYPE_PRECISION and TYPE_UNSIGNED, for example that ceil(log2(TYPE_MAX_VALUE - TYPE_MIN_VALUE)) must be greater or equal to TYPE_PRECISION. > I suspect we get this behavior from the Ada front-end as a > side effect of the language and possibly the need to do > runtime bounds checking on object values. But that's no > excuse for a front-end to lie about the bounds of an object. I don't think the Ada front-end lies about the bounds of types, but it does virtually use the whole spectrum of TYPE_PRECISION, TYPE_MAX_VALUE and TYPE_MIN_VALUE settings, unlike the C-family of front-ends. This problem was already raised when Diego contributed the VRP pass and Diego ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch. -- Eric Botcazou
Re: Segmentation fault in openmp simple routine from libgomp testsuite.
> I might be missing out on something but I get a segmentation fault when > manualy executing omp_hello.f from libgomp testsuite > (libgomp/testsuite/libgomp.fortran/omp_hello.f)... > > Compiled using gfortran -static -fopenmp -g omp_hello.f -o omp_hello Hum... for trunk on i686-linux, I do see the following. Dynamic linking works fine: $ gfortran -fopenmp omp_hello.f && OMP_NUM_THREADS=2 ./a.out Hello World from thread =0 Number of threads =2 Hello World from thread =1 Static linking fails: $ gfortran -fopenmp omp_hello.f -static /tmp/cc697VvU.o(.text+0x24): In function `MAIN__': omp_hello.f: undefined reference to `GOMP_parallel_start' /tmp/cc697VvU.o(.text+0x39):omp_hello.f: undefined reference to `GOMP_parallel_end' /tmp/cc697VvU.o(.text+0x49): In function `MAIN__.omp_fn.0': omp_hello.f: undefined reference to `omp_get_thread_num_' /tmp/cc697VvU.o(.text+0xe3):omp_hello.f: undefined reference to `omp_get_num_threads_' collect2: ld returned 1 exit status The reading of the libgomp.spec lead me to give it explicitly the needed libraries (although it shouldn't be necessary, I guess). But then, it segfaults: $ gfortran -fopenmp omp_hello.f -static -lgomp -lrt && OMP_NUM_THREADS=2 ./a.out zsh: segmentation fault OMP_NUM_THREADS=2 ./a.out And the backtrace is: Program received signal SIGSEGV, Segmentation fault. 0x08048466 in initialize_team () at ../../../gcc/libgomp/config/posix/sem.h:75 75 ../../../gcc/libgomp/config/posix/sem.h: No such file or directory. in ../../../gcc/libgomp/config/posix/sem.h (gdb) where #0 0x08048466 in initialize_team () at ../../../gcc/libgomp/config/posix/sem.h:75 #1 0x080aff5e in __do_global_ctors_aux () #2 0x08048109 in _init () #3 0x080613ed in __libc_csu_init () #4 0x08061138 in __libc_start_main () #5 0x08048141 in _start () PS: Some details on the static linking failure: Driving: gfortran -fopenmp omp_hello.f -static -v -lgfortranbegin -lgfortran -lm Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/cosmic/coudert/tmp/gfortran-20060228/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/cosmic/coudert/tmp/gfortran-20060228/gfortran_libs Thread model: posix gcc version 4.2.0 20060228 (experimental) /tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/4.2.0/f951 omp_hello.f -ffixed-form -quiet -dumpbase omp_hello.f -mtune=i386 -auxbase omp_hello -version -fopenmp -I /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/finclude -o /tmp/ccGKM8HT.s GNU F95 version 4.2.0 20060228 (experimental) (i386-linux) compiled by GNU C version 4.2.0 20060228 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/cc08jqIE.o /tmp/ccGKM8HT.s GNU assembler version 2.15.94.0.2.2 (i386-redhat-linux) using BFD version 2.15.94.0.2.2 20041220 Reading specs from /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/../../../libgomp.spec /tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/4.2.0/collect2 -m elf_i386 -static /usr/lib/crt1.o /usr/lib/crti.o /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/crtbeginT.o -lgomp -lrt -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0 -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/../../.. /tmp/cc08jqIE.o -lgfortranbegin -lgfortran -lm --start-group -lgcc -lgcc_eh -lpthread -lc --end-group /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/crtend.o /usr/lib/crtn.o /tmp/cc08jqIE.o(.text+0x24): In function `MAIN__': omp_hello.f: undefined reference to `GOMP_parallel_start' /tmp/cc08jqIE.o(.text+0x39):omp_hello.f: undefined reference to `GOMP_parallel_end' /tmp/cc08jqIE.o(.text+0x49): In function `MAIN__.omp_fn.0': omp_hello.f: undefined reference to `omp_get_thread_num_' /tmp/cc08jqIE.o(.text+0xe3):omp_hello.f: undefined reference to `omp_get_num_threads_' collect2: ld returned 1 exit status -- FX
Re: gnat -m31/-m32 broken on 64bit with gcc 4.x
Hi, > Ada currently does not have built-in support for multilibs (there's a related > PR I believe). #5911 I suppose. > Instead, it has another (similar but different) mechanism via the --RTS > make/compile/bind switch, which require manual build/install of several > gnatlib via calls to make -C gcc gnatlib with appropriate options. > > For instance to build a 64 bit run time with a 32 bits Solaris compiler: > > make -C gcc THREAD_KIND=m64 GNATLIBCFLAGS="-O2 -m64" gnatlib I've taken adalib and adainclude from a 31bit installation copied in the same dir as the 64bit versions under 32/. Compiling my example with --RTS=32 does the trick. Although this is not a final solution it is a good workaround - thanks. With a bit additional script hackery I hope to be able to bootstrap a 31bit gcc including ada support on a 64bit system. > Connecting this capability with the multilib mechanism would be nice although > nobody has done it so far (for either lack of interest or lack of knowledge > of the gcc makefiles), and there are non trivial issues since there are some > run-times that are supported by the Ada compiler (e.g. pthread run-time > on Solaris, the gnatlib-sjlj and gnatlib-zcx targets) that have no > corresponding multilib configuration, and vice-versa. > > Combining all the possibilities would simply create an explosion of run-time, > which is also not desirable. I believe you that this is not an easy job. Maybe it is eased a bit by the recent toplevel bootstrap changes?! Bye, -Andreas-
Re: gnat -m31/-m32 broken on 64bit with gcc 4.x
> I believe you that this is not an easy job. Maybe it is eased a bit by the > recent toplevel bootstrap changes?! I do not think so. The situation wrt multilib has not changed AFAIK. And in any case, this toplevel bootstrap change is still incomplete wrt Ada (missing passing flags to Ada Makefile) AFAIK, so the situation is currently (temporarily) worse. Arno
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On Tue, 2006-02-28 at 12:06 +0100, Eric Botcazou wrote: > [Sorry for the delay] No worries. > I was actually referring to explicit constraints on TYPE_MAX_VALUE and > TYPE_MIN_VALUE derived from TYPE_PRECISION and TYPE_UNSIGNED, for example > that ceil(log2(TYPE_MAX_VALUE - TYPE_MIN_VALUE)) must be greater or equal to > TYPE_PRECISION. OK. > > I suspect we get this behavior from the Ada front-end as a > > side effect of the language and possibly the need to do > > runtime bounds checking on object values. But that's no > > excuse for a front-end to lie about the bounds of an object. > > I don't think the Ada front-end lies about the bounds of types, but it does > virtually use the whole spectrum of TYPE_PRECISION, TYPE_MAX_VALUE and > TYPE_MIN_VALUE settings, unlike the C-family of front-ends. > > This problem was already raised when Diego contributed the VRP pass and Diego > ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch. And IMHO the work-arond in VRP is a hack around this braindamage. Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE effectively makes them useless as we can not rely on them to actually reflect the set of values allowed in an object. jeff
Re: Bootstrap failure on trunk: x86_64-linux-gnu
Eric Botcazou wrote: > This problem was already raised when Diego contributed the VRP pass and Diego > ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch. > Which doesn't mean that Ada is DTRT. On the contrary, Ada ought to be fixed. It's an ugly hack in extract_range_from_assert: /* Special handling for integral types with super-types. Some FEs construct integral types derived from other types and restrict the range of values these new types may take. It may happen that LIMIT is actually smaller than TYPE's minimum value. For instance, the Ada FE is generating code like this during bootstrap: D.1480_32 = nam_30 - 30361; if (D.1480_32 <= 1) goto ; else goto ; :; D.1480_94 = ASSERT_EXPR ; All the names are of type types__name_id___XDLU_3__3 which has min == 3 and max == 3. This means that the ASSERT_EXPR would try to create the range [300, 1] which is invalid. The fact that the type specifies MIN and MAX values does not automatically mean that every variable of that type will always be within that range, so the predicate may well be true at run time. If we had symbolic -INF and +INF values, we could represent this range, but we currently represent -INF and +INF using the type's min and max values. So, the only sensible thing we can do for now is set the resulting range to VR_VARYING. TODO, would having symbolic -INF and +INF values be worth the trouble? */ BTW, the answer to that 'TODO' question is 'no'. I briefly toyed with that idea, but it is much more convenient to use TYPE_MAX_VALUE and TYPE_MIN_VALUE. Otherwise, arithmetic on +INF and -INF becomes unpleasant.
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On 2/28/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > Eric Botcazou wrote: > > > This problem was already raised when Diego contributed the VRP pass and > > Diego > > ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch. > > > Which doesn't mean that Ada is DTRT. On the contrary, Ada ought to be > fixed. It's an ugly hack in extract_range_from_assert: > > /* Special handling for integral types with super-types. Some FEs > construct integral types derived from other types and restrict > the range of values these new types may take. > > It may happen that LIMIT is actually smaller than TYPE's minimum > value. For instance, the Ada FE is generating code like this > during bootstrap: > > D.1480_32 = nam_30 - 30361; > if (D.1480_32 <= 1) goto ; else goto ; > :; > D.1480_94 = ASSERT_EXPR ; > > All the names are of type types__name_id___XDLU_3__3 > which has min == 3 and max == 3. This means that > the ASSERT_EXPR would try to create the range [300, 1] which > is invalid. My understanding of Ada is that the above is not (or should not be) what the frontend generates, but D.1480_32 = nam_30 - 30361; should be carried out in the base type, as should the comparison be. It would be interesting to have a testcase that exposes the above behavior and hunt for the place where things start to go wrong. So correct should be D. = (base_type)nam_30; D.1480_32 = D. - 30361; and D.1480 of type base_type. Just papering over latent bugs isn't the way to go here - rather break Ada, so it (or whatever gets it wrong) gets fixed. Richard.
Inconsistency in ix86_binary_operator_ok?
I've a IA-32 backend question on the intended behaviour of the functions
ix86_binary_operator_ok and ix86_fixup_binary_operands.
My confusion is that these functions currently allow arithmetic
operations of the form "reg = op(mem,immed)" even though this
shape isn't supported by x86 ISA. For example, the following
simple test code,
int foo(int x)
{
return x | 4;
}
generates the following RTL in combine:
(insn 11 4 16 0 (parallel [
(set (reg:SI 60)
(ior:SI (mem/f:SI (reg/f:SI 16 argp) [2 x+0 S4 A32])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) 209 {*iorsi_1} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
which is then later fixed up by postreload.
My first question is whether this is intentional or an oversight?
The reason I ask/noticed this was that I'm working on a RTL patch to
canonicalize shifts vs. arithmetic operations, such that we always
perform the shift first. This should be a big win on ARM, but will
also allow us to simplify code such as:
x ^= 8;
x >>= 2;
x ^= 1;
where by reordering the arithmetic operations relative to the
shifts, we can catch more simplifications in combine.
The catch is that currently i386.md allows combine to first
combine commutative arithmetic operations with memory, creating
reg = xor(mem,8); reg = rshift(reg,2), but then inconsistently
won't allow a memory as the first operand in the non-commutative
shift operation, i.e. we're not allowed to create reg = rshift(mem,2).
Clearly there's an inconsistency. So the options include to either
allow reg = op(mem,immed) for non-commutative operators to also be
fixed by postreload, if the current behaviour is intentional and serves
some useful purpose, or alternatively to change ix86_binary_operator_ok
so that we only allow valid instructions at this point.
Many thanks in advance,
Roger
--
Re: Bootstrap failure on trunk: x86_64-linux-gnu
> Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE > effectively makes them useless as we can not rely on them to > actually reflect the set of values allowed in an object. Sorry, but why are you saying "we can not rely on them to actually reflect the set of values allowed in an object"? I think we can. My understanding is that the only subtlety with Ada is the TYPE_PRECISION thing, as you've written in your patch: + /* Ada creates sub-types where TYPE_MIN_VALUE/TYPE_MAX_VALUE do not + cover the entire range of values allowed by TYPE_PRECISION. + + We do not want to optimize away conversions to such types. Long + term I'd rather see the Ada front-end fixed. */ The obvious question would then be, why bother with TYPE_MIN_VALUE and TYPE_MAX_VALUE if they can be directly deduced from TYPE_PRECISION and TYPE_UNSIGNED? How do you represent subtypes with non-canonical bounds? -- Eric Botcazou
Re: Bootstrap failure on trunk: x86_64-linux-gnu
> It's an ugly hack in extract_range_from_assert: > > /* Special handling for integral types with super-types. Some FEs > construct integral types derived from other types and restrict > the range of values these new types may take. > > It may happen that LIMIT is actually smaller than TYPE's minimum > value. For instance, the Ada FE is generating code like this > during bootstrap: > > D.1480_32 = nam_30 - 30361; > if (D.1480_32 <= 1) goto ; else goto ; > :; > D.1480_94 = ASSERT_EXPR ; > > All the names are of type types__name_id___XDLU_3__3 > which has min == 3 and max == 3. This means that > the ASSERT_EXPR would try to create the range [300, 1] which > is invalid. > > The fact that the type specifies MIN and MAX values does not > automatically mean that every variable of that type will always > be within that range, so the predicate may well be true at run > time. If we had symbolic -INF and +INF values, we could > represent this range, but we currently represent -INF and +INF > using the type's min and max values. > > So, the only sensible thing we can do for now is set the > resulting range to VR_VARYING. TODO, would having symbolic -INF > and +INF values be worth the trouble? */ I think we would need to clarify that, because I'm not sure the Ada front-end directly generates: D.1480_32 = nam_30 - 30361; if (D.1480_32 <= 1) goto ; else goto ; :; D.1480_94 = ASSERT_EXPR ; -- Eric Botcazou
4.1.0-RC{1,2} installs headers to /include
Hi all,
in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include directory:
# cut -f 2- fl_wrapper.wlog | grep '^\/include\/' | cut -d / -f 1-4 | uniq
/include/c++
/include/c++/gcj
/include/c++/gnu
/include/c++/java
/include/c++/javax
/include/c++/org
/include/c++/java
/include/c++/gnu
/include/c++/gcj
/include/c++/gnu
/include/c++/java
/include/c++/javax
/include/c++/org
/include/c++/java
/include/c++/gnu
I hope the recently discussed change in the thread "GCC-4.1.x include/ssp/*.h"
already fix those ...
configure arguments have been:
--prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib64 \
--datadir=/usr/share --includedir=/usr/include --infodir=/usr/info \
--mandir=/usr/man --sysconfdir=/etc --localstatedir=/var \
--build=x86_64-t2-linux-gnu --host=x86_64-t2-linux-gnu \
--enable-__cxa_atexit --disable-checking --enable-multilib \
--with-gnu-as --with-gnu-ld --enable-threads=posix \
--enable-version-specific-runtime-libs --enable-libgcj --enable-shared
(autogenerated and thus a bit long ,-)
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de | http://www.t2-project.org
+49 (0)30 255 897 45
Re: 4.1.0-RC{1,2} installs headers to /include
René Rebe wrote:
> Hi all,
>
> in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include
> directory:
Are you sure? The log you show is presumably from your build log; have
you verified that this is where the files are placed in the filesystem?
> --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib64 \
> --datadir=/usr/share --includedir=/usr/include --infodir=/usr/info \
> --mandir=/usr/man --sysconfdir=/etc --localstatedir=/var \
> --build=x86_64-t2-linux-gnu --host=x86_64-t2-linux-gnu \
> --enable-__cxa_atexit --disable-checking --enable-multilib \
> --with-gnu-as --with-gnu-ld --enable-threads=posix \
> --enable-version-specific-runtime-libs --enable-libgcj --enable-shared
Certainly, based on that, we would hope the headers in question would
end up in /usr/include/c++. I have not personally tested all of the
header switches, but I have verified that the headers end up in
$prefix/include/c++ for me. The SSP patch I applied yesterday will have
no affect on this situation, as it applied only to the libssp headers.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: 4.1.0-RC{1,2} installs headers to /include
Hi,
On Tuesday 28 February 2006 19:50, Mark Mitchell wrote:
> René Rebe wrote:
> > Hi all,
> >
> > in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include
> > directory:
>
> Are you sure? The log you show is presumably from your build log; have
> you verified that this is where the files are placed in the filesystem?
Yes, since the path is absolute and not something from within the build.
The log further reveals:
...
install -c -m 644 javax/swing/JFormattedTextField.h
/include/c++/javax/swing/JFormattedTextField.h
...
> > --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib64 \
> > --datadir=/usr/share --includedir=/usr/include --infodir=/usr/info \
> > --mandir=/usr/man --sysconfdir=/etc --localstatedir=/var \
> > --build=x86_64-t2-linux-gnu --host=x86_64-t2-linux-gnu \
> > --enable-__cxa_atexit --disable-checking --enable-multilib \
> > --with-gnu-as --with-gnu-ld --enable-threads=posix \
> > --enable-version-specific-runtime-libs --enable-libgcj --enable-shared
>
> Certainly, based on that, we would hope the headers in question would
> end up in /usr/include/c++. I have not personally tested all of the
> header switches, but I have verified that the headers end up in
> $prefix/include/c++ for me. The SSP patch I applied yesterday will have
> no affect on this situation, as it applied only to the libssp headers.
Yes.
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de | http://www.t2-project.org
+49 (0)30 255 897 45
Re: 4.1.0-RC{1,2} installs headers to /include
René Rebe wrote:
> Hi,
>
> On Tuesday 28 February 2006 19:50, Mark Mitchell wrote:
>> René Rebe wrote:
>>> Hi all,
>>>
>>> in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include
>>> directory:
>> Are you sure? The log you show is presumably from your build log; have
>> you verified that this is where the files are placed in the filesystem?
>
> Yes, since the path is absolute and not something from within the build.
>
> The log further reveals:
>
> ...
> install -c -m 644 javax/swing/JFormattedTextField.h
> /include/c++/javax/swing/JFormattedTextField.h
It's too late to fix this for 4.1.0, but it's not too late for me to
include information in the release announcement. If you look in
$objdir/libjava/Makefile, what is the value of gxx_include_dir? I'm
assuming it's empty. If you add "--with-gxx-include-dir=/usr/include"
to your configury does that help?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: 4.1.0-RC{1,2} installs headers to /include
Hi again, On Tuesday 28 February 2006 20:19, Mark Mitchell wrote: > It's too late to fix this for 4.1.0, but it's not too late for me to > include information in the release announcement. If you look in > $objdir/libjava/Makefile, what is the value of gxx_include_dir? I'm > assuming it's empty. If you add "--with-gxx-include-dir=/usr/include" > to your configury does that help? In x86_64-t2-linux-gnu/libjava/Makefile I have: gxx_include_dir = $(libsubdir)/include/c++ Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45
Should gcc generate ELF type info for undefined symbol?
The current gcc only generates ELF type info for undefined symbol for
HPUX. This information is useful for linker to detect possible run-time
problems at link-time. Here is an example:
[EMAIL PROTECTED] mismatch]$ cat foo.c
#include
extern void bar (void);
int times;
int
main ()
{
printf ("times: %d\n", times);
bar ();
return 0;
}
[EMAIL PROTECTED] mismatch]$ cat bar.c
#include
#include
void
bar (void)
{
struct tms buf;
clock_t ticks = times (&buf);
printf ("Ticks: %ld\n", (long) ticks);
}
[EMAIL PROTECTED] mismatch]$ make
gcc -O -g -c -o foo.o foo.c
gcc -O -g -fPIC -c -o bar.o bar.c
gcc -o libbar.so -shared bar.o
gcc -o foo foo.o libbar.so -Wl,-rpath,.
./foo
times: 0
make: *** [all] Segmentation fault
If linker knows "times" referenced by libbar.so is a function, it can
avoid the run-time problem.
H.J.
Re: 4.1.0-RC{1,2} installs headers to /include
René Rebe wrote: > gxx_include_dir = $(libsubdir)/include/c++ That's the problem, then; there's no definition of libsubdir in that Makefile. What happens if you provide the explicit --with-gxx-include-dir option? I'm not sure when this was broken, but clearly the Java Makefile.am is incorrect; users of TL_AC_GXX_INCLUDE_DIR must define libsubdir. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Ada subtypes and base types
On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote: > Jeffrey A Law wrote: > > My suspicions appear to be correct. This never triggers except for > > Ada code and it's relatively common in Ada code. No surprise since > > I don't think any other front-end abuses TYPE_MAX_VALUE in the way > > the Ada front-end does. This wouldn't be the first time we've had > > to hack up something in the generic optimizers to deal with the > > broken TYPE_MAX_VALUE. > > What do you mean by "abuse"? I'd like to know too :). Both Pascal and Ada came up with the same representation of ranged types to the back-end, if anything else should be used, by all mean let us know the proposal. Laurent > TYPE_MAX_VALUE means maximal value > allowed by given type. For range types it is clearily the upper > bound of the range. Of course, upper bound should be representable, > so TYPE_MAX_VALUE <= (2**TYPE_PRECISION - 1) for unsigned types > and TYPE_MAX_VALUE <= (2**(TYPE_PRECISION - 1) - 1) for signed types. > However, if the language has non-trivial range types you can expect > strict inequality. Note, that if you do not allow strict inequality > above, TYPE_MAX_VALUE would be redundant. > > FYI GNU Pascal is using such representation for range types, so for > example: > > type t = 0..5; > > will give you TYPE_PRECISION equal to 32 (this is an old decision > which tries to increase speed at the cost of space, otherwise 8 > would be enough) and TYPE_MAX_VALUE equal to 5. > > GNU Pascal promotes arguments of operators, so that arithmetic take > place in "standard" types -- I belive Ada is doing the same. > > BTW, setting TYPE_PRECISION to 3 for the type above used to cause > wrong code, so the way above was forced by the backend. > > If you think that such behaviour is "abuse" then why to have sparate > TYPE_MAX_VALUE. How to represent range types so that optimizers > will know about allowed ranges (and use them!)? And how about debug > info? >
makeinfo version required (was: define_constraints patch, re-revised)
[ gcc-patches -> gcc ] On Tue, 28 Feb 2006, Mark Mitchell wrote: >> That said, I guess it's fine to ignore the ones with makeinfo 4.5, >> but based on my checks I'd be rather hesitant for us to require >> anything later than 4.6. > I don't think we should tie our own hands in this way. Building GCC > requires lots of tools; so be it. We could always have a check that > avoids building the documentation for old makeinfo. That would cause all sorts of problems for users of the BSD Ports Collections, to just give an example. That said, I don't really disagree about enforcing proper prerequisites to build GCC and its documentation, my question in this case, and in general, just is: Can the issue which we encountered be worked around in a simple way in our .texi sources, or is it important enough to warrant ramping up our requirements? (I don't know which is the case here, I just feel we shouldn't ramp up our requirements too readily.) Gerald
Re: 4.1.0-RC{1,2} installs headers to /include
Hi, On Tuesday 28 February 2006 20:54, Mark Mitchell wrote: > > gxx_include_dir = $(libsubdir)/include/c++ > > That's the problem, then; there's no definition of libsubdir in that > Makefile. What happens if you provide the explicit > --with-gxx-include-dir option? > > I'm not sure when this was broken, but clearly the Java Makefile.am is > incorrect; users of TL_AC_GXX_INCLUDE_DIR must define libsubdir. Yes, then it is: gxx_include_dir = /usr/include Though despite ccache and a Turion with 1.2GB RAM I'm still waiting for "make instal" and the list of installed files ,-) Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45
gcc-3.4-20060228 is now available
Snapshot gcc-3.4-20060228 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060228/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch revision 111581 You'll find: gcc-3.4-20060228.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20060228.tar.bz2 C front end and core compiler gcc-ada-3.4-20060228.tar.bz2 Ada front end and runtime gcc-g++-3.4-20060228.tar.bz2 C++ front end and runtime gcc-g77-3.4-20060228.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20060228.tar.bz2 Java front end and runtime gcc-objc-3.4-20060228.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20060228.tar.bz2The GCC testsuite Diffs from 3.4-20060221 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On Tue, 2006-02-28 at 18:42 +0100, Eric Botcazou wrote: > > Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE > > effectively makes them useless as we can not rely on them to > > actually reflect the set of values allowed in an object. > > Sorry, but why are you saying "we can not rely on them to actually reflect > the > set of values allowed in an object"? I think we can. My understanding is > that the only subtlety with Ada is the TYPE_PRECISION thing, as you've > written in your patch: Here's a great example from uintp.adb (which is the cause of the testsuite hang FWIW) We have a loop with the following termination code in uintp.num_bits # BLOCK 8 # PRED: 5 [100.0%] (fallthru,exec) 6 (fallthru,dfs_back,exec) # num_2 = PHI ; # bits_1 = PHI ; :; num.265_5 = (types__TintB) num_2; if (num.265_5 <= 0) goto ; else goto ; # SUCC: 7 (true,exec) 6 (false,exec) num_2 has the type: unit size user align 32 symtab 1074169056 alias set 8 precision 32 min max RM size > sizes-gimplified asm_written public visited unsigned SI size unit size user align 32 symtab 1080625184 alias set 8 precision 32 min max RM size constant invariant 31>> Note carefully, it has a min/max value of 0, 21474833647. So not surprisingly we have a range of [0, INF] recorded for num_2. So given the range [0, INF] and the test num_5 <= 0 we can (and do) simplify the test to num_5 == 0. So, why am I bringing this up? Because num can actually have the value 0x8000 at runtime, which is out of its type's MIN/MAX range. And what do you think happens? Well, given the (valid) simplification of the loop test and the way "num" is assigned within the loop (num = num / 2), the loop never terminates. How do we get the value 0x8000 into "num"? Let's look at the first two blocks in our function: # BLOCK 2 # PRED: ENTRY (fallthru,exec) # uintp__uints__table_41 = V_MAY_DEF ; # uintp__udigits__table_42 = V_MAY_DEF ; # TMT.2002_43 = V_MAY_DEF ; # TMT.2003_44 = V_MAY_DEF ; D.2350_4 = uintp__ui_is_in_int_range (input_3); if (D.2350_4 != 0) goto ; else goto ; # SUCC: 3 (true,exec) 4 (false,exec) # BLOCK 3 # PRED: 2 (true,exec) :; # uintp__uints__table_45 = V_MAY_DEF ; # uintp__udigits__table_46 = V_MAY_DEF ; # TMT.2002_47 = V_MAY_DEF ; # TMT.2003_48 = V_MAY_DEF ; D.2351_34 = uintp__ui_to_int (input_3); D.2352_35 = (types__TintB) D.2351_34; D.2353_36 = ABS_EXPR ; num_37 = (types__nat___XDLU_0__2147483647) D.2353_36; goto (); # SUCC: 5 (fallthru,exec) Let's assume that uintp__ui_is_int_range returns true (as it does) for our input (27). uintp__ui_to_int returns 0x8000 [For you non-Ada folks, uintp__ui_to_int doesn't do what you might initially think]. And ABS (0x8000) is 0x8000 which we then proceed to stuff into num_37 after a couple typecasts. Voila, we have a value in a variable that is out of the MIN/MAX range associated with the variable. > + /* Ada creates sub-types where TYPE_MIN_VALUE/TYPE_MAX_VALUE do not > + cover the entire range of values allowed by TYPE_PRECISION. > + > + We do not want to optimize away conversions to such types. Long > + term I'd rather see the Ada front-end fixed. */ > > The obvious question would then be, why bother with TYPE_MIN_VALUE and > TYPE_MAX_VALUE if they can be directly deduced from TYPE_PRECISION and > TYPE_UNSIGNED? How do you represent subtypes with non-canonical bounds? I wouldn't have a problem with non-canonical bounds if there were no way to get a value into an object which is outside the bounds. But if we can get values into the object which are outside those bounds, then either the bounds are incorrect or the program is invalid. Jeff
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On Tue, 2006-02-28 at 18:50 +0100, Eric Botcazou wrote: > > It's an ugly hack in extract_range_from_assert: > > > > /* Special handling for integral types with super-types. Some FEs > > construct integral types derived from other types and restrict > > the range of values these new types may take. > > > > It may happen that LIMIT is actually smaller than TYPE's minimum > > value. For instance, the Ada FE is generating code like this > > during bootstrap: > > > > D.1480_32 = nam_30 - 30361; > > if (D.1480_32 <= 1) goto ; else goto ; > > :; > > D.1480_94 = ASSERT_EXPR ; > > > > All the names are of type types__name_id___XDLU_3__3 > > which has min == 3 and max == 3. This means that > > the ASSERT_EXPR would try to create the range [300, 1] which > > is invalid. > > > > The fact that the type specifies MIN and MAX values does not > > automatically mean that every variable of that type will always > > be within that range, so the predicate may well be true at run > > time. If we had symbolic -INF and +INF values, we could > > represent this range, but we currently represent -INF and +INF > > using the type's min and max values. > > > > So, the only sensible thing we can do for now is set the > > resulting range to VR_VARYING. TODO, would having symbolic -INF > > and +INF values be worth the trouble? */ > > I think we would need to clarify that, because I'm not sure the Ada front-end > directly generates: > > D.1480_32 = nam_30 - 30361; > if (D.1480_32 <= 1) goto ; else goto ; > :; > D.1480_94 = ASSERT_EXPR ; This one is probably worth tracking down -- if the Ada front-end actually created this kind of code, then it would be a bug. Similarly if we originally had the proper typecasts and they were later eliminated, then that would be a bug in the optimizers. Diego -- do you recall what code actually triggered this problem? jeff
Re: Bootstrap failure on trunk: x86_64-linux-gnu
Jeffrey A Law wrote: > Diego -- do you recall what code actually triggered this problem? > Not sure, exactly. However, in figuring out what this code was working around, I remembered this thread from Kenner where he fixed this particular FE bug: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01347.html In that same thread I found a follow up from me promising to remove this code for 4.2. I, of course, forgot. *blush*. So, it seems that we don't actually need this ugliness anymore. I will test a patch removing this code now. Should I expect Ada to work with mainline, atm? Thanks.
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On Tue, 2006-02-28 at 17:51 -0500, Diego Novillo wrote: > Jeffrey A Law wrote: > > > Diego -- do you recall what code actually triggered this problem? > > > Not sure, exactly. > > However, in figuring out what this code was working around, I remembered > this thread from Kenner where he fixed this particular FE bug: > http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01347.html > > In that same thread I found a follow up from me promising to remove this > code for 4.2. I, of course, forgot. *blush*. Opps :-) > So, it seems that we don't actually need this ugliness anymore. I will > test a patch removing this code now. Should I expect Ada to work with > mainline, atm? You'll get a hang in the Ada testsuite as well as a handful of failures. But it should bootstrap and you can get meaningful before/after testresults as long as you kill gnat1 when it hands on the one test (don't remember its name offhand). jeff
Re: Segmentation fault in openmp simple routine from libgomp testsuite.
Should I file a bug ? I think it might be better to wait for the opinion of the gomp maintainers, as I'm fairly new to that stuff and could have missed something important. Jakuk, Diego? Is this a bug or a feature? :) Hum... for trunk on i686-linux, I do see the following. Dynamic linking works fine: $ gfortran -fopenmp omp_hello.f && OMP_NUM_THREADS=2 ./a.out Hello World from thread =0 Number of threads =2 Hello World from thread =1 Static linking fails: $ gfortran -fopenmp omp_hello.f -static /tmp/cc697VvU.o(.text+0x24): In function `MAIN__': omp_hello.f: undefined reference to `GOMP_parallel_start' /tmp/cc697VvU.o(.text+0x39):omp_hello.f: undefined reference to `GOMP_parallel_end' /tmp/cc697VvU.o(.text+0x49): In function `MAIN__.omp_fn.0': omp_hello.f: undefined reference to `omp_get_thread_num_' /tmp/cc697VvU.o(.text+0xe3):omp_hello.f: undefined reference to `omp_get_num_threads_' collect2: ld returned 1 exit status The reading of the libgomp.spec lead me to give it explicitly the needed libraries (although it shouldn't be necessary, I guess). But then, it segfaults: $ gfortran -fopenmp omp_hello.f -static -lgomp -lrt && OMP_NUM_THREADS=2 ./a.out zsh: segmentation fault OMP_NUM_THREADS=2 ./a.out And the backtrace is: Program received signal SIGSEGV, Segmentation fault. 0x08048466 in initialize_team () at ../../../gcc/libgomp/config/posix/sem.h:75 75 ../../../gcc/libgomp/config/posix/sem.h: No such file or directory. in ../../../gcc/libgomp/config/posix/sem.h (gdb) where #0 0x08048466 in initialize_team () at ../../../gcc/libgomp/config/posix/sem.h:75 #1 0x080aff5e in __do_global_ctors_aux () #2 0x08048109 in _init () #3 0x080613ed in __libc_csu_init () #4 0x08061138 in __libc_start_main () #5 0x08048141 in _start () PS: Some details on the static linking failure: Driving: gfortran -fopenmp omp_hello.f -static -v -lgfortranbegin -lgfortran -lm Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/cosmic/coudert/tmp/gfortran-20060228/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/cosmic/coudert/tmp/gfortran-20060228/gfortran_libs Thread model: posix gcc version 4.2.0 20060228 (experimental) /tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/ 4.2.0/f951 omp_hello.f -ffixed-form -quiet -dumpbase omp_hello.f -mtune=i386 -auxbase omp_hello -version -fopenmp -I /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 4.2.0/finclude -o /tmp/ccGKM8HT.s GNU F95 version 4.2.0 20060228 (experimental) (i386-linux) compiled by GNU C version 4.2.0 20060228 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/cc08jqIE.o /tmp/ccGKM8HT.s GNU assembler version 2.15.94.0.2.2 (i386-redhat-linux) using BFD version 2.15.94.0.2.2 20041220 Reading specs from /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 4.2.0/../../../libgomp.spec /tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/ 4.2.0/collect2 -m elf_i386 -static /usr/lib/crt1.o /usr/lib/crti.o /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 4.2.0/crtbeginT.o -lgomp -lrt -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 4.2.0 -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 4.2.0/../../.. /tmp/cc08jqIE.o -lgfortranbegin -lgfortran -lm --start-group -lgcc -lgcc_eh -lpthread -lc --end-group /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 4.2.0/crtend.o /usr/lib/crtn.o /tmp/cc08jqIE.o(.text+0x24): In function `MAIN__': omp_hello.f: undefined reference to `GOMP_parallel_start' /tmp/cc08jqIE.o(.text+0x39):omp_hello.f: undefined reference to `GOMP_parallel_end' /tmp/cc08jqIE.o(.text+0x49): In function `MAIN__.omp_fn.0': omp_hello.f: undefined reference to `omp_get_thread_num_' /tmp/cc08jqIE.o(.text+0xe3):omp_hello.f: undefined reference to `omp_get_num_threads_' collect2: ld returned 1 exit status
Re: GCC 4.1 RC2 available
> GCC 4.1 RC2 is now available from: > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060223 Still OK on SPARC/Solaris: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01558.html http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01557.html http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01556.html http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01555.html http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01554.html http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01553.html No regressions from 4.0.x, except several libjava failures with the Sun tools (not present with the GNU tools), probably an assembler problem/limitation. -- Eric Botcazou
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On Tue, Feb 28, 2006 at 03:40:37PM -0700, Jeffrey A Law wrote: > Here's a great example from uintp.adb (which is the cause of the > testsuite hang FWIW) > > We have a loop with the following termination code in uintp.num_bits > > # BLOCK 8 > # PRED: 5 [100.0%] (fallthru,exec) 6 (fallthru,dfs_back,exec) > # num_2 = PHI ; > # bits_1 = PHI ; > :; > num.265_5 = (types__TintB) num_2; > if (num.265_5 <= 0) goto ; else goto ; > # SUCC: 7 (true,exec) 6 (false,exec) ... > So, why am I bringing this up? Because num can actually have > the value 0x8000 at runtime, which is out of its type's > MIN/MAX range. And what do you think happens? Well, given the > (valid) simplification of the loop test and the way "num" is > assigned within the loop (num = num / 2), the loop never terminates. I've been following this entire thread, and I think there's a serious disconnect between the parties - it's unfortunate that none of the tree-ssa folks involved know Ada as I suspect that would straighten it out in a hurry. This is a perfect example. Now that we have some concrete code that's causing a problem, let's take a look at it (bear in mind, I don't know Ada either): function Num_Bits (Input : Uint) return Nat is Bits : Nat; Num : Nat; begin if UI_Is_In_Int_Range (Input) then Num := abs (UI_To_Int (Input)); Bits := 0; else Bits := Base_Bits * (Uints.Table (Input).Length - 1); Num := abs (Udigits.Table (Uints.Table (Input).Loc)); end if; while Types.">" (Num, 0) loop Num := Num / 2; Bits := Bits + 1; end loop; return Bits; end Num_Bits; I'm going to assume that UI_Is_In_Int_Range isn't true for 0x8000. The other case is still assigning 0x8000 to Nat somehow. I'd be amazed if that's really valid Ada! Could someone who knows the language comment, please? > I wouldn't have a problem with non-canonical bounds if there were > no way to get a value into an object which is outside the > bounds. But if we can get values into the object which are outside > those bounds, then either the bounds are incorrect or the program > is invalid. Ignoring 'Valid, which folks agreed to do earlier, I think everyone agrees with this statement - which is why I suspect that there's something wrong with Num_Bits. -- Daniel Jacobowitz CodeSourcery
Re: GCC-4.1.x include/ssl/*.h ??
Mark Mitchell wrote: > This will be the final patch for GCC 4.1.0. I plan to work through the > release checklist tonight. As always, the official announcement will > follow after the release has had time to make it to the mirrors. Just a word of warning about this patch for unsuspecting travellers. It appears to be parallel make unfriendly. (GNU Make 3.80) i.e. running the following command on a dual cpu system results in a missing `/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include/ssp' directory and no ssp headers. make install -j3 No errors, no nothing. Weird.. It's 100% reproducible here. Remove the -j3 and all is well. I suppose most folks never run `make install' in parallel.. but sometimes it's convenient to just simply: export MAKEFLAGS=-j3 for big compile jobs. Regards Greg -- http://www.diy-linux.org/
Libjava (gij) testting on the mainline
With clean sources on x86_64-linux-gnu, I am getting almost all tests for running gij to fail. Does anyone know what is going on here? Thanks, Andrew Pinski
Re: Bootstrap failure on trunk: x86_64-linux-gnu
Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE
effectively makes them useless as we can not rely on them to
actually reflect the set of values allowed in an object.
As we've all told you numerous times before, TYPE_MIN_VALUE/TYPE_MAX_VALUE
are meant *precisely* to refect the set of valid values in an object.
("valid" is a technical term in Ada, while "allowed" is vague, so I'm
using the former term).
Re: Bootstrap failure on trunk: x86_64-linux-gnu
Which doesn't mean that Ada is DTRT. On the contrary, Ada ought to be fixed. It's an ugly hack in extract_range_from_assert: It wasn't a bug in the Ada front end, but in fold, which was long-ago fixed. I thought this was removed a long time ago?
Re: Bootstrap failure on trunk: x86_64-linux-gnu
We have a loop with the following termination code in uintp.num_bits This sure looks like a bug in Num_Bits to me, not in the compilation of the front-end. The relevant code is: function Num_Bits (Input : Uint) return Nat is Bits : Nat; Num : Nat; begin if UI_Is_In_Int_Range (Input) then Num := abs (UI_To_Int (Input)); Bits := 0; This code only works for one-complement machines, since it assumes a symmetric range for Int. It breaks when UI_To_Int returns Integer'First, as it did in this case. When it does, the abs produces an erroneous result (since checking is disabled). So it almost doesn't matter what it puts into Num (but it actually puts in an out-of-range value there too). Robert, what's the proper fix here?
iWMMXt/Linux EABI toolchain
Hi! I'm attempting to build a iWMMXt/Linux EABI toolchain using gcc HEAD. I'm using the target xscale-iwmmxt-linux-gnueabi, I've added support for this target to binutils and built a cross linker etc. I've proceeded to add a suitable target in config.gcc which supports EABI, xscale and Linux basing it on the existing arm/linux target and replacing the linux-elf.h file with a modified one based on xscale-elf.h which I've called xscale-linux-elf.h. I then attempted to build a stage1 compiler with "--with-abi=iwmmxt --with-cpu=iwmmxt --with-arch=iwmmxt", but as soon as the build tries to run xgcc I get the error below. It looks like it's getting the types wrong, but I'm very new to GCC internals and I'm not sure where to look. /var/tmp/portage/gcc-4.2.0_alpha20060225/work/build/./gcc/xgcc -B/var/tmp/portage/gcc-4.2.0_alpha20060225/work/build/./gcc/ -B/usr/xscale-iwmmxt-linux-gnueabi/bin/ -B/usr/xscale-iwmmxt-linux-gnueabi/lib/ -isystem /usr/xscale-iwmmxt-linux-gnueabi/include -isystem /usr/xscale-iwmmxt-linux-gnueabi/sys-include -O2 -O2 -O2 -pipe -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/. -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/../include -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/../libcpp/include -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -Dinhibit_libc \ -c /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from ./tm.h:17, from /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c:70: /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/config/arm/arm.h:108: warning: integer constant is too large for 'long' type ... snip repetition /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c:206: warning: integer constant is too large for 'long' type /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c:207: error: requested alignment is too large /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c:234: warning: integer constant is too large for 'long' type ... Steve ___ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com
update_stmt calls
Hello, during a recent discussion, it was pointed to my attention that update_stmt is performance critical. I wondered why; this is the number of update_stmt calls for combine.i (all the other passes have less then 1000 calls): tree VRP : 17543 (10%) tree copy propagation : 3210 ( 2%) tree alias analysis : 113845 (67%) tree SSA other: 20824 (12%) dominator optimization: 1411 ( 1%) tree split crit edges : 3122 ( 2%) tree FRE : 2060 ( 1%) expand: 5703 ( 3%) TOTAL : 170549 I have a patch that decreases number of update_stmt calls in tree alias analysis to 46525; still, is it really that useful to run pass_may_alias *six* times during compilation? Obviously, we need the initial one, and there are comments after pass_sra and pass_fold_builtins that indicate that the following pass_may_alias cannot be avoided (which seems doubtful to me, at the very least in the later case), but the remaining three seem to be just placed randomly. I also have a patch that decreases the number of update_stmt calls in VRP to 5229 (which is more or less the number of ASSERT_EXPRs it creates, so this cannot be improved significantly). Zdenek
Re: iWMMXt/Linux EABI toolchain
On Wed, Mar 01, 2006 at 04:27:48AM +, Steven Newbury wrote: > Hi! I'm attempting to build a iWMMXt/Linux EABI toolchain using gcc HEAD. I'm > using the target xscale-iwmmxt-linux-gnueabi, I've added support for this > target to binutils and built a cross linker etc. > > I've proceeded to add a suitable target in config.gcc which supports EABI, > xscale and Linux basing it on the existing arm/linux target and replacing the > linux-elf.h file with a modified one based on xscale-elf.h which I've called > xscale-linux-elf.h. > > I then attempted to build a stage1 compiler with "--with-abi=iwmmxt > --with-cpu=iwmmxt --with-arch=iwmmxt", but as soon as the build tries to run > xgcc I get the error below. It looks like it's getting the types wrong, but > I'm very new to GCC internals and I'm not sure where to look. Try just using arm-none-linux-gnueabi and --with-cpu=iwmmxt --with-arch=iwmmxt; you almost certainly do not want --with-abi=iwmmxt. The error you gave suggests that you didn't modify something properly to handle the xscale-linux-gnueabi target, but arm would work just fine. -- Daniel Jacobowitz CodeSourcery
Re: update_stmt calls
On Feb 28, 2006, at 11:31 PM, Zdenek Dvorak wrote: I have a patch that decreases number of update_stmt calls in tree alias analysis to 46525; still, is it really that useful to run pass_may_alias *six* times during compilation? Obviously, we need the initial one, and there are comments after pass_sra and pass_fold_builtins that indicate that the following pass_may_alias cannot be avoided (which seems doubtful to me, at the very least in the later case). They can be avoided but just not today. The one after PRE is the same issue as the SRA and FAB. I filed PR 23659 for the problem with FAB, it is similar issue with the other two. Thanks, Andrew Pinski
Re: update_stmt calls
On Feb 28, 2006, at 11:31 PM, Zdenek Dvorak wrote: tree FRE : 2060 ( 1%) I bet the reason why this is so high is because we really don't remove useless casts before going into SSA so it pills up. -- Pinski
Re: makeinfo version required (was: define_constraints patch, re-revised)
On Tue, Feb 28, 2006 at 10:02:03PM +0100, Gerald Pfeifer wrote:
> That said, I don't really disagree about enforcing proper prerequisites to
> build GCC and its documentation, my question in this case, and in general,
> just is: Can the issue which we encountered be worked around in a simple
> way in our .texi sources, or is it important enough to warrant ramping up
> our requirements?
On reflection, @strong{} around the column headers will do; it
won't look *quite* as good in HTML and Info, but it's acceptable,
and it works with old makeinfo. I've checked in the patch below.
zw
* doc/md.texi: Avoid use of @headitem so that makeinfo <4.7
continues to work.
==
--- doc/md.texi (revision 111641)
+++ doc/md.texi (local)
@@ -3041,7 +3041,7 @@
@c the @c's prevent double blank lines in the printed manual.
@example
@multitable {Original} {Mangled}
[EMAIL PROTECTED] Original @tab Mangled@c
[EMAIL PROTECTED] @strong{Original} @tab @strong{Mangled} @c
@item @code{x} @tab @code{x} @c
@item @code{P42x} @tab @code{P42x}@c
@item @code{P4_x} @tab @code{P4__x} @c
Re: update_stmt calls
On Wed, 2006-03-01 at 05:31 +0100, Zdenek Dvorak wrote: > Hello, > > during a recent discussion, it was pointed to my attention that > update_stmt is performance critical. I wondered why; this is the number > of update_stmt calls for combine.i (all the other passes have less then > 1000 calls): > > tree VRP : 17543 (10%) > tree copy propagation : 3210 ( 2%) > tree alias analysis : 113845 (67%) > tree SSA other: 20824 (12%) > dominator optimization: 1411 ( 1%) > tree split crit edges : 3122 ( 2%) > tree FRE : 2060 ( 1%) > expand: 5703 ( 3%) > TOTAL : 170549 > > I have a patch that decreases number of update_stmt calls in tree alias > analysis to 46525; By doing what? I'm about to be forced to add a few more cases of TODO_update_tmt_usage. > still, is it really that useful to run pass_may_alias > *six* times during compilation? The one after PRE will be removed when i get a few days. > Obviously, we need the initial one, and > there are comments after pass_sra and pass_fold_builtins that indicate > that the following pass_may_alias cannot be avoided (which seems > doubtful to me, at the very least in the later case), You are always welcome to try. > but the remaining > three seem to be just placed randomly. The first one is placed after some initial cleanups have taken place that may have given us the ability to generate better aliasing information (due to removed blocks, conditionals, etc). The one after PRE is because PRE inserts new pointers and dereferences but doesn't copy the name and type tags from the original vars. I imagine the one after DSE is to work around some bug, it certainly doesn't improve precision in any way. > > I also have a patch that decreases the number of update_stmt calls > in VRP to 5229 (which is more or less the number of ASSERT_EXPRs it > creates, so this cannot be improved significantly). > > Zdenek >
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 04:27:48AM +, Steven Newbury wrote: > > Hi! I'm attempting to build a iWMMXt/Linux EABI toolchain using gcc HEAD. > I'm > > using the target xscale-iwmmxt-linux-gnueabi, I've added support for this > > target to binutils and built a cross linker etc. > > > > I've proceeded to add a suitable target in config.gcc which supports EABI, > > xscale and Linux basing it on the existing arm/linux target and replacing > the > > linux-elf.h file with a modified one based on xscale-elf.h which I've > called > > xscale-linux-elf.h. > > > > I then attempted to build a stage1 compiler with "--with-abi=iwmmxt > > --with-cpu=iwmmxt --with-arch=iwmmxt", but as soon as the build tries to > run > > xgcc I get the error below. It looks like it's getting the types wrong, > but > > I'm very new to GCC internals and I'm not sure where to look. > > Try just using arm-none-linux-gnueabi and --with-cpu=iwmmxt > --with-arch=iwmmxt; you almost certainly do not want --with-abi=iwmmxt. > > The error you gave suggests that you didn't modify something properly > to handle the xscale-linux-gnueabi target, but arm would work just fine. Thanks for the quick response! I'm sure it seems I like to make hard wok for myself! It gets worse, I'm porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm not concerned about being able to run old binaries. So is using abi=iwmmxt really not what I want? A really bad idea? Steve ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: iWMMXt/Linux EABI toolchain
On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote: > Thanks for the quick response! > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm > porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm not > concerned about being able to run old binaries. So is using abi=iwmmxt really > not what I want? A really bad idea? Absolutely. You want the AAPCS, not Intel's pre-AAPCS ABI. -- Daniel Jacobowitz CodeSourcery
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote: > > Thanks for the quick response! > > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm > > porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm > not > > concerned about being able to run old binaries. So is using abi=iwmmxt > really > > not what I want? A really bad idea? > > Absolutely. You want the AAPCS, not Intel's pre-AAPCS ABI. Ah right! I wasn't sure about that, thanks. I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the vendor string is picked up by my ebuild scripts to pass the iwmmxt target flags. Given my objective, am I wrong to try to make a tool chain that targets xscale-iwmmxt-linux-gnueabi specifically or do you just consider it unnecessary effort? Steve ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Preserving bootstrap with non-GCC compilers
Hi, I'm a big fan of Zack's "over-my-dead-body" motto when it comes to ditching bootstrap with non-GCC compilers. :-) It turns out that bootstrap is again broken on mainline for them (at least Sun CC) and that the problem is another instance of PR bootstrap/18058. Now the problem is reproducible with GCC if the build is configured with CC="gcc -fkeep-inline-functions". Given that the problem has already showed up at least twice and that there is a straightforward way to mimic it with GCC, I'm proposing to be proactive and add -fkeep-inline-functions to CFLAGS for stage1 of an --enable-bootstrap build if the bootstrap compiler is a version of GCC that supports it. More generally, if other bootstrap with non-GCC compilers issues pop up, I think we should strive to emulate them with GCC. Comments? I'm of course also volunteering to write the patch, provided that an adept at the new bootstrap (black) magic gives me a clue as to where I should start. :-) -- Eric Botcazou
gcc 4.1.0 NOT built on i686-pc-linux-gnu (Scientific Linux 3.0.4)
Output of `srcdir/config.guess': i686-pc-linux-gnu Content of `/etc/issue': Scientific Linux SL Release 3.0.4 (SL) Output of `uname -a': Linux mlinux.pd.infn.it 2.4.21-37.ELsmp #1 SMP Wed Sep 28 12:13:44 CDT 2005 i686 GNU/Linux Output of `rpm -q glibc': glibc-2.3.2-95.33 Configured with: ../gcc-4.1.0/configure --prefix=/usr/soft/gcc4 \ --with-mpfr=/usr/soft --with-gmp=/usr/soft \ --enable-languages=c,c++,fortran 2>&1 /usr/soft/lib/libmpfr.a and /usr/soft/lib/libgmp.a are from gmp 4.1.4 Built with: make MAKE="make -j 1" CFLAGS='-O' LIBCFLAGS='-g -O2' \ LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap Last lines from 'make bootstrap': stage1/xgcc -Bstage1/ -B/usr/soft/gcc4/i686-pc-linux-gnu/bin/ -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 -DHAVE_CONFIG_H -o f951 \ fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o fortran/options.o fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o fortran/symbol.o fortran/convert.o fortran/dependency.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-stmt.o fortran/trans-types.o main.o libbackend.a ../libcpp/libcpp.a -L/usr/soft/lib -L/usr/soft/lib -lmpfr -lgmp ../libcpp/libcpp.a ../libiberty/libiberty.a /usr/soft/lib/libmpfr.a(set_str.o): In function `mpfr_set_str': set_str.c:(.text+0x174): undefined reference to `__ctype_b' set_str.c:(.text+0x3b5): undefined reference to `__ctype_b' set_str.c:(.text+0x411): undefined reference to `__ctype_b' collect2: ld returned 1 exit status make[2]: *** [f951] Error 1 make[2]: Leaving directory `/home/loreti/work/4.1.0/objdir/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/home/loreti/work/4.1.0/objdir/gcc' make: *** [bootstrap] Error 2 Any hint ? -- Maurizio Loreti http://www.pd.infn.it/~loreti/mlo.html Un. of Padova, Dept. of Physics - Padova, Italy[EMAIL PROTECTED]
