Re: Undefined constant is crashing streams - g++ bug?
On Sun, 29 Apr 2012, Daniel Marschall wrote: I think I have found a bug in G++ . Please submit it to the bug tracker (I do not want to open an account there) if you think it is a bug - I am not sure about it. Opening an account is not that bad. The right list to ask for help is gcc-h...@gcc.gnu.org, please post any follow-up there. While I worked with "search+replace" I accidently had following in my source code: const char* DUMMY = DUMMY; It is amaazing that this code actually does compile. And no warning is output at all. -Winit-self http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Winit_002dself-289 (it won't warn if you write that line in the global scope, but it does inside a function) -- Marc Glisse
Re: making sizeof(void*) different from sizeof(void(*)())
Peter Bigot a écrit: The MSP430's split address space and ISA make it expensive to place data above the 64 kB boundary, but cheap to place code there. So I'm looking for a way to use HImode for data pointers, but PSImode for function pointers. If gcc supports this, it's not obvious how. I get partway there with FUNCTION_MODE and some hacks for the case where the called object is a symbol, but not when it's a pointer-to-function data object. I don't think it's a good solution to use different pointer sizes. You will run into all sorts of trouble -- both in the application and in GCC. Besides that, named address spaces are for data, not for functions. And they are supported for C only, not for C++, Objective-C, etc. The only candidate solution I've seen (and haven't yet tried) is to somehow assign all functions to be in a special named address space and use TARGET_ADDR_SPACE_POINTER_MODE to override the normal use of ptr_mode in build_pointer_type. I haven't been able to identify an existing back-end that has such a case, though I'd swear I've seen memory models like this for some other processor in the past. Could somebody suggest a workable solution for 4.7.x? AVR has similar problems to solve, see http://gcc.gnu.org/ml/gcc/2012-01/msg00365.html On AVR, the problem only arises for functions outside 128 KiB because instructions are always 2-byte aligned. Consequently, function pointers hold word-addresses. An easy solution would be to align function entry points and labels of computed and non-local goto to 2^n bytes. That way 16-bit pointers can target addresses in 2^n * 64 KiB. Other approach is linker stubs as mantioned in the link above. Johann
Re: making sizeof(void*) different from sizeof(void(*)())
On 4/29/2012 8:51 AM, Georg-Johann Lay wrote: Peter Bigot a écrit: The MSP430's split address space and ISA make it expensive to place data above the 64 kB boundary, but cheap to place code there. So I'm looking for a way to use HImode for data pointers, but PSImode for function pointers. If gcc supports this, it's not obvious how. I get partway there with FUNCTION_MODE and some hacks for the case where the called object is a symbol, but not when it's a pointer-to-function data object. I don't think it's a good solution to use different pointer sizes. You will run into all sorts of trouble -- both in the application and in GCC. Just to be clear, there is nothing in the standard that forbids the sizes being different AFAIK? I understand that both gcc and apps may make unwarranted assumptions.
Re: making sizeof(void*) different from sizeof(void(*)())
On Sun, Apr 29, 2012 at 7:51 AM, Georg-Johann Lay wrote: > Peter Bigot a écrit: > >> The MSP430's split address space and ISA make it expensive to place >> data above the 64 kB boundary, but cheap to place code there. So I'm >> looking for a way to use HImode for data pointers, but PSImode for >> function pointers. If gcc supports this, it's not obvious how. >> >> I get partway there with FUNCTION_MODE and some hacks for the case >> where the called object is a symbol, but not when it's a >> pointer-to-function data object. > > > I don't think it's a good solution to use different pointer sizes. > You will run into all sorts of trouble -- both in the application and > in GCC. Seems to be true in gcc at least. In C, I thought void* and void(*)() were so fundamentally incompatible that it was perfectly legitimate to have them be different sizes. (It was memory models on the DEC Alpha a decode or more ago that I recall as having that feature.) Are there really no gcc back-ends that take advantage of this? > Besides that, named address spaces are for data, not for functions. > And they are supported for C only, not for C++, Objective-C, etc. In that case, I'll ignore them and move to using variable and function attributes. It just seemed nice that it was possible to adapt the pointer mode based on the address space; it'd be nicer if it could be modified based on the full type, though. TARGET_TYPE_POINTER_MODE maybe. > >> The only candidate solution I've seen (and haven't yet tried) is to >> somehow assign all functions to be in a special named address space >> and use TARGET_ADDR_SPACE_POINTER_MODE to override the normal use of >> ptr_mode in build_pointer_type. >> >> I haven't been able to identify an existing back-end that has such a >> case, though I'd swear I've seen memory models like this for some >> other processor in the past. >> >> Could somebody suggest a workable solution for 4.7.x? > > > AVR has similar problems to solve, see > http://gcc.gnu.org/ml/gcc/2012-01/msg00365.html > > On AVR, the problem only arises for functions outside 128 KiB > because instructions are always 2-byte aligned. Consequently, > function pointers hold word-addresses. > > An easy solution would be to align function entry points and > labels of computed and non-local goto to 2^n bytes. That way > 16-bit pointers can target addresses in 2^n * 64 KiB. > > Other approach is linker stubs as mantioned in the link above. MSP430 has direct support for calling with a 20-bit pointer, so going through an indirection step is suboptimal. Also, a memory model supporting 16-bit data pointers and 20-bit code pointers is standard for commercial compilers for MSP430, so I'm a bit surprised at the possibility that gcc wouldn't support it. I assumed I just wasn't finding the right tickle-points. Peter
Re: making sizeof(void*) different from sizeof(void(*)())
Robert Dewar writes: > Just to be clear, there is nothing in the standard that forbids the > sizes being different AFAIK? I understand that both gcc and apps > may make unwarranted assumptions. POSIX makes that assumption, via the dlsym interface. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: making sizeof(void*) different from sizeof(void(*)())
On 4/29/2012 9:25 AM, Andreas Schwab wrote: Robert Dewar writes: Just to be clear, there is nothing in the standard that forbids the sizes being different AFAIK? I understand that both gcc and apps may make unwarranted assumptions. POSIX makes that assumption, via the dlsym interface. that's most unfortunate, I wonder why this assumption was ever allowed to creep into the POSIX interface. I wonder if it was deliberate, or accidental? Andreas.
Re: Should gcc give warning for this case?
This question is not appropriate on this mailing list, questions about using GCC should be sent to the gcc-h...@gcc.gnu.org list, please take any follow up there instead, thanks. On 29 April 2012 07:14, Qun-Ying wrote: > > No warning at all. Should gcc warn about the *next pointer points to > an unknown structure? No. next doesn't point to anything, it's NULL, which is safe and entirely correct behaviour for a pointer.
Re: making sizeof(void*) different from sizeof(void(*)())
Peter Bigot a écrit: Georg-Johann Lay wrote: Peter Bigot a écrit: The MSP430's split address space and ISA make it expensive to place data above the 64 kB boundary, but cheap to place code there. So I'm looking for a way to use HImode for data pointers, but PSImode for function pointers. If gcc supports this, it's not obvious how. I get partway there with FUNCTION_MODE and some hacks for the case where the called object is a symbol, but not when it's a pointer-to-function data object. I don't think it's a good solution to use different pointer sizes. You will run into all sorts of trouble -- both in the application and in GCC. Seems to be true in gcc at least. In C, I thought void* and void(*)() were so fundamentally incompatible that it was perfectly legitimate to have them be different sizes. (It was memory models on the DEC Alpha a decode or more ago that I recall as having that feature.) Most such compilers introduce restrictions to the C language and/or introduce non-standard extensions like, e.g near, far, huge. Are there really no gcc back-ends that take advantage of this? Some define function attributeslike new/far/long_call/longcall, but they serve different purposes, i.e. treat cases where jump targets of direct jumps are out of scope or respective machine instruction. Besides that, named address spaces are for data, not for functions. And they are supported for C only, not for C++, Objective-C, etc. In that case, I'll ignore them and move to using variable and function attributes. Attributes are too weak. You can use it to tag a symbol, but it won't get you big pointers for indirect calls. It just seemed nice that it was possible to adapt the pointer mode based on the address space; it'd be nicer if it could be modified based on the full type, though. TARGET_TYPE_POINTER_MODE maybe. Yes. However, GCC development always focused on the upper end of supported hardware: 64-bit systems, vectorizing, SIMD, ... There are just few developers that extend the lower end toward small, embedded systems and their needs, or add language extentions to better support that end. The only candidate solution I've seen (and haven't yet tried) is to somehow assign all functions to be in a special named address space and use TARGET_ADDR_SPACE_POINTER_MODE to override the normal use of ptr_mode in build_pointer_type. I haven't been able to identify an existing back-end that has such a case, though I'd swear I've seen memory models like this for some other processor in the past. Could somebody suggest a workable solution for 4.7.x? AVR has similar problems to solve, see http://gcc.gnu.org/ml/gcc/2012-01/msg00365.html On AVR, the problem only arises for functions outside 128 KiB because instructions are always 2-byte aligned. Consequently, function pointers hold word-addresses. An easy solution would be to align function entry points and labels of computed and non-local goto to 2^n bytes. That way 16-bit pointers can target addresses in 2^n * 64 KiB. Other approach is linker stubs as mantioned in the link above. MSP430 has direct support for calling with a 20-bit pointer, so going through an indirection step is suboptimal. Also, a memory model As some point you will have to pay if the hardware exceeds the implementation. As indirect calls are less common than direct ones, there is not too much overhead; just one jump. Aligning will add average cost of 7.5 bytes per aligned label, provided instructions may start at any byte address. If instructions are naturally 2-byte aligned, you just pay expected 6 bytes per aligned label. So you can easily calculate a reasonable overhead of jump pads against and weight against different label alignments. supporting 16-bit data pointers and 20-bit code pointers is standard for commercial compilers for MSP430, so I'm a bit surprised at the possibility that gcc wouldn't support it. I assumed I just wasn't finding the right tickle-points. Peter
Re: making sizeof(void*) different from sizeof(void(*)())
On Sun, 29 Apr 2012 09:43:02 -0400
Robert Dewar wrote:
> On 4/29/2012 9:25 AM, Andreas Schwab wrote:
> > Robert Dewar writes:
> >
> >> Just to be clear, there is nothing in the standard that forbids the
> >> sizes being different AFAIK? I understand that both gcc and apps
> >> may make unwarranted assumptions.
> >
> > POSIX makes that assumption, via the dlsym interface.
>
> that's most unfortunate, I wonder why this assumption was ever
> allowed to creep into the POSIX interface. I wonder if it was
> deliberate, or accidental?
IIRC, some old POSIX drafts proposed to add another function, perhaps dlfsym,
http://www.opengroup.org/sophocles2/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=3761
whiwh would be used for functions, and would be compatible with function
pointers of
different size than data pointers.
But it didn't make into the proposal.
My biased point of view is that designing a processor instruction set (for
POSIX-like
systems or standard C software in mind) with function pointers of different
size than
data pointers is today a mistake: most software make the implicit assumption
that all
pointers have the same size.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: making sizeof(void*) different from sizeof(void(*)())
On 4/29/2012 12:47 PM, Basile Starynkevitch wrote: My biased point of view is that designing a processor instruction set (for POSIX-like systems or standard C software in mind) with function pointers of different size than data pointers is today a mistake: most software make the implicit assumption that all pointers have the same size. What's your data for "most" here? I would have guessed that most software doesn't care.
go in 4.7.0 seems to fail quite badly
Has anyone seen better results from the testsuite for GO ? I am getting ugly results from the testsuite and this somewhat baffles me as the GCC 4.6.3 compiler I am using tests very well thus : http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02433.html However when I bootstrap GCC 4.7.0 and include go as a language to support I get horrific results thus : $ ../gcc-4.7.0/contrib/test_summary cat <<'EOF' | LAST_UPDATED: Obtained from SVN: tags/gcc_4_7_0_release revision 185675 Native configuration is x86_64-unknown-linux-gnu === g++ tests === Running target unix FAIL: g++.dg/charset/asm1.c -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/asm1.c scan-assembler .ascii bar UNRESOLVED: g++.dg/charset/asm1.c scan-assembler .ascii foo FAIL: g++.dg/charset/asm1.c -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/asm1.c scan-assembler .ascii bar UNRESOLVED: g++.dg/charset/asm1.c scan-assembler .ascii foo FAIL: g++.dg/charset/asm2.c -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/asm2.c scan-assembler std UNRESOLVED: g++.dg/charset/asm2.c scan-assembler cld UNRESOLVED: g++.dg/charset/asm2.c scan-assembler rep UNRESOLVED: g++.dg/charset/asm2.c scan-assembler movsb FAIL: g++.dg/charset/asm2.c -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/asm2.c scan-assembler std UNRESOLVED: g++.dg/charset/asm2.c scan-assembler cld UNRESOLVED: g++.dg/charset/asm2.c scan-assembler rep UNRESOLVED: g++.dg/charset/asm2.c scan-assembler movsb FAIL: g++.dg/charset/asm3.c -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/asm3.c scan-assembler foo FAIL: g++.dg/charset/asm3.c -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/asm3.c scan-assembler foo FAIL: g++.dg/charset/asm4.c -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/asm4.c scan-assembler-not translate FAIL: g++.dg/charset/asm4.c -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/asm4.c scan-assembler-not translate FAIL: g++.dg/charset/asm5.c -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/asm5.c scan-assembler foo FAIL: g++.dg/charset/asm5.c -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/asm5.c scan-assembler foo FAIL: g++.dg/charset/attribute1.c -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/attribute1.c scan-assembler foo FAIL: g++.dg/charset/attribute1.c -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/attribute1.c scan-assembler foo FAIL: g++.dg/charset/attribute2.c -std=c++98 (test for excess errors) FAIL: g++.dg/charset/attribute2.c -std=c++11 (test for excess errors) FAIL: g++.dg/charset/extern1.cc -std=c++98 (test for excess errors) FAIL: g++.dg/charset/extern1.cc -std=c++11 (test for excess errors) FAIL: g++.dg/charset/extern2.cc -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/extern2.cc scan-assembler-not foobar FAIL: g++.dg/charset/extern2.cc -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/extern2.cc scan-assembler-not foobar FAIL: g++.dg/charset/extern3.cc -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/extern3.cc scan-assembler-not abcdefghijklmnopqrstuvwxyz FAIL: g++.dg/charset/extern3.cc -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/extern3.cc scan-assembler-not abcdefghijklmnopqrstuvwxyz FAIL: g++.dg/charset/function.cc -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/function.cc scan-assembler-not "foobar" FAIL: g++.dg/charset/function.cc -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/function.cc scan-assembler-not "foobar" FAIL: g++.dg/charset/string.c -std=c++98 (test for excess errors) UNRESOLVED: g++.dg/charset/string.c scan-assembler-not string foobar FAIL: g++.dg/charset/string.c -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/charset/string.c scan-assembler-not string foobar === g++ Summary === # of expected passes48323 # of unexpected failures24 # of expected failures 286 # of unresolved testcases 28 # of unsupported tests 532 /home/dclarke/build/GCC/gcc-4.7.0-build-pass1/gcc/testsuite/g++/../../g++ version 4.7.0 (Blastwave.org Inc. Sat Apr 28 14:46:05 UTC 2012) === gcc tests === Running target unix FAIL: gcc.dg/charset/asm1.c (test for excess errors) UNRESOLVED: gcc.dg/charset/asm1.c scan-assembler .ascii bar UNRESOLVED: gcc.dg/charset/asm1.c scan-assembler .ascii foo FAIL: gcc.dg/charset/asm2.c (test for excess errors) FAIL: gcc.dg/charset/asm4.c (test for excess errors) UNRESOLVED: gcc.dg/charset/asm4.c scan-assembler foo FAIL: gcc.dg/charset/asm5.c (test for excess errors) UNRESOLVED: gcc.dg/charset/asm5.c scan-assembler-not translate FAIL: gcc.dg/charset/asm6.c (test for excess errors) UNRESOLVED: gcc.dg/charset/asm6.c scan-assembler foo FAIL: gcc.dg/charset/attribute1.c (test for excess errors) UNRESOLVED: gcc.dg/charset/attribute1.c scan-assembler foo FAIL: gcc.dg/charset/attribu
Re: making sizeof(void*) different from sizeof(void(*)())
On Sun, 29 Apr 2012 12:50:44 -0400
Robert Dewar wrote:
> On 4/29/2012 12:47 PM, Basile Starynkevitch wrote:
>
> > My biased point of view is that designing a processor instruction set (for
> > POSIX-like
> > systems or standard C software in mind) with function pointers of different
> > size than
> > data pointers is today a mistake: most software make the implicit
> > assumption that all
> > pointers have the same size.
>
> What's your data for "most" here? I would have guessed that most
> software doesn't care.
`dlsym` is the obvious hint (including the fact that the `dlfsym` proposal
vanished), and
also simply that most (probably nearly all) Linux/ELF systems and Unix systems
have same
size for data and function pointers.
Also, because while coding since 1974 (teenager then) I never personally got a
system
where they have been different -with the important exception of some
programming models
for early PC/AT (and PC/286) systems of the MSDOS area (e.g. Borland Turbo C
v1). IIRC
correctly, CrayY/MP have various size for some data pointers so it had
sizeof(char*) !=
sizeof (double*) but the function pointers had the size of some integral size
which was
the size of some data pointers (IIRC sizeof(void(*)()) == sizeof(long*) ==
sizeof(long)
on that machine).
And I did wrote that designing an ISA *today* for *Posix-like* systems
[emphasis both on
today and on Posix/Unix] with such a major difference would (IMHO) be a
mistake.
For instance, I don't think that porting the Linux kernel (or the FreeBSD one)
to such an
architecture (having data pointers of different size that function pointers) is
easy.
And GTK wants nearly all pointers to be gpointer-s, and may cast them to
function
pointers internally.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: making sizeof(void*) different from sizeof(void(*)())
On 4/29/2012 1:19 PM, Basile Starynkevitch wrote: For instance, I don't think that porting the Linux kernel (or the FreeBSD one) to such an architecture (having data pointers of different size that function pointers) is easy. Well it doesnt' surprise me too much that GNU/Linux has non-standard stuff in it And GTK wants nearly all pointers to be gpointer-s, and may cast them to function pointers internally. But GTK surprises me more. I guess the C world always surprises me in the extent to which people ignore the standard :-) Regards.
Re: making sizeof(void*) different from sizeof(void(*)())
Basile Starynkevitch writes: > `dlsym` is the obvious hint Most programs don't use dlsym. > also simply that most (probably nearly all) Linux/ELF systems and Unix > systems have same > size for data and function pointers. Those that don't use function descriptors. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Compile and run time comparison of every gcc release since 2.95
Marc Feeley, the author of the Gambit Scheme compiler and interpreter, has measured the time to "make" the current version of Gambit, and then to run an application in the Gambit interpreter, for every release of gcc since gcc-2.95. For each version of gcc, Feeley built Gambit in each of two ways: with each Scheme function compiled to its own C function (--enable-multiple-hosts), and with all the Scheme functions in a file combined into a single C function (--enable-single-host). The latter version increases compile time, and typically doubles the speed of execution of the compiled code. Feeley also compiled Gambit with each of -O1 or -O2. Perhaps some of you may be interested in the results, which can be found here: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2012-April/005936.html Brad Lucier
gcc-4.8-20120429 is now available
Snapshot gcc-4.8-20120429 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120429/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 186946 You'll find: gcc-4.8-20120429.tar.bz2 Complete GCC MD5=0364d905a7577e4564396afc01848708 SHA1=491e8929728f36be724f38a1de7e594399587eb2 Diffs from 4.8-20120422 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
