Re: No effect of -fshort-enums..is it a bug
* Andreas Schwab <[EMAIL PROTECTED]> [050921 17:46]: > "Gaurav Gautam, Noida" <[EMAIL PROTECTED]> writes: > > Does -fshort-enum guides the size of enumeration type or the size of > > enumerator constant ? > An enumerator constant is not an object, thus it has no size of its own. > Since the enumerator constants are of type int, not the enum type, > -fshort-enum should not have any effect on their type. I think some warning for this case would be nice. While the value is looks clearly definied, I think almost all cases where this is actually used will be errors. (The same with sizeof(void), which most likely only happens with p=malloc(sizeof(*p)) from macros). Is there already a warning against that (I cannot find any in the info page) or is there any chance to get such a thing implemented? Hochachtungsvoll, Bernhard R. Link
RE: On which platforms is -fvisibility supported?
Original Message >From: Jonathan Turkanis >Sent: 23 September 2005 01:43 > If the implication is that users should grep the source code before asking > questions, that's not a reasonable expectation. It is actually the _fundamental_ principle under which this particular mailing list operates! cheers, DaveK -- Can't think of a witty .sigline today
Re: Questionable code in fixup_reorder_chain
> Hi Jan,
>
> I think fixup_reorder_chain contains questionable code to cope with a
> pathological case:
>
> /* The degenerated case of conditional jump jumping to the next
>instruction can happen on target having jumps with side
>effects.
>
>Create temporarily the duplicated edge representing branch.
>It will get unidentified by force_nonfallthru_and_redirect
>that would otherwise get confused by fallthru edge not pointing
>to the next basic block. */
> if (!e_taken)
> {
> rtx note;
> edge e_fake;
> bool redirected;
>
> e_fake = unchecked_make_edge (bb, e_fall->dest, 0);
>
> redirected = redirect_jump (BB_END (bb),
> block_label (bb), 0);
> gcc_assert (redirected);
>
> Note the call to redirect_jump that creates a loop. It is responsible for
> the
> ICE on the attached Ada testcase with the 3.4.5pre compiler at -O3 because
> the
> edge and the jump disagree on the target.
Duh. The code is ineed quite ugly side case.
>
> The final patch: http://gcc.gnu.org/ml/gcc-cvs/2003-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?
I actually believe there was reason for creating the loop (ie
redirecting the edge to anything else than the fallthru egdge
destination) as otherwise we screwed up in
force_nonfallthru_and_redirect and this function (called via
force_nonfallthru) is supposed to redirect the jump back to proper
destination. This is remarkably ugly hack :(
Would be possible to at leat see the RTL and precise ICE this code is
causing?
Honza
Re: Problem with the special live analyzer in global alloc
Hello, I've opened a bugzilla for this: #24034 Bye, -Andreas-
RE: No effect of -fshort-enums..is it a bug
>
> > Hi Gaurav,
> >
> >> Please confirm which of the two outputs is correct and why is there
a
> > difference in the output of two versions of compiler?
> >
> > Both outputs are "correct".
> >
>
>
> No, the standard is entirely unambiguous:
>
>
> 6.4.4.3 Enumeration constants
> Syntax
> 1 enumeration-constant:
> identifier
> Semantics
> 2 An identifier declared as an enumeration constant has type int.
>
>
> The enumeration constants denoted by the identifiers a, b, and c are
> therefore of type int and must have size 4 (on a standard 32-bit
system),
> regardless of the size of the enumerated type aa.
Thank you all for your replies. But I have another question to ask
Consider another example
#include
int main()
{
enum ff {
p = 0, q = 4294967295, r
};
printf("size = %d %d %d\n", sizeof(enum ff),sizeof(q),
sizeof(r));
printf("value= %d %d %d\n", p,q,r);
}
Its output is with default options on gcc :
size = 8 8 8
value= 0 -1 0
Enumerator are supposed to be int and must have size 4. why are they
being treated as long here and taking 8 bytes? Size of int on my machine
is 4.
Also the compiler doesn't even gives a warning when the tc is compiled.
>
>
> > (Neither output is compliant to the standard, of course, as -fshort-
> enums
> > is a deviation from the standard.)
>
> Nope, the standard is entirely unambiguous:
>
>
> 6.7.2.2 Enumeration specifiers
>
> 4 Each enumerated type shall be compatible with an integer type. The
> choice
> of type is
> implementation-defined,97) but shall be capable of representing the
values
> of all the
> members of the enumeration. The enumerated type is incomplete until
after
> the } that
> terminates the list of enumerator declarations.
>
>
> The choice of what integer type to use to store a value of an
enumerated
> type is implementation-defined, and if a char is big enough to
represent
> all
> the values, the implementation is at liberty to use a char.
>
>
>
> cheers,
> DaveK
> --
> Can't think of a witty .sigline today
Re: Problem with the special live analyzer in global alloc
On Fri, 2005-09-23 at 15:50 +0200, Andreas Krebbel wrote: > Hello, > > I've opened a bugzilla for this: #24034 Just as an FYI, Kenny and I have replaced the global liveness analyzer with one from df.c, and removed the need for make_accurate_live_analysis (ie df.c now does the partial avail liveness stuff). We are currently in the process of changing all the other users of life analysis to use the df.c liveness, which should solve this problem (since they will all then use the accurate life analysis). > > Bye, > > -Andreas-
Re: Questionable code in fixup_reorder_chain
> I actually believe there was reason for creating the loop (ie > redirecting the edge to anything else than the fallthru egdge > destination) as otherwise we screwed up in > force_nonfallthru_and_redirect and this function (called via > force_nonfallthru) is supposed to redirect the jump back to proper > destination. This is remarkably ugly hack :( Note, however, the differences between the version you posted and the version you commited; in particular, the comment about the loop totally disappeared in between, while the code didn't. > Would be possible to at leat see the RTL and precise ICE this code is > causing? It is reproducible with 3.4.5pre at -O3 on x86: [EMAIL PROTECTED]:~/build/gcc-3_4-branch/native32> gcc/xgcc -Bgcc -S -O3 p.adb -Igcc/ada/rts +===GNAT BUG DETECTED==+ | 3.4.5 20050910 (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
Re: No effect of -fshort-enums..is it a bug
Hi Gaurav, You could do this... q = 4294967295U Or you could use -std=iso9899:1999 (perhaps with -pedantic) for the compiler to produce an error. Assuming you are using GCC 4.x. Or if you *want* to allow that, you could do this... -std=gnu99 I'm guessing as to which version of GCC you are using, and what command line options you used to compile with, and your platform's architecture. HTH, --Eljay
Re: On which platforms is -fvisibility supported?
Dave Korn wrote: > Original Message >> From: Jonathan Turkanis >> Sent: 23 September 2005 01:43 >> If the implication is that users should grep the source code before asking >> questions, that's not a reasonable expectation. > It is actually the _fundamental_ principle under which this particular > mailing list operates! Jonathan Turkanis wrote: > I've asked this question twice at gcc-help, but got no response. I didn't even get a sarcastic response! :-P The end result is that a *user* with a question about the documentation, must grep the souce. That's not a reasonable expectation. > cheers, > DaveK -- Jonathan Turkanis www.kangaroologic.com
gcc-4.0.2: supporting -fvisibility for solaris ld
The recommended way to build gcc-4.0.2 on Solaris 10 x86 is to use the binutils assembler and the solaris linker: http://gcc.gnu.org/install/specific.html#ix86-x-solaris210 This works, as long as you suppress HAVE_GAS_COMDAT_GROUP ( see http://gcc.gnu.org/ml/gcc/2005-04/msg01332.html ) but the resulting compiler does not support -fvisibility in any useful way, because the solaris linker fails the configure check "checking linker for .hidden support". The solaris linker does support .hidden though, so I am looking into adding support for -fvisibility with solaris ld. I have run into a problem, and I have a few questions. If, for purposes of experimentation, I hack up configure so that it sets HAVE_GAS_HIDDEN unconditionally, then make bootstrap succeeds, and I can in fact use the visibility flags, pragmas, and attributes. The resulting binaries show that symbols are correctly marked as LOCL and GLOB in accordance with the visibility selections. So far, so good. The problems start when I specify an -march argument in 32 bit mode. If when compiling I pass -march=pentium, -march=pentium2, etc., I get errors when trying to link more than one object file: ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file thunk32.o type=FUNC; file visibility32.o type=FUNC); If I look at the assembly listings in thunk32.s and visibility32.s I see the same listing that defines __i686.get_pc_thunk.bx in both files: .section.gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits .globl __i686.get_pc_thunk.bx .hidden __i686.get_pc_thunk.bx .type __i686.get_pc_thunk.bx, @function __i686.get_pc_thunk.bx: movl(%esp), %ebx ret In these same object files, there are other .gnu.linkonce sections, but the symbol is always marked .weak: .weak _ZTV3Foo .section.gnu.linkonce.d._ZTV3Foo,"aw",@progbits .align 8 .type _ZTV3Foo, @object .size _ZTV3Foo, 16 _ZTV3Foo: .long 0 So unlike all of the other .gnu.linkonce sections, where the contained symbol is marked as .weak, __i686.get_pc_thunk.bx is marked .globl. To my mind, the linker is right to complain when linking two objects containing that definition. With COMDAT group support disabled, is it true that part of gcc's implementation of .gnu.linkonce semantics is to make the symbol in the .gnu.linkonce section weak? If so, should symbols like __i686.get_pc_thunk.* also be weak in this instance, instead of global? If not, would someone please explain why not? Would enabling COMDAT group support (the sun linker does support it) remove this problem? If so, can anyone see a way around the fact that the solaris linker considers relocations against discarded symbols a fatal error, and it is nearly inevitable that when using COMDAT groups there will be relocations in the .eh_frame or debug_info sections against .gnu.linkonce sections that will be discarded? Sorry for the length, or if this is all somehow way off base; I'm new to gcc internals... Thanks, Andrew
Re: On which platforms is -fvisibility supported?
Robert Dewar wrote: Jonathan Turkanis wrote: Jonathan Turkanis wrote: > I've asked this question twice at gcc-help, but got no response. I didn't even get a sarcastic response! :-P Well there is no guaranteed response, given this is a volunteer activity. You can't complain if you don't get a response from the volunteer group (well you can complain, but no one is oblligated to pay any attention to your complaint). Obviously there's no guarantee. But don't tell me I can't complain. ;-) I'm a volunteer author and maintainer of several open source projects, and I never tell users to "use the source, Luke" if they have a question which should be answered in the documentation. GCC has a real problem in this area. The end result is that a *user* with a question about the documentation, must grep the souce. If you come to this mailing list, which is for gcc developers, that is part of the price of admission, this list is not for users, but for developers. That's not a reasonable expectation. It is for developers, and if you are not a developer, you are really in the wrong place. Break it down how you like; it's still true that it's not reasonable to expect a user with a question about the documentation to grep the source before asking. -- Jonathan Turkanis www.kangaroologic.com
Re: GCC 4.0.2 RC3
Eric Botcazou wrote: > > The GCC 4.0.2 RC3 prerelease is spinning now. > > Regressions on Solaris 2.6, 7, 8 and 9: > FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test > FAIL: ext/mt_allocator/check_delete.cc execution test > FAIL: ext/mt_allocator/check_new.cc execution test > FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test > FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test > FAIL: ext/mt_allocator/deallocate_local_thread-1.cc execution test > FAIL: ext/mt_allocator/deallocate_local_thread-3.cc execution test > FAIL: ext/mt_allocator/tune-1.cc execution test > 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 This patch: 2005-09-19 Benjamin Kosnik <[EMAIL PROTECTED]> 2005-09-19 Jakub Jelinek <[EMAIL PROTECTED]> to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you investigating these failures? We need to get this resolved ASAP. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0.2 RC3
Christian Joensson wrote: > FAIL: g++.dg/other/profile1.C (test for excess errors) > FAIL: g++.old-deja/g++.law/profile1.C (test for excess errors) > XPASS: g++.old-deja/g++.other/init5.C execution test > FAIL: g++.old-deja/g++.robertl/eb83.C (test for excess errors) Do you have g++.log output for these failures? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
c++ default operators
Hi list I was told that gcc by default, for every class creates operator =, and probably something else. This makes binary file bit larger than it suppose to be. Is it true, and if so, why this is the case ? Can gcc simply not generate that operator? -- Vercetti
Re: [RFC] propagating loop dependences from trees to RTL (for SMS)
On Sep 22, 2005, at 7:39 PM, Kenneth Zadeck wrote: I will pull a patch together tomorrow. There is currently nothing in the code for keeping the region stuff up to date as changes are made to the cfg. For most changes this would not be hard, but for some it is really hard. OK. I've code (about 6 months old) to keep loop info update during jump threading. I couldn't finish that work to keep loop info upto date from very beginning till end at that time. But now, I am seeing some day light, so hopefully I'll get back to it soon. - Devang Daniel Berlin wrote: On Thu, 2005-09-22 at 18:49 -0700, Devang Patel wrote: On Sep 22, 2005, at 2:32 AM, Steven Bosscher wrote: On Sep 22, 2005 11:25 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: 4. Other ideas? Preserving the information about loops throughout the optimizations, and just keeping this information attached at the loop description would by far be the cleanest approach -- admitedly also the one that requires the greatest amount of work. Shouldn't the regions patch allow us to preserve loops quite easily? Any pointer to this "regions patch" ? Thanks, Ask kenny for a copy. - Devang
[4.0] version '400p', expected version '400*'
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: (auroralinux corona + rathann's and rzm's FC3 updates) binutils-2.16.91.0.2-4.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.3-22.sparc.sparc gcc4-4.0.0-0.41.sparc.sparc glibc-2.3.5-0.fc3.1.sparcv9 glibc-2.3.5-0.fc3.1.sparc64 glibc-devel-2.3.5-0.fc3.1.sparc glibc-devel-2.3.5-0.fc3.1.sparc64 glibc-headers-2.3.5-0.fc3.1.sparc glibc-kernheaders-2.6-20sparc.sparc gmp-4.1.4-3sparc.sparc gmp-4.1.4-3sparc.sparc64 gmp-devel-4.1.4-3sparc.sparc gmp-devel-4.1.4-3sparc.sparc64 kernel-2.6.12-1.1505sp3.sparc64 package kernel-devel is not installed package kernel-smp is not installed libgcc-3.4.3-22.sparc.sparc libgcc-3.4.3-22.sparc.sparc64 libstdc++-3.4.3-22.sparc.sparc libstdc++-3.4.3-22.sparc.sparc64 libstdc++-devel-3.4.3-22.sparc.sparc libstdc++-devel-3.4.3-22.sparc.sparc64 make-3.80-5.sparc nptl-devel-2.3.5-0.fc3.1.sparcv9 tcl-8.4.7-2.sparc LAST_UPDATED: Fri Sep 23 04:57:40 UTC 2005 Currently, using bubblestrap, in gcc cvs 4.0 branch, I get failures like this: Executing on host: /usr/local/src/branch/objdir/gcc/testsuite/../g++ -B/usr/local/src/branch/objdir/gcc/testsuite/../ /usr/local/src/branch/gcc/gcc/testsuite/g++.dg/other/profile1.C -nostdinc++ -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/local/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libstdc++-v3/testsuite -fmessage-length=0 -fnon-call-exceptions -fprofile-arcs -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/src/.libs -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libiberty -lm -m64 -o ./profile1.exe(timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/g++.dg/other/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' output is: /usr/local/src/branch/gcc/gcc/testsuite/g++.dg/other/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' FAIL: g++.dg/other/profile1.C (test for excess errors) Excess errors: /usr/local/src/branch/gcc/gcc/testsuite/g++.dg/other/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' Executing on host: /usr/local/src/branch/objdir/gcc/testsuite/../g++ -B/usr/local/src/branch/objdir/gcc/testsuite/../ /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.law/profile1.C -nostdinc++ -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/local/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libstdc++-v3/testsuite -fmessage-length=0 -pg -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/src/.libs -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libiberty -lm -m64 -o ./profile1.exe(timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.law/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' output is: /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.law/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' PASS: g++.old-deja/g++.law/profile1.C Profiling unsupported (test for bogus messages, line ) FAIL: g++.old-deja/g++.law/profile1.C (test for excess errors) Excess errors: /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.law/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' Executing on host: /usr/local/src/branch/objdir/gcc/testsuite/../g++ -B/usr/local/src/branch/objdir/gcc/testsuite/../ /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.robertl/eb83.C -nostdinc++ -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/local/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libstdc++-v3/testsuite -fmessage-length=0 -fprofile-arcs -ftest-coverage -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/src/.libs -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libiberty -lm -m64 -o ./eb83.exe(timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.robertl/eb83.C:1: warning: 'eb83.gcda' is version '400p', expected version '400*' output is: /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.robertl/eb83.C:1: warning: 'eb83.gcda' is version '400p', expected version '400*' FAIL: g++.old-deja/g++.robertl/eb83.C (test for excess errors) Excess errors: /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.
Re: GCC 4.0.2 RC3
On 9/23/05, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Christian Joensson wrote: > > > FAIL: g++.dg/other/profile1.C (test for excess errors) > > FAIL: g++.old-deja/g++.law/profile1.C (test for excess errors) > > XPASS: g++.old-deja/g++.other/init5.C execution test > > FAIL: g++.old-deja/g++.robertl/eb83.C (test for excess errors) > > Do you have g++.log output for these failures? sorry, I didn't see this before I just sent off this: http://gcc.gnu.org/ml/gcc/2005-09/msg00777.html -- Cheers, /ChJ
Re: GCC 4.0.2 RC3
> to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you > investigating these failures? We need to get this resolved ASAP. I'm on it. -benjamin
Re: GCC 4.0.2 RC3
Benjamin Kosnik wrote: >>to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you >>investigating these failures? We need to get this resolved ASAP. > > > I'm on it. Thanks! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: warning about classpath import
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> What version of CVS are you using, and does it speak the "-X" Dave> option (new in 1.12.x)? Dave> http://ximbiot.com/cvs/manual/cvs-1.12.12/cvs_16.html#SEC155 By my reading the -X option requires 1.12 to be running on the server as well. So, I'm just going to do an old-style temporarily-breaking import; I'd rather not mess about without changing the installed cvs. Tom
Re: [RFC] patch to fix an ICE involving sign-extract of mmx expression
On Thu, Sep 22, 2005 at 01:21:06PM -0700, Fariborz Jahanian wrote: > /* Avoid creating invalid subregs, for example when > simplifying (x>>32)&255. */ > ! if (final_word >= GET_MODE_SIZE (inner_mode) > ! || (final_word % GET_MODE_SIZE (tmode)) != 0) > return NULL_RTX; I think you should just call validate_subreg. Ok with that change. r~
Re: [RFC] patch to fix an ICE involving sign-extract of mmx expression
On Sep 23, 2005, at 12:41 PM, Richard Henderson wrote: On Thu, Sep 22, 2005 at 01:21:06PM -0700, Fariborz Jahanian wrote: /* Avoid creating invalid subregs, for example when simplifying (x>>32)&255. */ ! if (final_word >= GET_MODE_SIZE (inner_mode) ! || (final_word % GET_MODE_SIZE (tmode)) != 0) return NULL_RTX; I think you should just call validate_subreg. Ok with that change. Yes. Will do so. - fj r~
Re: gcc-4.0.2: supporting -fvisibility for solaris ld
On Friday, September 23, 2005, at 08:31 AM, Andrew Morrow wrote:
If I look at the assembly listings in thunk32.s and visibility32.s I
see the same listing that defines __i686.get_pc_thunk.bx in both
files:
.section
.gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits
.globl __i686.get_pc_thunk.bx
.hidden __i686.get_pc_thunk.bx
I think this is a port problem. Step the code that does:
DECL_ONE_ONLY (decl) = 1;
(*targetm.asm_out.unique_section) (decl, 0);
named_section (decl, NULL, 0);
(*targetm.asm_out.globalize_label) (asm_out_file, name);
fputs ("\t.hidden\t", asm_out_file);
from i386.c:ix86_file_end. For group COMDAT, the label will (should)
be external and everybody else should cope with that. For
_gnu_linkonce type things, it will (should) be weak.
So unlike all of the other .gnu.linkonce sections, where the contained
symbol is marked as .weak, __i686.get_pc_thunk.bx is marked .globl. To
my mind, the linker is right to complain when linking two objects
containing that definition.
Correct.
With COMDAT group support disabled, is it true that part of gcc's
implementation of .gnu.linkonce semantics is to make the symbol in the
.gnu.linkonce section weak?
Yes, gcc should make it weak, one way, or another.
If so, should symbols like __i686.get_pc_thunk.* also be weak in this
instance, instead of global?
Yes.
Would enabling COMDAT group support (the sun linker does support it)
remove this problem?
It should, unless the SUN linker is broken and assuming no other issues
in the compiler that prevent it from working.
Question about the use of builtins in altivec.h
Hello all, I am an active AltiVec PPC assembly programmer, but until recently have not been using gcc's AltiVec extensions. However, lately, with a project I am contributing to, called "macstl" (www.pixelglow.com/macstl/), I've become involved in using this stuff. So there is my question: why would one define the vec_XXX routines in terms of __builtin_altivec_XXX compiler primitives as opposed to using inline asm statements? Is there any good reason for doing that with the already existing good support for inline assembly? Now, it is important to note: I am *not* using the builtins directly; I am invoking the vec_XXX functions that are defined in altivec.h and specified in the AltiVec PIM. I am asking this, because we're having some problems with those builtins inlining instructions properly when a certain level of logic complexity (in loops) arises. Even worse, gcc 4.0 (both 4.0.0 and 4.0.1) generates bad code (whereas gcc 3.4 is OK). 3.4 simply resorts to a series of calls to compiler generated routines (with mangled names such as "_Z7vec_addU8_vectorfs" probably corresponding to the vec_add's builtin) instead of inlining actual instructions. Again that happens when a certain level of code mass is reached. gcc 4.0 tries to do the same but, apparently, something goes wrong. I didn't inspect the produced assembly code in depth. Currently, I can only give examples in terms of the macstl expressions and compiler generated assembly output, but if you request, I can try to write a more direct loop that uses the vec_* code. So does anyone of you, compiler writers, know why the builtins are needed? Also, does anyone care that this stuff doesn't really work? Regards, Ilya
Re: Question about the use of builtins in altivec.h
On Sep 23, 2005, at 5:30 PM, Ilya Lipovsky wrote: Hello all, I am asking this, because we're having some problems with those builtins inlining instructions properly when a certain level of logic complexity (in loops) arises. Even worse, gcc 4.0 (both 4.0.0 and 4.0.1) generates bad code (whereas gcc 3.4 is OK). 3.4 simply resorts to a series of calls to compiler generated routines (with mangled names such as "_Z7vec_addU8_vectorfs" probably corresponding to the vec_add's builtin) instead of inlining actual instructions. Again that happens when a certain level of code mass is reached. gcc 4.0 tries to do the same but, apparently, something goes wrong. I didn't inspect the produced assembly code in depth. Currently, I can only give examples in terms of the macstl expressions and compiler generated assembly output, but if you request, I can try to write a more direct loop that uses the vec_* code. As always read http://gcc.gnu.org/bugs.html and file a bug. The inlining problem have been fixed for 4.1.0, by the stuff mentioned below. Also smaller the testcase the better So does anyone of you, compiler writers, know why the builtins are needed? The builtins are required so the compiler can schedule the code correctly. In 4.1.0, the altivec.h header have been rewritten so that we don't use inline functions but some builtins directly. Also, does anyone care that this stuff doesn't really work? Well there was a rewrite for 4.1.0 for the altivec.h header which should improve this. And also in both 4.0.0 and 4.1.0, there is autovectorization which should expose more bugs. Also sometime during either 3.4.0, 4.0.0, or 4.1.0, an altivec testsuite was addded. Thanks, Andrew Pinski
Re: c++ default operators
On Fri, Sep 23, 2005 at 07:09:21PM +0200, Tommy Vercetti wrote: > I was told that gcc by default, for every class creates operator =, and > probably something else. This makes binary file bit larger than it > suppose to be. Is it true, and if so, why this is the case ? Can gcc > simply not generate that operator? In the C++ language, we have the concept of the default assignment operator and the default copy constructor, which are created if needed by the compiler. But gcc won't create these if they aren't used. Another extra function people sometimes complain about is the two copies of the constructor: the in-charge version is for constructing an instance of the class, and the not-in-charge version is for initializing the base portion of a derived class. Getting rid of the not-in-charge version, for cases where it isn't needed, would require something like Java's "final" keyword.
Re: c++ default operators
Joe Buck wrote: Another extra function people sometimes complain about is the two copies of the constructor: the in-charge version is for constructing an instance of the class, and the not-in-charge version is for initializing the base portion of a derived class. Getting rid of the not-in-charge version, for cases where it isn't needed, would require something like Java's "final" keyword. Can't you get rid of the not-in-charge version by using -ffunction-sections and then linking with -Wl,--gc-sections (at least for an ELF/GNU binutils target)? David Daney
