[PING] 3 patches waiting for approval/review
[RFC] Allow functions calling mcount before prologue to be leaf functions http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00993.html [PATCH] PR57377: Fix mnemonic attribute http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01364.html [PATCH] Doc: Add documentation for the mnemonic attribute http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01436.html Bye, -Andreas-
[PATCH] Fix portability issue in gcc.dg/pr57287-2.c
I should have changed the testcase to use setjmp. Done now,
tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-09-03 Richard Biener
PR middle-end/57287
* gcc.dg/pr57287-2.c: Use setjmp, not __sigsetjmp.
Index: gcc/testsuite/gcc.dg/pr57287-2.c
===
--- gcc/testsuite/gcc.dg/pr57287-2.c(revision 202170)
+++ gcc/testsuite/gcc.dg/pr57287-2.c(working copy)
@@ -12,7 +12,7 @@ struct node
struct node *list;
struct node *head (void);
-sigjmp_buf *bar (void);
+jmp_buf *bar (void);
int baz (void)
{
@@ -25,8 +25,8 @@ int baz (void)
if (!varseen)
varseen = 1;
- sigjmp_buf *buf = bar (); /* { dg-bogus "may be used uninitialized" ""
} */
- __sigsetjmp (*buf, 1);
+ jmp_buf *buf = bar (); /* { dg-bogus "may be used uninitialized" "" } */
+ setjmp (*buf);
}
if (!varseen)
Re: Symtab cleanup 10/17 remove unnecesary DECL_ARGUMENTS and DECL_RESULT
On Mon, Sep 2, 2013 at 5:19 PM, Jan Hubicka wrote: >> >> But we still refer to the local entity from TREE_TYPE of the function decl, >> no? > > depending on definition of local entity. I tought we was discussing if > PARM_DECL > is local or not. > > I spent some time thining about the whole streaming scheme and I think we do > have > important side cases handled incorrectly. Lets try to discuss things. I > will try > to summarize my understanding to make sure we are on sync and I do not miss > something > important. > > So we now have two types of streams > - the global stream > this stream is one per compilation unit and it gets load into WPA > and merged with other streams by tree mergina and LTO-symtab resolution. > - local stream. > this stream is local for function (and hope for variable initializer > soon, too), > it is read when we need the function body and it is not in any way merged > with > global stream, except that the references to global streams are resolved > after merging > > We do have way to express references from local stream to global stream. We > however > can not express > A) references from global stream to local stream > B) references in between two different local streams. Correct. > The decision what should go to local or global stream is basically motivated > by > 1) everything needed for interprocedural optimization has to be global > 2) everything related to function bodies should be local. I'd rather formulate it as "everything not needed at WPA time should be local if it can be local" > For tree nodes, the decision about where the node goes is made by > tree_is_indexable. The current set of rules is > - parm_decl/result_decl is local >(before my change resut_decl was global and parm_decl was local, why those > was not the same escapes me, but it needed ugly fixup in ipa-prop that > needed to reconnect global DECL pointers to local DECL pointers after > streaming in) > - function variables are local if they are not static. >(Even external declarations are local, not only automatic vars.) > - Types are global unless they are variably modified types >(The variably modified type code walks into subtypes, so even pointers >to variably modified type are local or function declarations mentioning >these.) > - FIELD_DECL is global unless it is part of variably modified type. > - SSA_NAME is local despite logic of tree_is_indexable because it is handled >separately as part of gimple and gimple is always local. > - LABEL_DECLs are global even when their address is not taken and it would > make >more sense to hide it in the body sections > > Now I think we are safe only when our references never violate A) and B) and > moreover > C) same entity that needs to be unique (such as declarations by one decl rule >or BLOCK) is not streamed into multiple streams. We never merge things >between streams and duplicating those is forbidden by design. > > It is an irritating property of our streaming machinery that it is not > diagnozing violations of A/B/C. Violations of type A and B are basically > hidden > by introducing violations of type C and compiler tends to be resistant to > those > in a sense that is usually does not ICE. Yes, and with the re-organized streaming we can now do much better and much faster! This is because with the SCC finding we can record in O(SCC size) whether a) the SCC contains entities that are local (and to what function) or global, b) the SCC refers to other SCCs that are local (and in what function) We can then detect whether we run into the situation that the new SCC refers to SCCs that are in different local sections (which would mean those SCCs in turn would need to be globalized or that the current SCC needs to be duplicated into all local sections it refers to). I would not be surprised if our current tree structures, when strictly following restrictions A) and B) would need to be either all global or all duplicated into the local sections :/ At least we can now more easily formalize this (and can compute "scc_is_indexable" which is the property we need now) > Now I only once added sanity check for C and larnt that > > 1) variably sized types may end up being twice - in global stream because > they are > mentioned by FUNCTION_DECL/VARIABLE_DECL or TYPE_DECL > and local stream because of tree_is_indexable rule > > Moreover they violate A after landing in global stream because they refer > to temporaries in the gimple body. > As you mentioned, we may want to clear TYPE_SIZE and variable > DECL_FIELD_OFFSET. > But sadly I think dwarf2out needs both and gimple land needs > DECL_FIELD_OFFSET. > 2) TYPE_DECLS of local types (common in C++) tends to drag into global stream > BLOCK that later brings to global stream the local variables. > > Making function local TYPE_DECLs local seems cool, but it break A because >
Re: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets
On Mon, Sep 2, 2013 at 6:05 PM, Joseph S. Myers wrote: > On Mon, 2 Sep 2013, Richard Earnshaw wrote: > >> On 01/09/13 14:10, Bernd Edlinger wrote: >> > IMHO the AAPCS forbids packed structures. Therefore we need not >> > interfere with the C++ memory model if we have unaligned data. >> >> The AAPCS neither forbids nor requires packed structures. They're a GNU >> extension and as such not part of standard C++. Thus the semantics of >> such an operation are irrelavant to the AAPCS: you get to chose what the >> behaviour is in this case... > > The trouble is that AAPCS semantics are incompatible with the default GNU > semantics for non-packed structures as well - AAPCS > strict-volatile-bitfields is only compatible with --param > allow-store-data-races=1, which is not the default for any language > variant accepted by GCC (and I say that the default language semantics > here should not depend on the target architecture). As I said it should be easy to fulfil AAPCS requirements if they do not violate language constrains during code generation and thus warn about accesses that are emitted in a way not conforming to AAPCS (a warning at struct declaration time would be nicer, but I guess requires more coding and thought, though at the point we compute DECL_BIT_FIELD_REPRESENTATIVE in stor-layout.c would be a suitable place). Richard. > -- > Joseph S. Myers > jos...@codesourcery.com
Re: [PATCH] Fix PR tree-optimization/58137
On Mon, Sep 2, 2013 at 8:53 PM, Bernd Edlinger wrote: > On Fri, 30 Aug 2013 12:34:51 Richard Biener wrote: >> On Tue, Aug 20, 2013 at 1:01 PM, Bernd Edlinger >> wrote: >>> This patch fixes a bug in the vectorized pointer arithmetic in the forwprop >>> optimization pass. >>> >>> Although it seems to be impossible to create a vector of pointers with the >>> __attribute__((vector_size(x))) syntax, the vector loop optimization >>> together >>> with the loop unrolling can create code which adds a vector of ptroff_t >>> repeatedly to a vector of pointers. >>> >>> The code in tree-ssa-forwprop.c handles program transformations of the >>> form (PTR +- CST1) +- CST2 => PTR +- (CST1+-CST2) where PTR is >>> a vector of pointers and CST1 and CST2 are vectors of ptroff_t, without the >>> fix the result type of CST1+-CST2 was vector of pointer, which causes the >>> ICE in tree-cfg.c, which sees an undefined pointer + pointer operation. >>> >>> Additionally the check in tree-cfg.c allows expressions of the form CST - >>> PTR, >>> which is clearly wrong. That should be fixed too. >>> >>> The patch was bootstrapped and regression tested on i686-pc-linux-gnu. >> >> It seems to me that the forwprop code does not handle the fact that we >> are permissive as to using PLUS_EXPR instead of POINTER_PLUS_EXPR >> for vector pointer - offset additions. So instead of doing this dance the >> better (and more easily backportable) fix is to simply disable the transform >> on pointer valued PLUS_EXPR. Like with >> >> if (POINTER_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt >> return false; >> >> at the beginning of the function. >> > > the condition would have to be: > > if (TREE_CODE (TREE_TYPE (gimple_assign_lhs (stmt))) == VECTOR_TYPE > && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (gimple_assign_lhs (stmt) > return false; > > I tried this, and it fixes the ICE. However the generated code was still > vectorized but > much less efficient and used more registers. > > Fortunately there will be no need to backport this, since this bug does not > happen in > gcc 4.8.2 I checked that. I believe it was introduced with the checkin > r200059 by > Marc Glisse where associate_plusminus was enhanced to handle vector values. > Before that only TREE_CODE (rhs2) == INTEGER_CST was handled. > > Frankly I would prefer the initial version of the patch, because the code is > more > efficient this way. The vector data is folded correctly, only the data type > was wrong > and triggered the ICE in tree-cfg.c. > > Please advise. I'd rather go with the simple fix as the issue in forwprop is at least latent. We can improve on the code-gen as followup where I believe handling of POINTER_PLUS_EXPR would need to be added (that we avoid POINTER_PLUS_EXPR for vectors is a bug). That can be done in a way to cover the vector case properly. Or finally properly use POINTER_PLUS_EXPR for vectors or make the vectorizer not use pointer types but a corresponding unsigned integer type for them (that would also fix the original bug of course). Like with (untested) Index: gcc/tree-vect-stmts.c === --- gcc/tree-vect-stmts.c (revision 202196) +++ gcc/tree-vect-stmts.c (working copy) @@ -6179,8 +6179,7 @@ get_vectype_for_scalar_type_and_size (tr corresponding to that mode. The theory is that any use that would cause problems with this will disable vectorization anyway. */ else if (!SCALAR_FLOAT_TYPE_P (scalar_type) - && !INTEGRAL_TYPE_P (scalar_type) - && !POINTER_TYPE_P (scalar_type)) + && !INTEGRAL_TYPE_P (scalar_type)) scalar_type = lang_hooks.types.type_for_mode (inner_mode, 1); /* We can't build a vector type of elements with alignment bigger than actually that would be my preference here ... Thanks, Richard. > Thanks > Bernd. > >> The real fix is of course to make vector pointer operations properly >> use POINTER_PLUS_EXPR ... >> >> Richard. >> >> >> >>> Regards >>> Bernd Edlinger
Re: [PATCH] Portable Volatility Warning
On Tue, Sep 3, 2013 at 2:05 AM, Bernd Edlinger
wrote:
> This is a follow-up patch for Sandra Loosemore's patch in this
> thread: "reimplement -fstrict-volatile-bitfields, v3".
> It was already posted a few weeks ago, but in the wrong thread.
> Therfore I re-post it herewith.
> It was initially suggested by Hans-Peter Nilsson, and I had much
> help from him in putting everything together. Thanks again H-P.
> Here is a short specification:
> The -Wportable-volatility warning is an optional warning, to warn
> about code for which separate incompatbile definitions on different
> platforms (or between C and C++) exist even within gcc.
> It will be usable for driver code you want to be portable on different
> architectures.
> This warning should only be emitted if the code is significantly
> different when -fstrict-volatile-bitfields is used or not.
> It should not be emitted for the code which is not affected by this
> option.
> In other words, it should be emitted on all bit-fields when the
> definition or the context is volatile, except when the whole
> structure is not AAPCS ABI compliant, i.e. packed or unaligned.
> On the other hand you should always get the same
> warnings if you combine -Wportable-volatility with
> -fstrict-volatile-bitfields or not. And of course it should not
> depend on the specific target that is used to compile.
> I boot-strapped this on a i686-pc-linux-gnu and all Wportable-volatility
> test cases are passed for C and C++.
> I used a cross-compiler for arm-eabi to manually cross-check that
> the warnings are independent of the target platform.
Just a quick first note:
@@ -3470,6 +3470,13 @@ optimize_bit_field_compare (location_t l
|| offset != 0 || TREE_CODE (linner) == PLACEHOLDER_EXPR)
return 0;
+ /* Do not try to optimize on volatiles, as it would defeat the
+ -Wportable-volatility warning later:
+ If the COMPONENT_REF is replaced by a BIT_FIELD_REF we loose
+ information and thus the warning cannot be generated correctly. */
+ if (warn_portable_volatility && lvolatilep)
+return 0;
changing code-generation with a warning option looks wrong to me. Note
that I completely removed this code once (it also generates strange
BIT_FIELD_REFs) but re-instantiated it on request because of lost
optimizations.
Similar for
@@ -609,11 +609,14 @@ layout_decl (tree decl, unsigned int kno
occupying a complete byte or bytes on proper boundary,
and not -fstrict-volatile-bitfields. If the latter is set,
we unfortunately can't check TREE_THIS_VOLATILE, as a cast
- may make a volatile object later. */
+ may make a volatile object later.
+ Handle -Wportable-volatility analogous, as we would loose
+ information and defeat the warning later. */
if (TYPE_SIZE (type) != 0
&& TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
&& GET_MODE_CLASS (TYPE_MODE (type)) == MODE_INT
- && flag_strict_volatile_bitfields <= 0)
+ && flag_strict_volatile_bitfields <= 0
+ && warn_portable_volatility == 0)
{
enum machine_mode xmode
= mode_for_size_tree (DECL_SIZE (decl), MODE_INT, 1);
I also wonder about "we unfortunately can't check TREE_THIS_VOLATILE, as a cast
may make a volatile object later." - does that mean that AAPCS requires
struct X { int x : 8; char c; };
void foo (struct X *p)
{
((volatile struct X *)p)->x = 1;
}
to be treated as volatile bitfield access? Similar, is
volatile struct X x;
x.x = 1;
a volatile bitifled access?
I think the warning can be completely implemented inside struct-layout.c
for example in finish_bitfield_representative (if you pass that the first field
in the group, too). Of course that is at the expense of warning for
struct declarations rather than actual code differences (the struct may
not be used)
Richard.
> Regards
> Bernd Edlinger
[PATCH] S/390: Use fast BCR serialization facility.
Hi,
since z196 we have the fast-BCR-serialization facility. With this
facility a faster synchronization primitive is provided which is
sufficient for all our cases. In fact the compare and swap atomic
operations use the very same mechanism.
With this patch we always use the new variant on z196 and later.
The bcr variants used for synchronization purposes always go into
their own dispatch group. This wasn't correctly implemented for z196
and zEC12 so far.
I'll commit the patch after regression tests passed.
Bye,
-Andreas-
2013-09-03 Andreas Krebbel
* config/s390/s390.md: Add "bcr_flush" value to mnemonic
attribute.
("mem_thread_fence_1"): Use bcr 14,0 for z196 and later.
Set the mnemonic attribute to "bcr_flush". Set the "z196prop"
attribute to "z196_alone".
* config/s390/2827.md: Add "bcr_flush" to "ooo_groupalone" and
"zEC12_simple".
---
gcc/config/s390/2827.md |4
gcc/config/s390/s390.md | 16 +++!
2 files changed, 3 insertions(+), 17 modifications(!)
Index: gcc/config/s390/s390.md
===
*** gcc/config/s390/s390.md.orig
--- gcc/config/s390/s390.md
***
*** 291,297
z196_cracked"
(const_string "none"))
! (define_attr "mnemonic" "unknown" (const_string "unknown"))
;; Length in bytes.
--- 291,297
z196_cracked"
(const_string "none"))
! (define_attr "mnemonic" "bcr_flush,unknown" (const_string "unknown"))
;; Length in bytes.
***
*** 9007,9018
; Although bcr is superscalar on Z10, this variant will never
; become part of an execution group.
(define_insn "mem_thread_fence_1"
[(set (match_operand:BLK 0 "" "")
(unspec:BLK [(match_dup 0)] UNSPEC_MB))]
""
! "bcr\t15,0"
! [(set_attr "op_type" "RR")])
;
; atomic load/store operations
--- 9007,9028
; Although bcr is superscalar on Z10, this variant will never
; become part of an execution group.
+ ; With z196 we can make use of the fast-BCR-serialization facility.
+ ; This allows for a slightly faster sync which is sufficient for our
+ ; purposes.
(define_insn "mem_thread_fence_1"
[(set (match_operand:BLK 0 "" "")
(unspec:BLK [(match_dup 0)] UNSPEC_MB))]
""
! {
! if (TARGET_Z196)
! return "bcr\t14,0";
! else
! return "bcr\t15,0";
! }
! [(set_attr "op_type" "RR")
!(set_attr "mnemonic" "bcr_flush")
!(set_attr "z196prop" "z196_alone")])
;
; atomic load/store operations
Index: gcc/config/s390/2827.md
===
*** gcc/config/s390/2827.md.orig
--- gcc/config/s390/2827.md
***
*** 32,43
(const_int 0)))
(define_attr "ooo_groupalone" ""
! (cond [(eq_attr "mnemonic"
"lnxbr,madb,ltxtr,clc,axtr,msebr,slbgr,xc,alcr,lpxbr,slbr,maebr,mlg,mfy,lxdtr,maeb,lxeb,nc,mxtr,sxtr,dxbr,alc,msdbr,ltxbr,lxdb,madbr,lxdbr,lxebr,mvc,m,mseb,mlr,mlgr,slb,tcxb,msdb,sqxbr,alcgr,oc,flogr,alcg,mxbr,dxtr,axbr,mr,sxbr,slbg,ml,lcxbr")
(const_int 1)]
(const_int 0)))
(define_insn_reservation "zEC12_simple" 1
(and (eq_attr "cpu" "zEC12")
!(eq_attr "mnemonic"
"ltg,ogrk,lr,lnebr,lghrl,sdbr,x,asi,lhr,sebr,madb,ar,lhrl,clfxtr,llgfr,clghrl,cgr,cli,agrk,ic,adbr,aebr,lrv,clg,cy,cghi,sy,celfbr,seb,clgfr,al,tm,lang,clfebr,lghr,cdb,lpebr,laa,ark,lh,or,icy,xi,msebr,n,llihl,afi,cs,nrk,sth,lgr,l,lcr,stey,xg,crt,slgfr,ny,ld,j,llihh,slgr,clfhsi,slg,lb,lgrl,lrl,llihf,lndbr,llcr,laxg,mvghi,rllg,sdb,xrk,laag,alhsik,algfi,algr,aly,agfi,lrvr,d,crl,llgc,tmhl,algsi,lgh,icmh,clhrl,xgrk,icm,iilf,ork,lbr,cg,ldgr,lgf,iihf,llghr,sg,clfdbr,llgtr,stam,cebr,tmhh,tceb,slgf,basr,lgbr,maebr,lgb,cgfi,aeb,ltebr,lax,clfit,lrvgr,nihl,ni,clfdtr,srdl,mdb,srk,xihf,stgrl,sthrl,algf,ltr,cdlgbr,cgit,ng,lat,llghrl,ltgr,nihh,clgfrl,srlk,maeb,agr,cxlftr,ler,bcr,stcy,cds,clfi,nihf,ly,clt,lgat,alg,lhy,lgfrl,clghsi,clrt,tmll,srlg,tcdb,ay,sty,clr,lgfi,lan,lpdbr,clgt,adb,ahik,sra,algrk,cdfbr,lcebr,clfxbr,msdbr,ceb,clgr,tmy,tmlh,alghsik,lcgr,mvi,cdbr,ltgf,xr,larl,ldr,llgcr,clgrt,clrl,cghsi,cliy,madbr,oy,ogr,llgt,meebr,slr,clgxbr,chi,s,icmy,llc,ngr,clhhsi,ltgfr,llill,lhi,o,meeb,clgdtr,sll,clgrl,clgf,ledbr,cegbr,mviy,algfr,rll,cdlftr,sldl,cdlgtr,lg,niy,st,sgr,ag,le,xgr,cr,stg,llilh,sr,lzer,cdsg,sllk,mdbr,stoc,csg,clgit,chhsi,strl,llilf,lndfr,ngrk,clgebr,clgfi,llgh,mseb,ltdbr,oill,la,llhrl,stc,lghi,oihl,xiy,sllg,llgf,cgrt,ldeb,cl,sl,cdlfbr,oi,oilh,nr,srak,oihh,ear,slgrk,og,c,slgfi,sthy,oilf,oiy,msdb,oihf,a,cfi,lzxr,lzdr,srag,cdgbr,brasl,alr,cgrl,llgfrl,cit,clgxtr,ley,exrl,lcdfr,lay,xilf,lcdbr,alsi,mvhhi,srl,chsi,lgfr,lrvg,cly,sgrk,ahi,celgbr,nill,clgdbr,jg,slrk,lxr,sar,slfi,cpsdr,lcgfr,aghik,nilh,mvhi,lpdfr,xy,alrk,lao,agsi,ldy,nilf,llhr,alfi,laog,sly,aghi,ldebr,bras,srda,cefbr,lt"))
"nothing")
(define_insn_reservation "zEC12_cgdbr" 2
(and (eq_
[PATCH] S/390: Add support for the "load fp integer" instructions
Hi,
the attached patch implements pattern definitions for the nearest
integer functions for binary and decimal floating point. Since z196
we have "load fp integer" instructions which allow suppression of the
inexact exception. These provide a 1:1 mapping to several of the
standard math.h functions.
The DFP variants are not yet expanded for the standard math function
since the necessary GCC builtins are missing so far.
I'll commit the patch after waiting for comments and regression test.
Bye,
-Andreas-
2013-09-03 Andreas Krebbel
* config/s390/s390.md (UNSPEC_FPINT_FLOOR, UNSPEC_FPINT_BTRUNC)
(UNSPEC_FPINT_ROUND, UNSPEC_FPINT_CEIL, UNSPEC_FPINT_NEARBYINT)
(UNSPEC_FPINT_RINT): New constant definitions.
(FPINT, fpint_name, fpint_roundingmode): New integer iterator
definition with 2 attributes.
("2", "rint2")
("2", "rint2"): New pattern
definitions.
2013-09-03 Andreas Krebbel
* gcc.target/s390/nearestint-1.c: New testcase.
---
gcc/config/s390/2827.md | 21 ++!
gcc/config/s390/s390.md | 78 ++!
gcc/testsuite/gcc.target/s390/nearestint-1.c | 48
3 files changed, 143 insertions(+), 4 modifications(!)
Index: gcc/config/s390/2827.md
===
*** gcc/config/s390/2827.md.orig
--- gcc/config/s390/2827.md
***
*** 37,43
(define_insn_reservation "zEC12_simple" 1
(and (eq_attr "cpu" "zEC12")
!(eq_attr "mnemonic"
"ltg,ogrk,lr,lnebr,lghrl,sdbr,x,asi,lhr,sebr,madb,ar,lhrl,clfxtr,llgfr,clghrl,cgr,cli,agrk,ic,adbr,aebr,lrv,clg,cy,cghi,sy,celfbr,seb,clgfr,al,tm,lang,clfebr,lghr,cdb,lpebr,laa,ark,lh,or,icy,xi,msebr,n,llihl,afi,cs,nrk,sth,lgr,l,lcr,stey,xg,crt,slgfr,ny,ld,j,llihh,slgr,clfhsi,slg,lb,lgrl,lrl,llihf,lndbr,llcr,laxg,mvghi,rllg,sdb,xrk,laag,alhsik,algfi,algr,aly,agfi,lrvr,d,crl,llgc,tmhl,algsi,lgh,icmh,clhrl,xgrk,icm,iilf,ork,lbr,cg,ldgr,lgf,iihf,llghr,sg,clfdbr,llgtr,stam,cebr,tmhh,tceb,slgf,basr,lgbr,maebr,lgb,cgfi,aeb,ltebr,lax,clfit,lrvgr,nihl,ni,clfdtr,srdl,mdb,srk,xihf,stgrl,sthrl,algf,ltr,cdlgbr,cgit,ng,lat,llghrl,ltgr,nihh,clgfrl,srlk,maeb,agr,cxlftr,ler,bcr_flush,stcy,cds,clfi,nihf,ly,clt,lgat,alg,lhy,lgfrl,clghsi,clrt,tmll,srlg,tcdb,ay,sty,clr,lgfi,lan,lpdbr,clgt,adb,ahik,sra,algrk,cdfbr,lcebr,clfxbr,msdbr,ceb,clgr,tmy,tmlh,alghsik,lcgr,mvi,cdbr,ltgf,xr,larl,ldr,llgcr,clgrt,clrl,cghsi,cliy,madbr,oy,ogr,llgt,meebr,slr,clgxbr,chi,s,icmy,llc,ngr,clhhsi,ltgfr,llill,lhi,o,meeb,clgdtr,sll,clgrl,clgf,ledbr,cegbr,mviy,algfr,rll,cdlftr,sldl,cdlgtr,lg,niy,st,sgr,ag,le,xgr,cr,stg,llilh,sr,lzer,cdsg,sllk,mdbr,stoc,csg,clgit,chhsi,strl,llilf,lndfr,ngrk,clgebr,clgfi,llgh,mseb,ltdbr,oill,la,llhrl,stc,lghi,oihl,xiy,sllg,llgf,cgrt,ldeb,cl,sl,cdlfbr,oi,oilh,nr,srak,oihh,ear,slgrk,og,c,slgfi,sthy,oilf,oiy,msdb,oihf,a,cfi,lzxr,lzdr,srag,cdgbr,brasl,alr,cgrl,llgfrl,cit,clgxtr,ley,exrl,lcdfr,lay,xilf,lcdbr,alsi,mvhhi,srl,chsi,lgfr,lrvg,cly,sgrk,ahi,celgbr,nill,clgdbr,jg,slrk,lxr,sar,slfi,cpsdr,lcgfr,aghik,nilh,mvhi,lpdfr,xy,alrk,lao,agsi,ldy,nilf,llhr,alfi,laog,sly,aghi,ldebr,bras,srda,cefbr,lt"))
"nothing")
(define_insn_reservation "zEC12_cgdbr" 2
(and (eq_attr "cpu" "zEC12")
--- 37,43
(define_insn_reservation "zEC12_simple" 1
(and (eq_attr "cpu" "zEC12")
!(eq_attr "mnemonic"
"ltg,ogrk,lr,lnebr,lghrl,sdbr,x,asi,lhr,sebr,madb,ar,lhrl,clfxtr,llgfr,clghrl,cgr,cli,agrk,ic,adbr,aebr,lrv,clg,cy,cghi,sy,celfbr,seb,clgfr,al,tm,lang,clfebr,lghr,cdb,lpebr,laa,ark,lh,or,icy,xi,msebr,n,llihl,afi,cs,nrk,sth,lgr,l,lcr,stey,xg,crt,slgfr,ny,ld,j,llihh,slgr,clfhsi,slg,lb,lgrl,lrl,llihf,lndbr,llcr,laxg,mvghi,rllg,sdb,xrk,laag,alhsik,algfi,algr,aly,agfi,lrvr,d,crl,llgc,tmhl,algsi,lgh,icmh,clhrl,xgrk,icm,iilf,ork,lbr,cg,ldgr,lgf,iihf,llghr,sg,clfdbr,llgtr,stam,cebr,tmhh,tceb,slgf,basr,lgbr,maebr,lgb,cgfi,aeb,ltebr,lax,clfit,lrvgr,nihl,ni,clfdtr,srdl,mdb,srk,xihf,stgrl,sthrl,algf,ltr,cdlgbr,cgit,ng,lat,llghrl,ltgr,nihh,clgfrl,srlk,maeb,agr,cxlftr,ler,bcr_flush,stcy,cds,clfi,nihf,ly,clt,lgat,alg,lhy,lgfrl,clghsi,clrt,tmll,srlg,tcdb,ay,sty,clr,lgfi,lan,lpdbr,clgt,adb,ahik,sra,algrk,cdfbr,lcebr,clfxbr,msdbr,ceb,clgr,tmy,tmlh,alghsik,lcgr,mvi,cdbr,ltgf,xr,larl,ldr,llgcr,clgrt,clrl,cghsi,cliy,madbr,oy,ogr,llgt,meebr,slr,clgxbr,chi,s,icmy,llc,ngr,clhhsi,ltgfr,llill,lhi,o,meeb,clgdtr,sll,clgrl,clgf,ledbr,cegbr,mviy,algfr,rll,cdlftr,sldl,cdlgtr,lg,niy,st,sgr,ag,le,xgr,cr,stg,llilh,sr,lzer,cdsg,sllk,mdbr,stoc,csg,clgit,chhsi,strl,llilf,lndfr,ngrk,clgebr,clgfi,llgh,mseb,ltdbr,oill,la,llhrl,stc,lghi,oihl,xiy,sllg,llgf,cgrt,ldeb,cl,sl,cdlfbr,oi,oilh,nr,srak,oihh,ear,slgrk,og,c,slgfi,sthy,oilf,oiy,msdb,oihf,a,cfi,lzxr,lzdr,srag,cdgbr,brasl,alr,cgrl,llgfrl,cit,clgxtr,ley,exrl,lcdfr,lay,xilf,lcdbr,alsi,mvhhi,srl,chsi,lgfr,lrvg,cly,sgrk,ahi,celgbr,nill,clgdbr,jg,slrk,lxr,sar,slfi,cpsdr,lcgfr,aghik,nilh,mvhi,lpdfr,xy,alrk,lao,agsi,ldy,nilf,llhr,alfi,laog,sly,a
RE: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets
On Tue, 3 Sep 2013 10:30:22, Richard Biener wrote: > On Mon, Sep 2, 2013 at 6:05 PM, Joseph S. Myers > wrote: >> On Mon, 2 Sep 2013, Richard Earnshaw wrote: >> >>> On 01/09/13 14:10, Bernd Edlinger wrote: IMHO the AAPCS forbids packed structures. Therefore we need not interfere with the C++ memory model if we have unaligned data. >>> >>> The AAPCS neither forbids nor requires packed structures. They're a GNU >>> extension and as such not part of standard C++. Thus the semantics of >>> such an operation are irrelavant to the AAPCS: you get to chose what the >>> behaviour is in this case... >> >> The trouble is that AAPCS semantics are incompatible with the default GNU >> semantics for non-packed structures as well - AAPCS >> strict-volatile-bitfields is only compatible with --param >> allow-store-data-races=1, which is not the default for any language >> variant accepted by GCC (and I say that the default language semantics >> here should not depend on the target architecture). > > As I said it should be easy to fulfil AAPCS requirements if they do not > violate > language constrains during code generation and thus warn about accesses > that are emitted in a way not conforming to AAPCS (a warning at struct > declaration time would be nicer, but I guess requires more coding and thought, > though at the point we compute DECL_BIT_FIELD_REPRESENTATIVE in > stor-layout.c would be a suitable place). > Just to make that clear, Sandra's patch tries to follow the AAPCS requirements, _even if_ they violate the language constraints. Thus -fstrict-volatile-bitfields implies --param allow-store-data-races=1. Bernd. > Richard. > >> -- >> Joseph S. Myers >> jos...@codesourcery.com
Fix PR58285
This makes ANON_AGGRNAME_P work properly by draggin in tm.h before tree.h for the use in tree-streamer-out.c Committed as obvious. Richard. 2013-09-03 Richard Biener PR lto/58285 * tree-streamer-out.c: Include tm.h. * Makefile.in (tree-streamer-out.o): Depend on $(TM_H). Index: gcc/tree-streamer-out.c === *** gcc/tree-streamer-out.c (revision 202196) --- gcc/tree-streamer-out.c (working copy) *** along with GCC; see the file COPYING3. *** 22,27 --- 22,28 #include "config.h" #include "system.h" #include "coretypes.h" + #include "tm.h" #include "diagnostic.h" #include "tree.h" #include "tree-streamer.h" Index: gcc/Makefile.in === *** gcc/Makefile.in (revision 202196) --- gcc/Makefile.in (working copy) *** tree-streamer-in.o: tree-streamer-in.c $ *** 2186,2192 $(DATA_STREAMER_H) $(STREAMER_HOOKS_H) $(LTO_STREAMER_H) tree-streamer-out.o: tree-streamer-out.c $(CONFIG_H) $(SYSTEM_H) \ coretypes.h $(DIAGNOSTIC_H) $(TREE_STREAMER_H) $(DATA_STREAMER_H) \ ! $(STREAMER_HOOKS_H) streamer-hooks.o: streamer-hooks.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ $(STREAMER_HOOKS_H) lto-cgraph.o: lto-cgraph.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ --- 2187,2193 $(DATA_STREAMER_H) $(STREAMER_HOOKS_H) $(LTO_STREAMER_H) tree-streamer-out.o: tree-streamer-out.c $(CONFIG_H) $(SYSTEM_H) \ coretypes.h $(DIAGNOSTIC_H) $(TREE_STREAMER_H) $(DATA_STREAMER_H) \ ! $(STREAMER_HOOKS_H) $(TM_H) streamer-hooks.o: streamer-hooks.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ $(STREAMER_HOOKS_H) lto-cgraph.o: lto-cgraph.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
RE: [PATCH] Portable Volatility Warning
On Tue, 3 Sep 2013 10:53:10, Richard Biener wrote:
> On Tue, Sep 3, 2013 at 2:05 AM, Bernd Edlinger
> wrote:
>> This is a follow-up patch for Sandra Loosemore's patch in this
>> thread: "reimplement -fstrict-volatile-bitfields, v3".
>> It was already posted a few weeks ago, but in the wrong thread.
>> Therfore I re-post it herewith.
>> It was initially suggested by Hans-Peter Nilsson, and I had much
>> help from him in putting everything together. Thanks again H-P.
>> Here is a short specification:
>> The -Wportable-volatility warning is an optional warning, to warn
>> about code for which separate incompatbile definitions on different
>> platforms (or between C and C++) exist even within gcc.
>> It will be usable for driver code you want to be portable on different
>> architectures.
>> This warning should only be emitted if the code is significantly
>> different when -fstrict-volatile-bitfields is used or not.
>> It should not be emitted for the code which is not affected by this
>> option.
>> In other words, it should be emitted on all bit-fields when the
>> definition or the context is volatile, except when the whole
>> structure is not AAPCS ABI compliant, i.e. packed or unaligned.
>> On the other hand you should always get the same
>> warnings if you combine -Wportable-volatility with
>> -fstrict-volatile-bitfields or not. And of course it should not
>> depend on the specific target that is used to compile.
>> I boot-strapped this on a i686-pc-linux-gnu and all Wportable-volatility
>> test cases are passed for C and C++.
>> I used a cross-compiler for arm-eabi to manually cross-check that
>> the warnings are independent of the target platform.
>
> Just a quick first note:
>
> @@ -3470,6 +3470,13 @@ optimize_bit_field_compare (location_t l
> || offset != 0 || TREE_CODE (linner) == PLACEHOLDER_EXPR)
> return 0;
>
> + /* Do not try to optimize on volatiles, as it would defeat the
> + -Wportable-volatility warning later:
> + If the COMPONENT_REF is replaced by a BIT_FIELD_REF we loose
> + information and thus the warning cannot be generated correctly. */
> + if (warn_portable_volatility && lvolatilep)
> + return 0;
>
> changing code-generation with a warning option looks wrong to me. Note
> that I completely removed this code once (it also generates strange
> BIT_FIELD_REFs) but re-instantiated it on request because of lost
> optimizations.
>
I'm sorry for that, but with the BIT_FIELD_REF I was not able to recover
the declaration mode of the bit field member. And this happened
for some of the test cases I wanted to have warnings on.
If I remember correctly this applies to code like:
if (x.x == 1)
{ ... }
> Similar for
>
> @@ -609,11 +609,14 @@ layout_decl (tree decl, unsigned int kno
> occupying a complete byte or bytes on proper boundary,
> and not -fstrict-volatile-bitfields. If the latter is set,
> we unfortunately can't check TREE_THIS_VOLATILE, as a cast
> - may make a volatile object later. */
> + may make a volatile object later.
> + Handle -Wportable-volatility analogous, as we would loose
> + information and defeat the warning later. */
> if (TYPE_SIZE (type) != 0
> && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
> && GET_MODE_CLASS (TYPE_MODE (type)) == MODE_INT
> - && flag_strict_volatile_bitfields <= 0)
> + && flag_strict_volatile_bitfields <= 0
> + && warn_portable_volatility == 0)
> {
> enum machine_mode xmode
> = mode_for_size_tree (DECL_SIZE (decl), MODE_INT, 1);
>
> I also wonder about "we unfortunately can't check TREE_THIS_VOLATILE, as a
> cast
> may make a volatile object later." - does that mean that AAPCS requires
>
> struct X { int x : 8; char c; };
>
> void foo (struct X *p)
> {
> ((volatile struct X *)p)->x = 1;
> }
>
> to be treated as volatile bitfield access? Similar, is
>
Yes, that is a volatile bitfield access.
> volatile struct X x;
> x.x = 1;
>
> a volatile bitifled access?
>
Yes, that too is a volatile bitfiled access.
Someone please correct me if I am wrong.
> I think the warning can be completely implemented inside struct-layout.c
> for example in finish_bitfield_representative (if you pass that the first
> field
> in the group, too). Of course that is at the expense of warning for
> struct declarations rather than actual code differences (the struct may
> not be used)
>
Yes, except for the above use cases.
These may be difficult to find without a warning.
> Richard.
>
>
>> Regards
>> Bernd Edlinger
Clean up pretty printers [20/n]
Same topic as 19/n.
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-09-03 Gabriel Dos Reis
c/
* c-objc-common.c (c_tree_printer): Tidy.
c-family/
* c-pretty-print.h (c_pretty_printer::type_id): Now a virtual
member function.
(c_pretty_printer::storage_class_specifier): Likewise.
(c_pretty_printer::initializer): Likewise.
(pp_declaration): Remove.
(pp_declaration_specifiers): Likewise.
(pp_abstract_declarator): Likewise.
(pp_declarator): Likewise.
(pp_type_id): Likewise.
(pp_statement): Likewise.
(pp_constant): Likewise.
(pp_id_expression): Likewise.
(pp_primary_expression): Likewise.
(pp_unary_expression): Likewise.
(pp_multiplicative_expression): Likewise.
(pp_conditional_expression): Likewise.
(pp_assignment_expression): Likewise.
(pp_expression): Likewise.
(pp_c_type_id): Likewise.
(pp_c_storage_class_specifier): Likewise.
* c-pretty-print.c (pp_c_type_cast): Tidy.
(pp_c_pointer): Likewise.
(pp_c_type_specifier): Likewise.
(pp_c_parameter_type_list): Likewise.
(pp_c_function_definition): Likewise.
(pp_c_init_declarator): Likewise.
(pp_c_initializer_list): Likewise.
(pp_c_constructor_elts): Likewise.
(c_pretty_printer::direct_abstract_declarator): Likewise.
(c_pretty_printer::declaration_specifiers): Likewise.
(c_pretty_printer::primary_expression): Likewise.
(c_pretty_printer::postfix_expression): Likewise.
(c_pretty_printer::type_id): Rename from pp_c_type_id.
(c_pretty_printer::storage_class_specifier): Rename from
pp_c_storage_class_specifier.
(c_pretty_printer::initializer): Rename from pp_c_initializer.
(c_pretty_printer::c_pretty_printer): Do not assign to type_id,
storage_class_specifier, initializer, offset_list, flags.
cp/
* cxx-pretty-print.h (cxx_pretty_printer::type_id): Declare as
overrider.
* cxx-pretty-print.c (pp_cxx_storage_class_specifier): Remove.
(pp_cxx_userdef_literal): Tidy.
(pp_cxx_template_argument_list): Likewise.
(pp_cxx_typeid_expression): Likewise.
(pp_cxx_offsetof_expression_1): Likewise.
(cxx_pretty_printer::postfix_expression): Likewise.
(cxx_pretty_printer::unary_expression): Likewise.
(cxx_pretty_printer::statement): Likewise.
(cxx_pretty_printer::type_id): Rename from pp_cxx_type_id.
(c_pretty_printer::cxx_pretty_printer): Do not assign to type_id.
* error.c (dump_decl): Tidy.
(dump_expr): Likewise.
Index: c/c-objc-common.c
===
--- c/c-objc-common.c (revision 202201)
+++ c/c-objc-common.c (working copy)
@@ -120,7 +120,7 @@
t = DECL_DEBUG_EXPR (t);
if (!DECL_P (t))
{
- pp_expression (cpp, t);
+ cpp->expression (t);
return true;
}
}
@@ -143,12 +143,12 @@
if (DECL_NAME (name))
pp_identifier (cpp, lang_hooks.decl_printable_name (name, 2));
else
- pp_type_id (cpp, t);
+ cpp->type_id (t);
return true;
}
else
{
- pp_type_id (cpp, t);
+ cpp->type_id (t);
return true;
}
break;
@@ -157,7 +157,7 @@
if (TREE_CODE (t) == IDENTIFIER_NODE)
pp_identifier (cpp, IDENTIFIER_POINTER (t));
else
- pp_expression (cpp, t);
+ cpp->expression (t);
return true;
case 'V':
Index: c-family/c-pretty-print.c
===
--- c-family/c-pretty-print.c (revision 202201)
+++ c-family/c-pretty-print.c (working copy)
@@ -208,7 +208,7 @@
pp_c_type_cast (c_pretty_printer *pp, tree t)
{
pp_c_left_paren (pp);
- pp_type_id (pp, t);
+ pp->type_id (t);
pp_c_right_paren (pp);
}
@@ -296,7 +296,7 @@
/* ??? This node is now in GENERIC and so shouldn't be here. But
we'll fix that later. */
case DECL_EXPR:
- pp_declaration (pp, DECL_EXPR_DECL (t));
+ pp->declaration (DECL_EXPR_DECL (t));
pp_needs_newline (pp) = true;
break;
@@ -393,7 +393,7 @@
case TYPE_DECL:
if (DECL_NAME (t))
- pp_id_expression (pp, t);
+ pp->id_expression (t);
else
pp->translate_string ("");
break;
@@ -411,7 +411,7 @@
pp->translate_string ("");
if (TYPE_NAME (t))
- pp_id_expression (pp, TYPE_NAME (t));
+ pp->id_expression (TYPE_NAME (t));
else
pp->translate_string ("");
break;
@@ -431,7 +431,7 @@
function declarations, this routine prints not just the
specifier-qualifier-list of such entities or types of such entities,
but also the 'pointer' production part
Re: [PATCH][RFC] Fix PR57656
On Mon, 24 Jun 2013, Richard Biener wrote:
>
> This fixes the miscompile in PR57656 - folding of
>
> int t = 1 - (a - b) / c;
>
> to
>
> int t = (b - a) / c + 1;
>
> which introduces intermediate undefined overflow for
> a == -1 and b == INT_MAX.
>
> There seems to be a mix of assumptions of the context
> negate_expr_p is called in - for example the comments
> and the code suggests that when checking whether
> negate_expr_p (A - B) is true then we assume there
> is a user-written - (A - B) expression (and thus
> we'll at most remove an overflow). But we happily
> recurse for binary operands (which means re-associating
> the negate with the operation) for multiplications
> and divisions. Considering - ((A - B) * C) then the
> folding to (B - A) * C _introduces_ an intermediate
> overflow if C is zero and A == -1 and B == INT_MAX.
> So with the notion that the input is always a negation
> present in user code the recursion is wrong. And
> if not, then at least the MINUS_EXPR case is wrong.
>
> For maximum benefit the API should probably be split
> so that it specifies whether there is a negation in
> place that we want to remove or not which we then
> can use for the recursion.
>
> Anyway - here is a patch that fixes the testcase by
> simply avoiding the recursion in the division case,
> handling only two obvious cases as any re-org as
> outlined above is certainly not good for backporting.
> (and a re-org attempt should probably try to unify
> the three functions negate_expr_p, negate_expr and
> fold_negate_expr again)
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> Any comments? Is the patch below ok for trunk and branches
> in the mean time?
Re-bootstrapped and tested on x86_64-unknown-linux-gnu and
committed on trunk sofar.
Richard.
>
> Thanks,
> Richard.
>
> 2013-06-24 Richard Biener
>
> PR middle-end/57656
> * fold-const.c (negate_expr_p): Fix division case.
> (negate_expr): Likewise.
>
> * gcc.dg/torture/pr57656.c: New testcase.
>
> Index: gcc/fold-const.c
> ===
> *** gcc/fold-const.c (revision 200363)
> --- gcc/fold-const.c (working copy)
> *** negate_expr_p (tree t)
> *** 483,493
>and actually traps on some architectures. But if overflow is
>undefined, we can negate, because - (INT_MIN / 1) is an
>overflow. */
> ! if (INTEGRAL_TYPE_P (TREE_TYPE (t))
> ! && !TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (t)))
> ! break;
> ! return negate_expr_p (TREE_OPERAND (t, 1))
> ! || negate_expr_p (TREE_OPERAND (t, 0));
>
> case NOP_EXPR:
> /* Negate -((double)float) as (double)(-float). */
> --- 483,506
>and actually traps on some architectures. But if overflow is
>undefined, we can negate, because - (INT_MIN / 1) is an
>overflow. */
> ! if (INTEGRAL_TYPE_P (TREE_TYPE (t)))
> ! {
> ! if (!TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (t)))
> ! break;
> ! /* If overflow is undefined then we have to be careful because
> ! we ask whether it's ok to associate the negate with the
> ! division which is not ok for example for
> ! -((a - b) / c) where (-(a - b)) / c may invoke undefined
> ! overflow because of negating INT_MIN. So do not use
> ! negate_expr_p here but open-code the two important cases. */
> ! if (TREE_CODE (TREE_OPERAND (t, 0)) == NEGATE_EXPR
> ! || (TREE_CODE (TREE_OPERAND (t, 0)) == INTEGER_CST
> ! && may_negate_without_overflow_p (TREE_OPERAND (t, 0
> ! return true;
> ! }
> ! else if (negate_expr_p (TREE_OPERAND (t, 0)))
> ! return true;
> ! return negate_expr_p (TREE_OPERAND (t, 1));
>
> case NOP_EXPR:
> /* Negate -((double)float) as (double)(-float). */
> *** fold_negate_expr (location_t loc, tree t
> *** 682,697
> return fold_build2_loc (loc, TREE_CODE (t), type,
> TREE_OPERAND (t, 0), negate_expr (tem));
> }
> tem = TREE_OPERAND (t, 0);
> ! if (negate_expr_p (tem))
> ! {
> ! if (INTEGRAL_TYPE_P (type)
> ! && (TREE_CODE (tem) != INTEGER_CST
> ! || tree_int_cst_equal (tem, TYPE_MIN_VALUE (type
> ! fold_overflow_warning (warnmsg, WARN_STRICT_OVERFLOW_MISC);
> ! return fold_build2_loc (loc, TREE_CODE (t), type,
> ! negate_expr (tem), TREE_OPERAND (t, 1));
> ! }
> }
> break;
>
> --- 695,714
> return fold_build2_loc (loc, TREE_CODE (t), type,
> TREE_OPERAND (t, 0), negate_expr (tem));
> }
> + /* If overflow is undefined then we have to be careful because
> + we ask whether it's ok to associate the negate with the
[PATCH] Fix affine rework issue
I've noticed that I associate negation and conversion in one place.
Fixed by the following which also removes some useless converts.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-09-03 Richard Biener
* tree-affine.c (add_elt_to_tree): Fix association issue,
avoid useless converts and make sure to always return a
properly typed result.
Index: gcc/tree-affine.c
===
--- gcc/tree-affine.c (revision 202196)
+++ gcc/tree-affine.c (working copy)
@@ -381,36 +381,43 @@ add_elt_to_tree (tree expr, tree type, t
if (scale.is_minus_one ()
&& POINTER_TYPE_P (TREE_TYPE (elt)))
{
- elt = fold_build1 (NEGATE_EXPR, sizetype, convert_to_ptrofftype (elt));
+ elt = convert_to_ptrofftype (elt);
+ elt = fold_build1 (NEGATE_EXPR, TREE_TYPE (elt), elt);
scale = double_int_one;
}
if (scale.is_one ())
{
if (!expr)
- return elt;
+ {
+ if (POINTER_TYPE_P (TREE_TYPE (elt)))
+ return elt;
+ else
+ return fold_convert (type1, elt);
+ }
if (POINTER_TYPE_P (TREE_TYPE (expr)))
- return fold_build_pointer_plus (expr, convert_to_ptrofftype (elt));
+ return fold_build_pointer_plus (expr, elt);
if (POINTER_TYPE_P (TREE_TYPE (elt)))
- return fold_build_pointer_plus (elt, convert_to_ptrofftype (expr));
+ return fold_build_pointer_plus (elt, expr);
return fold_build2 (PLUS_EXPR, type1,
- fold_convert (type1, expr),
- fold_convert (type1, elt));
+ expr, fold_convert (type1, elt));
}
if (scale.is_minus_one ())
{
if (!expr)
- return fold_build1 (NEGATE_EXPR, TREE_TYPE (elt), elt);
+ return fold_build1 (NEGATE_EXPR, type1,
+ fold_convert (type1, elt));
if (POINTER_TYPE_P (TREE_TYPE (expr)))
- return fold_build_pointer_plus
- (expr, convert_to_ptrofftype
-(fold_build1 (NEGATE_EXPR, TREE_TYPE (elt), elt)));
+ {
+ elt = convert_to_ptrofftype (elt);
+ elt = fold_build1 (NEGATE_EXPR, TREE_TYPE (elt), elt);
+ return fold_build_pointer_plus (expr, elt);
+ }
return fold_build2 (MINUS_EXPR, type1,
- fold_convert (type1, expr),
- fold_convert (type1, elt));
+ expr, fold_convert (type1, elt));
}
elt = fold_convert (type1, elt);
@@ -434,8 +441,7 @@ add_elt_to_tree (tree expr, tree type, t
elt = fold_build1 (NEGATE_EXPR, type1, elt);
return fold_build_pointer_plus (expr, elt);
}
- return fold_build2 (code, type1,
- fold_convert (type1, expr), elt);
+ return fold_build2 (code, type1, expr, elt);
}
/* Makes tree from the affine combination COMB. */
[PATCH, C++, PR58282] Handle noexcept on transactions with -fno-exceptions
Jason,
Consider this testcase reduced from g++.dg/tm/noexcept-1.C:
...
struct TrueFalse
{
static constexpr bool v() { return true; }
};
int global;
template int foo()
{
__transaction_atomic noexcept(T::v()) { global += 1; }
return __transaction_atomic noexcept(T::v()) (global + 2);
}
int f1()
{
return foo();
}
...
It fails with a SIGSEGV when run with -fno-exceptions:
...
$ g++ noexcept-1.C -fno-exceptions -fgnu-tm -std=c++0x -S
noexcept-1.C: In function ‘int foo() [with T = TrueFalse]’:
noexcept-1.C:10:43: internal compiler error: Segmentation fault
__transaction_atomic noexcept(T::v()) { global += 1; }
^
...
The noexcept(t::v()) operator evaluates to true, so the noexcept specifier on
the transaction is set to true. Then cp/semantics.c:build_transaction_expr
builds a MUST_NOT_THROW_EXPR to safe-guard the property at runtime:
...
if (noex)
{
expr = build_must_not_throw_expr (expr, noex);
SET_EXPR_LOCATION (expr, loc);
TREE_SIDE_EFFECTS (expr) = 1;
}
...
During gimplification of the MUST_NOT_THROW_EXPR in
cp/cp-gimplify.c:gimplify_must_not_throw_expr, we're trying to translate into a
try/catch:
...
gimplify_and_add (body, &try_);
mnt = gimple_build_eh_must_not_throw (terminate_node);
gimple_seq_add_stmt_without_update (&catch_, mnt);
mnt = gimple_build_try (try_, catch_, GIMPLE_TRY_CATCH);
...
However, terminate_node is NULL at that point because of -fno-exceptions, so in
gimple.c:gimple_build_eh_must_not_throw, this line causes a SIGSEGV because decl
== terminate_node == NULL:
...
gcc_assert (TREE_CODE (decl) == FUNCTION_DECL);
...
This patch fixes the SIGSEGV by not generating a MUST_NOT_THROW_EXPR with
-fno-exceptions.
Bootstrapped and reg-tested on x86_64.
OK for trunk?
Thanks,
- Tom
2013-09-02 Tom de Vries
PR c++/58282
* semantics.c (finish_transaction_stmt, build_transaction_expr): Handle
flag_exceptions.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index ee3503c..c8b328c 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5189,7 +5189,7 @@ finish_transaction_stmt (tree stmt, tree compound_stmt, int flags, tree noex)
/* noexcept specifications are not allowed for function transactions. */
gcc_assert (!(noex && compound_stmt));
- if (noex)
+ if (noex && flag_exceptions)
{
tree body = build_must_not_throw_expr (TRANSACTION_EXPR_BODY (stmt),
noex);
@@ -5210,7 +5210,7 @@ tree
build_transaction_expr (location_t loc, tree expr, int flags, tree noex)
{
tree ret;
- if (noex)
+ if (noex && flag_exceptions)
{
expr = build_must_not_throw_expr (expr, noex);
SET_EXPR_LOCATION (expr, loc);
[PATCH] Accept ISL 0.12
The following patch makes us accept ISL 0.12.
Bootstrapped and tested on x86_64-unknown-linux-gnu (with using ISL 0.12),
applied as obvious.
Richard.
2013-09-03 Richard Biener
* configure.ac: Also allow ISL 0.12.
* configure: Regenerated.
Index: configure.ac
===
*** configure.ac(revision 202203)
--- configure.ac(working copy)
*** if test "x$with_isl" != "xno" &&
*** 1653,1658
--- 1653,1661
ISL_CHECK_VERSION(0,10)
if test "${gcc_cv_isl}" = no ; then
ISL_CHECK_VERSION(0,11)
+ if test "${gcc_cv_isl}" = no ; then
+ ISL_CHECK_VERSION(0,12)
+ fi
fi
dnl Only execute fail-action, if ISL has been requested.
ISL_IF_FAILED([
Index: configure
===
*** configure (revision 202203)
--- configure (working copy)
*** $as_echo "$gcc_cv_isl" >&6; }
*** 5965,5970
--- 5965,6019
fi
+ if test "${gcc_cv_isl}" = no ; then
+
+ if test "${ENABLE_ISL_CHECK}" = yes ; then
+ _isl_saved_CFLAGS=$CFLAGS
+ _isl_saved_LDFLAGS=$LDFLAGS
+ _isl_saved_LIBS=$LIBS
+
+ CFLAGS="${_isl_saved_CFLAGS} ${islinc} ${gmpinc}"
+ LDFLAGS="${_isl_saved_LDFLAGS} ${isllibs}"
+ LIBS="${_isl_saved_LIBS} -lisl"
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for version 0.12 of
ISL" >&5
+ $as_echo_n "checking for version 0.12 of ISL... " >&6; }
+ if test "$cross_compiling" = yes; then :
+ gcc_cv_isl=yes
+ else
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+ /* end confdefs.h. */
+ #include
+#include
+ int
+ main ()
+ {
+ if (strncmp (isl_version (), "isl-0.12", strlen ("isl-0.12")) != 0)
+ return 1;
+
+ ;
+ return 0;
+ }
+ _ACEOF
+ if ac_fn_c_try_run "$LINENO"; then :
+ gcc_cv_isl=yes
+ else
+ gcc_cv_isl=no
+ fi
+ rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
+ conftest.$ac_objext conftest.beam conftest.$ac_ext
+ fi
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_isl" >&5
+ $as_echo "$gcc_cv_isl" >&6; }
+
+ CFLAGS=$_isl_saved_CFLAGS
+ LDFLAGS=$_isl_saved_LDFLAGS
+ LIBS=$_isl_saved_LIBS
+ fi
+
+
+ fi
fi
[v3] libstdc++/58302
Hi,
a very stupid typo. Tested x86_64-linux, fixed in the active branches.
Thanks,
Paolo.
//
2013-09-03 Paolo Carlini
PR libstdc++/58302
* include/bits/random.tcc (negative_binomial_distribution<>::
operator()(_UniformRandomNumberGenerator&, const param_type&):
Fix typo in template argument.
* testsuite/26_numerics/random/negative_binomial_distribution/
operators/58302.cc: New.
Index: include/bits/random.tcc
===
--- include/bits/random.tcc (revision 202199)
+++ include/bits/random.tcc (working copy)
@@ -1291,7 +1291,7 @@
operator()(_UniformRandomNumberGenerator& __urng,
const param_type& __p)
{
- typedef typename std::gamma_distribution::param_type
+ typedef typename std::gamma_distribution::param_type
param_type;
const double __y =
Index:
testsuite/26_numerics/random/negative_binomial_distribution/operators/58302.cc
===
---
testsuite/26_numerics/random/negative_binomial_distribution/operators/58302.cc
(revision 0)
+++
testsuite/26_numerics/random/negative_binomial_distribution/operators/58302.cc
(working copy)
@@ -0,0 +1,34 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++11" }
+// { dg-require-cstdint "" }
+//
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [PATCH] PR58143/58227 wrong code at -O3
On Fri, Aug 30, 2013 at 6:43 PM, Bernd Edlinger
wrote:
> On Thu, 29 Aug 2013 11:54:22, Richard Biener wrote:
>> On Wed, Aug 28, 2013 at 11:24 PM, Bernd Edlinger
>> wrote:
>>> The lim pass (aka loop invariant motion) can move conditional expressions
>>> with
>>> possible undefined behavior out of the if statement inside a loop which may
>>> cause the
>>> loop optimization to silently generate wrong code as PR
>>> tree-optimization/58143 and
>>> PR tree-optimization/58227 demonstrate.
>>>
>>> This patch prevents lim from moving code that might cause undefined
>>> behavior.
>>>
>>> This triggered a minor regression in gcc.target/i386/pr53397-1.c:
>>> Here lim used to move the expression "2*step" out of the loop, but this may
>>> cause
>>> undefined behavior on case of overflow, I propose to resolve this by adding
>>> -fno-strict-overflow. The test case looks pretty constructed anyway.
>>>
>>> The patch was boot-strapped and regression tested on i686-pc-linux-gnu and
>>> X86_64-linux-gnu
>>>
>>> OK for trunk?
>>
>> 2013-08-28 Bernd Edlinger
>>
>> PR tree-optimization/58143
>> PR tree-optimization/58227
>> Prevent lim from moving conditional expressions
>> if that could trigger undefined behavior.
>> * gimple.h (gimple_could_trap_p_2): New function.
>> * gimple.c (gimple_could_trap_p_2): New function.
>> (gimple_could_trap_p_1): Call gimple_could_trap_p_2.
>> * tree-ssa-loop-im.c (movement_possibility): Likewise.
>>
>> Please fold the overall comment into the movement_possibility changelog.
>>
>
> done.
>
>> Can you instead of introducing gimple_could_trap_p_2 simply change the
>> signature and name of gimple_could_trap_p_1 please? It is only called
>> three times.
>> A proper name could be gimple_could_trap_or_invoke_undefined_p.
>>
>
> done.
>
>> That you need to change the two testcases makes me nervous (also please
>> use -fwrapv, not -fno-strict-overflow) - did you check what happens for them?
>>
>
> Yes, I looked at that again. That is an interesting story.
> Initially the function looks like:
>
> for (a = 1; a < step; a++) {
>for (b = 0; b
> when the lim pass is invoked that looks like:
>
> if (step> 1 && n> 0) {
> for (a = 1; a < step; a++) {
> pretmp = step * 2;
> for (b = 0; b < n; b += pretmp) {
>
> Well "step*2" was initially at loop level 2, but now I see, it is actually at
> loop level 1.
>
> When lim does not move this out of the loop the test case fails.
> But if lim moves this statement out of the loop despite the possible undefined
> behavior, the test case passes.
>
> Now I think this is good opportunity for a simple heuristic:
>
> If a statement is at loop level 1 we can move it out of the loop,
> regardless of the fact, that it may invoke undefined behavior, because if it
> is
> moved then out of any loops, and thus it cannot be an induction variable and
> cause problems with aggressive loop optimizations later.
VRP can still cause wrong-code issues (it's probably hard to generate a
testcase though). Also a less conservative check would be to see
whether we hoist _into_ loop level 0 (though we cannot check that at
the point where you placed the check).
> Only statements with possible undefined behavior in nested loops can become
> induction variable if lim moves them from one loop into an outer loop.
>
> Therefore with extremely much luck the test case will pass unmodified.
> I tried it, and the patch passes bootstrap and causes zero regressions
> with this heuristic.
>
> Ok for trunk now?
Jakub mentioned another possibility - make sure the moved expression
does not invoke undefined behavior by computing in an unsigned type.
That said, for the sake of backporting we need a patch as simple as
possible - so it would be interesting to see whether the patch without
the loop 1 heuristic has any effect on say SPEC CPU 2006 performance.
Thanks,
Richard.
> Thanks
> Bernd.
>
>> Thanks,
>> Richard.
>>
>>
>>
>>> Regards
>>> Bernd Edlinger
Re: folding (vec_)cond_expr in a binary operation
On Mon, Sep 2, 2013 at 11:46 AM, Marc Glisse wrote: > On Fri, 30 Aug 2013, Richard Biener wrote: > >> On Sat, Jul 6, 2013 at 9:42 PM, Marc Glisse wrote: >>> >>> First, the fold-const bit causes an assertion failure (building libjava) >>> in >>> combine_cond_expr_cond, which calls: >>> >>> t = fold_binary_loc (gimple_location (stmt), code, type, op0, op1); >>> >>> and then checks: >>> >>> /* Require that we got a boolean type out if we put one in. */ >>> gcc_assert (TREE_CODE (TREE_TYPE (t)) == TREE_CODE (type)); >>> >>> which makes sense... Note that the 2 relevant types are: >> >> >> well, the check is probably old and can be relaxed to also allow all >> compatible types. > > > Ok. Maybe it could even be removed then, we shouldn't check in every > function that calls fold_binary_loc that it returns something of the type > that was asked for. > > >>> Second, the way the forwprop transformation is done, it can be necessary >>> to >>> run the forwprop pass several times in a row, which is not nice. It >>> takes: >>> >>> stmt_cond >>> stmt_binop >>> >>> and produces: >>> >>> stmt_folded >>> stmt_cond2 >>> >>> But one of the arguments of stmt_folded could be an ssa_name defined by a >>> cond_expr, which could now be propagated into stmt_folded (there may be >>> other new possible transformations). However, that cond_expr has already >>> been visited and won't be again. The combine part of the pass uses a PLF >>> to >>> revisit statements, but the forwprop part doesn't have any specific >>> mechanism. >> >> >> forwprop is designed to re-process stmts it has folded to catch cascading >> effects. Now, as it as both a forward and a backward run you don't catch >> 2nd-order effects with iterating them. On my TODO is to only do one kind, >> either forward or backward propagation. > > > My impression is that even internally in the forward part, the > reprocessing doesn't really work, but that'll disappear anyway when the > forward part disappears. > > >> Btw, as for the patch I don't like that you basically feed everything into >> fold. Yes, I know we do that for conditions because that's quite >> important >> and nobody has re-written the condition folding as gimple pattern matcher. >> I doubt that this transform is important enough to warrant another >> exception ;) > > > I am not sure what you want here. When I notice the pattern (a?b:c) op d, I > need to check whether b op d and c op d are likely to simplify before > transforming it to a?(b op d):(c op d). And currently I can't see any way to > do that other than feeding (b op d) to fold. Even if/when we get a gimple > folder, we will still need to call it in about the same way. With a gimple folder you'd avoid building trees. You are testing for a quite complex pattern here - (a?b:c) & (d?e:f). It seems to be that for example + vec c=(a>3)?o:z; + vec d=(b>2)?o:z; + vec e=c&d; would be better suited in the combine phase (you are interested in combining the comparisons). That is, look for a [&|^] b where a and b are [VEC_]COND_EXPRs with the same values. Heh, and it's not obvious to me with looking for a minute what this should be simplified to ... (so the code and the testcase needs some comments on what you are trying to catch ...) Richard. > -- > Marc Glisse
[AArch64] Fix categorisation of the frecp* insns.
Hi, It looks like the frecp instructions got miscategorised as TARGET_FLOAT instructions when they are in fact TARGET_SIMD instructions. Move them to the right file, give them a simd_type, drop their "type" and "v8type" and clean up the useless types from aarch64.md. Also, where possible merge patterns. Tested on aarch64-none-elf with no regression. Thanks, James --- 2013-09-03 James Greenhalgh * config/aarch64/aarch64.md (type): Remove frecpe, frecps, frecpx. (aarch64_frecp): Move to aarch64-simd.md, fix to be a TARGET_SIMD instruction. (aarch64_frecps): Remove. * config/aarch64/aarch64-simd.md (aarch64_frecp): New, moved from aarch64.md (aarch64_frecps): Handle all float/vector of float modes. diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index f4b929edf44fbeebe6da2568a3aa76138eca0609..c085fb9c49958c5f402a28c0b39fe45ec1aadbc7 100644 --- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -4179,13 +4179,23 @@ (define_insn "aarch64_frecpe" (set_attr "simd_mode" "")] ) +(define_insn "aarch64_frecp" + [(set (match_operand:GPF 0 "register_operand" "=w") + (unspec:GPF [(match_operand:GPF 1 "register_operand" "w")] + FRECP))] + "TARGET_SIMD" + "frecp\\t%0, %1" + [(set_attr "simd_type" "simd_frecp") + (set_attr "mode" "")] +) + (define_insn "aarch64_frecps" - [(set (match_operand:VDQF 0 "register_operand" "=w") - (unspec:VDQF [(match_operand:VDQF 1 "register_operand" "w") - (match_operand:VDQF 2 "register_operand" "w")] + [(set (match_operand:VALLF 0 "register_operand" "=w") + (unspec:VALLF [(match_operand:VALLF 1 "register_operand" "w") + (match_operand:VALLF 2 "register_operand" "w")] UNSPEC_FRECPS))] "TARGET_SIMD" - "frecps\\t%0., %1., %2." + "frecps\\t%0, %1, %2" [(set_attr "simd_type" "simd_frecps") (set_attr "simd_mode" "")] ) diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md index 47532fca2c550e8ec9b63898511ef6c276943a45..a46dd5813acd9c800a6c519544fb7bca5de993d9 100644 --- a/gcc/config/aarch64/aarch64.md +++ b/gcc/config/aarch64/aarch64.md @@ -240,9 +240,6 @@ (define_attr "v8type" fmovf2i,\ fmovi2f,\ fmul,\ - frecpe,\ - frecps,\ - frecpx,\ frint,\ fsqrt,\ load_acq,\ @@ -3946,29 +3943,6 @@ (define_insn "smin3" (set_attr "mode" "")] ) -(define_insn "aarch64_frecp" - [(set (match_operand:GPF 0 "register_operand" "=w") - (unspec:GPF [(match_operand:GPF 1 "register_operand" "w")] - FRECP))] - "TARGET_FLOAT" - "frecp\\t%0, %1" - [(set_attr "v8type" "frecp") - (set_attr "type" "ffarith") - (set_attr "mode" "")] -) - -(define_insn "aarch64_frecps" - [(set (match_operand:GPF 0 "register_operand" "=w") - (unspec:GPF [(match_operand:GPF 1 "register_operand" "w") - (match_operand:GPF 2 "register_operand" "w")] - UNSPEC_FRECPS))] - "TARGET_FLOAT" - "frecps\\t%0, %1, %2" - [(set_attr "v8type" "frecps") - (set_attr "type" "ffarith") - (set_attr "mode" "")] -) - ;; --- ;; Reload support ;; ---
Re: [patch, fortran, docs] Unformatted sequential and special files
Hello world,
here is a rewrite, which I hope make things more clear.
Unformatted sequential files are now made up of subrecords, where
a logical record may only have one.
Regarding block devices: I don't know anybody who ever used them
from gfortran, so I tried to be as vague as possible.
Any more suggestions? OK for trunk otherwise?
Thomas
Index: gfortran.texi
===
--- gfortran.texi (Revision 201996)
+++ gfortran.texi (Arbeitskopie)
@@ -1121,6 +1121,8 @@
* Internal representation of LOGICAL variables::
* Thread-safety of the runtime library::
* Data consistency and durability::
+* Unformatted sequential file format::
+* I/O with special files::
@end menu
@@ -1291,7 +1293,109 @@
releasing @code{fcntl} file locks, if the server supports them, will
also force cache validation and flushing dirty data and metadata.
+@node Unformatted sequential file format
+@section Unformatted sequential file format
+@cindex unformatted sequential
+@cindex sequential, unformatted
+@cindex record marker
+@cindex subrecord
+Unformatted sequential files are stored as logical records using
+record markers. Each logical record consists of one of more subrecords.
+
+Each subrecord consists of a leading record marker, the data written
+by the user program, and a trailing record marker. The record markers
+are four-byte integers by default, and eight-byte integers if the
+@option{-fmax-subrecord-length=8} option (which exists for backwards
+compability reasons only) is in effect.
+
+The maximum number of bytes of user data in a subrecord is 2147483639
+(2 GiB - 9) for a four-byte record marker. If a logical record
+contains more data, the data is distributed among several subrecords.
+
+The absolute of the number stored in the record markers is the number
+of bytes of user data in the corresponding subrecord. If the leading
+record marker of a subrecord contains a negative number, another
+subrecord follows the current one. If the trailing record marker
+contains a negative number, then there is a preceding subrecord.
+
+In the most simple case, with only one subrecord per logical record,
+both record markers contain the number of bytes of user data in the
+record,
+
+The format for unformatted sequential data can be duplicated using
+unformatted stream, as shown in the example program for a single
+subrecord only:
+
+@smallexample
+program main
+ use iso_fortran_env, only: int32
+ implicit none
+ integer(int32) :: i
+ real, dimension(10) :: a, b
+ call random_number(a)
+ open (10,file='test.dat',form='unformatted',access='stream')
+ inquire (iolength=i) a
+ write (10) i, a, i
+ close (10)
+ open (10,file='test.dat',form='unformatted')
+ read (10) b
+ if (all (a == b)) print *,'success!'
+end program main
+@end smallexample
+
+@node I/O with special files
+@section I/O with special files
+@cindex special files
+@cindex character devices
+@cindex devices, character
+@cindex block devices
+@cindex devices, block
+@cindex sockets
+@cindex special files, character
+@cindex BACKSPACE
+@cindex REWIND
+@cindex ENDFILE
+@cindex pipes
+@cindex FIFO
+@cindex terminal devices
+@cindex unformatted sequential
+@cindex sequential, unformatted
+@cindex unformatted stream
+@cindex stream, unformatted
+@cindex formatted stream
+@cindex stream, formatted
+@cindex direct access
+
+Special character files such as pipes, FIFOs, sockets or terminal
+devices are supported only for the following types of file access:
+
+@itemize
+
+@item Formatted sequential
+
+@item Formatted stream
+
+@item Unformatted stream
+
+@end itemize
+
+For special character files, the @code{POS=} specifier for stream I/O
+can only be used in @code{INQUIRE} statements.
+
+@code{BACKSPACE}, @code{REWIND} and @code{ENDFILE} are not supported
+for character special files.
+
+Unformatted sequential and direct file access are @emph{not} supported
+for character special files. If necessary, unformatted sequential
+access can be simulated using unformatted stream, see @ref{Unformatted
+sequential file format}.
+
+Block devices have not been tested. It is likely that only
+unformatted stream and direct access will work for those. Some
+restrictions specific to the operating system regarding sizes and
+alignment of data may apply.
+
@c -
@c Extensions
@c -
Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL
Thanks Richard for reviewing.
On 02/09/13 22:15, Richard Biener wrote:
On Wed, Jul 3, 2013 at 2:25 PM, Kugan wrote:
On 17/06/13 18:33, Richard Biener wrote:
On Mon, 17 Jun 2013, Kugan wrote:
+/* Extract the value range of assigned exprassion for GIMPLE_ASSIGN stmt.
+ If the extracted value range is valid, return true else return
+ false. */
+static bool
+extract_exp_value_range (gimple stmt, value_range_t *vr)
+{
+ gcc_assert (is_gimple_assign (stmt));
+ tree rhs1 = gimple_assign_rhs1 (stmt);
+ tree lhs = gimple_assign_lhs (stmt);
+ enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
...
@@ -8960,6 +9016,23 @@ simplify_stmt_using_ranges (gimple_stmt_iterator
*gsi)
{
enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
tree rhs1 = gimple_assign_rhs1 (stmt);
+ tree lhs = gimple_assign_lhs (stmt);
+
+ /* Set value range information for ssa. */
+ if (!POINTER_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt)))
+ && (TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME)
+ && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt)))
+ && !SSA_NAME_RANGE_INFO (lhs))
+{
+ value_range_t vr = VR_INITIALIZER;
...
+ if (extract_exp_value_range (stmt, &vr))
+tree_ssa_set_value_range (lhs,
+ tree_to_double_int (vr.min),
+ tree_to_double_int (vr.max),
+ vr.type == VR_RANGE);
+}
This looks overly complicated to me. In vrp_finalize you can simply do
for (i = 0; i < num_vr_values; i++)
if (vr_value[i])
{
tree name = ssa_name (i);
if (POINTER_TYPE_P (name))
continue;
if (vr_value[i].type == VR_RANGE
|| vr_value[i].type == VR_ANTI_RANGE)
tree_ssa_set_value_range (name, tree_to_double_int
(vr_value[i].min), tree_to_double_int (vr_value[i].max), vr_value[i].type
== VR_RANGE);
}
Thanks Richard for taking time to review it.
I was doing something like what you are suggesting earlier but noticed some
problems and that’s the reason why I changed.
For example, for the following testcase from the test suite,
unsigned long l = (unsigned long)-2;
unsigned short s;
int main () {
long t = l + 1;
s = l;
if (s != (unsigned short) -2)
abort ();
exit (0);
}
with the following gimple stmts
main ()
{
short unsigned int s.1;
long unsigned int l.0;
;; basic block 2, loop depth 0
;;pred: ENTRY
l.0_2 = l;
s.1_3 = (short unsigned int) l.0_2;
s = s.1_3;
if (s.1_3 != 65534)
goto ;
else
goto ;
;;succ: 3
;;4
;; basic block 3, loop depth 0
;;pred: 2
abort ();
;;succ:
;; basic block 4, loop depth 0
;;pred: 2
exit (0);
;;succ:
}
has the following value range.
l.0_2: VARYING
s.1_3: [0, +INF]
From zero/sign extension point of view, the variable s.1_3 is expected to
have a value that will overflow (or varying) as this is what is assigned to
a smaller variable. extract_range_from_assignment initially calculates the
value range as VARYING but later changed to [0, +INF] by
extract_range_basic. What I need here is the value that will be assigned
from the rhs expression and not the value that we will have with proper
assignment.
I don't understand this. The relevant statement is
s.1_3 = (short unsigned int) l.0_2;
right? You have value-ranges for both s.1_3 and l.0_2 as above. And
you clearly cannot optimize the truncation away (and if you could,
you wond't need value-range information for that fact).
This is true. But just by looking at the value range of s.1.3 we will
only see [0 +INF], as we are transferring directly from the lattice to
lhs its value range.
[0, +INF] here tells us vrp_val_is_max and it is not
is_positive_overflow_infinity (or varying). Thats why we need to get the
value range of RHS expression which will tell us the actual range. We
can then use this range and see of we can fit it to lhs type without
truncation.
I understand that the above code of mine needs to be changed but not
convinced about the best way to do that.
I can possibly re-factor extract_range_from_assignment to give me this
information with an additional argument. Could you kindly let me know your
preference.
/* SSA name annotations. */
+ union vrp_info_type {
+/* Pointer attributes used for alias analysis. */
+struct GTY ((tag ("TREE_SSA_PTR_INFO"))) ptr_info_def *ptr_info;
+/* Value range attributes used for zero/sign extension elimination.
*/
/* Value range information. */
+struct GTY ((tag ("TREE_SSA_RANGE_INFO"))) range_info_def
*range_info;
+ } GTY ((desc ("%1.def_stmt && !POINTER_TYPE_P (TREE_TYPE
((tree)&%1))"))) vrp;
why do you need to test %1.def_stmt here?
I have seen some tree_ssa_name with def_stmt NULL. Thats why I added this.
Is that some
Re: [PATCH] Accept ISL 0.12
On Tue, Sep 03, 2013 at 12:04:51PM +0200, Richard Biener wrote:
>
> The following patch makes us accept ISL 0.12.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu (with using ISL 0.12),
> applied as obvious.
Richard,
Does this also accept isl 0.12.1 as that is the current bug fix release...
http://repo.or.cz/w/isl.git/shortlog/0e737ed0b35803685e9ebcfd8c528e00c30bbc43
from upstream.
Jack
>
> Richard.
>
> 2013-09-03 Richard Biener
>
> * configure.ac: Also allow ISL 0.12.
> * configure: Regenerated.
>
> Index: configure.ac
> ===
> *** configure.ac (revision 202203)
> --- configure.ac (working copy)
> *** if test "x$with_isl" != "xno" &&
> *** 1653,1658
> --- 1653,1661
> ISL_CHECK_VERSION(0,10)
> if test "${gcc_cv_isl}" = no ; then
> ISL_CHECK_VERSION(0,11)
> + if test "${gcc_cv_isl}" = no ; then
> + ISL_CHECK_VERSION(0,12)
> + fi
> fi
> dnl Only execute fail-action, if ISL has been requested.
> ISL_IF_FAILED([
> Index: configure
> ===
> *** configure (revision 202203)
> --- configure (working copy)
> *** $as_echo "$gcc_cv_isl" >&6; }
> *** 5965,5970
> --- 5965,6019
> fi
>
>
> + if test "${gcc_cv_isl}" = no ; then
> +
> + if test "${ENABLE_ISL_CHECK}" = yes ; then
> + _isl_saved_CFLAGS=$CFLAGS
> + _isl_saved_LDFLAGS=$LDFLAGS
> + _isl_saved_LIBS=$LIBS
> +
> + CFLAGS="${_isl_saved_CFLAGS} ${islinc} ${gmpinc}"
> + LDFLAGS="${_isl_saved_LDFLAGS} ${isllibs}"
> + LIBS="${_isl_saved_LIBS} -lisl"
> +
> + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for version 0.12 of
> ISL" >&5
> + $as_echo_n "checking for version 0.12 of ISL... " >&6; }
> + if test "$cross_compiling" = yes; then :
> + gcc_cv_isl=yes
> + else
> + cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> + /* end confdefs.h. */
> + #include
> +#include
> + int
> + main ()
> + {
> + if (strncmp (isl_version (), "isl-0.12", strlen ("isl-0.12")) != 0)
> + return 1;
> +
> + ;
> + return 0;
> + }
> + _ACEOF
> + if ac_fn_c_try_run "$LINENO"; then :
> + gcc_cv_isl=yes
> + else
> + gcc_cv_isl=no
> + fi
> + rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
> + conftest.$ac_objext conftest.beam conftest.$ac_ext
> + fi
> +
> + { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_isl" >&5
> + $as_echo "$gcc_cv_isl" >&6; }
> +
> + CFLAGS=$_isl_saved_CFLAGS
> + LDFLAGS=$_isl_saved_LDFLAGS
> + LIBS=$_isl_saved_LIBS
> + fi
> +
> +
> + fi
> fi
>
>
Re: [PATCH] Accept ISL 0.12
On Tue, 3 Sep 2013, Jack Howarth wrote:
> On Tue, Sep 03, 2013 at 12:04:51PM +0200, Richard Biener wrote:
> >
> > The following patch makes us accept ISL 0.12.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu (with using ISL 0.12),
> > applied as obvious.
>
> Richard,
>Does this also accept isl 0.12.1 as that is the current bug fix release...
>
> http://repo.or.cz/w/isl.git/shortlog/0e737ed0b35803685e9ebcfd8c528e00c30bbc43
>
> from upstream.
Yes.
> Jack
>
> >
> > Richard.
> >
> > 2013-09-03 Richard Biener
> >
> > * configure.ac: Also allow ISL 0.12.
> > * configure: Regenerated.
> >
> > Index: configure.ac
> > ===
> > *** configure.ac(revision 202203)
> > --- configure.ac(working copy)
> > *** if test "x$with_isl" != "xno" &&
> > *** 1653,1658
> > --- 1653,1661
> > ISL_CHECK_VERSION(0,10)
> > if test "${gcc_cv_isl}" = no ; then
> > ISL_CHECK_VERSION(0,11)
> > + if test "${gcc_cv_isl}" = no ; then
> > + ISL_CHECK_VERSION(0,12)
> > + fi
> > fi
> > dnl Only execute fail-action, if ISL has been requested.
> > ISL_IF_FAILED([
> > Index: configure
> > ===
> > *** configure (revision 202203)
> > --- configure (working copy)
> > *** $as_echo "$gcc_cv_isl" >&6; }
> > *** 5965,5970
> > --- 5965,6019
> > fi
> >
> >
> > + if test "${gcc_cv_isl}" = no ; then
> > +
> > + if test "${ENABLE_ISL_CHECK}" = yes ; then
> > + _isl_saved_CFLAGS=$CFLAGS
> > + _isl_saved_LDFLAGS=$LDFLAGS
> > + _isl_saved_LIBS=$LIBS
> > +
> > + CFLAGS="${_isl_saved_CFLAGS} ${islinc} ${gmpinc}"
> > + LDFLAGS="${_isl_saved_LDFLAGS} ${isllibs}"
> > + LIBS="${_isl_saved_LIBS} -lisl"
> > +
> > + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for version 0.12 of
> > ISL" >&5
> > + $as_echo_n "checking for version 0.12 of ISL... " >&6; }
> > + if test "$cross_compiling" = yes; then :
> > + gcc_cv_isl=yes
> > + else
> > + cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> > + /* end confdefs.h. */
> > + #include
> > +#include
> > + int
> > + main ()
> > + {
> > + if (strncmp (isl_version (), "isl-0.12", strlen ("isl-0.12")) != 0)
> > + return 1;
> > +
> > + ;
> > + return 0;
> > + }
> > + _ACEOF
> > + if ac_fn_c_try_run "$LINENO"; then :
> > + gcc_cv_isl=yes
> > + else
> > + gcc_cv_isl=no
> > + fi
> > + rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
> > + conftest.$ac_objext conftest.beam conftest.$ac_ext
> > + fi
> > +
> > + { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_isl" >&5
> > + $as_echo "$gcc_cv_isl" >&6; }
> > +
> > + CFLAGS=$_isl_saved_CFLAGS
> > + LDFLAGS=$_isl_saved_LDFLAGS
> > + LIBS=$_isl_saved_LIBS
> > + fi
> > +
> > +
> > + fi
> > fi
> >
> >
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend
Re: folding (vec_)cond_expr in a binary operation
(attaching the latest version. I only added comments since regtesting it)
On Tue, 3 Sep 2013, Richard Biener wrote:
Btw, as for the patch I don't like that you basically feed everything into
fold. Yes, I know we do that for conditions because that's quite
important
and nobody has re-written the condition folding as gimple pattern matcher.
I doubt that this transform is important enough to warrant another
exception ;)
I am not sure what you want here. When I notice the pattern (a?b:c) op d, I
need to check whether b op d and c op d are likely to simplify before
transforming it to a?(b op d):(c op d). And currently I can't see any way to
do that other than feeding (b op d) to fold. Even if/when we get a gimple
folder, we will still need to call it in about the same way.
With a gimple folder you'd avoid building trees.
Ah, so the problem is the cost of building those 2 trees? It will indeed
be better when we can avoid it, but I really don't expect the cost to be
that much...
You are testing for
a quite complex pattern here - (a?b:c) & (d?e:f).
But it is really handled in several steps. IIRC:
(a?1:0)&x becomes a?(x&1):0.
Since x is d?1:0, x&1 becomes d?1:0.
a?(d?1:0):0 is not (yet?) simplified further.
Now if we compare to 0: a?(d?1:0):0 != 0 simplifies to a?(d?1:0)!=0:0
then a?(d?-1:0):0 and finally a?d:0.
Each step can also trigger individually.
It seems to be that
for example
+ vec c=(a>3)?o:z;
+ vec d=(b>2)?o:z;
+ vec e=c&d;
would be better suited in the combine phase (you are interested in
combining the comparisons). That is, look for a [&|^] b where
a and b are [VEC_]COND_EXPRs with the same values.
Hmm, I am already looking for a binary op which has at least one operand
which is a [VEC_]COND_EXPR, in the combine (=backward) part of
tree-ssa-forwprop. Isn't that almost what you are suggesting?
Heh, and it's not obvious to me with looking for a minute what this
should be simplified to ...
(a?x:y)&(b?x:y) doesn't really simplify in general.
(so the code and the testcase needs some
comments on what you are trying to catch ...)
aIndex: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 202185)
+++ tree-ssa-forwprop.c (working copy)
@@ -363,23 +363,20 @@ combine_cond_expr_cond (gimple stmt, enu
gcc_assert (TREE_CODE_CLASS (code) == tcc_comparison);
fold_defer_overflow_warnings ();
t = fold_binary_loc (gimple_location (stmt), code, type, op0, op1);
if (!t)
{
fold_undefer_overflow_warnings (false, NULL, 0);
return NULL_TREE;
}
- /* Require that we got a boolean type out if we put one in. */
- gcc_assert (TREE_CODE (TREE_TYPE (t)) == TREE_CODE (type));
-
/* Canonicalize the combined condition for use in a COND_EXPR. */
t = canonicalize_cond_expr_cond (t);
/* Bail out if we required an invariant but didn't get one. */
if (!t || (invariant_only && !is_gimple_min_invariant (t)))
{
fold_undefer_overflow_warnings (false, NULL, 0);
return NULL_TREE;
}
@@ -1135,20 +1132,131 @@ forward_propagate_comparison (gimple_stm
/* Remove defining statements. */
return remove_prop_source_from_use (name);
bailout:
gsi_next (defgsi);
return false;
}
+/* Combine the binary operation defined in *GSI with one of its arguments
+ that is a condition, i.e. (A ? B : C) op D becomes A ? (B op D) : (C op D).
+ Returns 1 if there were any changes made, 2 if cfg-cleanup needs to
+ run. Else it returns 0. */
+
+static int
+combine_binop_with_condition (gimple_stmt_iterator *gsi)
+{
+ gimple stmt = gsi_stmt (*gsi);
+ tree type = TREE_TYPE (gimple_assign_lhs (stmt));
+ enum tree_code code = gimple_assign_rhs_code (stmt);
+ tree rhs1 = gimple_assign_rhs1 (stmt);
+ tree rhs2 = gimple_assign_rhs2 (stmt);
+ gimple def_stmt;
+ enum tree_code defcode;
+ bool trueok = false;
+ bool falseok = false;
+ tree true_op, false_op;
+ location_t loc = gimple_location (stmt);
+
+ if (TREE_CODE (rhs1) != SSA_NAME)
+goto second_op;
+
+ def_stmt = get_prop_source_stmt (rhs1, true, NULL);
+ if (!def_stmt || !can_propagate_from (def_stmt))
+goto second_op;
+
+ defcode = gimple_assign_rhs_code (def_stmt);
+ if (defcode != COND_EXPR && defcode != VEC_COND_EXPR)
+goto second_op;
+
+ true_op = fold_build2_loc (loc, code, type, gimple_assign_rhs2 (def_stmt),
+gimple_assign_rhs2 (stmt));
+ false_op = fold_build2_loc (loc, code, type, gimple_assign_rhs3 (def_stmt),
+ gimple_assign_rhs2 (stmt));
+
+ if (is_gimple_val (true_op))
+trueok = true;
+ if (is_gimple_val (false_op))
+falseok = true;
+ /* At least one of them has to simplify, or it isn't worth it. */
+ if (!trueok && !falseok)
+goto second_op;
+ if (!trueok)
+{
+ if (!valid_gimple_rhs_p (true_op))
+ goto second_op;
+ gimple g = gimple_build_assign (make_ssa_name (type, NULL),
Re: Symtab cleanup 10/17 remove unnecesary DECL_ARGUMENTS and DECL_RESULT
> > The decision what should go to local or global stream is basically > > motivated by > > 1) everything needed for interprocedural optimization has to be global > > 2) everything related to function bodies should be local. > > I'd rather formulate it as "everything not needed at WPA time should be > local if it can be local" OK. With additional rule that we want to have at least something local, or the local sections are pointless. > > > For tree nodes, the decision about where the node goes is made by > > tree_is_indexable. The current set of rules is > > - parm_decl/result_decl is local > >(before my change resut_decl was global and parm_decl was local, why > > those > > was not the same escapes me, but it needed ugly fixup in ipa-prop that > > needed to reconnect global DECL pointers to local DECL pointers after > > streaming in) > > - function variables are local if they are not static. > >(Even external declarations are local, not only automatic vars.) > > - Types are global unless they are variably modified types > >(The variably modified type code walks into subtypes, so even pointers > >to variably modified type are local or function declarations mentioning > >these.) > > - FIELD_DECL is global unless it is part of variably modified type. > > - SSA_NAME is local despite logic of tree_is_indexable because it is > > handled > >separately as part of gimple and gimple is always local. > > - LABEL_DECLs are global even when their address is not taken and it would > > make > >more sense to hide it in the body sections > > > > Now I think we are safe only when our references never violate A) and B) > > and moreover > > C) same entity that needs to be unique (such as declarations by one decl > > rule > >or BLOCK) is not streamed into multiple streams. We never merge things > >between streams and duplicating those is forbidden by design. > > > > It is an irritating property of our streaming machinery that it is not > > diagnozing violations of A/B/C. Violations of type A and B are basically > > hidden > > by introducing violations of type C and compiler tends to be resistant to > > those > > in a sense that is usually does not ICE. > > Yes, and with the re-organized streaming we can now do much better and > much faster! This is because with the SCC finding we can record in O(SCC > size) > whether a) the SCC contains entities that are local (and to what function) or > global, b) the SCC refers to other SCCs that are local (and in what function) > We can then detect whether we run into the situation that the new SCC refers > to SCCs that are in different local sections (which would mean those > SCCs in turn > would need to be globalized or that the current SCC needs to be duplicated > into > all local sections it refers to). > > I would not be surprised if our current tree structures, when strictly > following > restrictions A) and B) would need to be either all global or all duplicated > into > the local sections :/ > > At least we can now more easily formalize this (and can compute > "scc_is_indexable" which is the property we need now) I did not think of this. SCC code can definitely help us to not put into local section an SCC component that contains something that needs to be global. This is pretty cool in a way that tree_is_indexable don't need to do the closure itself (as it does for variadic types currently). I think the common case however is that you have variable A that is local. SCC streaming will make it local since it see no must be global entities in that var. Later you stream separate SCC component containing a type whose size depends on A. SCC already made A local and you get a violation. > > Another alternative I can think of is to declare duplication in between > > streams > > sane and allowed, but teach streaming in code to patch in the in-memory > > representation from global stream by local stream one when this happens. It > > seems bit tricky to implement - the decl states of functions would need to > > explicitly record the duplications in between local and global streams. > > I think duplication is what we do right now, otherwise we couldn't fill in all > tree references at streaming time. Yes, we duplicate and that leads to illformed IL. > > What we need to do is compute the decision once per SCC during the > SCC build and record statistics on how many trees we'll duplicate that > way (not sure if we even properly duplicate them now with the SCC streaming > ...) Except that we need plan for the scenario above. Honza > > Richard. > > > Honza
Re: Symtab cleanup 10/17 remove unnecesary DECL_ARGUMENTS and DECL_RESULT
On Tue, Sep 3, 2013 at 3:42 PM, Jan Hubicka wrote: >> > The decision what should go to local or global stream is basically >> > motivated by >> > 1) everything needed for interprocedural optimization has to be global >> > 2) everything related to function bodies should be local. >> >> I'd rather formulate it as "everything not needed at WPA time should be >> local if it can be local" > > OK. With additional rule that we want to have at least something local, > or the local sections are pointless. >> >> > For tree nodes, the decision about where the node goes is made by >> > tree_is_indexable. The current set of rules is >> > - parm_decl/result_decl is local >> >(before my change resut_decl was global and parm_decl was local, why >> > those >> > was not the same escapes me, but it needed ugly fixup in ipa-prop that >> > needed to reconnect global DECL pointers to local DECL pointers after >> > streaming in) >> > - function variables are local if they are not static. >> >(Even external declarations are local, not only automatic vars.) >> > - Types are global unless they are variably modified types >> >(The variably modified type code walks into subtypes, so even pointers >> >to variably modified type are local or function declarations mentioning >> >these.) >> > - FIELD_DECL is global unless it is part of variably modified type. >> > - SSA_NAME is local despite logic of tree_is_indexable because it is >> > handled >> >separately as part of gimple and gimple is always local. >> > - LABEL_DECLs are global even when their address is not taken and it >> > would make >> >more sense to hide it in the body sections >> > >> > Now I think we are safe only when our references never violate A) and B) >> > and moreover >> > C) same entity that needs to be unique (such as declarations by one decl >> > rule >> >or BLOCK) is not streamed into multiple streams. We never merge things >> >between streams and duplicating those is forbidden by design. >> > >> > It is an irritating property of our streaming machinery that it is not >> > diagnozing violations of A/B/C. Violations of type A and B are basically >> > hidden >> > by introducing violations of type C and compiler tends to be resistant to >> > those >> > in a sense that is usually does not ICE. >> >> Yes, and with the re-organized streaming we can now do much better and >> much faster! This is because with the SCC finding we can record in O(SCC >> size) >> whether a) the SCC contains entities that are local (and to what function) or >> global, b) the SCC refers to other SCCs that are local (and in what function) >> We can then detect whether we run into the situation that the new SCC refers >> to SCCs that are in different local sections (which would mean those >> SCCs in turn >> would need to be globalized or that the current SCC needs to be duplicated >> into >> all local sections it refers to). >> >> I would not be surprised if our current tree structures, when strictly >> following >> restrictions A) and B) would need to be either all global or all duplicated >> into >> the local sections :/ >> >> At least we can now more easily formalize this (and can compute >> "scc_is_indexable" which is the property we need now) > > I did not think of this. SCC code can definitely help us to not put into > local > section an SCC component that contains something that needs to be global. > This > is pretty cool in a way that tree_is_indexable don't need to do the closure > itself (as it does for variadic types currently). > > I think the common case however is that you have variable A that is local. > SCC > streaming will make it local since it see no must be global entities in that > var. Later you stream separate SCC component containing a type whose size > depends on A. SCC already made A local and you get a violation. You get a violation if you cannot make the separate SCC local in the same section as A or global. Once the separate SCC refers to a local entity it has to be local itself. The only problem is if it refers to two local entities in different local sections ... in which case we need to duplicate (or figure out a way to break one of the references). >> > Another alternative I can think of is to declare duplication in between >> > streams >> > sane and allowed, but teach streaming in code to patch in the in-memory >> > representation from global stream by local stream one when this happens. >> > It >> > seems bit tricky to implement - the decl states of functions would need to >> > explicitly record the duplications in between local and global streams. >> >> I think duplication is what we do right now, otherwise we couldn't fill in >> all >> tree references at streaming time. > > Yes, we duplicate and that leads to illformed IL. >> >> What we need to do is compute the decision once per SCC during the >> SCC build and record statistics on how many trees we'll duplicate that >> w
[PATCH]: Fix use of __builtin_eh_pointer in EH_ELSE
Hi,
The field state->ehp_region wasn't updated before lowering constructs in the eh
path of EH_ELSE. As a consequence, __builtin_eh_pointer is lowered to 0 (or
possibly to a wrong region number) in this path.
The only user of EH_ELSE looks to be trans-mem.c:lower_transaction, and the
consequence of that is a memory leak.
Furthermore, according to calls.c:flags_from_decl_or_type, the
"transaction_pure"
attribute must be set on the function type, not on the function declaration.
Hence the change to declare __builtin_eh_pointer.
(I don't understand the guard condition to set the attribute for it in tree.c.
Why is 'builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1)' needed in addition to
flag_tm ?)
No regressions (check-host) on x86-64 GNU/Linux.
Ok for trunk ?
Tristan.
2013-09-03 Tristan Gingold
* tree.c (set_call_expr_flags): Reject ECF_TM_PURE.
(build_common_builtin_nodes): Set "transaction_pure"
attribute on __builtin_eh_pointer function type (and not on
its declaration).
* tree-eh.c (lower_try_finally_nofallthru): Set and revert
ehp_region before callinf lower_eh_constructs_1.
(lower_try_finally_onedest): Likewise.
(lower_try_finally_copy): Likewise.
(lower_try_finally_switch): Likewise.
testsuite/
2013-09-03 Tristan Gingold
* gcc.dg/tm/except.c: New testcase.
diff --git a/gcc/testsuite/gcc.dg/tm/except.c b/gcc/testsuite/gcc.dg/tm/except.c
new file mode 100644
index 000..ed84bb3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tm/except.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-options "-fgnu-tm -O1 -fexceptions -fdump-tree-optimized" } */
+
+typedef struct node {
+ int val;
+ struct node *next;
+} node_t;
+
+node_t *head;
+
+__attribute__((transaction_safe))
+node_t *new_node(int val, node_t *next);
+
+int add(int val)
+{
+ int result;
+ node_t *prev, *next;
+
+ __transaction_atomic {
+prev = head;
+next = prev->next;
+while (next->val < val) {
+ prev = next;
+ next = prev->next;
+}
+result = (next->val != val);
+if (result) {
+ prev->next = new_node(val, next);
+}
+ }
+ return result;
+}
+
+/* { dg-final { scan-tree-dump-not "ITM_commitTransactionEH \\(0B\\)"
"optimized" } } */
+
+/* { dg-final { cleanup-tree-dump "optimized" } } */
diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 6ffbd26..86ee77e 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -1093,8 +1093,12 @@ lower_try_finally_nofallthru (struct leh_state *state,
if (tf->may_throw)
{
+ eh_region prev_ehp_region = state->ehp_region;
+
finally = gimple_eh_else_e_body (eh_else);
+ state->ehp_region = tf->region;
lower_eh_constructs_1 (state, &finally);
+ state->ehp_region = prev_ehp_region;
emit_post_landing_pad (&eh_seq, tf->region);
gimple_seq_add_seq (&eh_seq, finally);
@@ -1129,6 +1133,7 @@ lower_try_finally_onedest (struct leh_state *state,
struct leh_tf_state *tf)
gimple_stmt_iterator gsi;
tree finally_label;
location_t loc = gimple_location (tf->try_finally_expr);
+ eh_region prev_ehp_region = state->ehp_region;
finally = gimple_try_cleanup (tf->top_p);
tf->top_p_seq = gimple_try_eval (tf->top_p);
@@ -1140,12 +1145,16 @@ lower_try_finally_onedest (struct leh_state *state,
struct leh_tf_state *tf)
if (x)
{
if (tf->may_throw)
- finally = gimple_eh_else_e_body (x);
+ {
+ state->ehp_region = tf->region;
+ finally = gimple_eh_else_e_body (x);
+ }
else
finally = gimple_eh_else_n_body (x);
}
lower_eh_constructs_1 (state, &finally);
+ state->ehp_region = prev_ehp_region;
for (gsi = gsi_start (finally); !gsi_end_p (gsi); gsi_next (&gsi))
{
@@ -1255,13 +1264,19 @@ lower_try_finally_copy (struct leh_state *state, struct
leh_tf_state *tf)
if (tf->may_throw)
{
+ eh_region prev_ehp_region = state->ehp_region;
+
/* We don't need to copy the EH path of EH_ELSE,
since it is only emitted once. */
if (eh_else)
- seq = gimple_eh_else_e_body (eh_else);
+ {
+ seq = gimple_eh_else_e_body (eh_else);
+ state->ehp_region = tf->region;
+ }
else
seq = lower_try_finally_dup_block (finally, state, tf_loc);
lower_eh_constructs_1 (state, &seq);
+ state->ehp_region = prev_ehp_region;
emit_post_landing_pad (&eh_seq, tf->region);
gimple_seq_add_seq (&eh_seq, seq);
@@ -1432,8 +1447,12 @@ lower_try_finally_switch (struct leh_state *state,
struct leh_tf_state *tf)
{
if (tf->may_throw)
{
+ eh_region prev_ehp_region = state->ehp_region;
+
+ state->ehp_region = tf->region;
finally = gimple_eh_else_e_body (eh_else);
lower_eh_constructs_1 (state, &finally);
+ state->ehp_region = prev_ehp_region;
emit_post_landing_pad (&eh_seq, tf->region);
gimple_se
Re: [PING][PATCH] Fix PR58139 by correctly initializing reg_raw_mode[]
On 08/27/2013 02:00 PM, Peter Bergner wrote: > I'd like to ping the following patch which fixes a wrong code bug > on powerpc64-linux due to a lost dependency within the scheduler: > > Fix PR58139 by correctly initializing reg_raw_mode[] > > http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00910.html > > H.J., can you please try and SPEC test this patch on Intel to > make sure we don't regress you? Thanks. > Peter, sorry for the delay. I was on two week vacation. The patch is ok for the trunk. I'd wait for some time (may be 2 weeks) before committing it for gcc-4.8 as it might affect other targets (especially code generation through regno_reg_rtx). In perspective, if it works, we could remove get_raw_result_mode and get_raw_arg_mode hooks used currently only by IA64. Thanks.
[C++ Patch] PR 58305
Hi,
I think it's rather clear that we should warn in this case too, that is,
when we have:
ToBeDeprecated();
for a deprecated ToBeDeprecated type. Note however in my patchlet the
check on the TREE_CODE: if I remove it, then we also warn for the lines
x = e;
and
y = S::f;
of g++.dg/parse/attr3.C. This seems wrong per our documentation, because
those lines do not *name* the deprecated types E and F, but may make
sense, for example clang++ *does* warn on those.
Tested x86_64-linux.
Thanks!
Paolo.
/cp
2013-09-03 Paolo Carlini
PR c++/58305
* semantics.c (finish_expr_stmt): Maybe warn_deprecated_use.
/testsuite
2013-09-03 Paolo Carlini
PR c++/58305
* g++.dg/warn/deprecated-8.C: New.
Index: cp/semantics.c
===
--- cp/semantics.c (revision 202217)
+++ cp/semantics.c (working copy)
@@ -620,6 +620,9 @@ finish_expr_stmt (tree expr)
{
if (warn_sequence_point)
verify_sequence_points (expr);
+ if (TREE_CODE (expr) == TARGET_EXPR
+ && TREE_DEPRECATED (TREE_TYPE (expr)))
+ warn_deprecated_use (TREE_TYPE (expr), NULL_TREE);
expr = convert_to_void (expr, ICV_STATEMENT, tf_warning_or_error);
}
else if (!type_dependent_expression_p (expr))
Index: testsuite/g++.dg/warn/deprecated-8.C
===
--- testsuite/g++.dg/warn/deprecated-8.C(revision 0)
+++ testsuite/g++.dg/warn/deprecated-8.C(working copy)
@@ -0,0 +1,10 @@
+// PR c++/58305
+
+class ToBeDeprecated {
+} __attribute__ ((deprecated ("deprecated!")));
+
+int main() {
+ToBeDeprecated(); // { dg-warning "'ToBeDeprecated' is deprecated" }
+ToBeDeprecated x; // { dg-warning "'ToBeDeprecated' is deprecated" }
+return 0;
+}
Re: [PATCH] Fix PR58139 but correctly initializing reg_raw_mode[]
On Fri, Aug 16, 2013 at 02:53:11PM -0500, Peter Bergner wrote: > PR58139 > * gcc/reginfo.c (choose_hard_reg_mode): San through all mode classes > looking for widest mode. Just ChangeLog nits: 1) no gcc/ 2) Scan instead of San 3) PR target/58139 Jakub
[c++-concepts] Class template constraints
Attached is a patch for constrained class templates. It's the 3rd time I've sent it. I added some fixes for bugs discovered after the previous send, and added support for matching constrained declarations in out-of-class member function definitions. 2013-08-02 Andrew Sutton * gcc/cp/pt.c (get_class_bindings): Pass the partial specialization for constraint evaluation. Evaluate constraints, resulting in deduction failure on error. (get_specializaing_template_decl), (get_specialization_constraints), (maybe_new_partial_specialization): New. (maybe_process_partial_specialization): Allow the creation of new types for constrained partial specializations. (process_partial_specialization): Modify the canonical type of constrained partial specializations. (resolve_template_scope): New. Match the template scope to a specialization with appropriate constraints. (lookup_template_class_1): Compare constraints when entering a template scope. Check constraints on lookup. Do not explicitly check alias constraints. (instantiate_class_template_1): Do not explicitly check constraints during class template instantiation. (tsubst_decl): Instantiate the constraints of template declarations. (more_specialized_class): Pass specializations to get_class_bindings(). Compare specialization constraints if the types are equivalent. (most_specialized_class): Pass specialization to get_class_bndings(). * gcc/cp/decl2.c (check_class_fn): Get the decl's requirements from either the current template reqs or from the template parameters. Allow overloading of constrained out-of-class member definitions. * gcc/cp/parser.c (cp_parser_parse_type_parameter): Attach requirements to the current template parameter list. (cp_parser_init_declarator): Parse requires clauses for out-of-class member definitions. Be sure to restore current constraints before exiting the function. (cp_parser_member_declarator): Restore the previous requirements in an early-exit branch. (cp_parser_late_parsing_for_member): Restore constraints after maybe_end_member_template_processing(). (cp_parser_template_declaration_after_exp): Attach constraints to the current template parameters. * gcc/cp/constraint.cc (reduce_template_id): Don't crash when omitting ()'s on constraint calls. (check_requirements): Don't evaluate dependent arguments. (check_constraints): Don't try to evaluate when arguments are dependent. (equivalent_constraints): Optimize the case when a and b are the same constraints. -- Andrew Sutton template.patch Description: Binary data
Re: [PATCH] Don't issue array bound warnings on zero-length arrays
On 09/02/2013 04:27 AM, Richard Biener wrote:
> On Fri, Aug 30, 2013 at 5:13 PM, Meador Inge wrote:
>> Hi All,
>>
>> This patch fixes a minor issue that can occur when issuing array bounds
>> warnings. In GNU C mode we allow empty lists and their upper bound is
>> initialized to -1. This confuses the array bound analysis in VRP and
>> in some cases we end up issuing false positives. This patch fixes
>> the issue by bailing out when a zero-length array is encountered.
>>
>> OK for trunk?
>>
>> gcc/
>>
>> 2013-08-30 Meador Inge
>>
>> * tree-vrp.c (check_array_ref): Bail out no emtpy arrays.
>>
>> gcc/testsuite/
>>
>> 2013-08-30 Meador Inge
>>
>> * gcc.dg/Warray-bounds-11.c: New testcase.
>>
>> Index: gcc/testsuite/gcc.dg/Warray-bounds-11.c
>> ===
>> --- gcc/testsuite/gcc.dg/Warray-bounds-11.c (revision 0)
>> +++ gcc/testsuite/gcc.dg/Warray-bounds-11.c (revision 0)
>> @@ -0,0 +1,12 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -Warray-bounds -std=gnu99" } */
>> +/* Test zero-length arrays for GNU C. */
>> +
>> +unsigned int a[] = { };
>> +unsigned int size_a;
>> +
>> +int test(void)
>> +{
>> + /* This should not warn. */
>> + return size_a ? a[0] : 0;
>> +}
>> Index: gcc/tree-vrp.c
>> ===
>> --- gcc/tree-vrp.c (revision 202088)
>> +++ gcc/tree-vrp.c (working copy)
>> @@ -6137,9 +6137,10 @@ check_array_ref (location_t location, tr
>>low_sub = up_sub = TREE_OPERAND (ref, 1);
>>up_bound = array_ref_up_bound (ref);
>>
>> - /* Can not check flexible arrays. */
>> + /* Can not check flexible arrays or zero-length arrays. */
>>if (!up_bound
>> - || TREE_CODE (up_bound) != INTEGER_CST)
>> + || TREE_CODE (up_bound) != INTEGER_CST
>> + || tree_int_cst_equal (up_bound, integer_minus_one_node))
>
> That doesn't look correct - what if the lower bound is -10? That can
> easily happen
> for Ada, so please revert the patch.
OK.
> And I fail to see why the testcase should
> not warn. Clearly you have a definition of a here and it doesn't have
> an element
> so the access is out of bounds.
Not always, 'size_a' can be zero and the warning is worded such that the out of
bounds access always happens. In fact, changing the code to 'size_a = 0' still
issues a warning.
--
Meador Inge
CodeSourcery / Mentor Embedded
Re: [PATCH] Don't issue array bound warnings on zero-length arrays
On 09/03/2013 10:45 AM, Jakub Jelinek wrote: > On Tue, Sep 03, 2013 at 10:40:16AM -0500, Meador Inge wrote: >>> And I fail to see why the testcase should >>> not warn. Clearly you have a definition of a here and it doesn't have >>> an element >>> so the access is out of bounds. >> >> Not always, 'size_a' can be zero and the warning is worded such that the out >> of >> bounds access always happens. In fact, changing the code to 'size_a = 0' >> still >> issues a warning. > > How would that be different if you had that invalid access in a function > and never called the function, or called it only if (0) or similar? > We don't do reachability analysis, if any code we warn about can be > reachable from main, and still warn about invalid code, this is invalid > code, so it is IMHO just fine to warn about it. True. Perhaps I am getting too caught up in the wording. I thought we typically use "may" for warnings that aren't definitive, but in this case we use "is" (instead of something like "may be"): warning: array subscript is above array bounds [-Warray-bounds] -- Meador Inge CodeSourcery / Mentor Embedded
[PATCH,committed] AIX alias fix
varasm.c do_assemble_alias() calls globalize_decl() before creating an
alias for a global symbol. For FUNCTION_DECLs
ASM_OUTPUT_DEF_FROM_DECLS on AIX globalizes the code label in addition
to the function descriptor globalized by varasm.c. For
non-TREE_PUBLIC decls, the alias is declared as .lglobl for the code
label, but nothing emits the equivalent for the function descriptor.
The appended patch emits the additional lglobl.
Bootstrapped on powerpc-ibm-aix7.1.0.0
Thanks, David
* config/rs6000/rs6000.h (ASM_OUTPUT_DEF_FROM_DECLS): Emit lglobl for
function descriptor.
Index: rs6000.h
===
--- rs6000.h(revision 202225)
+++ rs6000.h(working copy)
@@ -2142,6 +2142,9 @@
fputs ("\t.lglobl\t.", FILE); \
RS6000_OUTPUT_BASENAME (FILE, alias); \
putc ('\n', FILE);\
+ fputs ("\t.lglobl\t", FILE); \
+ RS6000_OUTPUT_BASENAME (FILE, alias); \
+ putc ('\n', FILE);\
} \
fputs ("\t.set\t.", FILE);\
RS6000_OUTPUT_BASENAME (FILE, alias); \
Re: [PATCH] Don't issue array bound warnings on zero-length arrays
On Tue, Sep 03, 2013 at 11:01:17AM -0500, Meador Inge wrote: > On 09/03/2013 10:45 AM, Jakub Jelinek wrote: > > > On Tue, Sep 03, 2013 at 10:40:16AM -0500, Meador Inge wrote: > >>> And I fail to see why the testcase should > >>> not warn. Clearly you have a definition of a here and it doesn't have > >>> an element > >>> so the access is out of bounds. > >> > >> Not always, 'size_a' can be zero and the warning is worded such that the > >> out of > >> bounds access always happens. In fact, changing the code to 'size_a = 0' > >> still > >> issues a warning. > > > > How would that be different if you had that invalid access in a function > > and never called the function, or called it only if (0) or similar? > > We don't do reachability analysis, if any code we warn about can be > > reachable from main, and still warn about invalid code, this is invalid > > code, so it is IMHO just fine to warn about it. > > True. Perhaps I am getting too caught up in the wording. I thought we > typically use "may" for warnings that aren't definitive, but in this case > we use "is" (instead of something like "may be"): > >warning: array subscript is above array bounds [-Warray-bounds] That is only the case for uninit warnings which makes this distinction, no other warning afaik does something similar. And, even for uninit, even if you get is used uninitialized warning, it still may be on dead code, the difference is that if you hit the statement on which it warns, when it is the "is" variant, it means that you use there an uninitialized value, while the "may" variant means you can hit it both with uninitialized or initialized value. If you hit the a[0] statement, you always invoke undefined behavior, so it shouldn't be a "may". Jakub
Re: Type inheritance graph analysis & speculative devirtualization, part 7/7 (speculative devirtualizatoin)
> What is the footprint impact of speculative devirtualization? It is less than 2% of text section and once we solve problems with ipa-prop tracking, I hope it will be less. I hope we now understand better how to devirtualize and I think we can improve non-speculative devirt noticeably. > > Firefox is sensitive to footprint increases, especially on Android startup. That is what Martin's patch is expected to solve. With his ordering only fraction of the text and rodata section needs to be preloaded. We are still chasing some issues there, but it seems that "only" about 10MB is needed (out of 60MB binary). Not accounting dynamic linking of data.rel.ro that adds around another 5MB. It depends on FDO though. Honza
[Patch] Rewrite _StateSeq in regex
This patch fix the optional operator '?' and interval repeating like
"a{3,5}" through rewrite _StateSeq.
After this patch, the assertion supporting shall be the last
significant feature to be implemented.
It's booted and tested under x86_64. It'll be fully tested before committing.
Thanks!
--
Tim Shen
stateseq.patch
Description: Binary data
[PATCH, committed] check_weak_available for AIX
When objdump is not available, check_weak_available is unhappy on AIX.
This hard-codes that AIX supports weak, as is implemented for other
OSes.
Bootstrapped on powerpc-ibm-aix7.1.0.0
Thanks, David
* lib/target-supports.exp (check_weak_available): Return true for AIX.
Index: target-supports.exp
===
--- target-supports.exp (revision 202225)
+++ target-supports.exp (working copy)
@@ -226,6 +226,12 @@
return 1
}
+# All AIX targets should support it
+
+if { [istarget *-*-aix*] } {
+return 1
+}
+
# All solaris2 targets should support it
if { [istarget *-*-solaris2*] } {
Re: [PATCH] Don't issue array bound warnings on zero-length arrays
On Tue, Sep 03, 2013 at 10:40:16AM -0500, Meador Inge wrote: > > And I fail to see why the testcase should > > not warn. Clearly you have a definition of a here and it doesn't have > > an element > > so the access is out of bounds. > > Not always, 'size_a' can be zero and the warning is worded such that the out > of > bounds access always happens. In fact, changing the code to 'size_a = 0' > still > issues a warning. How would that be different if you had that invalid access in a function and never called the function, or called it only if (0) or similar? We don't do reachability analysis, if any code we warn about can be reachable from main, and still warn about invalid code, this is invalid code, so it is IMHO just fine to warn about it. Jakub
Re: [C++ Patch] PR 58305
.. unfortunately the issue isn't so easy because in any case we don't want to warn for typedefs of ToBeDeprecated. Paolo.
Re: [patch][PR/42955] Don't install $(target)/bin/gcc, gfortran, etc.
Ping^2? On 08/22/2013 02:00 PM, Brooks Moses wrote: Ping? On 08/08/2013 02:10 PM, Brooks Moses wrote: As discussed in PR/42955, when GCC is built as a cross-compiler, it will install "gcc", "g++", "c++", and "gfortran" binaries in $(target)/bin, as well as installing the $target-gcc and so forth in bin. However, these binaries in $(target)/bin do not work; they cannot find libexec. More to the point, this bug has been open for three years with no traffic, and the failure started significantly before that. Clearly, making these work is not a priority. Further, these binaries are real files, not symlinks or hard links; they take up actual space. As discussed on the bug, Joseph argues that $(target)/bin "contains executables from binutils for internal use by GCC; that's its sole purpose. The files installed by GCC there aren't used by GCC (rather, the public installed copy of the driver gets used when collect2 needs to call back to the driver), so shouldn't be installed." Thus, this patch, which simply removes these broken executables. Tested by building a cross-compiler and confirming that they are gone, and by building a native compiler and confirming that the expected bin/gcc, bin/g++, bin/c++, and bin/gfortran are still present. Ok to commit? - Brooks 2013-08-08 Brooks Moses PR driver/42955 * Makefile.in: Do not install driver binaries in $(target)/bin. PR driver/42955 * Make-lang.in: Do not install driver binaries in $(target)/bin.
Re: [Patch] Rewrite _StateSeq in regex
Hi, On 09/03/2013 06:26 PM, Tim Shen wrote: * include/bits/regex_compiler.h: Rewrite _Compiler to use new _StateSeq interfaces. nit: when you need more than one line, left align to the '*'. Also never begin a line with ':' (well, this is just common sense ;) Thanks a lot for now, let's see if there are more (substantive) comments... Paolo.
Re: [PATCH, x86] Use vector moves in memmove expanding
> The patch miscompiles the MPFR library on x86 Pentium Pro. Reduced testcase > attached, compile for x86 with -mtune=pentiumpro. Thanks, I'll look at that in the nearest future. Best regards, Michael
Re: [PATCH, x86] Use vector moves in memmove expanding
> Changes were checked into trunk:
> http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00179.html
The patch miscompiles the MPFR library on x86 Pentium Pro. Reduced testcase
attached, compile for x86 with -mtune=pentiumpro.
--
Eric Botcazoustatic void __attribute__((noinline, noclone))
my_memcpy (char *dest, const char *src, int n)
{
__builtin_memcpy (dest, src, n);
}
int
main (void)
{
char a1[4], a2[4];
__builtin_memset (a1, 'a', 4);
__builtin_memset (a2, 'b', 4);
my_memcpy (a2, a1, 4);
if (a2[0] != 'a')
__builtin_abort ();
return 0;
}
Re: [PATCH, x86] Use vector moves in memmove expanding
On Tue, Sep 3, 2013 at 12:05 PM, Michael V. Zolotukhin wrote: >> The patch miscompiles the MPFR library on x86 Pentium Pro. Reduced testcase >> attached, compile for x86 with -mtune=pentiumpro. > Thanks, I'll look at that in the nearest future. > > Best regards, Michael The problem is testb $2, %bl je .L6 It should be cmpb instead of testb. -- H.J.
Re: [PATCH 1/4] Support lambda templates.
On 03.09.2013 04:50, Jason Merrill wrote:
On 09/02/2013 05:18 PM, Adam Butcher wrote:
> will focus on the parameter pack stuff (when I get a chance).
>
Sounds good.
I had a quick hack at getting pack expansion working for the conversion
op.
The syntactic side seems to be okay. It gets all the way to finalizing
the tu.
It generates suitable diagnostics if I force warnings in various places
in my
testcase.
I've done what amounts to the following (diff hand edited to removing
noisy
debug logging and temporaries):
--
@@ -795,20 +794,39 @@ maybe_add_lambda_conv_op (tree type)
while (src)
{
- if (FUNCTION_PARAMETER_PACK_P (src))
- return;
+ tree new_node = copy_node (src);
if (!fn_args)
- fn_args = tgt = copy_node (src);
+ fn_args = tgt = new_node;
else
{
- TREE_CHAIN (tgt) = copy_node (src);
- tgt = TREE_CHAIN (tgt);
+ TREE_CHAIN (tgt) = new_node;
+ tgt = new_node;
}
mark_exp_read (tgt);
+
+ if (FUNCTION_PARAMETER_PACK_P (tgt))
+ vec_safe_push (argvec, make_pack_expansion (tgt));
+ else
vec_safe_push (argvec,
generic_lambda_p ? convert_from_reference
(tgt) : tgt);
src = TREE_CHAIN (src);
}
--
Problem is that no RTL is set for the incoming parms in the
instantiation of
the expansion. It ICEs in gimple_expand_cfg because 'DECL_RTL_IF_SET
(var)'
returns nullptr for the incoming parms resulting in a failed assertion
that
SA.partition_to_pseudo[i] is non-null.
What follows below is basically a dump of various info that may help
you to
point me in the right direction or may be completely useless or
unnecessary to
you.
Any ideas appreciated.
Cheers,
Adam
The error diagnostic is:
/home/ajb/t7-variadic-ptr.cpp: In static member function ‘static
decltype (((main()::...)>)0u).operator()(main::__lambda1::_FUN:: ...))
main()_FUN(P ...) [with P = {double, double, double};
decltype (((main()::...)>)0u).operator()(main::__lambda1::_FUN:: ...)) = float]’:
/home/ajb/t7-variadic-ptr.cpp:13:37: internal compiler error: in
gimple_expand_cfg, at cfgexpand.c:4649
auto g = [] (P...) { return 3.f; };
^
This only occurs if I instantiate the conversion op.
I added the following tracing to gimple_expand_cfg:
--
@@ -4635,9 +4635,17 @@ gimple_expand_cfg (void)
{
tree var = SSA_NAME_VAR (partition_to_var (SA.map, i));
+ debug_tree (var);
+
+ if (TREE_CODE (var) != VAR_DECL)
+fprintf (stderr, "SA.partition_to_pseudo[%d] == %p\n", i,
SA.partition_to_pseudo[i]);
+
if (TREE_CODE (var) != VAR_DECL
&& !SA.partition_to_pseudo[i])
+ {
SA.partition_to_pseudo[i] = DECL_RTL_IF_SET (var);
+ fprintf (stderr, "SA.partition_to_pseudo[%d] => %p\n", i,
SA.partition_to_pseudo[i]);
+ }
gcc_assert (SA.partition_to_pseudo[i]);
/* If this decl was marked as living in multiple places, reset
--
I expected the instantiated parm_decl for the pack expansion parms to
look
similar to this (from a 'normal' non-pack parm) ...
unit size
align 32 symtab 0 alias set -1 canonical type 0x7f3833f83f18
precision 32
pointer_to_this >
used SF file /home/ajb/t7-variadic-ptr.cpp line 12 col 30 size
unit size
align 32 context
(mem/c:SF (plus:DI (reg/f:DI 70 virtual-stack-vars)
(const_int -20 [0xffec])) [0 D.2134+0 S4 A32])
arg-type
incoming-rtl (reg:SF 21 xmm0 [ D.2134 ])>
... but instead it looks like this:
unit size
align 64 symtab 0 alias set -1 canonical type 0x7f3833f8d000
precision 64
pointer_to_this >
used VOID file /home/ajb/t7-variadic-ptr.cpp line 13 col 34
align 8
arg-type chain 0x7f38340e4680 D.2146>>
Everything under the tree type seems to be 'default' and I note that
context
has gone (it is there in the pack expansion expression prior to
instantiation). I'm not sure if this is relevant.
(note I was passing 3 doubles into the variadic template and a float
into the 'plain' single arg template)
Here's some dumps of the expansion creation from
maybe_add_lambda_conv_op:
SRC =>
>
type_0 type_6 VOID
align 8 symtab 0 alias set -1 structural equality>
decl_1 VOID file /home/ajb/t7-variadic-ptr.cpp line 13 col 34
align 8 context
>
NEW_NODE =>
>
type_0 type_6 VOID
align 8 symtab 0 alias set -1 structural equality>
decl_1 VOID file /home/ajb/t7-variadic-ptr.cpp line 13 col 34
align 8 context
>
MAKE_PACK_EXPANSION =>
>
type_0 type_6 VOID
align 8 symtab 0 alias set -1 structural equality>
arg 0 0x7f0ae00a0498>
decl_1 VOID file /home/ajb/t7-variadic-ptr.cpp line 13 col 34
align 8 context
>
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
I have fixed my test code and replaced those aliasing violations with
unions. Now the test result shows logb() is safe for the conversions.
The conclusion is, logb() and fabs() are always safe for the
converion, and sqrt() is unsafe for the conversion from sqrtl(double)
to sqrt(double). Other math functions are not safe for the conversion.
The new test code I used is shown below:
#include
#include
#include
#include
typedef union
{
int i;
float f;
} T32;
typedef union
{
long long int i;
double f;
} T64;
#define N 1000
#define test_math_func(func) \
for (i = 0; i < N; ++i) \
{ \
int d = rand(), e = rand(); \
if (d == 0) continue; \
T32 v, r1, r2; \
v.f = (float)e / d; \
r1.f = func(v.f), r2.f = func##f(v.f); \
if (r1.f != r2.f) \
{ \
printf("%s double -> float (%X) %X %X\n", #func, v.i, r1.i, r2.i); \
break; \
} \
} \
for (i = 0; i < N; ++i) \
{ \
int d = rand(), e = rand(); \
if (d == 0) continue; \
T32 v, r1, r2; \
v.f = (float)e / d; \
r1.f = func##l(v.f), r2.f = func##f(v.f); \
if (r1.f != r2.f) \
{ \
printf("%s long double -> float (%X) %X %X\n", #func, v.i, r1.i, r2.i); \
break; \
} \
} \
for (i = 0; i < N; ++i) \
{ \
int d = rand(), e = rand(); \
if (d == 0) continue; \
T64 v, r1, r2; \
v.f = (double)e / d; \
r1.f = func##l(v.f), r2.f = func(v.f); \
if (r1.f != r2.f) \
{ \
printf("%s long double -> double (%016llX) %016llX %016llX\n",
#func, v.i, r1.i, r2.i); \
break; \
} \
}
int main()
{
int i;
test_math_func(sin);
test_math_func(cos);
test_math_func(sinh);
test_math_func(cosh);
test_math_func(asin);
test_math_func(acos);
test_math_func(asinh);
test_math_func(acosh);
test_math_func(tan);
test_math_func(tanh);
test_math_func(atan);
test_math_func(atanh);
test_math_func(log);
test_math_func(log10);
test_math_func(log1p);
test_math_func(log2);
test_math_func(logb);
test_math_func(cbrt);
test_math_func(erf);
test_math_func(erfc);
test_math_func(exp);
test_math_func(exp2);
test_math_func(expm1);
test_math_func(sqrt);
test_math_func(fabs);
}
I have modified the patch according to this new conclusion. The patch
is pasted as below.
thanks,
Cong
===
--- gcc/convert.c (revision 201891)
+++ gcc/convert.c (working copy)
@@ -135,16 +135,24 @@ convert_to_real (tree type, tree expr)
CASE_MATHFN (COS)
CASE_MATHFN (ERF)
CASE_MATHFN (ERFC)
- CASE_MATHFN (FABS)
CASE_MATHFN (LOG)
CASE_MATHFN (LOG10)
CASE_MATHFN (LOG2)
CASE_MATHFN (LOG1P)
- CASE_MATHFN (LOGB)
CASE_MATHFN (SIN)
- CASE_MATHFN (SQRT)
CASE_MATHFN (TAN)
CASE_MATHFN (TANH)
+/* The above functions are not safe to do this conversion. */
+if (!flag_unsafe_math_optimizations)
+ break;
+ CASE_MATHFN (SQRT)
+/* sqrtl(double) cannot be safely converted to sqrt(double). */
+if (fcode == BUILT_IN_SQRTL &&
+(TYPE_MODE (type) == TYPE_MODE (double_type_node)) &&
+!flag_unsafe_math_optimizations)
+ break;
+ CASE_MATHFN (FABS)
+ CASE_MATHFN (LOGB)
#undef CASE_MATHFN
{
tree arg0 = strip_float_extensions (CALL_EXPR_ARG (expr, 0));
Index: gcc/testsuite/gcc.c-torture/execute/20030125-1.c
===
--- gcc/testsuite/gcc.c-torture/execute/20030125-1.c (revision 201891)
+++ gcc/testsuite/gcc.c-torture/execute/20030125-1.c (working copy)
@@ -44,11 +44,11 @@ __attribute__ ((noinline))
double
sin(double a)
{
- abort ();
+ return a;
}
__attribute__ ((noinline))
float
sinf(float a)
{
- return a;
+ abort ();
}
On Sat, Aug 31, 2013 at 9:24 AM, Joseph S. Myers
wrote:
> On Sat, 31 Aug 2013, Cong Hou wrote:
>
>> > I don't see why it would be unsafe for logb - can you give an example
>> > (exact float input value as hex float, and the values you believe logb
>> > should return for float and double).
>> >
>>
>> Please try the following code (you will get different results whether to
>> use optimization mode):
>>
>> #include
>> #include
>>
>> int main()
>> {
>> int i = 0x3edc67d5;
>> float f = *((float*)&i);
>> float r1 = logb(f);
>> float r2 = logbf(f);
>> printf("%x %x\n", *((int*)&r1), *((int*)&r2));
>> }
>
> (a) Please stop sending HTML email, so your messages reach the mailing
> list, and resend your messages so far to the list. The mailing list needs
> to see the whole of both sides of the discussion of any patch being
> proposed for GCC.
>
> (b) I referred to the values *you believe logb should return*.
> Optimization is not meant to preserve library bugs; the comparison should
> be on the basis of correctly rounded results from both float and double
> functions. The correct return from logb appears to be -2 here, and I get
> that from both logb and logbf with current git glibc. The existence of a
> bug in some old library is not r
Improve jump thread dumping
This finishes passing the entire path of a jump threading opportunity to
register_jump_thread and arranges to dump the entire path when dumping
details.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed onto the trunk.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f798068..0adc930 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2013-09-03 Jeff Law
+
+ * tree-ssa-threadedge.c (thread_across_edge): Record entire path
+ when not threading through a joiner block. Pass joiner/no joiner
+ state to register_jump_thread.
+ * tree-ssa-threadupdate.c (register_jump_thread): Get joiner/no joiner
+ state from argument rather than implying on path length.
+ Dump the entire jump thread path into debugging dump.
+ * tree-flow.h (register_jump_thread): Update prototype.
+
2013-08-29 Xinliang David Li
* tree-vect-data-refs.c (vect_compute_data_ref_alignment):
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 8712a19..dbc88b1 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2013-09-03 Jeff Law
+
+ * tree-ssa/ssa-dom-thread-3.c: Update due to changes in debug
+ dump output.
+
2013-09-03 Meador Inge
Revert:
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c
index d67f869..c2efd15 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c
@@ -43,6 +43,5 @@ expand_one_var (tree var, unsigned char toplevel, unsigned
char really_expand)
}
/* We should thread the jump, through an intermediate block. */
/* { dg-final { scan-tree-dump-times "Threaded" 1 "dom1"} } */
-/* { dg-final { scan-tree-dump-times "one or more intermediate" 1 "dom1"} } */
-/* { dg-final { cleanup-tree-dump "dom1" } } */
+/* { dg-final { scan-tree-dump-times "Registering jump thread .through joiner
block.: \\(.*\\); \\(.*\\); \\(.*\\);" 1 "dom1"} } */
diff --git a/gcc/tree-flow.h b/gcc/tree-flow.h
index ab42470..333e168 100644
--- a/gcc/tree-flow.h
+++ b/gcc/tree-flow.h
@@ -749,7 +749,7 @@ bool may_be_nonaddressable_p (tree expr);
/* In tree-ssa-threadupdate.c. */
extern bool thread_through_all_blocks (bool);
-extern void register_jump_thread (vec);
+extern void register_jump_thread (vec, bool);
/* In gimplify.c */
tree force_gimple_operand_1 (tree, gimple_seq *, gimple_predicate, tree);
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index fc33647..dddcfce 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -901,6 +901,10 @@ thread_across_edge (gimple dummy_cond,
if (dest == e->dest)
goto fail;
+ vec path = vNULL;
+ path.safe_push (e);
+ path.safe_push (taken_edge);
+
/* DEST could be null for a computed jump to an absolute
address. If DEST is not null, then see if we can thread
through it as well, this helps capture secondary effects
@@ -922,7 +926,10 @@ thread_across_edge (gimple dummy_cond,
simplify,
visited);
if (e2)
- taken_edge = e2;
+ {
+ taken_edge = e2;
+ path.safe_push (e2);
+ }
}
while (e2);
BITMAP_FREE (visited);
@@ -931,13 +938,10 @@ thread_across_edge (gimple dummy_cond,
remove_temporary_equivalences (stack);
if (taken_edge)
{
- vec path = vNULL;
propagate_threaded_block_debug_into (taken_edge->dest, e->dest);
- path.safe_push (e);
- path.safe_push (taken_edge);
- register_jump_thread (path);
- path.release ();
+ register_jump_thread (path, false);
}
+ path.release ();
return;
}
}
@@ -1009,7 +1013,7 @@ thread_across_edge (gimple dummy_cond,
{
propagate_threaded_block_debug_into (e3->dest,
taken_edge->dest);
- register_jump_thread (path);
+ register_jump_thread (path, true);
}
}
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index 8a872a3..8e40f66 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -1303,7 +1303,7 @@ thread_through_all_blocks (bool may_peel_loop_headers)
after fixing the SSA graph. */
void
-register_jump_thread (vec path)
+register_jump_thread (vec path, bool through_joiner)
{
/* Convert PATH into 3 edge representation we've been using. This
is temporary until we convert this file to use a path representation
@@ -1312,7 +1312,7 @@ register_jump_thread (vec path)
RE: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets
On Tue, 3 Sep 2013, Bernd Edlinger wrote: > >> The trouble is that AAPCS semantics are incompatible with the default GNU > >> semantics for non-packed structures as well - AAPCS > >> strict-volatile-bitfields is only compatible with --param > >> allow-store-data-races=1, which is not the default for any language > >> variant accepted by GCC (and I say that the default language semantics > >> here should not depend on the target architecture). > > > > As I said it should be easy to fulfil AAPCS requirements if they do not > > violate > > language constrains during code generation and thus warn about accesses > > that are emitted in a way not conforming to AAPCS (a warning at struct > > declaration time would be nicer, but I guess requires more coding and > > thought, > > though at the point we compute DECL_BIT_FIELD_REPRESENTATIVE in > > stor-layout.c would be a suitable place). > > > > Just to make that clear, Sandra's patch tries to follow the AAPCS > requirements, > _even if_ they violate the language constraints. > > Thus -fstrict-volatile-bitfields implies --param allow-store-data-races=1. And my concern is specifically about the defaults - the default for ARM should be the same C/C++ language as on other targets - rather than what happens if someone specifies -fstrict-volatile-bitfields explicitly. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH 1/4] Support lambda templates.
On 09/03/2013 03:50 PM, Adam Butcher wrote: Problem is that no RTL is set for the incoming parms in the instantiation of the expansion. It ICEs in gimple_expand_cfg because 'DECL_RTL_IF_SET (var)' returns nullptr for the incoming parms resulting in a failed assertion that SA.partition_to_pseudo[i] is non-null. Sounds like a problem with how _FUN's parameters are instantiated. I'm not sure why it would be special. Does using a function parameter pack in the lambda body work currently? If so, how are the expanded parameters different? Jason
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
On Tue, 3 Sep 2013, Xinliang David Li wrote: > >From Joseph: > > "The > conversion is not safe for sqrt if the two types are double and long > double and long double is x86 extended, for example." > > This is not reflected in the patch. No, the problem is that it tries to reflect it but hardcodes the specific example I gave, rather than following the logic I explained regarding the precisions of the types involved, which depend on the target. And since I only gave a simplified analysis, for two types when this function deals with cases involving three types, the patch submission needs to include its own analysis for the full generality of three types to justify the logic used (as inequalities involving the three precisions). (I suspect it reduces to the case of two types so you don't need to go into the details of reasoning about floating point to produce the more general analysis. But in any case, it's for the patch submitter to give the full explanation.) -- Joseph S. Myers jos...@codesourcery.com
Go patch committed: Rework closure value passing
This patch changes the way that closure values are passed in the Go
frontend. In June I changed the code to pass a closure value as the
last argument to a function, which required adding descriptor wrapper
functions for all top-level functions to accept and ignore that
argument. This patch changes the code to instead call __go_set_closure
before calling a function and have the function call __go_get_closure
after it is called. This eliminates the need for the descriptor wrapper
functions.
This is also a step toward implementing reflect.MakeFunc, a standard
library function. An implementation of MakeFunc requires retrieving the
closure value without knowing what arguments are passed to the function.
That will be possible via __go_get_closure, when it was not possible
with the older scheme.
It would be nice to be able to use the static chain register here. We
can't, because GCC only permits using the static chain with a known
function, not for an indirect call as is required by Go. In the future
it would be possible to write a target-specific implementation of
__go_set_closure and __go_get_closure to use the static chain register,
or, really, any register not used to pass parameters. This would work
because we would know that both the caller and callee are Go functions,
or are functions that do not use the static chain.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.
Ian
diff -r f571bacb20cc go/expressions.cc
--- a/go/expressions.cc Fri Aug 23 14:03:20 2013 -0700
+++ b/go/expressions.cc Tue Sep 03 14:40:41 2013 -0700
@@ -1382,7 +1382,7 @@
Func_descriptor_expression::Func_descriptor_expression(Named_object* fn)
: Expression(EXPRESSION_FUNC_DESCRIPTOR, fn->location()),
-fn_(fn), dfn_(NULL), dvar_(NULL)
+fn_(fn), dvar_(NULL)
{
go_assert(!fn->is_function() || !fn->func_value()->needs_closure());
}
@@ -1417,18 +1417,6 @@
return Func_descriptor_expression::descriptor_type;
}
-// Copy a Func_descriptor_expression;
-
-Expression*
-Func_descriptor_expression::do_copy()
-{
- Func_descriptor_expression* fde =
-Expression::make_func_descriptor(this->fn_);
- if (this->dfn_ != NULL)
-fde->set_descriptor_wrapper(this->dfn_);
- return fde;
-}
-
// The tree for a function descriptor.
tree
@@ -1455,11 +1443,8 @@
Bvariable* bvar;
if (no->package() != NULL
|| Linemap::is_predeclared_location(no->location()))
-{
- bvar = context->backend()->immutable_struct_reference(var_name, btype,
- loc);
- go_assert(this->dfn_ == NULL);
-}
+bvar = context->backend()->immutable_struct_reference(var_name, btype,
+ loc);
else
{
Location bloc = Linemap::predeclared_location();
@@ -1469,8 +1454,7 @@
bvar = context->backend()->immutable_struct(var_name, is_hidden, false,
btype, bloc);
Expression_list* vals = new Expression_list();
- go_assert(this->dfn_ != NULL);
- vals->push_back(Expression::make_func_code_reference(this->dfn_, bloc));
+ vals->push_back(Expression::make_func_code_reference(this->fn_, bloc));
Expression* init =
Expression::make_struct_composite_literal(this->type(), vals, bloc);
Translate_context bcontext(gogo, NULL, NULL, NULL);
@@ -6792,8 +6776,8 @@
}
Struct_field_list* sfl = new Struct_field_list();
- // The type here is wrong--it should be new_fntype. But we don't
- // have new_fntype yet, and it doesn't really matter.
+ // The type here is wrong--it should be the C function type. But it
+ // doesn't really matter.
Type* vt = Type::make_pointer_type(Type::make_void_type());
sfl->push_back(Struct_field(Typed_identifier("fn.0", vt, loc)));
sfl->push_back(Struct_field(Typed_identifier("val.1",
@@ -6802,18 +6786,18 @@
Type* closure_type = Type::make_struct_type(sfl, loc);
closure_type = Type::make_pointer_type(closure_type);
- Function_type* new_fntype = orig_fntype->copy_with_closure(closure_type);
+ Function_type* new_fntype = orig_fntype->copy_with_names();
Named_object* new_no = gogo->start_function(Gogo::thunk_name(), new_fntype,
false, loc);
+ Variable* cvar = new Variable(closure_type, NULL, false, false, false, loc);
+ cvar->set_is_used();
+ Named_object* cp = Named_object::make_variable("$closure", NULL, cvar);
+ new_no->func_value()->set_closure_var(cp);
+
gogo->start_block(loc);
- Named_object* cp = gogo->lookup("closure.0", NULL);
- go_assert(cp != NULL
- && cp->is_variable()
- && cp->var_value()->is_parameter());
-
// Field 0 of the closure is the function code pointer, field 1 is
// the value on which to invoke the method.
Expression* arg = Expression::make_var_reference(cp, loc);
@@ -6831,7 +6815,7 @@
const Typed_identifier_list* new_params = new_fntype->parameters();
args = new Expression_list();
for (Typed_identifier_list::const_iterator p = new_params->begin();
- p + 1 != new_params->en
-static-libstdc++ breaks building gdb
I'm on a openSUSE 11.4 system with a:
gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
host compiler. When I building gdb trunk, I get a failure to build because
configure tests g++ to see if these work, but gdb links with gcc and 4.5.1
errors out with the flag. You can't set LDFLAGS, because that is given to gcc,
without testing the flag with gcc. So, either:
AC_LANG_PUSH(C++)
goes away, or we need to exclude 4.5 as well. I tested the first approach and
while it gives a message, it doesn't fail the link, so short of rewriting the
test, we need to bump the minor number up 1. I make no claim that 4.6.0
doesn't also fail.
If someone knows when the driver was made to error out with the proper return
code, it would be better to put that into the test instead.
Here is the failure trying to make the first approach work:
configure:4926: checking whether gcc accepts -static-libstdc++ -static-libgcc
configure:4937: gcc -o conftest -g -O2 -static-libstdc++ -static-libgcc
conftest.c >&5
gcc: unrecognized option '-static-libstdc++'
configure:4937: $? = 0
configure:4938: result: yes
Ok?
diff --git a/binutils/configure b/binutils/configure
index a2671fb..d9cb7b8 100755
--- a/binutils/configure
+++ b/binutils/configure
@@ -4981,7 +4981,7 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
-#if (__GNUC__ < 4) || (__GNUC__ == 4 && __GNUC_MINOR__ < 5)
+#if (__GNUC__ < 4) || (__GNUC__ == 4 && __GNUC_MINOR__ < 6)
#error -static-libstdc++ not implemented
#endif
int main() {}
diff --git a/binutils/configure.ac b/binutils/configure.ac
index 04cf83f..c819263 100644
--- a/binutils/configure.ac
+++ b/binutils/configure.ac
@@ -1269,7 +1269,7 @@ if test "$GCC" = yes; then
AC_MSG_CHECKING([whether g++ accepts -static-libstdc++ -static-libgcc])
AC_LANG_PUSH(C++)
AC_LINK_IFELSE([
-#if (__GNUC__ < 4) || (__GNUC__ == 4 && __GNUC_MINOR__ < 5)
+#if (__GNUC__ < 4) || (__GNUC__ == 4 && __GNUC_MINOR__ < 6)
#error -static-libstdc++ not implemented
#endif
int main() {}],
Re: [PATCH] Convert more passes to new dump framework
On Fri, Aug 30, 2013 at 11:28 PM, Sharad Singhai wrote:
>> Found the issue. The stream was incorrectly being closed when it was
>> stderr/stdout. So only the dump output before the first dump_finish
>> call was being emitted to stderr. I fixed this the same way the
>> alt_dump_file was being handled just below - don't close if it is
>> stderr/stdout. Confirmed that this fixes the problem.
>>
>> (So the real ratio between the volume of -fdump-...=stderr and
>> -fopt-info is much higher than what I reported in an earlier email)
>>
>> Is the following patch ok, pending regression tests?
>>
>> 2013-08-30 Teresa Johnson
>>
>> * dumpfile.c (dump_finish): Don't close stderr/stdout.
>>
>> Index: dumpfile.c
>> ===
>> --- dumpfile.c (revision 202059)
>> +++ dumpfile.c (working copy)
>> @@ -450,7 +450,8 @@ dump_finish (int phase)
>>if (phase < 0)
>> return;
>>dfi = get_dump_file_info (phase);
>> - if (dfi->pstream)
>> + if (dfi->pstream && strcmp("stderr", dfi->pfilename) != 0
>> + && strcmp("stdout", dfi->pfilename) != 0)
>> fclose (dfi->pstream);
>>
>>if (dfi->alt_stream && strcmp("stderr", dfi->alt_filename) != 0
>
> Yes, this is clearly a bug which I missed. Thanks for fixing it. Is it
> feasible to add a test case for it?
>
> Thanks,
> Sharad
Good idea. I modified an existing test to dump to stderr instead of a
dump file. Since it has 2 functions with messages from each, I
confirmed that it exposed the bug.
Here is the full patch. Bootstrapped and tested on
x86_64-unknown-linux-gnu. Ok for trunk?
Thanks,
Teresa
2013-09-03 Teresa Johnson
* dumpfile.c (dump_finish): Don't close stderr/stdout.
* testsuite/gcc.dg/unroll_1.c: Test dumping to stderr.
Index: dumpfile.c
===
--- dumpfile.c (revision 202121)
+++ dumpfile.c (working copy)
@@ -450,7 +450,9 @@ dump_finish (int phase)
if (phase < 0)
return;
dfi = get_dump_file_info (phase);
- if (dfi->pstream)
+ if (dfi->pstream && (!dfi->pfilename
+ || (strcmp("stderr", dfi->pfilename) != 0
+ && strcmp("stdout", dfi->pfilename) != 0)))
fclose (dfi->pstream);
if (dfi->alt_stream && strcmp("stderr", dfi->alt_filename) != 0
Index: testsuite/gcc.dg/unroll_1.c
===
--- testsuite/gcc.dg/unroll_1.c (revision 202121)
+++ testsuite/gcc.dg/unroll_1.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-rtl-loop2_unroll -fno-peel-loops
-fdisable-tree-cunroll -fdisable-tree-cunrolli
-fenable-rtl-loop2_unroll" } */
+/* { dg-options "-O2 -fdump-rtl-loop2_unroll=stderr -fno-peel-loops
-fdisable-tree-cunroll -fdisable-tree-cunrolli
-fenable-rtl-loop2_unroll" } */
unsigned a[100], b[100];
inline void bar()
@@ -11,7 +11,7 @@ int foo(void)
{
int i;
bar();
- for (i = 0; i < 2; i++)
+ for (i = 0; i < 2; i++) /* { dg-message "note: loop turned into
non-loop; it never loops" } */
{
a[i]= b[i] + 1;
}
@@ -21,12 +21,10 @@ int foo(void)
int foo2(void)
{
int i;
- for (i = 0; i < 2; i++)
+ for (i = 0; i < 2; i++) /* { dg-message "note: loop turned into
non-loop; it never loops" } */
{
a[i]= b[i] + 1;
}
return 1;
}
-
-/* { dg-final { scan-rtl-dump-times "loop turned into non-loop; it
never loops" 2 "loop2_unroll" } } */
-/* { dg-final { cleanup-rtl-dump "loop2_unroll" } } */
+/* { dg-prune-output ".*" } */
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: -static-libstdc++ breaks building gdb
On Tuesday 03 September 2013 17:39:10 Mike Stump wrote: > host compiler. When I building gdb trunk, I get a failure to build because > configure tests g++ to see if these work, but gdb links with gcc and 4.5.1 > errors out with the flag. You can't set LDFLAGS, because that is given to > gcc, without testing the flag with gcc. So, either: it's a bug in gcc code. random subdirs (like binutils) shouldn't be working around it: http://gcc.gnu.org/PR56750 -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
Could you please tell me how to check the precision of long double in GCC on different platforms? Thank you! Cong On Tue, Sep 3, 2013 at 2:43 PM, Joseph S. Myers wrote: > On Tue, 3 Sep 2013, Xinliang David Li wrote: > >> >From Joseph: >> >> "The >> conversion is not safe for sqrt if the two types are double and long >> double and long double is x86 extended, for example." >> >> This is not reflected in the patch. > > No, the problem is that it tries to reflect it but hardcodes the specific > example I gave, rather than following the logic I explained regarding the > precisions of the types involved, which depend on the target. And since I > only gave a simplified analysis, for two types when this function deals > with cases involving three types, the patch submission needs to include > its own analysis for the full generality of three types to justify the > logic used (as inequalities involving the three precisions). (I suspect > it reduces to the case of two types so you don't need to go into the > details of reasoning about floating point to produce the more general > analysis. But in any case, it's for the patch submitter to give the full > explanation.) > > -- > Joseph S. Myers > jos...@codesourcery.com
Re: -static-libstdc++ breaks building gdb
On Sep 3, 2013, at 2:39 PM, Mike Stump wrote: > I'm on a openSUSE 11.4 system with a: > > gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585] > > host compiler. When I building gdb trunk, I get a failure to build because > configure tests g++ to see if these work, but gdb links with gcc and 4.5.1 > errors out with the flag. You can't set LDFLAGS, because that is given to > gcc, without testing the flag with gcc. Hum, I was confused by other build errors. I was assuming that the diagnostic: gcc: unrecognized option '-static-libstdc++' was necessary to fix to get the link to not fail. I was wrong. It is however, unsightly.
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
On Tue, 3 Sep 2013, Cong Hou wrote: > + CASE_MATHFN (SQRT) > +/* sqrtl(double) cannot be safely converted to sqrt(double). */ > +if (fcode == BUILT_IN_SQRTL && > +(TYPE_MODE (type) == TYPE_MODE (double_type_node)) && > +!flag_unsafe_math_optimizations) > + break; Please reread my previous messages on this subject and try again, with regard to both the patch itself and the accompanying analysis. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
>From Joseph: "The conversion is not safe for sqrt if the two types are double and long double and long double is x86 extended, for example." This is not reflected in the patch. David On Tue, Sep 3, 2013 at 2:27 PM, Joseph S. Myers wrote: > On Tue, 3 Sep 2013, Cong Hou wrote: > >> + CASE_MATHFN (SQRT) >> +/* sqrtl(double) cannot be safely converted to sqrt(double). */ >> +if (fcode == BUILT_IN_SQRTL && >> +(TYPE_MODE (type) == TYPE_MODE (double_type_node)) && >> +!flag_unsafe_math_optimizations) >> + break; > > Please reread my previous messages on this subject and try again, with > regard to both the patch itself and the accompanying analysis. > > -- > Joseph S. Myers > jos...@codesourcery.com
Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion
This is a patch to prevent scheduler from scheduling compare and
branch away, in order to increase macro-fusion opportunity on recent
x86 platforms. It is motivated by the following small testcase.
double __attribute__ ((noinline)) bar (double sum);
int a[100];
double bar (double sum)
{
int i;
for (i = 0; i < 100; i++)
sum += (0.5 + (a[i%100] - 128));
return sum;
}
int main() {
double total;
int i;
for (i = 0; i < 1000; i++)
total += bar (i);
return total != 0.333;
}
~/workarea/gcc-r201963/build/install/bin/gcc -O2 -mtune=corei7-avx 1.c -o 1.out
The binary of the kernel loop in func bar () is:
401180: 89 c8 mov%ecx,%eax
401182: 66 0f 57 c9 xorpd %xmm1,%xmm1
401186: f7 ee imul %esi
401188: 89 c8 mov%ecx,%eax
40118a: c1 f8 1fsar$0x1f,%eax
40118d: c1 fa 05sar$0x5,%edx
401190: 29 c2 sub%eax,%edx
401192: b8 64 00 00 00 mov$0x64,%eax
401197: 0f af d0imul %eax,%edx
40119a: 89 c8 mov%ecx,%eax
40119c: 83 c1 01add$0x1,%ecx
40119f: 29 d0 sub%edx,%eax
4011a1: 48 98 cltq
4011a3: 8b 04 85 60 51 6c 00mov0x6c5160(,%rax,4),%eax
4011aa: 83 c0 80add$0xff80,%eax
4011ad: 81 f9 40 42 0f 00 cmp$0xf4240,%ecx
4011b3: f2 0f 2a c8 cvtsi2sd %eax,%xmm1
4011b7: f2 0f 58 ca addsd %xmm2,%xmm1
4011bb: f2 0f 58 c1 addsd %xmm1,%xmm0
4011bf: 75 bf jne401180
Here cmp (addr: 4011ad) and jne (addr: 4011bf) are not consecutive in
object code, but they are consecutive before sched2 pass. If we
manually keep the cmp and jne together, the performance of 1.out
changes from 2.40s to 2.31s on a sandybridge machine. Perf stat result
shows that UOPS_RETIRED.MACRO_FUSED event increases from 131,075 to
1,000,130,308, and UOPS_RETIRED.ANY event decreases from
23,002,543,637 to 22,002,511,525.
The patch is to reschedule cmp and jmp to make them consecutive. It is
done at the end of scheduling each block before schedule result is
commited. bootstrapped and regression ok on x86_64-linux-gnu. ok for
trunk?
2013-09-03 Wei Mi
* haifa-sched.c (move_insns): New function.
(adjust_for_macro_fusion): Ditto.
(schedule_block): Call adjust_for_macro_fusion before commit schedule.
* doc/tm.texi.in: Generated.
* doc/tm.texi: Ditto.
* config/i386/x86-tune.def (DEF_TUNE): Add m_COREI7 for
X86_TUNE_FUSE_CMP_AND_BRANCH.
* config/i386/i386.c (ix86_macro_fusion_p): New function.
(ix86_macro_fusion_pair_p): Ditto.
* target.def: Add macro_fusion_p and macro_fusion_pair_p in sched
group.
Index: haifa-sched.c
===
--- haifa-sched.c (revision 201963)
+++ haifa-sched.c (working copy)
@@ -5605,6 +5605,56 @@ choose_ready (struct ready_list *ready,
}
}
+/* Move insn scheduled_insns[I] to the position J in scheduled_insns. */
+
+static void
+move_insns (int i, int j)
+{
+ rtx insn = scheduled_insns[i];
+ scheduled_insns.ordered_remove (i);
+ scheduled_insns.safe_insert (j, insn);
+}
+
+/* If the last cond jump and the cond register setting insn are consecutive
+ before scheduling, and are scheduled away from each other, this func
+ tries to rearrange insns in scheduled_insns and keep those two insns
+ together. This is good for performance on microarchitectures supporting
+ macro-fusion. */
+
+static void
+adjust_for_macro_fusion ()
+{
+ int i = -1, length;
+ unsigned int condreg1, condreg2;
+ rtx cc_reg_1;
+ rtx insn;
+ rtx last = scheduled_insns.last();
+
+ targetm.fixed_condition_code_regs (&condreg1, &condreg2);
+ cc_reg_1 = gen_rtx_REG (CCmode, condreg1);
+ length = scheduled_insns.length ();
+ if (any_condjump_p (last) && reg_referenced_p (cc_reg_1, PATTERN (last)))
+{
+ for (i = length - 2; i >= 0; i--)
+ {
+ insn = scheduled_insns[i];
+ if (modified_in_p (cc_reg_1, insn))
+break;
+ }
+}
+ if (i < 0 || i == length - 2)
+return;
+
+ if (NEXT_INSN (insn) != last)
+return;
+
+ if (!targetm.sched.macro_fusion_pair_p
+ || !targetm.sched.macro_fusion_pair_p (insn, last))
+return;
+
+ move_insns (i, length - 2);
+}
+
/* This function is called when we have successfully scheduled a
block. It uses the schedule stored in the scheduled_insns vector
to rearrange the RTL. PREV_HEAD is used as the anchor to which we
@@ -6421,6 +6471,9 @@ schedule_block (basic_block *target_bb,
if (success)
{
+ if (targetm.sched.macro_fusion_p
+ && targetm.sched.macro_fusio
Re: [PATCH] Enable non-complex math builtins from C99 for Bionic
On Thu, Aug 22, 2013 at 05:04:21PM +0400, Alexander Ivchenko wrote: > Ugh.. thanks, you are right. That points to another problem that I > didn't see before: > > 3) *linux* targets that do not append to tm_p_file (s390x-*-linux* and > s390x-ibm-tpf* - your patch addresses that problem correctly) OR > tmake_file (bfin*-linux-uclibc* or crisv32-*-linux* | cris-*-linux*) > > (btw bfin*-linux-uclibc* or crisv32-*-linux* | cris-*-linux* are > broken now anyways: > > opening glibc-c.o: No such file or directory > make[1]: *** [cc1-checksum.c] Error 1 > make[1]: *** Waiting for unfinished jobs...) > > Sorry again for the inconvenience, here is the updated patch that now, > hopefully, fixes the issues with my initial patch. > (Andreas patch still needs to be applied) > > Is it OK? > > diff --git a/gcc/ChangeLog b/gcc/ChangeLog > index 6e27be2..2d15fb1 100644 > --- a/gcc/ChangeLog > +++ b/gcc/ChangeLog > @@ -1,3 +1,17 @@ > +2013-08-21 Alexander Ivchenko > + > + * config/linux-android.c (linux_android_libc_has_function): Fix > + checks for libc. > + * config/bfin/uclinux.h: Define TARGET_LIBC_HAS_FUNCTION as > + no_c99_libc_has_function. > + * config/c6x/uclinux-elf.h: Ditto. > + * config/lm32/uclinux-elf.h: Ditto. > + * config/m68k/uclinux.h: Ditto. > + * config/moxie/uclinux.h: Ditto. > + * config.gcc (bfin*-linux-uclibc*): Add t-linux-android to tmake_file. > + (crisv32-*-linux*, cris-*-linux*): Ditto. > + * config/bfin/bfin.c: Include "tm_p.h". > + > 2013-08-21 Joern Rennecke > > * reload.h (struct reg_equivs): Rename to .. Please do not put diff's of the ChangeLog file in the patch. Instead you should have the ChangeLog parts in the message, and if it is more than a few lines, the patch (without the ChangeLog bits) should be a separate attachment. That allows us to apply the patch without an error. I just got back from vacation, and noticed the powerpc linux compiler no longer builds, and I've been reading my old mail from the last week or so. I suspect we will need similar patches for the powerpc. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
On Tue, 3 Sep 2013, Cong Hou wrote: > Could you please tell me how to check the precision of long double in > GCC on different platforms? REAL_MODE_FORMAT (TYPE_MODE (long_double_type_node))->p (but you should be referring to the relevant types - "type", the type being converted to, "itype", the type of the function being called in the source code, "TREE_TYPE (arg0)", the type of the argument after extensions have been removed, and "newtype", computed from those - so you should have expressions like the above with two or more of those four types, but not with long_double_type_node directly). The patch submission will need to include a proper analysis to justify to the reader why the particular inequality with particular types from those four is correct in all cases where the relevant code may be executed. -- Joseph S. Myers jos...@codesourcery.com
Re: [C++ Patch] PR 58305
On 09/03/2013 11:10 AM, Paolo Carlini wrote: ToBeDeprecated(); I'd rather handle this case in build_functional_cast. Jason
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
On 4 September 2013 00:17:00 Cong Hou wrote: Could you please tell me how to check the precision of long double in GCC on different platforms? I did not follow your discussion but.. http://uclibc.org/~aldot/precision_check.f Or something along those lines in your favourite language. HTH.. Thank you! Cong Sent with AquaMail for Android http://www.aqua-mail.com
Re: [C++ Patch] PR 58305
On 09/03/2013 11:32 PM, Jason Merrill wrote:
On 09/03/2013 11:10 AM, Paolo Carlini wrote:
ToBeDeprecated();
I'd rather handle this case in build_functional_cast.
Indeed. Thanks for the great tip. A tried to find a place where I could
use the same check we have in grokdeclarator, involving DECL_ARTIFICIAL
on a TYPE_DECL, but failed, shame on me.
Anyway, I'm finishing testing the below on x86_64-linux.
Thanks,
Paolo.
///
/cp
2013-09-03 Paolo Carlini
PR c++/58305
* typeck2.c (build_functional_cast): Maybe warn_deprecated_use.
/testsuite
2013-09-03 Paolo Carlini
PR c++/58305
* g++.dg/warn/deprecated-8.C: New.
Index: cp/typeck2.c
===
--- cp/typeck2.c(revision 202231)
+++ cp/typeck2.c(working copy)
@@ -1761,7 +1761,14 @@ build_functional_cast (tree exp, tree parms, tsubs
return error_mark_node;
if (TREE_CODE (exp) == TYPE_DECL)
-type = TREE_TYPE (exp);
+{
+ type = TREE_TYPE (exp);
+
+ if (complain & tf_warning
+ && TREE_DEPRECATED (type)
+ && DECL_ARTIFICIAL (exp))
+ warn_deprecated_use (type, NULL_TREE);
+}
else
type = exp;
Index: testsuite/g++.dg/warn/deprecated-8.C
===
--- testsuite/g++.dg/warn/deprecated-8.C(revision 0)
+++ testsuite/g++.dg/warn/deprecated-8.C(working copy)
@@ -0,0 +1,15 @@
+// PR c++/58305
+
+class ToBeDeprecated {
+} __attribute__ ((deprecated ("deprecated!")));
+
+typedef ToBeDeprecated NotToBeDeprecated; // { dg-warning "'ToBeDeprecated' is
deprecated" }
+
+int main() {
+
+ ToBeDeprecated();// { dg-warning "'ToBeDeprecated' is deprecated" }
+ ToBeDeprecated x;// { dg-warning "'ToBeDeprecated' is deprecated" }
+
+ NotToBeDeprecated();
+ NotToBeDeprecated y;
+}
Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
On Mon, 2013-09-02 at 13:44 +0200, Michael Matz wrote: > Hi, > > On Fri, 30 Aug 2013, David Malcolm wrote: > > > Here's the result of a pair of builds of r202029 without and with the > > patches, configured with --enable-checking=release, running "make", then > > stripping debuginfo [1] > > > > So the overall sizes of such binaries are essentially unchanged. > > Yep, cool. > > > Any suggestions on what to compile to compare performance? By 60 > > seconds, do you mean 60s for one TU, or do you mean a large build e.g. > > the linux kernel? > > For one TU, so as to not measure any significant execve, as or IO > overhead. Some people compile e.g preprocessed variants of some GCC > source file, myself I'm measuring such speeds since some years with > unchanged versions of the attached (big-code.c, several large functions > with arithmetics and one-deep loops) which can be customized > by hand to produce different largeness and kdecore.cc [1] (real world C++ > library code from 2009). > > You can customize big-code.c to match some compile time goal by > commenting out some FUNC invocation for some types, or by changing the > body size of the functions by fiddling in the FUNC macro itself to invoke > more of the L2's or even L3's, but that's really slow. Thanks. Everyone seems to have their own benchmarking test files - I'd like to gather those that I can into a common repository. What license is big-code.c under? Presumably kdecore.cc is from a compile of KDE and thus covered by the license of that (plus of all the headers that were included, I guess). I scripted compilation of each of big-code.c and kdecore.cc at -O3, using the cc1plus from each of the builds described above, 10 times (i.e. the build of r202029 without (control) and with the patches (experiment), both configured with --enable-checking=release, running "make", then stripping debuginfo). I wrote a script to parse the "TOTAL" timevar data from the logs, extracting the total timings for user, sys, and wallclock, and the ggc memory total. I used some code from Python's benchmarking suite to determine whether the observed difference is "significant", and to draw comparative graphs of the data (actually, to generate URLs to Google's Chart API). There were no significant differences for these data between the cc1plus with the patch and the cc1plus without. The script uses Student's two-tailed T test on the benchmark results at the 95% confidence level to determine significance, but it also has a cutoff in which when the averages are within 1% of each other they are treated as "insignificant". If I remove the cutoff, then the kdecore.cc wallclock time is reported as *faster* with the patch (t=2.41) - but by a tiny amount. FWIW this benchmarking code can be seen at: https://github.com/davidmalcolm/gcc-build/commit/4581f080be2ed92179bfc1bc12e0ba9e923adaae Data and URLs to graphs follow: kdecore.cc -O3: usr control: [63.01, 63.11, 62.9, 63.14, 63.22, 63.0, 63.21, 63.03, 63.07, 63.09] experiment: [62.94, 63.05, 62.99, 63.03, 63.25, 62.91, 63.14, 62.96, 63.0, 63.04] Min: 62.90 -> 62.91: 1.00x slower Avg: 63.078000 -> 63.031000: 1.00x faster Not significant Stddev: 0.09852 -> 0.10049: 1.0200x larger Timeline: http://goo.gl/8P9mFr kdecore.cc -O3: sys control: [5.85, 5.74, 5.91, 5.79, 5.79, 5.85, 5.81, 5.9, 5.83, 5.8] experiment: [5.8, 5.81, 5.88, 5.88, 5.77, 5.87, 5.69, 5.8, 5.75, 5.84] Min: 5.74 -> 5.69: 1.01x faster Avg: 5.827000 -> 5.809000: 1.00x faster Not significant Stddev: 0.05229 -> 0.06154: 1.1769x larger Timeline: http://goo.gl/xfWoUL kdecore.cc -O3: wall control: [69.01, 69.01, 68.94, 69.03, 69.13, 68.99, 69.18, 69.07, 69.01, 69.01] experiment: [68.88, 68.97, 68.99, 69.03, 69.12, 68.88, 68.96, 68.86, 68.85, 68.99] Min: 68.94 -> 68.85: 1.00x faster Avg: 69.038000 -> 68.953000: 1.00x faster Not significant Stddev: 0.07052 -> 0.08616: 1.2217x larger Timeline: http://goo.gl/Pf9BL8 kdecore.cc -O3: ggc control: [988589.0, 988591.0, 988585.0, 988582.0, 988584.0, 988589.0, 988585.0, 988582.0, 988584.0, 988586.0] experiment: [988593.0, 988585.0, 988589.0, 988585.0, 988591.0, 988588.0, 988591.0, 988585.0, 988589.0, 988590.0] Mem max: 988591.000 -> 988593.000: 1.x larger Usage over time: http://goo.gl/4pxB8Y big-code.c -O3: usr control: [60.06, 60.31, 60.33, 60.29, 60.28, 60.26, 60.41, 60.28, 60.29, 60.29] experiment: [59.9, 60.14, 60.27, 60.33, 60.22, 60.33, 60.31, 60.33, 60.16, 60.26] Min: 60.06 -> 59.90: 1.00x faster Avg: 60.28 -> 60.225000: 1.00x faster Not significant Stddev: 0.08781 -> 0.13360: 1.5215x larger Timeline: http://goo.gl/gkFbgi big-code.c -O3: sys control: [1.32, 1.37, 1.34, 1.41, 1.35, 1.34, 1.29, 1.36, 1.33, 1.35] experiment: [1.38, 1.35, 1.32, 1.32, 1.33, 1.33, 1.34, 1.32, 1.41, 1.35] Min: 1.29 -> 1.32: 1.02x slower Avg: 1.346000 -> 1.345000: 1.00x faster Not significant Stddev: 0.03169 -> 0.02
Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
On Mon, 2013-09-02 at 13:44 +0200, Michael Matz wrote: > Hi, > > On Fri, 30 Aug 2013, David Malcolm wrote: > [...] > > > And the manual GTY markers are so not maintainable in the long run, > > > gengtype or something else really needs to be taught to create them > > > automatically. > > > > Apart from the GTY aspect, how do people feel about the patch series? > > Generally I like it, the parts I don't like are common to all the > C++ification patches [2]. The manual GTY parts give me the creeps, but I > think I expressed that already :) > > > Ciao, > Michael. > [1] http://frakked.de/~matz/kdecore.cc.gz > [2] In this series it's the is_a/has_a/dyn_cast uglification, > - gcc_gimple_checking_assert (gimple_has_mem_ops (g)); > - g->gsmembase.vuse = vuse; > + gimple_statement_with_memory_ops *mem_ops_stmt = > +as_a (g); > + mem_ops_stmt->vuse = vuse; > > I can't really say I find this shorter, easier to read, more > expressive or even safer than what was there before. And the > repetition for adding the helpers for const and non-const types > all the time doesn't make it better. Part of this is the verbose struct names. I mentioned getting rid of the "_statement" part of the typenames, I think I'll do that. The other part is that the accessor functions become redundant, and that you'd be able to do the cast once, and then use all of the various fields of a gimple_whatever, bypassing the getters/setters. > (Btw: something for your helper script: it's customary to put the > '=' to the next line; I know there is precedent for your variant, > but '=' on next line is prevalent) Thanks; I'll fix that.
Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
On Mon, 2013-09-02 at 14:35 +0200, Martin Jambor wrote: > Hi, > > On Fri, Aug 30, 2013 at 03:21:22PM -0400, David Malcolm wrote: > > Apart from the GTY aspect, how do people feel about the patch series? > > FWIW I have vague thoughts about doing something similar for tree - > > doing so *might* give an easier route to the type vs expression > > separation that Andrew spoke about at the Cauldron rearchitecture BoF. > > (I started looking at doing a similar C++-ification of rtx, but... > > gah) > > > > I like it but before you start looking at the biger things, could you > perhpas proceed with the symtab? It has much fewer classes, will > probably affect private development of fewer people, the accessor > macros/functions of symtab are less developed so it will immediately > really make code nicer, Honza has approved it and I'm really looking > forward to it. Also, perhaps it will show us at much saller scale > potential problems with the general scheme. Sorry about the delay. I wasn't aware that it had been approved; there seemed to be a lot of caveats and objections in that thread. On re-reading, http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01147.html could be seen as approval, but I guess I was making a conservative reading of that post. I hope to refresh the patches and reboostrap/repost them at some point this week. > I'm only writing this because the development there seems a bit > stalled and it it a shame. Of course, you ay want to simplify the > manual markings first. I'd perfectly understand that. I've been poking at gengtype (and running benchmarks; see other post), which would affect the symtab patch, though it's something of a quagmire...
[patch, bz #58312] Fix libssp handling of vsnprintf for cross-compilers
Jakub et al - The attached patch fixes bug 58312, by replacing the runtime check of vsnprintf with a compile-time check -- which means that it now performs the same checks for both native and cross compilers, ensuring consistency instead of the previous behavior of just discarding some libssp functions when cross-compiling. I've tested this by reconfiguring (on an x86-linux cross configuration) and confirming that it behaves as expected -- the HAVE_USABLE_VSNPRINTF macro is defined in confdefs.h, and the config.log has verbosity of output similar to the previous version. (The formerly-explicit output is included as part of the AC_CHECK_FUNC macro.) It is possible that this will enable the macro on some native configurations where vsnprintf was present but is broken. The effect is simply that a few additional functions (which rely on vsnprintf) are compiled into libssp; this seems relatively innocuous. Jakub, I'm cc'ing you in hopes that you're a reasonably appropriate person to review this. Ok for trunk? Thanks, - Brooks 2013-09-03 Brooks Moses * configure.ac: Replace runtime vsnprintf check with compile-time check. * configure: Regenerate. 2013-09-03_libssp-configure.diff Description: Binary data
[C++ Patch] PR 24926
Hi,
of the various access control issues we have got, this one seems rather
manageable.
It seems to me that in case of nested anonymous aggregates what is
needed to get the access control right is just a bit of recursion, to
completely propagate the access from the outer to the inner aggregates.
The patch seems large but in fact just moves to a recursive helper the
code that currently handles anonymous aggregates in finish_struct_anon.
Patch appears to work well, no regressions etc, I'm not 100% sure we
couldn't simplify a bit the new finish_struct_anon_r.
Thanks!
Paolo.
/cp
2013-09-04
PR c++/24926
* class.c (finish_struct_anon_r): New.
(finish_struct_anon): Use it.
/testsuite
2013-09-04
PR c++/24926
* g++.dg/parse/access11.C: New.
Index: cp/class.c
===
--- cp/class.c (revision 202231)
+++ cp/class.c (working copy)
@@ -2773,73 +2773,112 @@ warn_hidden (tree t)
}
}
-/* Check for things that are invalid. There are probably plenty of other
- things we should check for also. */
+/* Recursive helper for finish_struct_anon. */
static void
-finish_struct_anon (tree t)
+finish_struct_anon_r (tree field, bool complain)
{
- tree field;
-
- for (field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
+ if (DECL_NAME (field) == NULL_TREE
+ && ANON_AGGR_TYPE_P (TREE_TYPE (field)))
{
- if (TREE_STATIC (field))
- continue;
- if (TREE_CODE (field) != FIELD_DECL)
- continue;
+ bool is_union = TREE_CODE (TREE_TYPE (field)) == UNION_TYPE;
+ tree elt = TYPE_FIELDS (TREE_TYPE (field));
+ for (; elt; elt = DECL_CHAIN (elt))
+ {
+ /* We're generally only interested in entities the user
+declared, but we also find nested classes by noticing
+the TYPE_DECL that we create implicitly. You're
+allowed to put one anonymous union inside another,
+though, so we explicitly tolerate that. We use
+TYPE_ANONYMOUS_P rather than ANON_AGGR_TYPE_P so that
+we also allow unnamed types used for defining fields. */
+ if (DECL_ARTIFICIAL (elt)
+ && (!DECL_IMPLICIT_TYPEDEF_P (elt)
+ || TYPE_ANONYMOUS_P (TREE_TYPE (elt
+ continue;
- if (DECL_NAME (field) == NULL_TREE
- && ANON_AGGR_TYPE_P (TREE_TYPE (field)))
- {
- bool is_union = TREE_CODE (TREE_TYPE (field)) == UNION_TYPE;
- tree elt = TYPE_FIELDS (TREE_TYPE (field));
- for (; elt; elt = DECL_CHAIN (elt))
+ if (!complain && TREE_STATIC (elt))
+ continue;
+
+ if (TREE_CODE (elt) != FIELD_DECL)
{
- /* We're generally only interested in entities the user
-declared, but we also find nested classes by noticing
-the TYPE_DECL that we create implicitly. You're
-allowed to put one anonymous union inside another,
-though, so we explicitly tolerate that. We use
-TYPE_ANONYMOUS_P rather than ANON_AGGR_TYPE_P so that
-we also allow unnamed types used for defining fields. */
- if (DECL_ARTIFICIAL (elt)
- && (!DECL_IMPLICIT_TYPEDEF_P (elt)
- || TYPE_ANONYMOUS_P (TREE_TYPE (elt
- continue;
-
- if (TREE_CODE (elt) != FIELD_DECL)
+ if (complain)
{
if (is_union)
- permerror (input_location, "%q+#D invalid; an anonymous
union can "
+ permerror (input_location,
+ "%q+#D invalid; an anonymous union can "
"only have non-static data members", elt);
else
- permerror (input_location, "%q+#D invalid; an anonymous
struct can "
+ permerror (input_location,
+ "%q+#D invalid; an anonymous struct can "
"only have non-static data members", elt);
- continue;
}
+ continue;
+ }
+ if (complain)
+ {
if (TREE_PRIVATE (elt))
{
if (is_union)
- permerror (input_location, "private member %q+#D in
anonymous union", elt);
+ permerror (input_location,
+ "private member %q+#D in anonymous union",
+ elt);
else
- permerror (input_location, "private member %q+#D in
anonymous struct", elt);
+ permerror (input_location,
+ "private member %q+#D in anonymous struct",
+ elt);
}
else if (TREE_PROTECTED (elt))
{
Re: [PATCH] [lambda] Extract lambda functions from semantics.c.
On Jul 12, 2013, at 11:18 PM, Adam Butcher wrote: > * gcc/cp/semantics.c (build_lambda_expr), > (build_lambda_object), (begin_lambda_type), (lambda_return_type), > (lambda_function), (lambda_capture_field_type), (is_capture_proxy), > (is_normal_capture_proxy), (insert_capture_proxy), > (insert_pending_capture_proxies), (lambda_proxy_type), > (build_capture_proxy), (vla_capture_type), > (register_capture_members), (add_default_capture), > (lambda_expr_this_capture), (maybe_resolve_dummy), > (nonlambda_method_basetype), (maybe_add_lambda_conv_op) and > (is_lambda_ignored_entity): Moved definitions into ... > * gcc/cp/lambda.c: ... this new file. This can cause an incremental build failure because there are no dependencies: diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in index 2c1774f..65dfe08 100644 --- a/gcc/cp/Make-lang.in +++ b/gcc/cp/Make-lang.in @@ -351,6 +351,7 @@ cp/vtable-class-hierarchy.o: cp/vtable-class-hierarchy.c \ cp/name-lookup.o: cp/name-lookup.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ $(TM_H) $(CXX_TREE_H) $(TIMEVAR_H) gt-cp-name-lookup.h $(PARAMS_H) \ $(DIAGNOSTIC_CORE_H) $(FLAGS_H) debug.h pointer-set.h +cp/lambda.o: cp/lambda.c $(CXX_TREE_H) $(CGRAPH_H) $(VEC_H) $(SYSTEM_H) coretypes.h cp/cxx-pretty-print.o: cp/cxx-pretty-print.c $(CXX_PRETTY_PRINT_H) \ $(CONFIG_H) $(SYSTEM_H) $(TM_H) coretypes.h $(CXX_TREE_H) tree-pretty-print.h When tree codes are added or moved, the check is then against the wrong number, and this will kill the build. I'm still looking forward to the day when all the dependancies are unceremoniously ripped out, until then... Ok?
[PATCH] manage dom-walk_data initialization and finalization with constructors and destructors
From: Trevor Saunders
bootstrapped on x86_64-unknown-linux-gnu with same test results as unpatched
r202185 ok?
* compare-elim.c (find_comparisons_in_bb): adjust
* domwalk.c (init_walk_dominator_tree): Convert to dom_walk_data constructor.
(fini_walk_dominator_tree): Convert to dom_walk_data destructor.
* domwalk.h (dom_walk_data::dom_walk_data): declare
(dom_walk_data::~dom_walk_data): declare
(init_walk_dominator_tree): remove
(fini_walk_dominator_tree): remove
* fwprop.c (build_single_def_use_links): adjust
* gimple-ssa-strength-reduction.c (execute_strength_reduction): adjust
* graphite-sese-to-poly.c (build_sese_conditions_after): adjust
* tree-into-ssa.c (rewrite_blocks): adjust
(mark_def_site_blocks): adjust
* tree-ssa-dom.c (tree_ssa_dominator_optimize): adjust
* tree-ssa-dse.c (tree_ssa_dse): adjust
* tree-ssa-loop-im.c (determine_invariantness): adjust
(move_computations): adjust
* tree-ssa-phiopt.c (get_non_trapping): adjust
* tree-ssa-pre.c (eliminate): adjust
* tree-ssa-strlen.c (tree_ssa_strlen): adjust
* tree-ssa-uncprop.c (tree_ssa_uncprop): adjust
diff --git a/gcc/compare-elim.c b/gcc/compare-elim.c
index e907376..8a1e68f 100644
--- a/gcc/compare-elim.c
+++ b/gcc/compare-elim.c
@@ -403,17 +403,13 @@ find_comparisons_in_bb (struct dom_walk_data *data
ATTRIBUTE_UNUSED,
static void
find_comparisons (void)
{
- struct dom_walk_data data;
+ struct dom_walk_data data (CDI_DOMINATORS);
- memset (&data, 0, sizeof(data));
- data.dom_direction = CDI_DOMINATORS;
data.before_dom_children = find_comparisons_in_bb;
calculate_dominance_info (CDI_DOMINATORS);
- init_walk_dominator_tree (&data);
walk_dominator_tree (&data, ENTRY_BLOCK_PTR);
- fini_walk_dominator_tree (&data);
clear_aux_for_blocks ();
free_dominance_info (CDI_DOMINATORS);
diff --git a/gcc/domwalk.c b/gcc/domwalk.c
index 8c1ddc6..bc7a93f 100644
--- a/gcc/domwalk.c
+++ b/gcc/domwalk.c
@@ -261,22 +261,26 @@ walk_dominator_tree (struct dom_walk_data *walk_data,
basic_block bb)
free (worklist);
}
-void
-init_walk_dominator_tree (struct dom_walk_data *walk_data)
+dom_walk_data::dom_walk_data (cdi_direction direction)
+ : dom_direction(direction),
+ initialize_block_local_data (NULL),
+before_dom_children (NULL),
+ after_dom_children (NULL),
+ global_data (NULL),
+block_local_data_size (0)
{
- walk_data->free_block_data.create (0);
- walk_data->block_data_stack.create (0);
+ free_block_data.create (0);
+ block_data_stack.create (0);
}
-void
-fini_walk_dominator_tree (struct dom_walk_data *walk_data)
+dom_walk_data::~dom_walk_data ()
{
- if (walk_data->initialize_block_local_data)
+ if (initialize_block_local_data)
{
- while (walk_data->free_block_data.length () > 0)
- free (walk_data->free_block_data.pop ());
+ while (free_block_data.length () > 0)
+ free (free_block_data.pop ());
}
- walk_data->free_block_data.release ();
- walk_data->block_data_stack.release ();
+ free_block_data.release ();
+ block_data_stack.release ();
}
diff --git a/gcc/domwalk.h b/gcc/domwalk.h
index 54b7f3c..94986c7 100644
--- a/gcc/domwalk.h
+++ b/gcc/domwalk.h
@@ -26,6 +26,10 @@ typedef void *void_p;
struct dom_walk_data
{
+public:
+ dom_walk_data (cdi_direction);
+ ~dom_walk_data ();
+
/* This is the direction of the dominator tree we want to walk. i.e.,
if it is set to CDI_DOMINATORS, then we walk the dominator tree,
if it is set to CDI_POST_DOMINATORS, then we walk the post
@@ -70,5 +74,3 @@ struct dom_walk_data
};
void walk_dominator_tree (struct dom_walk_data *, basic_block);
-void init_walk_dominator_tree (struct dom_walk_data *);
-void fini_walk_dominator_tree (struct dom_walk_data *);
diff --git a/gcc/fwprop.c b/gcc/fwprop.c
index 8fe02ac..e10754b 100644
--- a/gcc/fwprop.c
+++ b/gcc/fwprop.c
@@ -269,8 +269,6 @@ single_def_use_leave_block (struct dom_walk_data *walk_data
ATTRIBUTE_UNUSED,
static void
build_single_def_use_links (void)
{
- struct dom_walk_data walk_data;
-
/* We use the multiple definitions problem to compute our restricted
use-def chains. */
df_set_flags (DF_EQ_NOTES);
@@ -291,14 +289,12 @@ build_single_def_use_links (void)
/* Walk the dominator tree looking for single reaching definitions
dominating the uses. This is similar to how SSA form is built. */
- walk_data.dom_direction = CDI_DOMINATORS;
+ dom_walk_data walk_data (CDI_DOMINATORS);
walk_data.initialize_block_local_data = NULL;
walk_data.before_dom_children = single_def_use_enter_block;
walk_data.after_dom_children = single_def_use_leave_block;
- init_walk_dominator_tree (&walk_data);
walk_dominator_tree (&walk_data, ENTRY_BLOCK_PTR);
- fini_walk_dominator_tree (&walk_data);
BITMAP_FREE (local_lr);
BITMAP_FREE (local_md);
diff --git a/gcc/gimple-ssa-strength-reduction.c
b/gcc/gimple-ssa-strength-reduction.c
index e85e629..240b190 100644
--- a/gcc/gimple-ssa-strength-reduction.c
+++ b/gcc/gimp
Re: [Patch] Rewrite _StateSeq in regex
According to this email(http://gcc.gnu.org/ml/libstdc++/2013-09/msg5.html), I add a testcase. -- Tim Shen stateseq.patch Description: Binary data
Re: [C++ Patch] PR 58305
OK. Jason
Go patch committed: Fix passing fn with multiple results to builtin
This patch from Chris Manghane fixes passing a function that returns
multiple results to a builtin function, as in append(F()) if F returns
two values. That should work since append can take two arguments. This
patch actually makes it work. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.8 branch.
Ian
diff -r f711f44d1105 go/expressions.cc
--- a/go/expressions.cc Tue Sep 03 14:50:27 2013 -0700
+++ b/go/expressions.cc Tue Sep 03 21:29:03 2013 -0700
@@ -9138,35 +9138,27 @@
// Because do_type will return an error type and thus prevent future
// errors, check for that case now to ensure that the error gets
// reported.
- if (this->get_function_type() == NULL)
+ Function_type* fntype = this->get_function_type();
+ if (fntype == NULL)
{
if (!this->fn_->type()->is_error())
this->report_error(_("expected function"));
return Expression::make_error(loc);
}
- // Recognize a call to a builtin function.
- Func_expression* fne = this->fn_->func_expression();
- if (fne != NULL
- && fne->named_object()->is_function_declaration()
- && fne->named_object()->func_declaration_value()->type()->is_builtin())
-return new Builtin_call_expression(gogo, this->fn_, this->args_,
- this->is_varargs_, loc);
-
// Handle an argument which is a call to a function which returns
// multiple results.
if (this->args_ != NULL
&& this->args_->size() == 1
- && this->args_->front()->call_expression() != NULL
- && this->fn_->type()->function_type() != NULL)
-{
- Function_type* fntype = this->fn_->type()->function_type();
+ && this->args_->front()->call_expression() != NULL)
+{
size_t rc = this->args_->front()->call_expression()->result_count();
if (rc > 1
- && fntype->parameters() != NULL
- && (fntype->parameters()->size() == rc
- || (fntype->is_varargs()
- && fntype->parameters()->size() - 1 <= rc)))
+ && ((fntype->parameters() != NULL
+ && (fntype->parameters()->size() == rc
+ || (fntype->is_varargs()
+ && fntype->parameters()->size() - 1 <= rc)))
+ || fntype->is_builtin()))
{
Call_expression* call = this->args_->front()->call_expression();
Expression_list* args = new Expression_list;
@@ -9180,6 +9172,11 @@
}
}
+ // Recognize a call to a builtin function.
+ if (fntype->is_builtin())
+return new Builtin_call_expression(gogo, this->fn_, this->args_,
+ this->is_varargs_, loc);
+
// If this call returns multiple results, create a temporary
// variable for each result.
size_t rc = this->result_count();
@@ -9188,8 +9185,7 @@
std::vector* temps =
new std::vector;
temps->reserve(rc);
- const Typed_identifier_list* results =
- this->fn_->type()->function_type()->results();
+ const Typed_identifier_list* results = fntype->results();
for (Typed_identifier_list::const_iterator p = results->begin();
p != results->end();
++p)
@@ -9204,10 +9200,8 @@
// Handle a call to a varargs function by packaging up the extra
// parameters.
- if (this->fn_->type()->function_type() != NULL
- && this->fn_->type()->function_type()->is_varargs())
-{
- Function_type* fntype = this->fn_->type()->function_type();
+ if (fntype->is_varargs())
+{
const Typed_identifier_list* parameters = fntype->parameters();
go_assert(parameters != NULL && !parameters->empty());
Type* varargs_type = parameters->back().type();
Re: [PATCH] Enable non-complex math builtins from C99 for Bionic
On 23/08/2013, at 1:04 AM, Alexander Ivchenko wrote:
> Ugh.. thanks, you are right. That points to another problem that I
> didn't see before:
>
> 3) *linux* targets that do not append to tm_p_file (s390x-*-linux* and
> s390x-ibm-tpf* - your patch addresses that problem correctly) OR
> tmake_file (bfin*-linux-uclibc* or crisv32-*-linux* | cris-*-linux*)
Could you be more verbose, please? What some of the *linux* target do not
append to tm_p_file?
It seems that there are at least two separate problems:
1. OPTION_BIONIC is not defined in linux-android.c . I think the right fix
here is to copy definitions of OPTION_BIONIC (and, optionally, OPTION_UCLIBC)
from gcc/config/linux.h to rs6000/linux.h, rs6000/linux64.h and alpha/linux.h
-- in other words, define OPTION_BIONIC and OPTION_UCLIBC whenever OPTION_GLIBC
is defined.
2. The second problem is to do with definitions of TARGET_LIBC_HAS_FUNCTION for
bfin, c6x, lm32, m68k and moxie. What is the failure scenario here?
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 7e1d529..89cf30a 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1018,7 +1018,7 @@ bfin*-uclinux*)
> ;;
> bfin*-linux-uclibc*)
> tm_file="${tm_file} dbxelf.h elfos.h bfin/elf.h gnu-user.h linux.h
> glibc-stdint.h bfin/linux.h ./linux-sysroot-suffix.h"
> - tmake_file="bfin/t-bfin-linux t-slibgcc"
> + tmake_file="bfin/t-bfin-linux t-slibgcc t-linux-android"
> use_collect2=no
> ;;
> bfin*-rtems*)
Why? Bfin has nothing to do with android.
> @@ -1053,7 +1053,7 @@ cris-*-elf | cris-*-none)
> crisv32-*-linux* | cris-*-linux*)
> tm_file="dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h
> glibc-stdint.h cris/linux.h"
> # We need to avoid using t-linux, so override default tmake_file
> - tmake_file="cris/t-cris cris/t-linux t-slibgcc"
> + tmake_file="cris/t-cris cris/t-linux t-slibgcc t-linux-android"
> extra_options="${extra_options} cris/linux.opt"
> case $target in
> cris-*-*)
Same question here.
> diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
> index 7fab975..18457f8 100644
> --- a/gcc/config/bfin/bfin.c
> +++ b/gcc/config/bfin/bfin.c
> @@ -46,6 +46,7 @@
> #include "cgraph.h"
> #include "langhooks.h"
> #include "bfin-protos.h"
> +#include "tm_p.h"
> #include "tm-preds.h"
> #include "tm-constrs.h"
> #include "gt-bfin.h"
> diff --git a/gcc/config/bfin/uclinux.h b/gcc/config/bfin/uclinux.h
> index ca0f4ee..63cba99 100644
> --- a/gcc/config/bfin/uclinux.h
> +++ b/gcc/config/bfin/uclinux.h
> @@ -44,3 +44,6 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively. If not, see
> #define TARGET_SUPPORTS_SYNC_CALLS 1
>
> #define SUBTARGET_FDPIC_NOT_SUPPORTED
> +
> +#undef TARGET_LIBC_HAS_FUNCTION
> +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
> diff --git a/gcc/config/c6x/uclinux-elf.h b/gcc/config/c6x/uclinux-elf.h
> index 5d61f4d..fa0937e 100644
> --- a/gcc/config/c6x/uclinux-elf.h
> +++ b/gcc/config/c6x/uclinux-elf.h
> @@ -62,3 +62,5 @@
> : "0" (_beg), "b" (_end), "b" (_scno)); \
> }
>
> +#undef TARGET_LIBC_HAS_FUNCTION
> +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
> diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
> index 4a4b48d..e9d9e9a 100644
> --- a/gcc/config/linux-android.c
> +++ b/gcc/config/linux-android.c
> @@ -35,9 +35,9 @@ linux_android_has_ifunc_p (void)
> bool
> linux_android_libc_has_function (enum function_class fn_class)
> {
> - if (OPTION_GLIBC)
> + if (linux_libc == LIBC_GLIBC)
> return true;
> - if (OPTION_BIONIC)
> + if (linux_libc == LIBC_BIONIC)
> if (fn_class == function_c94
> || fn_class == function_c99_misc
> || fn_class == function_sincos)
The above hunk should not be necessary after (1).
> diff --git a/gcc/config/lm32/uclinux-elf.h b/gcc/config/lm32/uclinux-elf.h
> index 3a556d7..a5e8163 100644
> --- a/gcc/config/lm32/uclinux-elf.h
> +++ b/gcc/config/lm32/uclinux-elf.h
> @@ -77,3 +77,5 @@
> #undef CC1_SPEC
> #define CC1_SPEC "%{G*} %{!fno-PIC:-fPIC}"
>
> +#undef TARGET_LIBC_HAS_FUNCTION
> +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
> diff --git a/gcc/config/m68k/uclinux.h b/gcc/config/m68k/uclinux.h
> index 8d74312..b1af7d2 100644
> --- a/gcc/config/m68k/uclinux.h
> +++ b/gcc/config/m68k/uclinux.h
> @@ -67,3 +67,6 @@ along with GCC; see the file COPYING3. If not see
>sections. */
> #undef M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
> #define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P 1
> +
> +#undef TARGET_LIBC_HAS_FUNCTION
> +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
> diff --git a/gcc/config/moxie/uclinux.h b/gcc/config/moxie/uclinux.h
> index 498037e..85c65f2 100644
> --- a/gcc/config/moxie/uclinux.h
> +++ b/gcc/config/moxie/uclinux.h
> @@ -37,3 +37,6 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively. If not, see
> --wrap=mmap --wrap=munmap --wrap=alloca\
> %{fmudflapth: --wrap=pthread_create\
> }} %{fmudflap|fmudflapth: --wrap=main}"
> +
> +#undef TARGET_LIBC_HAS_FUNCTION
> +#define TARGET_LIBC_HAS_FUN
Re: ELF interposition and One Definition Rule
On 08/28/13 12:52, Jan Hubicka wrote: What is really important for backend is that it is not defined what happens when you compare addresses of those functions (based on fact that youcan't take it, as for ctors/dtors, or compare it, as for virtual functions). If backend also knows that they are not interposable, it knows it can freely duplicate or unify their bodies when it seems win. I think this is the wrong test. It's true that at the language level, these things don't have addresses. But someone trying to use interposition is not working at that level -- they're working at the ELF level (for sake of picking a binary format). At that level, these things do have addresses, just like any other (non-inlined) function. I know of a case where users have expected interposition of member functions to work (ugly though that is). I can't recall whether ctors/dtors or vfuncs were the functions of interest, but that's not really the point. At the binary level, these are just regular functions. nathan
