Re: bug in lra causes incorrect register usage / compiler crash
On 04/29/14 14:16, Paul Shortis wrote: I've now confirmed this same issue occurs on a stock i386 build when -fomit-frame-pointer is specified with -O2 and a test case with reasonable register pressure. Please file a report with a compilable testcase. This is important both for the reviewer so that they can dive deeper into the issue if they feel the need and so that we can add a suitable regression test into the testsuite. Thanks, Jeff
Re: [PATCH][RFC] Always require a 64bit HWI
On Tue, 29 Apr 2014, Jeff Law wrote: > On 04/29/14 05:21, Richard Biener wrote: > > > > The following patch forces the availability of a 64bit HWI > > (without applying the cleanups that result from this). I propose > > this exact patch for a short time to get those that are affected > > and do not want to be affected scream. > > > > But honestly I don't see any important host architecture that > > not already requires a 64bit HWI. > > > > Another concern is that the host compiler may not provide a > > 64bit type. I'm not sure that this is an issue nowadays > > (even though C++98 doesn't have 'long long', so it's maybe > > more an issue now with C++ than it was previously with > > requiring C89). But given that it wasn't an issue for > > the existing 64bit HWI requiring host archs it shouldn't > > be an issue now. > > > > The benefit of this change is obviously the cleanup that > > can result from it - especially getting rid of code > > generation dependences on the host (!need_64bit_hwi > > doesn't mean we force a 32bit hwi). As followup > > we can replace HOST_WIDE_INT and its friends with > > int64_t variants and appear less confusing to > > newcomers (and it's also less characters to type! yay!). > > > > We'd still retain HOST_WIDEST_FAST_INT, and as Kenny > > said elsewhere wide-int should internally operate on that, > > not on the eventually slow int64_t. But that's a separate > > issue. > > > > So - any objections? > > > > Thanks, > > Richard. > > > > 2014-04-29 Richard Biener > > > > libcpp/ > > * configure.ac: Always set need_64bit_hwint to yes. > > * configure: Regenerated. > > > > * config.gcc: Always set need_64bit_hwint to yes. > No objections. The requirement for 64 bit HWINT traces its origins back to > the MIPS R5900 target IIRC. It's probably well past the time when we should > just bite the bullet and make HWINT 64 bits across the board. > > If the host compiler doesn't support 64-bit HWINT, then it seems to me the > host compiler can be used to bootstrap 4.9, which can then be used to > bootstrap more modern GCCs. > > And like you I suspect it's really not going to be an issue in practice. I realized I forgot to copy gcc-patches, so done now (patch copied below again for reference). I propose to apply the patch after the wide-int merge for a short period of time and then followup with a patch to remove the need_64bit_hwint code (I'll make sure to send that out for review before applying this one). Testing coverage for non-64bit hwi configs is really low these days (I know of only 32bit hppa-*-* that is still built and tested semi-regularly - Dave, I suppose the host compiler has a 64bit long long type there, right?). Thanks, Richard. 2014-04-29 Richard Biener libcpp/ * configure.ac: Always set need_64bit_hwint to yes. * configure: Regenerated. * config.gcc: Always set need_64bit_hwint to yes. Index: libcpp/configure.ac === --- libcpp/configure.ac (revision 209890) +++ libcpp/configure.ac (working copy) @@ -200,7 +200,7 @@ case $target in tilegx*-*-* | tilepro*-*-* ) need_64bit_hwint=yes ;; *) - need_64bit_hwint=no ;; + need_64bit_hwint=yes ;; esac case $need_64bit_hwint:$ac_cv_sizeof_long in Index: gcc/config.gcc === --- gcc/config.gcc (revision 209890) +++ gcc/config.gcc (working copy) @@ -233,7 +233,7 @@ gnu_ld="$gnu_ld_flag" default_use_cxa_atexit=no default_gnu_indirect_function=no target_gtfiles= -need_64bit_hwint= +need_64bit_hwint=yes need_64bit_isa= native_system_header_dir=/usr/include target_type_format_char='@'
Re: Integration of ISL code generator into Graphite
Hi Roman, Congratulations. Advices: 1) it is thought that there is a correlation between the time spent for designing of code and the time need for debugging it - poor design could dramatically increase the debugging time. So don't rush to have some pieces of code running - it is very important to have before a clear picture of how these different pieces of code will fit together. 2) reuse code as much as possible - one source is of course Graphite - another source may be the PPCG compiler that uses isl AST to generate C/CUDA/OpenCL code. It is a source to source compiler, but still there are a lot of things that show you how to work with isl ast and may considerably help you. Mircea - Original Message - > From: "Roman Gareev" > To: "Mircea Namolaru" , "Tobias Grosser" > > Cc: "Albert Cohen" , gcc@gcc.gnu.org > Sent: Sunday, April 27, 2014 9:49:01 PM > Subject: Re: Integration of ISL code generator into Graphite > > Hi Mircea. > > Sorry, I've been missing for a while. Thank you for your ideas! I > agree that reusing of the existing code (especially code using > tree-SSA related information) is important for this project. I'm > considering the current code in graphite_clast_to_gimple.c, and want > to ask a few questions about it. I'll send them in a new message. > > > – > > > Cheers, Roman Gareev >
LTO + conditional jump + delay slot
Hi,
I encountered a problem on test 'gcc.c-torture/execute/loop-7.c' (gcc4.7.3) on
my private port during test case "-O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects"
Here is the tested code :
void foo (unsigned int n)
{
int i, j = -1;
for (i = 0; i < 10 && j < 0; i++)
{
if ((1UL << i) == n)
j = i;
}
if (j < 0)
abort ();
}
main()
{
foo (64);
exit (0);
}
The LTO option merge the foo function into the main function.
I'll try present my problem by simplifying the resulting assembler.
:
:L1
[...] << content of the loop
compare 0, $R0 << test to know if the loop goes on or stop
($R0 synthetize the whole loop end condition)
jump_delayed.ifNE L1 << conditional delayed jump : the loop end if $R0
== 0
nop #delayslot1
sll $R1, 1, $R0 #delayslot2 << instruction which is part of the loop content
but placed into the 2nd delay slot of jump_delayed.ifNE instruction
compare -1, $R2 << test if (j < 0)
branch.ifeq abort<< conditional branch to abort
branch exit << branch to exit which expect a 0 into
$R0 as first parameter
The test fail, not because abort is called, but because exit is called with $R0
containing 0x80 and not 0.
I think GCC expect $R0 to be equal to 0 when the loop end (so no need to set
explicitly $R0 to 0)
But in this case the 'sll' instruction placed into the delay slot of the
conditional delayed jump modify $R0 even if no jump is performed.
Is it a bug due to LTO merging the 'foo' and 'main' function ?
Or does GCC really thinks that the instructions placed into the delay slot of
conditional jump are executed only if the condition is true ?
Or is it simply a GCC incompatibility between 'conditional jump' & 'delay
slots' ?
Here are some parts of my backend relative to delay slot and conditional jump
(nothing formidable :) ):
(define_delay (ior (eq_attr "type" "jump") (eq_attr "type" "cond_jump"))
[(and (eq_attr "delayable" "yes") (eq_attr "length" "1")) (nil) (nil)
(and (eq_attr "delayable" "yes") (eq_attr "length" "1")) (nil) (nil)])
(define_insn "jumpif"
[(set (pc)
(if_then_else (match_operator 0 "comparison_operator"
[(match_operand 2 "cc_register" "") (const_int 0)])
(label_ref (match_operand 1 "" ""))
(pc)))]
""
{ [...] // use final_sequence to detect delay slot }
[set_attr "type" "cond_jump")
(set_attr "delayable" "no")]
Regards,
Selim
Re: LTO + conditional jump + delay slot
On Wed, Apr 30, 2014 at 1:03 PM, BELBACHIR Selim
wrote:
> Hi,
>
> I encountered a problem on test 'gcc.c-torture/execute/loop-7.c' (gcc4.7.3)
> on my private port during test case "-O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects"
>
> Here is the tested code :
>
> void foo (unsigned int n)
Try making this function static, that might reproduce the issue without
LTO (eventually add -fno-early-inlining). -fwhole-program without -flto
should also reproduce it.
> {
> int i, j = -1;
>
> for (i = 0; i < 10 && j < 0; i++)
> {
> if ((1UL << i) == n)
> j = i;
> }
>
> if (j < 0)
> abort ();
> }
>
> main()
> {
> foo (64);
> exit (0);
> }
>
>
> The LTO option merge the foo function into the main function.
>
> I'll try present my problem by simplifying the resulting assembler.
>
> :
> :L1
> [...] << content of the loop
> compare 0, $R0 << test to know if the loop goes on or stop
> ($R0 synthetize the whole loop end condition)
> jump_delayed.ifNE L1 << conditional delayed jump : the loop end if
> $R0 == 0
> nop #delayslot1
> sll $R1, 1, $R0 #delayslot2 << instruction which is part of the loop content
> but placed into the 2nd delay slot of jump_delayed.ifNE instruction
> compare -1, $R2 << test if (j < 0)
> branch.ifeq abort<< conditional branch to abort
> branch exit << branch to exit which expect a 0 into
> $R0 as first parameter
>
> The test fail, not because abort is called, but because exit is called with
> $R0 containing 0x80 and not 0.
> I think GCC expect $R0 to be equal to 0 when the loop end (so no need to set
> explicitly $R0 to 0)
> But in this case the 'sll' instruction placed into the delay slot of the
> conditional delayed jump modify $R0 even if no jump is performed.
>
> Is it a bug due to LTO merging the 'foo' and 'main' function ?
>
> Or does GCC really thinks that the instructions placed into the delay slot of
> conditional jump are executed only if the condition is true ?
>
> Or is it simply a GCC incompatibility between 'conditional jump' & 'delay
> slots' ?
the delay-slot code is fragile, you probably simply run into a bug.
Richard.
>
>
> Here are some parts of my backend relative to delay slot and conditional jump
> (nothing formidable :) ):
>
> (define_delay (ior (eq_attr "type" "jump") (eq_attr "type" "cond_jump"))
> [(and (eq_attr "delayable" "yes") (eq_attr "length" "1")) (nil) (nil)
>(and (eq_attr "delayable" "yes") (eq_attr "length" "1")) (nil) (nil)])
>
> (define_insn "jumpif"
> [(set (pc)
> (if_then_else (match_operator 0 "comparison_operator"
> [(match_operand 2 "cc_register" "") (const_int 0)])
> (label_ref (match_operand 1 "" ""))
> (pc)))]
> ""
> { [...] // use final_sequence to detect delay slot }
> [set_attr "type" "cond_jump")
>(set_attr "delayable" "no")]
>
>
> Regards,
>
> Selim
>
>
>
>
>
Re: LTO + conditional jump + delay slot
On 30 April 2014 12:20, Richard Biener wrote: > the delay-slot code is fragile, you probably simply run into a bug. In particular, we lack in-tree ports with multiple delay slots, so while the support exists theoretically, it is not tested and maintained in any meaningful way.
Re: How can I generate a new function at compile time?
Thank you for the hint. I managed to extract the basic blocks to a helper function and put a call to this helper function at the place of the removed basic blocks in the original function. All this is done with help of move_sese_region_to_fn. The helper function is created similar to create_omp_child_function. I had a successful compilation run when I moved the pass just after pass_build_cgraph_edges. The problems I am still facing is with passing of parameters. I imagine that variables used in the helper function which are defined in the original function should become in-out parameters to the helper function. For that I wanted to use DECL_ARGUMENTS and the arguments to gimple_build_call or gimple_build_call_vec. However, how do I find the undefined variables in the helper function and how do I find out to which variables in the original function they belong. In particular, how do I get the names and order in the argument list right? Do you know of some equally useful examples? To me it seems that what is done in omp-low.c (expand_omp_taskreg or expand_omp_target) is not exactly what I need. Thank you again and best regards, Benedikt
Re: How can I generate a new function at compile time?
On Wed, Apr 30, 2014 at 2:16 PM, Benedikt Huber wrote: > Thank you for the hint. I managed to extract the basic blocks to a helper > function and put > a call to this helper function at the place of the removed basic blocks in > the original function. > All this is done with help of move_sese_region_to_fn. > The helper function is created similar to create_omp_child_function. > I had a successful compilation run when I moved the pass just after > pass_build_cgraph_edges. > > The problems I am still facing is with passing of parameters. > I imagine that variables used in the helper function which are defined in the > original function > should become in-out parameters to the helper function. > For that I wanted to use DECL_ARGUMENTS and the arguments to > gimple_build_call or gimple_build_call_vec. > However, how do I find the undefined variables in the helper function and how > do I find out to > which variables in the original function they belong. In particular, how do I > get the names and order > in the argument list right? > Do you know of some equally useful examples? > To me it seems that what is done in omp-low.c (expand_omp_taskreg or > expand_omp_target) is not > exactly what I need. But it's very similar. Other than you need to figure out what variables are used in the region yourself. The autopar code (tree-parloops.c) may have more what you have in mind (though the code is very old and I consider it ugly as hell). It also uses the omp lowering infrastructure to do the actual outlining. Richard. > Thank you again and best regards, > Benedikt
aarch64 ada rpms
On 04/30/2014 12:57 AM, Matthias Klose wrote: > Am 16.04.2014 09:02, schrieb r...@redhat.com: >> I'll see about puting some rpms somewhere public so that no one else >> has to do the whole canadian-cross compile dance. > > are these already online? a tarball would be fine too. And is there a > backport > for 4.9 too? Thanks for the reminder. I've now pushed rpms to http://people.redhat.com/~rth/ That's a 4.9 backport of the changes now on mainline, on top of the current fedora rawhide package. The srpm of course contains the backport patch. r~
Re: [PATCH][RFC] Always require a 64bit HWI
On 04/30/14 02:16, Richard Biener wrote: On Tue, 29 Apr 2014, Jeff Law wrote: On 04/29/14 05:21, Richard Biener wrote: The following patch forces the availability of a 64bit HWI (without applying the cleanups that result from this). I propose this exact patch for a short time to get those that are affected and do not want to be affected scream. But honestly I don't see any important host architecture that not already requires a 64bit HWI. Another concern is that the host compiler may not provide a 64bit type. I'm not sure that this is an issue nowadays (even though C++98 doesn't have 'long long', so it's maybe more an issue now with C++ than it was previously with requiring C89). But given that it wasn't an issue for the existing 64bit HWI requiring host archs it shouldn't be an issue now. The benefit of this change is obviously the cleanup that can result from it - especially getting rid of code generation dependences on the host (!need_64bit_hwi doesn't mean we force a 32bit hwi). As followup we can replace HOST_WIDE_INT and its friends with int64_t variants and appear less confusing to newcomers (and it's also less characters to type! yay!). We'd still retain HOST_WIDEST_FAST_INT, and as Kenny said elsewhere wide-int should internally operate on that, not on the eventually slow int64_t. But that's a separate issue. So - any objections? Thanks, Richard. 2014-04-29 Richard Biener libcpp/ * configure.ac: Always set need_64bit_hwint to yes. * configure: Regenerated. * config.gcc: Always set need_64bit_hwint to yes. No objections. The requirement for 64 bit HWINT traces its origins back to the MIPS R5900 target IIRC. It's probably well past the time when we should just bite the bullet and make HWINT 64 bits across the board. If the host compiler doesn't support 64-bit HWINT, then it seems to me the host compiler can be used to bootstrap 4.9, which can then be used to bootstrap more modern GCCs. And like you I suspect it's really not going to be an issue in practice. I realized I forgot to copy gcc-patches, so done now (patch copied below again for reference). I propose to apply the patch after the wide-int merge for a short period of time and then followup with a patch to remove the need_64bit_hwint code (I'll make sure to send that out for review before applying this one). Testing coverage for non-64bit hwi configs is really low these days (I know of only 32bit hppa-*-* that is still built and tested semi-regularly - Dave, I suppose the host compiler has a 64bit long long type there, right?). My recollection is that HP aCC supports long long, but I don't recall when support for that was introduced. I'm really trying hard to forget hpux-isms. Plus, they can always start the bootstrapping process with GCC 4.9. jeff
Re: [PATCH][RFC] Always require a 64bit HWI
On 4/30/2014 12:00 PM, Jeff Law wrote: My recollection is that HP aCC supports long long, but I don't recall when support for that was introduced. I'm really trying hard to forget hpux-isms. Plus, they can always start the bootstrapping process with GCC 4.9. I can't remember but without ansi support one needs to start with an early 4.X version. Dave -- John David Anglindave.ang...@bell.net
powerpc64le ada binaries
Ada binaries for powerpc64le-linux-gnu can be found at [1], these should be good for bootstrapping (or install gnat-4.8 in Ubuntu 14.04 LTS). Ada should then be buildable from the 4.9.0 release. Install the deb, or use ar(1) on the deb file to extract the files. Thanks to Ulrich Weigand helping a lot with the initial bootstrap. Matthias [1] https://launchpad.net/ubuntu/+source/gcc-snapshot/20140405-0ubuntu1
wide-int testing, go bits
I am seeing the below on wide-int. The go teststsuite violates one of the principals of goo test suite hygiene, the names thought arbitrary, should be stable. These names are not stable across differing build locations. s,.*/testsuite/,,g is approximately what it needs. Thanks. New tests that PASS: go.test/test/dwarf/dwarf.dir/main.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z1.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z10.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z11.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z12.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z13.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z14.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z15.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z16.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z17.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z18.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z19.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z2.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z20.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z3.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z4.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z5.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z6.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z7.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z8.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z9.go compilation, -O2 -g go.test/test/dwarf/dwarf.dir/main.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z1.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z10.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z11.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z12.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z13.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z14.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z15.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z16.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z17.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z18.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z19.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z2.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z20.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z3.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z4.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z5.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z6.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z7.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z8.go /home/mrs/wide/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z9.go execution, -O2 -g Old tests that passed, that have disappeared: (Eeek!) go.test/test/dwarf/dwarf.dir/main.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z1.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z10.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z11.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z12.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z13.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z14.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z15.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z16.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z17.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z18.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z19.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z2.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z20.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z3.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z4.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z5.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z6.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z7.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z8.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z9.go compilation, -O2 -g go.test/test/dwarf/dwarf.dir/main.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z1.go /home/mrs/wide-base/gcc/gcc/testsuite/go.test/test/dwarf/dwarf.dir/z10
implementation question
Hi, assuming the need to generate code in which almost everything is used 3x (e.g. 3x registers, 3 times data, etc.) for a specific purpose (*) for any given target, what would be the best way to implement it? (let's name this 3ple-voting behavior) a) as a forked backend target of each target (e.g. a 3ple-voting version of x86, a 3ple-voting version of ARM, etc.) b) as a late GIMPLE phase pluging? (*) The need comes from radiation bit-flipping tolerant software (the interested reader may check http://en.wikipedia.org/wiki/Single_event_upset). I am interested in SEUs affecting microprocessor registers and data. There is a voting technique in which the subjects under protection are triplicated, so on each operation, a check is performed whether the three are equal, or two are equal (in which case the third is fixed), or the three are distinct. Would a late GIMPLE phase plugin suffice? I think that I should manage to get the RTL tree with the necessary nodes triplicated and let the backend do its job, right? Or, am I forgetting any backend pass that may optimize/get screwed because of this? Thanks! Daniel.
Re: [Testsuite] getpid in gcc.c-torture/execute/pr58419.c
On 04/25/14 03:16, Dhakshinamoorthy, Soundararajan wrote: 2014-04-25 Soundararajan Dhakshinamoorthy * gcc.c-torture/execute/pr58419.c: Adjust the test to work with bare metal targets. The test code references to functions that is not implemented for the avr target (getpid()). THanks. I tweaked the ChangeLog slightly and installed your patch. Jeff
gcc-4.9-20140430 is now available
Snapshot gcc-4.9-20140430 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140430/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 209959 You'll find: gcc-4.9-20140430.tar.bz2 Complete GCC MD5=927ac2ac71b182c5f00cc34b66b6f08a SHA1=558e91e4a44901037512ebfbd937cd152013973d Diffs from 4.9-20140423 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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: [PATCH][RFC] Always require a 64bit HWI
On 30-Apr-14, at 4:16 AM, Richard Biener wrote: Testing coverage for non-64bit hwi configs is really low these days (I know of only 32bit hppa-*-* that is still built and tested semi-regularly - Dave, I suppose the host compiler has a 64bit long long type there, right?). I'm OK with this change as I know this causes support issues. The HP ansi C compiler and aCC have long long. This is not an issue for linux. I believe people can find HP-UX GCC binaries on the net. Dave -- John David Anglin dave.ang...@bell.net
Secondary platform change request
Since the original MinGW refuses to support 64-bit, I would like to discuss whether we should remove i686-mingw32 from the secondary platforms list and replace it with MinGW-w64.
