Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Oct 19, 2012, at 10:51 PM, Richard Smith wrote:
>
> On Fri, Oct 19, 2012 at 10:50 PM, Chandler Carruth
> wrote:
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith wrote:
> [Crossposted to both GCC and Clang dev lists]
>
> Hi,
>
> One issue facing library authors wanting to use C++11's constexpr feature is
> that the same implementation must be provided for both the case of function
> invocation substitution and for execution at runtime. Due to the constraints
> on constexpr function definitions, this can force an implementation of a
> library function to be inefficient. To counteract this, I'd like to propose
> the addition of a builtin:
>
> bool __builtin_constexpr_p()
>
> This builtin would only be supported within constexpr function definitions.
> If the containing function is undergoing function invocation substitution, it
> returns true. Otherwise, it returns false. Hence we can implement library
> functions with a pattern like:
>
> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
> q+1, n-1);
> }
> __attribute__((always_inline)) constexpr int my_strncmp(const char *p,
> const char *q, size_t n) {
> return __builtin_constexpr_p() ? constexpr_strncmp(p, q, n) : strncmp(p,
> q, n);
> }
>
> Does this seem reasonable?
>
> Yes, especially the primary functionality. However, I have some concerns
> about the interface. Let me hypothesize a different interface:
>
> This stays the same...
> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1, q+1,
> n-1);
> }
>
> But here we do something different on the actual declaration:
> [[constexpr_alias(constexpr_strncmp)]]
> int strncmp(const char *p, const char *q, size_t n);
>
> When parsing the *declaration* of this function, we lookup the function name
> passed to constexpr_alias. We must find a constexpr function with an
> identical signature. Then, at function invocation substitution of strncmp, we
> instead substitute the body of constexpr_strncmp.
>
> This seems more direct (no redirection in the code), and it also provides a
> specific advantage of allowing this to be easily added to an existing
> declaration in a declaration-only header file without impacting or changing
> the name of the runtime executed body or definition.
>
> I really like this approach.
I'd love to see this is in the pre-Bristol mailing with implementation
experience to back it up. :-) Nice job Richard and Chandler!
Howard
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Fri, Oct 19, 2012 at 10:50 PM, Chandler Carruth wrote:
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith
> wrote:
>>
>> [Crossposted to both GCC and Clang dev lists]
>>
>> Hi,
>>
>> One issue facing library authors wanting to use C++11's constexpr feature
>> is that the same implementation must be provided for both the case of
>> function invocation substitution and for execution at runtime. Due to the
>> constraints on constexpr function definitions, this can force an
>> implementation of a library function to be inefficient. To counteract this,
>> I'd like to propose the addition of a builtin:
>>
>> bool __builtin_constexpr_p()
>>
>> This builtin would only be supported within constexpr function
>> definitions. If the containing function is undergoing function invocation
>> substitution, it returns true. Otherwise, it returns false. Hence we can
>> implement library functions with a pattern like:
>>
>> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n)
>> {
>> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
>> q+1, n-1);
>> }
>> __attribute__((always_inline)) constexpr int my_strncmp(const char *p,
>> const char *q, size_t n) {
>> return __builtin_constexpr_p() ? constexpr_strncmp(p, q, n) :
>> strncmp(p, q, n);
>> }
>>
>> Does this seem reasonable?
>
>
> Yes, especially the primary functionality. However, I have some concerns
> about the interface. Let me hypothesize a different interface:
>
> This stays the same...
>>
>> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
>> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
>> q+1, n-1);
>> }
>
>
> But here we do something different on the actual declaration:
>>
>> [[constexpr_alias(constexpr_strncmp)]]
>> int strncmp(const char *p, const char *q, size_t n);
>
>
> When parsing the *declaration* of this function, we lookup the function name
> passed to constexpr_alias. We must find a constexpr function with an
> identical signature. Then, at function invocation substitution of strncmp,
> we instead substitute the body of constexpr_strncmp.
What do you do for member functions? Name the member with or without
qualification? Can the constexpr version be private?
Jeffrey
Re: thumb2 support
> Hello, I'm working with the BeagleBone and gcc-4.5.4 on Gentoo. If I > try to compile the 3.6 kernel with CONFIG_THUMB2_KERNEL, I get: > > arch/arm/boot/compressed/head.S:127: Error: selected processor does > not support requested special purpose register -- `mrs r2,cpsr' > arch/arm/boot/compressed/head.S:134: Error: selected processor does > not support requested special purpose register -- `mrs r2,cpsr' > arch/arm/boot/compressed/head.S:136: Error: selected processor does > not support requested special purpose register -- `msr cpsr_c,r2' > > This post indicates that mainline gcc does not currently support thumb2: > > https://groups.google.com/d/msg/beagleboard/P52fgMDzp8A/vupzuh71vdYJ > > However, this indicates that thumb2 has been supported since 4.3: > > http://gcc.gnu.org/gcc-4.3/changes.html > > Can anyone clear this up? The errors are coming from an assembler file that is not part of the GCC sources. Are those instructions valid for Thumb2? I don't know. If they are valid, then the issue is with the assembler, which is not part of GCC; check the version of the GNU binutils that you have installed. If those instructions are not valid, then you need to change your source. >>> >>> Thanks Ian. I'm using binutils-2.22-r1. Do you happen to know which >>> version of binutils should support thumb2? >> >> Hi Grant. I'm pretty sure this was fixed by: >> >> commit c0d796cf810a84f10703c0390f7b1c5887b837c9 >> Author: Nick Clifton >> Date: Wed Jun 13 14:18:59 2012 + >> >> PR gas/12698 >> * config/tc-arm.c (do_t_mrs): Do not require an m-profile >> architecure when assembling for all archiectures. >> (do_t_msr): Likewise. >> >> which will be in the upcoming binutils 2.23. Debian/Ubuntu carry this >> as a patch on top of their 2.22. >> >> -- Michael > > Thanks a lot Michael. I'm having trouble compiling 2.23 on Gentoo but > I'm working on it. > > - Grant I can compile binutils-2.23.51.0.1 on the Beaglebone, but not 2.23.51.0.2 or 2.23.51.0.3. I can compile the 3.6 kernel with thumb2 support with 2.23.51.0.1. Thanks, Grant
AIX trunk build fail #2
David got me past my first problem.
AIX 6.1 TL07 SP03, gcc 4.5.2 git repository on "master". Last pull was
> commit 43780738cd22a2fbea5fd7d8260a76e0c3121f43
> Author: hubicka
> Date: Sat Oct 20 14:19:12 2012 +
Here is the new error:
> /gsa/ausgsa/projects/r/ruby/bin/bash /usr/work/src/gcc.git/gcc/mkconfig.sh
> bconfig.h
> /usr/work/build/gcc.git/./prev-gcc/g++ -B/usr/work/build/gcc.git/./prev-gcc/
> -B/gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/bin/ -nostdinc++
> -B/usr/work/build/gcc.git/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs
> -B/usr/work/build/gcc.git/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/libsupc++/.libs
>
> -I/usr/work/build/gcc.git/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/include/powerpc-ibm-aix6.1.0.0
> -I/usr/work/build/gcc.git/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/include
> -I/usr/work/src/gcc.git/libstdc++-v3/libsupc++
> -L/usr/work/build/gcc.git/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs
> -L/usr/work/build/gcc.git/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/libsupc++/.libs
> -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
> -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
> -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/work/src/gcc.git/gcc
> -I/usr/work/src/gcc.git/gcc/build -I/usr/work/src/gcc.git/gcc/../include
> -I/usr/work/src/gcc.git/gcc/../libcpp/include
> -I/usr/work/src/gcc.git/gcc/../libdecnumber
> -I/usr/work/src/gcc.git/gcc/../libdecnumber/dpd -I../libdecnumber
> -I/usr/work/src/gcc.git/gcc/../libbacktrace\
> -o build/genconstants.o /usr/work/src/gcc.git/gcc/genconstants.c
> In file included from /usr/work/src/gcc.git/gcc/system.h:639:0,
> from /usr/work/src/gcc.git/gcc/genconstants.c:29:
> /usr/work/src/gcc.git/gcc/genconstants.c: In function 'int
> print_enum_type(void**, void*)':
> /usr/work/src/gcc.git/gcc/genconstants.c:68:60: error: missing sentinel in
> function call [-Werror=format]
>value_name = ACONCAT (("num_", def->name, "_values", NULL));
> ^
> /usr/work/src/gcc.git/gcc/../include/libiberty.h:658:37: note: in definition
> of macro 'alloca'
> # define alloca(x) __builtin_alloca(x)
> ^
> /usr/work/src/gcc.git/gcc/genconstants.c:68:16: note: in expansion of macro
> 'ACONCAT'
>value_name = ACONCAT (("num_", def->name, "_values", NULL));
> ^
> /usr/work/src/gcc.git/gcc/genconstants.c:68:60: error: missing sentinel in
> function call [-Werror=format]
>value_name = ACONCAT (("num_", def->name, "_values", NULL));
> ^
> /usr/work/src/gcc.git/gcc/../include/libiberty.h:183:17: note: in definition
> of macro 'ACONCAT'
> concat_copy2 ACONCAT_PARAMS)
> ^
> cc1plus: all warnings being treated as errors
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Oct 19, 2012, at 23:27 , Andy Gibbs wrote:
> On Saturday, October 20, 2012 7:50 AM, Chandler Carruth wrote:
>> [...snip...] Let me hypothesize a different interface:
>>
>> This stays the same...
>> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
>> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1, q+1,
>> n-1);
>> }
>>
>>
>> But here we do something different on the actual declaration:
>> [[constexpr_alias(constexpr_strncmp)]]
>> int strncmp(const char *p, const char *q, size_t n);
>>
>> When parsing the *declaration* of this function, we lookup the function
>> name passed to constexpr_alias. We must find a constexpr function with an
>> identical signature. Then, at function invocation substitution of strncmp,
>> we instead substitute the body of constexpr_strncmp.
>>
>> This seems more direct (no redirection in the code), and it also provides
>> a specific advantage of allowing this to be easily added to an existing
>> declaration in a declaration-only header file without impacting or
>> changing the name of the runtime executed body or definition.
>
> I'd be very happy with this solution. I come across precisely the problem
> raised by Richard on a very regular basis and have different workarounds
> for both gcc and clang. I'd love to see something "standard" emerging!
>
> For my side, I'd still like some way of declaring a function to be used
> only in a constexpr environment, meaning that the compiler gives an error
> up front when a function is then used in a non-constexpr environment. The
> above proposal will provide a link-time error if the non-constexpr function
> is not defined, which is half-way there. Perhaps using the "unavailable"
> attribute in conjunction with "constexpr_alias" would be the compile-time
> solution...
While throwing things out there, why not just optionally allow constexpr
functions to coexist with non-constexpr functions of the same name, like inline
and non-inline? That would solve both the original problem and Andy's problem.
// Primary declaration.
int strcmp(const char *p, const char *q, size_t n);
// This declaration will be used in any constexpr contexts.
// Non-constexpr contexts will use the declaration above (which may be inline)
constexpr int strcmp(const char *p, const char *q, size_t n) {
return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : strcmp(p+1, q+1, n-1);
}
This avoids both new builtins and having to come up with a manually-mangled
name for the alternate implementation. But it is most definitely a language
change.
And for Andy's problem, you'd then get...something like this?
constexpr int foo(int n) {
return n + 1;
}
int foo(int n) = delete;
...but I have not thought about the problems in implementing this.
Jordan
gcc-4.7-20121020 is now available
Snapshot gcc-4.7-20121020 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121020/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 192641 You'll find: gcc-4.7-20121020.tar.bz2 Complete GCC MD5=af871f577c9b9cfb18413ffa39326064 SHA1=cb2513f7a05efda3b9911ddb5e11b9322d57d1eb Diffs from 4.7-20121013 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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.
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Sat, Oct 20, 2012 at 12:53 AM, Chandler Carruth wrote:
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith wrote:
>>
>> [Crossposted to both GCC and Clang dev lists]
>>
>> Hi,
>>
>> One issue facing library authors wanting to use C++11's constexpr feature is
>> that the same implementation must be provided for both the case of function
>> invocation substitution and for execution at runtime. Due to the constraints
>> on constexpr function definitions, this can force an implementation of a
>> library function to be inefficient. To counteract this, I'd like to propose
>> the addition of a builtin:
>>
>> bool __builtin_constexpr_p()
>>
>> This builtin would only be supported within constexpr function definitions.
>> If the containing function is undergoing function invocation substitution,
>> it returns true. Otherwise, it returns false. Hence we can implement library
>> functions with a pattern like:
>>
>> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
>> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
>> q+1, n-1);
>> }
>> __attribute__((always_inline)) constexpr int my_strncmp(const char *p,
>> const char *q, size_t n) {
>> return __builtin_constexpr_p() ? constexpr_strncmp(p, q, n) : strncmp(p,
>> q, n);
>> }
>>
>> Does this seem reasonable?
>
>
> Yes, especially the primary functionality. However, I have some
> concerns about the interface. Let me hypothesize a different
> interface:
>
> This stays the same...
>> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
>> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1, q+1,
>> n-1);
>> }
>
>
> But here we do something different on the actual declaration:
>>
>> [[constexpr_alias(constexpr_strncmp)]]
>> int strncmp(const char *p, const char *q, size_t n);
>
>
> When parsing the *declaration* of this function, we lookup the
> function name passed to constexpr_alias. We must find a constexpr
> function with an identical signature. Then, at function invocation
> substitution of strncmp, we instead substitute the body of
> constexpr_strncmp.
>
> This seems more direct (no redirection in the code), and it also
> provides a specific advantage of allowing this to be easily added to
> an existing declaration in a declaration-only header file without
> impacting or changing the name of the runtime executed body or
> definition.
>
> -Chandler
>
> PS: Sorry for the dup Clang folks, the GCC list doesn't like my mail client.
The way to solve this issue is:
1) to make most of the restrictions on constexpr functions evaporate.
2) resist the temptation of introducing a primitive to query the state of
the optimizers.
-- Gaby
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose wrote: > While throwing things out there, why not just optionally allow constexpr > functions to coexist with non-constexpr functions of the same name, like > inline and non-inline? Or remove most of the restrictions on constexpr functions that were necessary only to win approval for C++11. This case doesn't strike me as one of those where you fight complexity with even greater complexity. Allow loops and the like in constexpr functions and be done with it. See my comments on the C++ Extension Working Group when these (and related) issues where brought up. -- Gaby
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Sat, Oct 20, 2012 at 7:36 PM, Gabriel Dos Reis wrote: > On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose wrote: >> While throwing things out there, why not just optionally allow constexpr >> functions to coexist with non-constexpr functions of the same name, like >> inline and non-inline? I think this is fundamentally the wrong approach. Constexpr functions aren't a different kind of function, they're just functions for which are sometimes required to be evaluated at translation time. Hence overload resolution should not depend on whether a function is constexpr. Also, this approach tends to require two definitions of constexpr functions even where the definitions are the same (if one calls a constexpr overload and the other calls a non-constexpr overload). What we want is just a mechanism to make function invocation substitution take a different path if it encounters a function which it can't process (because the runtime form of that function is somehow written in a way that it can't handle). > Or remove most of the restrictions on constexpr functions that were necessary > only to win approval for C++11. This case doesn't strike me as one of > those where you fight complexity with even greater complexity. > > Allow loops and the like in constexpr functions and be done with it. See my > comments on the C++ Extension Working Group when these (and related) > issues where brought up. Yes, I completely agree, but I don't think this solves the whole problem. There are certain constructs which we are unlikely to *ever* permit in constexpr functions, such as (as an extreme case) inline assembly. Where possible, we should share an implementation between compile time and runtime. This proposal is for the exceptional cases (which, over time, should become fewer and fewer), and as a stopgap measure while we work towards the right solution.
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Sat, Oct 20, 2012 at 10:23 PM, Richard Smith wrote: >> Allow loops and the like in constexpr functions and be done with it. See my >> comments on the C++ Extension Working Group when these (and related) >> issues where brought up. > > Yes, I completely agree, but I don't think this solves the whole > problem. There are certain constructs which we are unlikely to *ever* > permit in constexpr functions, such as (as an extreme case) inline > assembly. Where possible, we should share an implementation between > compile time and runtime. This proposal is for the exceptional cases > (which, over time, should become fewer and fewer), and as a stopgap > measure while we work towards the right solution. I am just back to College Station. We should coodinate for the post-Portland mailing. If I can have your current draft by tomorrow morning, that would be great. -- Gaby
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Oct 20, 2012, at 20:23 , Richard Smith wrote: > On Sat, Oct 20, 2012 at 7:36 PM, Gabriel Dos Reis > wrote: >> On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose wrote: >>> While throwing things out there, why not just optionally allow constexpr >>> functions to coexist with non-constexpr functions of the same name, like >>> inline and non-inline? > > I think this is fundamentally the wrong approach. Constexpr functions > aren't a different kind of function, they're just functions for which > are sometimes required to be evaluated at translation time. Hence > overload resolution should not depend on whether a function is > constexpr. Also, this approach tends to require two definitions of > constexpr functions even where the definitions are the same (if one > calls a constexpr overload and the other calls a non-constexpr > overload). What we want is just a mechanism to make function > invocation substitution take a different path if it encounters a > function which it can't process (because the runtime form of that > function is somehow written in a way that it can't handle). Just to clarify, I had assumed that if the constexpr function is the only visible declaration, it would be used as the runtime implementation as well, as it currently is in C++11. I guess in C++11 you can forward-declare a constexpr function without making it constexpr, though, so it's not backwards-compatible. Jordan
gcc master build problems
Hi there, on the gcc buildfarm : /home/h4ck3rm1k3/experiments/gcc-build/ I am having problems with a standard build of the gcc using the 4.5.1 compiler. 1. ./morestack.vis:1: Error: junk at end of line, first unrecognized character is `:' h4ck3rm1k3@gcc10:~/experiments/gcc-build/x86_64-unknown-linux-gnu/32/libgcc$ /home/h4ck3rm1k3/experiments/gcc-build/./gcc/xgcc -save-temps -B/home/h4ck3rm1k\ 3/experiments/gcc-build/./gcc/ -B/home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/bin/ -B/home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/lib/ -isystem /h\ ome/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/include -isystem /home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/sys-include-g -O2 -m32 -O2 -g -O2 -D\ IN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -\ g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. \ -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_\ TLS -o morestack.o -MT morestack.o -MD -MP -MF morestack.dep -c -xassembler-with-cpp -include morestack.vis ../../../../gcc/libgcc/config/i386/morestack.S ./morestack.vis: Assembler messages: ./morestack.vis:1: Error: junk at end of line, first unrecognized character is `:' workaround compile like this ; /home/h4ck3rm1k3/experiments/gcc-build/./gcc/xgcc -c -B/home/h4ck3rm1k3/experim\ ents/gcc-build/./gcc/ -B/home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/bin/ -B/home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/lib/ -isystem /home/h4ck3\ rm1k3/install/x86_64-unknown-linux-gnu/include -isystem /home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/sys-include-g -O2 -m32 -O2 -g -O2 -DIN_GCC \ -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LI\ BGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../.\ ./../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o mo\ restack.o -MT morestack.o -MD -MP morestack.s Then the file is empty libgcc.map, it is generated by some complex sed script, but it is failing. /usr/bin/ld:libgcc.map:1: syntax error in VERSION script anyone else had this problem? mike -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com Contributor FOSM, the CC-BY-SA map of the world http://fosm.org Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3 Free Software Foundation Europe Fellow http://fsfe.org/support/?h4ck3rm1k3
Re: gcc master build problems
On Sat, Oct 20, 2012 at 11:01 PM, Mike Dupont
wrote:
> Hi there,
> on the gcc buildfarm :
> /home/h4ck3rm1k3/experiments/gcc-build/
> I am having problems with a standard build of the gcc using the 4.5.1
> compiler.
>
> 1. ./morestack.vis:1: Error: junk at end of line, first unrecognized
> character is `:'
morestack.vis is generated by the makefile:
ifneq (,$(vis_hide))
# If we have -fvisibility=hidden, then we need to generate hide
# lists for object files implemented in assembly.
ASM_HIDDEN_OP = @asm_hidden_op@
define gen-hide-list
$(NM) -pg $< | \
$(AWK) 'NF == 3 && $$2 !~ /^[UN]$$/ && $$3 !~ /.*_compat/ \
&& $$3 !~ /.*@.*/ \
{ print "\t$(ASM_HIDDEN_OP)", $$3 }' > $@T
mv -f $@T $@
endef
else
gen-hide-list = echo > $@
endif
If either the nm or awk is producing the incorrect output, the build might fail.
Thanks,
Andrew Pinski
>
> h4ck3rm1k3@gcc10:~/experiments/gcc-build/x86_64-unknown-linux-gnu/32/libgcc$
> /home/h4ck3rm1k3/experiments/gcc-build/./gcc/xgcc -save-temps
> -B/home/h4ck3rm1k\
> 3/experiments/gcc-build/./gcc/
> -B/home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/bin/
> -B/home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/lib/ -isystem /h\
> ome/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/include -isystem
> /home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/sys-include-g
> -O2 -m32 -O2 -g -O2 -D\
> IN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition -isystem ./include
> -fpic -mlong-double-80 -\
> g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic
> -mlong-double-80 -I. -I. -I../../.././gcc -I../../../../gcc/libgcc
> -I../../../../gcc/libgcc/. \
> -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include
> -I../../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
> -DHAVE_CC_TLS -DUSE_\
> TLS -o morestack.o -MT morestack.o -MD -MP -MF morestack.dep -c
> -xassembler-with-cpp -include morestack.vis
> ../../../../gcc/libgcc/config/i386/morestack.S
> ./morestack.vis: Assembler messages:
> ./morestack.vis:1: Error: junk at end of line, first unrecognized
> character is `:'
>
> workaround compile like this ;
> /home/h4ck3rm1k3/experiments/gcc-build/./gcc/xgcc -c
> -B/home/h4ck3rm1k3/experim\
> ents/gcc-build/./gcc/
> -B/home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/bin/
> -B/home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/lib/ -isystem
> /home/h4ck3\
> rm1k3/install/x86_64-unknown-linux-gnu/include -isystem
> /home/h4ck3rm1k3/install/x86_64-unknown-linux-gnu/sys-include-g
> -O2 -m32 -O2 -g -O2 -DIN_GCC \
> -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition -isystem ./include
> -fpic -mlong-double-80 -g -DIN_LI\
> BGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80
> -I. -I. -I../../.././gcc -I../../../../gcc/libgcc
> -I../../../../gcc/libgcc/. -I../../.\
> ./../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include
> -I../../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
> -DHAVE_CC_TLS -DUSE_TLS -o mo\
> restack.o -MT morestack.o -MD -MP morestack.s
>
>
> Then the file is empty libgcc.map, it is generated by some complex sed
> script, but it is failing.
> /usr/bin/ld:libgcc.map:1: syntax error in VERSION script
>
> anyone else had this problem?
>
> mike
>
> --
> James Michael DuPont
> Member of Free Libre Open Source Software Kosova http://flossk.org
> Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com
> Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
> Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
> Free Software Foundation Europe Fellow http://fsfe.org/support/?h4ck3rm1k3
