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
> 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 suppor
> 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), o
[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 objec
nux
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
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
> 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 Makefil
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
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_
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 co
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 exa
> 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
> 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
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++/
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 --s
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 t
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 verifie
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.
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 ("t
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;
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
> >
[ 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 G
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 w
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
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
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 typ
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.
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 thi
)
#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/
> 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.htm
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
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 travel
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
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*
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?
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_
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 basi
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 : 32
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
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
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
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
> wa
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):
>
--- 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 binut
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
--- 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
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 reproduci
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
48 matches
Mail list logo
