lignment errors
> during bootstrap.
Did you read http://gcc.gnu.org/install/specific.html? There are known
problems in some versions of the GNU tools and some versions of the Sun
tools. Please provide more detailed info.
--
Eric Botcazou
> is for x86 platforms only.
The problem is definitely present on SPARC (see the relocation).
> In any case this looks wrong and needs to be fixed.
Yes, we should probably revisit the problem.
--
Eric Botcazou
hows up for sparc.
Do you have a testcase? AFAIK the problem only shows up with the Sun tools.
--
Eric Botcazou
> In any case it looks like gcc cannot be built on Solaris using standard
> GNU binutils releases.
2.15 is the only one problematic, unless proven otherwise.
--
Eric Botcazou
proven otherwise.
>
> No, I've had problems with almsot all other previous GNU binutils
> releases, see my previous posts on this list.
Including 2.13.x and 2.14?
--
Eric Botcazou
ibgcj.so.6
> collect2: ld returned 1 exit status
>
> Is there a way I can find the exact "ld" command line, in order to
> provide a small testcase for the GNU binutils bugzilla?
Pass -debug to collect2. I'm not sure this will give you a *small* testcase
though.
--
Eric Botcazou
ibgcj.so.6
> collect2: ld returned 1 exit status
>
> Is there a way I can find the exact "ld" command line, in order to
> provide a small testcase for the GNU binutils bugzilla?
Pass -debug to collect2. I'm not sure this will give you a *small* testcase
though.
--
Eric Botcazou
t to be enough.
Yeah, in 1991 my 386 featured 4 Mb and I really see no reason why it could not
be used to build libgcj nowadays. ;-)
--
Eric Botcazou
h-as and --with-ld are respectively
specified because the configure machinery will probe in that case.
They are required otherwise because the Sun tools are the default.
--
Eric Botcazou
the patched assembler. If we are lucky, the
problem was generic and has been fixed on SPARC too.
--
Eric Botcazou
> Personally, I think we should default to not installing libiberty.a,
> though we should install libiberty.so if we build it.
And fix PR other/16513 in the process.
--
Eric Botcazou
thing. IIRC I tried before filing the PR
but got lost in the configure machinery.
--
Eric Botcazou
> For one thing, libgfortran requires c99 support, which is not in
> newlib iiuc.
In practice, no, it doesn't. F95 works fine on Solaris 2.5.1, which is the
typical non-C99 native platform.
--
Eric Botcazou
060.html
and can be considered as a baseline for now.
--
Eric Botcazou
> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote:
> > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html
>
> The vectorization failures still need to be fixed.
Are these specific to SPARC? If so, I don't think development should be held
off for the
ve detected that the insn is not valid.
--
Eric Botcazou
struct S1132 {
struct{
unsigned long int b;
struct{void * d[7];}c[30];
}a[3];
char e:8) - 1) & 7) + 1);
struct{}f;
};
extern int fails;
void check1132va (int z, ...)
{
struct S1132 arg;
long double ld;
__bui
rc64-sun-solaris2.9> gcc/xgcc -Bgcc -S
t007_y.c -dr
cc1: warning: unrecognized gcc debugging option: r
[EMAIL PROTECTED]:~/build/gcc/sparc64-sun-solaris2.9> gcc/xgcc -Bgcc -S
t007_y.c
-fdump-rtl-expand
cc1: error: unrecognized command line option "-fdump-rtl-expand"
--
Eric Botcazou
se_ins_ext_p
What is yours?
--
Eric Botcazou
> For Ada, I propose we make the following changes:
>- by default, enable overflow checks using -ftrapv
-ftrapv is not practically usable because (1) it generates awful code and (2)
it badly interacts with the RTL optimizers.
--
Eric Botcazou
cause it is too low-level. Its
general mechanism certainly can help (once it is fixed) but it must be driven
by something more Ada-aware.
--
Eric Botcazou
> This particular problem is gone now
Right, works fine on Solaris too.
--
Eric Botcazou
at path.
> I don't see that's so terrible, the jmp will be free in practice anyway
> so I don't think you will find this slows things down.
You missed the point; the overflow check has been optimized away by one of the
RTL optimization passes.
--
Eric Botcazou
rns for
every architecture. AFAICS only Alpha has (some of) them. And fix the RTL
optimizers in the process.
--
Eric Botcazou
e'. Moreover, int_size_in_bytes is
invoked unconditionally on 'valtype' and would segfault if it was 0, so
valtype is set every time mode == BLKmode. So I think having a non-BLKmode
on records with a single integer field would not change anything as far as
the return value is c
led to produce executable
FAIL: obj-c++.dg/try-catch-9.mm (test for excess errors)
WARNING: obj-c++.dg/try-catch-9.mm compilation failed to produce executable
FAIL: obj-c++.dg/va-meth-1.mm execution test
--
Eric Botcazou
approach, do not look at 3.x bugs; the 4.x compilers have
obsoleted a subtantial amount of 3.x-ish things it would be wasteful to learn
at this point.
--
Eric Botcazou
> What do objc.log and obj-c++.log say? I'm still seeing mysterious FC3
> (a fresh install thereof, no less) failures that no one else seems to
> be able to reproduce...
objc.log is clean, obj-c++.log is attached. This is on SuSE 9.2 Professional.
--
Eric Botcazou
obj-c++.log.
ry-catch-2.mm compilation failed to produce executable
> FAIL: obj-c++.dg/try-catch-9.mm (test for excess errors)
> WARNING: obj-c++.dg/try-catch-9.mm compilation failed to produce executable
> FAIL: obj-c++.dg/va-meth-1.mm execution test
Roughly the same results on SPARC/Solaris (21 failures instead of 25 though).
--
Eric Botcazou
ssions.
SPARC/Linux is OK too (Christian):
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00616.html
--
Eric Botcazou
.org/PR22020 yesterday. You might want to take a look,
of course assuming Joseph is not already on it. :-)
--
Eric Botcazou
atter what some bugmaster says or doesn't
> say, all that matters is the verdict of the maintainer responsible for the
> area of the compiler for which you propose a patch.
Do not underestimate the importance of Bugzilla (hence that of the
bugmasters): for most users of GCC, it's the only interface to the GCC
community.
--
Eric Botcazou
tdc++-v3/testsuite/27_io/basic_istream/ignore\
/wchar_t/7220.cc:51: undefined reference to `std::basic_istream >::ignore(int, long)'^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
and so on.
--
Eric Botcazou
s %s %s %s\n", $8, $4, $5, $6 }}' \ LC_ALL=C sort
> | -u
>
> before and after the patch?
Nice magic spell. :-)
The diff is attached.
--
Eric Botcazou
--- before.log 2005-06-16 10:06:25.009231000 -0500
+++ after.log 2005-06-16 10:06:46.519581000 -0500
@@ -5,6 +5,7 @@
> And that one should be fixed by the patch I posted, so Solaris
> should be hopefully fine.
Yup, OK everywhere.
--
Eric Botcazou
egression.
--
Eric Botcazou
t;return CL_Ada;
> }
The flag_wrapv problem doesn't come from the Ada front-end, which generates a
perfectly reasonable construct, but from fold so the workaround should be
installed in fold instead, if it is agreed that a workaround is needed.
But Diego is now working on the problem.
--
Eric Botcazou
ports about it; for example pointer difference
> with odd sized objects was broken for years, and reported only twice
> or so.
-ftrapv is simply not usable as of today because the performance degradation
is abysmal. Plus it is broken in very simple cases (PR middle-end/19020).
--
Eric Botcazou
> This is unlike aliasing, when most lines of code out there,
> did not break aliasing rules (even before they were
> introduced).
Are you sure? IIRC -fstrict-aliasing was once enabled at -O2 and then
disabled to give people more time to fix their code.
--
Eric Botcazou
you have:
> - probability of 63% to violate aliasing rules
> - and 100% (99.999 with 43 nines) to violate overflow rules.
Then there are different "most"s because, if each line of code has 1%
chance to violate overflow rules, "most" of them don't for reasonable
definitions of "most".
--
Eric Botcazou
that can be easily patched in ia64_function_arg.
I plan on submitting a patch to Steve and you next week.
Thanks for your feedback.
--
Eric Botcazou
hat we would need for Ada.
> I think this might mess up the parameter passing of structures that contain
> a single field, particularly when that field is smaller than 64 bits, like a
> single char, an int, or a float.
Running the 2 compat testsuites shows that this actually doesn't happen.
--
Eric Botcazou
bg object:
csz01 = str01.max_size();
This didn't happen in RC2 and I've not investigated what changed. The code is
the same on Solaris 7 and 8, but the Solaris 2.5.1, 2.6 and 7 machines are
substantially more limited than the Solaris 8, 9 and 10 machines.
--
Eric Botcazou
ite harness has changed).
--
Eric Botcazou
ric code of the library exposed only by that target, and
> only now.
Agreed, but were these tests simply run with the 4.0.0 testsuite?
--
Eric Botcazou
7;s what the users are supposed to do. Binutils 2.16.x work fine
on SPARC/Solaris so I presume they would work just fine on Linux too.
--
Eric Botcazou
table to break binary compatibility here. However it
is relatively easy to patch ia64_function_arg to counter the macro change.
The patch was bootstrapped/regtested/compat-regtested on ia64-hp-hpux11.23.
2005-07-07 Eric Botcazou <[EMAIL PROTECTED]>
* config/ia64/hpux.h (MEMBER_TY
> This is OK with me.
Thanks.
> Presumably we should wait for a comment from Steve, as ia64-hpux is more his
> port than mine.
Sure.
> You probably meant to send this to the gcc-patches list.
Yes. :-) Pilot error...
--
Eric Botcazou
AIL: gcc.misc-tests/gcov-7.c execution test
> FAIL: gcc.misc-tests/gcov-7.c gcov failed: gcov-7.c.gcov does not exist
> FAIL: gcc.misc-tests/gcov-8.c execution test
> FAIL: gcc.misc-tests/gcov-8.c gcov failed: gcov-8.c.gcov does not exist
> FAIL: gcc.misc-tests/gcov-9.c execution test
> FAIL: gcc.misc-tests/gcov-9.c gcov failed: gcov-9.c.gcov does not exist
Joe Buck reports the same problems on SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html
According to my testing, the fix is to upgrade to GNU Binutils 2.16 or 2.16.1.
--
Eric Botcazou
gap is eliminated at -O1.
--
Eric Botcazou
m has isinf() as below.
>
> #include
> int
> main ()
> {
> float f = 0.0; isinf(f)
> ;
> return 0;
> }
The test is clearly fragile. Assigning the return value of isinf to a
variable should be sufficient for 4.0.x at -O0.
--
Eric Botcazou
return 0;
> }
The compiler knows the answer of isinf (0) so it again optimizes away the
call. Try something like:
int a;
int
main (int argc, char *argv[])
{
a = isinf ((double) argc);
return 0;
}
or additionally compile with -fno-builtin.
--
Eric Botcazou
less). This means
> that the compiler may deduce that isinf((double)argc) always
> returns false, without ever calling the function.
You're too clever. :-)
union U {
int i;
double d;
};
volatile int a;
int
main (int argc, char *argv[])
{
union U u;
u.i = argc;
a = isinf (u.d);
return 0;
}
--
Eric Botcazou
> Why not just use AC_HAVE_FUNCS(isinf)? IIUC this is part of a configure
> script, although whether it is autoconf generated is not clear so far.
Real men write their configure checks by hand, although whether the rrdtool
maintainer is a male is not clear so far. ;-)
--
Eric Botcazou
ll missing something...
Please submit the fix for all active branches and CC me in the submission (and
Roger Sayle who approved the patch).
Thanks in advance.
--
Eric Botcazou
ARC machines I have (it is OK with 4.0.x).
IIRC I observed the same regression between 3.2.x and 3.3.x on even slower
machines, but 3.4.x fixed it.
--
Eric Botcazou
nd
produced a series of patches only aimed at cutting down the memory
consumption and speeding up the compiler. So that's definitely doable,
albeit certainly hard.
--
Eric Botcazou
s latent.
--
Eric Botcazou
(again) shoot ourselves in the foot so grossly.
--
Eric Botcazou
005-09/msg00931.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00932.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00933.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00934.html
--
Eric Botcazou
> You didn't test --enable-languages=obj-c++
Yeah, it's a plot, we positively refuse to test everything Apple has *not*
contributed. ;-)
--
Eric Botcazou
atch-9.mm compilation failed to produce executab
It's on x86-64/Linux. And I'm seeing roughly the same failures on
SPARC/Solaris.
--
Eric Botcazou
> I filed them as bugs, not fixed them.
OK, thanks for confirming.
--
Eric Botcazou
any feedback.
Has Benjamin applied his patch on the 4.0 branch? If so, my feeling is that
RC3 would not be superfluous.
--
Eric Botcazou
est
FAIL: ext/mt_allocator/tune-2.cc execution test
FAIL: ext/mt_allocator/tune-3.cc execution test
FAIL: ext/mt_allocator/tune-4.cc execution test
--
Eric Botcazou
ext/mt_allocator/tune-2.cc execution test
FAIL: ext/mt_allocator/tune-3.cc execution test
FAIL: ext/mt_allocator/tune-4.cc execution test
--
Eric Botcazou
-03/msg01294.html
The original version: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02097.html
Am I right in thinking that the call to redirect_jump must be removed?
Thanks in advance.
--
Eric Botcazou
WITH Text_IO;
PROCEDURE p IS
TYPE RealIS DIGITS 12;
TYPE Double IS DIGITS
10 (prerelease) (i586-suse-linux-gnu) GCC error: |
| in redirect_branch_edge, at cfgrtl.c:948 |
| Error detected at p.adb:70:6 |
Do you really want me to send RTL dumps?
Thanks for your quick response.
--
Eric Botcazou
inux
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01019.html
Just to make it clear: that's not a SPARC 64-bit Ada compiler, only a 32-bit
Ada compiler with a questionable name.
> Many thanks to people enabling Ada in their builds!
Seconded.
--
Eric Botcazou
> Indeed this is clearly correct. And one does wonder how this
> missing line has managed to not cause problems elsewhere...
I've installed the patch on the mainline, after bootstrapping/regtesting it on
x86_64-suse-linux. Do you want me to put it on the 4.0 branch too?
--
Eric Botcazou
. The Solaris problem
> is unfortunate, but I think not fatal.
Agreed. But I'm requesting a "caveat" note about the Solaris regression here:
http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2
mentioning the workaround (g++ -pthreads) and the link:
http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html
--
Eric Botcazou
> Done.
Thank you very much.
--
Eric Botcazou
te.
> See http://gcc.gnu.org/bugs.html> for instructions.
> compiler exited with status 1
I really should have tested it with multilibs... I'll fix tomorrow.
Thanks for the heads up.
--
Eric Botcazou
ratio?
And finally:
- portability of svn to non-Linux systems
Thanks in advance.
--
Eric Botcazou
> Irrespective of the other issues currently discussed, this is a very
> good idea!
Seconded!
--
Eric Botcazou
> It does not fail for power and I'm trying to figure out why it fails for
> x86 architecture.
SPARC is also affected, but in 32-bit mode only.
--
Eric Botcazou
itten in glibc (in
particular the 'alloc' line) is quite annoying. Or is that a lost cause and
should profiling require static linking in presence of nested functions?
Thanks in advance.
--
Eric Botcazou
da to be used in that cases either, but who knows. ;-)
Thanks for your decisive help.
--
Eric Botcazou
What should we do about that? Conditionalize the combined FP operations on
-ffast-math or something along these lines?
Thanks in advance.
--
Eric Botcazou
extern void abort (void);
typedef struct
{
float X;
float Y;
float Z;
float S;
} Unit_Quaternion_Type;
Unit_Quaternion_Type M
n", but I might be wrong.
--
Eric Botcazou
> Fused multiply-add always uses "infinite precision" in the intermediate
> result. Only a single rounding is performed at the end.
Of course, but I was implicitly referring to the 82-bit thing. But it seems I
was wrong, as the testcase fails on PowerPC w/ -mfused-madd too.
--
Eric Botcazou
(dw2_output_indirect_constant_1): Try to output indirect constants
into linkonce sections if possible.
(dw2_force_const_mem): Likewise. Register indirect_pool with GGC.
(dw2_output_indirect_constants): Likewise.
Thoughts?
--
Eric Botcazou
#include
extern void b
he bug is in the C++ front end in how we
> mangle (or not) the local class.
Yes, I think that's the crux of the matter: for the time being, neither the
C++ nor the Ada front-end mangles local exceptions. Either they should or
the problem lies in the EH machinery.
--
Eric Botcazou
and add in GCC but I would hate to see its use turned off
> by default.
If that's the consensus among IA-64 maintainers, it's fine with me.
--
Eric Botcazou
posed to be local to the translation unit.
--
Eric Botcazou
.weak DW.ref._ZTIZ3foovE1S#
.section.gnu.linkonce.s.DW.ref._ZTIZ3foovE1S,"aws",@progbits
.align 8
.type DW.ref._ZTIZ3foovE1S#, @object
.size DW.ref._ZTIZ3foovE1S#, 8
DW.ref._ZTIZ3foovE1S:
data8 _ZTIZ3foovE1S#
Found both in u.S and
So,
while the 2 DW.ref._ZTIZ3foovE1S symbols are advertised as being identical,
their contents would *not* be identical at link-time.
--
Eric Botcazou
only in Ada. I suspect it's not so easy in C++.
Anyway the generic fix turns out to be straightforward so I think we should
take that path.
--
Eric Botcazou
to be restored too. Incidentally, the current code
probably works in that case, but I think it cannot happen in practice.
--
Eric Botcazou
with Ada.Text_IO;
procedure P is
type Int_Ptr is access all Integer;
Data : Int_Ptr := null;
begin
Data.all := 0;
exception
when others =>
Ada.Text_IO.Put_Line ("Exception handled");
end P;
2
set options [concat "$ALWAYS_GFORTRANFLAGS" $options];
set options [dg-additional-files-options $options $source]
verbose "options4: $options" 2
return [target_compile $source $dest $type $options]
}
--
Eric Botcazou
> Why O3 rather than O2, I thought O3 was just O2 + implicit inlining
In the old days only, i.e. that has not been true since 3.1 at least.
--
Eric Botcazou
> I'm using "sparc-sun-solaris2.9" for the target... Does the 2.9 indicate
> the target version of Solaris, or the version of the SPARC architecture, or
> ??? .
2.9 means Solaris 9.
--
Eric Botcazou
l/apps/.software/linux/gcc-3.4.4-x86-sparc-build/sysroot/lib/libc.a when
> searching for -lc
What does 'sparc-sun-solaris2.9-objdump -f' return on these objects?
--
Eric Botcazou
l tests,
both on RHEL 3 which uses MD_FALLBACK_FRAME_STACK_FOR and on SLES 9 which
uses MD_HANDLE_UNWABI. I'll submit it shortly.
--
Eric Botcazou
> Anyways, I found a mistake in my sysroot and these messages seem to have
> vanished I had a symlink pointing to my local (linux) /lib instead of
> the sysroot's /lib (oops)
That would indeed explain the problem you were having.
--
Eric Botcazou
27;:
> ../../gcc/libgcc2.c:511: error: total size of local objects too large
>
> which does not make any sense. The above is for a x86_64 host, but I
> see this errors everywhere.
I guess the sanity check I've added doesn't apply to micro-cont
short.
>
> call to g : g (a, 3);
> definition of g : int g (float b, short c)
>
> I am not sure which part of the compiler is responsible to have the the
> types matched, but I think they should at this point.
> I am still working on this.
Any news on this?
--
Eric Botcazou
> A patch to fix this regression was committed earlier today to GCC4.1.
Works fine on SPARC. Thanks!
--
Eric Botcazou
're thinking in x86 here. SPARC uses the -mtune/-mcpu idiom.
--
Eric Botcazou
rc3 as opposed to the UltraSparc3cu?
No, that's unexpected.
--
Eric Botcazou
c is fine.
For the 64-bit compiler (sparc64-sun-solaris2.9), CC="cc -xarch=v9" is fine.
--
Eric Botcazou
101 - 200 of 1095 matches
Mail list logo
