Using -save-temps and @file should also save the intermediate @file used by the driver?
Does anyone have some thoughts they'd like to share on this: "When you compile anything using @file support, the driver assumes @file (at_file_supplied is true) is allowed and may pass options to the linker via @file using a *temporary* file. When -save-temps is also used, the temporary @file passed to the linker should also be saved. Saving the temporary @file passed to the linker allows a developer to re-run just the collect2/ld command. On trunk this means that gcc/gcc.c (create_at_file) should honour the save_temps_flag, saving the temporary @file for later analysis or use." From: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44273
Re: Using -save-temps and @file should also save the intermediate @file used by the driver?
On Tue, May 10, 2011 at 10:28 AM, Ian Bolton wrote: > Does anyone have some thoughts they'd like to share on this: > > "When you compile anything using @file support, the driver assumes @file > (at_file_supplied is true) is allowed and may pass options to the linker via > @file using a *temporary* file. > > When -save-temps is also used, the temporary @file passed to the linker > should > also be saved. > > Saving the temporary @file passed to the linker allows a developer to re-run > just the collect2/ld command. > > On trunk this means that gcc/gcc.c (create_at_file) should honour the > save_temps_flag, saving the temporary @file for later analysis or use." For such driver bits you should specify -Wl,-debug which saves those files. Richard. > From: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44273 > > > > > >
Randomization in gcc generates different assembly file
Hi all, I am poring gcc 4.3.2 for a micro-controller and use it to compile C source code. I found that gcc is very sensitive to small changes in C source code even if the change doesn't affect any function of the source code. For example, a source file foo.c includes a header file foo.h. If one macro definition is added to foo.h and the macro is not used in foo.c. The assembly file foo.s is still changed and a few instructions swapped positions . I checked foo.c.129t.final_cleanup and found difference in it. I am wondering what caused the change in foo.o. Is there any randomization in gcc? How can I make the assembly file foo.s same no matter foo.h is changed or not? Thanks -Qifei Fan
Re: Randomization in gcc generates different assembly file
On Tue, May 10, 2011 at 12:08 PM, fanqifei wrote: > Hi all, > > I am poring gcc 4.3.2 for a micro-controller and use it to compile C > source code. > I found that gcc is very sensitive to small changes in C source code > even if the change doesn't affect any function of the source code. > For example, a source file foo.c includes a header file foo.h. > If one macro definition is added to foo.h and the macro is not used in > foo.c. The assembly file foo.s is still changed and a few instructions > swapped positions . > I checked foo.c.129t.final_cleanup and found difference in it. > > I am wondering what caused the change in foo.o. Is there any > randomization in gcc? > How can I make the assembly file foo.s same no matter foo.h is changed or not? alias analysis behavior depends on DECL_UIDs for partitioning which unfortunately shows this behavior in older releases (fixed as of GCC 4.5 at least). Richard. > Thanks > -Qifei Fan >
Re: Randomization in gcc generates different assembly file
On Tue, May 10, 2011 at 6:23 PM, Richard Guenther wrote: > On Tue, May 10, 2011 at 12:08 PM, fanqifei wrote: >> Hi all, >> >> I am poring gcc 4.3.2 for a micro-controller and use it to compile C >> source code. >> I found that gcc is very sensitive to small changes in C source code >> even if the change doesn't affect any function of the source code. >> For example, a source file foo.c includes a header file foo.h. >> If one macro definition is added to foo.h and the macro is not used in >> foo.c. The assembly file foo.s is still changed and a few instructions >> swapped positions . >> I checked foo.c.129t.final_cleanup and found difference in it. >> >> I am wondering what caused the change in foo.o. Is there any >> randomization in gcc? >> How can I make the assembly file foo.s same no matter foo.h is changed or >> not? > > alias analysis behavior depends on DECL_UIDs for partitioning which > unfortunately shows this behavior in older releases (fixed as of GCC 4.5 > at least). > > Richard. Which file or fucntion should I look into? Maybe I can work around in 4.3.2 What change in 4.5 fixed it? Thanks. -Qifei Fan
Re: Randomization in gcc generates different assembly file
On Tue, May 10, 2011 at 1:43 PM, fanqifei wrote: > On Tue, May 10, 2011 at 6:23 PM, Richard Guenther > wrote: >> On Tue, May 10, 2011 at 12:08 PM, fanqifei wrote: >>> Hi all, >>> >>> I am poring gcc 4.3.2 for a micro-controller and use it to compile C >>> source code. >>> I found that gcc is very sensitive to small changes in C source code >>> even if the change doesn't affect any function of the source code. >>> For example, a source file foo.c includes a header file foo.h. >>> If one macro definition is added to foo.h and the macro is not used in >>> foo.c. The assembly file foo.s is still changed and a few instructions >>> swapped positions . >>> I checked foo.c.129t.final_cleanup and found difference in it. >>> >>> I am wondering what caused the change in foo.o. Is there any >>> randomization in gcc? >>> How can I make the assembly file foo.s same no matter foo.h is changed or >>> not? >> >> alias analysis behavior depends on DECL_UIDs for partitioning which >> unfortunately shows this behavior in older releases (fixed as of GCC 4.5 >> at least). >> >> Richard. > Which file or fucntion should I look into? Maybe I can work around in 4.3.2 Look into tree-ssa-alias.c and tree-ssa-structalias.c > What change in 4.5 fixed it? A complete rewrite of the above ... Richard. > Thanks. > -Qifei Fan >
Re: What is the type of imm16 in builtin-func?
Liu writes:
> I write a pattern like this:
> (define_insn "extrv4di"
> [(set (match_operand:V4DI 0 "register_operand" "=Z")
> (unspec:V4DI
> [(match_operand:V4DI 1 "register_operand" "Z")
> (match_operand:SI 2 "immediate_operand" "")]
> UNSPEC_EXTR))]
> "TARGET_VECTORS"
> "extrd\t%0,%1,%2"
> [(set_attr "type" "vadd")])
>
> and the the code in mips.c:
> #define CODE_FOR_extrd CODE_FOR_extrv4di
> XX_BUILTIN (extrd, MIPS_V4DI_FTYPE_V4DI_INT),
>
> define a macro in mips.md:
>(UNSPEC_EXTR 821)
>
> the xx.h:
> __extension__ static __inline int64x4_t __attribute__ ((__always_inline__))
> extrd (int64x4_t s, const int i)
> {
> return __builtin_extrd (s, i);
> }
>
> When I write a testcase like:
> int64x4_t vec_vpextrd (int64x4_t s, const int t)
> {
> int64x4_t r;
> r = vpextrd (s, t);
> return r;
> }
>
> I get a error:
> /opt/cross-tools/bin/../lib/gcc/mips64el-unknown-linux-gnu/4.5.1/include/xx.h:1535:31:
> error: invalid argument to built-in function
>
> What should I do? What's the type of imm8/imm16 in builtin-func?
Not sure if you've already worked this out, but I think the problem
is that the "t" in vec_vpextrd is not a _known_ constant integer.
vec_vpextrd must either pass a specific integer itself or must
also be marked as always_inline (like vpextrd already is).
Richard
Re: Randomization in gcc generates different assembly file
>> Which file or fucntion should I look into? Maybe I can work around in 4.3.2 > > Look into tree-ssa-alias.c and tree-ssa-structalias.c > >> What change in 4.5 fixed it? > > A complete rewrite of the above ... > > Richard. So is there easy way to work around in 4.3.2 to disable the randomization? I am not familiar with tree ssa. Hope there is. :( -- -Qifei Fan
Re: I've successfully build 4.5.3 on Solaris x86
> uname -a : > SunOS devsolx86 5.10 Generic_139556-08 i86pc i386 i86pc Solaris > > config.guess output: > i386-pc-solaris2.10 > > gcc -v output: > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/export/usr_local/gcc4/bin/../libexec/gcc/i386-pc-solaris2.10/4.5.3/lto-wrapper > Target: i386-pc-solaris2.10 > Configured with: ../configure --with-gnu-as --with-as=/usr/sfw/bin/gas > --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-shared > --enable-languages=c,c++ --with-gmp=/usr/local --with-mpfr=/usr/local > --prefix=/usr/local/gcc4 > Thread model: posix > gcc version 4.5.3 (GCC) > > Only enabled C/C++ > > Had to install mpc-0.8.1 (newer one didn't compile). Â used gmp-5.0.2, > mpfr-3.0.1 > see http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00795.html New mpc compiles fine on Solaris 8 and 10 on Sparc v7, v8, v9 and on i386 and AMD64. I have not bothered with Intel i7 as I don't see it as any different from an x86_64 build on AMD Opterons. At least, the result is the same. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
basic bloc chaining: using dominance
Hello, I am working on a plugin at the GIMPLE state, I am parsing basic blocks and I need to check that a call to foo() is only present once in a function. Howerver, it can be present several times if it is in different basic blocks and only one is executed at execution time. I think the most convenient way is to use dominance relation between the basic blocks: I can warn in a basic block A calling the foo() function only if there is a block B calling foo and dominating A. In others cases, I cannot be sure that there is several calls to foo(). In the file gcc/dominance.c, there is a dominated_by_p function which allows to test dominance between 2 basic blocks and I would like to use it to solve this problem. I would like to have your opinion, does it looks the google solution to the problem or is there another way to do this? If this is a good solution, I will implement a primitive in MELT allowing to use dominated_by_p function in MELT. Thanks! Pierre Vittet My Google Summer Of Code projet: http://www.google-melange.com/gsoc/project/google/gsoc2011/piervit/15001
Re: Randomization in gcc generates different assembly file
fanqifei writes: >>> Which file or fucntion should I look into? Maybe I can work around in 4.3.2 >> >> Look into tree-ssa-alias.c and tree-ssa-structalias.c >> >>> What change in 4.5 fixed it? >> >> A complete rewrite of the above ... >> >> Richard. > So is there easy way to work around in 4.3.2 to disable the randomization? > I am not familiar with tree ssa. Hope there is. :( You could disable alias analysis via -fno-strict-aliasing. Of course that will affect optimization. I can't think of another easy way. Ian
Re: basic bloc chaining: using dominance
Pierre Vittet writes: > I am working on a plugin at the GIMPLE state, I am parsing basic > blocks and I need to check that a call to foo() is only present once > in a function. Howerver, it can be present several times if it is in > different basic blocks and only one is executed at execution time. > > I think the most convenient way is to use dominance relation between > the basic blocks: I can warn in a basic block A calling the foo() > function only if there is a block B calling foo and dominating A. In > others cases, I cannot be sure that there is several calls to foo(). > > In the file gcc/dominance.c, there is a dominated_by_p function which > allows to test dominance between 2 basic blocks and I would like to > use it to solve this problem. > > I would like to have your opinion, does it looks the google solution > to the problem or is there another way to do this? > > If this is a good solution, I will implement a primitive in MELT > allowing to use dominated_by_p function in MELT. Yes, dominated_by_p and friends are the right way to test for basic block dominance. Note that you have to build the graph first; see uses of calculate_dominance_info. Ian
Re: Randomization in gcc generates different assembly file
On Tue, May 10, 2011 at 4:20 PM, Ian Lance Taylor wrote: > fanqifei writes: > Which file or fucntion should I look into? Maybe I can work around in 4.3.2 >>> >>> Look into tree-ssa-alias.c and tree-ssa-structalias.c >>> What change in 4.5 fixed it? >>> >>> A complete rewrite of the above ... >>> >>> Richard. >> So is there easy way to work around in 4.3.2 to disable the randomization? >> I am not familiar with tree ssa. Hope there is. :( > > You could disable alias analysis via -fno-strict-aliasing. Of course > that will affect optimization. > > I can't think of another easy way. I think that won't help - we still do all the partitioning work thus the non-TBAA path will be affected. Richard. > Ian >
Debugging information in C macros
Hello all,
I was wondering if it is possible to improve the debugging information
generated by gcc when resolving C macros? Just as an example, when I
preprocessed the following C file:
extern int printf (__const char *__restrict __format, ...);
#define my_macro(i) \
do { \
*(i) = 1; \
*(i) += 2; \
} while(0)
int main(void)
{
int i = 0;
printf("i = %d\n", i);
my_macro(&i);
printf("i = %d\n", i);
return 0;
}
I got the following output:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
extern int printf (__const char *__restrict __format, ...);
int main(void)
{
int i = 0;
printf("i = %d\n", i);
do { *(&i) = 1; *(&i) += 2; } while(0);
printf("i = %d\n", i);
return 0;
}
By adding a couple of "#" lines as follows I was able to much improve
the debugging experience:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
extern int printf (__const char *__restrict __format, ...);
int main(void)
{
int i = 0;
printf("i = %d\n", i);
# 4 "test.c"
do {
# 5 "test.c"
*(&i) = 1;
# 6 "test.c"
*(&i) += 2;
# 7 "test.c"
} while(0);
# 14 "test.c"
printf("i = %d\n", i);
return 0;
}
I wonder whether this couldn't be done by the gcc preprocessor? Or does
standards compliance forbid this?
( [ http://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html ] didn't
quite make this clear, and it isn't clear to me whether those "#" lines
are part of the standard.)
Regards,
Michael
Re: Debugging information in C macros
On Tue, 10 May 2011 17:33:57 +0200
Michael T wrote:
> I was wondering if it is possible to improve the debugging information
> generated by gcc when resolving C macros? Just as an example, when I
> preprocessed the following C file:
>
> extern int printf (__const char *__restrict __format, ...);
>
> #define my_macro(i) \
> do { \
> *(i) = 1; \
> *(i) += 2; \
> } while(0)
>
I am not a standard guru, but in my naive view this counts as one
single logical line (because backslash newline is handled by
preprocessing), so expansion of that macro invocation should be one
line also.
Besides, I believe that there are lots of actual C code which depends
upon that behavior. Code like
#define my_fatal_at(Msg,Line) do { \
printf ("%s:%d fatal error: %s\n", __FILE__, Line, Msg); \
abort (); \
} while(0);
#define my_fatal(Msg) my_fatal_at(Msg,__LINE__)
My feeling is that with your proposal, the line number reported would
be wrong.
(I would image that both Linux Kernel's printk and Gtk g_assert might
behave similarily)
But maybe I didn't understood what you are proposing, or what the C
standards are saying. So I might be wrong.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
RE: Debugging information in C macros
> From: bas...@starynkevitch.net
> On Tue, 10 May 2011 17:33:57 +0200
> Michael T wrote:
> > I was wondering if it is possible to improve the debugging information
> > generated by gcc when resolving C macros? Just as an example, when I
> > preprocessed the following C file:
[...]
> I am not a standard guru, but in my naive view this counts as one
> single logical line (because backslash newline is handled by
> preprocessing), so expansion of that macro invocation should be one
> line also.
>
> Besides, I believe that there are lots of actual C code which depends
> upon that behavior. Code like
> #define my_fatal_at(Msg,Line) do { \
> printf ("%s:%d fatal error: %s\n", __FILE__, Line, Msg); \
> abort (); \
> } while(0);
[...]
Sadly that sounds rather convincing. Thanks for the answer and sorry for the
noise.
Regards,
Michael
RE: Debugging information in C macros
> From: rasel...@hotmail.com
> > From: bas...@starynkevitch.net
> > On Tue, 10 May 2011 17:33:57 +0200
> > Michael T wrote:
> > > I was wondering if it is possible to improve the debugging information
> > > generated by gcc when resolving C macros? Just as an example, when I
> > > preprocessed the following C file:
[...]
> > Besides, I believe that there are lots of actual C code which depends
> > upon that behavior. Code like
> > #define my_fatal_at(Msg,Line) do { \
> > printf ("%s:%d fatal error: %s\n", __FILE__, Line, Msg); \
> > abort (); \
> > } while(0);
[...]
> Sadly that sounds rather convincing. Thanks for the answer and sorry for the
> noise.
Although thinking about it, __FILE__ and __LINE__ are also handled by the
preprocessor, so they need not be affected by "#" lines. I'm sure there must be
a reason though why gcc isn't doing this already.
Regards,
Michael
Re: Debugging information in C macros
> "Michael" == Michael T writes: Michael> I was wondering if it is possible to improve the debugging Michael> information generated by gcc when resolving C macros? It could be done, but nobody has tried. Michael> I wonder whether this couldn't be done by the gcc preprocessor? Michael> Or does standards compliance forbid this? A DWARF extension might be needed, but that is not a big deal. The bulk of the work will be defining exactly what you want in various cases, and then of course the implementation in GCC. It isn't clear to me that you always want to emit this information. E.g., there are some hairy macros in libc that, presumably, only libc developers would ever want to step through. Look for a 6 part series from Dodji Seketeli in December 2010 for some work that would be a good starting point for this. The first message is titled "[PATCH 0/6] Tracking locations of tokens resulting from macro expansion". This series changes GCC to more accurately track source locations through macro expansion. Tom
Re: IRA improvement patch
On 05/06/2011 10:21 AM, Hari Sandanagobalane wrote:
Hi Vlad,
I found a problem with your IRA improvement checkin r171649 on
29-3-2011. I can't get picochip port to build with this change. The
problem is in the function "clarify_prohibited_class_mode_regs" in
ira.c:1413. The code reproduced here is
/* Clarify IRA_PROHIBITED_CLASS_MODE_REGS by excluding hard registers
spanning from one register pressure class to another one. It is
called after defining the pressure classes. */
static void
clarify_prohibited_class_mode_regs (void)
{
int j, k, hard_regno, cl, pclass, nregs;
for (cl = (int) N_REG_CLASSES - 1; cl >= 0; cl--)
for (j = 0; j < NUM_MACHINE_MODES; j++)
for (k = ira_class_hard_regs_num[cl] - 1; k >= 0; k--)
{
hard_regno = ira_class_hard_regs[cl][k];
if (TEST_HARD_REG_BIT
(ira_prohibited_class_mode_regs[cl][j], hard_regno))
continue;
nregs = hard_regno_nregs[hard_regno][j];
pclass = ira_pressure_class_translate[REGNO_REG_CLASS
(hard_regno)];
for (nregs-- ;nregs >= 0; nregs--)
if (((enum reg_class) pclass
!= ira_pressure_class_translate[REGNO_REG_CLASS
(hard_regno + nregs)]))
{
SET_HARD_REG_BIT (ira_prohibited_class_mode_regs[cl][j],
hard_regno);
break;
}
}
}
I do not understand the functionality of the code, but i get a
segfault in the line
if (((enum reg_class) pclass
!= ira_pressure_class_translate[REGNO_REG_CLASS
(hard_regno + nregs)]))
In the case where it segfaults, the hard_regno+nregs is greater than
FIRST_PSEUDO_REGISTER. It leads to access beyond the end of
REGNO_REG_CLASS array.
I realise that hard_regno_nregs happily gives you a value beyond the
FIRST_PSEUDO_REGISTER. I can change it so it wouldn't do that, if that
is the solution to this. Can you clarify?
Sorry for the delay with the answer, Hari. I was on vacation last week.
Thanks for pointing the problem. Usually ports have some virtual
registers after the real hard registers before the first pseudo-register
and this did not happen for other ports.
So your proposal is right one. You could add `hard_regno + nregs >=
FIRST_PSEUDO_REGISTER ||' at the start of if-condition and send the
patch for approval.
Vlad
Re: Debugging information in C macros
On Tue, 2011-05-10 at 17:33 +0200, Michael T wrote: > Hello all, > > I was wondering if it is possible to improve the debugging information > generated by gcc when resolving C macros? Just as an example, when I > preprocessed the following C file: > Have you tried '-g3'? R.
[google] Merged google/main -> google/gcc-4_6 rev 173605
This merge brings all the changes in google/main up to rev 173605. Validated on x86_64. Diego. Merged revisions 173258,173353,173395,173398,173411,173416,173499,173504,173526,173605 via svnmerge from svn+ssh://gcc.gnu.org/svn/gcc/branches/google/main r173258 | cgd | 2011-05-02 12:34:02 -0400 (Mon, 02 May 2011) | 5 lines 2011-05-02 Chris Demetriou * config/i386/i386.c (get_pc_thunk_name): Make 32-bit thunk prefix be __x86.get_pc_thunk. r173353 | davidxl | 2011-05-04 00:15:49 -0400 (Wed, 04 May 2011) | 1 line backport 173177,173147 etc from trunk r173395 | eraman | 2011-05-04 17:02:51 -0400 (Wed, 04 May 2011) | 23 lines 2011-05-04 Silvius Rus * doc/invoke.texi: Document -fprofile-generate-sampling option. * gcov-io.h (__gcov_set_sampling_rate): New declaration. * profile.c (branch_prob): Add support for sampled profile collection. * profile.h (add_sampling_to_edge_counters): New declaration. * common.opt (fprofile-generate-sampling): New option. * tree-profile: Include header files; define EDGE_COUNTER_STMT_COUNT. (instrumentation_to_be_sampled, gcov_sample_counter_decl) (gcov_sampling_rate_decl): New globals. (insert_if_then, add_sampling_wrapper, is_instrumentation_to_be_sampled) (add_sampling_to_edge_counters, gimple_init_instrumentation_sampling): New functions. (gimple_init_edge_profiler): Call gimple_init_instrumentation_sampling. (gimple_gen_edge_profiler): Mark start of instrumentation block. * libgcov.c (__gcov_sampling_rate): New extern declaration. (gcov_sampling_rate_initialized, __gcov_sample_counter): New globals. (gcov_exit): Set sampling rate; minor coding style fixes. (__gcov_init): Initialize __gcov_sampling_rate. * params.def (PARAM_PROFILE_GENERATE_SAMPLING_RATE): New parameter. r173398 | tmsriram | 2011-05-04 18:15:16 -0400 (Wed, 04 May 2011) | 46 lines 2011-05-04 Sriraman Tallam * tree-pass.h (pass_tree_convert_builtin_dispatch): New pass. (pass_ipa_multiversion_dispatch): New pass. * builtin-types.def (BT_PTR_FN_INT): New pointer type. (BT_FN_INT_PTR_FN_INT_PTR_PTR_VAR): New function type for __builtin_dispatch. * builtins.def (BUILT_IN_DISPATCH): New builtin to support multi-version calls. * mversn-dispatch.c: New file. * timevar.def (TV_MVERSN_DISPATCH): New time var. * common.opt (fclone-hot-version-paths): New flag. * Makefile.in (mversn-dispatch.o): New rule. * passes.c (init_optimization_passes): Add the new multi-version and dispatch passes to the pass list. * params.def (PARAM_NUMBER_OF_MVERSN_CLONES): Define. (PARAM_MVERSN_CLONE_CGRAPH_DEPTH): Define. * doc/invoke.texi (mversn-clone-depth): Document. (num-mversn-clones): Document. (fclone-hot-version-paths): Document. * c-family/c-common.c (handle_version_selector_attribute): New function. (c_common_attribute_table): New attribute "version_selector". * testsuite/gcc.dg/mversn7.c: New test. * testsuite/gcc.dg/mversn4.c: New test. * testsuite/gcc.dg/mversn4.h: New test. * testsuite/gcc.dg/mversn4a.c: New test. * testsuite/gcc.dg/torture/mversn1.c: New test. * testsuite/gcc.dg/mversn2.c: New test. * testsuite/gcc.dg/mversn6.c: New test. * testsuite/gcc.dg/mversn3.c: New test. * testsuite/g++.dg/mversn8.C: New test. * testsuite/g++.dg/mversn10a.C: New test. * testsuite/g++.dg/mversn14a.C: New test. * testsuite/g++.dg/tree-prof/mversn13.C: New test. * testsuite/g++.dg/tree-prof/mversn15.C: New test. * testsuite/g++.dg/tree-prof/mversn15a.C: New test. * testsuite/g++.dg/mversn9.C: New test. * testsuite/g++.dg/mversn10.C: New test. * testsuite/g++.dg/mversn12.C: New test. * testsuite/g++.dg/mversn14.C: New test. * testsuite/g++.dg/mversn16.C: New test. * testsuite/g++.dg/torture/mversn11.C: New test. * testsuite/g++.dg/torture/mversn5.C: New test. * testsuite/g++.dg/torture/mversn5.h: New test. * testsuite/g++.dg/torture/mversn5a.C: New test. r173411 | cgd | 2011-05-04 21:47:55 -0400 (Wed, 04 May 2011) | 14 lines 2011-05-04 Chris Demetriou Backport from trunk r173391: 2011-05-04 Chris Demetriou * config/i386/morestack.S (__i686.get_pc_thunk.bx): Rename to... (__x86.get_pc_thunk.bx): ...this. (__morestack): Adjust for rename, remove undef of __i686. Backport from trunk r173345: 2011-05-03 Chris Demetriou * config/i386/morestack.S (__i686.get_pc_thunk.bx): New. r173416 | davidxl | 2011-05-05 01:43:59 -0400 (Thu, 05 May 2011) | 1 line
gcc-4.4-20110510 is now available
Snapshot gcc-4.4-20110510 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110510/ 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 173635 You'll find: gcc-4.4-20110510.tar.bz2 Complete GCC (includes all of below) MD5=1c42348d4dee3771d167de8c0c9f4c02 SHA1=9ac578ff1e7a4641f83b00229c9216d81cef11a9 gcc-core-4.4-20110510.tar.bz2C front end and core compiler MD5=96e39fb240742920e0f1c1de25cb36e5 SHA1=41e459711e12d8d4254274d9866cde2353eeb885 gcc-ada-4.4-20110510.tar.bz2 Ada front end and runtime MD5=68db5e0745e407de6a2d3fc1a92beb77 SHA1=cd138e0db3a95b2eded564e1aacef05ed5e45846 gcc-fortran-4.4-20110510.tar.bz2 Fortran front end and runtime MD5=1cf1ebc89813af0a79cdbd49c2ba3cec SHA1=9b6ec439a15d7bd786c0fcf3aec15a2c2882141a gcc-g++-4.4-20110510.tar.bz2 C++ front end and runtime MD5=42a60aed2eaa2c8e0aa61c88387f4d08 SHA1=bd158906e63f868665c7d7658fe4bcfb9822d0e7 gcc-go-4.4-20110510.tar.bz2 Go front end and runtime MD5=d58fab212a188b144e13be80d100e27a SHA1=414d1c65c5489b143828012d69f5e8893fc1eca0 gcc-java-4.4-20110510.tar.bz2Java front end and runtime MD5=0cbbfd5c1a208aca2b9fc4b7fab71420 SHA1=49cd9d616990936d88c63916e3b3fe59ed0aa2ad gcc-objc-4.4-20110510.tar.bz2Objective-C front end and runtime MD5=29ea0496697815e3313b47d3f8c84a1e SHA1=77d65991db53225e30636df51f8f3d9f8b2fd845 gcc-testsuite-4.4-20110510.tar.bz2 The GCC testsuite MD5=af4b60732562ac790cd330c0a9841d52 SHA1=b487f7f72489735b714f8b6cf3ad13700c448bfd Diffs from 4.4-20110503 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.
[google] Merged gcc-4_6-branch into google/gcc-4_6
This merge brings every change in gcc-4_6-branch up to rev 173632. Validated on x86_64. Diego.
