Re: Will backend ever see an memory operand with address wrap around?
On Sun, May 13, 2012 at 11:58 PM, H.J. Lu wrote:
> On Sun, May 13, 2012 at 12:01 PM, Richard Guenther
> wrote:
>> On Sun, May 13, 2012 at 6:32 PM, H.J. Lu wrote:
>>> Hi,
>>>
>>> I am trying to optimize memory address for x32. X32 runs in 64-bit mode.
>>> 64-bit address is base + index * scale + offset:
>>> 1. Base is 64bit.
>>> 2. Index is 64bit.
>>> 3. Offset is 8bit or 32bit
>>>
>>> 0x67 address size prefix is used to zero-extend 32bit address to 64bit:
>>> 1. Upper 32bits of base or index can be none-zero.
>>> 2. Index can be negative.
>>>
>>> We can avoid 0x67 prefix if
>>> 1. There is no index
>>> 2. Upper 32bits of base is zero:
>>> a. When base is set via 32bit load op, the upper 32bits are
>>> atomically zero-extended from the lower 32bits
>>> 3. Base + offset is a valid 32-bit address.
>>>
>>> Will x86 backend ever see a memory address with wrap around.
>>> That is to use 0x + 0x30 to represent 0x2f.
>>
>> Why not? Easily from code like
>>
>> long foo (long a, long b)
>> {
>> return *((long *)(a + b));
>> }
>>
>
> What is the expect run-time behavior when a + b has
> overflow/underflow?
If you make it unsigned long then with the values to quote
you derefernece 0x2f (sorry for using signed arith, and thus
undefinedness on overflow in the example).
Richard.
>
> --
> H.J.
Re: Will backend ever see an memory operand with address wrap around?
On Mon, May 14, 2012 at 4:26 AM, Geert Bosch wrote: > > On May 13, 2012, at 21:17, amyl...@spamcop.net wrote: >> The expectation is wrap-around. Note that loop strenght reduction can >> cause assumed wrap-around semantics in RTL for strictly conforming C input >> where no such wrap-around is in evidence. > > Really, we should define signed integer arithmetic in RTL to always > be wrap-around. While there may (*) be some benefit in "taking > advantage" of undefined semantics of integer overflow in early tree > optimizers (computing number of loop iterations etc.), at the same > time it also reduces optimization opportunities. > > Transformations cannot introduce overflows where none existed before, > so integer addition and subtraction are not associative. In the > end, the hardware is deterministic and does have wrap-around > semantics. So, it really doesn't make sense to pretend in RTL that > it doesn't. I agree - but we don't have signed vs. unsigned PLUS on RTL so RTL arith is unsigned anway, no? Richard. > -Geert > > -- > (*) At the end of the day, I think everybody would win by unambiguously > defining signed integer arithmetic as using wrap-around semantics > everywhere. Software is hard enough with defined semantics. >
About trees and expanded code by macros
Hello. I'am developing an statement detector for c++ and I would like to detect if an statement is expanded from macro. Can I detect in ast tree if an statement is expanded code from macro? Thanks.
Re: About trees and expanded code by macros
Hi Alberto, As far as I understand it you want to know if a statement was expanded from a preprocessor macro, right? This isn't possible. The preprocessor is a separate thing altogether and I doubt any preprocessing information remains for the compiler proper to deal with. Cheers, Paulo Matos On 14/05/12 08:53, Alberto Lozano Alelu wrote: Hello. I'am developing an statement detector for c++ and I would like to detect if an statement is expanded from macro. Can I detect in ast tree if an statement is expanded code from macro? Thanks. -- PMatos
Re: About trees and expanded code by macros
This information is incorrect. GCC tracks macro expansion information since GCC 4.7, and it has been further improved and enabled by default in GCC 4.8. See the option ftrack-macro-expansion and the interface located in libcpp/include/line-map.h. If you have trouble understanding the interface, find it lacking, and want to suggest improvements (patches would be even better), please do so. Cheers, Manuel. On 14 May 2012 10:49, Paulo J. Matos wrote: > Hi Alberto, > > As far as I understand it you want to know if a statement was expanded from > a preprocessor macro, right? > > This isn't possible. The preprocessor is a separate thing altogether and I > doubt any preprocessing information remains for the compiler proper to deal > with. > > Cheers, > > Paulo Matos > > > On 14/05/12 08:53, Alberto Lozano Alelu wrote: >> >> Hello. >> >> I'am developing an statement detector for c++ and I would like to >> detect if an statement is expanded from macro. >> >> Can I detect in ast tree if an statement is expanded code from macro? >> >> Thanks. >> > > > -- > PMatos >
Re: About trees and expanded code by macros
Thanks for correcting me Manuel. I am just getting acquainted with GCC4.7, good to know that information has been added. Cheers, Paulo Matos On 14/05/12 10:07, Manuel López-Ibáñez wrote: This information is incorrect. GCC tracks macro expansion information since GCC 4.7, and it has been further improved and enabled by default in GCC 4.8. See the option ftrack-macro-expansion and the interface located in libcpp/include/line-map.h. If you have trouble understanding the interface, find it lacking, and want to suggest improvements (patches would be even better), please do so. Cheers, Manuel. On 14 May 2012 10:49, Paulo J. Matos wrote: Hi Alberto, As far as I understand it you want to know if a statement was expanded from a preprocessor macro, right? This isn't possible. The preprocessor is a separate thing altogether and I doubt any preprocessing information remains for the compiler proper to deal with. Cheers, Paulo Matos On 14/05/12 08:53, Alberto Lozano Alelu wrote: Hello. I'am developing an statement detector for c++ and I would like to detect if an statement is expanded from macro. Can I detect in ast tree if an statement is expanded code from macro? Thanks. -- PMatos -- PMatos
Został przekroczony limit przechowywania w skrzynce pocztowej
Został przekroczony limit przechowywania w skrzynce pocztowej. Nie będą mogli wysyłać i odbierać nowe wiadomości do uaktualnieniem e-mail kontyngent. Skopiuj poniższy link i wypełnij formularz w celu aktualizacji konta. https://docs.google.com/spreadsheet/viewform?formkey=dHhlZVdORm1lVjU2aXRJUFgxOTBjWGc6MQ System Administrator 192.168.0.1
Re: Will backend ever see an memory operand with address wrap around?
On Sun, May 13, 2012 at 10:24 PM, wrote: > Quoting "H.J. Lu" : > >> What is the run-time result when overflow happens? > > > Assuming you use a 32 bit unsigned base address, and the space beyond 4G > is unmapped, you'll get a SEGV. So, when used for load and store, "base + offset" with overflow/underflow has unspecified behavior. -- H.J.
RE: Add STB_SECONDARY to gABI
This looks good. I just want to check one thing with you. In point 5 you state that unresolved secondary symbols have a zero value. Are you implying that unresolved secondary symbols should not result in a link or load-time error? If that's the case, you should also make it clear that a secondary reference (STB_SECONDARY/SHN_UNDEF) has lower precedence than a global or weak reference. Randy > -Original Message- > From: generic-...@googlegroups.com [mailto:generic- > a...@googlegroups.com] On Behalf Of H.J. Lu > Sent: Saturday, May 12, 2012 9:53 AM > To: Generic System V Application Binary Interface; GCC Development; > Binutils; GNU C Library; Ansari, Zia > Subject: Add STB_SECONDARY to gABI > > Here is the final proposal to add STB_SECONDARY to gABI. > Any comments? > > Thanks. > > -- > H.J. > --- > We want to provide a relocatable object which can take advantage of all > versions of a supported OS. For a function, foo, in the C library, we > can use it only if it is available on all versions of the C library or > we provide our own implementation of foo. With our own foo, the one in > the C library will never be used. Here is a proposal to add > STB_SECONDARY > to gABI to support the secondary definition so that a software vendor > can provide an alternative implementation in case it isn't available > in the C library. > > STB_SECONDARY > > Secondary symbols are similar to weak symbols, but their definitions > have even lower precedence. The difference between secondary symbols > and weak symbols are > > 1. The link editor must search archive library and extract > archive members to resolve defined and undefined secondary symbol. > 2. When the link editor searches a shared object, it must honor > the global or weak definition in the shared object and ignore the > secondary one with the same name. > 3. The link editor ignores the secondary definition if there is > a global, weak or common definition with the same name. Multiple > secondary definitions with the same name will not cause an error. > The first appearance of the secondary definition should be honored > and the rest are ignored. > 4. The link editor may treat the secondary definition in the > shared object as a global definition. > 5. Unresolved secondary symbols have a zero value. > > The purpose of this symbol binding is to provide the primary > definition as a global, weak or common symbol in an archive library > or a shared object while keeping a secondary definition in a > relocatable object. If there is no primary definition, the > secondary definition will be used. > > When secondary definitions become part of an executable or shared > object, linker may convert them to global or local definitions. > > At run-time, when resolving a symbol, after seeing a secondary > definition, the dynamic linker must keep searching until a > global or weak definition is found. If a global or weak > definition is found, it will be used to satisfy the symbol lookup. > Otherwise, the secondary definition will be used. > > If the dlopen loads a global or weak definition after the program > has already resolved references to a secondary definition, those > references remain bound to the secondary definition. Any > references resolved after the dlopen, for which the dlopened > module is included in the module search list, would be resolved > to the global or weak definition. > > STB_SECONDARY is defined as: > > #define STB_SECONDARY 3 /* Secondary symbol */ > > -- > You received this message because you are subscribed to the Google > Groups "Generic System V Application Binary Interface" group. > To post to this group, send email to generic-...@googlegroups.com. > To unsubscribe from this group, send email to generic- > abi+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/generic-abi?hl=en.
Aukcijski centar
Postovani, Prvi centar koji svim pravnim i fizickim osobama omogucuje potpuno besplatno prodaju svih vrsta nove i rabljene robe i usluga . Svu svoju robu ili uslugu mozete odmah - vec danas potpuno besplatno prodavati direktno iz svog poduzeca, obrta, gospodarstva po svojim cijenama preko portala http://www.aukcijskicentar.hr Na Vama je samo da se besplatno registrirate na http//www.aukcijskicentar.hr, kliknete na predaj aukciju ili oglas i nakon unosa kliknete «OBJAVI» ! Vas oglas/aukcija je aktivan i ceka na Vaseg kupca ! Preporucite nas Vasim prijateljima jer Vama i Vasim prijateljima nudimo brojne mogucnosti poslovne suradnje ! Puno uspjeha u kupnji - prodaji zeli Vam Tim Aukcijskog centra i...@aukcijskicentar.com tel. +385 1 2042-574 fax. +385 1 2042-004 http://www.aukcijskicentar.hr
Re: What do do with the exceptional case of expand_case for SJLJ exceptions
On 05/12/12 06:00, Steven Bosscher wrote: > * toplev.c (process_options): Fail for sjlj exceptions if the > target machine > has no casesi insn and no tablejump insn. Looks good. How many targets have neither case/tablejump? r~
Trying to track down a register allocation issue
I'm running into an ICE due to what looks like wrong register allocation, and
I'm trying to figure out where the problem lies. It shows up with today's GCC
(trunk). I haven't yet tried to narrow it down to a particular change.
It shows up in the pdp11 target, -O2. Not clear that this is pdp11 specific.
The ira dump shows this insn:
(insn 72 71 73 8 (set (reg:SI 129 [ D.2729 ])
(mem:SI (post_inc:HI (reg:HI 167 [orig:107 ivtmp.50 ] [107])) [2
MEM[base: D.2843_99, offset: 0B]+0 S4 A16]))
../../../../../newlib-1.18.0/newlib/libc/stdlib/gdtoa-gethex.c:79 11 {movsi}
(expr_list:REG_INC (reg:HI 167 [orig:107 ivtmp.50 ] [107])
(nil)))
The pointer register (167) is used later in the block, and is shown as alive at
block end.
The reload dump shows it like this:
(insn 72 248 250 8 (set (reg:SI 2 r2)
(mem:SI (post_inc:HI (reg:HI 2 r2)) [2 MEM[base: D.2843_99, offset:
0B]+0 S4 A16]))
../../../../../newlib-1.18.0/newlib/libc/stdlib/gdtoa-gethex.c:79 11 {movsi}
(expr_list:REG_INC (reg:HI 2 r2)
(nil)))
That causes an ICE in the postreload stage. But in any case, I'm trying to
figure out why reload assigned R2 both to reg 129 and to reg 167, when 167 is
still alive.
Any suggestions on where to look?
paul
Re: What do do with the exceptional case of expand_case for SJLJ exceptions
On Mon, May 14, 2012 at 4:23 PM, Richard Henderson wrote: > On 05/12/12 06:00, Steven Bosscher wrote: >> * toplev.c (process_options): Fail for sjlj exceptions if the >> target machine >> has no casesi insn and no tablejump insn. > > Looks good. How many targets have neither case/tablejump? Those are m32c, moxie, and rl78. For rl78 there is a comment in gcc/config/rl78/rl78.h that suggests there should be a tablejump insn, but it's not there. This is unfortunate because rl78 is a "#define DWARF2_UNWIND_INFO 0" target, i.e. it defaults to (and only supports??) SJLJ-based exceptions. Ciao! Steven P.S. What the other targets have, is listed below: alpha "tablejump" arm "casesi" "tablejump" avr "casesi" bfin"tablejump" c6x "casesi" "tablejump" cr16"tablejump" cris"casesi" epiphany"tablejump" fr30"tablejump" frv "casesi" "tablejump" h8300 "tablejump" i386"tablejump" ia64"tablejump" iq2000 "tablejump" lm32"tablejump" m32r"tablejump" m68k"tablejump" mcore "tablejump" mep "tablejump" microblaze "tablejump" mips"tablejump" mmix"tablejump" mn10300 "casesi" "tablejump" pa "casesi" pdp11 "tablejump" picochip"tablejump" rs6000 "tablejump" rx "tablejump" s390"casesi" score "tablejump" sh "casesi" sparc "tablejump" spu "casesi" "tablejump" stormy16"casesi" tilegx "tablejump" tilepro "tablejump" v850"casesi" "tablejump" vax "casesi" xtensa "tablejump"
RE: Add STB_SECONDARY to gABI
How about stating that the behavior of STB_SECONDARY symbols in areas not specified by this proposal matches that of STB_WEAK? For example, we may not want to go into runtime details when an unresolved-hence-zero-valued secondary reference (type STT_FUNC) is hit at runtime. In such instances let us ride on the existing definitions of STB_WEAK. In that way, we don’t have to define everything explicitly. Does that look good? -- Supra > -Original Message- > From: generic-...@googlegroups.com [mailto:generic- > a...@googlegroups.com] On Behalf Of Lowell, Randy > Sent: 14 May 2012 07:12 PM > To: generic-...@googlegroups.com; GCC Development; Binutils; GNU C > Library; Ansari, Zia > Subject: RE: Add STB_SECONDARY to gABI > > This looks good. I just want to check one thing with you. In point > 5 > you state that unresolved secondary symbols have a zero value. Are > you implying that unresolved secondary symbols should not result in > a > link or load-time error? If that's the case, you should also make > it > clear that a secondary reference (STB_SECONDARY/SHN_UNDEF) has lower > precedence than a global or weak reference. > > Randy > > > -Original Message- > > From: generic-...@googlegroups.com [mailto:generic- > > a...@googlegroups.com] On Behalf Of H.J. Lu > > Sent: Saturday, May 12, 2012 9:53 AM > > To: Generic System V Application Binary Interface; GCC > Development; > > Binutils; GNU C Library; Ansari, Zia > > Subject: Add STB_SECONDARY to gABI > > > > Here is the final proposal to add STB_SECONDARY to gABI. > > Any comments? > > > > Thanks. > > > > -- > > H.J. > > --- > > We want to provide a relocatable object which can take advantage > of all > > versions of a supported OS. For a function, foo, in the C > library, we > > can use it only if it is available on all versions of the C > library or > > we provide our own implementation of foo. With our own foo, the > one in > > the C library will never be used. Here is a proposal to add > > STB_SECONDARY > > to gABI to support the secondary definition so that a software > vendor > > can provide an alternative implementation in case it isn't > available > > in the C library. > > > > STB_SECONDARY > > > > Secondary symbols are similar to weak symbols, but their > definitions > > have even lower precedence. The difference between > secondary symbols > > and weak symbols are > > > > 1. The link editor must search archive library and extract > > archive members to resolve defined and undefined secondary > symbol. > > 2. When the link editor searches a shared object, it must > honor > > the global or weak definition in the shared object and ignore > the > > secondary one with the same name. > > 3. The link editor ignores the secondary definition if there is > > a global, weak or common definition with the same name. > Multiple > > secondary definitions with the same name will not cause an > error. > > The first appearance of the secondary definition should be > honored > > and the rest are ignored. > > 4. The link editor may treat the secondary definition in the > > shared object as a global definition. > > 5. Unresolved secondary symbols have a zero value. > > > > The purpose of this symbol binding is to provide the primary > > definition as a global, weak or common symbol in an archive > library > > or a shared object while keeping a secondary definition in a > > relocatable object. If there is no primary definition, the > > secondary definition will be used. > > > > When secondary definitions become part of an executable or > shared > > object, linker may convert them to global or local > definitions. > > > > At run-time, when resolving a symbol, after seeing a > secondary > > definition, the dynamic linker must keep searching until a > > global or weak definition is found. If a global or weak > > definition is found, it will be used to satisfy the symbol > lookup. > > Otherwise, the secondary definition will be used. > > > > If the dlopen loads a global or weak definition after the > program > > has already resolved references to a secondary definition, > those > > references remain bound to the secondary definition. Any > > references resolved after the dlopen, for which the dlopened > > module is included in the module search list, would be > resolved > > to the global or weak definition. > > > > STB_SECONDARY is defined as: > > > > #define STB_SECONDARY 3 /* Secondary symbol */ > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Generic System V Application Binary Interface" group. > > To post to this group, send email to generic-...@googlegroups.com. > > To unsubscribe from this group, send email to generic- > > abi+unsubscr...@googlegroups.com. > > For more options, visit this group at > > h
[cxx-conversion] Merge from trunk
I've just merged cxx-conversion up to rev 187449. Diego.
RE: Add STB_SECONDARY to gABI
> -Original Message- > From: generic-...@googlegroups.com [mailto:generic- > a...@googlegroups.com] On Behalf Of Lowell, Randy > Sent: 14 May 2012 07:12 PM > To: generic-...@googlegroups.com; GCC Development; Binutils; GNU C > Library; Ansari, Zia > Subject: RE: Add STB_SECONDARY to gABI > > This looks good. I just want to check one thing with you. In point > 5 > you state that unresolved secondary symbols have a zero value. Are > you implying that unresolved secondary symbols should not result in > a > link or load-time error? If that's the case, you should also make > it > clear that a secondary reference (STB_SECONDARY/SHN_UNDEF) has lower > precedence than a global or weak reference. In this case we should just mention that "secondary reference (STB_SECONDARY/SHN_UNDEF) has lower precedence than a global or weak reference". We cannot keep point number 5 (as it appears now) under differences because gABI already says "Unresolved weak symbols have a zero value". So either remove point number 5 under differences or change it to something discussed above. -- Supra > > Randy > > > -Original Message- > > From: generic-...@googlegroups.com [mailto:generic- > > a...@googlegroups.com] On Behalf Of H.J. Lu > > Sent: Saturday, May 12, 2012 9:53 AM > > To: Generic System V Application Binary Interface; GCC > Development; > > Binutils; GNU C Library; Ansari, Zia > > Subject: Add STB_SECONDARY to gABI > > > > Here is the final proposal to add STB_SECONDARY to gABI. > > Any comments? > > > > Thanks. > > > > -- > > H.J. > > --- > > We want to provide a relocatable object which can take advantage > of all > > versions of a supported OS. For a function, foo, in the C > library, we > > can use it only if it is available on all versions of the C > library or > > we provide our own implementation of foo. With our own foo, the > one in > > the C library will never be used. Here is a proposal to add > > STB_SECONDARY > > to gABI to support the secondary definition so that a software > vendor > > can provide an alternative implementation in case it isn't > available > > in the C library. > > > > STB_SECONDARY > > > > Secondary symbols are similar to weak symbols, but their > definitions > > have even lower precedence. The difference between > secondary symbols > > and weak symbols are > > > > 1. The link editor must search archive library and extract > > archive members to resolve defined and undefined secondary > symbol. > > 2. When the link editor searches a shared object, it must > honor > > the global or weak definition in the shared object and ignore > the > > secondary one with the same name. > > 3. The link editor ignores the secondary definition if there is > > a global, weak or common definition with the same name. > Multiple > > secondary definitions with the same name will not cause an > error. > > The first appearance of the secondary definition should be > honored > > and the rest are ignored. > > 4. The link editor may treat the secondary definition in the > > shared object as a global definition. > > 5. Unresolved secondary symbols have a zero value. > > > > The purpose of this symbol binding is to provide the primary > > definition as a global, weak or common symbol in an archive > library > > or a shared object while keeping a secondary definition in a > > relocatable object. If there is no primary definition, the > > secondary definition will be used. > > > > When secondary definitions become part of an executable or > shared > > object, linker may convert them to global or local > definitions. > > > > At run-time, when resolving a symbol, after seeing a > secondary > > definition, the dynamic linker must keep searching until a > > global or weak definition is found. If a global or weak > > definition is found, it will be used to satisfy the symbol > lookup. > > Otherwise, the secondary definition will be used. > > > > If the dlopen loads a global or weak definition after the > program > > has already resolved references to a secondary definition, > those > > references remain bound to the secondary definition. Any > > references resolved after the dlopen, for which the dlopened > > module is included in the module search list, would be > resolved > > to the global or weak definition. > > > > STB_SECONDARY is defined as: > > > > #define STB_SECONDARY 3 /* Secondary symbol */ > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Generic System V Application Binary Interface" group. > > To post to this group, send email to generic-...@googlegroups.com. > > To unsubscribe from this group, send email to generic- > > abi+unsubscr...@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/generic-abi?hl=en. > >
[x86-64 psABI] RFC: Extend x86-64 psABI to support x32
Hi, Support for the x32 psABI: http://sites.google.com/site/x32abi/ is added in Linux kernel 3.4-rc1. X32 uses the ILP32 model for x86-64 instruction set with size of long and pointers == 4 bytes. X32 is already supported in GCC 4.7.0 and binutils 2.22. I am now working to integrate x32 support into GLIBC 2.16 and GDB 7.5 Here is a patch to extend x86-64 psABI for x32. Any comments? Thanks. -- H.J. psabi-x32.patch Description: Binary data
Re: [x86-64 psABI] RFC: Extend x86-64 psABI to support x32
On 05/14/2012 10:31 AM, H.J. Lu wrote: > Hi, > > Support for the x32 psABI: > > http://sites.google.com/site/x32abi/ > > is added in Linux kernel 3.4-rc1. X32 uses the ILP32 model for x86-64 > instruction set with size of long and pointers == 4 bytes. X32 is > already supported in GCC 4.7.0 and binutils 2.22. I am now working > to integrate x32 support into GLIBC 2.16 and GDB 7.5 Here is a > patch to extend x86-64 psABI for x32. Any comments? > As a minor nitpick, I have always used x32 with a lower case x. The capital X32 looks odd to me. -hpa
Re: [x86-64 psABI] RFC: Extend x86-64 psABI to support x32
On Mon, May 14, 2012 at 10:34 AM, H. Peter Anvin wrote: > On 05/14/2012 10:31 AM, H.J. Lu wrote: >> Hi, >> >> Support for the x32 psABI: >> >> http://sites.google.com/site/x32abi/ >> >> is added in Linux kernel 3.4-rc1. X32 uses the ILP32 model for x86-64 >> instruction set with size of long and pointers == 4 bytes. X32 is >> already supported in GCC 4.7.0 and binutils 2.22. I am now working >> to integrate x32 support into GLIBC 2.16 and GDB 7.5 Here is a >> patch to extend x86-64 psABI for x32. Any comments? >> > > As a minor nitpick, I have always used x32 with a lower case x. The > capital X32 looks odd to me. > I used X32 together with LP64. I can use ILP32 instead of X32 when LP64 is mentioned at the same time. -- H.J.
RE: Add STB_SECONDARY to gABI
> -Original Message- > From: generic-...@googlegroups.com [mailto:generic- > a...@googlegroups.com] On Behalf Of Suprateeka R Hegde > Sent: Monday, May 14, 2012 12:40 PM > To: generic-...@googlegroups.com; 'GCC Development'; 'Binutils'; 'GNU C > Library'; 'Ansari, Zia' > Subject: RE: Add STB_SECONDARY to gABI > > How about stating that the behavior of > STB_SECONDARY symbols in areas not specified > by this proposal matches that of STB_WEAK? > > For example, we may not want to go into > runtime details when an unresolved-hence-zero-valued > secondary reference (type STT_FUNC) is hit at runtime. > In such instances let us ride on the existing > definitions of STB_WEAK. > > In that way, we don't have to define > everything explicitly. Does that look good? Good idea. My concern about precedence of weak vs. secondary undefs is probably just an implementation detail, so I'll withdraw that. It only comes into play if the implementation creates a merged list of undefs for all of the input object files and/or load modules. From the perspective of the gABI, each reference is handled individually, so we don't need to say anything about precedence of conflicting undefs. So I agree with the suggestion to delete difference #5 and add the "otherwise matches STB_WEAK" statement. Randy > > -- > Supra > > > -Original Message- > > From: generic-...@googlegroups.com [mailto:generic- > > a...@googlegroups.com] On Behalf Of Lowell, Randy > > Sent: 14 May 2012 07:12 PM > > To: generic-...@googlegroups.com; GCC Development; Binutils; GNU C > > Library; Ansari, Zia > > Subject: RE: Add STB_SECONDARY to gABI > > > > This looks good. I just want to check one thing with you. In point > > 5 > > you state that unresolved secondary symbols have a zero value. Are > > you implying that unresolved secondary symbols should not result in > > a > > link or load-time error? If that's the case, you should also make > > it > > clear that a secondary reference (STB_SECONDARY/SHN_UNDEF) has lower > > precedence than a global or weak reference. > > > > Randy > > > > > -Original Message- > > > From: generic-...@googlegroups.com [mailto:generic- > > > a...@googlegroups.com] On Behalf Of H.J. Lu > > > Sent: Saturday, May 12, 2012 9:53 AM > > > To: Generic System V Application Binary Interface; GCC > > Development; > > > Binutils; GNU C Library; Ansari, Zia > > > Subject: Add STB_SECONDARY to gABI > > > > > > Here is the final proposal to add STB_SECONDARY to gABI. > > > Any comments? > > > > > > Thanks. > > > > > > -- > > > H.J. > > > --- > > > We want to provide a relocatable object which can take advantage > > of all > > > versions of a supported OS. For a function, foo, in the C > > library, we > > > can use it only if it is available on all versions of the C > > library or > > > we provide our own implementation of foo. With our own foo, the > > one in > > > the C library will never be used. Here is a proposal to add > > > STB_SECONDARY > > > to gABI to support the secondary definition so that a software > > vendor > > > can provide an alternative implementation in case it isn't > > available > > > in the C library. > > > > > > STB_SECONDARY > > > > > > Secondary symbols are similar to weak symbols, but their > > definitions > > > have even lower precedence. The difference between > > secondary symbols > > > and weak symbols are > > > > > > 1. The link editor must search archive library and extract > > > archive members to resolve defined and undefined secondary > > symbol. > > > 2. When the link editor searches a shared object, it must > > honor > > > the global or weak definition in the shared object and ignore > > the > > > secondary one with the same name. > > > 3. The link editor ignores the secondary definition if there is > > > a global, weak or common definition with the same name. > > Multiple > > > secondary definitions with the same name will not cause an > > error. > > > The first appearance of the secondary definition should be > > honored > > > and the rest are ignored. > > > 4. The link editor may treat the secondary definition in the > > > shared object as a global definition. > > > 5. Unresolved secondary symbols have a zero value. > > > > > > The purpose of this symbol binding is to provide the primary > > > definition as a global, weak or common symbol in an archive > > library > > > or a shared object while keeping a secondary definition in a > > > relocatable object. If there is no primary definition, the > > > secondary definition will be used. > > > > > > When secondary definitions become part of an executable or > > shared > > > object, linker may convert them to global or local > > definitions. > > > > > > At run-time, when resolving a symbol, after seeing a > > secondary > > > definition, the dynamic linker must keep searching until a > > > global or weak definition is fou
Re: What do do with the exceptional case of expand_case for SJLJ exceptions
> For rl78 there is a comment in gcc/config/rl78/rl78.h that suggests > there should be a tablejump insn, but it's not there. The only unconditional branches rl78 has are immediate and register-indirect, i.e. "BR $label" and "BR AX". > This is unfortunate because rl78 is a "#define DWARF2_UNWIND_INFO 0" > target, i.e. it defaults to (and only supports??) SJLJ-based > exceptions. Return address on stack is not the same size as a pointer, so there's no way to describe the unwind operation in dwarfish.
Re: What do do with the exceptional case of expand_case for SJLJ exceptions
On 05/14/12 12:59, DJ Delorie wrote: >> > For rl78 there is a comment in gcc/config/rl78/rl78.h that suggests >> > there should be a tablejump insn, but it's not there. > The only unconditional branches rl78 has are immediate and > register-indirect, i.e. "BR $label" and "BR AX". > The later is certainly how tablejump would be implemented. r~
gcc 4.3.x: Bug in ieee754-{df,sf}.S
Hi,
currently, our software (www.lejos.org, build with a gcc 4.3.x based
arm-elf toolchain) manages to compare floats correctly most of the time.
But sometimes, the comparisons don't have the expected result.
Basically, comparisons behave non-deterministically.
We believe, that this is the result of a Bug in ieee754-{df,sf}.S.
A fix that seems to be related has been committed on June 5th, 2009, SVN
revision 148210. The commit comment was:
gcc/
* config/arm/ieee754-df.S (cmpdf2): Avoid writing below SP.
* config/arm/ieee754-sf.S (cmpsf2): Likewise.
Is gcc 4.3 still supported? Will there be release of gcc 4.3.7?
If yes, may I ask that you backport the fix to 4.3.x?
I didn't check the other branches (4.4, 4.5, or 4.6), but if it's
missing there then it should definitely be backported to these branches
as well.
Kind Regards,
Sven
Re: gcc 4.3.x: Bug in ieee754-{df,sf}.S
On Mon, May 14, 2012 at 1:36 PM, Sven Köhler wrote:
> Hi,
>
> currently, our software (www.lejos.org, build with a gcc 4.3.x based
> arm-elf toolchain) manages to compare floats correctly most of the time.
> But sometimes, the comparisons don't have the expected result.
> Basically, comparisons behave non-deterministically.
>
> We believe, that this is the result of a Bug in ieee754-{df,sf}.S.
> A fix that seems to be related has been committed on June 5th, 2009, SVN
> revision 148210. The commit comment was:
>
> gcc/
> * config/arm/ieee754-df.S (cmpdf2): Avoid writing below SP.
> * config/arm/ieee754-sf.S (cmpsf2): Likewise.
>
>
> Is gcc 4.3 still supported? Will there be release of gcc 4.3.7?
No. http://gcc.gnu.org/ describes GCC 4.5.x as the "oldest maintained
release series".
> I didn't check the other branches (4.4, 4.5, or 4.6), but if it's
> missing there then it should definitely be backported to these branches
> as well.
4.4 won't get it, so far as I can see. I don't know how decisions are
made on which patches are backported to supported versions.
-- James
Re: gcc 4.3.x: Bug in ieee754-{df,sf}.S
Quoting James Dennett : On Mon, May 14, 2012 at 1:36 PM, Sven Köhler wrote: Hi, Is gcc 4.3 still supported? Will there be release of gcc 4.3.7? No. http://gcc.gnu.org/ describes GCC 4.5.x as the "oldest maintained release series". Of course, if he has the resources and willingness to do so, he can do the backport himself or pay a contractor to do it. So the answer to the first question is really "depends." I suppose strictly speaking, there might even be an outside chance of a GCC 4.3.7 if someone "donated" the time of a competent release manager, and there was sufficient demand that the steering commitee considered it worthwhile sanctioning, but that'd be in a whole different ballpark from the mere 'support' question.
Re: Trying to track down a register allocation issue
Quoting paul_kon...@dell.com: I'm running into an ICE due to what looks like wrong register allocation, and I'm trying to figure out where the problem lies. It shows up with today's GCC (trunk). I haven't yet tried to narrow it down to a particular change. It shows up in the pdp11 target, -O2. Not clear that this is pdp11 specific. If a match test is confused with an overlap test somehwhere, the incidence would be influenced by the endianness. The little-endian equivalent would be (reg:SI 2) versus (reg:HI 3). Except that the latter wouldn't tend to be created by (misdirected) attempts to tie modes of different sizes. And of course you have a word size factor here; on a 32 or 64 bit target, you need larger modes to get multi-hard-register pseudos.
confusion about fma description in section 16.9 of gccint doc.
Section 16.9 of the current gcc doc is as follows. It implies that the fma pattern should/could be used on a machine that double rounds the multiply add. `fmam4' Multiply operand 2 and operand 1, then add operand 3, storing the result in operand 0. All operands must have mode m. This pattern is used to implement the |fma|, |fmaf|, and |fmal| builtin functions from the ISO C99 standard. The |fma| operation may produce different results than doing the multiply followed by the add if the machine does not perform a rounding step between the operations. However, this gccint doc says that this pattern is to be used to implement the fma* builtin functions of ISO C99. The iso c99 standard states: 7.12.13 Floating multiply-add 7.12.13.1 Thefmafunctions Synopsis 1 #include double fma(double x, double y, double z); float fmaf(float x, float y, float z); long double fmal(long double x, long double y, long double z); Description 2 The fma functions compute (x × y) + z, rounded as one ternary operation: they compute the value (as if) to infinite precision and round once to the result format, according to the rounding mode characterized by the value of FLT_ROUNDS. Returns 3 The fma functions return (x × y) + z, rounded as one ternary operation. Point 2 of the standard above states that those functions only do single rounding. My guess is that the gccint doc is wrong.(I should point out that the gccint doc for the new rtl operator in section 10.9 does require only single rounding. But that is not the question here.) Should i change the section 16.9 doc to indicate that this pattern is only to be used if the machine can do this with a single rounding? kenny
Re: gcc 4.3.x: Bug in ieee754-{df,sf}.S
Am 14.05.2012 23:01, schrieb James Dennett:
> On Mon, May 14, 2012 at 1:36 PM, Sven Köhler wrote:
>> Hi,
>>
>> currently, our software (www.lejos.org, build with a gcc 4.3.x based
>> arm-elf toolchain) manages to compare floats correctly most of the time.
>> But sometimes, the comparisons don't have the expected result.
>> Basically, comparisons behave non-deterministically.
>>
>> We believe, that this is the result of a Bug in ieee754-{df,sf}.S.
>> A fix that seems to be related has been committed on June 5th, 2009, SVN
>> revision 148210. The commit comment was:
>>
>> gcc/
>> * config/arm/ieee754-df.S (cmpdf2): Avoid writing below SP.
>> * config/arm/ieee754-sf.S (cmpsf2): Likewise.
>>
>>
>> Is gcc 4.3 still supported? Will there be release of gcc 4.3.7?
>
> No. http://gcc.gnu.org/ describes GCC 4.5.x as the "oldest maintained
> release series".
I see. So I will backport it myself.
>> I didn't check the other branches (4.4, 4.5, or 4.6), but if it's
>> missing there then it should definitely be backported to these branches
>> as well.
>
> 4.4 won't get it, so far as I can see. I don't know how decisions are
> made on which patches are backported to supported versions.
Actually, the patch was committed long time before 4.3.6 (more than 2
years). I guess, the patch was never backported - at least not 4.3.x.
How do I disable warnings across gcc versions?
This code warns (incorrectly, but that's a whole separate issue):
double foo(double a, double b)
{
bool option1_ok, option2_ok;
double option1, option2;
if (a == 0) {
option1_ok = false;
} else {
option1 = b;
option1_ok = true;
}
if (a == 1) {
option2_ok = false;
} else {
option2 = b;
option2_ok = true;
}
if (option1_ok) return option1;
if (option2_ok) return option2;
return 7;
}
Unfortunately, the bogus warning is -Wuninitialized in gcc 4.6 and
-Wmaybe-uninitialized in gcc 4.7. The obvious way to silence the
warning is to wrap it in:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
...
#pragma GCC diagnostic pop
It silences the original warning, but now gcc 4.6 says:
warning: unknown option after ‘#pragma GCC diagnostic’ kind [-Wpragmas]
This seems to defeat the purpose, and adding
#pragma GCC diagnostic ignored "-Wpragmas"
is a little gross. How am I supposed to do this?
Thanks,
Andy
Re: How do I disable warnings across gcc versions?
On 5/14/2012 6:26 PM, Andy Lutomirski wrote: This seems to defeat the purpose, and adding #pragma GCC diagnostic ignored "-Wpragmas" is a little gross. How am I supposed to do this? The gcc mailing list is for gcc development, not quetions about the use of gcc, please address such questions to the gcc help list.
Re: confusion about fma description in section 16.9 of gccint doc.
Kenneth Zadeck writes: > Should i change the section 16.9 doc to indicate that this pattern is > only to be used if the machine can do this with a single rounding? Sure. Ian
Re: confusion about fma description in section 16.9 of gccint doc.
committed in revision 187494. thanks. On 05/14/2012 08:05 PM, Ian Lance Taylor wrote: Kenneth Zadeck writes: Should i change the section 16.9 doc to indicate that this pattern is only to be used if the machine can do this with a single rounding? Sure. Ian
A question about loop ivopt
Hi, Why can't we replace function force_expr_to_var_cost directly with function computation_cost in tree-ssa-loop-ivopt.c? Actually I think it is inaccurate for the current recursive algorithm in force_expr_to_var_cost to estimate expr cost. Instead computation_cost can count some back-end factors and make the estimation more accurate. For example, using computation_cost, we may check whether back-ends can tie some modes transformation expressed by SUBREG or not. If we use force_expr_to_var_cost, some more computations around type promotion/demotion would increase the cost estimated. Looking at the algorithm in force_expr_to_var_cost, it is just to analyze the operator in the expression and give estimation. Should it be the same as expanding EXPR to RTX and give estimation like in computation_cost? Any thoughts? Thanks, -Jiangning
