Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux
Paolo Carlini schrieb:
> Paolo Carlini wrote:
>> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
>> case conservative to have a link type test identical to the one used in
>> libgomp and libgfortran and a fall back to the .s file (as currently used).
>>
> I committed the below to mainline. Assuming no issues are noticed with
> it, I mean to apply it to 4_4-branch too in a few days.
with this patch applied to the 4.4 branch, the tests now succeed as expected on
the 4_4-branch on {armeabi,hppa,sparc}-linux.
thanks, Matthias
Re: [Announcement] Creating lightweight IPO branch
Xinliang David Li writes: > > If the idea is generally accepted, I will prepare a series of patches > and submit them to gcc trunk. I was reading your wiki page. Interesting idea. One aspect that wasn't clear to me on reading it was how different compiler arguments for different files are handled. How would the compiler compiling another source file know what special arguments (like -I -D or special -f options) it needs? Or in what directory it was compiled in for -I paths? Or do you assume that is always all the same? The other thing that wasn't clear to me was the worst case behaviour. If there's a single large file x.c that has a function that is called from 100 other small files with hot call sites then x.c would be compiled 100 times, right? Is there something to mitigate such worst case behaviour? Thanks, -Andi -- a...@linux.intel.com -- Speaking for myself only.
[gcc trunk on cygwin] ../../gcc/gcc/config/i386/msformat-c.c:[39,40,41,42,43,44,58,75,87,110,128,145] error: enum conversion in initialization is invalid in C++
This is on Windows XP Pro/SP3 cygwin Intel Core2 Duo t9...@2.80ghz system with packages: binutils 20080624-2 2.18.50.20080625 bison2.3-1 2.3 cloog-ppl0.15.3-1 cygwin 1.7.0-46 dejagnu 20021217-2 1.4.2.x expect 20030128-1 5.26 gcc-ada 3.4.4-999 gcc-core 3.4.4-999 gcc-g++ 3.4.4-999 gmp 4.3.0-1 libcloog-devel 0.15.3-1 libgmp-devel 4.3.0-1 libmpfr-devel2.4.1-3 libppl 0.10.2-1 make 3.81-2 mpfr 2.4.1-3 ppl 0.10.2-1 ppl-devel0.10.2-1 tcltk20080420-1 8.4 w32api 3.13-1 LAST_UPDATED: Tue May 5 06:34:47 UTC 2009 (revision 147118) configured by ../gcc/configure, generated by GNU Autoconf 2.59, with options \" '--enable-threads=posix' '--without-ppl' '--without-cloog' '--enable-languages=c,c++' /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev-gcc/ -B/usr/local/i686-pc-cygwin/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber \ ../../gcc/gcc/config/i386/msformat-c.c cc1: warnings being treated as errors ../../gcc/gcc/config/i386/msformat-c.c:39: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:39: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:40: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:40: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:41: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:41: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:42: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:42: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:43: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:43: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:44: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:44: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:44: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:44: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:58: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:75: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:87: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:110: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:128: error: enum conversion in initialization is invalid in C++ ../../gcc/gcc/config/i386/msformat-c.c:145: error: enum conversion in initialization is invalid in C++ make[3]: *** [msformat-c.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 Any hints on what's going on and how to cure the issue? -- Cheers, /ChJ
Re: -combine option for C++ sources
2009/5/5 Pramod Joisha : > > > Presently, the -combine option works only for C sources. I was wondering > whether there are technical reasons for not supporting it for C++ sources. If > not, are there plans for providing this support in the near future? As LTO will obsolete -combine I do not see that -combine will be ever implemented for anything else besides C. Richard.
Re: [gcc trunk on cygwin] ../../gcc/gcc/config/i386/msformat-c.c:[39,40,41,42,43,44,58,75,87,110,128,145] error: enum conversion in initialization is invalid in C++
Christian Joensson wrote: > ../../gcc/gcc/config/i386/msformat-c.c:39: error: enum conversion in > initialization is invalid in C++ > Any hints on what's going on and how to cure the issue? Yep: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00125.html (and thread). cheers, DaveK
Re: [gcc trunk on cygwin] ../../gcc/gcc/config/i386/msformat-c.c:[39,40,41,42,43,44,58,75,87,110,128,145] error: enum conversion in initialization is invalid in C++
2009/5/5 Dave Korn : > Christian Joensson wrote: > >> ../../gcc/gcc/config/i386/msformat-c.c:39: error: enum conversion in >> initialization is invalid in C++ > >> Any hints on what's going on and how to cure the issue? > > Yep: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00125.html (and thread). Thanks, I'll hold on a while for the agreed, eventually, patch to be committed. -- Cheers, /ChJ
Re: [Announcement] Creating lightweight IPO branch
On Tue, May 5, 2009 at 7:00 AM, Xinliang David Li wrote: > Hi, I am going to create a gcc branch for the functionality of > lightweight IPO. The description of the project and current status can > be found in http://gcc.gnu.org/wiki/LightweightIpo. Some highlights: > > 1) If you already use FDO in your build, you also get IPO almost for free; > 2) It is an IPO solution practical to very large real world C++ applications; > 3) Performance potential is very large (though I've seen case > increased compiler freedom can lead to performance degradation due to > over-optimization (inliner, unroller etc) -- but this is a different > matter). > > If the idea is generally accepted, I will prepare a series of patches > and submit them to gcc trunk. I was hoping that with LTO we can get rid of -combine, as its type/decl merging is fragile in many cases. Does this somehow conflict with LIPO? From what I understand is that you are merging TUs in the frontend (like -combine) - did you consider merging TUs with the LTO infrastructure, but in memory? On the whole LIPO sounds indeed very interesting. Thanks, Richard.
Re: Re: -combine option for C++ sources
On Tue, 5 May 2009, Richard Guenther wrote: > 2009/5/5 Pramod Joisha : > > > > > > Presently, the -combine option works only for C sources. I was > > wondering whether there are technical reasons for not supporting it > > for C++ sources. If not, are there plans for providing this support in > > the near future? > > As LTO will obsolete -combine I do not see that -combine will be > ever implemented for anything else besides C. Formally there are things -combine does that LTO doesn't (front-end-specific consistency checks across translation units, supporting non-ELF targets). But I agree we should deprecate -combine when LTO goes in (or better, deprecate the mechanism it uses and make the driver transparently wrap LTO if possible); the consistency checks might better be done through plugins, and there should be no great difficulty in adding LTO support for non-ELF targets (that support arbitrary named sections) if desired. (The C++ front end should still grow some sort of support for handling information from multiple translation units at once to implement exported templates, but that's another matter.) -- Joseph S. Myers jos...@codesourcery.com
C_MAYBE_CONST_EXPR, PR16302, Wlogical-op and make_range/merge_ranges
I have the following code for implementing a new warning (PR16302). It
works as intended but I feel there is some duplication with the code
in fold_range_test (fold_const.c). However, fold_range_test cannot
handle arguments that contain C_MAYBE_CONST_EXPR, hence the explicit
testing I added below.
Any suggestions?
Is this sufficient or is there any way to do this "properly" ?
/* Warn about uses of logical || / && operator in a context where it
is likely that the bitwise equivalent was intended by the
programmer. We have seen an expression in which CODE is a binary
- operator used to combine expressions OP_LEFT and OP_RIGHT, which
- before folding had CODE_LEFT and CODE_RIGHT. */
-
+ operator used to combine expressions OP_LEFT and OP_RIGHT, which
before folding
+ had CODE_LEFT and CODE_RIGHT, into an expression of type TYPE. */
void
-warn_logical_operator (location_t location, enum tree_code code,
+warn_logical_operator (location_t location, enum tree_code code, tree type,
enum tree_code code_left, tree op_left,
enum tree_code ARG_UNUSED (code_right), tree op_right)
{
+ int or_op = (code == TRUTH_ORIF_EXPR || code == TRUTH_OR_EXPR);
+ int in0_p, in1_p, in_p;
+ tree low0, low1, low, high0, high1, high, lhs, rhs, tem;
+ bool strict_overflow_p = false;
+
if (code != TRUTH_ANDIF_EXPR
&& code != TRUTH_AND_EXPR
&& code != TRUTH_ORIF_EXPR
&& code != TRUTH_OR_EXPR)
return;
@@ -1740,17 +1744,65 @@ warn_logical_operator (location_t locati
&& !TREE_NO_WARNING (op_left)
&& TREE_CODE (op_right) == INTEGER_CST
&& !integer_zerop (op_right)
&& !integer_onep (op_right))
{
- if (code == TRUTH_ORIF_EXPR || code == TRUTH_OR_EXPR)
+ if (or_op)
warning_at (location, OPT_Wlogical_op, "logical %"
" applied to non-boolean constant");
else
warning_at (location, OPT_Wlogical_op, "logical %"
" applied to non-boolean constant");
TREE_NO_WARNING (op_left) = true;
+ return;
+}
+
+ /* We do not warn for constants because they are typical of macro
+ expansions that test for features. */
+ if (CONSTANT_CLASS_P (op_left) || CONSTANT_CLASS_P (op_right))
+return;
+
+ /* This warning only makes sense with logical operands. */
+ if (!(truth_value_p (TREE_CODE (op_left))
+ || INTEGRAL_TYPE_P (TREE_TYPE (op_left)))
+ || !(truth_value_p (TREE_CODE (op_right))
+ || INTEGRAL_TYPE_P (TREE_TYPE (op_right
+return;
+
+ lhs = make_range (op_left, &in0_p, &low0, &high0, &strict_overflow_p);
+ rhs = make_range (op_right, &in1_p, &low1, &high1, &strict_overflow_p);
+
+ if (lhs && TREE_CODE (lhs) == C_MAYBE_CONST_EXPR)
+lhs = C_MAYBE_CONST_EXPR_EXPR (lhs);
+
+ if (rhs && TREE_CODE (rhs) == C_MAYBE_CONST_EXPR)
+rhs = C_MAYBE_CONST_EXPR_EXPR (rhs);
+
+ /* If this is an OR operation, invert both sides; we will invert
+ again at the end. */
+ if (or_op)
+in0_p = !in0_p, in1_p = !in1_p;
+
+ /* If both expressions are the same, if we can merge the ranges, and we
+ can build the range test, return it or it inverted. If one of the
+ ranges is always true or always false, consider it to be the same
+ expression as the other. */
+ if ((lhs == 0 || rhs == 0 || operand_equal_p (lhs, rhs, 0))
+ && merge_ranges (&in_p, &low, &high, in0_p, low0, high0,
+ in1_p, low1, high1)
+ && 0 != (tem = build_range_check (type,
+ lhs != 0 ? lhs
+ : rhs != 0 ? rhs : integer_zero_node,
+ in_p, low, high)))
+{
+ if (TREE_CODE (tem) != INTEGER_CST)
+ return;
+
+ warning_at (location, OPT_Wlogical_op,
+ or_op
+ ? "logical % of collectively exhaustive tests
is always true"
+ : "logical % of mutually exclusive tests is
always false");
}
}
Fwd: gcc instruction scheduling makes things worse?
Hi,all,
I have recently porting the instruction scheduler to the new arch of
our lab. But something seems strange.
Our pipeline( single issue) will stall for 1 cycle if the
arithmetic/logic instruction follows by a load, and for 2 cycles if a
store/jump/call instruction follows. I wrote my scheduler as follows:
(define_insn_reservation "apc_genetic_insn" 1
(eq_attr "type" "!load,mul")
"nothing")
(define_insn_reservation "apc_load_insn" 2
(eq_attr "type" "load")
"nothing")
(define_insn_reservation "apc_mul_insn" 4
(eq_attr "type" "mul")
"nothing")
The multiply operation is implemented by 4 arithmetic instruction, so
I made the latency 4 cycles. As our pipeline introduces no interlock,
so the reservations for all insns are "nothing", which is very similar
as XTENSA. For data dependency cases, I do some jobs in the
adjust_cost target hook.
static int
target_adjust_cost (rtx insn, rtx link, rtx dep, int cost)
{
..
switch (get_attr_type(insn) ){
case TYPE_ARITH_LOGIC:
if (REG_NOTE_KIND (link) == 0 && get_attr_type (dep) == TYPE_LOAD)
return 2;
break;
case TYPE_JUMP_CALL_STORE:
if (REG_NOTE_KIND (link) == 0 && get_attr_type (dep) == TYPE_LOAD)
return 3;
break;
..
}
return 1;
}
When I finished the scheduler, I got a strange phenomenon:
The CPI is reduced, but the total execution cycles are dramatically increased.
I read THE GNU INSTRUCTION SCHEDULER written by Michael D. Tiemann,
which mentioned a similar situation in sparc arch( chapter 7 extension
and future work), This article infromed me that register pressure is a
really big problem during instruction scheduling. I know I must ignore
something critical, but I don't know what it is. Is anyone there
helping me? Thank in advance.
Xiao
Re: -combine option for C++ sources
Pramod Joisha writes: > Presently, the -combine option works only for C sources. I was > wondering whether there are technical reasons for not supporting it > for C++ sources. If not, are there plans for providing this support in > the near future? As a historical note, Geoff Keating, who implemented -combine for C, was working on -combine for C++ when his employer, Apple, decided to halt contributions to gcc. I don't know how far he got or whether he would be able to share his patches. Ian
Re: Using MPC Library with GCC
On Tue, 28 Apr 2009, Kaveh R. Ghazi wrote: > From: "Mark Mitchell" > > > That is not a decision, however, on whether using MPC is or is not a > > good idea. There have been objections raised to MPC, on the grounds > > that it may not build on all host systems, or that the costs it brings > > in terms of complexity of building GCC outweigh its benefits. We should > > reach consensus on those issues before making a decision about whether > > to depend upon it. > > Thanks Mark. Although I personally felt that the GPLv3-compatible license > terms were sufficient from a legal and policy perspective, it's good to > clarify this officially for future circumstances as well as retroactively > for the libraries we already depend on. Also I agree that the remainder of > the discussion (i.e. whether it's a "good idea" in this particular case) > should be conducted in the public forum and that's what I asked for in my > proposal to the SC. > > So to address the remaining concerns, ... I didn't hear back from anyone opposing (or supporting!) MPC. Does that mean it's no longer controversial? Hopefully I've addressed the outstanding issues raised. http://gcc.gnu.org/ml/gcc/2009-04/msg00741.html --Kaveh
Re: Slush: Bug-Fixes Only for Middle End and Primary Platforms
Mark Mitchell wrote: > We're in Stage 1, and in Stage 1 big changes happen -- and then there is > naturally some instability. We clearly have some instability at > present, so we need to slow down until that's resolved. It looks like we have successfully resolved many of the problems. I still see a bootstrapping PR (PR39929), but it's unclear to me whether there are still problems there or not. Given the progress, the slush is over. However, Paolo Bonzini has announced the intention to merge the cond-optab branch on Friday. Therefore, until that is done, please do not make any major check-ins (e.g., branch merges). Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Trunk freeze next Friday morning GMT for cond-optab merge
Paolo Bonzini wrote: > Hi all, I plan to merge the cond-optab branch next Friday morning > European time. No commit should be made to trunk from Friday 6:00 AM > GMT to 12:00 AM GMT (or probably earlier). Paolo, I've asked that there be no "major" check-ins between now and then in order to give you the best possible chance at getting this done on Friday, as you've requested. Good luck! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux
Matthias Klose wrote:
> Paolo Carlini schrieb:
>
>> Paolo Carlini wrote:
>>
>>> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
>>> case conservative to have a link type test identical to the one used in
>>> libgomp and libgfortran and a fall back to the .s file (as currently used).
>>>
>>>
>> I committed the below to mainline. Assuming no issues are noticed with
>> it, I mean to apply it to 4_4-branch too in a few days.
>>
> with this patch applied to the 4.4 branch, the tests now succeed as expected
> on
> the 4_4-branch on {armeabi,hppa,sparc}-linux.
>
Good. I have now backported the patch to 4_4-branch too. Please double
check that the regression tests are also fine, thanks in advance.
Paolo.
GCC 4.5.0 Status Report (2009-05-05)
Status == The trunk is in Stage 1. As previously stated, we expect that Stage 1 will last through at least July. Clearly, we have had a significant jump in P1 issues due to the major changes made to the compiler middle-end. Let's drive that number down -- otherwise it will be hard for other people to get their improvements contributed. The slush that I requested last week has been lifted. However, I have asked for relative calm until the cond-optab branch has been merged to mainline, which will hopefully occur on Friday, May 8th. Quality Data Priority # Change from Last Report --- --- P1 16 + 16 P2 83 + 10 P31 - 14 --- --- Total 100 + 12 Previous Report === http://gcc.gnu.org/ml/gcc/2009-04/msg00565.html The next report for 4.4.0 will be sent by Richard. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using MPC Library with GCC
Kaveh R. GHAZI wrote: > I didn't hear back from anyone opposing (or supporting!) MPC. Does that > mean it's no longer controversial? Hopefully I've addressed the > outstanding issues raised. > > http://gcc.gnu.org/ml/gcc/2009-04/msg00741.html I personally think relying on MPC is a reasonable choice, given the fact that (as you say) the language specifications do in some cases require support for these kinds of manipulations of complex numbers at compile-time. In the past, however, other people have had objections. I'd like to give them more time (let's say one more week) to comment. If that week passes without negative comment, let's start coordinating how to move forward with it. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [Announcement] Creating lightweight IPO branch
Andi, On Tue, May 5, 2009 at 1:49 AM, Andi Kleen wrote: > Xinliang David Li writes: >> >> If the idea is generally accepted, I will prepare a series of patches >> and submit them to gcc trunk. > > I was reading your wiki page. Interesting idea. > > One aspect that wasn't clear to me on reading it was how different > compiler arguments for different files are handled. How would the > compiler compiling another source file know what special arguments > (like -I -D or special -f options) it needs? Or in what directory it > was compiled in for -I paths? Or do you assume that is always all the > same? This is actually mentioned in the document. Please see the section about the module info record format. In each module info, the information about -I paths, -D/-Us are recorded. Those will be passed to the preprocessor when each module is processed. > > The other thing that wasn't clear to me was the worst case > behaviour. If there's a single large file x.c that has a function that > is called from 100 other small files with hot call sites then x.c > would be compiled 100 times, right? x.c as an auxiliary module, is never fully compiled. It is fully parsed and after inlining, it is discarded (function DFEed). > Is there something to mitigate > such worst case behaviour? Yes, there are related options to throttle worst case behavior. This problem will most likely exist in theory (very large cluster in dynamic call graph). For most of the applications I see, hot calls are limited intra module or small clusters. Thanks, David > > Thanks, > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only. >
Re: [Announcement] Creating lightweight IPO branch
On Tue, May 05, 2009 at 10:25:13AM -0700, Xinliang David Li wrote: > Andi, > > On Tue, May 5, 2009 at 1:49 AM, Andi Kleen wrote: > > Xinliang David Li writes: > >> > >> If the idea is generally accepted, I will prepare a series of patches > >> and submit them to gcc trunk. > > > > I was reading your wiki page. Interesting idea. > > > > One aspect that wasn't clear to me on reading it was how different > > compiler arguments for different files are handled. How would the > > compiler compiling another source file know what special arguments > > (like -I -D or special -f options) it needs? Or in what directory it > > was compiled in for -I paths? Or do you assume that is always all the > > same? > > This is actually mentioned in the document. Please see the section > about the module info record format. In each module info, the > information about -I paths, -D/-Us are recorded. Those will be passed > to the preprocessor when each module is processed. I found it after the post :/. But it seems to be only a small subset of options. How about -m or -f flags? -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [Announcement] Creating lightweight IPO branch
On Tue, May 5, 2009 at 2:47 AM, Richard Guenther wrote: > On Tue, May 5, 2009 at 7:00 AM, Xinliang David Li wrote: >> Hi, I am going to create a gcc branch for the functionality of >> lightweight IPO. The description of the project and current status can >> be found in http://gcc.gnu.org/wiki/LightweightIpo. Some highlights: >> >> 1) If you already use FDO in your build, you also get IPO almost for free; >> 2) It is an IPO solution practical to very large real world C++ >> applications; >> 3) Performance potential is very large (though I've seen case >> increased compiler freedom can lead to performance degradation due to >> over-optimization (inliner, unroller etc) -- but this is a different >> matter). >> >> If the idea is generally accepted, I will prepare a series of patches >> and submit them to gcc trunk. > > I was hoping that with LTO we can get rid of -combine, as its type/decl > merging is fragile in many cases. Does this somehow conflict with > LIPO? LIPO does not depend on existing type/decl merging functionality -- though it does leverage the parser driver code -- mainly extending the filescope push/pop thingy, so mostly there is no conflict. From what I understand is that you are merging TUs in the > frontend (like -combine) - did you consider merging TUs with the > LTO infrastructure, but in memory? In LIPO, TU merging does not happen in frontend (the document may sound a little confusing) -- the modules are parsed independently and merged/linked after parsing. Diego and I talked about the possibilty of using LTO to do this -- but that requires significant driver change. > > On the whole LIPO sounds indeed very interesting. Thanks, David > > Thanks, > Richard. >
Re: [Announcement] Creating lightweight IPO branch
On Tue, May 5, 2009 at 10:38 AM, Andi Kleen wrote: > On Tue, May 05, 2009 at 10:25:13AM -0700, Xinliang David Li wrote: >> Andi, >> >> On Tue, May 5, 2009 at 1:49 AM, Andi Kleen wrote: >> > Xinliang David Li writes: >> >> >> >> If the idea is generally accepted, I will prepare a series of patches >> >> and submit them to gcc trunk. >> > >> > I was reading your wiki page. Interesting idea. >> > >> > One aspect that wasn't clear to me on reading it was how different >> > compiler arguments for different files are handled. How would the >> > compiler compiling another source file know what special arguments >> > (like -I -D or special -f options) it needs? Or in what directory it >> > was compiled in for -I paths? Or do you assume that is always all the >> > same? >> >> This is actually mentioned in the document. Please see the section >> about the module info record format. In each module info, the >> information about -I paths, -D/-Us are recorded. Those will be passed >> to the preprocessor when each module is processed. > > I found it after the post :/. But it seems to be only a small subset of > options. How about -m or -f flags? Right -- general option handling is yet need to be done. For instance, we may not want to inline a function from a module with -fstrict-aliasing to another function from a module with -fno-strict-aliasing. This is a universal CMO problem. One simple way is to use option checksum to make sure imported module has the same option as the importing module. Thanks, David > > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only. >
gcc-4.4-20090505 is now available
Snapshot gcc-4.4-20090505 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090505/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 147140 You'll find: gcc-4.4-20090505.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090505.tar.bz2 C front end and core compiler gcc-ada-4.4-20090505.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090505.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090505.tar.bz2 C++ front end and runtime gcc-java-4.4-20090505.tar.bz2 Java front end and runtime gcc-objc-4.4-20090505.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090505.tar.bz2The GCC testsuite Diffs from 4.4-20090428 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: Fwd: gcc instruction scheduling makes things worse?
He Xiao wrote: When I finished the scheduler, I got a strange phenomenon: The CPI is reduced, but the total execution cycles are dramatically increased. If this is a machine with a small number of registers, then try disabling the first instruction scheduling pass that runs before register allocation. This tends to increase register pressure so much that you end up with worse code than if you didn't schedule. There is a second scheduling pass after register allocation that will still run. See for instance the flag_schedule_insns code in config/i386/i386.c in the function optimization_options. Try debugging the scheduler to make sure it is doing what it should be doing. If you use options like -fsched-verbose=9 -fdump-rtl-sched2 then you will get an output file that contains info about the scheduling choices that were made for the second scheduling pass. This file contains estimated issue cycles for all of the instructions that were scheduled. You can try writing small testcases to verify that you get the result you expect for specific cases. The output will look like this ;; Ready list (t = 6):9 ;;6--> 9 dx=ax*0x4+ax :decodern,p0 where 6 is the issue cycle, and 9 is the insn uid, and then the next part shows what this instruction is doing (this is an x86 lea). Jim
GCC 4.4.1 Status Report (2009-05-05)
Status == GCC 4.4.0 was released into the wild approximately two weeks ago, and so far few serious defects have been reported. That's great! There are, however, a copule of open P1s and a bevy of P2s -- most of which also apply to 4.5. So, there are good opportunities to help both 4.4 and 4.5. The 4.4 branch is open under the usual release branch rules. We are aiming for a 4.4.1 release around June 21st. Quality Data Priority # Change from Last Report --- --- P12 + 2 P2 80 + 5 P30 - 9 --- --- Total82 - 2 Previous Report === http://gcc.gnu.org/ml/gcc/2009-04/msg00564.html The next report for 4.4.0 will be sent by Richard. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
opaque vector types?
Is there an opaque vector type? Something that can be assigned to/from other vector types of the same size, without warning? I'm working on a coprocessor which has separate SIMD arithmetic operations for each data size, but only one SIMD logical operation for all sizes. I.e. there's four ADD insns (V8QI, V4HI, etc) , but only one AND insn. I'd like to use an opaque vector type for the AND builtin, to avoid warnings.
Re: opaque vector types?
On Tue, May 5, 2009 at 11:04 PM, DJ Delorie wrote: > I'm working on a coprocessor which has separate SIMD arithmetic > operations for each data size, but only one SIMD logical operation for > all sizes. I.e. there's four ADD insns (V8QI, V4HI, etc) , but only > one AND insn. I'd like to use an opaque vector type for the AND > builtin, to avoid warnings. You could do what the rs6000 back-end does for the altivec builtins and resolve them while the parser is run (the SPU back-end does the same thing too). Yes there are opaque vector types, you just use build_opaque_vector_type instead of build_vector_type. -- Pinski
Re: opaque vector types?
Andrew Pinski writes: > You could do what the rs6000 back-end does for the altivec builtins > and resolve them while the parser is run (the SPU back-end does the > same thing too). Yes there are opaque vector types, you just use > build_opaque_vector_type instead of build_vector_type. Thanks, I'll look at those. Any way to prototype such functions in C ?
