libgo patch committed: Update to weekly.2012-02-07 release
I have patched libgo to the weekly.2012-02-07 release. As usual this message only contains changes to files specific to gccgo. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r 7b3bde10b118 libgo/MERGE --- a/libgo/MERGE Wed Feb 08 14:33:09 2012 -0800 +++ b/libgo/MERGE Thu Feb 09 00:00:42 2012 -0800 @@ -1,4 +1,4 @@ -1107a7d3cb07 +52ba9506bd99 The first line of this file holds the Mercurial revision number of the last merge done from the master library sources. diff -r 7b3bde10b118 libgo/Makefile.am --- a/libgo/Makefile.am Wed Feb 08 14:33:09 2012 -0800 +++ b/libgo/Makefile.am Thu Feb 09 00:00:42 2012 -0800 @@ -226,6 +226,7 @@ $(exp_inotify_gox) \ exp/norm.gox \ exp/proxy.gox \ + exp/signal.gox \ exp/terminal.gox \ exp/types.gox \ exp/utf8string.gox @@ -257,13 +258,11 @@ toolexeclibgoimagedir = $(toolexeclibgodir)/image toolexeclibgoimage_DATA = \ - image/bmp.gox \ image/color.gox \ image/draw.gox \ image/gif.gox \ image/jpeg.gox \ - image/png.gox \ - image/tiff.gox + image/png.gox toolexeclibgoindexdir = $(toolexeclibgodir)/index @@ -327,8 +326,7 @@ toolexeclibgoos_DATA = \ os/exec.gox \ - os/user.gox \ - os/signal.gox + os/user.gox toolexeclibgopathdir = $(toolexeclibgodir)/path @@ -949,7 +947,6 @@ go/crypto/cipher/cipher.go \ go/crypto/cipher/ctr.go \ go/crypto/cipher/io.go \ - go/crypto/cipher/ocfb.go \ go/crypto/cipher/ofb.go go_crypto_des_files = \ go/crypto/des/block.go \ @@ -1107,6 +1104,8 @@ go/exp/proxy/per_host.go \ go/exp/proxy/proxy.go \ go/exp/proxy/socks5.go +go_exp_signal_files = \ + go/exp/signal/signal.go go_exp_terminal_files = \ go/exp/terminal/terminal.go \ go/exp/terminal/util.go @@ -1179,9 +1178,6 @@ go/html/template/transition.go \ go/html/template/url.go -go_image_bmp_files = \ - go/image/bmp/reader.go - go_image_color_files = \ go/image/color/color.go \ go/image/color/ycbcr.go @@ -1203,12 +1199,6 @@ go/image/png/reader.go \ go/image/png/writer.go -go_image_tiff_files = \ - go/image/tiff/buffer.go \ - go/image/tiff/compress.go \ - go/image/tiff/consts.go \ - go/image/tiff/reader.go - go_index_suffixarray_files = \ go/index/suffixarray/qsufsort.go \ go/index/suffixarray/suffixarray.go @@ -1317,9 +1307,6 @@ go/os/user/user.go \ go/os/user/lookup_unix.go -go_os_signal_files = \ - go/os/signal/signal.go - go_path_filepath_files = \ go/path/filepath/match.go \ go/path/filepath/path.go \ @@ -1673,6 +1660,7 @@ exp/html.lo \ exp/norm.lo \ exp/proxy.lo \ + exp/signal.lo \ exp/terminal.lo \ exp/types.lo \ exp/utf8string.lo \ @@ -1693,13 +1681,11 @@ net/http/httptest.lo \ net/http/httputil.lo \ net/http/pprof.lo \ - image/bmp.lo \ image/color.lo \ image/draw.lo \ image/gif.lo \ image/jpeg.lo \ image/png.lo \ - image/tiff.lo \ index/suffixarray.lo \ io/ioutil.lo \ log/syslog.lo \ @@ -1720,7 +1706,6 @@ old/template.lo \ $(os_lib_inotify_lo) \ os/user.lo \ - os/signal.lo \ path/filepath.lo \ regexp/syntax.lo \ net/rpc/jsonrpc.lo \ @@ -2607,6 +2592,16 @@ @$(CHECK) .PHONY: exp/proxy/check +@go_include@ exp/signal.lo.dep +exp/signal.lo.dep: $(go_exp_signal_files) + $(BUILDDEPS) +exp/signal.lo: $(go_exp_signal_files) + $(BUILDPACKAGE) +exp/signal/check: $(CHECK_DEPS) + @$(MKDIR_P) exp/signal + @$(CHECK) +.PHONY: exp/signal/check + @go_include@ exp/terminal.lo.dep exp/terminal.lo.dep: $(go_exp_terminal_files) $(BUILDDEPS) @@ -2776,16 +2771,6 @@ @$(CHECK) .PHONY: hash/fnv/check -@go_include@ image/bmp.lo.dep -image/bmp.lo.dep: $(go_image_bmp_files) - $(BUILDDEPS) -image/bmp.lo: $(go_image_bmp_files) - $(BUILDPACKAGE) -image/bmp/check: $(CHECK_DEPS) - @$(MKDIR_P) image/bmp - @$(CHECK) -.PHONY: image/bmp/check - @go_include@ image/color.lo.dep image/color.lo.dep: $(go_image_color_files) $(BUILDDEPS) @@ -2836,16 +2821,6 @@ @$(CHECK) .PHONY: image/png/check -@go_include@ image/tiff.lo.dep -image/tiff.lo.dep: $(go_image_tiff_files) - $(BUILDDEPS) -image/tiff.lo: $(go_image_tiff_files) - $(BUILDPACKAGE) -image/tiff/check: $(CHECK_DEPS) - @$(MKDIR_P) image/tiff - @$(CHECK) -.PHONY: image/tiff/check - @go_include@ index/suffixarray.lo.dep index/suffixarray.lo.dep: $(go_index_suffixarray_files) $(BUILDDEPS) @@ -3088,16 +3063,6 @@ @$(CHECK) .PHONY: os/user/check -@go_include@ os/signal.lo.dep -os/signal.lo.dep: $(go_os_signal_files) - $(BUILDDEPS) -os/signal.lo: $(go_os_signal_files) - $(BUILDPACKAGE) -os/signal/check: $(CHECK_DEPS) - @$(MKDIR_P) os/signal - @$(CHECK) -.PHONY: os/signal/check - @go_include@ path/filepath.lo.dep path/filepath.lo.dep: $(go_path_filepath_files) $(BUILDDEPS) @@ -3412,6 +3377,8 @@ $(BUILDGOX) exp/proxy.gox: exp/proxy.lo $(BUILDGOX) +exp/signal.gox: exp/signal.lo + $(BUILDGOX) exp/terminal.gox: exp/terminal.lo $(BUILDGOX) exp/types.gox: exp/types.lo @@ -3446,8 +3413,6 @@ hash/fnv.gox: hash/fnv.lo $(BUILDGOX) -image/bmp.gox: image/bmp.lo - $(BU
Go patch committed: Testsuite driver tweaks
This patch to the Go testsuite driver does two things. 1) Disables
stack.go on systems which do not support -fsplit-stack. This test uses
a great deal of stack space and can overrun a thread stack. 2) Builds
select5-out.go without optimization. The test is a generated file that
takes a long time to compile, and already had special code to extend the
timeout on Alpha systems. Rathe than worry about timeouts, I just
disabled optimization. The test still runs quickly even when not
optimized.
With this patch I was able to build and run the Go testsuite with no
failures on x86 and x86_64 Solaris 10. (I tested before the libgo
update I just committed.)
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu and
i386-pc-solaris2.10. Committed to mainline.
Ian
2012-02-09 Ian Lance Taylor
* go.test/go-test.exp (go-gc-tests): Don't run stack.go on systems
which don't support -fsplit-stack. Turn off optimization when
compiling select5-out.go.
Index: go.test/go-test.exp
===
--- go.test/go-test.exp (revision 184034)
+++ go.test/go-test.exp (working copy)
@@ -330,8 +330,9 @@ proc go-gc-tests { } {
continue
}
- if { [file tail $test] == "select2.go" && \
- ! [check_effective_target_split_stack] } {
+ if { ( [file tail $test] == "select2.go" \
+ || [file tail $test] == "stack.go" ) \
+ && ! [check_effective_target_split_stack] } {
# chan/select2.go fails on targets without split stack,
# because they allocate a large stack segment that blows
# out the memory calculations.
@@ -1018,10 +1019,12 @@ proc go-gc-tests { } {
} else {
pass "$name execution"
file delete $base-out.x
- # This testcase takes long time to compile.
- dg-timeout-factor list 4 { target alpha*-*-* }
+ # Disable optimizations as this test takes a long time
+ # to compile.
+ set hold $TORTURE_OPTIONS
+ set TORTURE_OPTIONS [ list { -O0 -g }]
go-torture-execute "./$base-out.go"
- unset_timeout_vars
+ set TORTURE_OPTIONS $hold
}
file delete $base-out.go
}
Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE
Hi Patrick, On 9 Feb 2012, at 05:10, Patrick Marlier wrote: On 02/08/2012 12:12 AM, Jack Howarth wrote: I believe the remaining libitm.c++/eh-1.C execution test failures are due to the weakref linker bug currently in Xcode 4.x (radr://10466868) which I hae been told will be fixed in the next Xcode release after Xcode 4.3. Jack Humm... In fact, not completely. Of course, if the linker was working, the HAVE_ELF_STYLE_WEAKREF will be defined and no problem. Otherwise in the eh-1.c, we can see that _ITM_cxa_allocation_exception is using the dummy function __cxa_allocation_exception defined into eh_cpp.cc but not the one from libstdc++. There is no dynamic symbol resolution since the function is defined in the file. I do not really know why those functions are defined here, I think it may causes more problems than it solves for darwin. When Rainer introduced this, he mentioned "on Tru64 UNIX. Of course it cannot work to provide only a single dummy function, but all weak definitions must be backed by dummy definitions on that platform." http://patchwork.ozlabs.org/patch/126007/ Iain mentioned this when he introduced the dummy def for darwin: *** FWIW, weakref actually work (at runtime) for earlier Darwin Weak refs have been working a (long) time on Darwin @ runtime - don't remember what version they were introduced ... but maybe from almost/ actually the start. - it's just that refs either need to be satisfied by dummies at link time - We are dealing with tool bugs (or, at least, changes in behavior) - the Linker would not [intentionally, see below*] accept unsatisfied linkage for weak refs @ Darwin <= 9 (XCode 3.1.4) ... and then for the XCode 3.2.x tool-chain on Darwin 10 it does accept it (i.e. ELF- like semantics work). Then (an acknowledged bug) with the (current) XCode 4.x tool-chain on either D10 or D11 the linker is again not accepting. * The (original, Darwin version, weak ref) idea, as documented, is that weak refs are for optional features - so the developer @ link- time supplies the library reference (place where the reference would be found, if present - this tells dyld what the proper two-level name of the lib is, when present). Then, at runtime dyld should not barf if the reference is not present. This is a different approach from the ELF weak-ref where the reference does not need to be supplied @ link-time - although it seems that Darwin is shifting towards supporting both from D10 onwards. - or the library namespace has to be flattened (which is generally undesirable). this would be a (IMO very) Bad Idea because we'd be doing it for every exe that included libitm... bleah. The two-level lib namespace is one of Darwin's nicer features ;) I think refs (from libstdc++) should be satisfied at link time with - lstdc++ but probably I am missing something? when you link c++ code, that is what is required .. but obv. we don't want lstdc++ on the link line for c (because the library *will* be found @ runtime - and thus the routines would be called). I have an idea ... perhaps we supply (yet another) crt that is linked last on the line and provides the dummies. That way the linkage will be satisfied from libstd++ for c++ and the dummies for c. will try and see if I can fit a trial of that idea in on D9 & D10. Note that removing definitions in eh_cpp.cc make the test passes. but it will make the c tests fail for D9 and any version of Darwin on which elf-style weak refs is not currently working ... cheers Iain Thanks guys! -- Patrick.
Re: [Patch, fortran] PR50981 (elemental/optional interaction) follow-up fix
Dear Mikael, On 02/08/2012 12:25 AM, Mikael Morin wrote: Regression tested on x86_64-unknown-freebsd9.0. OK for trunk? OK and thanks for the patch! Tobias
Re: [PATCH] Fix sibcall argument overlap checking if pretend_args_size (PR target/52129)
Hi Richard and Jakub
Since 4.6 contains the same bug, I would like to back port it to 4.6
branch. Could you approve it for 4.6?
Jing and Doug
Could you approve it for google/gcc-4_6-mobile branch?
thanks
Carrot
On Mon, Feb 6, 2012 at 9:14 PM, Richard Guenther
wrote:
> On Mon, Feb 6, 2012 at 2:01 PM, Jakub Jelinek wrote:
>> Hi!
>>
>> The attached testcase is miscompiled on arm*, by doing a sibcall when setup
>> of one argument overwrites incoming arguments used to setup parameters in
>> later insns.
>> The reason why
>> mem_overlaps_already_clobbered_arg_p/check_sibcall_argument_overlap
>> fails to detect is that the caller has non-zero
>> crtl->args.pretend_args_size, and in that case the base:
>> /* The argument block when performing a sibling call is the
>> incoming argument block. */
>> if (pass == 0)
>> {
>> argblock = crtl->args.internal_arg_pointer;
>> argblock
>> #ifdef STACK_GROWS_DOWNWARD
>> = plus_constant (argblock, crtl->args.pretend_args_size);
>> #else
>> = plus_constant (argblock, -crtl->args.pretend_args_size);
>> #endif
>> stored_args_map = sbitmap_alloc (args_size.constant);
>> sbitmap_zero (stored_args_map);
>> }
>> apparently isn't virtual-incoming-rtx, but that plus pretend_args_size
>> (8 in this case). When we store bits into stored_args_map sbitmap,
>> we use arg->locate.slot_offset.constant based values (or something different
>> for ARGS_GROW_DOWNWARD, but when mem_overlaps_already_clobbered_arg_p is
>> testing those bits, it uses just virtual-incoming-rtx offsets (or something
>> different for ARGS_GROW_DOWNWARD). This patch fixes it by adjusting the
>> virtual-incoming-rtx relative offset to be actually argblock relative
>> offset.
>>
>> Bootstrapped/regtested on x86_64-linux and i686-linux and tested on the
>> testcase on arm cross. Ok for trunk?
>
> Ok.
>
> Thanks,
> Richard.
>
>> 2012-02-06 Jakub Jelinek
>>
>> PR target/52129
>> * calls.c (mem_overlaps_already_clobbered_arg_p): If val is
>> CONST_INT_P, subtract resp. add crtl->args.pretend_args_size to it.
>>
>> * gcc.c-torture/execute/pr52129.c: New test.
>>
>> --- gcc/calls.c.jj 2012-02-01 14:44:27.0 +0100
>> +++ gcc/calls.c 2012-02-06 10:19:12.112132905 +0100
>> @@ -1808,6 +1808,11 @@ mem_overlaps_already_clobbered_arg_p (rt
>> return true;
>> else
>> i = INTVAL (val);
>> +#ifdef STACK_GROWS_DOWNWARD
>> + i -= crtl->args.pretend_args_size;
>> +#else
>> + i += crtl->args.pretend_args_size;
>> +#endif
>>
>> #ifdef ARGS_GROW_DOWNWARD
>> i = -i - size;
>> --- gcc/testsuite/gcc.c-torture/execute/pr52129.c.jj 2012-02-06
>> 10:27:50.988876791 +0100
>> +++ gcc/testsuite/gcc.c-torture/execute/pr52129.c 2012-02-06
>> 10:25:26.0 +0100
>> @@ -0,0 +1,28 @@
>> +/* PR target/52129 */
>> +
>> +extern void abort (void);
>> +struct S { void *p; unsigned int q; };
>> +struct T { char a[64]; char b[64]; } t;
>> +
>> +__attribute__((noinline, noclone)) int
>> +foo (void *x, struct S s, void *y, void *z)
>> +{
>> + if (x != &t.a[2] || s.p != &t.b[5] || s.q != 27 || y != &t.a[17] || z !=
>> &t.b[17])
>> + abort ();
>> + return 29;
>> +}
>> +
>> +__attribute__((noinline, noclone)) int
>> +bar (void *x, void *y, void *z, struct S s, int t, struct T *u)
>> +{
>> + return foo (x, s, &u->a[t], &u->b[t]);
>> +}
>> +
>> +int
>> +main ()
>> +{
>> + struct S s = { &t.b[5], 27 };
>> + if (bar (&t.a[2], (void *) 0, (void *) 0, s, 17, &t) != 29)
>> + abort ();
>> + return 0;
>> +}
>>
>> Jakub
Re: [PATCH] Fix sibcall argument overlap checking if pretend_args_size (PR target/52129)
On Thu, Feb 09, 2012 at 04:54:59PM +0800, Carrot Wei wrote: > Since 4.6 contains the same bug, I would like to back port it to 4.6 > branch. Could you approve it for 4.6? Yes, this is ok. I'm sorry for deferring too many 4.6 backports for way too long, will get to it eventually. Jakub
Re: [PATCH] Use relayout_decl instead of layout_decl when completing vars with incomplete types (PR c/51339)
On Thu, Feb 09, 2012 at 12:11:45AM +0100, Ulrich Weigand wrote:
> The finish_decl change appears to have introduced a regression
> in attribute ((aligned)) handling. With the following code:
>
> extern const int foo[];
> const int __attribute__((aligned(16))) foo[] = { 0 };
>
> the attribute now seems to be ignored; reverting the change
> above causes the attribute to be honored again.
Seems the bug is elsewhere though, testing a fix, see
PR52181 I've filed for this.
Jakub
Re: [PATCH} backport r175475 to gcc-4_6-branch
On Wed, 8 Feb 2012, Jack Howarth wrote: >Currently PR49536 still exists in gcc-4_6-branch. The following > patch backports r175475 for the gcc 4.6.3 release. This will be helpful > to dragonegg users (http://llvm.org/bugs/show_bug.cgi?id=10042) as > dragonegg currently doesn't build against FSF gcc trunk yet. Regression > tested on x86_64-apple-darwin11... > > http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg00599.html > > Okay for gcc-4_6-branch and thus gcc 4.6.3? > Jack Ok. Thanks, Richard. > 2012-02-08 Jack Howarth > > Backport from mainline > 2011-06-27 Richard Guenther > > PR tree-optimization/49536 > * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): > For non-scalar inner types use a scalar type according to > the scalar inner mode. > > Index: gcc/tree-vect-stmts.c > === > --- gcc/tree-vect-stmts.c (revision 183938) > +++ gcc/tree-vect-stmts.c (working copy) > @@ -5117,6 +5117,15 @@ get_vectype_for_scalar_type_and_size (tr >&& GET_MODE_CLASS (inner_mode) != MODE_FLOAT) > return NULL_TREE; > > + /* We shouldn't end up building VECTOR_TYPEs of non-scalar components. > + When the component mode passes the above test simply use a type > + corresponding to that mode. The theory is that any use that > + would cause problems with this will disable vectorization anyway. */ > + if (!SCALAR_FLOAT_TYPE_P (scalar_type) > + && !INTEGRAL_TYPE_P (scalar_type) > + && !POINTER_TYPE_P (scalar_type)) > +scalar_type = lang_hooks.types.type_for_mode (inner_mode, 1); > + >/* If no size was supplied use the mode the target prefers. Otherwise > lookup a vector mode of the specified size. */ >if (size == 0) > > -- Richard Guenther SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Re: [PATCH] Fix var-tracking /c vs. non-/c note emitting (PR debug/52165)
On Wed, Feb 8, 2012 at 8:32 PM, Jakub Jelinek wrote: > Hi! > > emit_note_insn_var_location already had code to ensure that > non-NOTE_DURING_CALL_P notes emitted EMIT_NOTE_BEFORE_INSN > with NEXT_INSN (call_insn) are put after all the NOTE_DURING_CALL_P > notes after the call, but if there is NOTE_INSN_CALL_ARG_LOCATION > note there too, this code doesn't trigger and we would emit > a non-NOTE_DURING_CALL_P note before NOTE_INSN_CALL_ARG_LOCATION > note possibly followed by NOTE_DURING_CALL_P notes. That then may > trigger ICEs in dwarf2out, which assumes that the LVL labels change > monotonically, and that for calls first come all .LVLXXX-1 labels (if any) > and then .LVLXXX (if any). > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux and > with go cross to s390x-linux. Ok for trunk? Ok. Thanks, Richard. > 2012-02-08 Jakub Jelinek > > PR debug/52165 > * var-tracking.c (emit_note_insn_var_location): If > EMIT_NOTE_BEFORE_INSN and insn is NOTE_INSN_CALL_ARG_LOCATION, > emit it before next non-NOTE_INSN_CALL_ARG_LOCATION > non-NOTE_DURING_CALL_P insn. > > --- gcc/var-tracking.c.jj 2012-01-30 00:10:01.0 +0100 > +++ gcc/var-tracking.c 2012-02-08 16:20:54.808523330 +0100 > @@ -8225,9 +8225,14 @@ emit_note_insn_var_location (void **varp > /* Make sure that the call related notes come first. */ > while (NEXT_INSN (insn) > && NOTE_P (insn) > - && NOTE_DURING_CALL_P (insn)) > + && ((NOTE_KIND (insn) == NOTE_INSN_VAR_LOCATION > + && NOTE_DURING_CALL_P (insn)) > + || NOTE_KIND (insn) == NOTE_INSN_CALL_ARG_LOCATION)) > insn = NEXT_INSN (insn); > - if (NOTE_P (insn) && NOTE_DURING_CALL_P (insn)) > + if (NOTE_P (insn) > + && ((NOTE_KIND (insn) == NOTE_INSN_VAR_LOCATION > + && NOTE_DURING_CALL_P (insn)) > + || NOTE_KIND (insn) == NOTE_INSN_CALL_ARG_LOCATION)) > note = emit_note_after (NOTE_INSN_VAR_LOCATION, insn); > else > note = emit_note_before (NOTE_INSN_VAR_LOCATION, insn); > > Jakub
Re: Go patch committed: Build math library with -funsafe-math-optimizations
On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor wrote: > The master Go math library uses assembler code on 386 processors to take > advantage of 387 instructions. This patch lets gccgo do the same thing, > by compiling the math library with -funsafe-math-optimizations. I also > pass -mfancy-math-387, although that is the default. It would not be > appropriate to compile all Go code with -funsafe-math-optimizations, of > course, but the math library is designed to handle it. Huh ... I'd rather not do that if I were you. Instead I'd say we lack a machine specific flag to enable the fancy-x87-math patterns which then -funsafe-math-optimizations should enable. The x87 math routines are the only thing you are after, right? No math-library can be _safe_ against -funsafe-math-optimizations I believe. Richard. > The compiler currently rewrites calls to, e.g., acos to call acosl > instead when using excess precision. This also enables the use of > assembler routines on 387. I tweaked the compiler to only do this when > optimizing, which is probably how it should have been done anyhow. (At > some point this code will move into the gcc interface out of the > frontend proper.) > > With this change the math library no longer refers to functions like > acosl on 386 systems--the operations are done inline using 387 > instructions--which should address some portability problems. > > Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu (32-bit > and 64-bit mode). Committed to mainline. > > Ian >
Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result
On Wed, Feb 8, 2012 at 10:25 PM, Kai Tietz wrote:
> 2012/1/11 Richard Guenther :
>>
>> count despite being declared volatile and only loaded once in the source
>> is loaded twice in gimple. If it were a HW register which destroys the
>> device after the 2nd load without an intervening store you'd wrecked
>> the device ;)
>>
>> Richard.
>
> Thanks for explaination. I tried to flip order for lhs/rhs in
> gimplify_modify_expr & co. Issue here is that for some cases we are
> relying here on lhs for gimplifying rhs (is_gimple_reg_rhs_or_call vs
> is_gimple_mem_rhs_or_call) and this doesn't work for cases in C++
> like:
>
> typedef const unsigned char _Jv_Utf8Const;
> typedef __SIZE_TYPE__ uaddr;
>
> void maybe_adjust_signature (_Jv_Utf8Const *&s, uaddr &special)
> {
> union {
> _Jv_Utf8Const *signature;
> uaddr signature_bits;
> };
> signature = s;
> special = signature_bits & 1;
> signature_bits -= special;
> s = signature;
> }
>
> So I modified gimplify_self_mod_expr for post-inc/dec so that we use
> following sequence
> and add it to pre_p for it:
>
> tmp = lhs;
> lvalue = tmp (+/-) rhs
> *expr_p = tmp;
As I explained this is the wrong place to fix the PR. The issue is not
about self-modifying expressions but about evaluating call argument
side-effects before side-effects of the lhs.
Richard.
> ChangeLog
>
> 2012-02-08 Kai Tietz
>
> PR middle-end/48814
> * gimplify.c (gimplify_self_mod_expr): Move for
> postfix-inc/dec the modification in pre and return
> temporary with origin value.
>
> 2012-02-08 Kai Tietz
>
> * gcc.c-torture/execute/pr48814-1.c: New test.
> * gcc.c-torture/execute/pr48814-2.c: New test.
> * gcc.dg/tree-ssa/assign-1.c: New test.
> * gcc.dg/tree-ssa/assign-2.c: New test.
>
> I did boostrap for all languages (including Ada and Obj-C++) and
> regression tests on host x86_64-unknown-linux-gnu. Ok for apply?
>
> Regards,
> Kai
>
> Index: gcc/gcc/gimplify.c
> ===
> --- gcc.orig/gcc/gimplify.c
> +++ gcc/gcc/gimplify.c
> @@ -2197,7 +2197,7 @@ gimplify_self_mod_expr (tree *expr_p, gi
> bool want_value)
> {
> enum tree_code code;
> - tree lhs, lvalue, rhs, t1;
> + tree lhs, lvalue, rhs, t1, t2;
> gimple_seq post = NULL, *orig_post_p = post_p;
> bool postfix;
> enum tree_code arith_code;
> @@ -2264,20 +2264,23 @@ gimplify_self_mod_expr (tree *expr_p, gi
> arith_code = POINTER_PLUS_EXPR;
> }
>
> - t1 = build2 (arith_code, TREE_TYPE (*expr_p), lhs, rhs);
> -
> - if (postfix)
> - {
> - gimplify_assign (lvalue, t1, orig_post_p);
> - gimplify_seq_add_seq (orig_post_p, post);
> - *expr_p = lhs;
> - return GS_ALL_DONE;
> - }
> - else
> + if (!postfix)
> {
> + t1 = build2 (arith_code, TREE_TYPE (*expr_p), lhs, rhs);
> *expr_p = build2 (MODIFY_EXPR, TREE_TYPE (lvalue), lvalue, t1);
> return GS_OK;
> }
> +
> + /* Assign lhs to temporary variable. */
> + t2 = create_tmp_var (TREE_TYPE (lhs), NULL);
> + gimplify_assign (t2, lhs, pre_p);
> + /* Do increment and assign it to lvalue. */
> + t1 = build2 (arith_code, TREE_TYPE (*expr_p), t2, rhs);
> + gimplify_assign (lvalue, t1, pre_p);
> +
> + gimplify_seq_add_seq (orig_post_p, post);
> + *expr_p = t2;
> + return GS_ALL_DONE;
> }
>
> /* If *EXPR_P has a variable sized type, wrap it in a WITH_SIZE_EXPR. */
> Index: gcc/gcc/testsuite/gcc.c-torture/execute/pr48814-1.c
> ===
> --- /dev/null
> +++ gcc/gcc/testsuite/gcc.c-torture/execute/pr48814-1.c
> @@ -0,0 +1,18 @@
> +extern void abort (void);
> +
> +int arr[] = {1,2,3,4};
> +int count = 0;
> +
> +int __attribute__((noinline))
> +incr (void)
> +{
> + return ++count;
> +}
> +
> +int main()
> +{
> + arr[count++] = incr ();
> + if (count != 2 || arr[count] != 3)
> + abort ();
> + return 0;
> +}
> Index: gcc/gcc/testsuite/gcc.c-torture/execute/pr48814-2.c
> ===
> --- /dev/null
> +++ gcc/gcc/testsuite/gcc.c-torture/execute/pr48814-2.c
> @@ -0,0 +1,18 @@
> +extern void abort (void);
> +
> +int arr[] = {1,2,3,4};
> +int count = 0;
> +
> +int
> +incr (void)
> +{
> + return ++count;
> +}
> +
> +int main()
> +{
> + arr[count++] = incr ();
> + if (count != 2 || arr[count] != 3)
> + abort ();
> + return 0;
> +}
> Index: gcc/gcc/testsuite/gcc.dg/tree-ssa/assign-1.c
> ===
> --- /dev/null
> +++ gcc/gcc/testsuite/gcc.dg/tree-ssa/assign-1.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +
> +volatile int count;
> +void bar(int);
> +void foo()
> +{
> + bar(count++);
> +}
> +
> +/* { dg-final { scan-tree-dump-times "count =" 1 "optimized"} } */
> +/* { dg-final { cleanup-tree-dump "optimized" } } */
> Index: gcc/gcc/testsuite/g
Re: [PATCH] Fix PR middle-end/52140, ICE on valid code
On Thu, Feb 9, 2012 at 3:34 AM, Peter Bergner wrote:
> The following patch fixes an ICE when we try and generate a compare of
> decimal float variables when we are not compiling for a cpu with dfp
> hardware support. This is a regression from gcc 4.4. The patch below
> bootstrapped and regression tested with no regressions on trunk, 4.6
> and 4.5. Is this ok everywhere?
>
> I'll note that there seem to be a few other places that need this change,
> but they aren't needed to fix this ICE, so I left them for a 4.8. cleanup.
Ok.
Thanks,
Richard.
> Peter
>
>
> gcc/
> PR middle-end/52140
> * dojump.c (do_compare_rtx_and_jump): Use SCALAR_FLOAT_MODE_P.
>
> gcc/testsuite/
> PR middle-end/52140
> * gcc.dg/dfp/pr52140.c: New test.
>
> Index: gcc/dojump.c
> ===
> --- gcc/dojump.c (revision 184032)
> +++ gcc/dojump.c (working copy)
> @@ -1049,7 +1049,7 @@ do_compare_rtx_and_jump (rtx op0, rtx op
> }
> else
> {
> - if (GET_MODE_CLASS (mode) == MODE_FLOAT
> + if (SCALAR_FLOAT_MODE_P (mode)
> && ! can_compare_p (code, mode, ccp_jump)
> && can_compare_p (swap_condition (code), mode, ccp_jump))
> {
> @@ -1060,7 +1060,7 @@ do_compare_rtx_and_jump (rtx op0, rtx op
> op1 = tmp;
> }
>
> - else if (GET_MODE_CLASS (mode) == MODE_FLOAT
> + else if (SCALAR_FLOAT_MODE_P (mode)
> && ! can_compare_p (code, mode, ccp_jump)
>
> /* Never split ORDERED and UNORDERED. These must be
> implemented. */
> Index: gcc/testsuite/gcc.dg/dfp/pr52140.c
> ===
> --- gcc/testsuite/gcc.dg/dfp/pr52140.c (revision 0)
> +++ gcc/testsuite/gcc.dg/dfp/pr52140.c (revision 0)
> @@ -0,0 +1,10 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O1" } */
> +
> +/* This used to result in an ICE. */
> +
> +int
> +foo (_Decimal64 x, _Decimal64 y)
> +{
> + return (x < y) || (x > y);
> +}
>
>
[VMS & Ada] (committed): Remove dependency on adamsg.msg
Hi,
the Ada run time depends on DEC-Ada messages, which requires either the native
message compiler or the DEC-Ada library.
Both were not convenient to build a cross-compiler.
This patch removes the dependency simply by using the message code instead.
Tested by building for ia64-hp-openvms.
Committed on trunk.
Tristan.
ada/
2012-02-09 Tristan Gingold
* gcc-interface/Makefile.in: Remove .sym rule (not used).
Remove adamsg.o object (requires native message compiler).
* init.c (CMA$_EXIT_THREAD, MTH$_FLOOVEMAT, SS$_INTDIV): Define as a
macro instead of as extern int.
(ADA$_ALREADY_OPEN, ADA$_CONSTRAINT_ERRO, ADA$_DATA_ERROR)
(ADA$_DEVICE_ERROR, ADA$_END_ERROR, ADA$_FAC_MODE_MISMAT)
(ADA$_IOSYSFAILED, ADA$_KEYSIZERR, ADA$_KEY_MISMATCH)
(ADA$_LAYOUT_ERROR, ADA$_LINEXCMRS, ADA$_MAXLINEXC)
(ADA$_MODE_ERROR, ADA$_MRN_MISMATCH, ADA$_MRS_MISMATCH)
(ADA$_NAME_ERROR, ADA$_NOT_OPEN, ADA$_ORG_MISMATCH)
(ADA$_PROGRAM_ERROR, ADA$_RAT_MISMATCH, ADA$_RFM_MISMATCH)
(ADA$_STAOVF, ADA$_STATUS_ERROR, ADA$_STORAGE_ERROR)
(ADA$_UNSUPPORTED, ADA$_USE_ERROR): Likewise.
(struct cond_except): Field cond is now an unsigned int.
(dec_ada_cond_except_table): Adjust.
(cond_except_table): Likewise.
(cond_resignal_table): Likewise.
(__gnat_default_resignal_p): Fix style.
Index: gcc/ada/init.c
===
--- gcc/ada/init.c (revision 184040)
+++ gcc/ada/init.c (working copy)
@@ -1117,12 +1117,12 @@
/* These codes are in standard message libraries. */
extern int C$_SIGKILL;
-extern int CMA$_EXIT_THREAD;
extern int SS$_DEBUG;
-extern int SS$_INTDIV;
extern int LIB$_KEYNOTFOU;
extern int LIB$_ACTIMAGE;
-extern int MTH$_FLOOVEMAT; /* Some ACVC_21 CXA tests */
+#define CMA$_EXIT_THREAD 4227492
+#define MTH$_FLOOVEMAT 1475268 /* Some ACVC_21 CXA tests */
+#define SS$_INTDIV 1156
/* These codes are non standard, which is to say the author is
not sure if they are defined in the standard message libraries
@@ -1131,7 +1131,7 @@
#define FDL$_UNPRIKW 11829410
struct cond_except {
- const int *cond;
+ unsigned int cond;
const struct Exception_Data *except;
};
@@ -1181,76 +1181,73 @@
extern Exception_Code Base_Code_In (Exception_Code);
/* DEC Ada exceptions are not defined in a header file, so they
- must be declared as external addresses. */
+ must be declared. */
-extern int ADA$_PROGRAM_ERROR;
-extern int ADA$_LOCK_ERROR;
-extern int ADA$_EXISTENCE_ERROR;
-extern int ADA$_KEY_ERROR;
-extern int ADA$_KEYSIZERR;
-extern int ADA$_STAOVF;
-extern int ADA$_CONSTRAINT_ERRO;
-extern int ADA$_IOSYSFAILED;
-extern int ADA$_LAYOUT_ERROR;
-extern int ADA$_STORAGE_ERROR;
-extern int ADA$_DATA_ERROR;
-extern int ADA$_DEVICE_ERROR;
-extern int ADA$_END_ERROR;
-extern int ADA$_MODE_ERROR;
-extern int ADA$_NAME_ERROR;
-extern int ADA$_STATUS_ERROR;
-extern int ADA$_NOT_OPEN;
-extern int ADA$_ALREADY_OPEN;
-extern int ADA$_USE_ERROR;
-extern int ADA$_UNSUPPORTED;
-extern int ADA$_FAC_MODE_MISMAT;
-extern int ADA$_ORG_MISMATCH;
-extern int ADA$_RFM_MISMATCH;
-extern int ADA$_RAT_MISMATCH;
-extern int ADA$_MRS_MISMATCH;
-extern int ADA$_MRN_MISMATCH;
-extern int ADA$_KEY_MISMATCH;
-extern int ADA$_MAXLINEXC;
-extern int ADA$_LINEXCMRS;
+#define ADA$_ALREADY_OPEN 0x0031a594
+#define ADA$_CONSTRAINT_ERRO 0x00318324
+#define ADA$_DATA_ERROR0x003192c4
+#define ADA$_DEVICE_ERROR 0x003195e4
+#define ADA$_END_ERROR 0x00319904
+#define ADA$_FAC_MODE_MISMAT 0x0031a8b3
+#define ADA$_IOSYSFAILED 0x0031af04
+#define ADA$_KEYSIZERR 0x0031aa3c
+#define ADA$_KEY_MISMATCH 0x0031a8e3
+#define ADA$_LAYOUT_ERROR 0x00319c24
+#define ADA$_LINEXCMRS 0x0031a8f3
+#define ADA$_MAXLINEXC 0x0031a8eb
+#define ADA$_MODE_ERROR0x00319f44
+#define ADA$_MRN_MISMATCH 0x0031a8db
+#define ADA$_MRS_MISMATCH 0x0031a8d3
+#define ADA$_NAME_ERROR0x0031a264
+#define ADA$_NOT_OPEN 0x0031a58c
+#define ADA$_ORG_MISMATCH 0x0031a8bb
+#define ADA$_PROGRAM_ERROR 0x00318964
+#define ADA$_RAT_MISMATCH 0x0031a8cb
+#define ADA$_RFM_MISMATCH 0x0031a8c3
+#define ADA$_STAOVF0x00318cac
+#define ADA$_STATUS_ERROR 0x0031a584
+#define ADA$_STORAGE_ERROR 0x00318c84
+#define ADA$_UNSUPPORTED 0x0031a8ab
+#define ADA$_USE_ERROR 0x0031a8a4
/* DEC Ada specific conditions. */
static const struct cond_except dec_ada_cond_except_table [] = {
- {&ADA$_PROGRAM_ERROR, &program_error},
- {&ADA$_USE_ERROR, &Use_Error},
- {&ADA$_KEYSIZERR, &program_error},
- {&ADA$_STAOVF, &storage_error},
- {&ADA$_CONSTRAINT_ERRO, &constraint_error},
- {&ADA$_IOSYSFAILED, &Device_Error},
- {&ADA$_LAYOUT_ERROR,&Layout_Error},
- {&ADA$_STORAGE_ERROR, &storage_error},
-
Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result
On Thu, Feb 9, 2012 at 11:29 AM, Richard Guenther
wrote:
> On Wed, Feb 8, 2012 at 10:25 PM, Kai Tietz wrote:
>> 2012/1/11 Richard Guenther :
>>>
>>> count despite being declared volatile and only loaded once in the source
>>> is loaded twice in gimple. If it were a HW register which destroys the
>>> device after the 2nd load without an intervening store you'd wrecked
>>> the device ;)
>>>
>>> Richard.
>>
>> Thanks for explaination. I tried to flip order for lhs/rhs in
>> gimplify_modify_expr & co. Issue here is that for some cases we are
>> relying here on lhs for gimplifying rhs (is_gimple_reg_rhs_or_call vs
>> is_gimple_mem_rhs_or_call) and this doesn't work for cases in C++
>> like:
>>
>> typedef const unsigned char _Jv_Utf8Const;
>> typedef __SIZE_TYPE__ uaddr;
>>
>> void maybe_adjust_signature (_Jv_Utf8Const *&s, uaddr &special)
>> {
>> union {
>> _Jv_Utf8Const *signature;
>> uaddr signature_bits;
>> };
>> signature = s;
>> special = signature_bits & 1;
>> signature_bits -= special;
>> s = signature;
>> }
>>
>> So I modified gimplify_self_mod_expr for post-inc/dec so that we use
>> following sequence
>> and add it to pre_p for it:
>>
>> tmp = lhs;
>> lvalue = tmp (+/-) rhs
>> *expr_p = tmp;
>
> As I explained this is the wrong place to fix the PR. The issue is not
> about self-modifying expressions but about evaluating call argument
> side-effects before side-effects of the lhs.
I am testing the attached instead.
Richard.
2012-02-09 Richard Guenther
PR middle-end/48814
* gimplify.c (gimplify_modify_expr): Perform side-effects of
the RHS before those of the LHS.
2012-02-08 Kai Tietz
* gcc.c-torture/execute/pr48814-1.c: New test.
* gcc.c-torture/execute/pr48814-2.c: New test.
* gcc.dg/tree-ssa/assign-1.c: New test.
* gcc.dg/tree-ssa/assign-2.c: New test.
fix-pr48814
Description: Binary data
Re: Too much memory in chan/select2.go used
On Thu, Feb 9, 2012 at 7:43 AM, Ian Lance Taylor wrote: > Uros Bizjak writes: > >> Some more debugging reveal the difference between alpha and x86_64. >> Alpha does not implement split stacks, so soon after >> "runtime.MemStats.Alloc = 0" line, we allocate exactly 2MB fake stack >> via: > > Thanks for tracking this down. > >> So, short of XFAILing the test on non-split stack targets, I have no >> other idea how to handle this testcase failure. > > I thought about it for a while, and I can't think of any better approach > than to skip this test case. A simple xfail doesn't work because it > xfails the compilation of the test case rather than the execution, > leading to an XPASS and a FAIL. Thanks! BTW: I'd like to point out that we can use go-execute-xfail in this case, so the case is compiled but is known to fail execution for some reason. Uros.
Re: [patch, testsuite, committed] Test case for vectorization PR 32380
On Wed, Feb 08, 2012 at 08:57:15PM +0100, Thomas Koenig wrote:
> I committed the attached test case after verifying that it passes and
> that only real(4) variables occur (so the requiredment on vect_float
> should be correct.)
This fails e.g. on i686-linux. The problem is that dg-options for */vect/*
tests overrides the standard options, instead of adding to them, so the
-msse2 needed for the test to actually vectorize anything in it is gone.
I think now that we have dg-additional-options, we can use it instead
(at least, the testcase works with that), and perhaps we should eventually
remove the magic testcase names like no-vfa-*, fast-math-*, no-fast-math-*,
wrapv-* etc. and just use dg-additional-options in those vect.exp tests.
Ok for trunk?
2012-02-09 Jakub Jelinek
PR fortran/32380
* gfortran.dg/vect/pr32380.f: Use dg-additional-options instead
of dg-options.
--- gcc/testsuite/gfortran.dg/vect/pr32380.f.jj 2012-02-09 12:11:00.0
+0100
+++ gcc/testsuite/gfortran.dg/vect/pr32380.f2012-02-09 12:27:24.860308981
+0100
@@ -1,6 +1,6 @@
! { dg-do compile }
! { dg-require-effective-target vect_float }
-! { dg-options "-O3 -fcray-pointer -ftree-vectorize -fdump-tree-vect-stats" }
+! { dg-additional-options "-O3 -fcray-pointer" }
! PR 32380 - loops were not vectorized due to unaligned store.
subroutine trnfbt(e,f,qs,mte,gm,ihgenf,hgener,lft,llt,sthick,
. fibl,istupd,ies,hoff)
Jakub
[C/C++ PATCH] Fix merge_decls/duplicate_decls DECL_USER_ALIGN/DECL_ALIGN handling (PR c/52181)
Hi!
DECL_USER_ALIGN bit used to be formerly in tree_decl_common structure
directly, thus the memcpy merge_decls performs used to copy also the
DECL_USER_ALIGN (newdecl) bit to DECL_USER_ALIGN (olddecl). But
it has been moved into tree_base, which is not copied that way.
This means that in C if olddecl has normal alignment and newdecl has bigger
alignment and DECL_USER_ALIGN, it will have the bigger DECL_ALIGN (which
is copied with memcpy), but won't have DECL_USER_ALIGN set, so when we call
relayout_decl on it this DECL_ALIGN is reset back to the smaller value.
Fixed by copying that bit.
After writing a larger testcase for this I've noticed that the C++ FE
has a bug in this too, but the other way around, i.e. if olddecl had
user alignment and newdecl does not, newdecl will not inherit the user
alignment.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-02-09 Jakub Jelinek
PR c/52181
* c-decl.c (merge_decls): Copy DECL_USER_ALIGN bit from olddecl to
newdecl.
* decl.c (duplicate_decls): If olddecl has bigger DECL_ALIGN than
newdecl, copy DECL_ALIGN to newdecl and or DECL_USER_ALIGN bits.
* c-c++-common/pr52181.c: New test.
--- gcc/c-decl.c.jj 2012-01-15 20:59:56.0 +0100
+++ gcc/c-decl.c2012-02-09 09:33:35.955067726 +0100
@@ -2449,6 +2449,7 @@ merge_decls (tree newdecl, tree olddecl,
memcpy ((char *) olddecl + sizeof (struct tree_common),
(char *) newdecl + sizeof (struct tree_common),
sizeof (struct tree_decl_common) - sizeof (struct tree_common));
+DECL_USER_ALIGN (olddecl) = DECL_USER_ALIGN (newdecl);
switch (TREE_CODE (olddecl))
{
case FUNCTION_DECL:
--- gcc/cp/decl.c.jj2012-01-26 09:22:19.0 +0100
+++ gcc/cp/decl.c 2012-02-09 09:56:42.129108618 +0100
@@ -2214,7 +2214,12 @@ duplicate_decls (tree newdecl, tree oldd
SET_DECL_INIT_PRIORITY (olddecl, DECL_INIT_PRIORITY (newdecl));
DECL_HAS_INIT_PRIORITY_P (olddecl) = 1;
}
- /* Likewise for DECL_USER_ALIGN and DECL_PACKED. */
+ /* Likewise for DECL_ALIGN, DECL_USER_ALIGN and DECL_PACKED. */
+ if (DECL_ALIGN (olddecl) > DECL_ALIGN (newdecl))
+{
+ DECL_ALIGN (newdecl) = DECL_ALIGN (olddecl);
+ DECL_USER_ALIGN (newdecl) |= DECL_USER_ALIGN (olddecl);
+}
DECL_USER_ALIGN (olddecl) = DECL_USER_ALIGN (newdecl);
if (TREE_CODE (newdecl) == FIELD_DECL)
DECL_PACKED (olddecl) = DECL_PACKED (newdecl);
--- gcc/testsuite/c-c++-common/pr52181.c.jj 2012-02-09 09:36:36.332028377
+0100
+++ gcc/testsuite/c-c++-common/pr52181.c2012-02-09 09:36:04.0
+0100
@@ -0,0 +1,13 @@
+/* PR c/52181 */
+/* { dg-do compile } */
+
+extern const int v1[];
+const int __attribute__((aligned(16))) v1[] = { 1 };
+extern const int __attribute__((aligned(16))) v2[];
+const int v2[] = { 1 };
+extern const int __attribute__((aligned(16))) v3[];
+const int __attribute__((aligned(16))) v3[] = { 1 };
+const int __attribute__((aligned(16))) v4[] = { 1 };
+int test[(__alignof__ (v4) != __alignof__ (v1) /* { dg-bogus "is
negative" } */
+|| __alignof__ (v4) != __alignof__ (v2)
+|| __alignof__ (v4) != __alignof__ (v3)) ? -1 : 0];
Jakub
Re: [patch, testsuite, committed] Test case for vectorization PR 32380
On Thu, 9 Feb 2012, Jakub Jelinek wrote:
> On Wed, Feb 08, 2012 at 08:57:15PM +0100, Thomas Koenig wrote:
> > I committed the attached test case after verifying that it passes and
> > that only real(4) variables occur (so the requiredment on vect_float
> > should be correct.)
>
> This fails e.g. on i686-linux. The problem is that dg-options for */vect/*
> tests overrides the standard options, instead of adding to them, so the
> -msse2 needed for the test to actually vectorize anything in it is gone.
>
> I think now that we have dg-additional-options, we can use it instead
> (at least, the testcase works with that), and perhaps we should eventually
> remove the magic testcase names like no-vfa-*, fast-math-*, no-fast-math-*,
> wrapv-* etc. and just use dg-additional-options in those vect.exp tests.
Yeah ... but IIRC dg-additional-options doesn't work everywhere
> Ok for trunk?
Ok.
Thanks,
Richard.
> 2012-02-09 Jakub Jelinek
>
> PR fortran/32380
> * gfortran.dg/vect/pr32380.f: Use dg-additional-options instead
> of dg-options.
>
> --- gcc/testsuite/gfortran.dg/vect/pr32380.f.jj 2012-02-09
> 12:11:00.0 +0100
> +++ gcc/testsuite/gfortran.dg/vect/pr32380.f 2012-02-09 12:27:24.860308981
> +0100
> @@ -1,6 +1,6 @@
> ! { dg-do compile }
> ! { dg-require-effective-target vect_float }
> -! { dg-options "-O3 -fcray-pointer -ftree-vectorize -fdump-tree-vect-stats" }
> +! { dg-additional-options "-O3 -fcray-pointer" }
> ! PR 32380 - loops were not vectorized due to unaligned store.
>subroutine trnfbt(e,f,qs,mte,gm,ihgenf,hgener,lft,llt,sthick,
> . fibl,istupd,ies,hoff)
>
>
Re: [C/C++ PATCH] Fix merge_decls/duplicate_decls DECL_USER_ALIGN/DECL_ALIGN handling (PR c/52181)
On Thu, Feb 9, 2012 at 12:38 PM, Jakub Jelinek wrote:
> Hi!
>
> DECL_USER_ALIGN bit used to be formerly in tree_decl_common structure
> directly, thus the memcpy merge_decls performs used to copy also the
> DECL_USER_ALIGN (newdecl) bit to DECL_USER_ALIGN (olddecl). But
> it has been moved into tree_base, which is not copied that way.
> This means that in C if olddecl has normal alignment and newdecl has bigger
> alignment and DECL_USER_ALIGN, it will have the bigger DECL_ALIGN (which
> is copied with memcpy), but won't have DECL_USER_ALIGN set, so when we call
> relayout_decl on it this DECL_ALIGN is reset back to the smaller value.
> Fixed by copying that bit.
>
> After writing a larger testcase for this I've noticed that the C++ FE
> has a bug in this too, but the other way around, i.e. if olddecl had
> user alignment and newdecl does not, newdecl will not inherit the user
> alignment.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
I'd say this needs to be backported to at least the point where we moved
the align fields.
Richard.
> 2012-02-09 Jakub Jelinek
>
> PR c/52181
> * c-decl.c (merge_decls): Copy DECL_USER_ALIGN bit from olddecl to
> newdecl.
>
> * decl.c (duplicate_decls): If olddecl has bigger DECL_ALIGN than
> newdecl, copy DECL_ALIGN to newdecl and or DECL_USER_ALIGN bits.
>
> * c-c++-common/pr52181.c: New test.
>
> --- gcc/c-decl.c.jj 2012-01-15 20:59:56.0 +0100
> +++ gcc/c-decl.c 2012-02-09 09:33:35.955067726 +0100
> @@ -2449,6 +2449,7 @@ merge_decls (tree newdecl, tree olddecl,
> memcpy ((char *) olddecl + sizeof (struct tree_common),
> (char *) newdecl + sizeof (struct tree_common),
> sizeof (struct tree_decl_common) - sizeof (struct tree_common));
> + DECL_USER_ALIGN (olddecl) = DECL_USER_ALIGN (newdecl);
> switch (TREE_CODE (olddecl))
> {
> case FUNCTION_DECL:
> --- gcc/cp/decl.c.jj 2012-01-26 09:22:19.0 +0100
> +++ gcc/cp/decl.c 2012-02-09 09:56:42.129108618 +0100
> @@ -2214,7 +2214,12 @@ duplicate_decls (tree newdecl, tree oldd
> SET_DECL_INIT_PRIORITY (olddecl, DECL_INIT_PRIORITY (newdecl));
> DECL_HAS_INIT_PRIORITY_P (olddecl) = 1;
> }
> - /* Likewise for DECL_USER_ALIGN and DECL_PACKED. */
> + /* Likewise for DECL_ALIGN, DECL_USER_ALIGN and DECL_PACKED. */
> + if (DECL_ALIGN (olddecl) > DECL_ALIGN (newdecl))
> + {
> + DECL_ALIGN (newdecl) = DECL_ALIGN (olddecl);
> + DECL_USER_ALIGN (newdecl) |= DECL_USER_ALIGN (olddecl);
> + }
> DECL_USER_ALIGN (olddecl) = DECL_USER_ALIGN (newdecl);
> if (TREE_CODE (newdecl) == FIELD_DECL)
> DECL_PACKED (olddecl) = DECL_PACKED (newdecl);
> --- gcc/testsuite/c-c++-common/pr52181.c.jj 2012-02-09 09:36:36.332028377
> +0100
> +++ gcc/testsuite/c-c++-common/pr52181.c 2012-02-09 09:36:04.0
> +0100
> @@ -0,0 +1,13 @@
> +/* PR c/52181 */
> +/* { dg-do compile } */
> +
> +extern const int v1[];
> +const int __attribute__((aligned(16))) v1[] = { 1 };
> +extern const int __attribute__((aligned(16))) v2[];
> +const int v2[] = { 1 };
> +extern const int __attribute__((aligned(16))) v3[];
> +const int __attribute__((aligned(16))) v3[] = { 1 };
> +const int __attribute__((aligned(16))) v4[] = { 1 };
> +int test[(__alignof__ (v4) != __alignof__ (v1) /* { dg-bogus "is
> negative" } */
> + || __alignof__ (v4) != __alignof__ (v2)
> + || __alignof__ (v4) != __alignof__ (v3)) ? -1 : 0];
>
> Jakub
Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE
Hi Patrick,
apologies for
(a) the extra loop - I missed a deprecation warning when I built your
last version ...
(b) rolling two things into one mail ...
... (point 1 is related the pie issue, point 2 to linkage hassles).
On 9 Feb 2012, at 08:36, Iain Sandoe wrote:
I think refs (from libstdc++) should be satisfied at link time with
-lstdc++ but probably I am missing something?
when you link c++ code, that is what is required .. but obv. we
don't want lstdc++ on the link line for c (because the library
*will* be found @ runtime - and thus the routines would be called).
I have an idea ... perhaps we supply (yet another) crt that is
linked last on the line and provides the dummies. That way the
linkage will be satisfied from libstd++ for c++ and the dummies for c.
will try and see if I can fit a trial of that idea in on D9 & D10.
Point 2 below... now I look at this again, I wonder why the current
scheme doesn't cause a problem for Rainer on c++ as well?
===
anyway.
1/ one of the routines you had in the fix was deprecated, can we try:
+ Dl_info info;
+
+ if (! dladdr (f, &info) || info.dli_fbase == NULL)
+abort ();
+
+ mh = (struct mach_header *) info.dli_fbase;
(and the additional header include) instead?
2/ I've moved the dummy routines to the [Darwin] tm crt endfile ..
+/* Provide dummy functions to satisfy linkage for versions of the
Darwin tool-chain that
+ that can't handle undefined weak refs at the link stage. */
+
+extern void *__cxa_allocate_exception (size_t) WEAK;
+extern void __cxa_throw (void *, void *, void *) WEAK;
+extern void *__cxa_begin_catch (void *) WEAK;
+extern void *__cxa_end_catch (void) WEAK;
+extern void __cxa_tm_cleanup (void *, void *, unsigned int) WEAK;
+
+void *__cxa_allocate_exception (size_t s UNUSED) { return NULL; }
+void __cxa_throw (void * a UNUSED, void * b UNUSED, void * c UNUSED)
+{ return; }
+void *__cxa_begin_catch (void * a UNUSED) { return NULL; }
+void *__cxa_end_catch (void) { return NULL; }
+void __cxa_tm_cleanup (void * a UNUSED, void * b UNUSED, unsigned
int c UNUSED)
+{ return; }
+
Rainer, would that work for you too ? ... it would allow removal from
libitm/eh_cpp.cc
for now, for Darwin:
-#if !defined (HAVE_ELF_STYLE_WEAKREF)
+#if !defined (HAVE_ELF_STYLE_WEAKREF) && ! defined (__MACH__)
The attached works with/without -fpie on Darwin 9, I won't get a
chance to test on D10 for a while, that machine is fully tied up ...
and I don't have D11 could people try it, if this seems reasonable?
Iain
libgcc/config/darwin-crt-tm.c | 96 ++---
libgcc/config/t-darwin|3 +
libitm/eh_cpp.cc |2 +-
3 files changed, 75 insertions(+), 26 deletions(-)
diff --git a/libgcc/config/darwin-crt-tm.c b/libgcc/config/darwin-crt-tm.c
index 2311337..380767b 100644
--- a/libgcc/config/darwin-crt-tm.c
+++ b/libgcc/config/darwin-crt-tm.c
@@ -23,33 +23,68 @@ a copy of the GCC Runtime Library Exception along with this
program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
Re: [C/C++ PATCH] Fix merge_decls/duplicate_decls DECL_USER_ALIGN/DECL_ALIGN handling (PR c/52181)
On Thu, Feb 09, 2012 at 12:54:59PM +0100, Richard Guenther wrote: > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > I'd say this needs to be backported to at least the point where we moved > the align fields. Agreed, but I'd wait with the backports a little bit. Jakub
Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result
On Thu, Feb 9, 2012 at 11:53 AM, Richard Guenther
wrote:
> On Thu, Feb 9, 2012 at 11:29 AM, Richard Guenther
> wrote:
>> On Wed, Feb 8, 2012 at 10:25 PM, Kai Tietz wrote:
>>> 2012/1/11 Richard Guenther :
count despite being declared volatile and only loaded once in the source
is loaded twice in gimple. If it were a HW register which destroys the
device after the 2nd load without an intervening store you'd wrecked
the device ;)
Richard.
>>>
>>> Thanks for explaination. I tried to flip order for lhs/rhs in
>>> gimplify_modify_expr & co. Issue here is that for some cases we are
>>> relying here on lhs for gimplifying rhs (is_gimple_reg_rhs_or_call vs
>>> is_gimple_mem_rhs_or_call) and this doesn't work for cases in C++
>>> like:
>>>
>>> typedef const unsigned char _Jv_Utf8Const;
>>> typedef __SIZE_TYPE__ uaddr;
>>>
>>> void maybe_adjust_signature (_Jv_Utf8Const *&s, uaddr &special)
>>> {
>>> union {
>>> _Jv_Utf8Const *signature;
>>> uaddr signature_bits;
>>> };
>>> signature = s;
>>> special = signature_bits & 1;
>>> signature_bits -= special;
>>> s = signature;
>>> }
>>>
>>> So I modified gimplify_self_mod_expr for post-inc/dec so that we use
>>> following sequence
>>> and add it to pre_p for it:
>>>
>>> tmp = lhs;
>>> lvalue = tmp (+/-) rhs
>>> *expr_p = tmp;
>>
>> As I explained this is the wrong place to fix the PR. The issue is not
>> about self-modifying expressions but about evaluating call argument
>> side-effects before side-effects of the lhs.
>
> I am testing the attached instead.
Doesn't work. Btw, Kai, your patch surely breaks things if you put
the lvalue update into the pre queue.
Consider a simple
a[i++] = i;
you gimplify that to
i.0 = i;
D.1709 = i.0;
i = D.1709 + 1;
a[D.1709] = i;
which is wrong.
Seems we are lacking some basic pre-/post-modify testcases ...
Richard.
[C++ Patch] PR 51494 (and 52183)
Hi,
a related/duplicate issue went into Bugzilla today, thus I decided to
return to the RFC/Patch which I posted back in December
(http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01593.html): as far as I
can see my analysis still stands and, to be clear, I'm proposing this
kind of patch for post-4.7.0, at this point. The below, compared to the
old draft proposal is a bit tidier, but should still do the right thing,
it fixes the new more involved testcase too.
Tested x86_64-linux.
Thanks,
Paolo.
/cp
2012-02-09 Paolo Carlini
PR c++/51494
PR c++/52183
* tree.c (maybe_dummy_object): Add a bool parameter.
* cp-tree.h (maybe_dummy_object): Update.
* semantics.c (finish_call_expr): Adjust call, pass
non_static_member_function_p (fn) as boolean argument.
(finish_non_static_data_member, finish_qualified_id_expr,
finish_id_expression): Adjust calls.
* typeck.c (convert_member_func_to_ptr): Likewise.
* init.c (build_offset_ref): Likewise.
/testsuite
2012-02-09 Paolo Carlini
PR c++/51494
PR c++/52183
* g++.dg/cpp0x/lambda/lambda-51494.C: New.
Index: testsuite/g++.dg/cpp0x/lambda/lambda-51494.C
===
--- testsuite/g++.dg/cpp0x/lambda/lambda-51494.C(revision 0)
+++ testsuite/g++.dg/cpp0x/lambda/lambda-51494.C(revision 0)
@@ -0,0 +1,12 @@
+// PR c++/51494
+// { dg-options -std=c++0x }
+
+struct A
+{
+ static void f() {}
+
+ void foo()
+ {
+[] () { f(); };
+ }
+};
Index: cp/typeck.c
===
--- cp/typeck.c (revision 184041)
+++ cp/typeck.c (working copy)
@@ -6112,7 +6112,7 @@ convert_member_func_to_ptr (tree type, tree expr)
expr = build_address (PTRMEM_CST_MEMBER (expr));
else
{
- decl = maybe_dummy_object (TYPE_PTRMEM_CLASS_TYPE (intype), 0);
+ decl = maybe_dummy_object (TYPE_PTRMEM_CLASS_TYPE (intype), 0, true);
decl = build_address (decl);
expr = get_member_function_from_ptrfunc (&decl, expr);
}
Index: cp/init.c
===
--- cp/init.c (revision 184041)
+++ cp/init.c (working copy)
@@ -1,7 +1,7 @@
/* Handle initialization things in C++.
Copyright (C) 1987, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
- 2011 Free Software Foundation, Inc.
+ 2011, 2012 Free Software Foundation, Inc.
Contributed by Michael Tiemann (tiem...@cygnus.com)
This file is part of GCC.
@@ -1847,7 +1847,7 @@ build_offset_ref (tree type, tree member, bool add
}
/* Set up BASEBINFO for member lookup. */
- decl = maybe_dummy_object (type, &basebinfo);
+ decl = maybe_dummy_object (type, &basebinfo, true);
/* A lot of this logic is now handled in lookup_member. */
if (BASELINK_P (member))
Index: cp/tree.c
===
--- cp/tree.c (revision 184041)
+++ cp/tree.c (working copy)
@@ -1,6 +1,7 @@
/* Language-dependent node constructors for parse phase of GNU compiler.
Copyright (C) 1987, 1988, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
- 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2007, 2008, 2009, 2010, 2011
+ 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2007, 2008, 2009, 2010, 2011,
+ 2012
Free Software Foundation, Inc.
Hacked by Michael Tiemann (tiem...@cygnus.com)
@@ -2553,10 +2554,11 @@ build_dummy_object (tree type)
/* We've gotten a reference to a member of TYPE. Return *this if appropriate,
or a dummy object otherwise. If BINFOP is non-0, it is filled with the
- binfo path from current_class_type to TYPE, or 0. */
+ binfo path from current_class_type to TYPE, or 0. If MAYBE_CAPTURE_THIS
+ is false, in a lambda we don't want to capture 'this'. */
tree
-maybe_dummy_object (tree type, tree* binfop)
+maybe_dummy_object (tree type, tree* binfop, bool maybe_capture_this)
{
tree decl, context;
tree binfo;
@@ -2583,7 +2585,8 @@ tree
(TREE_TYPE (current_class_ref), context)))
decl = current_class_ref;
else if (current != current_class_type
- && context == nonlambda_method_basetype ())
+ && context == nonlambda_method_basetype ()
+ && maybe_capture_this)
/* In a lambda, need to go through 'this' capture. */
decl = (build_x_indirect_ref
((lambda_expr_this_capture
Index: cp/semantics.c
===
--- cp/semantics.c (revision 184041)
+++ cp/semantics.c (working copy)
@@ -1538,7 +1538,7 @@ finish_non_static_data_member (tree decl, tree obj
tree scope = qualifying_scope;
if (scope == NULL_TREE)
scope = context_for_name_lookup (decl);
- object = maybe_dummy_object (scope, NULL);
+ object = maybe_du
Re: Go patch committed: Provide matherr function
Ian Lance Taylor writes: > On SVID-based systems, when certain math functions encounter an > exceptional condition they call a magic function named matherr. That > function is permitted to change the result which the math functions will > return. a program is permitted to provide its own version of matherr. > > Solaris works this way and at least the Solaris version of matherr does > not act as Go, or an ordinary interpretation of the function, would > expect. E.g., calling acos on an out-of-range value will return 0 > rather than NaN. Unfortunately, this breaks the libgo build on Solaris 8 and 9: /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c: In function 'matherr': /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:38:17: error: 'NAN' undeclared (first use in this function) /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:38:17: note: each undeclared identifier is reported only once for each function it appears in /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:68:28: error: 'INFINITY' undeclared (first use in this function) make[4]: *** [go-matherr.lo] Error 1 I couldn't find an appproprite replacement in the system headers. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result
2012/2/9 Richard Guenther :
> On Thu, Feb 9, 2012 at 11:53 AM, Richard Guenther
> wrote:
>> On Thu, Feb 9, 2012 at 11:29 AM, Richard Guenther
>> wrote:
>>> On Wed, Feb 8, 2012 at 10:25 PM, Kai Tietz wrote:
2012/1/11 Richard Guenther :
>
> count despite being declared volatile and only loaded once in the source
> is loaded twice in gimple. If it were a HW register which destroys the
> device after the 2nd load without an intervening store you'd wrecked
> the device ;)
>
> Richard.
Thanks for explaination. I tried to flip order for lhs/rhs in
gimplify_modify_expr & co. Issue here is that for some cases we are
relying here on lhs for gimplifying rhs (is_gimple_reg_rhs_or_call vs
is_gimple_mem_rhs_or_call) and this doesn't work for cases in C++
like:
typedef const unsigned char _Jv_Utf8Const;
typedef __SIZE_TYPE__ uaddr;
void maybe_adjust_signature (_Jv_Utf8Const *&s, uaddr &special)
{
union {
_Jv_Utf8Const *signature;
uaddr signature_bits;
};
signature = s;
special = signature_bits & 1;
signature_bits -= special;
s = signature;
}
So I modified gimplify_self_mod_expr for post-inc/dec so that we use
following sequence
and add it to pre_p for it:
tmp = lhs;
lvalue = tmp (+/-) rhs
*expr_p = tmp;
>>>
>>> As I explained this is the wrong place to fix the PR. The issue is not
>>> about self-modifying expressions but about evaluating call argument
>>> side-effects before side-effects of the lhs.
>>
>> I am testing the attached instead.
>
> Doesn't work. Btw, Kai, your patch surely breaks things if you put
> the lvalue update into the pre queue.
>
> Consider a simple
>
> a[i++] = i;
>
> you gimplify that to
>
> i.0 = i;
> D.1709 = i.0;
> i = D.1709 + 1;
> a[D.1709] = i;
>
> which is wrong.
>
> Seems we are lacking some basic pre-/post-modify testcases ...
>
> Richard.
Why, this should be wrong? In fact C specification just says that the
post-inc has to happen at least before next sequence-point. It
doesn't say that the increment has to happen after evaluation of rhs.
The produced gimple for the following C-code
int arr[128];
void foo (int i)
{
arr[i++] = i;
}
is:
foo (int i)
{
int D.1364;
D.1364 = i;
i = D.1364 + 1;
arr[D.1364] = i;
}
which looks to me from description of the C-specification correct.
Kai
Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE
Hi Iain,
On 02/09/2012 07:26 AM, Iain Sandoe wrote:
apologies for
(a) the extra loop - I missed a deprecation warning when I built your
last version ...
Thanks! Actually, I saw the depreciation but I didn't found that dladdr.
(b) rolling two things into one mail ...
... (point 1 is related the pie issue, point 2 to linkage hassles).
On 9 Feb 2012, at 08:36, Iain Sandoe wrote:
I think refs (from libstdc++) should be satisfied at link time with
-lstdc++ but probably I am missing something?
when you link c++ code, that is what is required .. but obv. we don't
want lstdc++ on the link line for c (because the library *will* be
found @ runtime - and thus the routines would be called).
I have an idea ... perhaps we supply (yet another) crt that is linked
last on the line and provides the dummies. That way the linkage will
be satisfied from libstd++ for c++ and the dummies for c.
will try and see if I can fit a trial of that idea in on D9 & D10.
Thanks for the explanation.
Point 2 below... now I look at this again, I wonder why the current
scheme doesn't cause a problem for Rainer on c++ as well?
Yep, this confuses me too.
2/ I've moved the dummy routines to the [Darwin] tm crt endfile ..
+/* Provide dummy functions to satisfy linkage for versions of the
Darwin tool-chain that
+ that can't handle undefined weak refs at the link stage. */
+
+extern void *__cxa_allocate_exception (size_t) WEAK;
+extern void __cxa_throw (void *, void *, void *) WEAK;
+extern void *__cxa_begin_catch (void *) WEAK;
+extern void *__cxa_end_catch (void) WEAK;
+extern void __cxa_tm_cleanup (void *, void *, unsigned int) WEAK;
+
+void *__cxa_allocate_exception (size_t s UNUSED) { return NULL; }
+void __cxa_throw (void * a UNUSED, void * b UNUSED, void * c UNUSED)
+{ return; }
+void *__cxa_begin_catch (void * a UNUSED) { return NULL; }
+void *__cxa_end_catch (void) { return NULL; }
+void __cxa_tm_cleanup (void * a UNUSED, void * b UNUSED, unsigned int c
UNUSED)
+{ return; }
+
Note you should also do the same for alloc_cpp.cc:
#if !defined (HAVE_ELF_STYLE_WEAKREF)
void *_ZnwX (size_t) { return NULL; }
void _ZdlPv (void *) { return; }
void *_ZnaX (size_t) { return NULL; }
void _ZdaPv (void *) { return; }
void *_ZnwXRKSt9nothrow_t (size_t, c_nothrow_p) { return NULL; }
void _ZdlPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) { return NULL; }
void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
#endif /* HAVE_ELF_STYLE_WEAKREF */
Native configuration is x86_64-apple-darwin10.8.0
=== libitm tests ===
Schedule of variations:
unix
Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description
file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file
for target.
Using /Users/patrick/gcc/trunk/libitm/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /Users/patrick/gcc/trunk/libitm/testsuite/libitm.c/c.exp ...
Running /Users/patrick/gcc/trunk/libitm/testsuite/libitm.c++/c++.exp ...
=== libitm Summary ===
# of expected passes26
# of expected failures 3
# of unsupported tests 1
Tested with XCode 4.0. I do not have any darwin 11.
Thanks.
--
Patrick.
Index: libitm/alloc_cpp.cc
===
--- libitm/alloc_cpp.cc (revision 183968)
+++ libitm/alloc_cpp.cc (working copy)
@@ -60,7 +60,7 @@ extern void _ZdlPvRKSt9nothrow_t (void *, c_nothro
extern void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) __attribute__((weak));
extern void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) __attribute__((weak));
-#if !defined (HAVE_ELF_STYLE_WEAKREF)
+#if !defined (HAVE_ELF_STYLE_WEAKREF) && !defined (__MACH__)
void *_ZnwX (size_t) { return NULL; }
void _ZdlPv (void *) { return; }
void *_ZnaX (size_t) { return NULL; }
Index: libitm/eh_cpp.cc
===
--- libitm/eh_cpp.cc (revision 183968)
+++ libitm/eh_cpp.cc (working copy)
@@ -39,7 +39,7 @@ extern void *__cxa_begin_catch (void *) WEAK;
extern void *__cxa_end_catch (void) WEAK;
extern void __cxa_tm_cleanup (void *, void *, unsigned int) WEAK;
-#if !defined (HAVE_ELF_STYLE_WEAKREF)
+#if !defined (HAVE_ELF_STYLE_WEAKREF) && !defined (__MACH__)
void *__cxa_allocate_exception (size_t) { return NULL; }
void __cxa_throw (void *, void *, void *) { return; }
void *__cxa_begin_catch (void *) { return NULL; }
Index: libgcc/config/darwin-crt-tm.c
===
--- libgcc/config/darwin-crt-tm.c (revision 183968)
+++ libgcc/config/darwin-crt-tm.c (working copy)
@@ -23,33 +23,68 @@ a copy of the GCC Runtime Library Exception along
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
Re: [PATCH] increase timeout in simulate-thread gdb test
I think there was a defect for that... Anyway, I think 10 seconds just came out of someones imagination, but I'm not sure. Was that you Aldy? I really can't remember, but it's possible. Given thats the case, I'd be more tempted long term to simply disable the line by line output into the log file... I assume thats possible. then we dont need any special time outs. If a failure needs investigation, you look at it by hand. Andrew
Re: [PATCH] increase timeout in simulate-thread gdb test
On Thu, Feb 9, 2012 at 3:12 PM, Aldy Hernandez wrote: >> I think there was a defect for that... Anyway, I think 10 seconds just >> came out of someones imagination, but I'm not sure. Was that you Aldy? > > > I really can't remember, but it's possible. It was me, and the sole reason was that timeout didn't worked and the log filled the file system. After timeout functionality was fixed, the timeout was forced to 10 seconds. It is an arbitrary number. Uros.
Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result
On Thu, Feb 9, 2012 at 2:48 PM, Kai Tietz wrote:
> 2012/2/9 Richard Guenther :
>> On Thu, Feb 9, 2012 at 11:53 AM, Richard Guenther
>> wrote:
>>> On Thu, Feb 9, 2012 at 11:29 AM, Richard Guenther
>>> wrote:
On Wed, Feb 8, 2012 at 10:25 PM, Kai Tietz wrote:
> 2012/1/11 Richard Guenther :
>>
>> count despite being declared volatile and only loaded once in the source
>> is loaded twice in gimple. If it were a HW register which destroys the
>> device after the 2nd load without an intervening store you'd wrecked
>> the device ;)
>>
>> Richard.
>
> Thanks for explaination. I tried to flip order for lhs/rhs in
> gimplify_modify_expr & co. Issue here is that for some cases we are
> relying here on lhs for gimplifying rhs (is_gimple_reg_rhs_or_call vs
> is_gimple_mem_rhs_or_call) and this doesn't work for cases in C++
> like:
>
> typedef const unsigned char _Jv_Utf8Const;
> typedef __SIZE_TYPE__ uaddr;
>
> void maybe_adjust_signature (_Jv_Utf8Const *&s, uaddr &special)
> {
> union {
> _Jv_Utf8Const *signature;
> uaddr signature_bits;
> };
> signature = s;
> special = signature_bits & 1;
> signature_bits -= special;
> s = signature;
> }
>
> So I modified gimplify_self_mod_expr for post-inc/dec so that we use
> following sequence
> and add it to pre_p for it:
>
> tmp = lhs;
> lvalue = tmp (+/-) rhs
> *expr_p = tmp;
As I explained this is the wrong place to fix the PR. The issue is not
about self-modifying expressions but about evaluating call argument
side-effects before side-effects of the lhs.
>>>
>>> I am testing the attached instead.
>>
>> Doesn't work. Btw, Kai, your patch surely breaks things if you put
>> the lvalue update into the pre queue.
>>
>> Consider a simple
>>
>> a[i++] = i;
>>
>> you gimplify that to
>>
>> i.0 = i;
>> D.1709 = i.0;
>> i = D.1709 + 1;
>> a[D.1709] = i;
>>
>> which is wrong.
>>
>> Seems we are lacking some basic pre-/post-modify testcases ...
>>
>> Richard.
>
> Why, this should be wrong? In fact C specification just says that the
> post-inc has to happen at least before next sequence-point. It
> doesn't say that the increment has to happen after evaluation of rhs.
>
> The produced gimple for the following C-code
>
> int arr[128];
>
> void foo (int i)
> {
> arr[i++] = i;
> }
>
> is:
>
> foo (int i)
> {
> int D.1364;
>
> D.1364 = i;
> i = D.1364 + 1;
> arr[D.1364] = i;
> }
>
> which looks to me from description of the C-specification correct.
Hm, indeed. I'll test the following shorter patch and add the struct-return
volatile testcase.
Richard.
fix-pr48814
Description: Binary data
Re: [PATCH] increase timeout in simulate-thread gdb test
On 02/09/2012 09:38 AM, Uros Bizjak wrote: On Thu, Feb 9, 2012 at 3:12 PM, Aldy Hernandez wrote: It was me, and the sole reason was that timeout didn't worked and the log filled the file system. After timeout functionality was fixed, the timeout was forced to 10 seconds. It is an arbitrary number. I suspected as much. Long term I think we should remove the line by line log info as the default. Andrew
[PATCH, ARM] Cortex-A8 backend fixes
This patch fixes few things in pipeline description of ARM Cortex-A8.
1) arm_no_early_alu_shift_value_dep() checks early dependence only for
one argument, ignoring the dependence on register used as shift amount.
For example, this function is used as a condition in bypass that sets
dep_cost=0 between mov and ALU operations:
mov r0, r1
add r3, r4, r5, asr r0
This results in dep_cost returning 0 for these insns, while according
to Technical Reference Manual it should be 1
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Babcagee.html).
Also, in PLUS and MINUS rtx expressions the order of operands is
different: PLUS has shift expression as its first argument, while MINUS
usually has shift as a second argument. But in
arm_no_early_alu_shift_value_dep() only the first argument is checked as
EARLY_OP. We changed arm_no_early_alu_shift_dep() so it uses
rtx_search() to find SHIFT expression. As all registers for SHIFT
expression are required at stage E1, it's no difference whether it's
shift's first or second argument, so we use new
arm_no_early_alu_shift_dep() instead of
arm_no_early_alu_shift_value_dep() in Cortex-A8 bypasses. Functions
arm_no_early_alu_shift_[value_]dep() are also used in Cortex-A5,
Cortex-R4 and ARM1136JFS descriptions, so we named modified function as
arm_cortex_a8_no_early_alu_shift_dep().
Besides SHIFTs and ROTATE, the function also handles MULT (which is used
to represent shifts by a constant) and ZERO_EXTEND and SIGN_EXTEND (they
also have type of alu_shift).
2) MUL to ALU bypass has incorrect delay of 4 cycles, while according to
TRM it has to be 5 for MUL and 6 for MULL. The patch splits this bypass
in two and sets the correct delay values.
3) In cortex-a8.md MOV with shift instructions matched to wrong
reservations (cortex_a8_alu_shift, cortex_a8_alu_shift_reg). Adding
insn attribute "mov" for arm_shiftsi3 pattern in arm.md fixes that.
4) SMLALxy was moved from cortex_a8_mull reservation to
cortex_a8_smlald, which according to TRM has proper timing for this insn
(1 cycle less than MULL).
5) ARM Cortex-A8 TRM itself contains inaccurate timings for availability
of RdLo in some multiply instructions. Namely, lower part of the result
for (S|U)MULL, (S|U)MLAL, UMAAL, SMLALxy, SMLALD, SMLSLD instructions
is already available at E4 stage (instead of E5 in TRM).
This information initially was found in beagle board mailing list, and
it's confirmed by our tests and these sites:
http://www.avison.me.uk/ben/programming/cortex-a8.html and
http://hilbert-space.de/?p=66
The patch adds two bypasses between these instructions and MOV
instruction, which uses arm_mull_low_part_dep() to check whether
dependency is only on the low part of MUL destination. Bypasses between
MULL and ALU insns for RdLo can't be added, because between this pair of
reservation there are existing bypasses. However, in practice these
multiply insns are rare, and on SPEC2K INT code low part of the result
for such insns is never used.
--
Best regards,
Dmitry
2012-02-09 Ruben Buchatskiy
* config/arm/arm-protos.h (arm_cortex_a8_no_early_alu_shift_dep,
arm_mull_low_part_dep): Declare.
* config/arm/arm.c (arm_cortex_a8_no_early_alu_shift_dep,
arm_mull_low_part_dep, is_early_op): New function.
* config/arm/arm.md (arm_shiftsi3): Add "mov" insn attribute.
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 23a29c6..2a1334e 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -97,10 +97,12 @@ extern int neon_struct_mem_operand (rtx);
extern int arm_no_early_store_addr_dep (rtx, rtx);
extern int arm_early_store_addr_dep (rtx, rtx);
extern int arm_early_load_addr_dep (rtx, rtx);
+extern int arm_cortex_a8_no_early_alu_shift_dep (rtx, rtx);
extern int arm_no_early_alu_shift_dep (rtx, rtx);
extern int arm_no_early_alu_shift_value_dep (rtx, rtx);
extern int arm_no_early_mul_dep (rtx, rtx);
extern int arm_mac_accumulator_is_mul_result (rtx, rtx);
+extern int arm_mull_low_part_dep (rtx, rtx);
extern int tls_mentioned_p (rtx);
extern int symbol_mentioned_p (rtx);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index ee26c51..e92c75b 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -23035,6 +23035,56 @@ arm_early_load_addr_dep (rtx producer, rtx consumer)
return reg_overlap_mentioned_p (value, addr);
}
+/* Return nonzero and copy *X to *DATA if *X is a SHIFT operand.
+ This is a callback for for_each_rtx in arm_no_early_alu_shift_dep(). */
+
+static int
+is_early_op (rtx *x, void *data)
+{
+ rtx *rtx_data = (rtx *) data;
+ enum rtx_code code;
+ code = GET_CODE (*x);
+
+ if (code == ASHIFT || code == ASHIFTRT || code == LSHIFTRT
+ || code == ROTATERT || code == ROTATE || code == MULT
+ || code == ZERO_EXTEND || code == SIGN_EXTEND)
+{
+ *rtx_data = *x;
+ return 1;
+}
+ else
+return 0;
Re: [PATCH] Fix PR middle-end/52140, ICE on valid code
On Thu, 2012-02-09 at 11:31 +0100, Richard Guenther wrote: > On Thu, Feb 9, 2012 at 3:34 AM, Peter Bergner wrote: > > The following patch fixes an ICE when we try and generate a compare of > > decimal float variables when we are not compiling for a cpu with dfp > > hardware support. This is a regression from gcc 4.4. The patch below > > bootstrapped and regression tested with no regressions on trunk, 4.6 > > and 4.5. Is this ok everywhere? > > Ok. Committed on trunk and both branches. Thanks. Peter
Re: libgo patch committed: Update to weekly.2012-02-07 release
Ian Lance Taylor writes:
> I have patched libgo to the weekly.2012-02-07 release. As usual this
> message only contains changes to files specific to gccgo. Bootstrapped
> and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to
> mainline.
I needed the following patch to have it compile on Solaris.
Rainer
diff --git a/libgo/go/os/stat_solaris.go b/libgo/go/os/stat_solaris.go
--- a/libgo/go/os/stat_solaris.go
+++ b/libgo/go/os/stat_solaris.go
@@ -9,18 +9,18 @@ import (
"time"
)
-func sameFile(fs1, fs2 *FileStat) bool {
- sys1 := fs1.Sys.(*syscall.Stat_t)
- sys2 := fs2.Sys.(*syscall.Stat_t)
- return sys1.Dev == sys2.Dev && sys1.Ino == sys2.Ino
+func sameFile(sys1, sys2 interface{}) bool {
+ stat1 := sys1.(*syscall.Stat_t)
+ stat2 := sys2.(*syscall.Stat_t)
+ return stat1.Dev == stat2.Dev && stat1.Ino == stat2.Ino
}
func fileInfoFromStat(st *syscall.Stat_t, name string) FileInfo {
- fs := &FileStat{
+ fs := &fileStat{
name:basename(name),
size:int64(st.Size),
modTime: timestrucToTime(st.Mtime),
- Sys: st,
+ sys: st,
}
fs.mode = FileMode(st.Mode & 0777)
switch st.Mode & syscall.S_IFMT {
@@ -52,5 +52,5 @@ func timestrucToTime(ts syscall.Timestru
// For testing.
func atime(fi FileInfo) time.Time {
- return timestrucToTime(fi.(*FileStat).Sys.(*syscall.Stat_t).Atime)
+ return timestrucToTime(fi.(*fileStat).Sys().(*syscall.Stat_t).Atime)
}
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result
On Thu, Feb 9, 2012 at 3:41 PM, Richard Guenther
wrote:
> On Thu, Feb 9, 2012 at 2:48 PM, Kai Tietz wrote:
>> 2012/2/9 Richard Guenther :
>>> On Thu, Feb 9, 2012 at 11:53 AM, Richard Guenther
>>> wrote:
On Thu, Feb 9, 2012 at 11:29 AM, Richard Guenther
wrote:
> On Wed, Feb 8, 2012 at 10:25 PM, Kai Tietz
> wrote:
>> 2012/1/11 Richard Guenther :
>>>
>>> count despite being declared volatile and only loaded once in the source
>>> is loaded twice in gimple. If it were a HW register which destroys the
>>> device after the 2nd load without an intervening store you'd wrecked
>>> the device ;)
>>>
>>> Richard.
>>
>> Thanks for explaination. I tried to flip order for lhs/rhs in
>> gimplify_modify_expr & co. Issue here is that for some cases we are
>> relying here on lhs for gimplifying rhs (is_gimple_reg_rhs_or_call vs
>> is_gimple_mem_rhs_or_call) and this doesn't work for cases in C++
>> like:
>>
>> typedef const unsigned char _Jv_Utf8Const;
>> typedef __SIZE_TYPE__ uaddr;
>>
>> void maybe_adjust_signature (_Jv_Utf8Const *&s, uaddr &special)
>> {
>> union {
>> _Jv_Utf8Const *signature;
>> uaddr signature_bits;
>> };
>> signature = s;
>> special = signature_bits & 1;
>> signature_bits -= special;
>> s = signature;
>> }
>>
>> So I modified gimplify_self_mod_expr for post-inc/dec so that we use
>> following sequence
>> and add it to pre_p for it:
>>
>> tmp = lhs;
>> lvalue = tmp (+/-) rhs
>> *expr_p = tmp;
>
> As I explained this is the wrong place to fix the PR. The issue is not
> about self-modifying expressions but about evaluating call argument
> side-effects before side-effects of the lhs.
I am testing the attached instead.
>>>
>>> Doesn't work. Btw, Kai, your patch surely breaks things if you put
>>> the lvalue update into the pre queue.
>>>
>>> Consider a simple
>>>
>>> a[i++] = i;
>>>
>>> you gimplify that to
>>>
>>> i.0 = i;
>>> D.1709 = i.0;
>>> i = D.1709 + 1;
>>> a[D.1709] = i;
>>>
>>> which is wrong.
>>>
>>> Seems we are lacking some basic pre-/post-modify testcases ...
>>>
>>> Richard.
>>
>> Why, this should be wrong? In fact C specification just says that the
>> post-inc has to happen at least before next sequence-point. It
>> doesn't say that the increment has to happen after evaluation of rhs.
>>
>> The produced gimple for the following C-code
>>
>> int arr[128];
>>
>> void foo (int i)
>> {
>> arr[i++] = i;
>> }
>>
>> is:
>>
>> foo (int i)
>> {
>> int D.1364;
>>
>> D.1364 = i;
>> i = D.1364 + 1;
>> arr[D.1364] = i;
>> }
>>
>> which looks to me from description of the C-specification correct.
>
> Hm, indeed. I'll test the following shorter patch and add the struct-return
> volatile testcase.
Works apart from
Running target unix/
FAIL: ext/pb_ds/regression/trie_map_rand.cc execution test
FAIL: ext/pb_ds/regression/trie_set_rand.cc execution test
Maybe invalid testcases. Who knows ... same fails happen with your patch.
Richard.
> Richard.
Re: [PATCH][4.8] C++ memory model bitfield handling rewrite
On Wed, Feb 8, 2012 at 3:14 AM, Richard Guenther wrote: > On Tue, 7 Feb 2012, Jakub Jelinek wrote: > >> On Tue, Feb 07, 2012 at 04:01:31PM +, Jonathan Wakely wrote: >> > > What would it have said for -fabi-version=1 where for >> > > we place s.i and s.d into the same byte? >> > >> > I think it says they shouldn't be in the same byte :-) >> >> They don't, except for compatibility with the old ABI. >> I think easiest would be either to error out on -fabi-version=1 >> mixed with an explicit option to request C++11 memory model, >> or just ignore it (perhaps with a warning), people who care about the strict >> memory model requirements just shouldn't use -fabi-version=1. >> Using atomic modifications of the byte that has parts of the tail >> padding bits used by another class would be IMHO an overkill. > > I agree. The question is of course whether the C++ memory model > folks thought about this issue in case there is an ABI that requires > this tail-padding reuse (they could have, for example, declared > that s.i and s.d are in the same bitfield - that would have made > things easy). I would think this is an implementation-defined issue (therefore GCC is required to document its choices.) -- Gaby
[patch ada]: Fix PR/50942
Hi, this fix ada bootstrap issue for stage 3 for windows native builds ChangeLog 2012-02-09 Kai Tietz PR ada/50942 * gcc-interface/Makefile.in (LN_S): Add r-option. Tested for i686-w64-mingw32. Ok for apply? Regards, Kai Index: gcc/gcc/ada/gcc-interface/Makefile.in === --- gcc.orig/gcc/ada/gcc-interface/Makefile.in +++ gcc/gcc/ada/gcc-interface/Makefile.in @@ -1485,7 +1485,7 @@ ifeq ($(strip $(filter-out alpha64 ia64 soext = .exe hyphen = _ LN = cp -p -LN_S = cp -p +LN_S = cp -pr .SUFFIXES: .sym
Re: [patch ada]: Fix PR/50942
On Feb 9, 2012, at 5:25 PM, Kai Tietz wrote: > Hi, > > this fix ada bootstrap issue for stage 3 for windows native builds > > ChangeLog > > 2012-02-09 Kai Tietz > > PR ada/50942 > * gcc-interface/Makefile.in (LN_S): Add r-option. > > Tested for i686-w64-mingw32. Ok for apply? Puzzling. Aren't these variables only defined on VMS hosts, due to the ifeq just before ? Tristan. > > Regards, > Kai > > Index: gcc/gcc/ada/gcc-interface/Makefile.in > === > --- gcc.orig/gcc/ada/gcc-interface/Makefile.in > +++ gcc/gcc/ada/gcc-interface/Makefile.in > @@ -1485,7 +1485,7 @@ ifeq ($(strip $(filter-out alpha64 ia64 > soext = .exe > hyphen = _ > LN = cp -p > -LN_S = cp -p > +LN_S = cp -pr > > .SUFFIXES: .sym
Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE
On Thu, Feb 09, 2012 at 08:54:14AM -0500, Patrick Marlier wrote:
> Hi Iain,
>
> On 02/09/2012 07:26 AM, Iain Sandoe wrote:
>> apologies for
>> (a) the extra loop - I missed a deprecation warning when I built your
>> last version ...
> Thanks! Actually, I saw the depreciation but I didn't found that dladdr.
>
>> (b) rolling two things into one mail ...
>> ... (point 1 is related the pie issue, point 2 to linkage hassles).
>>
>> On 9 Feb 2012, at 08:36, Iain Sandoe wrote:
I think refs (from libstdc++) should be satisfied at link time with
-lstdc++ but probably I am missing something?
>>>
>>> when you link c++ code, that is what is required .. but obv. we don't
>>> want lstdc++ on the link line for c (because the library *will* be
>>> found @ runtime - and thus the routines would be called).
>>>
>>> I have an idea ... perhaps we supply (yet another) crt that is linked
>>> last on the line and provides the dummies. That way the linkage will
>>> be satisfied from libstd++ for c++ and the dummies for c.
>>>
>>> will try and see if I can fit a trial of that idea in on D9 & D10.
> Thanks for the explanation.
>
>> Point 2 below... now I look at this again, I wonder why the current
>> scheme doesn't cause a problem for Rainer on c++ as well?
> Yep, this confuses me too.
>
>> 2/ I've moved the dummy routines to the [Darwin] tm crt endfile ..
>>
>> +/* Provide dummy functions to satisfy linkage for versions of the
>> Darwin tool-chain that
>> + that can't handle undefined weak refs at the link stage. */
>> +
>> +extern void *__cxa_allocate_exception (size_t) WEAK;
>> +extern void __cxa_throw (void *, void *, void *) WEAK;
>> +extern void *__cxa_begin_catch (void *) WEAK;
>> +extern void *__cxa_end_catch (void) WEAK;
>> +extern void __cxa_tm_cleanup (void *, void *, unsigned int) WEAK;
>> +
>> +void *__cxa_allocate_exception (size_t s UNUSED) { return NULL; }
>> +void __cxa_throw (void * a UNUSED, void * b UNUSED, void * c UNUSED)
>> +{ return; }
>> +void *__cxa_begin_catch (void * a UNUSED) { return NULL; }
>> +void *__cxa_end_catch (void) { return NULL; }
>> +void __cxa_tm_cleanup (void * a UNUSED, void * b UNUSED, unsigned int c
>> UNUSED)
>> +{ return; }
>> +
>
> Note you should also do the same for alloc_cpp.cc:
> #if !defined (HAVE_ELF_STYLE_WEAKREF)
> void *_ZnwX (size_t) { return NULL; }
> void _ZdlPv (void *) { return; }
> void *_ZnaX (size_t) { return NULL; }
> void _ZdaPv (void *) { return; }
>
> void *_ZnwXRKSt9nothrow_t (size_t, c_nothrow_p) { return NULL; }
> void _ZdlPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
> void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) { return NULL; }
> void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
> #endif /* HAVE_ELF_STYLE_WEAKREF */
>
>
>
> Native configuration is x86_64-apple-darwin10.8.0
>
> === libitm tests ===
>
> Schedule of variations:
> unix
>
> Running target unix
> Using /usr/local/share/dejagnu/baseboards/unix.exp as board description
> file for target.
> Using /usr/local/share/dejagnu/config/unix.exp as generic interface file
> for target.
> Using /Users/patrick/gcc/trunk/libitm/testsuite/config/default.exp as
> tool-and-target-specific interface file.
> Running /Users/patrick/gcc/trunk/libitm/testsuite/libitm.c/c.exp ...
> Running /Users/patrick/gcc/trunk/libitm/testsuite/libitm.c++/c++.exp ...
>
> === libitm Summary ===
>
> # of expected passes26
> # of expected failures 3
> # of unsupported tests 1
>
> Tested with XCode 4.0. I do not have any darwin 11.
>
> Thanks.
Patrick,
The results for this new patch applied to r184045 on x86_64-apple-darwin11
using Xcode 4.2.1 are below.
Native configuration is x86_64-apple-darwin11.3.0
=== libitm tests ===
Running target unix/-m32
=== libitm Summary for unix/-m32 ===
# of expected passes26
# of expected failures 3
# of unsupported tests 1
Running target unix/-m64
=== libitm Summary for unix/-m64 ===
# of expected passes26
# of expected failures 3
# of unsupported tests 1
=== libitm Summary ===
# of expected passes52
# of expected failures 6
# of unsupported tests 2
Compiler version: gcc libitm
Platform: x86_64-apple-darwin11.3.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man
--infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto
--enable-stage1-languages=c,lto
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.7 --enable-checking=release --enable-cloog-backend=isl
Since we may never see the weakref linker fix available for Xcode 4.x on Snow
Leopard
(as that will be Xcode 4.4 or later), we might as well avoid w
Re: [patch ada]: Fix PR/50942
> this fix ada bootstrap issue for stage 3 for windows native builds > > ChangeLog > > 2012-02-09 Kai Tietz > > PR ada/50942 > * gcc-interface/Makefile.in (LN_S): Add r-option. > > Tested for i686-w64-mingw32. Ok for apply? No, this chunk is only relevant for VMS so cannot possibly fix anything on Windows. Can you give the exact error message you are getting? AFAIK, LN_S is/should only be used for files, not directories BTW, so your change would be wrong even if in a Windows section. Arno
[PATCH] Fix PR50031, take 2
Following is a revision of yesterday's PR50031 patch submission,
modified per Richard's comments. Bootstrapped and tested with no
regressions on powerpc64-linux. I've confirmed the same performance
improvements in SPEC. OK for trunk?
Thanks,
Bill
2012-02-09 Bill Schmidt
Ira Rosen
PR tree-optimization/50031
* targhooks.c (default_builtin_vectorization_cost): Handle
vec_promote_demote.
* target.h (enum vect_cost_for_stmt): Add vec_promote_demote.
* tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Handle
all types of reduction and pattern statements.
(vect_estimate_min_profitable_iters): Likewise.
* tree-vect-stmts.c (vect_model_promotion_demotion_cost): New function.
(vect_get_load_cost): Use vec_perm for permutations; add dump logic
for explicit realigns.
(vectorizable_conversion): Call vect_model_promotion_demotion_cost.
* config/spu/spu.c (spu_builtin_vectorization_cost): Handle
vec_promote_demote.
* config/i386/i386.c (ix86_builtin_vectorization_cost): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Update
vec_perm for VSX and handle vec_promote_demote.
Index: gcc/targhooks.c
===
--- gcc/targhooks.c (revision 183944)
+++ gcc/targhooks.c (working copy)
@@ -514,6 +514,7 @@ default_builtin_vectorization_cost (enum vect_cost
case scalar_to_vec:
case cond_branch_not_taken:
case vec_perm:
+ case vec_promote_demote:
return 1;
case unaligned_load:
Index: gcc/target.h
===
--- gcc/target.h(revision 183944)
+++ gcc/target.h(working copy)
@@ -145,7 +145,8 @@ enum vect_cost_for_stmt
scalar_to_vec,
cond_branch_not_taken,
cond_branch_taken,
- vec_perm
+ vec_perm,
+ vec_promote_demote
};
/* The target structure. This holds all the backend hooks. */
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 183944)
+++ gcc/tree-vect-loop.c(working copy)
@@ -2417,7 +2417,8 @@ vect_get_single_scalar_iteraion_cost (loop_vec_inf
if (stmt_info
&& !STMT_VINFO_RELEVANT_P (stmt_info)
&& (!STMT_VINFO_LIVE_P (stmt_info)
- || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
+ || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_info)))
+ && !STMT_VINFO_IN_PATTERN_P (stmt_info))
continue;
if (STMT_VINFO_DATA_REF (vinfo_for_stmt (stmt)))
@@ -2564,15 +2565,48 @@ vect_estimate_min_profitable_iters (loop_vec_info
{
gimple stmt = gsi_stmt (si);
stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
+
+ /* Translate the last statement in a pattern into the
+related replacement statement. */
+ if (STMT_VINFO_IN_PATTERN_P (stmt_info))
+ {
+ stmt = STMT_VINFO_RELATED_STMT (stmt_info);
+ stmt_info = vinfo_for_stmt (stmt);
+ }
+
/* Skip stmts that are not vectorized inside the loop. */
if (!STMT_VINFO_RELEVANT_P (stmt_info)
&& (!STMT_VINFO_LIVE_P (stmt_info)
- || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
+ || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_info
continue;
+
vec_inside_cost += STMT_VINFO_INSIDE_OF_LOOP_COST (stmt_info) *
factor;
/* FIXME: for stmts in the inner-loop in outer-loop vectorization,
some of the "outside" costs are generated inside the outer-loop.
*/
vec_outside_cost += STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info);
+ if (is_pattern_stmt_p (stmt_info)
+ && STMT_VINFO_PATTERN_DEF_SEQ (stmt_info))
+{
+ gimple_stmt_iterator gsi;
+
+ for (gsi = gsi_start (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info));
+ !gsi_end_p (gsi); gsi_next (&gsi))
+{
+ gimple pattern_def_stmt = gsi_stmt (gsi);
+ stmt_vec_info pattern_def_stmt_info
+ = vinfo_for_stmt (pattern_def_stmt);
+ if (STMT_VINFO_RELEVANT_P (pattern_def_stmt_info)
+ || STMT_VINFO_LIVE_P (pattern_def_stmt_info))
+ {
+ vec_inside_cost
+ += STMT_VINFO_INSIDE_OF_LOOP_COST
+ (pattern_def_stmt_info) * factor;
+ vec_outside_cost
+ += STMT_VINFO_OUTSIDE_OF_LOOP_COST
+ (pattern_def_stmt_info);
+}
+ }
+ }
}
}
Index: gcc/tree-vect-stmts.c
=
Re: Go patch committed: Build math library with -funsafe-math-optimizations
Richard Guenther writes: > On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor wrote: >> The master Go math library uses assembler code on 386 processors to take >> advantage of 387 instructions. This patch lets gccgo do the same thing, >> by compiling the math library with -funsafe-math-optimizations. I also >> pass -mfancy-math-387, although that is the default. It would not be >> appropriate to compile all Go code with -funsafe-math-optimizations, of >> course, but the math library is designed to handle it. > > Huh ... I'd rather not do that if I were you. Instead I'd say we lack a > machine specific flag to enable the fancy-x87-math patterns which > then -funsafe-math-optimizations should enable. The x87 math > routines are the only thing you are after, right? No math-library > can be _safe_ against -funsafe-math-optimizations I believe. Yes, that approach would make sense, but this doesn't seem like the right time to do it. The -funsafe-math-optimizations option does not permit arbitrary behaviour. It merely permits a set of optimizations which violate strict IEEE conformance. I believe the Go math library can be safe in the presence of those optimizations, because the library does explicit checks for NaN and infinity, where necessary, before it does the actual operation. The math library has a fairly extensive set of tests, including tests of exceptional conditions, and it passes the tests when using -funsafe-math-optimizations. Note that I'm only using -funsafe-math-optimizations on x86. Ian
Re: [C/C++ PATCH] Fix merge_decls/duplicate_decls DECL_USER_ALIGN/DECL_ALIGN handling (PR c/52181)
On Thu, 9 Feb 2012, Jakub Jelinek wrote: > 2012-02-09 Jakub Jelinek > > PR c/52181 > * c-decl.c (merge_decls): Copy DECL_USER_ALIGN bit from olddecl to > newdecl. > > * decl.c (duplicate_decls): If olddecl has bigger DECL_ALIGN than > newdecl, copy DECL_ALIGN to newdecl and or DECL_USER_ALIGN bits. > > * c-c++-common/pr52181.c: New test. The C change and testcase are OK. -- Joseph S. Myers jos...@codesourcery.com
Backported 15 patches to 4.6 branch
Hi!
I've backported these patches from trunk to 4.6 branch,
bootstrapped/regtested them on x86_64-linux and i686-linux
and committed. Sorry for the delay.
Jakub
2012-02-09 Jakub Jelinek
Backported from mainline
2011-12-15 Jakub Jelinek
PR debug/51517
* tree-ssa-coalesce.c (coalesce_ssa_name): For !optimize, test
!DECL_IGNORED_P instead of !DECL_ARTIFICIAL.
* trans-decl.c (gfc_get_symbol_decl): Don't set DECL_INITAL on span.
(gfc_trans_deferred_vars): Instead add its runtime initialization
here.
--- gcc/tree-ssa-coalesce.c (revision 182361)
+++ gcc/tree-ssa-coalesce.c (revision 182362)
@@ -1373,7 +1373,7 @@ coalesce_ssa_name (void)
if (a
&& SSA_NAME_VAR (a)
- && !DECL_ARTIFICIAL (SSA_NAME_VAR (a))
+ && !DECL_IGNORED_P (SSA_NAME_VAR (a))
&& (!has_zero_uses (a) || !SSA_NAME_IS_DEFAULT_DEF (a)))
{
tree *slot = (tree *) htab_find_slot (ssa_name_hash, a, INSERT);
--- gcc/fortran/trans-decl.c(revision 182361)
+++ gcc/fortran/trans-decl.c(revision 182362)
@@ -1352,7 +1352,6 @@ gfc_get_symbol_decl (gfc_symbol * sym)
gfc_finish_var_decl (span, sym);
TREE_STATIC (span) = TREE_STATIC (decl);
DECL_ARTIFICIAL (span) = 1;
- DECL_INITIAL (span) = build_int_cst (gfc_array_index_type, 0);
GFC_DECL_SPAN (decl) = span;
GFC_TYPE_ARRAY_SPAN (TREE_TYPE (decl)) = span;
@@ -3394,6 +3393,17 @@ gfc_trans_deferred_vars (gfc_symbol * pr
if (sym->assoc)
continue;
+ if (sym->attr.subref_array_pointer
+ && GFC_DECL_SPAN (sym->backend_decl)
+ && !TREE_STATIC (GFC_DECL_SPAN (sym->backend_decl)))
+ {
+ gfc_init_block (&tmpblock);
+ gfc_add_modify (&tmpblock, GFC_DECL_SPAN (sym->backend_decl),
+ build_int_cst (gfc_array_index_type, 0));
+ gfc_add_init_cleanup (block, gfc_finish_block (&tmpblock),
+ NULL_TREE);
+ }
+
if (sym->attr.dimension)
{
/* Assumed-size Cray pointees need to be treated as AS_EXPLICIT. */
2012-02-09 Jakub Jelinek
Backported from mainline
2011-12-15 Jakub Jelinek
PR c/51360
* c-parser.c (c_parser_omp_clause_num_threads,
c_parser_omp_clause_schedule): Call mark_exp_read.
* semantics.c (finish_omp_clauses): For OMP_CLAUSE_NUM_THREADS_EXPR
and OMP_CLAUSE_SCHEDULE_CHUNK_EXPR call mark_rvalue_use.
* gcc.dg/gomp/pr51360.c: New test.
* g++.dg/gomp/pr51360.C: New test.
* g++.dg/gomp/pr51360-2.C: New test.
--- gcc/cp/semantics.c (revision 182380)
+++ gcc/cp/semantics.c (revision 182381)
@@ -4087,6 +4087,8 @@ finish_omp_clauses (tree clauses)
error ("num_threads expression must be integral");
remove = true;
}
+ else
+ OMP_CLAUSE_NUM_THREADS_EXPR (c) = mark_rvalue_use (t);
break;
case OMP_CLAUSE_SCHEDULE:
@@ -4101,6 +4103,8 @@ finish_omp_clauses (tree clauses)
error ("schedule chunk size expression must be integral");
remove = true;
}
+ else
+ OMP_CLAUSE_SCHEDULE_CHUNK_EXPR (c) = mark_rvalue_use (t);
break;
case OMP_CLAUSE_NOWAIT:
--- gcc/c-parser.c (revision 182380)
+++ gcc/c-parser.c (revision 182381)
@@ -9011,6 +9011,7 @@ c_parser_omp_clause_num_threads (c_parse
{
location_t expr_loc = c_parser_peek_token (parser)->location;
tree c, t = c_parser_expression (parser).value;
+ mark_exp_read (t);
t = c_fully_fold (t, false, NULL);
c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, "expected %<)%>");
@@ -9218,6 +9219,7 @@ c_parser_omp_clause_schedule (c_parser *
here = c_parser_peek_token (parser)->location;
t = c_parser_expr_no_commas (parser, NULL).value;
+ mark_exp_read (t);
t = c_fully_fold (t, false, NULL);
if (OMP_CLAUSE_SCHEDULE_KIND (c) == OMP_CLAUSE_SCHEDULE_RUNTIME)
--- gcc/testsuite/g++.dg/gomp/pr51360.C (revision 0)
+++ gcc/testsuite/g++.dg/gomp/pr51360.C (revision 182381)
@@ -0,0 +1,28 @@
+// PR c/51360
+// { dg-do compile }
+// { dg-options "-Wunused -W -fopenmp" }
+
+template
+void
+foo (T a, T b, T c)
+{
+ T m, n, o, i;
+ m = 6;
+ n = 1;
+ o = 5;
+ a = 6;
+ b = 1;
+ c = 5;
+ #pragma omp parallel for num_threads (m) if (n) schedule (static, o)
+ for (i = 0; i < 10; i++)
+;
+ #pragma omp parallel for num_threads (a) if (b) schedule (static, c)
+ for (i = 0; i < 10; i++)
+;
+}
+
+void
+bar ()
+{
+ foo (0, 0, 0);
+}
--- gcc/testsuite/gcc.dg/gomp/pr51360.c (revision 0)
+++ gcc/testsuite/gcc.dg/gomp/pr51360.c (revision 182381)
@@ -0,0 +1,21 @@
+/* PR c/51360 */
+/* { dg-do compile } */
+/* { dg-options "-Wunused -W -fopenmp" } */
+
+void
+foo (int a, int b, int c)
+{
+ int m, n, o, i;
+ m =
Re: [v3] Update C++11 status table.
> * doc/xml/manual/documentation_hacking.xml: Fix invalid > attribute. > > Also committed to trunk. Tested with 'make doc-xml-validate-docbook > doc-html' Doh! Thanks for cleaning up after my late-night hacking. If you can, I'd appreciate you trying to generate the PDF doxygen manual with the memory-increasing change to TeX. I understand the doc toolchain for doing this is non-trivial. I really want the hyperlinks without it this huge reference doc is largely useless. -benjamin
Re: Too much memory in chan/select2.go used
Uros Bizjak writes: > BTW: I'd like to point out that we can use go-execute-xfail in this > case, so the case is compiled but is known to fail execution for some > reason. Thanks, I didn't know about that one. I think I'll leave it as is for now because I'm treating stack.go the same way, and stack.go does sometimes pass even without -fsplit-stack. Ian
Re: Go patch committed: Provide matherr function
Rainer Orth writes: > Ian Lance Taylor writes: > >> On SVID-based systems, when certain math functions encounter an >> exceptional condition they call a magic function named matherr. That >> function is permitted to change the result which the math functions will >> return. a program is permitted to provide its own version of matherr. >> >> Solaris works this way and at least the Solaris version of matherr does >> not act as Go, or an ordinary interpretation of the function, would >> expect. E.g., calling acos on an out-of-range value will return 0 >> rather than NaN. > > Unfortunately, this breaks the libgo build on Solaris 8 and 9: > > /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c: In function 'matherr': > /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:38:17: error: 'NAN' > undeclared (first use in this function) > /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:38:17: note: each > undeclared identifier is reported only once for each function it appears in > /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:68:28: error: > 'INFINITY' undeclared (first use in this function) > make[4]: *** [go-matherr.lo] Error 1 > > I couldn't find an appproprite replacement in the system headers. Hmmm, INFINITY and NAN are in C99. Does it work to do something like #ifndef INFINITY #define INFINITY (1.0 / 0.0) #endif #ifndef NAN #define NAN (0.0 / 0.0) #endif ? Another possibility for NAN would to call nan(), if that is available. Ian
Re: Go patch committed: Provide matherr function
Rainer Orth writes: > Ian Lance Taylor writes: > >> On SVID-based systems, when certain math functions encounter an >> exceptional condition they call a magic function named matherr. That >> function is permitted to change the result which the math functions will >> return. a program is permitted to provide its own version of matherr. >> >> Solaris works this way and at least the Solaris version of matherr does >> not act as Go, or an ordinary interpretation of the function, would >> expect. E.g., calling acos on an out-of-range value will return 0 >> rather than NaN. > > Unfortunately, this breaks the libgo build on Solaris 8 and 9: > > /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c: In function 'matherr': > /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:38:17: error: 'NAN' > undeclared (first use in this function) > /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:38:17: note: each > undeclared identifier is reported only once for each function it appears in > /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:68:28: error: > 'INFINITY' undeclared (first use in this function) > make[4]: *** [go-matherr.lo] Error 1 > > I couldn't find an appproprite replacement in the system headers. Oh, wait, we can use __builtin_inf and __builtin_nan. Ian
Re: Go patch committed: Provide matherr function
Ian Lance Taylor writes:
>> Unfortunately, this breaks the libgo build on Solaris 8 and 9:
>>
>> /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c: In function
>> 'matherr':
>> /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:38:17: error: 'NAN'
>> undeclared (first use in this function)
>> /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:38:17: note: each
>> undeclared identifier is reported only once for each function it appears in
>> /vol/gcc/src/hg/trunk/local/libgo/runtime/go-matherr.c:68:28: error:
>> 'INFINITY' undeclared (first use in this function)
>> make[4]: *** [go-matherr.lo] Error 1
>>
>> I couldn't find an appproprite replacement in the system headers.
>
> Hmmm, INFINITY and NAN are in C99.
True, but full C99 support was only introduced in Solaris 10.
> Does it work to do something like
>
> #ifndef INFINITY
> #define INFINITY (1.0 / 0.0)
> #endif
>
> #ifndef NAN
> #define NAN (0.0 / 0.0)
> #endif
>
> ?
I could give it a try once the current bootstraps are finished. For the
moment I've shamelessly adapted the following from the __GNUC__ section
of Solaris 11 :
diff --git a/libgo/runtime/go-matherr.c b/libgo/runtime/go-matherr.c
--- a/libgo/runtime/go-matherr.c
+++ b/libgo/runtime/go-matherr.c
@@ -24,6 +24,14 @@
#define PI 3.14159265358979323846264338327950288419716939937510582097494459
+#ifndef INFINITY
+#define INFINITY (__builtin_inff ())
+#endif
+
+#ifndef NAN
+#define NAN (__builtin_nanf (""))
+#endif
+
int
matherr (struct exception* e)
{
> Another possibility for NAN would to call nan(), if that is available.
It's not, unfortunately.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libgo patch committed: Update to weekly.2012-02-07 release
Rainer Orth writes: > I needed the following patch to have it compile on Solaris. Thanks. I completely forgot about that file. Committed to mainline. Ian
Re: [v3] Update C++11 status table.
On 9 February 2012 17:43, Benjamin Kosnik wrote: > >> * doc/xml/manual/documentation_hacking.xml: Fix invalid >> attribute. >> >> Also committed to trunk. Tested with 'make doc-xml-validate-docbook >> doc-html' > > Doh! > > Thanks for cleaning up after my late-night hacking. If you can, I'd > appreciate you trying to generate the PDF doxygen manual with the > memory-increasing change to TeX. I understand the doc toolchain for > doing this is non-trivial. Sure, I'll give it a go later.
Re: [patch ada]: Fix PR/50942
2012/2/9 Arnaud Charlet : >> this fix ada bootstrap issue for stage 3 for windows native builds >> >> ChangeLog >> >> 2012-02-09 Kai Tietz >> >> PR ada/50942 >> * gcc-interface/Makefile.in (LN_S): Add r-option. >> >> Tested for i686-w64-mingw32. Ok for apply? > > No, this chunk is only relevant for VMS so cannot possibly fix > anything on Windows. > > Can you give the exact error message you are getting? > > AFAIK, LN_S is/should only be used for files, not directories BTW, > so your change would be wrong even if in a Windows section. > > Arno Hmm, I interpret 'ifeq ($(strip $(filter-out alpha64 ia64 dec hp vms% openvms% alphavms%,$(host))),)' as anthing not mentioned here. The bug is as described in the bug-report: Failure on Stage 3 when a make script try to execute following command: cp -p ../.././gcc/ada/rts adainclude Error messgage: cp: omitting directory '../.././gcc/ada/rts' Regards, Kai
Re: [patch ada]: Fix PR/50942
On 09/02/2012 18:55, Kai Tietz wrote: > Hmm, I interpret 'ifeq ($(strip $(filter-out alpha64 ia64 dec hp vms% > openvms% alphavms%,$(host))),)' as anthing not mentioned here. "If, after removing alpha64 ia64 dec hp vms% openvms% alphavms% (and stray whitespace) from the host, what remains is equal to nothing" -> "If host consists only of things in alpha64 ia64 dec hp vms% openvms% alphavms%". It's a slightly confusing construct I agree. Watch out for the difference between filter vs. filter-out and ifeq vs. ifneq, and note that that final comma indicates there's an empty string as arg2 of the if condition. cheers, DaveK
Re: [patch ada]: Fix PR/50942
> Hmm, I interpret 'ifeq ($(strip $(filter-out alpha64 ia64 dec hp vms% > openvms% alphavms%,$(host))),)' as anthing not mentioned here. That's a misunderstanding as explained by Dave Korn. > The bug is as described in the bug-report: > > Failure on Stage 3 when a make script try to execute following command: > > cp -p ../.././gcc/ada/rts adainclude We should never have such a command emitted by make, so the error is elsewhere/earlier. I suspect some variable didn't get expanded properly. It's possibly a bug in the version/port of make that you are using. Arno
Re: [patch ada]: Fix PR/50942
On 9 Feb 2012, at 19:59, Arnaud Charlet wrote: The bug is as described in the bug-report: Failure on Stage 3 when a make script try to execute following command: cp -p ../.././gcc/ada/rts adainclude We should never have such a command emitted by make, so the error is elsewhere/earlier. I suspect some variable didn't get expanded properly. nevertheless on Darwin (with GNU make 3.81) we get .. rm -rf adalib ln -s ../.././gcc/ada/rts adainclude ln -s ../.././gcc/ada/rts adalib It's possibly a bug in the version/port of make that you are using. maybe .. but it appears to be wider than just windows. Iain
Re: [patch ada]: Fix PR/50942
> nevertheless on Darwin (with GNU make 3.81) we get .. > > rm -rf adalib > ln -s ../.././gcc/ada/rts adainclude > ln -s ../.././gcc/ada/rts adalib Ah, this comes from libada/Makefile.in and is actually "expected", even though it's a bit kludgy IMO. This was introduced by revision 145622 to handle multilibs, I complete forgot about this special handling. In any case, the fix if any belongs either in configure or in libada/Makefile.in, not in gcc-interface. Arno
New German PO file for 'gcc' (version 4.7-b20120128)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/gcc/de.po (This file, 'gcc-4.7-b20120128.de.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
6 backported patches for 4.5 branch
Hi!
I've committed these backports to 4.5 branch after bootstrapping/regtesting
them on x86_64-linux and i686-linux.
Jakub
2012-02-09 Jakub Jelinek
Backported from mainline
2012-01-26 Jakub Jelinek
* make-relative-prefix.c (make_relative_prefix_1): Avoid warning
about using preprocessor directives inside of macro arguments.
2012-01-02 Jakub Jelinek
* make-relative-prefix.c (make_relative_prefix_1): Avoid
stack overflow if PATH contains just a single entry and
HOST_EXECUTABLE_SUFFIX needs to be used.
PR driver/48306
* make-relative-prefix.c: Include sys/stat.h.
(make_relative_prefix_1): If access succeeds, check also stat
if nstore is a regular file.
--- libiberty/make-relative-prefix.c(revision 182819)
+++ libiberty/make-relative-prefix.c(revision 183561)
@@ -58,6 +58,9 @@
#ifdef HAVE_UNISTD_H
#include
#endif
+#ifdef HAVE_SYS_STAT_H
+#include
+#endif
#include
@@ -245,10 +248,15 @@
{
char *startp, *endp, *nstore;
size_t prefixlen = strlen (temp) + 1;
+ size_t len;
if (prefixlen < 2)
prefixlen = 2;
- nstore = (char *) alloca (prefixlen + strlen (progname) + 1);
+ len = prefixlen + strlen (progname) + 1;
+#ifdef HAVE_HOST_EXECUTABLE_SUFFIX
+ len += strlen (HOST_EXECUTABLE_SUFFIX);
+#endif
+ nstore = (char *) alloca (len);
startp = endp = temp;
while (1)
@@ -263,7 +271,7 @@
}
else
{
- strncpy (nstore, startp, endp - startp);
+ memcpy (nstore, startp, endp - startp);
if (! IS_DIR_SEPARATOR (endp[-1]))
{
nstore[endp - startp] = DIR_SEPARATOR;
@@ -279,8 +287,14 @@
#endif
)
{
- progname = nstore;
- break;
+#if defined (HAVE_SYS_STAT_H) && defined (S_ISREG)
+ struct stat st;
+ if (stat (nstore, &st) >= 0 && S_ISREG (st.st_mode))
+#endif
+ {
+ progname = nstore;
+ break;
+ }
}
if (*endp == 0)
2012-02-09 Jakub Jelinek
Backported from mainline
2012-01-05 Jakub Jelinek
PR middle-end/51768
* stmt.c (check_unique_operand_names): Don't ICE during error
reporting if i is from labels chain.
* c-c++-common/pr51768.c: New test.
--- gcc/stmt.c (revision 182920)
+++ gcc/stmt.c (revision 182921)
@@ -1253,11 +1253,11 @@ check_operand_nalternatives (tree output
static bool
check_unique_operand_names (tree outputs, tree inputs, tree labels)
{
- tree i, j;
+ tree i, j, i_name = NULL_TREE;
for (i = outputs; i ; i = TREE_CHAIN (i))
{
- tree i_name = TREE_PURPOSE (TREE_PURPOSE (i));
+ i_name = TREE_PURPOSE (TREE_PURPOSE (i));
if (! i_name)
continue;
@@ -1268,7 +1268,7 @@ check_unique_operand_names (tree outputs
for (i = inputs; i ; i = TREE_CHAIN (i))
{
- tree i_name = TREE_PURPOSE (TREE_PURPOSE (i));
+ i_name = TREE_PURPOSE (TREE_PURPOSE (i));
if (! i_name)
continue;
@@ -1282,7 +1282,7 @@ check_unique_operand_names (tree outputs
for (i = labels; i ; i = TREE_CHAIN (i))
{
- tree i_name = TREE_PURPOSE (i);
+ i_name = TREE_PURPOSE (i);
if (! i_name)
continue;
@@ -1297,8 +1297,7 @@ check_unique_operand_names (tree outputs
return true;
failure:
- error ("duplicate asm operand name %qs",
-TREE_STRING_POINTER (TREE_PURPOSE (TREE_PURPOSE (i;
+ error ("duplicate asm operand name %qs", TREE_STRING_POINTER (i_name));
return false;
}
--- gcc/testsuite/c-c++-common/pr51768.c(revision 0)
+++ gcc/testsuite/c-c++-common/pr51768.c(revision 182921)
@@ -0,0 +1,25 @@
+/* PR middle-end/51768 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void
+foo (void)
+{
+ asm goto ("" : : : : lab, lab, lab2, lab); /* { dg-error "duplicate asm
operand name" } */
+lab:;
+lab2:;
+}
+
+void
+bar (void)
+{
+ asm goto ("" : : [lab] "i" (0) : : lab); /* { dg-error "duplicate asm
operand name" } */
+lab:;
+}
+
+void
+baz (void)
+{
+ int x;
+ asm ("" : [lab] "=r" (x) : [lab] "r" (x)); /* { dg-error "duplicate asm
operand name" } */
+}
2012-02-09 Jakub Jelinek
Backported from mainline
2012-01-05 Jakub Jelinek
PR rtl-optimization/51767
* cfgrtl.c (force_nonfallthru_and_redirect): Force addition
of jump_block and add an extra edge for degenerated asm gotos.
* gcc.c-torture/compile/pr51767.c: New test.
--- gcc/cfgrtl.c(revision 182921)
+++ gcc/cfgrtl.c(revision 182922)
@@ -1129,6 +1129,7 @@ force_nonfall
trans-mem: virtual ops for gimple_transaction
> From: rguenth at gcc dot gnu.org
> the __transaction_atomic // SUBCODE=[ GTMA_HAVE_STORE ] statement
> looks like an overly optimistic way to start a transaction in my quick view.
Indeed. At some point this worked, but this may have gotten lost
during one of the merges. Now,
# .MEM_8 = VDEF <.MEM_7(D)>
__transaction_relaxed // SUBCODE=[ ... ]
Bootstrapped and tested on x86_64. Ok?
r~
* tree-ssa-dce.c (propagate_necessity): Handle GIMPLE_TRANSACTION.
* tree-ssa-operands.c (parse_ssa_operands): Add virtual operands
for GIMPLE_TRANSACTION. Tidy if's into a switch.
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index ccdf14a..ace9ef9 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -965,6 +965,13 @@ propagate_necessity (struct edge_list *el)
mark_aliased_reaching_defs_necessary (stmt, op);
}
}
+ else if (gimple_code (stmt) == GIMPLE_TRANSACTION)
+ {
+ /* The beginning of a transaction is a memory barrier. */
+ /* ??? If we were really cool, we'd only be a barrier
+for the memories touched within the transaction. */
+ mark_all_reaching_defs_necessary (stmt);
+ }
else
gcc_unreachable ();
diff --git a/gcc/tree-ssa-operands.c b/gcc/tree-ssa-operands.c
index 0045dd8..ed0d34d 100644
--- a/gcc/tree-ssa-operands.c
+++ b/gcc/tree-ssa-operands.c
@@ -1043,35 +1043,46 @@ static void
parse_ssa_operands (gimple stmt)
{
enum gimple_code code = gimple_code (stmt);
+ size_t i, n, start = 0;
- if (code == GIMPLE_ASM)
-get_asm_expr_operands (stmt);
- else if (is_gimple_debug (stmt))
+ switch (code)
{
+case GIMPLE_ASM:
+ get_asm_expr_operands (stmt);
+ break;
+
+case GIMPLE_TRANSACTION:
+ /* The start of a transaction is a memory barrier. */
+ add_virtual_operand (stmt, opf_def | opf_use);
+ break;
+
+case GIMPLE_DEBUG:
if (gimple_debug_bind_p (stmt)
&& gimple_debug_bind_has_value_p (stmt))
get_expr_operands (stmt, gimple_debug_bind_get_value_ptr (stmt),
opf_use | opf_no_vops);
-}
- else
-{
- size_t i, start = 0;
+ break;
- if (code == GIMPLE_ASSIGN || code == GIMPLE_CALL)
- {
- get_expr_operands (stmt, gimple_op_ptr (stmt, 0), opf_def);
- start = 1;
- }
-
- for (i = start; i < gimple_num_ops (stmt); i++)
- get_expr_operands (stmt, gimple_op_ptr (stmt, i), opf_use);
+case GIMPLE_RETURN:
+ append_vuse (gimple_vop (cfun));
+ goto do_default;
+case GIMPLE_CALL:
/* Add call-clobbered operands, if needed. */
- if (code == GIMPLE_CALL)
- maybe_add_call_vops (stmt);
+ maybe_add_call_vops (stmt);
+ /* FALLTHRU */
- if (code == GIMPLE_RETURN)
- append_vuse (gimple_vop (cfun));
+case GIMPLE_ASSIGN:
+ get_expr_operands (stmt, gimple_op_ptr (stmt, 0), opf_def);
+ start = 1;
+ /* FALLTHRU */
+
+default:
+do_default:
+ n = gimple_num_ops (stmt);
+ for (i = start; i < n; i++)
+ get_expr_operands (stmt, gimple_op_ptr (stmt, i), opf_use);
+ break;
}
}
[v3] libstdc++/51798
This is the rest of 51798, completing the conversion to C++11 atomics in libstdc++. This is now a complete transition, modulo documentation which I plan to finish as a separate patch once I am back from the ISO C++ meeting. tested x86_64/linux -benjamin 2012-02-09 Benjamin Kosnik Jonathan Wakely PR libstdc++/51798 continued. * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Use __atomic_* builtins instead of __sync_* builtins for atomic functionality. * include/bits/shared_ptr_base.h: Same. * include/parallel/compatibility.h: Same. * include/profile/impl/profiler_state.h: Same. * include/tr1/shared_ptr.h: Same. * libsupc++/eh_ptr.cc: Same. * libsupc++/eh_throw.cc: Same. * libsupc++/eh_tm.cc: Same. * libsupc++/guard.cc: Same. * configure: Regenerated. * testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust line numbers. * testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc: Same. diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index 529532e..e089b20 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -2685,7 +2685,7 @@ AC_DEFUN([GLIBCXX_ENABLE_PCH], [ dnl dnl Check for atomic builtins. dnl See: -dnl http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html#Atomic-Builtins +dnl http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html dnl dnl This checks to see if the host supports the compiler-generated dnl builtins for atomic operations for various integral sizes. Note, this @@ -2726,12 +2726,13 @@ AC_DEFUN([GLIBCXX_ENABLE_ATOMIC_BUILTINS], [ [typedef bool atomic_type; atomic_type c1; atomic_type c2; - const atomic_type c3(0); - __sync_fetch_and_add(&c1, c2); - __sync_val_compare_and_swap(&c1, c3, c2); - __sync_lock_test_and_set(&c1, c3); - __sync_lock_release(&c1); - __sync_synchronize();], + atomic_type c3(0); + __atomic_fetch_add(&c1, c2, __ATOMIC_RELAXED); + __atomic_compare_exchange_n(&c1, &c2, c3, true, __ATOMIC_ACQ_REL, + __ATOMIC_RELAXED); + __atomic_test_and_set(&c1, __ATOMIC_RELAXED); + __atomic_load_n(&c1, __ATOMIC_RELAXED); + ], [glibcxx_cv_atomic_bool=yes], [glibcxx_cv_atomic_bool=no]) ]) @@ -2744,12 +2745,13 @@ AC_DEFUN([GLIBCXX_ENABLE_ATOMIC_BUILTINS], [ [typedef short atomic_type; atomic_type c1; atomic_type c2; - const atomic_type c3(0); - __sync_fetch_and_add(&c1, c2); - __sync_val_compare_and_swap(&c1, c3, c2); - __sync_lock_test_and_set(&c1, c3); - __sync_lock_release(&c1); - __sync_synchronize();], + atomic_type c3(0); + __atomic_fetch_add(&c1, c2, __ATOMIC_RELAXED); + __atomic_compare_exchange_n(&c1, &c2, c3, true, __ATOMIC_ACQ_REL, + __ATOMIC_RELAXED); + __atomic_test_and_set(&c1, __ATOMIC_RELAXED); + __atomic_load_n(&c1, __ATOMIC_RELAXED); + ], [glibcxx_cv_atomic_short=yes], [glibcxx_cv_atomic_short=no]) ]) @@ -2762,12 +2764,13 @@ AC_DEFUN([GLIBCXX_ENABLE_ATOMIC_BUILTINS], [ [typedef int atomic_type; atomic_type c1; atomic_type c2; - const atomic_type c3(0); - __sync_fetch_and_add(&c1, c2); - __sync_val_compare_and_swap(&c1, c3, c2); - __sync_lock_test_and_set(&c1, c3); - __sync_lock_release(&c1); - __sync_synchronize();], + atomic_type c3(0); + __atomic_fetch_add(&c1, c2, __ATOMIC_RELAXED); + __atomic_compare_exchange_n(&c1, &c2, c3, true, __ATOMIC_ACQ_REL, + __ATOMIC_RELAXED); + __atomic_test_and_set(&c1, __ATOMIC_RELAXED); + __atomic_load_n(&c1, __ATOMIC_RELAXED); + ], [glibcxx_cv_atomic_int=yes], [glibcxx_cv_atomic_int=no]) ]) @@ -2780,12 +2783,13 @@ AC_DEFUN([GLIBCXX_ENABLE_ATOMIC_BUILTINS], [ [typedef long long atomic_type; atomic_type c1; atomic_type c2; - const atomic_type c3(0); - __sync_fetch_and_add(&c1, c2); - __sync_val_compare_and_swap(&c1, c3, c2); - __sync_lock_test_and_set(&c1, c3); - __sync_lock_release(&c1); - __sync_synchronize();], + atomic_type c3(0); + __atomic_fetch_add(&c1, c2, __ATOMIC_RELAXED); + __atomic_compare_exchange_n(&c1, &c2, c3, true, __ATOMIC_ACQ_REL, + __ATOMIC_RELAXED); + __atomic_test_and_set(&c1, __ATOMIC_RELAXED); + __atomic_load_n(&c1, __ATOMIC_RELAXED); + ], [glibcxx_cv_atomic_long_long=yes], [glibcxx_cv_atomic_long_long=no]) ]) @@ -2807,12 +2811,13 @@ int main() typedef bool atomic_type; atomic_type c1; atomic_type c2; - const atomic_type c3(0); - __sync_fetch_and_add(&c1, c2); - __sync_val_compare_and_swap(&c1, c3, c2); - __sync_lock_test_and_set(&c1, c3); - __sync_lock_release(&c1); - __sync_synchronize(); + atomic_type c3(0); + __atomic_fetch_add(&c1, c
[PATCH, rtl-optimization]: Fix post-reload compare elimination pre-pass
Hello!
I am trying to enable post-reload compare elimination pass on x86, and
I discovered a problem in the way redundant compares are eliminated.
The problem lies in the assumption that:
(1) All comparison patterns are represented as
[(set (reg:CC) (compare:CC (reg) (immediate)))]
which is not true for x86 or any target which exposes FLAGS_REG early
and defines SELECT_CC_MODE.
Following testcase:
--cut here--
int test (int a, int b)
{
int lt = a + b < 0;
int eq = a + b == 0;
if (lt)
return 1;
return eq;
}
--cut here--
compiles to the following dump before entering post-reload compare
elimination pass:
(insn 8 4 9 2 (parallel [
(set (reg:SI 4 si [orig:60 D.1710 ] [60])
(plus:SI (reg/v:SI 5 di [orig:63 a ] [63])
(reg/v:SI 4 si [orig:64 b ] [64])))
(clobber (reg:CC 17 flags))
]) cmp.c:3 253 {*addsi_1}
(nil))
(insn 9 8 10 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 4 si [orig:60 D.1710 ] [60])
(const_int 0 [0]))) cmp.c:4 2 {*cmpsi_ccno_1}
(nil))
(note 10 9 33 2 NOTE_INSN_DELETED)
(insn 33 10 34 2 (set (reg:QI 1 dx [65])
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) cmp.c:4 595 {*setcc_qi}
(nil))
(insn 34 33 30 2 (set (reg:SI 1 dx [65])
(zero_extend:SI (reg:QI 1 dx [65]))) cmp.c:4 123
{*zero_extendqisi2_movzbl}
(nil))
(insn 30 34 29 2 (set (reg/v:SI 0 ax [orig:59 eq ] [59])
(const_int 1 [0x1])) cmp.c:6 64 {*movsi_internal}
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)))
(insn 29 30 31 2 (set (reg:CCGOC 17 flags)
(compare:CCGOC (reg:SI 4 si [orig:60 D.1710 ] [60])
(const_int 0 [0]))) cmp.c:6 2 {*cmpsi_ccno_1}
(nil))
(insn 31 29 25 2 (set (reg/v:SI 0 ax [orig:59 eq ] [59])
(if_then_else:SI (ge (reg:CCGOC 17 flags)
(const_int 0 [0]))
(reg:SI 1 dx [65])
(reg/v:SI 0 ax [orig:59 eq ] [59]))) cmp.c:6 903 {*movsicc_noc}
(nil))
The redundant-compare elimination pre-pass blindly eliminates (insn
29) from the sequence. The elimination is done without updating the
compare mode in (insn 9)! The correct approach would be to also update
the compare mode of (insn 9) to the mode of
targetm.cc_modes_compatible target hook, which in the case abowe would
be (CCZmode, CCGOCmode) -> CCGOCmode.
Attached patch fixes this problem by checking for mode compatibility
of redundant compare with previous compare before elimination, and
sets the mode of previous compare to mode, compatible with both
compares.
2012-02-10 Uros Bizjak
* compare-elim.c (find_comparisons_in_bb): Eliminate only compares
having mode compatible with the mode of previous compare. Substitute
compare mode of previous compare with the mode, compatible
with eliminated and previous compare.
Patch was bootstrapped and regression tested with additional x86
specific patch that enables post-reload compare eliminations on
x86_64-pc-linux-gnu {,-m32}. The complete patch is attached to this
message.
Is RTL optimisation part of the patch OK for mainline SVN and 4.6 ?
Uros.
Index: compare-elim.c
===
--- compare-elim.c (revision 184067)
+++ compare-elim.c (working copy)
@@ -297,11 +297,36 @@ find_comparisons_in_bb (struct dom_walk_data *data
src = conforming_compare (insn);
if (src)
{
+ enum machine_mode src_mode = GET_MODE (src);
+
/* Eliminate a compare that's redundant with the previous. */
if (last_cmp_valid
&& rtx_equal_p (last_cmp->in_a, XEXP (src, 0))
&& rtx_equal_p (last_cmp->in_b, XEXP (src, 1)))
{
+ rtx flags, x;
+ enum machine_mode new_mode
+ = targetm.cc_modes_compatible (last_cmp->orig_mode, src_mode);
+
+ /* New mode is incompatible with the previous compare mode. */
+ if (new_mode == VOIDmode)
+ continue;
+
+ if (new_mode != last_cmp->orig_mode)
+ {
+ flags = gen_rtx_REG (src_mode, targetm.flags_regnum);
+
+ /* Generate new comparison for substitution. */
+ x = gen_rtx_COMPARE (new_mode, XEXP (src, 0), XEXP (src, 1));
+ x = gen_rtx_SET (VOIDmode, flags, x);
+
+ if (!validate_change (last_cmp->insn,
+ &PATTERN (last_cmp->insn), x, false))
+ continue;
+
+ last_cmp->orig_mode = new_mode;
+ }
+
delete_insn (insn);
continue;
}
@@ -311,7 +336,7 @@ find_comparisons_in_bb (struct dom_walk_data *data
last_cmp->prev_clobber = last_clobber;
last_cmp->in_a = XEXP (src, 0);
last_cmp->in_b = XEXP (src, 1);
- last_cmp->orig_mode = GET_MODE (SET_DEST (single_set (insn)));
+ last_cmp->orig_
Re: trans-mem: virtual ops for gimple_transaction
On Thu, 2012-02-09 at 15:05 -0800, Richard Henderson wrote: > + /* The beginning of a transaction is a memory barrier. > */ > + /* ??? If we were really cool, we'd only be a barrier > +for the memories touched within the transaction. */ Why? I'm not quite sure what kind of memory barrier you mean here, but a transaction can synchronize with other transactions and thus should be a barrier for all memory accesses, or not? We could move safe code into it, but not out of it or across it. We could perhaps move transaction_pure code across it, or out of it, IIRC. Torvald
Re: Go patch committed: Provide matherr function
Rainer Orth writes:
> I could give it a try once the current bootstraps are finished. For the
> moment I've shamelessly adapted the following from the __GNUC__ section
> of Solaris 11 :
I committed this patch which ought to work.
Bootstrapped and ran Go testsuite on i386-pc-solaris2.11.
Ian
Index: libgo/runtime/go-matherr.c
===
--- libgo/runtime/go-matherr.c (revision 184024)
+++ libgo/runtime/go-matherr.c (working copy)
@@ -35,7 +35,7 @@ matherr (struct exception* e)
n = e->name;
if (__builtin_strcmp (n, "acos") == 0
|| __builtin_strcmp (n, "asin") == 0)
-e->retval = NAN;
+e->retval = __builtin_nan ("");
else if (__builtin_strcmp (n, "atan2") == 0)
{
if (e->arg1 == 0 && e->arg2 == 0)
@@ -53,11 +53,11 @@ matherr (struct exception* e)
}
else if (__builtin_strcmp (n, "log") == 0
|| __builtin_strcmp (n, "log10") == 0)
-e->retval = NAN;
+e->retval = __builtin_nan ("");
else if (__builtin_strcmp (n, "pow") == 0)
{
if (e->arg1 < 0)
- e->retval = NAN;
+ e->retval = __builtin_nan ("");
else if (e->arg1 == 0 && e->arg2 == 0)
e->retval = 1.0;
else if (e->arg1 == 0 && e->arg2 < 0)
@@ -65,9 +65,9 @@ matherr (struct exception* e)
double i;
if (modf (e->arg2, &i) == 0 && ((int64_t) i & 1) == 1)
- e->retval = copysign (INFINITY, e->arg1);
+ e->retval = copysign (__builtin_inf (), e->arg1);
else
- e->retval = INFINITY;
+ e->retval = __builtin_inf ();
}
else
return 0;
@@ -75,7 +75,7 @@ matherr (struct exception* e)
else if (__builtin_strcmp (n, "sqrt") == 0)
{
if (e->arg1 < 0)
- e->retval = NAN;
+ e->retval = __builtin_nan ("");
else
return 0;
}
[arm-embedded] Backport mainline r183733
Hi, Backport mainline r183733 to ARM/embedded-4_6-branch. The patch is already in gcc-4_6-branch, now commit to ARM/embedded-4_6-branch. gcc/ChangeLog.arm 2012-02-10 Bin Cheng Backport from mainline. 2012-01-30 Bin Cheng PR target/51835 * config/arm/arm.c (arm_libcall_uses_aapcs_base): Use correct ABI for __aeabi_d2iz/__aeabi_d2uiz with hard-float. gcc/testsuite/ChangeLog.arm 2012-02-10 Bin Cheng Backport from mainline. 2012-01-30 Bin Cheng PR target/51835 * gcc.target/arm/pr51835.c: New testcase.
Re: [PATCH] Fix sibcall argument overlap checking if pretend_args_size (PR target/52129)
On Thu, Feb 9, 2012 at 12:54 AM, Carrot Wei wrote:
> Hi Richard and Jakub
>
> Since 4.6 contains the same bug, I would like to back port it to 4.6
> branch. Could you approve it for 4.6?
>
> Jing and Doug
>
> Could you approve it for google/gcc-4_6-mobile branch?
>
OK for google/gcc-4_6-mobile and gcc-4_6_2-mobile
Jing
> thanks
> Carrot
>
> On Mon, Feb 6, 2012 at 9:14 PM, Richard Guenther
> wrote:
>> On Mon, Feb 6, 2012 at 2:01 PM, Jakub Jelinek wrote:
>>> Hi!
>>>
>>> The attached testcase is miscompiled on arm*, by doing a sibcall when setup
>>> of one argument overwrites incoming arguments used to setup parameters in
>>> later insns.
>>> The reason why
>>> mem_overlaps_already_clobbered_arg_p/check_sibcall_argument_overlap
>>> fails to detect is that the caller has non-zero
>>> crtl->args.pretend_args_size, and in that case the base:
>>> /* The argument block when performing a sibling call is the
>>> incoming argument block. */
>>> if (pass == 0)
>>> {
>>> argblock = crtl->args.internal_arg_pointer;
>>> argblock
>>> #ifdef STACK_GROWS_DOWNWARD
>>> = plus_constant (argblock, crtl->args.pretend_args_size);
>>> #else
>>> = plus_constant (argblock, -crtl->args.pretend_args_size);
>>> #endif
>>> stored_args_map = sbitmap_alloc (args_size.constant);
>>> sbitmap_zero (stored_args_map);
>>> }
>>> apparently isn't virtual-incoming-rtx, but that plus pretend_args_size
>>> (8 in this case). When we store bits into stored_args_map sbitmap,
>>> we use arg->locate.slot_offset.constant based values (or something different
>>> for ARGS_GROW_DOWNWARD, but when mem_overlaps_already_clobbered_arg_p is
>>> testing those bits, it uses just virtual-incoming-rtx offsets (or something
>>> different for ARGS_GROW_DOWNWARD). This patch fixes it by adjusting the
>>> virtual-incoming-rtx relative offset to be actually argblock relative
>>> offset.
>>>
>>> Bootstrapped/regtested on x86_64-linux and i686-linux and tested on the
>>> testcase on arm cross. Ok for trunk?
>>
>> Ok.
>>
>> Thanks,
>> Richard.
>>
>>> 2012-02-06 Jakub Jelinek
>>>
>>> PR target/52129
>>> * calls.c (mem_overlaps_already_clobbered_arg_p): If val is
>>> CONST_INT_P, subtract resp. add crtl->args.pretend_args_size to it.
>>>
>>> * gcc.c-torture/execute/pr52129.c: New test.
>>>
>>> --- gcc/calls.c.jj 2012-02-01 14:44:27.0 +0100
>>> +++ gcc/calls.c 2012-02-06 10:19:12.112132905 +0100
>>> @@ -1808,6 +1808,11 @@ mem_overlaps_already_clobbered_arg_p (rt
>>> return true;
>>> else
>>> i = INTVAL (val);
>>> +#ifdef STACK_GROWS_DOWNWARD
>>> + i -= crtl->args.pretend_args_size;
>>> +#else
>>> + i += crtl->args.pretend_args_size;
>>> +#endif
>>>
>>> #ifdef ARGS_GROW_DOWNWARD
>>> i = -i - size;
>>> --- gcc/testsuite/gcc.c-torture/execute/pr52129.c.jj 2012-02-06
>>> 10:27:50.988876791 +0100
>>> +++ gcc/testsuite/gcc.c-torture/execute/pr52129.c 2012-02-06
>>> 10:25:26.0 +0100
>>> @@ -0,0 +1,28 @@
>>> +/* PR target/52129 */
>>> +
>>> +extern void abort (void);
>>> +struct S { void *p; unsigned int q; };
>>> +struct T { char a[64]; char b[64]; } t;
>>> +
>>> +__attribute__((noinline, noclone)) int
>>> +foo (void *x, struct S s, void *y, void *z)
>>> +{
>>> + if (x != &t.a[2] || s.p != &t.b[5] || s.q != 27 || y != &t.a[17] || z !=
>>> &t.b[17])
>>> + abort ();
>>> + return 29;
>>> +}
>>> +
>>> +__attribute__((noinline, noclone)) int
>>> +bar (void *x, void *y, void *z, struct S s, int t, struct T *u)
>>> +{
>>> + return foo (x, s, &u->a[t], &u->b[t]);
>>> +}
>>> +
>>> +int
>>> +main ()
>>> +{
>>> + struct S s = { &t.b[5], 27 };
>>> + if (bar (&t.a[2], (void *) 0, (void *) 0, s, 17, &t) != 29)
>>> + abort ();
>>> + return 0;
>>> +}
>>>
>>> Jakub
