Re: What does zero-length array mean at file scope?
Joseph S. Myers wrote: > On Sun, 24 May 2009, Andrew Haley wrote: > >> Of course we have to fix the assembler output. For [any] two declarations >> a and b, &a != &b, even when a is a zero-length array. So, you have to >> allocate at least one byte. > > I don't think this is necessarily part of the semantics for the GNU > extensions of zero-length arrays and empty structures. Certainly when > they are used in the middle of a structure they are not expected to take > up any space (so their address may be the same as that of the next > member). I see. In that this breaks the semantics of C in a pretty fundamental way this is pretty bad, but it's been in gcc for a long time. Andrew.
Problems with sibling calls
Hi, I'd like to support sibling calls for a target where function args can be passed in call-saved registers, namely AVR. The trouble is this: If a callee gets some arguments passed on the stack or in call-saved regs, the callee is not ok for a sibling call. That's because sibcall_epilogue executes before sibcall insns. All this information is pretty easy available in FUNCTION_ARGS resp. FUNCTION_ARG_ADVANCE and can be stored in CUMULATIVE_ARGS. However, the place where the information is needed is in targetm.function_ok_for_sibcall (aka. TARGET_FUNCTION_OK_FOR_SIBCALL), and that hook only gets the function decl and call expression trees, but these trees do not contain information about where the calle's arguments get passed. How can that be fixed? Most probably, I am missing something, and the information is hidden somewhere is the trees passed to targetm.function_ok_for_sibcall? All of the following fixed I considered are not nice: =1= Store the needed information in a static backend variable. Store in FUNCTION_ARG et al. and use it in TARGET_FUNCTION_OK_FOR_SIBCALL. Bad, because this makes implications on the way calls.c runs the backend hooks. May break if local functions are involved. =2= Copy the machinery that elaborates the function arguments from calls.c to the backend and redo all the work on the arguments to be passed. =3= Introduce a new backend hook bool targetm.function_ok_for_sibcall_with_cum (tree, tree, CUMULATIVE_ARGS*); and call it with &args_so_far from calls.c:expand_call I'd prefer =3= but I don't want to change the middle end. =1= works (AVR does not implement local functions) fine but seems too hacky. =2= might work but is overkill. So what am I missing here? Is there some other approach to solve this? If =3= is appropriate I could workout a patch and provide it (calls.c, targetm, docs/tm.texi, ...). Thanks much cheers, Georg-Johann
MinGW toolchain build failure for M16CM32C
Hi, I am trying to build a MinGW toolchain for M16CM32C target using the following sources: GCC-4.4.0 Binutils-2.19 Newlib-1.17 The linux toolchain was built successfully, however MinGW toolchain build failed. During make, I get the following error. -- i386-pc-mingw32msvc-gcc -c -g -O2 -D__USE_MINGW_ACCESS -Wall -Wconversion -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../generic" -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win" -mwin32 -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DBUILD_tcl /home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../compat/strtoll.c -o strtoll.o i386-pc-mingw32msvc-gcc -c -g -O2 -D__USE_MINGW_ACCESS -Wall -Wconversion -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../generic" -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win" -mwin32 -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DBUILD_tcl /home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../compat/strtoull.c -o strtoull.o o tcl.res.o --include "/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../generic" --include "/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win" /home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/tcl.rc /bin/sh: o: command not found make[3]: [tcl.res.o] Error 127 (ignored) i386-pc-mingw32msvc-gcc -shared -g -O2 -D__USE_MINGW_ACCESS -Wl,--stack,8388608 -o tcl84.dll -mwin32-Wl,--out-implib,libtcl84.a regcomp.o regexec.o regfree.o regerror.o tclAlloc.o tclAsync.o tclBasic.o tclBinary.o tclCkalloc.o tclClock.o tclCmdAH.o tclCmdIL.o tclCmdMZ.o tclCompCmds.o tclCompExpr.o tclCompile.o tclDate.o tclEncoding.o tclEnv.o tclEvent.o tclExecute.o tclFCmd.o tclFileName.o tclGet.o tclHash.o tclHistory.o tclIndexObj.o tclInterp.o tclIO.o tclIOCmd.o tclIOGT.o tclIOSock.o tclIOUtil.o tclLink.o tclLiteral.o tclListObj.o tclLoad.o tclMain.o tclNamesp.o tclNotify.o tclObj.o tclPanic.o tclParse.o tclParseExpr.o tclPipe.o tclPkg.o tclPosixStr.o tclPreserve.o tclProc.o tclRegexp.o tclResolve.o tclResult.o tclScan.o tclStringObj.o tclStubInit.o tclStubLib.o tclThread.o tclThreadAlloc.o tclThreadJoin.o tclTimer.o tclUtf.o tclUtil.o tclVar.o tclWin32Dll.o tclWinChan.o tclWinConsole.o tclWinSerial.o tclWinError.o tclWinFCmd.o tclWinFile.o tclWinInit.o tclWinLoad.o tclWinMtherr.o tclWinNotify.o tclWinPipe.o tclWinSock.o tclWinThrd.o tclWinTime.o strftime.o strtoll.o strtoull.o tcl.res.o i386-pc-mingw32msvc-gcc: tcl.res.o: No such file or directory make[3]: *** [tcl84.dll] Error 1 -- The native MinGW toolchain (i386-pc-mingw32msvc-gcc) for i386 was built using the following source. GCC-3.4.5 Any help would be highly appreciated. Thanking you in anticipation. Regards, Mahesh Shavari
Re: MinGW toolchain build failure for M16CM32C
2009/5/29 Mahesh Basavaraj Shavari :
> Hi,
> I am trying to build a MinGW toolchain for M16CM32C target using the
> following sources:
>
> GCC-4.4.0
> Binutils-2.19
> Newlib-1.17
>
> The linux toolchain was built successfully, however MinGW toolchain build
> failed.
> During make, I get the following error.
>
> --
> i386-pc-mingw32msvc-gcc -c -g -O2 -D__USE_MINGW_ACCESS -Wall -Wconversion
> -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../generic"
> -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win" -mwin32 -DPACKAGE_NAME=\"\"
> -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
> -DPACKAGE_BUGREPORT=\"\" -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DBUILD_tcl
> /home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../compat/strtoll.c -o strtoll.o
> i386-pc-mingw32msvc-gcc -c -g -O2 -D__USE_MINGW_ACCESS -Wall -Wconversion
> -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../generic"
> -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win" -mwin32 -DPACKAGE_NAME=\"\"
> -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
> -DPACKAGE_BUGREPORT=\"\" -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DBUILD_tcl
> /home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../compat/strtoull.c -o strtoull.o
> o tcl.res.o --include
> "/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../generic" --include
> "/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win"
> /home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/tcl.rc
> /bin/sh: o: command not found
> make[3]: [tcl.res.o] Error 127 (ignored)
> i386-pc-mingw32msvc-gcc -shared -g -O2 -D__USE_MINGW_ACCESS
> -Wl,--stack,8388608 -o tcl84.dll -mwin32
> -Wl,--out-implib,libtcl84.a regcomp.o regexec.o regfree.o regerror.o
> tclAlloc.o tclAsync.o tclBasic.o tclBinary.o tclCkalloc.o tclClock.o
> tclCmdAH.o tclCmdIL.o tclCmdMZ.o tclCompCmds.o tclCompExpr.o tclCompile.o
> tclDate.o tclEncoding.o tclEnv.o tclEvent.o tclExecute.o tclFCmd.o
> tclFileName.o tclGet.o tclHash.o tclHistory.o tclIndexObj.o tclInterp.o
> tclIO.o tclIOCmd.o tclIOGT.o tclIOSock.o tclIOUtil.o tclLink.o tclLiteral.o
> tclListObj.o tclLoad.o tclMain.o tclNamesp.o tclNotify.o tclObj.o tclPanic.o
> tclParse.o tclParseExpr.o tclPipe.o tclPkg.o tclPosixStr.o tclPreserve.o
> tclProc.o tclRegexp.o tclResolve.o tclResult.o tclScan.o tclStringObj.o
> tclStubInit.o tclStubLib.o tclThread.o tclThreadAlloc.o tclThreadJoin.o
> tclTimer.o tclUtf.o tclUtil.o tclVar.o tclWin32Dll.o tclWinChan.o
> tclWinConsole.o tclWinSerial.o tclWinError.o tclWinFCmd.o tclWinFile.o
> tclWinInit.o tclWinLoad.o tclWinMtherr.o tclWinNotify.o tclWinPipe.o
> tclWinSock.o tclWinThrd.o tclWinTime.o strftime.o strtoll.o strtoull.o
> tcl.res.o
> i386-pc-mingw32msvc-gcc: tcl.res.o: No such file or directory
> make[3]: *** [tcl84.dll] Error 1
> --
>
> The native MinGW toolchain (i386-pc-mingw32msvc-gcc) for i386 was built using
> the following source.
> GCC-3.4.5
>
> Any help would be highly appreciated.
> Thanking you in anticipation.
>
> Regards,
> Mahesh Shavari
>
>
Hello,
it seems so that you makefile tries to compile resource file (.rc) via
gcc frontend. This fails AFAIK. Instead the windres tool (part of
binutils) have to be invoked here. This should fix your problem.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: MinGW toolchain build failure for M16CM32C
2009/5/29 Kai Tietz :
> 2009/5/29 Mahesh Basavaraj Shavari :
>> Hi,
>> I am trying to build a MinGW toolchain for M16CM32C target using the
>> following sources:
>>
>> GCC-4.4.0
>> Binutils-2.19
>> Newlib-1.17
>>
>> The linux toolchain was built successfully, however MinGW toolchain build
>> failed.
>> During make, I get the following error.
>>
>> --
>> i386-pc-mingw32msvc-gcc -c -g -O2 -D__USE_MINGW_ACCESS -Wall -Wconversion
>> -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../generic"
>> -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win" -mwin32 -DPACKAGE_NAME=\"\"
>> -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
>> -DPACKAGE_BUGREPORT=\"\" -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int
>> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
>> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DBUILD_tcl
>> /home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../compat/strtoll.c -o strtoll.o
>> i386-pc-mingw32msvc-gcc -c -g -O2 -D__USE_MINGW_ACCESS -Wall -Wconversion
>> -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../generic"
>> -I"/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win" -mwin32 -DPACKAGE_NAME=\"\"
>> -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
>> -DPACKAGE_BUGREPORT=\"\" -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int
>> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
>> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DBUILD_tcl
>> /home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../compat/strtoull.c -o
>> strtoull.o
>> o tcl.res.o --include
>> "/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/../generic" --include
>> "/home/RX_FINAL_V0901/KPIT/src-cross/tcl/win"
>> /home/RX_FINAL_V0901/KPIT/src-cross/tcl/win/tcl.rc
>> /bin/sh: o: command not found
>> make[3]: [tcl.res.o] Error 127 (ignored)
>> i386-pc-mingw32msvc-gcc -shared -g -O2 -D__USE_MINGW_ACCESS
>> -Wl,--stack,8388608 -o tcl84.dll -mwin32
>> -Wl,--out-implib,libtcl84.a regcomp.o regexec.o regfree.o regerror.o
>> tclAlloc.o tclAsync.o tclBasic.o tclBinary.o tclCkalloc.o tclClock.o
>> tclCmdAH.o tclCmdIL.o tclCmdMZ.o tclCompCmds.o tclCompExpr.o tclCompile.o
>> tclDate.o tclEncoding.o tclEnv.o tclEvent.o tclExecute.o tclFCmd.o
>> tclFileName.o tclGet.o tclHash.o tclHistory.o tclIndexObj.o tclInterp.o
>> tclIO.o tclIOCmd.o tclIOGT.o tclIOSock.o tclIOUtil.o tclLink.o tclLiteral.o
>> tclListObj.o tclLoad.o tclMain.o tclNamesp.o tclNotify.o tclObj.o tclPanic.o
>> tclParse.o tclParseExpr.o tclPipe.o tclPkg.o tclPosixStr.o tclPreserve.o
>> tclProc.o tclRegexp.o tclResolve.o tclResult.o tclScan.o tclStringObj.o
>> tclStubInit.o tclStubLib.o tclThread.o tclThreadAlloc.o tclThreadJoin.o
>> tclTimer.o tclUtf.o tclUtil.o tclVar.o tclWin32Dll.o tclWinChan.o
>> tclWinConsole.o tclWinSerial.o tclWinError.o tclWinFCmd.o tclWinFile.o
>> tclWinInit.o tclWinLoad.o tclWinMtherr.o tclWinNotify.o tclWinPipe.o
>> tclWinSock.o tclWinThrd.o tclWinTime.o strftime.o strtoll.o strtoull.o
>> tcl.res.o
>> i386-pc-mingw32msvc-gcc: tcl.res.o: No such file or directory
>> make[3]: *** [tcl84.dll] Error 1
>> --
>>
>> The native MinGW toolchain (i386-pc-mingw32msvc-gcc) for i386 was built
>> using the following source.
>> GCC-3.4.5
>>
>> Any help would be highly appreciated.
>> Thanking you in anticipation.
>>
>> Regards,
>> Mahesh Shavari
>>
>>
>
> Hello,
>
> it seems so that you makefile tries to compile resource file (.rc) via
> gcc frontend. This fails AFAIK. Instead the windres tool (part of
> binutils) have to be invoked here. This should fix your problem.
>
> Cheers,
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
Second remark. In you build line there is a typo. Not sure if this a
paste issue, but
... "win/../compat/strtoull.c -o strtoull.o o tcl.res.o" ...
is wrong. There is a '-' missing before 'o'. It should be something like
... "win/../compat/strtoull.c -o strtoull.o -o tcl.res.o" ...
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
[OT] Re: MinGW toolchain build failure for M16CM32C
Kai Tietz wrote: > Second remark. In you build line there is a typo. Not sure if this a > paste issue, but > > ... "win/../compat/strtoull.c -o strtoull.o o tcl.res.o" ... > > is wrong. There is a '-' missing before 'o'. It should be something like > > ... "win/../compat/strtoull.c -o strtoull.o -o tcl.res.o" ... Don't miss also this error, buried among the rest: /bin/sh: o: command not found > make[3]: [tcl.res.o] Error 127 (ignored) Looks to me like $(WINDRES) is empty, and that was actually a separate line from the compiler command-line that got wrapped together in transmission. (Not that teaching gcc how to handle .rc files wouldn't be a nice idea!) As this is not remotely a GCC problem, but a makefile or autoconf problem in the distribution, you should follow it up on a more related mailing list. (Looks from the path names like this is one of KPIT's bundles, do they have a support forum?) cheers, DaveK
Re: Problems with sibling calls
Georg-Johann Lay wrote: > The trouble is this: If a callee gets some arguments passed on the stack > or in call-saved regs, the callee is not ok for a sibling call. That's > because sibcall_epilogue executes before sibcall insns. > > All this information is pretty easy available in FUNCTION_ARGS resp. > FUNCTION_ARG_ADVANCE and can be stored in CUMULATIVE_ARGS. > > However, the place where the information is needed is in > targetm.function_ok_for_sibcall (aka. TARGET_FUNCTION_OK_FOR_SIBCALL), > and that hook only gets the function decl and call expression trees, but > these trees do not contain information about where the calle's arguments > get passed. > > How can that be fixed? Most probably, I am missing something, and the > information is hidden somewhere is the trees passed to > targetm.function_ok_for_sibcall? > So what am I missing here? Is there some other approach to solve this? The standard answer is that frame layout and other per-function info is stored in the "struct function" machine-dependent part of the global 'cfun' current function struct. See: http://gcc.gnu.org/onlinedocs/gccint/Per_002dFunction-Data.html cheers, DaveK
Re: Problems with sibling calls
Georg-Johann Lay writes: > The trouble is this: If a callee gets some arguments passed on the > stack or in call-saved regs, the callee is not ok for a sibling > call. That's because sibcall_epilogue executes before sibcall insns. I'm having trouble with your terminology "call-saved regs". Do that mean "caller-saved regs" or "callee-saved regs"? I gather that in the case where f wants to make a sibling call to g, the problem is that this fails if g accepts arguments anywhere other than in registers which are neither caller-saved nor callee-saved. I would expect that that would be fairly easy to determine from the call expression. You can be conservative when doing something odd like passing a struct: the only effect would be that in an extremely small number of cases gcc would make a regular call when it could make a sibling call. > Introduce a new backend hook >bool targetm.function_ok_for_sibcall_with_cum (tree, tree, > CUMULATIVE_ARGS*); > and call it with &args_so_far from calls.c:expand_call It would be OK to change the existing hook to add a CUMULATIVE_ARGS* parameter, but unfortunately you don't have the CUMULATIVE_ARGS at the point where it is called. Adding another one does seem pretty ugly. Ian
RFC: Option handling and PR 37565
While looking into PR 37565 I began to wonder if we need to modify how
we handle optimization flag handling. Currently we have
OVERRIDE_OPTIONS, C_COMMON_OVERRIDE_OPTIONS, and OPTIMIZATION_OPTIONS to
set or override the optimization flags a user gives. One proposal to
fix 37565 was to split OVERRIDE_OPTIONS into OVERRIDE_OPTIONS_ALWAYS and
OVERRIDE_OPTIONS_ONCE which would create two new macros.
But I was wondering if a cleaner method to deal with these options would
be to get rid of all these macros and use target functions to access
flag values.
My idea is that we would never change the values of the flags that are
set by the user but instead would have a target overridable function
that returns the value for a given flag by default but in which the
return value could be overridden for some flags on some targets.
So instead of
if (flag_var_tracking)
we would have
if (targetm.get_optimization_flag_value(OPT_fvar_tracking))
The default behaviour of get_optimization_flag_value when passed
OPT_fvar_tracking would be to return the value of flag_var_tracking but
if a particular target didn't support this optimization they could have
a target specific version of get_optimization_flag_value that always
returned 0 for OPT_fvar_tracking. That way we don't have to use
OVERRIDE_OPTIONS to set flag_var_tracking to 0 or worry about it getting
reset by the __optimize__ attribute.
Here is a patch to define the target overridable get_optimization_flag_value
function as well as a set_optimization_flag_value function. I also
modified opth-gen.awk and optc-gen.awk to make the flags static so that
the rest of the compiler would have to use these functions. Obviously
the compiler won't build after applying this patch because we would have
to change all the flag references but I thought I would send this
proposal out before doing any more work in that direction.
What do people think? Does this seem like a reasonable direction to go?
Does anyone see any blockers to this idea? If we wanted to proceed down
this path it seems like we could either do it with a big bang approach
(making flags static and change all accesses) or gradually by not making
the flags static and gradually introducing the use of the
get_optimization_flag_value function over time.
2009-05-29 Steve Ellcey
PR middle-end/37565
PR target/37106
* opth-gen.awk: Remove extern decls of flags.
Add decls for default_get_optimization_flag_value
and set_optimization_flag_value.
* optc-gen.awk: Make flags static.
Define default_get_optimization_flag_value
and set_optimization_flag_value.
* target.h (gcc_target): Add get_optimization_flag_value.
* target-def.h (TARGET_GET_OPTIMIZATION_FLAG_VALUE): New.
Index: optc-gen.awk
===
--- optc-gen.awk(revision 147259)
+++ optc-gen.awk(working copy)
@@ -534,6 +534,29 @@ print " if (targetm.target_option.print
print "targetm.target_option.print (file, indent, ptr);";
print "}";
+print "";
+print "int";
+print "default_get_flag_value(enum opt_code code)";
+print "{";
+print "#ifdef ENABLE_CHECKING";
+for (i = 0; i < n_opts; i++) {
+ enum = "OPT_" opts[i];
+ if (opts[i] == "finline-limit=" || opts[i] == "Wlarger-than=") {
+ enum = enum "eq";
+ }
+ gsub ("[^A-Za-z0-9]", "_", enum);
+ name = var_name(flags[i]);
+if (name == "") {
+ print " if (code == " enum ") gcc_unreachable ();";
+ }
+ else {
+ print " if (code == " enum " && cl_options[(int)
code].flag_var != &" name ") gcc_unreachable ();";
+ }
+}
+print "#endif";
+print " gcc_assert(cl_options[(int) code].flag_var);";
+print " return *(cl_options[(int) code].flag_var);";
+print "}";
print "#endif";
}
Re: Problems with sibling calls
Ian Lance Taylor schrieb: Georg-Johann Lay writes: The trouble is this: If a callee gets some arguments passed on the stack or in call-saved regs, the callee is not ok for a sibling call. That's because sibcall_epilogue executes before sibcall insns. I'm having trouble with your terminology "call-saved regs". Do that mean "caller-saved regs" or "callee-saved regs"? They are callee-saved in that case. I gather that in the case where f wants to make a sibling call to g, the problem is that this fails if g accepts arguments anywhere other than in registers which are neither caller-saved nor callee-saved. I would expect that that would be fairly easy to determine from the call expression. You can be conservative when doing something odd like passing a struct: the only effect would be that in an extremely small number of cases gcc would make a regular call when it could make a sibling call. Yes that's right. It would work if I recreate the information which code a couple of lines away did already, I just wanted to avoid doubling (some parts of) the code/work in order to keep the backend clean. Moreover, calls.c is far from being short and straight forward, and obviously many different cases must be handled. Many cases will disappear because the implementation is for a specific machine, though. Introduce a new backend hook bool targetm.function_ok_for_sibcall_with_cum (tree, tree, CUMULATIVE_ARGS*); and call it with &args_so_far from calls.c:expand_call It would be OK to change the existing hook to add a CUMULATIVE_ARGS* parameter, but unfortunately you don't have the CUMULATIVE_ARGS at the point where it is called. Adding another one does seem pretty ugly. Yes, having two hooks that do almost the same is odd. The original TARGET_FUNCTION_OK_FOR_SIBCALL could always return true and the new one would be the worker instead. But that's definitely ugly. And the two hooks would need different default implementations (one returning false and the other true). I am working with 4.3.3, and there args_fo_far is available when the hook gets called. The final call to FUNCTION_ARG with mode=VOIDmode will follow after the hook, which seems reasonable to me. Georg-Johann
Re: Problems with sibling calls
Dave Korn schrieb: Georg-Johann Lay wrote: The trouble is this: If a callee gets some arguments passed on the stack or in call-saved regs, the callee is not ok for a sibling call. That's because sibcall_epilogue executes before sibcall insns. All this information is pretty easy available in FUNCTION_ARGS resp. FUNCTION_ARG_ADVANCE and can be stored in CUMULATIVE_ARGS. However, the place where the information is needed is in targetm.function_ok_for_sibcall (aka. TARGET_FUNCTION_OK_FOR_SIBCALL), and that hook only gets the function decl and call expression trees, but these trees do not contain information about where the calle's arguments get passed. How can that be fixed? Most probably, I am missing something, and the information is hidden somewhere is the trees passed to targetm.function_ok_for_sibcall? So what am I missing here? Is there some other approach to solve this? The standard answer is that frame layout and other per-function info is stored in the "struct function" machine-dependent part of the global 'cfun' current function struct. Yep, thanks much! That's the right place to store the information and will solve the local function problem. But this will only (or is intended to) track information for the caller, not information needed for the callee that was gathered in the mentioned hooks. It can be used, of course, to exchange data between hooks provided with CUMULATIVE_ARGS and hooks that aren't, but it would still make implications on how the hooks get called in calls.c:expand_call(). Georg-Johann
Re: Problems with sibling calls
Georg-Johann Lay wrote: > But this will only (or is intended to) track information for the caller, > not information needed for the callee that was gathered in the mentioned > hooks. It can be used, of course, to exchange data between hooks > provided with CUMULATIVE_ARGS and hooks that aren't, but it would still > make implications on how the hooks get called in calls.c:expand_call(). You decide whether to allow sibcalls on a per-caller basis generally. All the information needed to know how the arguments will be passed is available at the call site, and your backend knows how arguments are passed, so it can decide then whether the callee is also suitable or not. It shouldn't be a significant overhead even if you have to evaluate the suitability of the same callee multiple times in independent callers. cheers, DaveK
Re: Problems with sibling calls
Georg-Johann Lay wrote: > Yes that's right. It would work if I recreate the information which code > a couple of lines away did already, I just wanted to avoid doubling > (some parts of) the code/work in order to keep the backend clean. Well, then don't! Factor out the common parts of your stack layout and arg passing into subroutines that can be called from multiple places in your backend. > Moreover, calls.c is far from being short and straight forward, and > obviously many different cases must be handled. Many cases will > disappear because the implementation is for a specific machine, though. You shouldn't need to be doing anything to calls.c itself, unless I've missed something seriously complicated here. cheers, DaveK
Re: RFC: Option handling and PR 37565
Steve Ellcey writes: > So instead of > if (flag_var_tracking) > we would have > if (targetm.get_optimization_flag_value(OPT_fvar_tracking)) I don't particularly want to have to make an indirect function call every time we check a flag. I don't see why we should check every time when we can determine the value once when the compiler starts. Also, we would still need a place to give backend warnings like unwind tables currently require either a frame pointer or -maccumulate-outgoing-args for correctness So I guess I don't much like the idea. Ian
Re: RFC: Option handling and PR 37565
On Fri, 29 May 2009, Steve Ellcey wrote: > While looking into PR 37565 I began to wonder if we need to modify how > we handle optimization flag handling. Currently we have > OVERRIDE_OPTIONS, C_COMMON_OVERRIDE_OPTIONS, and OPTIMIZATION_OPTIONS to > set or override the optimization flags a user gives. One proposal to > fix 37565 was to split OVERRIDE_OPTIONS into OVERRIDE_OPTIONS_ALWAYS and > OVERRIDE_OPTIONS_ONCE which would create two new macros. > > But I was wondering if a cleaner method to deal with these options would > be to get rid of all these macros and use target functions to access > flag values. I don't really feel that either the original proposal or this one is any cleaner than what we have right now, and the original proposal is at least simpler. As neither really addresses the general issues with how options are handled (as I see them), on the whole I'd prefer the simpler way of fixing the bug that is at least easier to tear out later. The way I see it, the basic problem is the large amount of ad hoc code, much of it target-specific, handling options, their defaults and their interactions. The PR you mention is one problem arising from this; it's difficult for options in optimize attributes to work like those on the command line. Another group of problems relate to specs and multilib selection; these have no access to the code in the compiler proper handling option interactions and defaults and instead make piecemeal attempts to replicate bits of that logic, badly. Both proposals involve new target hooks or macros, moving ad hoc code around rather than eliminating it. These can use arbitrary C code to manipulate option state. This is very flexible, but flexibility can be bad; we want consistent rules in GCC for how partially overlapping or overriding options should interact, for example, and it should be hard for particular targets or options to break those consistent rules accidentally. Consistency tends to argue for making .opt files more expressive rather than proliferating hooks or macros. My general idea is that there should be some sort of object for the compiler global state - both target-dependent and and target-independent - derived from the command line. (The cl_optimization structure is a useful start to this.) The compiler should maintain several such objects at once. There would be one for the command line immediately after being parsed, before any defaults get applied that would be affected by optimize attributes, and a global one with defaults applied that is used by references to flag variables. optimize attributes might create a function-local options structure by copying the pre-defaults one, applying the function-local options to it and then calling the hooks to apply defaults to that structure. Multilib selection might compute structures for each multilib and match them to the structure for the command line. Where you suggest: > My idea is that we would never change the values of the flags that are > set by the user but instead would have a target overridable function > that returns the value for a given flag by default but in which the > return value could be overridden for some flags on some targets. > > So instead of > if (flag_var_tracking) > we would have > if (targetm.get_optimization_flag_value(OPT_fvar_tracking)) I'd instead suggest #define flag_var_tracking ((int) global_options.optimization.fvar_tracking) (automatically generated) or similar. The cast makes it not an lvalue, which is a good idea because I also don't want random code changing the options; changes to the structure should be limited to particular places (automatically generated from .opt files where possible) receiving a pointer to the particular structure they are to change. I think any solution other than a temporary, minimally intrusive fix for specific bugs that have been found needs to start with a detailed analysis of how and why the present hooks are used in existing targets, resulting in an understanding of the requirements for a solution and proposals for consistent rules on how options interact. -- Joseph S. Myers jos...@codesourcery.com
Re: RFC: Option handling and PR 37565
Ian Lance Taylor wrote: > Steve Ellcey writes: > >> So instead of >> if (flag_var_tracking) >> we would have >> if (targetm.get_optimization_flag_value(OPT_fvar_tracking)) > > I don't particularly want to have to make an indirect function call > every time we check a flag. I don't see why we should check every time > when we can determine the value once when the compiler starts. The PR is about the interaction between backend optimisation overrides and "pragma GCC optimize" and the __optimize__ attribute. Since these change as compilation proceeds, the backend's choices at compiler startup may need to be revisited. However I also feel it's a bit of a top-heavy solution. What's wrong with the simple ONCE/ALWAYS split proposed by HJ in comment #8? cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565#c8
Re: RFC: Option handling and PR 37565
On Fri, 2009-05-29 at 09:38 -0700, Ian Lance Taylor wrote: > Steve Ellcey writes: > > > So instead of > > if (flag_var_tracking) > > we would have > > if (targetm.get_optimization_flag_value(OPT_fvar_tracking)) > > I don't particularly want to have to make an indirect function call > every time we check a flag. I don't see why we should check every time > when we can determine the value once when the compiler starts. But if we want to fully support things like the __optimize__ attribute then we can't just check once when the compiler starts. The flag could be changed during compilation by the optimize attribute so at the very least we need to override some values every time we see this attribute (which is what we are not doing now). > Also, we would still need a place to give backend warnings like > > unwind tables currently require either a frame pointer or > -maccumulate-outgoing-args for correctness Warnings are an issue, but again we have the problem that we can't just do warnings once at the beginning since values could be changed during compilation. Maybe the set function should also be overridable so that it could issue warnings when a variable is set though that wouldn't help with the above warning since it looks like it needs to be given when something isn't set. I am not sure I have an answer to this problem. > So I guess I don't much like the idea. > > Ian Steve Ellcey s...@cup.hp.com
Re: RFC: Option handling and PR 37565
On Fri, 2009-05-29 at 16:56 +, Joseph S. Myers wrote: > I don't really feel that either the original proposal or this one is any > cleaner than what we have right now, and the original proposal is at least > simpler. As neither really addresses the general issues with how options > are handled (as I see them), on the whole I'd prefer the simpler way of > fixing the bug that is at least easier to tear out later. I thought my proposal was cleaner because we could have a rule that says flags are only changed by user specified flags and by the optimize attribute. target code could look at those values and other variables to determine if it wanted to do a particular optimization or not but it wouldn't ever change the flag value that was set on the command line or by the attribute. > Both proposals involve new target hooks or macros, moving ad hoc code > around rather than eliminating it. These can use arbitrary C code to > manipulate option state. This is very flexible, but flexibility can be > bad; we want consistent rules in GCC for how partially overlapping or > overriding options should interact, for example, and it should be hard for > particular targets or options to break those consistent rules > accidentally. Consistency tends to argue for making .opt files more > expressive rather than proliferating hooks or macros. I think that what I want to do is remove the manipulating (changing) of the option state completely (except by user flags and the optimization attribute) and make the use/access of that state more flexible then just checking a single flag. > Where you suggest: > > > My idea is that we would never change the values of the flags that are > > set by the user but instead would have a target overridable function > > that returns the value for a given flag by default but in which the > > return value could be overridden for some flags on some targets. > > > > So instead of > > if (flag_var_tracking) > > we would have > > if (targetm.get_optimization_flag_value(OPT_fvar_tracking)) > > I'd instead suggest > > #define flag_var_tracking ((int) global_options.optimization.fvar_tracking) > > (automatically generated) or similar. The cast makes it not an lvalue, > which is a good idea because I also don't want random code changing the > options; changes to the structure should be limited to particular places > (automatically generated from .opt files where possible) receiving a > pointer to the particular structure they are to change. That would fix Ian's complaint about an indirect function call but it still means that the decision to do or not do var_tracking is kept in a single variable that might or might not need to be overridden in some case. But I guess in your proposal something in the opt file would tell us if we want to override the default behaviour for var_tracking and generate the code that would change it's value from the default. Steve Ellcey s...@cup.hp.com
Measuring FSF gcc from 4.1.2 to today on various benchmarks.
I've put at http://www.math.purdue.edu/~lucier/bugzilla/9/ some compile-time and run-time statistics related to PR 39157 and PR 33928 and compile times and run times for the programs in the Gambit Scheme benchmark suite. The statistics are for 4.1.2 release, 4.2.4 release, 4.3.3 release, 4.4.1 20090522, 4.5.0 20090521 (revision 147758), and 4.5.0 20090521 (revision 147758) with -fno-forward-propagate; they use (mainly) the set of options -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp on a Core 2 quad processor (running basically nothing else at the time). I would conclude from the statistics that, right now, the cost of including -fforward-propagate in -O1 overrides any performance benefit that may result. Brad
Re: RFC: Option handling and PR 37565
Steve Ellcey writes: > On Fri, 2009-05-29 at 09:38 -0700, Ian Lance Taylor wrote: >> Steve Ellcey writes: >> >> > So instead of >> >if (flag_var_tracking) >> > we would have >> >if (targetm.get_optimization_flag_value(OPT_fvar_tracking)) >> >> I don't particularly want to have to make an indirect function call >> every time we check a flag. I don't see why we should check every time >> when we can determine the value once when the compiler starts. > > But if we want to fully support things like the __optimize__ attribute > then we can't just check once when the compiler starts. The flag could > be changed during compilation by the optimize attribute so at the very > least we need to override some values every time we see this attribute > (which is what we are not doing now). Fair enough, but 99.9% of compilations will not use the __optimize__ attribute. So I still don't want to make an indirect function call every time we check a flag. Joseph's suggestion of a more disciplined approach to option interactions may be the way to go. We can at least handle many simple cases that way (this backend always enables/disables this option), while retaining a C function escape clause if there are complex ones. Ian
Problem with libpthread of uClibc
Hi, We are using ARM Cortex-A9 processor. The toolchain is gcc-4.0.0 with uClibc-0.9.30 and the kernel is 2.6.28. Using this toolchain when we build any application like "Hello World" and link it against pthread lib, the application does a segmentation fault when executed on target and gives "Illegal instruction" error message. I debugged the problem and it came out to be that "swp" instructions were disabled on the cortex-a9. The SWP instruction has been deprecated starting with the ARMv6 architecture. On newer ARMv7 processors, this instruction is disabled by default but it can be enabled by bit 10 in the System Control register. We can also build the kernel with CONFIG_OABI_COMPAT enabled. The real problem seems to be in the linuxthreads of uClibc where "swp" is being used for locks. Shall this not be replaced with ldrex/strex for ARMv7 onwards? Regards, Nitin
The Linux binutils 2.19.51.0.6 is release
This is the beta release of binutils 2.19.51.0.6 for Linux, which is
based on binutils 2009 0529 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.19.51.0.6 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.19.51.0.5:
1. Update from binutils 2009 0529.
2. Rewrite STT_GNU_IFUNC, R_386_IRELATIVE and R_X86_64_IRELATIVE linker
support for STT_GNU_IFUNC symbols in shared library, dynamic executable
and static executable.
3. Add plugin support.
4. Improve spu support.
Changes from binutils 2.19.51.0.4:
1. Update from binutils 2009 0525.
2. Add STT_GNU_IFUNC, R_386_IRELATIVE and R_X86_64_IRELATIVE support to
assembler and linker.
3. Add LD_AS_NEEDED support to linker.
4. Remove AMD SSE5 support.
5. A new Intel syntax parser in x86 assembler.
6. Add DWARF discriminator support.
7. Add --64 support for x86 PE/COFF assembler.
8. Support common symbol with alignment for PE/COFF.
9. Improve gold support.
10. Improve arm support.
11. Improve mep support.
12. Improve mips support.
13. Improve ppc support.
14. Improve spu support.
Changes from binutils 2.19.51.0.3:
1. Update from binutils 2009 0418.
2. Remove EFI targets and use PEI targets for EFI. Add --file-alignment,
--heap, --image-base, --section-alignment, --stack and --subsystem command
line options for objcopy. PR 10074.
3. Update linker to warn alternate ELF machine code.
4. Fix x86 linker TLS transition. PR 9938.
5. Improve DWARF dumper to check relocations against STT_SECTION
symbol.
6. Guard DWARF dumper on bad DWARF input.
7. Add EM_ETPU and EM_SLE9X. Reserve 3 ELF machine types for Intel.
8. Adding a linker missing entry symbol warning for -pie. PR 9970.
9. Make the -e option for linker to imply -u. PR 6766.
10. Properly handle paging for PEI targets.
11. Fix assembler listing with input from stdin.
12. Update objcopy/string to generate symbol table if there is any
relocation in output. PR 9945.
13. Require texinfo 4.7 for build. PR 10039.
14. Add moxie support.
15. Improve gold support.
16. Improve AIX support.
17. Improve arm support.
18. Improve cris support.
19. Improve crx support.
20. Improve mips support.
21. Improve ppc support.
22. Improve s390 support.
23. Improve spu support.
24. Improve vax support.
Changes from binutils 2.19.51.0.2:
1. Update from binutils 2009 0310.
2. Fix strip on common symbols
Re: Problem with libpthread of uClibc
Nitin Garg writes: > We are using ARM Cortex-A9 processor. The toolchain is gcc-4.0.0 with > uClibc-0.9.30 and the kernel is 2.6.28. > > Using this toolchain when we build any application like "Hello World" > and link it against pthread lib, the application does a segmentation > fault when executed on target and gives "Illegal instruction" error > message. > > I debugged the problem and it came out to be that "swp" instructions > were disabled on the cortex-a9. The SWP instruction has been > deprecated starting with the ARMv6 architecture. On newer ARMv7 > processors, this instruction is disabled by default but it can be > enabled by bit 10 in the System Control register. We can also build > the kernel with CONFIG_OABI_COMPAT enabled. > > The real problem seems to be in the linuxthreads of uClibc where "swp" > is being used for locks. > Shall this not be replaced with ldrex/strex for ARMv7 onwards? This message is not appropriate for the mailing list g...@gcc.gnu.org. gcc@gcc.gnu.org is for the discussion of gcc development. Please take any followups to this message to gcc-h...@gcc.gnu.org. Thanks. Actually I'm not sure there is any gcc issue here at all. gcc 4.0.0 is fairly old. Ian
Re: Using MPC Library with GCC
On Wed, 13 May 2009, Mark Mitchell wrote: > Kaveh R. GHAZI wrote: > > > 1. Consider MPC as an optional library now, install all the code and make > > it hard-required only when all the complex math functions are made > > available in a future released version of the library or sometime in > > stage3, whichever is first. > > I think this is the best option. > > Please make sure to open a P1 PR for 4.5.0 indicating that we should > throw the hard-requirement switch. The last patch to enable use of MPC in GCC was reviewed today and installed. I'm sure other updates will come, but the base functionality is now there. I've opened PR 40302 as you requested (and assigned myself). Thanks, --Kaveh
