e this is a configure-time option only.
[2] describes GCC SJLJ, which is not the same as GNAT SJLJ.
--
Eric Botcazou
was somehow suspecting that gnat1 supports both ZCX and SJLJ, looks in
> system.ads, and decides what kind of assembly code it needs to emit based on
> that. Am I correct?
Yes, you are.
> In that case, I need just one compiler and two libgnats, right?
Right.
--
Eric Botcazou
o True in system.ads).
> Eric, how difficult would it be to backport a fix from 4.2 to 4.1?
Too invasive I'd think.
--
Eric Botcazou
is it too late now?
> I just don't think it's as obvious a call as your question above makes out.
> There are downsides to this approach too, especially when no one person
> is in overall charge of repository (mainline and branch).
Right. And, in my opinion, these downsides are easily underestimated.
--
Eric Botcazou
release
branch sooner than later?
> I think one source of the problem is that standards the that I hold
> myself to, may potentially be unrealistic for many contributors.
Definitely. I'd say that the patches you review are not your babies, only
those you write are. :-)
--
Eric Botcazou
> since p is a global variable, it can be used in other functions. Any
> other causes?
The first thing to do is to post a reproducer. As Ian said, your code doesn't
even compile...
--
Eric Botcazou
siderably, improving compile times at the expense of lost
aliasing precision. */
maybe_create_global_var (ai);
We have found this to be quite helpful on gigantic elaboration procedures
generated for Ada packages instantiating gazillions of generics. We have
actually lowered the threshol
y
will not be able to disambiguate memory accesses it would have been able to,
if the limit were not reached.
> it is also not really partially disabling. It's really fully disabling
> in 99% of
Partially because it only affects call-clobbered variables IIUC.
--
Eric Botcazou
C
> notices this later, and dies.
See PR rtl-optimization/29329 for a variant.
> Ideas?
The combiner already knows how to update liveness information in some cases
(lost REG_NOTEs) so I think that we probably need to extend this mechanism.
--
Eric Botcazou
> The problem is presumably arising from the REG_EQUAL notes. Where are
> those being generated? Why does this case not arise for other targets?
If the problem stems from REG_NOTEs, then it may again be a duplicate of PR
rtl-optimization/25514.
--
Eric Botcazou
> But note this is with RTL checking enabled (--enable-checking=rtl).
Can anyone refresh my memory: why is RTL checking disabled on the mainline?
--
Eric Botcazou
> Because it takes a LONG time.
Figures? Tree checking is not cheap with GCC 4.x either.
--
Eric Botcazou
d on.) At 5
> minutes each it adds up fast!
> http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00294.html
This happened at some point during 4.1 development too. It turned out to be a
code generation bug that was butchering the PTHREAD_* initializer macros.
--
Eric Botcazou
min
assert,runtime,misc,gc: 186 min
assert,runtime,misc,gc,tree:203 min
assert,runtime,misc,gc,tree,rtl,rtlflag 266 min
So I was wrong, tree checking is still relatively cheap; misc and rtl are not.
--
Eric Botcazou
e for this
> case?
The test needs to check that --gc-sections works, so indirectly invoking
ppc64_elf_gc_mark_hook seems to be unavoidable. You could try to tweak the
contents of the sections if you understand why ppc64_elf_gc_mark_hook loops.
--
Eric Botcazou
> This patch introduces canonical types into GCC, which allow us to
> compare two types very efficiently and results in an overall
> compile-time performance improvement.
Please avoid cross-posting, patches should go to gcc-patches@ only.
--
Eric Botcazou
s case, whether it is
> an assembler or linker bug, and whether there is a workaround?
... if the user is trying to link objects files assembled by the GNU assembler
using the Sun linker.
--
Eric Botcazou
> I have built a static runtime library and i want the linker to access
> it automatically without having to pass it explicitly.
Wrong list, this one is for GCC development, not development with GCC.
Try [EMAIL PROTECTED] instead.
--
Eric Botcazou
> Yes, congratulations Richard!
Auf Deutsch, bitte! :-)
--
Eric Botcazou
ts) seems to take
> ages.
Right, this seems to be noticeably slower with 4.2, especially libstdc++.
--
Eric Botcazou
should be passed to the configure
line of GCC itself and the compiler entirely rebuilt.
--
Eric Botcazou
> So, my question is this: Do I need to have libgmp and libmpfr
> available as both 32 and 64 bit variants?
No if you use only one compiler (i.e. the multilibbed 32-bit compiler).
--
Eric Botcazou
info (4, precision(0.0_4), range(0.0_4)), &
real_info (8, precision(0.0_8), range(0.0_8)), &
real_info (10, precision(0.0_10), range(0.0_10)) /)
or something along these lines.
--
Eric Botcazou
> but again I got into troubles
libgfortran/selected_real_kind.inc is also generated.
--
Eric Botcazou
mpfr should be multilibbed :)
Yes, that works, at least on x86-64/Linux.
--
Eric Botcazou
ng Paul Eggert's
cleverness to spark your own gigantic thread? :-) Certainly, doing a mere
build with "make" and a complete bootstrap with "make bootstrap" was rather
reasonable, but you and other build machinery wizards convinced us that this
would be a pain to su
> Not much. I'm convinced it would be feasible, but definitely not easy,
> so I wanted to see how much interest there was - seems like some, but
> not a lot.
Would this comprise retrofitting the support into the 4.2 branch?
--
Eric Botcazou
either automatic bootstrap is a good feature and
we're done, or it (after all) isn't and no series of compilers should be
released with it.
--
Eric Botcazou
> I'd like to see it closed, too, all Linux/BSD vendors I know of are either
> still using 3.x or have switched to 4.1 already.
Yes, 4.1.x seems to have been selected by various vendors as the codebase for
their first GCC4-based release.
--
Eric Botcazou
is that you apparently successively replied
to the previous post, which means that all the patches are tied to a single
gigantic thread in my mailer. :-(
--
Eric Botcazou
ny case of a bug being _closed_
> just because the platform is not a primary one.
Neither can I.
--
Eric Botcazou
> The reaction varies with developer. AIX continues to use
> xcoff/stabs. The feedback of AIX users to IBM sales representatives and
> executives will determine the response.
FYI Sun has switched to DWARF-2 by default in Studio 11. Just to put a bit of
pressure on you. :-)
rnings (entity, Off). The problem of suppressing
warnings for a whole given portion of code is of course more complex.
--
Eric Botcazou
> There's a later ;) simley in the mail and maybe you missed one after
> the second paragraph. (certainly you did)
Then I guess the question is: what is the scope of a smiley? Does it
retroactively cover all the preceding sentences, including the subject?
--
Eric Botcazou
> libcpp/files.c:1238 seems to be a call to memcpy. I don't see
> anyplace a floating point exception might come from. I've certainly
> never seen anything like that.
Division by zero somewhere?
--
Eric Botcazou
> make STAGE1_CFLAGS="-O"
> BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE"
> profiledbootstrap
Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler.
--
Eric Botcazou
> And I am still getting floating point exception even with a bare make. Any
> way to debug this?
Not easily unless you already know the innards of the compiler, I'm afraid.
--
Eric Botcazou
mkheaders.conf
> /bin/sh: : cannot execute
> /bin/sh: /]*/../,, -e ta: not found
> sed: Function s,[ cannot be parsed.
That should not happen on Solaris if you set CONFIG_SHELL=/bin/ksh as
recommended in http://gcc.gnu.org/install/specific.html#x-x-solaris2
--
Eric Botcazou
> This patch bootstraps and passes make check on x86_64.
Please do not cross-post. Patches should go to gcc-patches@ only.
--
Eric Botcazou
t; release, most appear not.
The -fpic/-fPIC failures are a little annoying but other platforms probably
have similar glitches, so we can live with them (I personally don't test
with -fpic/-fPIC so I have only the above 2 failures in my logs).
Results on other versions of Solaris are on par with those on Solaris 10.
--
Eric Botcazou
correct
> problems in these patches: the choices will be only to keep the patches
> checked in or to take them out entirely.
What about the patch for PR other/27843 then?
--
Eric Botcazou
> Furthermore, I am not really sure that the FSF testing
> infrastructure is setup to deal with tests of hundreds
> of thousands of lines of code.
Right, this is not the "spirit" of the GCC regression testsuite.
We instead strive to distill reduced testcases from these
> FWIW, in Apple distributed GCC 4.0.x, strict-aliasing is disabled by
> default when -O? is used because it breaks too much existing
> code (not just Apple internal code).
Much more than in 3.x?
--
Eric Botcazou
> I could say much more (there are interesting stories about the
> behind-the-scenes politics) but it's off-topic.
Please think about writing a book telling the whole story when the dust will
have settled. :-)
--
Eric Botcazou
flag,runtime,tree
Thread model: posix
gcc version 4.3.0 20070304 (experimental)
I'm a bit puzzled by the real/user ratio, the box was supposed to be idle...
--
Eric Botcazou
terday... sorry for the noise.
--
Eric Botcazou
4.1.x though.
--
Eric Botcazou
> 2006-02-07 Eric Botcazou <[EMAIL PROTECTED]>
> config/sol26.h (CPP_SUBTARGET_SPEC): Accept -pthread.
> doc/invoke.texi (SPARC options): Document -pthread.
It's only an alias for the existing -pthreads, not worth mentioning IMO.
--
Eric Botcazou
> So why is it there? Compatibility with some other compiler?
To work around some laziness in libgomp. :-) Other platforms only have
-pthread it seems.
--
Eric Botcazou
if (DWARF2_UNWIND_INFO || DWARF2_FRAME_INFO)
initial_return_save (INCOMING_RETURN_ADDR_RTX);
#endif
--
Eric Botcazou
ver plagued by serious
problems due to the SRA bit-field patch.
--
Eric Botcazou
> GCC 4.2.0 RC2 is building now, and, if all goes well, will be announced
> and uploaded later today.
Bad timing I'd think, Ian's controversial TYPE_MAX_VALUE patch is still there.
--
Eric Botcazou
gnu-ld --enable-languages=c,c++,ada
--disable-nls --prefix=/home/eric/gnat/local
--enable-checking=assert,misc,tree,rtl,rtlflag
Thread model: posix
gcc version 4.1.0 20050227 (experimental)
--
Eric Botcazou
> also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
Sure? The suspected patch is not present on that branch.
--
Eric Botcazou
.0 branch, and I don't see any
patch from you or Roger there, so I presume you're confusing with mainline.
--
Eric Botcazou
n matches the
> Linux version, also the Solaris version behaves like *I* expect.
The shared version is required on Solaris to properly support exception
handling across shared libraries.
> Now my question: which behaviour is the correct one?
Both.
--
Eric Botcazou
n
> the same way, no dynamic linking necessary. With the newest snapshot
> gcc-4.0-07032005 there is dynamic linking necessary. The code is written in
> C++, but there is no exception handling.
That's a bit odd. However we would need more information to properly diagnose
the
ibgcc if
you want to use the static libgcc, at the cost of proper EH support.
--
Eric Botcazou
ines in C
> is that they will see more testing. I think it would be really tough
> for, say Ada, to rely on features in the backend that are not used at
> all by C/C++.
That's already the case for other features, although these are primarily
middle-end features.
--
Eric Botcazou
> stage1/xgcc -Bstage1/ -B/usr/local/sparc-linux/bin/ -c -g -O2
> -gnatpg -gnata -g -O1 -fno-inline \
> -I- -I. -Iada -I/usr/local/src/trunk/gcc/gcc/ada
> /usr/local/src/trunk/gcc/gcc/ada/a-except.adb -o ada/a-except.o
> unhandled expression in get_expr_operands():
>
This i
back-end and be released with 4.1. The amount of
work is not overwhelming but, as GCC is a volunteer project, your company
might consider hiring someone to do the work if it deems the feature a
requirement for 4.1.
--
Eric Botcazou
;d like you to make a decision for that branch too.
Thanks in advance.
--
Eric Botcazou
reas with a bare 'make' it is built by the installed
compiler. So in general the final compilers are not identical.
What prevents you from setting CFLAGS="-O2 -fomit-frame-pointer" if you
happen to be rebuilding the compiler with an installed version of itself?
--
Eric Botcazou
Why should 2 different build processes generate the
same executable? Is there a (written) rule about this?
--
Eric Botcazou
problem is present in 3.4.x for the C++ compiler (but
> > is not a regression there) so I'd like you to make a decision for that
> > branch too.
>
> I'd prefer not to apply this for 3.4.
Agreed.
--
Eric Botcazou
ding some kind of
> special support. (I'm not actually sure what the assembler does with
> the name; presumably puts it in debug information.)
I can speak for the SPARC 64-bit assembler: it creates a special ELF symbol
for it (STB_GLOBAL, STT_REGISTER, SHN_UNDEF).
--
Eric Botcazou
> I do regular bootstraps of mainline all languages on FC3
> i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm using
> --enable-checking=tree,misc,rtl,rtlflag which might make a difference.
You should add 'assert' with 4.x, otherwise you miss the
directory `/usr/local/src/trunk/objdir32/gcc'
> make[1]: *** [stage2_build] Error 2
> make[1]: Leaving directory `/usr/local/src/trunk/objdir32/gcc'
> make: *** [bootstrap] Error 2
Now fixed. Thanks for the heads up.
--
Eric Botcazou
sr/include/dlfcn.h
. /usr/include/link.h
.. /usr/include/sys/link.h
.. /usr/include/libelf.h
--
Eric Botcazou
> > Here's what I get with -H:
>
> Sorry? -H applied to what command?
The GCC command line you pasted.
--
Eric Botcazou
how to proceed though.
Remove that file when bootstrapping GCC or configure --with-local-prefix.
--
Eric Botcazou
No, is not directly included, only .
--
Eric Botcazou
LUE_REGNO_P and
require all potential return registers to be recognized by the macro. But
FUNCTION_VALUE_REGNO_P is used outside of builtins.c, in lcm.c and rtlanal.c,
so this could pessimize the common case.
What do you think?
Thanks in advance.
--
Eric Botcazou
> That was my thoughts too. You could take a look at how I fixed it on
> ARM.
Thanks. So basically you bypass the apply_result_mode array entirely, which
is still wrong as it is on SPARC?
--
Eric Botcazou
> sparc
>
> Eric Botcazou says he is working on predicates.md himself.
>
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01694.html
Confirmed. :-) However don't hold your breath, my priority is 4.0.0 until
after it is released.
--
Eric Botcazou
s bigger and
> better, but don't need all the parts)
Configure with --disable-libgcj. I even considered making this the default on
SPARC/Solaris because libgcj build times are insanely long in 4.x and the
default setting is to build 2 such monsters on Solaris 7 and up.
--
Eric Botcazou
> single digits.
Sure, but libgcj build times have escalated, /bin/ksh or not /bin/ksh, and
they are getting unreasonable on (low-end) hardware currently sold by Sun.
--
Eric Botcazou
mode describes the widest mode of a *single* hard register.
Now, before your change, apply_result_size computed the widest mode of
*multi* hard registers, that's not the same thing.
--
Eric Botcazou
ll and untyped_return can be hacked to work around this (a la
ARM), but this would need to be done in every back-end. So I think you
should find another approach to fix your MIPS-specific problem, possibly by
hacking MIPS' untyped_call and untyped_return.
--
Eric Botcazou
x86_64-linux is clean too.
--
Eric Botcazou
cd $dir/run
> + if [ ! -x $dir/tests/$chapter/$i/$binmain ]; then
> + sync
> + fi
> target_run $dir/tests/$chapter/$i/$binmain >
> $dir/tests/$chapter/$i/${i}.log 2>&1 cd $dir/tests/$chapter/$i
> cat ${i}.log >> $dir/acats.log
Thanks, I'll test.
--
Eric Botcazou
> http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01875.html
A bit outdated. Most of them should be gone as of today.
--
Eric Botcazou
ia:
>
> http://gcc.gnu.org/gcc-4.0/criteria.html
>
> for primary and secondary platforms.
sparc-sun-solaris2.9 is OK for C/C++/Objective-C/Ada/F95, except
FAIL: gcc.dg/builtin-apply4.c execution test
in 32-bit mode. Patch in testing.
We severely regressed for Java (22*2 new failures) 3 days ago.
--
Eric Botcazou
> Is that a regression though? builtin-apply4.c is a new test.
http://gcc.gnu.org/ml/gcc/2005-04/msg00299.html
--
Eric Botcazou
e
cases Java hackers should coordinate with the platform maintainers that try
to keep the Java compiler healthy on their architecture, despite the huge tax
of CPU cycles this entails. These CPU cycles should not be simply wasted.
--
Eric Botcazou
> Please post the list of failures to [EMAIL PROTECTED]
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00671.html
--
Eric Botcazou
nd SPARC is the port that features the greatest number of officially
appointed maintainers. :-)
> However, if you can let me have a logon I can have a look.
Thanks for the offer. I'll try and see what I can do.
--
Eric Botcazou
> which I see you've already committed a patch for, and a large number
> of Java failures.
>
> <http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html>
>
> for 4.0.0-20050410.
Same failure as on Solaris.
Andrew, do you have a Darwin machine at hand?
--
Eric Botcazou
That doesn't cover many architectures/OSes though.
--
Eric Botcazou
RC, so the 4.0.0pre compiler is now regression-free for all languages on
sparc-sun-solaris2.9 (as well as sparc64-sun-solaris2.9).
--
Eric Botcazou
er you compile with -m32 or -m64.
--
Eric Botcazou
ml/gcc-testresults/2005-04/msg01297.html
--
Eric Botcazou
possibilities?
For 3.3 and 3.4, this was "fixed" by not recording memory equivalences that
have the infamous RTX_UNCHANGING_P flag set.
--
Eric Botcazou
oes the whole job should be made available.
The second patch is not necessary. It is only meant to avoid the tons of
failures you get (it was inadvertently dropped from Binutils 2.15).
--
Eric Botcazou
s of course not optimal, unnecessary spills are generated.
--
Eric Botcazou
as generated by GCC).
As an alternative, I could probably disable STABS for the 64-bit compiler.
--
Eric Botcazou
tion.
Was that long enough? :-) However, my reaction has not changed since
yesterday: did you mean SET_DEST?
--
Eric Botcazou
else than setting the pseudo to the value it
is already equivalenced to.
--
Eric Botcazou
> Not being able to build in the source directory is a bug.
> Having to set CONFIG_SHELL is a bug.
> Having to install a newer cctools is a bug.
>
> Bugs should be fixed. Papering over them with documentation is, well,
> unappealing to me.
How can you fix bugs in Solaris&#
abels
>
> Therefore :
> 1) This seems to be x86-specific, so I would suggest moving this
> paragraph from sparc-sun-solaris2* to i?86-*-solaris2*
The problem is present on SPARC so the paragraph can't be moved.
Not sure whether the bug ID is correct though.
--
Eric Botcazou
1 - 100 of 1094 matches
Mail list logo
