Re: -Os is weak...
On Fri, Sep 10, 2010 at 10:44:24AM +0200, Steven Bosscher wrote: > On Thu, Sep 9, 2010 at 6:43 PM, DJ Delorie wrote: > > > I guess the most important missing optimizations are various forms of > code unification, such as the sequence abstraction code that GCC used > to have (http://gcc.gnu.org/projects/cfo.html, but it never worked > properly and it was way too slow), or some suffix-tree based sequence > finding code. Various algorithms can be found in the academic > literature about code size optimizations via abstraction (see e.g. > "Procedural Abstraction with Reverse Prefix Trees", > http://portal.acm.org/citation.cfm?id=1545074). Was CFO finally merged to mainline? At least, I can't find it in current gcc. > Personally, I had hoped that the ARM folks (Linaro, or what's it > called?) would work on -Os. While I've never actually used it, a web > search suggests that the RealView compilers generate code that is as > much as 20% smaller than GCC at -Os (for unnamed benchmarks), so > apparently there is a lot of room for improvement in GCC and the ARM > people should know where. > We, Linaro Toolchain Working Group, are doing the investigation on code size improvements on thumb-2. As you said, there would be a lot of room for improvement, and here is the report we got, fyi. http://lists.linaro.org/pipermail/linaro-toolchain/2010-September/000202.html > Finally, of course there are just various issues with instruction > selection in GCC that result in larger-than-necessary code. It seems > that this doesn't hurt code speed so much, but for code size GCC > doesn't always select the shortes sequence possible. Some Google folks > (Carrot Wei in particular) have filed bugs and patches for a couple of > cases for ARM, but there is no target-independent frame work for > selecting the shortest insn or sequence. During the investigation, I feel that all the potential improvements are identified by ARM experts or by reading asm code manually. This mode doesn't scale very well. IMO, it is necessary to have a target-independent framework for code size optimization. I have no idea to do that framework though. -- Yao Qi CodeSourcery y...@codesourcery.com (650) 331-3385 x739
Re: array of pointer to function support in GNU C
On Wed, Sep 15, 2010 at 11:15 PM, ir_idjit wrote:
>
> i've been writing bits of codes where it requires to have an array or
> "pointers to functions", so the decision of which function to execute is
> indexed... (i know, a lot of you will say "well, that's a VERY specific of a
> solution, there's always the problem of binary compatibility when passing
> arguments for different argument-taking functions, blah, blah, blah... just
> rely on good old fashioned function calls with conditional statements..."
> but, pls, forget about that sort of incompatibility...)
>
> even if i hadn't tried it in C++, i know it should work as i've seen some
> examples posted on the net. but i'm trying to write my code in GNU C, so it
> could be compiled by GCC -- god knows i would never try to compile it in GNU
> C++; that gargantuan thing
>
> but whatever i do it i just can't get it to work
> code:
>
> some_header.h:
> static void *(*oper_table)(void **);
>
>
>
> main.c:
> int main(void)
> {
> oper_table[0]; /* just a test. data is not used or modified*/
oper_table[0](NULL); // you decoared it to receive a parameter... and
even if it didn't you'd need ().
> return 1;
> }
>
> error: subscripted value is pointer to function
>
>
>
>
> whereas:
> int main(void)
> {
> void *(*func)(void **);
> func;
strange that this does anything... since it also requires a pointer to
a pointer...
> return 1;
> }
>
> compiles just fine
>
> i do realize that i'm depending on dialect-specific features, so i don't
> even know if this is supported on my gcc as of version 4.3.3. if it's not a
> dialect problem, then this stumps me even more.
> --
> View this message in context:
> http://old.nabble.com/array-of-pointer-to-function-support-in-GNU-C-tp29725303p29725303.html
> Sent from the gcc - Dev mailing list archive at Nabble.com.
>
>
Re: -Os is weak...
Yao Qi writes: > > During the investigation, I feel that all the potential improvements > are identified by ARM experts or by reading asm code manually. This > mode doesn't scale very well. IMO, it is necessary to have a > target-independent framework for code size optimization. I have no > idea to do that framework though. On x86 gcc is definitely behind some other compilers in terms of code size. Try reading some examples from http://embed.cs.utah.edu/embarrassing/ Since the criteria of the comparisons is code size it can show you where gcc is behind some other compilers (but note that these comparisons do not include the best compilers for small size and also do not run with -Os currently) This is for x86, but could be probably used for other architectures too. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: -Os is weak...
On Thu, Sep 16, 2010 at 9:35 AM, Yao Qi wrote: > Was CFO finally merged to mainline? At least, I can't find it in > current gcc. Yes, it was merged. And then it was removed again because the implementation had several big problems. Such as, it didn't actually work. Ciao! Steven
Mixed mode __complex__ arithmetic
Hi, I have a patch in testing which streamlines a bit and wanted to make sure we are supporting well mixed-mode __complex__ arithmetic, like: __complex__ double cd1; __complex__ float cf1; cd1 *= cf1; are we aware of any special problem in this area? Thanks! Paolo.
Re: array of pointer to function support in GNU C
On Thu, 16 Sep 2010 00:50:07 -0700
J Decker wrote:
[...]
> > int main(void)
> > {
> > void *(*func)(void **);
> > func;
> strange that this does anything... since it also requires a pointer to
> a pointer...
I think the compiler is right: "func" is a pointer to a function.
Since the () operator (function call) is not used, it simply parses as
an expression without any side effect. Same as
char *x;
x;
Zoltan
new canadian mirror
Hello! http://gcc.skazkaforyou.com location: Canada Please contact me about this mirror. Thanks. Sergey
Re: -Os is weak...
On Thu, Sep 16, 2010 at 10:55:22AM +0200, Andi Kleen wrote: > Try reading some examples from http://embed.cs.utah.edu/embarrassing/ > Since the criteria of the comparisons is code size it can show > you where gcc is behind some other compilers > > (but note that these comparisons do not include the best compilers > for small size and also do not run with -Os currently) I'm not denying that there is lots of room for -Os code size improvements, but from the http://embed.cs.utah.edu/embarrassing/ results GCC doesn't perform that bad in comparison with other compilers (gcc 3.4 best, then icc and then gcc 4.5), and all the results there were from -Os compilations across the different compilers. Jakub
Re: Mixed mode __complex__ arithmetic
On Thu, 16 Sep 2010, Paolo Carlini wrote: > Hi, > > I have a patch in testing which streamlines a bit and wanted > to make sure we are supporting well mixed-mode __complex__ arithmetic, like: > > __complex__ double cd1; > __complex__ float cf1; > > cd1 *= cf1; > > are we aware of any special problem in this area? I am not aware of any problems. The complex float value will be converted to complex double as required by C99. -- Joseph S. Myers jos...@codesourcery.com
Re: Mixed mode __complex__ arithmetic
On 09/16/2010 05:26 PM, Joseph S. Myers wrote:
> I am not aware of any problems. The complex float value will be converted
> to complex double as required by C99.
>
Thanks Joseph, good to now. For your curiosity, I was trying to change
the code like this:
Index: complex
===
--- complex (revision 164337)
+++ complex (working copy)
@@ -1132,10 +1132,7 @@
complex&
operator*=(const complex<_Tp>& __z)
{
- _ComplexT __t;
- __real__ __t = __z.real();
- __imag__ __t = __z.imag();
- _M_value *= __t;
+ _M_value *= __z.__rep();
return *this;
}
but unfortunately I can't really do it, because _Tp can be != floating
point type. For floating point types it would work.
Paolo.
Re: ICE with GCC-4.5.1-20100708
On 7/16/2010 08:46, Yaakov (Cygwin/X) wrote:
On Fri, 2010-07-16 at 02:06 +0200, Angelo Graziosi wrote:
Testing the mingw64-i686* packages found at
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW (Cygwin cross
compiler, see[*]), I have obtained an ICE:
$ cat ICE_test.cpp
void foo(char const* upattern, int color)
{
static short bitmap_data[8];
for (int i = 0; i< 8; i++)
{
bitmap_data[i] = (unsigned char)~upattern[i];
}
}
$ mingw32-g++ -O3 -c ICE_test.cpp
ICE_test.cpp: In function ‘void foo(const char*, int)’:
ICE_test.cpp:1:6: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:3157
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Using '-O0/-O1/-O2' in place of '-O3' option, works just fine!
Confirmed. Note that this does not occur with the other cross-targets
compiled from the same snapshot (i686-pc-mingw32, x86_64-w64-mingw32,
i686-pc-linux-gnu), even with -O3.
Yaakov
Cygwin Ports
Adding mingw-w64-public to CC.
Re: Bugzilla outage Friday, September 17, 18:00GMT-21:00GMT
On Wed, Sep 15, 2010 at 1:44 PM, Ian Lance Taylor wrote: > Thanks to sterling work by Frédéric Buclin, the gcc.gnu.org overseers > group is preparing to upgrade gcc.gnu.org bugzilla to a current version. > We will be taking bugzilla offline on Friday, September 17, for three > hours starting at 18:00GMT, 11:00PDT to do a final database upgrade and > conversion to the new system. Please let us know if this is an > intolerable inconvenience. Due to unforeseen hardware problems (not at gcc.gnu.org) we are going to postpone this upgrade and outage. We will keep people updated. Sorry for the false alarm. Ian
About LTO merging symbol tables
Hi All, Does the lto module merge all the global symbol tables maintained by each function together? I mean, for example, if in two function bodies there are two global variable (suppose its name is aaa) references . Are the VAR_DECL nodes of variable aaa in the two function bodies is the same node? Thanks, Hongtao Yu Purdue University
Re: About LTO merging symbol tables
On Thu, Sep 16, 2010 at 18:06, Hongtao wrote: > Hi All, > > Does the lto module merge all the global symbol tables maintained by > each function together? I mean, for example, if in two function bodies > there are two global variable (suppose its name is aaa) references . Are > the VAR_DECL nodes of variable aaa in the two function bodies is the > same node? If they can be merged under the One Definition Rule, then yes. Otherwise, an error is emitted. It uses the same rules used by the linker. Diego.
gcc-4.5-20100916 is now available
Snapshot gcc-4.5-20100916 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100916/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 164348 You'll find: gcc-4.5-20100916.tar.bz2 Complete GCC (includes all of below) MD5=69e95a246c4b0e69a1e9b38c8b9155b3 SHA1=47c7546aaa7d62d8e57da3aa1575158caa8dcc5f gcc-core-4.5-20100916.tar.bz2C front end and core compiler MD5=e34e185eb88f0dc37a97beef48e8c919 SHA1=4679c8eea60539c9cf63835bb99530ff591f881f gcc-ada-4.5-20100916.tar.bz2 Ada front end and runtime MD5=e50a28bba6cf6ce8263f98080c77b1eb SHA1=48df523801a8285350e3452fc0aa91749f3b4416 gcc-fortran-4.5-20100916.tar.bz2 Fortran front end and runtime MD5=5bbd2b5b5389192f83c5c3601152864b SHA1=4ef0b3ff03755b0d11597df02a49390f7f3a178d gcc-g++-4.5-20100916.tar.bz2 C++ front end and runtime MD5=9ac9f3907fccc8e6e174ab1fa1aea636 SHA1=a643d60e2a645c7f3aa3e4be1f905ed869a84e8d gcc-java-4.5-20100916.tar.bz2Java front end and runtime MD5=8eabf68e8347036c660b75c530719eaa SHA1=6b7156d82f6f8cf301fe933914ca30e3b3e20bb5 gcc-objc-4.5-20100916.tar.bz2Objective-C front end and runtime MD5=99c19e49f2dda54309ee669900c8d61b SHA1=c74d39953ada52d3ac3fb29918c6e8fbf6336fd3 gcc-testsuite-4.5-20100916.tar.bz2 The GCC testsuite MD5=cef1f41ee1024c380694ed0b1d373d43 SHA1=2e9da3c46d3e926483578037ae8e7283a532cc84 Diffs from 4.5-20100909 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
[C++-0x] User-defined literals.
Greetings,
I am slowly working on user defined literals for C++-0x.
This is my first foray into the C++ front end and I'm stuck.
Anyway, I managed to parse things like
long double
operator"" _foo(long double x) { return 2.0L * x; }
The result is a normal function that I can either call like
operator "" _foo(1.2L);
or just
_foo(1.2L);
The problem is when I parse something like
u"string"w
I want to generate a call to something like
std::string operator"" w(const char16_t*, size_t);
i.e. I want to build a call:
w(u"string", 6);
I have a (not nearly ready for prime time) patch attached. My current
problem is in parser.c cp_parser_primary_expression after the string types.
Thanks for any help you can give,
Ed
Index: gcc/cp/error.c
===
--- gcc/cp/error.c (revision 164355)
+++ gcc/cp/error.c (working copy)
@@ -3033,7 +3033,12 @@
pedwarn (input_location, OPT_pedantic,
"inline namespaces "
"only available with -std=c++0x or -std=gnu++0x");
- break;
+ break;
+ case CPP0X_USER_DEFINED_LITERALS:
+ pedwarn (input_location, 0,
+"user-defined literals "
+"only available with -std=c++0x or -std=gnu++0x");
+ break;
default:
gcc_unreachable();
}
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 164355)
+++ gcc/cp/parser.c (working copy)
@@ -3579,13 +3579,50 @@
case CPP_STRING32:
case CPP_WSTRING:
case CPP_UTF8STRING:
- /* ??? Should wide strings be allowed when parser->translate_strings_p
-is false (i.e. in attributes)? If not, we can kill the third
-argument to cp_parser_string_literal. */
- return cp_parser_string_literal (parser,
- parser->translate_strings_p,
- true);
+ {
+ tree strl;
+ cp_token *next_token;
+ /* ??? Should wide strings be allowed when parser->translate_strings_p
+ is false (i.e. in attributes)? If not, we can kill the third
+ argument to cp_parser_string_literal. */
+ strl = cp_parser_string_literal (parser,
+parser->translate_strings_p,
+true);
+
+ next_token = cp_lexer_peek_token (parser->lexer);
+ if (next_token->type == CPP_NAME)
+ {
+ tree identifier;
+ VEC(tree,gc) *vec;
+ int len = TREE_STRING_LENGTH (strl);
+
+ identifier = cp_parser_identifier(parser);
+ if (identifier == error_mark_node)
+ return error_mark_node;
+
+ /* Build up a call to the user-defined operator */
+ vec = make_tree_vector ();
+ VEC_safe_push (tree, gc, vec, strl);
+ VEC_safe_push (tree, gc, vec, build_int_cst (size_type_node, len));
+ identifier = perform_koenig_lookup (identifier, vec,
+ /*include_std=*/false);
+ if (identifier == error_mark_node)
+ {
+ release_tree_vector (vec);
+ error ("unable to find user-defined operator");
+ return error_mark_node;
+ }
+ identifier = finish_call_expr (identifier, &vec, false, true,
+ tf_warning_or_error);
+ release_tree_vector (vec);
+
+ return identifier;
+ }
+ else
+ return strl;
+ }
+
case CPP_OPEN_PAREN:
{
tree expr;
@@ -10927,6 +10964,31 @@
cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE);
return ansi_opname (ARRAY_REF);
+case CPP_STRING:
+ {
+ if (cxx_dialect == cxx98)
+ maybe_warn_cpp0x (CPP0X_USER_DEFINED_LITERALS);
+ if (TREE_STRING_LENGTH (token->u.value) > 2)
+ {
+ error ("expected empty string after % keyword");
+ return error_mark_node;
+ }
+ /* Consume the string. */
+ cp_lexer_consume_token (parser->lexer);
+ /* Look for an identifier. */
+ id = cp_parser_identifier (parser);
+
+ /* Look for a `('. */
+ token = cp_lexer_peek_token (parser->lexer);
+ if (token->type != CPP_OPEN_PAREN)
+ {
+ error ("expected function declaration");
+ return error_mark_node;
+ }
+
+ return id;
+ }
+
default:
/* Anything else is an error. */
break;
Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h(revision 164355)
+++ gcc/cp/cp-tree.h(working copy)
@@ -389,7 +389,9 @@
/* defaulted and deleted functions */
CPP0X_DEFAULTED_DELETED,
/* inline namespaces */
- CPP0X_INLINE_NAMESPACES
+ CPP0X_INLINE
