Re: -Os is weak...
On Fri, 10 Sep 2010, Steven Bosscher wrote:
>> The docs say...
>>
>> @item -Os
>> @opindex Os
>> Optimize for size. �...@option{-os} enables all @option{-O2} optimizations
>> that
>> do not typically increase code size. It also performs further
>> optimizations designed to reduce code size.
>>
>> @option{-Os} disables the following optimization flags:
>> @gccoptlist{-falign-functions -falign-jumps -falign-loops @gol
>> -falign-labels -freorder-blocks -freorder-blocks-and-partition @gol
>> -fprefetch-loop-arrays -ftree-vect-loop-version}
> What you quote above, from the documentation, is also actually
> incomplete. The -Os option also enables optimizations that are not
> performed at -O[123], e.g. code hoisting only runs at -Os (see
> gcse.c:pass_rtl_hoist).
Any chance you could update the documentation, Steven or DJ?
Gerald
Handle macros like TARGET_OS_CPP_BUILTINS for non C-family frontends
Hi all,
I'm trying to see a way forward for PR 42954: when preprocessing Fortran source
files, we used to call the C preprocessor and run the Fortran compiler on the
generated file. We now use libcpp directly, but by doing so, we have lost a
good number of target-dependent CPP builtins that are defined via
TARGET_OS_CPP_BUILTINS and TARGET_CPU_CPP_BUILTINS macros. These macros were
used in real-life code (including mine!) for conditional compilation, and the
new behaviour is a regression.
The reason these macros can't be used directly can be seen on the example of
config/sol2.h:
#define TARGET_OS_CPP_BUILTINS()\
do {\
builtin_define_std ("unix");\
builtin_define_std ("sun"); \
/* For C++ we need to add some additional macro \
definitions required by the C++ standard \
library. */ \
if (c_dialect_cxx ()) \
{ \
builtin_define ("__STDC_VERSION__=199901L");\
builtin_define ("_XOPEN_SOURCE=600"); \
} \
TARGET_SUB_OS_CPP_BUILTINS(); \
} while (0)
(I've removed a few lines, but you get the idea.)
Calling c_dialect_cxx() is not going to work in the Fortran front-end, as this
is a function defined in c-family/c-common.h, which we don't include (and don't
want to include!). Other such problematic functions or variables include
flag_isoc99, flag_iso, flag_leading_underscore (see full list at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954).
How can we fix this? The only way I see would be to have two macros instead of
TARGET_OS_CPP_BUILTINS: one that will be used for source-preprocessing in all
languages (maybe keeping the name TARGET_OS_CPP_BUILTINS), and one that will be
used only for C-family languages (TARGET_OS_CPP_BUILTINS_CFAMILY). It seems
like a bit of work, to get everything in the right place. However, I don't
really see an alternative solution, which is why I'm writing here: would there
be any easier solution? Or one that makes more sense to you?
As this is a major change, I'd like to get this in before the end of stage1,
probably submitting it next week-end, if we can agree on a path for me to
implement.
Thanks for the help!
FX
Re: Handle macros like TARGET_OS_CPP_BUILTINS for non C-family frontends
On Sun, Sep 26, 2010 at 4:21 PM, FX wrote: > How can we fix this? The only way I see would be to have two macros > instead of TARGET_OS_CPP_BUILTINS: one that will be used for source- > preprocessing in all languages (maybe keeping the name > TARGET_OS_CPP_BUILTINS), and one that will be used only for C-family > languages (TARGET_OS_CPP_BUILTINS_CFAMILY). That seems to be the only solution, yes. I looked into this earlier this year when I was trying to separate the front-ends better from the middle-end (define interface, modularization, whatever...). Better than macros would be hooks, but macros would be a good start. One problem is that it isn't always clear what defines belong to CPP and what is C-family specific. > It seems like a bit of > work, to get everything in the right place. Yes, this is a big job, and it's not easy/mechanical either. Ciao! Steven
Re: Handle macros like TARGET_OS_CPP_BUILTINS for non C-family frontends
On Sun, 26 Sep 2010, FX wrote: > How can we fix this? The only way I see would be to have two macros > instead of TARGET_OS_CPP_BUILTINS: one that will be used for > source-preprocessing in all languages (maybe keeping the name > TARGET_OS_CPP_BUILTINS), and one that will be used only for C-family > languages (TARGET_OS_CPP_BUILTINS_CFAMILY). It seems like a bit of work, > to get everything in the right place. However, I don't really see an > alternative solution, which is why I'm writing here: would there be any > easier solution? Or one that makes more sense to you? If you're redesigning these macros, you ought to be designing things to use hooks instead anyway, though these macros probably aren't that easy to replace by hooks. You could I suppose define the hooks to take a structure of callbacks that they use in place of directly calling builtin_define or testing flag_isoc99 - or if you set up s separate hooks structure that is at least only used in front ends that link with libcpp, then you might reduce the number of callbacks needed. Or you could fully split things up as you suggest - put C-family-only hooks in targetcm, and libcpp-using hooks in a new structure. Splitting things up is probably cleaner than having a lot of callbacks. Whatever you do, you probably want to arrange for the code that is common between c-family/c-cppbuiltin.c and fortran/cpp.c (defining various language-independent macros) to be genuinely shared between front ends using libcpp, instead of duplicated. -- Joseph S. Myers jos...@codesourcery.com
Polyhedron Fortran benchmark - compiler comparison: Good results for GCC 4.6
Hello all, given the optimization work which has gone into 4.6, I thought I would run the Polyhedron Fortran test suite. The system is - Intel Core2 Duo CPU E8400 @ 3.00GHz - CentOS release 5.5 (Final) [x86-64] Tested compilers: - GCC 4.6 (recent nightly build) - Intel Fortran compiler (ifort) 11.1 - PathScale compiler (pathf95) 3.2.99 - Portland Group compiler (pgf90) 10.1 In case of GCC, I have two 'normal' compilations (gfortran64 and gfortranIMF2) and two using -flto -fwhole-program (gfortranLTO and gfortranIMF). Additionally, for gfortranIMF and gfortranIMF, LD_PRELOAD is used to preload Intel's libimf library, which replaces some libm functions. Result in a nutshell: - On geometric average, all compilers do not differ much - for single benchmarks, the difference can be rather large. On geometric means maximal difference is 10% - GCC (using LTO and GLIBC's libm), ifort and pathf95's performance is almost the same (< 1.5% difference) - pgi is about 6% slower. - Using Intel's libimf, GCC is (on geometric mean) the fastest compiler (3% faster than ifort and pathf95), without it is the slowest of the three (by <1.5%) The results are up at http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/iff/ Regarding the slow down of rnflow due to LTO, cf. PR Regarding the gas_dyn slowness, cf. PR 31067 Thanks to all who made it possible! Tobias PS: I really miss a GCC vectorization library; I could have used in addition -mveclibabi=svml, but I have decided that there are already enough results for GCC.
Re: Polyhedron Fortran benchmark - compiler comparison: Good results for GCC 4.6
On Sun, Sep 26, 2010 at 04:47:29PM +0200, Tobias Burnus wrote: > Hello all, > > given the optimization work which has gone into 4.6, I thought I would > run the Polyhedron Fortran test suite. I was interested in seeing how 4.6 stacks up against previous versions of gfortran. On x86_64-*-freebsd, using my preferred set of options, I see Benchmark gfc42gfc43gfc44gfc45gfc4x Name (secs) (secs) (secs) (secs) (secs) - --- --- --- --- --- ac41.7417.7917.7617.4816.59 aermod44.6645.7047.2146.2341.41 air22.5922.2923.2619.5819.68 capacita 116.02 117.91 112.57 116.89 116.43 channel20.5220.5620.3320.8320.83 doduc50.4149.8653.2650.2050.22 fatigue21.8616.6614.6912.4813.18 gas_dyn20.1216.1616.0615.3714.42 induct65.5762.2549.1032.5932.82 linpk45.1344.5645.1245.0849.17 mdbx24.1123.7522.9723.0723.01 nf59.3459.4158.7256.0454.94 protein68.8569.7269.8270.2465.35 rnflow52.3651.8150.8750.4050.34 test_fpu32.6633.6633.8933.6933.92 tfft11.9511.5911.5011.5911.79 Geo. Mean37.1634.0433.3331.5731.28 options: -O2 -march=native -funroll-loops -ftree-vectorize gfc42 --> gcc version 4.2.5 20090330 gfc43 --> gcc version 4.3.6 20100903 gfc44 --> gcc version 4.4.5 20100903 gfc45 --> gcc version 4.5.1 20100728 gfc4x --> gcc version 4.6.0 20100916 In general, I like the trend in the geometric mean. The linpk tests looks suspicious but I've had no time to investiagte. -- Steve
gcc-4.3-20100926 is now available
Snapshot gcc-4.3-20100926 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100926/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 164638 You'll find: gcc-4.3-20100926.tar.bz2 Complete GCC (includes all of below) MD5=f2ee385e4677912b98006911ca4918b7 SHA1=d0d87b3576408ddab9714998480a2adbf950a217 gcc-core-4.3-20100926.tar.bz2C front end and core compiler MD5=b54d592bed35da9cdbb2488b5ad34d80 SHA1=11c80ec1497024a3a5f3714b0969b7006862535f gcc-ada-4.3-20100926.tar.bz2 Ada front end and runtime MD5=80e3e2cb1e72b2fbe33f6574d1adc3b0 SHA1=433f4d847c95301fbb8c2ff62b3dfe7838c0b641 gcc-fortran-4.3-20100926.tar.bz2 Fortran front end and runtime MD5=e79a50064578d1ce6019c7f504729243 SHA1=ddada61089d10b052af77aff35826ae85503223b gcc-g++-4.3-20100926.tar.bz2 C++ front end and runtime MD5=7f7fe49847071bcfa15f26e592762172 SHA1=781800e644fc18c775971c3186bdd597c6d9fdc6 gcc-java-4.3-20100926.tar.bz2Java front end and runtime MD5=c7c125a7cd201a8851d0466ab229b77c SHA1=148d6fb5b7f24c7c7cd7c572e403affbe4c57eee gcc-objc-4.3-20100926.tar.bz2Objective-C front end and runtime MD5=de04a6ad3de264dababf905072b1972a SHA1=9219a97a7ea9c033a729202af634cf0e17d7f9e7 gcc-testsuite-4.3-20100926.tar.bz2 The GCC testsuite MD5=10e844ed73b02ff67026d4ec24efbfef SHA1=30ae39ee1dfb0773a3b5dbacd7d5d5f7735c6c5b Diffs from 4.3-20100919 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
eliminating mpc/mpfr and reducing gmp
Hi. You know, gmp/mpfr/mpc are a significant portion of building any frontend/backend. So I looked at it. mpc of course is only for complex numbers. Our frontend doesn't use them. Maybe only for "builtins" as well. #define do_mpc_arg1(a, b, c) NULL_TREE and such. mpfr appears to be used for floating point builtins. Not for floating point constant folding as I'd thought? We generate very few builtins, just memcmp, memset, memmove, memcpy, and *sync*. Either way, floating point doesn't matter to me much. #define do_mpfr_arg1(a,b,c) NULL_TREE and such. including something_logarithm, something_exponent. And #if out the version report in toplev.c. And the then unused conversions in real.c. and the #include in real.h. and then mpfr isn't needed. That is: changes to gcc to eliminate mpc and mpfr dependencies are pretty darn small. I used #if 1/#if 0, but it'd be easy enough to have configure -without-mpc -without-mpfr. I was able to do this for 4.5, and then 4.3 was trivial, the same except no mpc. And then, if you dig a bit more, you find that gmp contains "n", "q" (rational), "z", "f" (float), and miscellaneous e.g. *rand*. (apples and oranges: *rand* must operate on some mp type, of course) None of "q" and "f" are needed, and vast swaths of "n" and "z" are unused and can be deleted. Easier to truncate the files first when experimenting. Probably can do even better. There is a file in GMP dumbmp.c (as in dump, stupid) that contains a simple portable subset of GMP, used for some "generator" programs. First glance says it isn't sufficient, but it might be close.. The result is a lot faster to build, if you are just doing a just a single stage build of a compiler. To some extent it adds up -- multiple stages. To some extent it is is minor -- if you are building libstdc++/libada/libjava x multilibs. I build just a frontend/backend though. I understand you can also build/install the libraries once. That isn't a terrible option. I have operated that away. But does have drawbacks. It is harder for Canadian cross and "cross back" (cross build a native compiler), which admittedly, I don't do much. There were problems last I tried, esp. with enable-shared and fixincludes, and it always a pain to get the C runtime headers/libraries. The first I opened bugs for. The second can't really be fixed, except e.g. with an integrated tree with glibc/newlib. Maybe some people have scripts out there to scp the appropriate files. I end up taking way more than necessary and sometimes hunting around for what I missed. and gmp doesn't build with default gcc 4.0 on Intel MacOSX 10.5. Building within the gcc tree is one workaround, because how it fiddles with CFLAGS and seemingly accidentally avoids the problems with "inline". Granted, CC=gcc-4.2 is another easy one. Other options. Anyway. - Jay
passing #define-d values to #define-d macros
i can seem to get this to work:
#define PREFIX "p_"
#define HIGHER_INTERFACE(id) LOWER_INTERFACE(PREFIX, id)
#define LOWER_INTERFACE(prefix, id) struct prefix##id \
{ \
int i; \
}
int main(void)
{
HIGHER_INTERFACE(0);
/* test if struct declaration went well: */
struct p_0 var;
return 0;
}
when i compile with gcc 4.3.3 it says:
"error: storage size of 'var' isn't known"
i know c preprocessor has MANY shortcomings (or maybe it isn't, maybe those
were supposed to be handled by the development environment's make system)...
but if you're writing libraries that can be easily ported to many system
with VERY LITTLE modification, shouldn't this tiny functionality been
adressed?? an escape character would've been nice
--
View this message in context:
http://old.nabble.com/passing--define-d-values-to--define-d-macros-tp29815182p29815182.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: passing #define-d values to #define-d macros
drives me crazy that i can't get his to work -- View this message in context: http://old.nabble.com/passing--define-d-values-to--define-d-macros-tp29815182p29815215.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: passing #define-d values to #define-d macros
On Sun, Sep 26, 2010 at 06:09:34PM -0700, ir_idjit wrote:
> i can seem to get this to work:
>
> #define PREFIX "p_"
> #define HIGHER_INTERFACE(id) LOWER_INTERFACE(PREFIX, id)
>
> #define LOWER_INTERFACE(prefix, id) struct prefix##id \
> { \
> int i; \
> }
>
> int main(void)
> {
> HIGHER_INTERFACE(0);
>
> /* test if struct declaration went well: */
> struct p_0 var;
> return 0;
> }
This question is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for gcc development. It would be appropriate for a forum about
using the C language, such as the newsgroup comp.lang.c or
gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks.
Your problem can be solved by using another layer of indirection and
making PREFIX to not be a string:
#define PREFIX p_
#define HIGHER_INTERFACE(id) L2(PREFIX, id)
#define L2(prefix,id) LOWER_INTERFACE(prefix,id)
#define LOWER_INTERFACE(prefix, id) struct prefix##id \
{ \
int i; \
}
int main(void)
{
HIGHER_INTERFACE(0);
/* test if struct declaration went well: */
struct p_0 var;
return 0;
}
-Nathan
signed/unsigned comparison warning level
Can the severity of signed/unsigned comparisons be raised, since GCC
does not properly handle the comparisons.
Every example below is false compiled with gcc 4.5.0
int main()
{
int s = -2;
unsigned int u = 0xFFFDU;
if( s < u )
printf( "okay\n" );
else
printf( "incorrect handling\n" ); // gets here
{
int i = -2;
unsigned u = 2;
if (i < u) {
// Does GCC get here? no, it doesn't
printf( "Ya, of course\n" );
}
else
printf( "gcc puked\n" ); // gets here
}
{
unsigned int i = -3;
if( i < 0 )
printf( "this can't happen, it's unsigned.\n" );
else
printf( "this is actually a correct result here\n" ); // does
get this
}
{
int i = -3;
// visual studio does not warn on this one either... just the first
two comparisons
if( i < (unsigned)0 )
printf( "-3 is < 0 \n" );
else
printf( "-3 is more than 0?\n" ); // gets here
}
return 0;
}
---
I said a lot of words on
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/d0ec33f0-2534-48f8-9673-538d68d8ef86
to describe how this might be handled and even if 5% of the cases
were fixed, it would be 250% better overall.
I don't know why standards left this open, other than there isn't a
single-instruction translation from code to CPU for the comparison;
But if it's not fixed, this warning should definatly be issued at
default warning level. This should be more like 'if this comparison
can be wrong, it will be wrong'.
Re: signed/unsigned comparison warning level
J Decker writes:
> Can the severity of signed/unsigned comparisons be raised, since GCC
> does not properly handle the comparisons.
GCC properly handles the comparisons according to the rules laid down in
the C/C++ language standards.
> int main()
>
> {
> int s = -2;
> unsigned int u = 0xFFFDU;
>
> if( s < u )
> printf( "okay\n" );
> else
> printf( "incorrect handling\n" ); // gets here
The language standards say that s is promoted from int to unsigned int
(C99 6.3.1.8). The conversion from int to unsigned int produces
0xfffe (assuming int is 32 bits) (C99 6.3.1.3). 0xfffe <
0xfffd is false.
> {
> int i = -2;
> unsigned u = 2;
> if (i < u) {
> // Does GCC get here? no, it doesn't
> printf( "Ya, of course\n" );
> }
> else
> printf( "gcc puked\n" ); // gets here
> }
Here the comparison is between 0xfffe and 2.
>{
>
> unsigned int i = -3;
>if( i < 0 )
>printf( "this can't happen, it's unsigned.\n" );
>else
> printf( "this is actually a correct result here\n" ); // does
> get this
> }
An unsigned integer is always >= 0, by definition.
>{
>
> int i = -3;
> // visual studio does not warn on this one either... just the first
> two comparisons
> if( i < (unsigned)0 )
>printf( "-3 is < 0 \n" );
>else
> printf( "-3 is more than 0?\n" ); // gets here
> }
>
> return 0;
>
> }
Same here.
> I don't know why standards left this open, other than there isn't a
> single-instruction translation from code to CPU for the comparison;
The standards did not leave this open. They define precisely what is
supposed to happen.
> But if it's not fixed, this warning should definatly be issued at
> default warning level. This should be more like 'if this comparison
> can be wrong, it will be wrong'.
There is no problem comparing values of signed type with values of
unsigned type if the signed values are known to be nonnegative. Of
course it is sometimes hard to know that; hence the warning. But
enabling the warning by default does not make sense.
Ian
Re: signed/unsigned comparison warning level
> The standards did not leave this open. They define precisely what is > supposed to happen. > Really? I'll have to drop this whole lobbying effort then. That makes me sad that they didn't define it to be comparing of the numbers where there are overlaps in signed and unsigned instead of causing all negative signed values to be wrong. > >> But if it's not fixed, this warning should definatly be issued at >> default warning level. This should be more like 'if this comparison >> can be wrong, it will be wrong'. > > There is no problem comparing values of signed type with values of > unsigned type if the signed values are known to be nonnegative. Of > course it is sometimes hard to know that; hence the warning. But > enabling the warning by default does not make sense. > It's exactly the fact that 'of course it is sometimes' that makes the warning make more sense to be on by default. I don't always know that I've added an unsigned value to an expression, causing one side of a comparison to become unsigned, resulting in 100% failure on negative signed result comparison. > Ian >
