4.3 x86_64 Bootstrap breaks
4.3 trunk revision 126185 I got at x86_64: libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[6]: *** [kill.lo] Error 1 Anyone else got the same? 126184 passes. Looks like problems in this check: r126185 | kargl | 2007-07-02 10:47:21 +0800 (Mon, 02 Jul 2007) | 281 lines Thanks - Joey
Re: 4.3 x86_64 Bootstrap breaks
> 4.3 trunk revision 126185 I got at x86_64: > > libtool: compile: unable to infer tagged configuration > libtool: compile: specify a tag with `--tag' > make[6]: *** [kill.lo] Error 1 > > Anyone else got the same? Yes, but resync your tree and this will be gone. -- Eric Botcazou
autoconf 2.61 on debian etch and GCC
The new compile farm servers are running debian etch (4.0) which comes with autoconf 2.61 and no package for 2.59 According to Rask Ingemann Lambertsen autoconf 2.61 doesn't work correctly for GCC (see below). What do GCC developpers do on debian etch? Thanks in advance, Laurent On Fri, 2007-06-29 at 11:27 +0200, Rask Ingemann Lambertsen wrote: > On Mon, Jun 25, 2007 at 08:11:31PM +0200, Laurent GUERBY wrote: > > > > If 2.61 really causes us trouble I'll try to do a manual install of 2.59 > > from whatever .tar.gz I can find. > >It does, as the config.status it produces is broken. Look at this line: > > s,@TOPLEVEL_CONFIGURE_ARGUMENTS@,|#_!!_#|/home/rask/src/gcc/configure linux > gnu,g >
Re: autoconf 2.61 on debian etch and GCC
* Laurent GUERBY <[EMAIL PROTECTED]> [2007-07-03 12:45]: > What do GCC developpers do on debian etch? You should be able to install version 2.59 from snapshot.debian.net (and then put in on hold so it won't get upgraded automatically). -- Martin Michlmayr http://www.cyrius.com/
Re: Wow!
On 7/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote: > > I'm curious if it was the pre/fre changes. can you try -fno-tree-pre > > and -fno-tree-fre and see if it slows down again? > Adding -fno-tree-pre slows aermod back to 33.942s. Nice optimization. ;) Thanks. (You really should thank richard guenther and steven bosscher, who continually beat me up till i finished it :P) Unfortunately, this "improvement" is a miscompare: Value= 2190.9357900 Target= 2191.1145000 Tolerance=0.100E-02 FAIL Value= 34310.421880 Target= 34310.421880 Tolerance=0.300E-01 Value= 4260.5888700 Target= 4260.9716800 Tolerance=0.500E-01 FAIL Value= 37093.921880 Target= 37094.375000 Tolerance=0.200E-01 FAIL Value= 7924.6811500 Target= 7924.8842800 Tolerance=0.300E-01 FAIL Value= 37093.921880 Target= 37094.375000 Tolerance= 1.00 aermod FAILED4 fails and2 passes Richard.
bootstrap broken on powerpc?
I'm seeing this failure with several recent revisions from the last day or two: ... checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /Develop/mainline-dn/build3/powerpc64-unknown-linux-gnu/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 Anyone else seeing this? thanks, dorit
Re: [GSoC: DDG export][RFC] Current status
"Alexander Monakov" <[EMAIL PROTECTED]> writes:
> The implementation follows the outline presented in my initial message
> on the project, here: http://gcc.gnu.org/ml/gcc/2007-03/msg00900.html
> . Data references and data dependency relations obtained via
> compute_dependencies_for_loop are copied into containing struct (which
> is a member of struct function). This containing struct is marked
> GTY((skip)), because its lifetime and lifetime of its components is
> known (from the moment of export until destruction late in the RTL
> pipeline). However, I need to preserve trees that are referenced in
> the exported datarefs (to be able to bind MEMs to datarefs later), so
> I need to put them into a GC-visible array. For now that array is
> global. Can it be done better?
It seems to me that this array could also be in the function struct.
I don't see why not. Given the way it is used, it also seems to me
that this array should be a pointer_map.
> MEMs are bound to datarefs by means of saving original trees for MEMs
> during expand. This is a large part of the attached patch with
> changes to emit-rtl.[ch], which adds new field to struct mem_attrs
> (mem_orig_expr), initializes it and propagates through various RTL
> transformations. Notice that it has stricter hashing (as compared to
> orig_expr part of the same struct), so it will reduce sharing of
> mem_attrs (and also increase size of the struct, obviously). Can it
> be a problem? Please also note that this patch is a part of aliasing
> information exporting patch by Dmitry Melnik, which available now in
> alias-export branch.
Adding a new field to mem_attrs could be a problem. You'll have to
measure to see how much the memory usage changes.
> After original tree is found, a corresponding dataref is looked up in
> exported info. I guess I will need here hashtabs for fast lookup
> (also for searching ddrs for pairs of datarefs), am I right?
Yes, hash tables or pointer maps.
> The verifier also frequently breaks on passes that create unreachable
> basic blocks (because dominator analysis called from flow_loops_find
> asserts there are none). For now I just place
> delete_unreachable_blocks in such passes, is that ok?
Not for the final patch, but it's OK for debugging.
> +/* If EXPR contains conversions at the root of the tree, all of them
> + will be removed. */
> +
> +static tree
> +skip_conversions (tree expr)
> +{
> + tree inner = expr;
> + /* Remove any conversions: they don't change what the underlying
> + object is. Likewise for SAVE_EXPR. */
> + while (TREE_CODE (inner) == NOP_EXPR || TREE_CODE (inner) == CONVERT_EXPR
> +|| TREE_CODE (inner) == NON_LVALUE_EXPR
> +|| TREE_CODE (inner) == VIEW_CONVERT_EXPR
> +|| TREE_CODE (inner) == SAVE_EXPR)
> +inner = TREE_OPERAND (inner, 0);
> + return inner;
> +}
I don't understand why it's OK to throw all these away. Some of them
change the meaning of the expression. I also don't understand why you
want to throw them away.
> @@ -1401,27 +1456,36 @@ component_ref_for_mem_expr (tree ref)
> {
>tree inner = TREE_OPERAND (ref, 0);
>
> - if (TREE_CODE (inner) == COMPONENT_REF)
> + /* Remove any conversions: they don't change what the underlying
> + object is. Likewise for SAVE_EXPR. */
> + while (TREE_CODE (inner) == NOP_EXPR || TREE_CODE (inner) == CONVERT_EXPR
> + || TREE_CODE (inner) == NON_LVALUE_EXPR
> + || TREE_CODE (inner) == VIEW_CONVERT_EXPR
> + || TREE_CODE (inner) == SAVE_EXPR)
> +inner = TREE_OPERAND (inner, 0);
> +
> + if (TREE_CODE (inner) == COMPONENT_REF || TREE_CODE (inner) ==
> INDIRECT_REF)
> inner = component_ref_for_mem_expr (inner);
>else
> {
> - /* Now remove any conversions: they don't change what the underlying
> - object is. Likewise for SAVE_EXPR. */
> - while (TREE_CODE (inner) == NOP_EXPR || TREE_CODE (inner) ==
> CONVERT_EXPR
> - || TREE_CODE (inner) == NON_LVALUE_EXPR
> - || TREE_CODE (inner) == VIEW_CONVERT_EXPR
> - || TREE_CODE (inner) == SAVE_EXPR)
> - inner = TREE_OPERAND (inner, 0);
> -
>if (! DECL_P (inner))
> inner = NULL_TREE;
> }
>
>if (inner == TREE_OPERAND (ref, 0))
> return ref;
> - else
> -return build3 (COMPONENT_REF, TREE_TYPE (ref), inner,
> -TREE_OPERAND (ref, 1), NULL_TREE);
> + else if (TREE_CODE (ref) == COMPONENT_REF)
> +{
> + return build3 (COMPONENT_REF, TREE_TYPE (ref), inner,
> + TREE_OPERAND (ref, 1), NULL_TREE);
> +}
> + else /* INDIRECT_REF. */
> +{
> + if (inner == NULL_TREE)
> + return NULL_TREE;
> + else
> + return build1 (INDIRECT_REF, TREE_TYPE (ref), inner);
> +}
> }
The handling of INDIRECT_REF here seems clearly wrong. You definitely
can't discard conversions for an INDIRECT_REF.
Hope this helps a bit. I will have more luck understanding what is
going on when I see how yo
Re: Wow!
Uros Bizjak Mon, 02 Jul 2007 20:29:41 +0200 wrote: Hello! It is worth noticing that latest changes to gcc brought more than 75% speed-up on Polyhedron aermod.f90 benchmark [1]. I can confirm this on 32bit nocona, and double-checked on 64bit core2: gcc -O3 -funroll-loops -ftree-vectorize -ffast-math: (GCC) 4.3.0 20070622 : 0m33.530s (GCC) 4.3.0 20070702 : 0m11.805s [1]: http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html Uros. Please, to add the option -S and -fdump-tree-gimple to the script, and paste the ".s" and ".gimple" files to see the differences since the real or abstract machine. Bye xuxi
[patch] conditionally declare bswap functions depending on target
The target I am working on is 16-bit target and cannot support 64- bit data types (DI mode). How about conditionally declare the function? #if LONG_LONG_TYPE_SIZE > 32 extern DItype __bswapdi2 (DItype); #endif So, I finally got around to this patch. While I was at it I went ahead and check SImode as well. Tested on mips64vr-elf and x86-darwin. OK? -eric 2007-07-03 Eric Christopher <[EMAIL PROTECTED]> * libgcc2.h: Conditionally include __bswapsi2 and __bswapdi2. Index: libgcc2.h === --- libgcc2.h (revision 126242) +++ libgcc2.h (working copy) @@ -342,18 +342,23 @@ extern UWtype __udiv_w_sdiv (UWtype *, U extern word_type __cmpdi2 (DWtype, DWtype); extern word_type __ucmpdi2 (DWtype, DWtype); +#if MIN_UNITS_PER_WORD > 1 +extern SItype __bswapsi2 (SItype); +#endif +#if LONG_LONG_TYPE_SIZE > 32 +extern DItype __bswapdi2 (DItype); +#endif + extern Wtype __absvSI2 (Wtype); extern Wtype __addvSI3 (Wtype, Wtype); extern Wtype __subvSI3 (Wtype, Wtype); extern Wtype __mulvSI3 (Wtype, Wtype); extern Wtype __negvSI2 (Wtype); -extern SItype __bswapsi2 (SItype); extern DWtype __absvDI2 (DWtype); extern DWtype __addvDI3 (DWtype, DWtype); extern DWtype __subvDI3 (DWtype, DWtype); extern DWtype __mulvDI3 (DWtype, DWtype); extern DWtype __negvDI2 (DWtype); -extern DItype __bswapdi2 (DItype); #ifdef COMPAT_SIMODE_TRAPPING_ARITHMETIC extern SItype __absvsi2 (SItype);
Re: [patch] conditionally declare bswap functions depending on target
Eric Christopher <[EMAIL PROTECTED]> writes: > 2007-07-03 Eric Christopher <[EMAIL PROTECTED]> > > * libgcc2.h: Conditionally include __bswapsi2 and > __bswapdi2. This is OK if you change "include" to "declare" in the ChangeLog entry. Thanks. Ian
Re: autoconf 2.61 on debian etch and GCC
* Laurent GUERBY wrote on Tue, Jul 03, 2007 at 12:45:45PM CEST: > > According to Rask Ingemann Lambertsen autoconf 2.61 > doesn't work correctly for GCC (see below). [...] > On Fri, 2007-06-29 at 11:27 +0200, Rask Ingemann Lambertsen wrote: > > On Mon, Jun 25, 2007 at 08:11:31PM +0200, Laurent GUERBY wrote: > > > > > > If 2.61 really causes us trouble I'll try to do a manual install of 2.59 > > > from whatever .tar.gz I can find. > > > >It does, as the config.status it produces is broken. Look at this line: > > > > s,@TOPLEVEL_CONFIGURE_ARGUMENTS@,|#_!!_#|/home/rask/src/gcc/configure linux > > gnu,g Please consider the following patch. $ac_configure_args has the following differences to original args: - duplicate-argument suppression, - quoting to be used inside "eval" as below, - --no-create, --no-recursion, and --silent stripped out (variables $no_create, $no_recursion, and $silent provide these; I don't think $TOPLEVEL_CONFIGURE_ARGUMENTS needs the first two). I've tested it very lightly only (mostly because errors will typically happen with setups different from mine). The 'set x ..; shift' is to accommodate for old (non-POSIX) shells that error out on 'set --', not sure if gcc has a policy against this kind of change. (FWIW, the "|#_!!_#|" in the line is intentional and not a bug.) I'd be interested in other GCC issues using Autoconf 2.61 over 2.59. Cheers, Ralf ChangeLog: 2007-07-03 Ralf Wildenhues <[EMAIL PROTECTED]> * configure.ac (TOPLEVEL_CONFIGURE_ARGUMENTS): Use $ac_configure_args, not "$@". Do not use `set --'. (baseargs): Likewise. * configure: Regenerate. Index: configure.ac === --- configure.ac(revision 126245) +++ configure.ac(working copy) @@ -88,7 +88,8 @@ # Export original configure arguments for use by sub-configures. # Quote arguments with shell meta charatcers. TOPLEVEL_CONFIGURE_ARGUMENTS= -set -- "$progname" "$@" +eval "set x \"$progname\" $ac_configure_args" +shift for ac_arg do case "$ac_arg" in @@ -2090,7 +2091,8 @@ baseargs= keep_next=no skip_next=no -eval "set -- $ac_configure_args" +eval "set x $ac_configure_args" +shift for ac_arg do if test X"$skip_next" = X"yes"; then
Re: autoconf 2.61 on debian etch and GCC
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Index: configure.ac > === > --- configure.ac (revision 126245) > +++ configure.ac (working copy) > @@ -88,7 +88,8 @@ > # Export original configure arguments for use by sub-configures. > # Quote arguments with shell meta charatcers. > TOPLEVEL_CONFIGURE_ARGUMENTS= > -set -- "$progname" "$@" > +eval "set x \"$progname\" $ac_configure_args" To avoid expanding $progname twice: eval "set x \"\$progname\" $ac_configure_args" Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Wow!
On Tue, 2007-07-03 at 13:07 +0200, Richard Guenther wrote: > On 7/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: > > > Daniel Berlin wrote: > > > > I'm curious if it was the pre/fre changes. can you try -fno-tree-pre > > > > and -fno-tree-fre and see if it slows down again? > > > Adding -fno-tree-pre slows aermod back to 33.942s. Nice optimization. ;) > > Thanks. > > (You really should thank richard guenther and steven bosscher, who > > continually beat me up till i finished it :P) > > > > Unfortunately, this "improvement" is a miscompare: > > > Value= 2190.9357900 Target= 2191.1145000 Tolerance=0.100E-02 > FAIL > > Value= 34310.421880 Target= 34310.421880 Tolerance=0.300E-01 > > Value= 4260.5888700 Target= 4260.9716800 Tolerance=0.500E-01 > FAIL > > Value= 37093.921880 Target= 37094.375000 Tolerance=0.200E-01 > FAIL > > Value= 7924.6811500 Target= 7924.8842800 Tolerance=0.300E-01 > FAIL > > Value= 37093.921880 Target= 37094.375000 Tolerance= 1.00 > > aermod FAILED4 fails and2 passes Having been down this path so many times -- any time a benchmark shows a big improvement, my first reaction is that something has been mis- compiled. If not, then I worry that it's just some ugly secondary cache effect from variables moving around on the stack or something similar. Only once I can convince myself that neither of those is the case do I get excited about the improvement. Perhaps I've become somewhat jaded through the years :-) Jeff > > Richard.
Re: autoconf 2.61 on debian etch and GCC
* Andreas Schwab wrote on Tue, Jul 03, 2007 at 06:58:56PM CEST: > To avoid expanding $progname twice: > > eval "set x \"\$progname\" $ac_configure_args" Indeed; thanks! Updated proposed patch (I have no maintainer privs). :ADDPATCH configure: ChangeLog: 2007-07-03 Ralf Wildenhues <[EMAIL PROTECTED]> * configure.ac (TOPLEVEL_CONFIGURE_ARGUMENTS): Use $ac_configure_args, not "$@". Do not use `set --'. (baseargs): Likewise. * configure: Regenerate. Index: configure.ac === --- configure.ac(revision 126264) +++ configure.ac(working copy) @@ -88,7 +88,8 @@ # Export original configure arguments for use by sub-configures. # Quote arguments with shell meta charatcers. TOPLEVEL_CONFIGURE_ARGUMENTS= -set -- "$progname" "$@" +eval "set x \"\$progname\" $ac_configure_args" +shift for ac_arg do case "$ac_arg" in @@ -2090,7 +2091,8 @@ baseargs= keep_next=no skip_next=no -eval "set -- $ac_configure_args" +eval "set x $ac_configure_args" +shift for ac_arg do if test X"$skip_next" = X"yes"; then
Question regarding getting .rodata into the .data section instead of .text
Is there a command option (for GCC, G++, and/or GAS) that will force .rodata (like jump tables) to be located in the .data section? Thanks, Rich Rich Tuttle Ulticom, Inc. (856)787-2745 [EMAIL PROTECTED]
Re: Question regarding getting .rodata into the .data section instead of .text
"Richmond Tuttle" <[EMAIL PROTECTED]> writes: > Is there a command option (for GCC, G++, and/or GAS) that will force > .rodata (like jump tables) to be located in the .data section? You can use a linker script to override the default placement. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Wow!
On 7/3/07, Jeffrey Law <[EMAIL PROTECTED]> wrote: On Tue, 2007-07-03 at 13:07 +0200, Richard Guenther wrote: > On 7/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: > > > Daniel Berlin wrote: > > > > I'm curious if it was the pre/fre changes. can you try -fno-tree-pre > > > > and -fno-tree-fre and see if it slows down again? > > > Adding -fno-tree-pre slows aermod back to 33.942s. Nice optimization. ;) > > Thanks. > > (You really should thank richard guenther and steven bosscher, who > > continually beat me up till i finished it :P) > > > > Unfortunately, this "improvement" is a miscompare: > > > Value= 2190.9357900 Target= 2191.1145000 Tolerance=0.100E-02 > FAIL > > Value= 34310.421880 Target= 34310.421880 Tolerance=0.300E-01 > > Value= 4260.5888700 Target= 4260.9716800 Tolerance=0.500E-01 > FAIL > > Value= 37093.921880 Target= 37094.375000 Tolerance=0.200E-01 > FAIL > > Value= 7924.6811500 Target= 7924.8842800 Tolerance=0.300E-01 > FAIL > > Value= 37093.921880 Target= 37094.375000 Tolerance= 1.00 > > aermod FAILED4 fails and2 passes Having been down this path so many times -- any time a benchmark shows a big improvement, my first reaction is that something has been mis- compiled. If not, then I worry that it's just some ugly secondary cache effect from variables moving around on the stack or something similar. Only once I can convince myself that neither of those is the case do I get excited about the improvement. Perhaps I've become somewhat jaded through the years :-) Of course in this case (the above is with -ffast-math) one could say I got what I asked for. Fast but maybe (slightly) inaccurate. Of course we miss the tolerances by more than an order of magnitude. Richard.
How should gcc handle "-shared -pie" and "-pie -shared"?
On Tue, Jul 03, 2007 at 08:50:29PM +0200, Andreas Schwab wrote: > "H.J. Lu" <[EMAIL PROTECTED]> writes: > > > Where is it documented. > > Nowhere. > > > Gcc 4.3 just passes "-shared -pie" to linker. I don't see gcc driver > > remove -pie. > > Look at the use of Scrt1.o. It's much of a mess. > Gcc currently ignores -pie when there is a -shared due to treatment of Scrt1.o. However, this behavior is undocumted. We like to match the linker behavior with gcc. Is this gcc behavior intentional? Will this gcc behavior ever change? Can we document this gcc behavior? BTW, this is another problem which can be handled like: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885 H.J.
Re: MPFR 2.3.0 Release Candidate
On Tue, 3 Jul 2007, Vincent Lefevre wrote: > The release of MPFR 2.3.0 is imminent. Please help to make this > release as good as possible by downloading and testing this > release candidate: > > http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.tar.bz2 > http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.tar.gz > http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.zip > [...] > Please send success and failure reports to <[EMAIL PROTECTED]>. Works for me on sparc-sun-solaris2.10 and sparc64-sun-solaris2.10. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Question regarding getting .rodata into the .data section instead of .text
On Tuesday 03 July 2007, Andreas Schwab wrote: > "Richmond Tuttle" <[EMAIL PROTECTED]> writes: > > Is there a command option (for GCC, G++, and/or GAS) that will force > > .rodata (like jump tables) to be located in the .data section? > > You can use a linker script to override the default placement. However gcc will still use the RO data addressing model, which means it's only of limited use. Paul
RE: no_new_pseudos
On 03 July 2007 22:14, Kenneth Zadeck wrote: > David Edelsohn points out that some of the expanders could have all of > this code removed since expanders only run before reload. I do not know > how to figure this out. I thought that movMM expanders could still be run /during/ reload, at the very least? Or does "some of the expanders" mean "excluding movMM" in particular? (I'm not sure if I should infer the word "those" between "removed since" and "expanders only"). cheers, DaveK -- Can't think of a witty .sigline today
RE: no_new_pseudos
> I thought that movMM expanders could still be run /during/ reload, at the > very least? Or does "some of the expanders" mean "excluding movMM" in > particular? (I'm not sure if I should infer the word "those" between > "removed since" and "expanders only"). Certainly movMM can run during reload. It was at least the case at some point (don't know if it still is) that addMM3 can run as well. Possibly others, but I think not.
Re: Writing to Subversion via Git
Ollie Wild wrote: As an aside to the ongoing git repository discussion, I'm curious if anyone has experimented with committing changes to the GCC repository via git-svn's dcommit command. I'm curious to know if it plays nicely with GCC's svn commit machinery. It should. git-svn is bidirectional. Initially, I thought pushing would require the git tree to be hosted on gcc.gnu.org, so it could access the svn repository without using the developer ssh key. But I wasn't thinking distributed! If you clone my gcc tree on git.infradead.org, you'll also end up cloning all the git-svn info. So you can use git-svn yourself to push your changes to gcc.gnu.org! The only problem is that git-svn uses a very inefficient format to store its metadata. It's a few gigs to rsync. -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Re: RFC: Make dllimport/dllexport imply default visibility
Geoffrey Keating wrote:
> GCC's concept of visibility is very different to that of some other
> compilers.
Yes, and that may be a problem. For some features, we want to have GNU
semantics that are consistent that across platforms; for others, we want
to match other compilers on a particular platform.
To be clear, I don't have any objection to the semantics you stated,
from the point of view of first principles of language design. But,
they do not match existing practice on various systems -- and I consider
that a serious problem. In particular, ARM SymbianOS is a system that
has specifically defined DLL attributes in terms of ELF visibility.
There's no choice about the semantics on that system, including the fact
that the first "S" below is a valid class on that system.
Fortunately, for:
> In respect of this specific example, the compiler should not give any
> effect to the attribute on 'f' in:
>
> struct __attribute__((visibility("hidden"))) S {
> void f() __attribute__((visibility("default")));
> }
>
> because another shared library can define:
>
> struct __attribute__((visibility("default"))) S {
> void f();
> }
we can be generous. In particular, we can do what the user asks with
the first "S", i.e., give "f" default visibility. There's no inherent
problem there. We can then detect that there are two "S::f" when both
shared libraries are loaded (if we think that's a useful check), or we
can just call it undefined behavior, as it would be if there were no
visibility markers in this example, but there were conflicting
definitions of "S::f".
We could of course issue a warning, or, I guess, an error. I see this
as a style issue, so a warning seems better to me, but if Darwin wants
to forbid giving member functions more visibility than their containing
classes, that's not for me to say.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
On 03/07/2007, at 5:13 PM, Mark Mitchell wrote: Geoffrey Keating wrote: GCC's concept of visibility is very different to that of some other compilers. Yes, and that may be a problem. For some features, we want to have GNU semantics that are consistent that across platforms; for others, we want to match other compilers on a particular platform. Yes. __attribute__((visibility)) has consistent GNU semantics, and other features (eg. -fvisibility-ms-compat, __dllspec) match other compilers. To be clear, I don't have any objection to the semantics you stated, from the point of view of first principles of language design. But, they do not match existing practice on various systems -- and I consider that a serious problem. It's not possible for any semantics to match existing practise on every system, since systems differ. As I said, I think that it would be best for GCC to have one standard consistent set of semantics for __attribute__((visibility)), and then if it's desirable to match existing practise on other systems that should be done with other features explicitly labelled as such. I hope you don't mean that there are other system's compilers using the '__attribute__((visibility))' syntax in a way that's incompatible with GCC. If there are, I think the appropriate response is a combination of fixincludes and a polite e-mail asking them to stop. smime.p7s Description: S/MIME cryptographic signature
Re: no_new_pseudos
Dave Korn wrote: > On 03 July 2007 22:14, Kenneth Zadeck wrote: > > >> David Edelsohn points out that some of the expanders could have all of >> this code removed since expanders only run before reload. I do not know >> how to figure this out. >> > > I thought that movMM expanders could still be run /during/ reload, at the > very least? Or does "some of the expanders" mean "excluding movMM" in > particular? (I'm not sure if I should infer the word "those" between "removed > since" and "expanders only"). > > cheers, > DaveK > I believe that david meant the expanders except the mm ones. However this is not my department. kenny
Re: RFC: Make dllimport/dllexport imply default visibility
Geoffrey Keating wrote:
> Yes. __attribute__((visibility)) has consistent GNU semantics, and
> other features (eg. -fvisibility-ms-compat, __dllspec) match other
> compilers.
The only semantics that make sense on SymbianOS are the ones that allow
default visibility within a hidden class. So, whether or not there's a
command-line option, it's going to be on by default, and therefore is
going to be inconsistent with a system on which GCC disallows (or
ignores) that.
However, since this is a conservative extension to your semantics (all
valid programs remain valid and have the same meaning), I don't
understand why you think this is a problem. The SymbianOS semantics
give the programmer more choices, which, as with most such things, the
programmer can use in good ways or bad.
The good news is that the change that I made caused the compiler to stop
silently ignoring explicit requests from the programmer and without
changing the meaning of any valid programs. So, we can (and do) still
have consistent GNU semantics across platforms with this change.
> I hope you don't mean that there are other system's compilers using the
> '__attribute__((visibility))' syntax in a way that's incompatible with
> GCC. If there are, I think the appropriate response is a combination of
> fixincludes and a polite e-mail asking them to stop.
I don't know if there are, but I certainly wouldn't be surprised. The
GNU attribute syntax is implemented in the EDG front end and there are
lots of EDG-based compilers.
RealView 3.0.x doesn't support the visibility attribute, but it does
support other GNU attributes. __declspec(dllexport) and
__attribute__((visibility("default"))) are synonyms on SymbianOS. It
would be odd for them to be different because dllexport is defined in
terms of visibility. It seems unlikely to me that RealView would add
the visibility attribute but disallow usage that is valid with the
__declspec syntax, but, of course, I can't speak for ARM.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
Yes. __attribute__((visibility)) has consistent GNU semantics, and
other features (eg. -fvisibility-ms-compat, __dllspec) match other
compilers.
The only semantics that make sense on SymbianOS are the ones that
allow
default visibility within a hidden class.
I think we're talking past each other. What semantics exactly are
these? Who created them? Where are they implemented? Are they
documented? Who documented them? Why can't they be changed?
I don't know what you mean by 'make sense'. Clearly these semantics
do make sense; no-one's brain has exploded yet. You probably mean
'compatible with the system headers' or possibly 'that I like' or
perhaps 'that my users like' or 'that my users understand'.
So, whether or not there's a
command-line option, it's going to be on by default, and therefore is
going to be inconsistent with a system on which GCC disallows (or
ignores) that.
Maybe, and maybe not. In particular, an option that changes defaults
is one thing, but if the user overrides the default with GCC-specific
syntax and the compiler does something different, that's another
thing altogether.
I hope you don't mean that there are other system's compilers
using the
'__attribute__((visibility))' syntax in a way that's incompatible
with
GCC. If there are, I think the appropriate response is a
combination of
fixincludes and a polite e-mail asking them to stop.
I don't know if there are, but I certainly wouldn't be surprised. The
GNU attribute syntax is implemented in the EDG front end and there are
lots of EDG-based compilers.
This doesn't quite count, because EDG implements it to be compatible
with GCC, and I'm sure if you find it isn't then they'll fix it (or
at least acknowledge it as a bug).
RealView 3.0.x doesn't support the visibility attribute, but it does
support other GNU attributes.
So it can't conflict.
__declspec(dllexport) and
__attribute__((visibility("default"))) are synonyms on SymbianOS.
As far as I can tell they're synonyms everywhere, although my
understanding is subject to change through bug reports. The question
is about "__attribute__((visibility("hidden")))".
If you have -fvisibility-ms-compat switched on, then
struct S {
void f() __dllspec(dllimport);
};
is entirely valid and does what you want to do. So if you're just
trying to be compatible with Visual Studio, or trying to be
compatible with people trying to be compatible with Visual Studio,
that's already implemented.
And likewise, for new code, the answer is to not make 'S' hidden in
the first place, which by coincidence is also:
struct S {
void f() __dllspec(dllimport);
};
or so.
smime.p7s
Description: S/MIME cryptographic signature
GCC 4.2.1 Status Report (2007-07-03)
Summary --- The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. I plan to make this release unless I am made aware of P1 regressions relative to GCC 4.2.0. At present, there are 29 P1s open against GCC 4.2.x, virtually all of which are also present in GCC 4.3. Thus, you can kill two birds with one stone by attacking these problems. Half of these 29 P1s are C++ problems, including, mostly, ICEs on valid code. I will do what I can to attack those, but I would also appreciate the help of my fellow C++ maintainers (Nathan, Jason) and any other folks who would like to help out. There are also plenty of wrong-code problems, like: PR 32004: can't find a register in class... PR 32327: Incorrect stack sharing causing removal ... PR 32328: -fstrict-aliasing causes skipped code PR 32533: miscompilation with -O3 -ffast-math -ftree-vectorize -march=native Statistics -- P1: 29 P2: 113 P3: 2 Total: 144 Previous Report --- http://gcc.gnu.org/ml/gcc/2007-05/msg00670.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Geoffrey Keating wrote:
> On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
>
>> Geoffrey Keating wrote:
>>
>>> Yes. __attribute__((visibility)) has consistent GNU semantics, and
>>> other features (eg. -fvisibility-ms-compat, __dllspec) match other
>>> compilers.
>>
>> The only semantics that make sense on SymbianOS are the ones that allow
>> default visibility within a hidden class.
>
> I think we're talking past each other. What semantics exactly are
> these? Who created them? Where are they implemented? Are they
> documented? Who documented them? Why can't they be changed?
SymbianOS allows you to declare a member dllimport or dllexport even
though the class is declared with hidden visibility. dllimport and
dllexport imply default visibility.
The semantics, as I described earlier in this thread, are simple: the
visibility you specify for the class is the default for all members,
including vtables and other compiler-generated stuff, but the user may
explicitly override that by specifying a visibility for the member. The
semantics I describe are a conservative extension to the semantics you
describe; they are operationally identical, except that the semantics
you describe forbid giving a member more visibility than its class. The
change that I made was to stop G++ from silently ignoring such a request.
I don't know who created the SymbianOS semantics, but they are
implemented in ARM's RealView compiler, which is the compiler used to
build SymbianOS and most of the applications for that system. Those
semantics go back to pre-ELF SymbianOS but are preserved in the current
ELF-based SymbianOS explicitly in terms of ELF visibility. They're
documented, at least partially, in various places, including the ARM
EABI and the RealView compiler. They can't be changed because there are
millions of lines of code that require them.
>> So, whether or not there's a
>> command-line option, it's going to be on by default, and therefore is
>> going to be inconsistent with a system on which GCC disallows (or
>> ignores) that.
>
> Maybe, and maybe not. In particular, an option that changes defaults is
> one thing, but if the user overrides the default with GCC-specific
> syntax and the compiler does something different, that's another thing
> altogether.
Here, the compiler was silently ignoring an attribute explicitly given
by the user. I changed the compiler not to ignore the attribute. That
did not alter the GNU semantics, unless we consider it an intentional
feature that we ignored the attribute. (I can't imagine that we would
consider that a feature; if for some reason we are going to refuse to
let users declare members with more visibility than specified for the
class, we should at least issue an error message.)
>>> I hope you don't mean that there are other system's compilers using the
>>> '__attribute__((visibility))' syntax in a way that's incompatible with
>>> GCC. If there are, I think the appropriate response is a combination of
>>> fixincludes and a polite e-mail asking them to stop.
>>
>> I don't know if there are, but I certainly wouldn't be surprised. The
>> GNU attribute syntax is implemented in the EDG front end and there are
>> lots of EDG-based compilers.
>
> This doesn't quite count, because EDG implements it to be compatible
> with GCC, and I'm sure if you find it isn't then they'll fix it (or at
> least acknowledge it as a bug).
EDG licensees routinely modify the front end. The attribute handling is
specifically designed to be easy to extend. ARM has already confirmed
(on this list) that the RealView behavior is intentional. It seems
unlikely that it will go away.
>> RealView 3.0.x doesn't support the visibility attribute, but it does
>> support other GNU attributes.
>
> So it can't conflict.
I don't find that a convincing argument. The two compilers have
different syntaxes for specifying ELF visibility. But, they meant the
same thing in all respects (so far as I know) except for this case. We
could invent some alternative attribute to mark a class "hidden, but in
the SymbianOS way that allows you to override the visibility of members,
not in the GNU way that doesn't", but that seems needlessly complex.
Concretely, are you arguing that my patch was a bad change? If so, do
you feel that silently discarding the attribute on members was a good
thing? Do you feel that preventing users from making members more
visible than classes must be an error, rather than just considering it
in questionable taste?
> If you have -fvisibility-ms-compat switched on, then
>
> struct S {
> void f() __dllspec(dllimport);
> };
That, however, is not quite the case in question; rather it's:
struct S __declspec(notshared) {
void f() __declspec(dllimport); // Or dllexport
};
The class itself is explicitly declared with hidden visibility. And, as
far as I know, there's no desire on SymbianOS to make vtables and such
visible, even when class members are not, which seems to be
