A question about cleanup_cfg ()
Hello, I have a basic-block and I want to get the last jump insn of it. I use BB_END (bb) for that purpose. The instruction I get is a NOTE_INSN_PROLOGUE_END which appears right before the jump insn; and when doing NEXT_INSN for that note I get the first insn of the next bb (code_label); which means the jump insn was skipped... Investigating this behavior showed that it occurs right after calling cleanup_cfg () from cfg_layout_initialize (0) (which is been called at the beginning of the new pass I'm working on -that is placed right before pass_free_cfg) It is not clear why BB_END (bb) did not return the jump insn as expected... Thanks, Revital ... (note 124 122 151 2 NOTE_INSN_PROLOGUE_END) (jump_insn 151 124 152 2 (set (pc) (label_ref 51)) -1 (nil))) ;; End of basic block 2 -> ( 4 ... (barrier 152 151 149) ;; Pred edge 4 [50.0%] (can_fallthru) (code_label 149 152 34 3 18 "" [1 uses])
Re: A question about cleanup_cfg ()
On Thu, Dec 11, 2008 at 9:57 AM, Revital1 Eres <[EMAIL PROTECTED]> wrote: > > Hello, > > I have a basic-block and I want to get the last jump insn of it. > I use BB_END (bb) for that purpose. > The instruction I get is a NOTE_INSN_PROLOGUE_END which appears right > before the jump insn; and when doing NEXT_INSN for that note I get > the first insn of the next bb (code_label); which means the jump insn > was skipped... > Investigating this behavior showed that it occurs right after calling > cleanup_cfg () from cfg_layout_initialize (0) (which is been called > at the beginning of the new pass I'm working on -that is placed right > before pass_free_cfg) > It is not clear why BB_END (bb) did not return the jump insn as > expected... Because you called cfg_layout_initialize (0). It puts the CFG in cfglayout mode. And there are no unconditional jumps in cfglayout mode. You could easily have found this out yourself by printing the basic block (debug_bb_n(2) from gdb) after calling cfg_layout_initialize (0). Gr. Steven
Re: question on optimizing calls to library functions
> The main difference that springs to mind: SIN is built-in, MATMUL is a > library > function. In gcc/builtin.defs, one finds Not just that: SIN is a pure (or const, depending on -frounding-math) function, which can be subject to CSE and DCE. I don't see anything suggesting that for MATMUL in intrinsic.c. In fact, since MATMUL receives the return array by reference and writes to it, it would be very wrong to make MATMUL const or pure. Paolo
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
Gents,
thanks for taking the time to explain stuff - hopefully, in the end,
we'll resolve this.
---
Firstly, issues with my choice of configure options might be
important - but they are not relevant to the underlying problem.
The basic problem is entirely repeatable with default options
("regress", for example, shows 128 unsupported libgomp tests).
I am happy to be 'blown out of the water' here - but I do want to
understand the limitations.
If gcc X.Y can deliver greater functionality than the default install
on darwinX then, IMO, I should be able to pass this onto my clients
and users.
Obviously, I want to do this in a secure manner, that does not break
the system for my clients, and is understandable by developers.
[* I am not trying to replicate your work Jack, but seeking a
different deployment solution - which is required in some cases].
We have strayed, to some extent, from the specific issue of TLS into
more general areas; but these are v. important areas (and one might
at least see this list as partial documentation for some future
engineer also trying to understand).
===
apropos emutls (I emailed Jakub, who kindly replied)
1/ The reason that emutls is in gcc_eh is because there must be only
one copy in an executable.
So, in the general case, when using emults, one must:
(a) link all parts of the executable using emutls statically (which
is tedious to achieve on darwin without moving all the dylibs to one
side)
(b) link with the libgcc_s.1that contains emutls.
so, AFAICT (at least on darwin) these are broken w.r.t emutls:
gcc main-progam.c -lgcc_eh -lsome-library-already-linked-to-emutls-
in-gcc_s.1 .
gcc main-progam.c -lstatic-libgcc -lsome-library-already-linked-to-
emutls-in-gcc_s.1 .
(in fact, D8 ld won't let you do the second unless "some-library-
already-linked-to-emutls-in-gcc_s.1" is already installed).
I have a hunch that this is, at least partially, the origin of
sporadic failures in crayptr2 (which has been one of the very few
tests using tls so far - because all the rest have been UNSUPPORTED
by the fails in dg target supports).
2/ If I understand correctly, one must link with the ex. handlers in
libSystem if one wants proper operation languages using exceptions
(i.e. the reason that --shared-libgcc is used in the testsuite). **
see also below.
So, my kludge to libgomp.exp "-lgcc_s.1" is probably broken with
respect to ex. handlers for g++, objc etc.
- unless it's acceptable for a single executable to get its EH code
from a newer libgcc_s.1
(i.e. is it a matter of consistency, or *must* the EH code absolutely
come from libSystem, for some other reason ?)
If the static libs are segregated because of these needs - then why
not segregate the dylibs?
I.E. put the EH code in libgcc_eh.so (which can then be ignored on
darwin)
apropos the general issue of supplying an enhanced gcc runtime set
onto darwinX
(assuming that the problems are fundamentally resolvable).
On 11 Dec 2008, at 00:13, Geoff Keating wrote:
On Dec 10, 2008, at 3:24 PM, IainS wrote:
On 10 Dec 2008, at 22:36, Geoff Keating wrote:
On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:
On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote:
To use the 'unversioned set' implies that you're compiling for a
version of Mac OS that Apple has not yet created and most likely
will never exist. This is not useful.
One way to get extra runtime support is put routines in libgcc.a
which can be statically linked into executables if they aren't
present in the system.
if one did -lgcc_s.10.x -lgcc_s.1 would that break it?
... should it not pick up only the unresolved symbols from s.1
( you would also have to be prepared to install libgcc_s.1 in a
suitable place).
The second part here is the tricky part. I would not recommend
installing your libgcc_s.1.dylib in /usr/lib, or anywhere else
really, since you don't know that it'll be compatible with the
system one.
(a)
--enable-version-specific-runtime-libs**
should ensure that this is achieved without any risk of trampling on
the system (we certainly do not want to take responsibility for that).
(and with --program-suffix=-x.y.z allows me to have 4.3 and 4.4
installed along with apple-released 4.0 and 4.2 ... )
** providing one does *not* use --with-slibdir=/usr/lib (see below)
(b)
an alternative (especially attractive to me) is:
package a set of gccx.y libs with rpaths @executable_path/../lib
I can then deliver this as a user drag-installable app (perhaps
wasteful of disk space, but nicely self-contained) :
MyAppUsingGFortran.app
Contents/
MacOS/
MyAppUsingGFortran
lib/
libgfortran.dylib
etc.
libgcc_s.1.dylib
(c) There are all the other usual suspects ; put the libs in
DYLD_FALLBACK_LIBRARY_PATH etc. etc.
T
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Thu, Dec 11, 2008 at 12:38:11PM +, IainS wrote: ... > > I have a hunch that this is, at least partially, the origin of sporadic > failures in crayptr2 (which has been one of the very few tests using tls > so far - because all the rest have been UNSUPPORTED by the fails in dg > target supports). ... No. The random failures in crayptr2 are due to multiple threads reading an offset value of 0 and is fixed by the proposed patch... http://gcc.gnu.org/bugzilla/attachment.cgi?id=16879 which solves PR35677. I have confirmed this on i686-apple-darwin9 several times now. Jack
Retargetting alpha to mtalpha
Hi, I made an extension of the alpha backend. To make it cleaner I have created another backend directory (in gcc/config/mtalpha). I updated the configure scripts and binutils accordingly (with the new path, name "mtalpha", features of my extension). The problem is when I generate the compiler (as a cross-compiler on my x86 machine), I have the following errors while generating the libgcc: HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET " \ /bin/sh ../../gcc-4.1.0-core-uT/gcc/mkconfig.sh tconfig.h /opt/gcc_dev/gcc-4.1.0-core-uT-build/./gcc/xgcc -B/opt/gcc_dev/gcc-4.1.0-core-uT-build/./gcc/ -B/opt/cross-mtalpha/mtalpha-linux-gnu/bin/ -B/opt/cross-mtalpha/mtalpha-linux-gnu/lib/ -isystem /opt/cross-mtalpha/mtalpha-linux-gnu/include -isystem /opt/cross-mtalpha/mtalpha-linux-gnu/sys-include -O2 -O2 -g3 -O0 -mieee -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-4.1.0-core-uT/gcc -I../../gcc-4.1.0-core-uT/gcc/. -I../../gcc-4.1.0-core-uT/gcc/../include -I../../gcc-4.1.0-core-uT/gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -Dinhibit_libc \ -c ../../gcc-4.1.0-core-uT/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:71: ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:59: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:59: error: width of 'sorted' exceeds its type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:60: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:60: error: width of 'from_array' exceeds its type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:61: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:61: error: width of 'mixed_encoding' exceeds its type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:62: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:62: error: width of 'encoding' exceeds its type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:65: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:65: error: width of 'count' exceeds its type ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h: In function 'last_fde': ../../gcc-4.1.0-core-uT/gcc/unwind-dw2-fde.h:180: warning: comparison is always false due to limited range of data type ../../gcc-4.1.0-core-uT/gcc/crtstuff.c: At top level: ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:184: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:186: error: size of array '__CTOR_LIST__' is too large ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:186: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:197: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:199: error: size of array '__DTOR_LIST__' is too large ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:199: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:206: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:207: error: requested alignment is too large ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:234: warning: initialization makes pointer from integer without a cast ../../gcc-4.1.0-core-uT/gcc/crtstuff.c: In function '__do_global_dtors_aux': ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:264: warning: integer constant is too large for 'long' type ../../gcc-4.1.0-core-uT/gcc/crtstuff.c:300: warning: integer constant is too large for 'long' type make[1]: *** [crtbegin.o] Error 1 make[1]: Leaving directory `/opt/gcc_dev/gcc-4.1.0-core-uT-build/gcc' make: *** [all-gcc] Error 2 Any clue ? Thanks for any help. T.
wieseltux23 wants to keep up with you on Twitter
To find out more about Twitter, visit the link below: http://twitter.com/i/804c155986608fb6129205812a0af487ac6da136 Thanks, -The Twitter Team About Twitter Twitter is a unique approach to communication and networking based on the simple concept of status. What are you doing? What are your friends doing—right now? With Twitter, you may answer this question over SMS or the Web and the responses are shared between contacts. This message was sent by a Twitter user who entered your email address. If you'd prefer not to receive emails when other people invite you to Twitter, click here: http://twitter.com/i/optout/83df78c1b26d20278beb320d6a904e233c7bad00
wieseltux23 wants to keep up with you on Twitter
To find out more about Twitter, visit the link below: http://twitter.com/i/b6cdbda2dd0b97a447dd7db3f70e04adc08aa8b5 Thanks, -The Twitter Team About Twitter Twitter is a unique approach to communication and networking based on the simple concept of status. What are you doing? What are your friends doing—right now? With Twitter, you may answer this question over SMS or the Web and the responses are shared between contacts. This message was sent by a Twitter user who entered your email address. If you'd prefer not to receive emails when other people invite you to Twitter, click here: http://twitter.com/i/optout/436a04093c21ff09783566d01e95c65a8f05b92d
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On 11 Dec 2008, at 13:51, Jack Howarth wrote:
On Thu, Dec 11, 2008 at 12:38:11PM +, IainS wrote:
...
I have a hunch that this is, at least partially, the origin of
sporadic
failures in crayptr2 (which has been one of the very few tests
using tls
so far - because all the rest have been UNSUPPORTED by the fails
in dg
target supports).
...
No. The random failures in crayptr2 are due to multiple threads
reading
an offset value of 0 and is fixed by the proposed patch...
http://gcc.gnu.org/bugzilla/attachment.cgi?id=16879
actually, the deeper one digs ...
it seems that libgomp is not being built with tls emulation.
(for exactly the same reasons - the configure test fails with the
unresolved __emutls... symbol)
from libgomp/config.h
/* Define to 1 if the target assembler supports thread-local storage. */
/* #undef HAVE_CC_TLS */
/* Define to 1 if the target supports thread-local storage. */
/* #undef HAVE_TLS */
and libgomp/config.log
tchCS/gcc-440-install/powerpc-apple-darwin8.11.0/sys-include -o
conftest -g -O2 -pthread conftest.c >&5
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
___emutls_get_address
collect2: ld returned 1 exit status
configure:17892: $? = 1
configure: program exited with status 1
configure: failed program was:
| __thread int a; int b; int main() { return a = b; }
configure:18104: result: no
So, I guess, the libgomp tests should not be built with TLS
emulation ; and any test requiring TLS should be hidden behind a
{ dg-require-effective-target tls_runtime }
which was a proposal anyway ( http://gcc.gnu.org/ml/fortran/2008-12/
msg00155.html).
at least this will be consistent until such time as a general
solution to making the emulation available is agreed.
(and that means addressing the general issues I raised earlier).
Iain
Wrong code with -O3 -fgraphite-identity
I have done a few tests at r142680 on i686-apple-darwin9 on the polyhedron test suite and I have found a couple of wrong codes at -O3 -fgraphite-identity, namely for capacita.f90 and fatigue.f90 (nothing to report so far for channel.f90 and induct.f90). I have little time to explore the problems. What would be the most effective way to report? Dominique
Re: Wrong code with -O3 -fgraphite-identity
I do know these problems and also the place that I have to fix. I guess a meta bug like this one "Wrong code with -O3 -fgraphite-identity on polyhedron benchmarks" is enough. Thanks for testing, Sebastian Pop -- AMD - GNU Tools
Re: Wrong code with -O3 -fgraphite-identity
On Thu, Dec 11, 2008 at 2:36 PM, Sebastian Pop wrote: > I do know these problems and also the place that I have to fix. > > I guess a meta bug like this one "Wrong code with -O3 > -fgraphite-identity on polyhedron benchmarks" is enough. > I just opened a bug that I will have to fix before submitting any more bugs about wrong code generated by graphite: http://gcc.gnu.org/PR38494 [graphite] Bootstrap fails with graphite enabled Sebastian Pop -- AMD - GNU Tools
gcc-4.3-20081211 is now available
Snapshot gcc-4.3-20081211 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081211/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 142693 You'll find: gcc-4.3-20081211.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20081211.tar.bz2 C front end and core compiler gcc-ada-4.3-20081211.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20081211.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20081211.tar.bz2 C++ front end and runtime gcc-java-4.3-20081211.tar.bz2 Java front end and runtime gcc-objc-4.3-20081211.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20081211.tar.bz2The GCC testsuite Diffs from 4.3-20081204 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
get_ref_base_and_extent() semantics
Hi, today I have encountered an unpleasant problem with the function get_ref_base_and_extent() when it claimed a known and constant offset for the expression insn_4(D)->u.fld[arg.82_3].rt_rtvec. (arg being a default_def parameter of the function, insn is an rtx). Moreover, it also returned constant size and max_size, all three equal to 64 (bits). This is certainly wrong (I believe the function got confused by unions) but after looking at the function and what it did in debugger, I grew unsure what the expected behavior is. The two alternatives I consider possibly correct are returned offset equal to -1 or, alternatively, offset equal to the offset of the array (+ offset of rt_rtvec which is zero) and max_size equal either to the size of the array or -1 if it is unknown. At the moment, the function never returns offset equal to -1, the comment above it does not even mention such possibility and, from the limited research I did, its callers do not expect and check for it. However, at the same time, the special handling of non-constants in array indices after the label "done" does not trigger in this particular case (here I suspect the unions come to play because it is the last part of the conjunction that evaluates to false). Which (or what else) is the correct semantics of the function? Both make sense to me (I would prefer the former but I suspect other users rely on the latter). What would be the correct fix, when a union field is itself a record ending with a variable-length array? How much would I pessimize things if I just returned -1 max_size if both a non-constant index and a union was encountered? Or did I miss something else? Thanks a lot in advance, Martin
