Re: [ARM] PR 50090: aliases in libgcc.a with default visibility
On 17 August 2011 15:07, Joseph S. Myers wrote: > On Wed, 17 Aug 2011, Richard Sandiford wrote: > >> libgcc/ >> PR target/50090 >> * config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias >> instead of an assembly one. > > Is RENAME_LIBRARY_SET used at all after this patch or should it be > removed? A patch to remove that is pre-approved provided ofcourse this patch has been applied :) Ramana
Re: [PATCH] PR c++/45625 - Template parm name doesn't hide outer class scope's member name
OK. Jason
Re: [PATCH, ARM, iWMMXt][4/5]: WMMX machine description
On 14 July 2011 08:45, Xinyu Qi wrote:
>> Hi,
>>
>> It is the fourth part of iWMMXt maintenance.
>>
Can this be broken down further. ? I'll have to do this again but
there are some initial comments below for some discussion.
>
> Since "*cond_iwmmxt_movsi_insn" would be got rid of soon, I keep it unchanged.
>
> *config/arm/arm.c (arm_output_iwmmxt_shift_immediate): New function.
> (arm_output_iwmmxt_tinsr): Ditto.
s/Ditto/Likewise
> *config/arm/arm-protos.h (arm_output_iwmmxt_shift_immediate): New prototype.
s/New prototype/Declare.
> (arm_output_iwmmxt_tinsr): Ditto.
> *config/arm/iwmmxt.md (WCGR0, WCGR1, WCGR2, WCGR3): New constant.
> (iwmmxt_psadbw, iwmmxt_walign, iwmmxt_tmrc, iwmmxt_tmcr): Delete.
> (iwmmxt_tbcstqi, iwmmxt_tbcsthi, iwmmxt_tbcstsi, *iwmmxt_clrv8qi,
> *iwmmxt_clrv4hi, *iwmmxt_clrv2si): Rename...
> (tbcstv8qi, tbcstv4hi, tbsctv2si, iwmmxt_clrv8qi, iwmmxt_clrv4hi,
> iwmmxt_clrv2si): ...New pattern.
s/...//
> (*and3_iwmmxt, *ior3_iwmmxt, *xor3_iwmmxt, rori3,
> ashri3_iwmmxt, lshri3_iwmmxt, ashli3_iwmmxt,
> iwmmxt_waligni, iwmmxt_walignr, iwmmxt_walignr0, iwmmxt_walignr1,
> iwmmxt_walignr2, iwmmxt_walignr3, iwmmxt_setwcgr0, iwmmxt_setwcgr1,
> iwmmxt_setwcgr2, iwmmxt_setwcgr3, iwmmxt_getwcgr0, iwmmxt_getwcgr1,
> iwmmxt_getwcgr2, iwmmxt_getwcgr3): New pattern.
Break this up into multiple lines. Each line should only have upto 80
characters. Put this on one line and say New and add the others in a
row afterwards and use Likewise.
Look at other patches in the near past which set up Changelogs.
> (*iwmmxt_arm_movdi, *iwmmxt_movsi_insn, iwmmxt_uavgrndv8qi3,
> iwmmxt_uavgrndv4hi3, iwmmxt_uavgv8qi3, iwmmxt_uavgv4hi3, iwmmxt_tinsrb,
> iwmmxt_tinsrh, iwmmxt_tinsrw, eqv8qi3, eqv4hi3, eqv2si3, gtuv8qi3, gtuv4hi3,
> gtuv2si3, gtv8qi3, gtv4hi3, gtv2si3, iwmmxt_wunpckihb, iwmmxt_wunpckihh,
> iwmmxt_wunpckihw, iwmmxt_wunpckilb, iwmmxt_wunpckilh, iwmmxt_wunpckilw,
> iwmmxt_wunpckehub, iwmmxt_wunpckehuh, iwmmxt_wunpckehuw, iwmmxt_wunpckehsb,
> iwmmxt_wunpckehsh, iwmmxt_wunpckehsw, iwmmxt_wunpckelub, iwmmxt_wunpckeluh,
> iwmmxt_wunpckeluw, iwmmxt_wunpckelsb, iwmmxt_wunpckelsh, iwmmxt_wunpckelsw,
> iwmmxt_wmadds, iwmmxt_wmaddu, iwmmxt_wsadb, iwmmxt_wsadh, iwmmxt_wsadbz,
> iwmmxt_wsadhz): Revise.
Revise to do what ?
> (define_insn "*iwmmxt_movsi_insn"
> - [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
> m,z,r,?z,Uy,z")
>- (match_operand:SI 1 "general_operand" "rk, I,K,mi,rk,r,z,Uy,z,
>z"))]
>+ [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,r,rk,
>m,z,r,?z,?Uy,?z,t,r,?t,?z,t")
>+ (match_operand:SI 1 "general_operand" " rk,I,K,N,mi,rk,r,z,Uy, z,
>z,r,t, z, t,t"))]
> "TARGET_REALLY_IWMMXT
>- && ( register_operand (operands[0], SImode)
>- || register_operand (operands[1], SImode))"
>- "*
>- switch (which_alternative)
>+ && ((register_operand (operands[0], SImode)
>+ && (!reload_completed
>+ || REGNO_REG_CLASS (REGNO (operands[0])) == IWMMXT_GR_REGS))
>+ || (register_operand (operands[1], SImode)
>+ && (!reload_completed
> (iwmmxt2.md): Include.
> *config/arm/iwmmxt2.md: New file.
> *config/arm/iterators.md (VMMX2): New mode_iterator.
> *config/arm/arm.md (wtype): New attribute.
> *config/arm/t-arm (MD_INCLUDES): Add iwmmxt2.md.
>
> Thanks,
> Xinyu
>
>+ || REGNO_REG_CLASS (REGNO (operands[1])) == IWMMXT_GR_REGS)))"
I don't like this at all - what you are doing is assuming that after
reg-alloc you are going to be able to rely on whether something has a
particular register class and then turn on and off it's matching. So
this matches before reload and doesn't do so after reload for the
cases where *iwmmxt_movsi_insn is really in a core register. I don't
think you can do it this way. If you really want to do this properly -
have an arch field for iwmmxt as well in the arch attribute and then
add these alternatives to existing patterns.
The documentation states with respect to conditions for a define_insn :
`For nameless patterns, the condition is applied only when matching an
individual insn, and only after the insn has matched the pattern's
recognition template. The insn's operands may be found in the vector
@code{operands}. For an insn where the condition has once matched, it
can't be used to control register allocation, for example by excluding
certain hard registers or hard register combinations.'
If I understand what you are trying to do here - you are trying to use
*arm_movsi_insn and other patterns in the rest of the backend and let
things like "predicable" kick in right after reload for all cases
other than the ones you enumerate. In which case get rid of all the
other constaints in this pattern other than the constraints that are
valid for registers of class IWMMXT_REGS
Also the definition of output_move_double has changed now and hence
this needs some rework.
Should there be a distinction between iwmmxt and iwmmxt2 ? Is it a
user visible option ?
Re: [pph] Fix child references being included multiple times (issue 4904050)
On 11-08-17 22:09 , Gabriel Charette wrote: Can you approve version 1 instead?! Sure, that variant is fine as well. Whichever version better suits your next patch. The documentation is on the variable in the C file directly as I've noticed this is what is done most of the time... I put it at that line in the file because this is where the references from pph-streamer.c are (unless it's different for variables then it is for functions??) I tend to stick globals at the start of the header to make them more visible. Cutting and pasting the same documentation on both places is fine. Thanks. Diego.
Re: [pph] Fix child references being included multiple times (issue 4904050)
Thinking more about this on my way back... I will only need includes directly included by the current pph, not the full include tree as I added in version 2 of this patch thinking I would need it for the line_table... Can you approve version 1 instead?! > http://codereview.appspot.com/4904050/diff/3001/gcc/cp/pph-streamer.h#newcode210 > gcc/cp/pph-streamer.h:210: extern VEC(pph_stream_ptr, heap) > *pph_read_images; >> >> 209 >> 210 extern VEC(pph_stream_ptr, heap) *pph_read_images; > > Move earlier in the file and add documentation. The documentation is on the variable in the C file directly as I've noticed this is what is done most of the time... I put it at that line in the file because this is where the references from pph-streamer.c are (unless it's different for variables then it is for functions??) Cheers, Gab
RE: [PATCH, ARM, iWMMXt][1/5]: ARM code generic change
> -Original Message- > From: Ramana Radhakrishnan [mailto:ramana.radhakrish...@linaro.org] At 2011-08-18 09:29:34,"Ramana Radhakrishnan" wrote: > Hi , > > Sorry about the delayed review - It's taken me a while to get back to this . > > On 14 July 2011 08:35, Xinyu Qi wrote: > >> > Hi, > >> > > >> > It is the first part of iWMMXt maintenance. > >> > > >> > *config/arm/arm.c (arm_option_override): > >> > Enable iWMMXt with VFP. iWMMXt and NEON are incompatible. > >> iWMMXt unsupported under Thumb-2 mode. > >> > (arm_expand_binop_builtin): Accept immediate op (with mode VOID) > >> > *config/arm/arm.md: > >> > Resettle include location of iwmmxt.md so that *arm_movdi > >> and *arm_movsi_insn could be used when iWMMXt is enabled. > > This is OK modulo the Changelog entry. > > Please write this as : > > * config/arm/arm.c (arm_option_override): Enable use of iwMMXt > with VFP. Disable use of iwMMXt and Neon. > * config/arm/arm.md (iwmmxt.md): Include earlier. > (*arm_movsi_insn): Remove check for TARGET_IWMMXT. > (*arm_movdi_insn): Likewise. > > > cheers > Ramana Thanks for reviewing! I remember updating the patch stack according to your previous comment several weeks ago. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01100.html http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01101.html http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01103.html http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01105.html http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01106.html The new ChangLog for this part: *config/arm/arm.c (arm_option_override): Enable use of iWMMXt with VFP. Disable use of iwMMXt and Neon. (arm_expand_binop_builtin): Accept VOIDmode op. *config/arm/arm.md (*arm_movdi, *arm_movsi_insn): Remove check for TARGET_IWMMXT. (iwmmxt.md): Include earlier. Thanks, Xinyu
RE: [PATCH, ARM] Generate conditional compares in Thumb2 state
Attached is the new patch file. Review please! ChangeLog: 2011-08-18 Jiangning Liu * config/arm/arm.md (*ior_scc_scc): Enable for Thumb2 as well. (*ior_scc_scc_cmp): Likewise (*and_scc_scc): Likewise. (*and_scc_scc_cmp): Likewise. (*and_scc_scc_nodom): Likewise. (*cmp_ite0, *cmp_ite1, *cmp_and, *cmp_ior): Handle Thumb2. Testsuite Changelog would be: 2011-08-18 Jiangning Liu * gcc.target/arm/thumb2-cond-cmp-1.c: New. Make sure conditional compare can be generated. * gcc.target/arm/thumb2-cond-cmp-2.c: Likewise. * gcc.target/arm/thumb2-cond-cmp-3.c: Likewise. * gcc.target/arm/thumb2-cond-cmp-4.c: Likewise. Regression test against cortex-M0/M3/M4 profile with "-mthumb" option doesn't show any new failures. Thanks, -Jiangning fix_cond_cmp_5.patch Description: Binary data
Re: [c++] Keep tm, div_t, ldiv_t, lconv mangling on Solaris (PR libstdc++-v3/1773)
On 08/17/2011 09:06 AM, Rainer Orth wrote:
+@deftypefn {Target Hook} tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree
@var{decl})
+Return target-specific mangling context of @var{decl}.
+@end deftypefn
This should say "or NULL_TREE". Otherwise OK.
Jason
Re: [PATCH, ARM, iWMMXt][2/5]: intrinsic head file change
On 6 July 2011 11:11, Xinyu Qi wrote:
> Hi,
>
> It is the second part of iWMMXt maintenance.
>
> *config/arm/mmintrin.h:
> Revise the iWMMXt intrinsics head file. Fix some intrinsics and add some new
> intrinsics
Is there a document somewhere that lists these intrinsics and what
each of these are supposed to be doing ? Missing details again . We
seem to be changing quite a few things.
> +
> +/* We will treat __int64 as a long long type
> +and __m64 as an unsigned long long type to conform to VSC++. */Is
> +typedef unsigned long long __m64;
> +typedef long long __int64;
Interesting this sort of a change with these cases where you are
changing the type to conform to VSC++ ? This just means old code that
uses this is pretty much broken. Not that I have much hope of that
happening by default - -flax-conversions appears to be needed even
with a trunk compiler.
> @@ -54,7 +63,7 @@ _mm_cvtsi64_si32 (__int64 __i)
> static __inline __int64
> _mm_cvtsi32_si64 (int __i)
> {
> - return __i;
> + return (__i & 0x);
> }
Eh ? why the & 0x before promotion rules. Is this set of
intrinsics documented some place ? What is missing and could be the
subject of a follow-up patch is a set of tests for the wMMX intrinsics
What's the behaviour of wandn supposed to be ? Does wandn x, y, z
imply x = y & ~z or x = ~y & z ? If the former then your intrinsic
expansion is wrong unless the meaning of this has changed ? Whats the
behaviour of the intrinsic __mm_and_not_si64 . ?
@@ -985,44 +1004,83 @@ _mm_setzero_si64 (void)
static __inline void
_mm_setwcx (const int __value, const int __regno)
{
> + /*Since gcc has the imformation of all wcgr regs
> +in arm backend, use builtin to access them instead
> +of throw asm directly. Thus, gcc could do some
> +optimization on them. */
> +
Also this comment is contradictory to what follows in the patch .
You've prima-facie replaced them with bits of inline assembler. I'm
not sure this comment makes a lot of sense on its own.
Ramana
Re: [PATCH, ARM, iWMMXt][5/5]: pipeline description
On 6 July 2011 11:18, Xinyu Qi wrote: > Hi, > > It is the fifth part of iWMMXt maintenance. > > *config/arm/marvell-f-iwmmxt.md: New file. Add Marvell WMMX pipeline > description. Needs addition to MD_INCLUDES . where are you including this file ? Ramana > > Thanks, > Xinyu >
Re: [PATCH, ARM, iWMMXt][1/5]: ARM code generic change
Hi , Sorry about the delayed review - It's taken me a while to get back to this . On 14 July 2011 08:35, Xinyu Qi wrote: >> > Hi, >> > >> > It is the first part of iWMMXt maintenance. >> > >> > *config/arm/arm.c (arm_option_override): >> > Enable iWMMXt with VFP. iWMMXt and NEON are incompatible. >> iWMMXt unsupported under Thumb-2 mode. >> > (arm_expand_binop_builtin): Accept immediate op (with mode VOID) >> > *config/arm/arm.md: >> > Resettle include location of iwmmxt.md so that *arm_movdi >> and *arm_movsi_insn could be used when iWMMXt is enabled. This is OK modulo the Changelog entry. Please write this as : * config/arm/arm.c (arm_option_override): Enable use of iwMMXt with VFP. Disable use of iwMMXt and Neon. * config/arm/arm.md (iwmmxt.md): Include earlier. (*arm_movsi_insn): Remove check for TARGET_IWMMXT. (*arm_movdi_insn): Likewise. cheers Ramana
Re: [pph] Fix child references being included multiple times (issue 4904050)
OK with a minor nit. http://codereview.appspot.com/4904050/diff/3001/gcc/cp/pph-streamer.h File gcc/cp/pph-streamer.h (right): http://codereview.appspot.com/4904050/diff/3001/gcc/cp/pph-streamer.h#newcode210 gcc/cp/pph-streamer.h:210: extern VEC(pph_stream_ptr, heap) *pph_read_images; 209 210 extern VEC(pph_stream_ptr, heap) *pph_read_images; Move earlier in the file and add documentation. http://codereview.appspot.com/4904050/
Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)
On Wed, Aug 17, 2011 at 4:59 PM, Hans-Peter Nilsson wrote: > On Tue, 16 Aug 2011, Sriraman Tallam wrote: > > (I don't see anyone else making this comment, so maybe I missed > something obvious, but I don't think so...) > >> Support for getting CPU type and feature information at run-time. >> >> The following patch provides support for finding the platform type at >> run-time, like cpu type and features supported. The multi-versioning >> framework will use the builtins added to dispatch the right function >> version. Please refer to http://gcc.gnu.org/ml/gcc/2011-08/msg00298.html for >> details on function multi-versioning usability. >> >> * tree-pass.h (pass_tree_fold_builtin_target): New pass. >> * builtins.def (BUILT_IN_TARGET_SUPPORTS_CMOV): New builtin. >> (BUILT_IN_TARGET_SUPPORTS_MMX): New builtin. >> (BUILT_IN_TARGET_SUPPORTS_POPCOUNT): New builtin. >> (BUILT_IN_TARGET_SUPPORTS_SSE): New builtin. >> (BUILT_IN_TARGET_SUPPORTS_SSE2): New builtin. >> (BUILT_IN_TARGET_SUPPORTS_SSE3): New builtin. >> (BUILT_IN_TARGET_SUPPORTS_SSSE3): New builtin. >> (BUILT_IN_TARGET_SUPPORTS_SSE4_1): New builtin. >> (BUILT_IN_TARGET_SUPPORTS_SSE4_2): New builtin. >> (BUILT_IN_TARGET_IS_AMD): New builtin. >> (BUILT_IN_TARGET_IS_INTEL): New builtin. >> (BUILT_IN_TARGET_IS_COREI7_NEHALEM): New builtin. >> (BUILT_IN_TARGET_IS_COREI7_WESTMERE): New builtin. >> (BUILT_IN_TARGET_IS_COREI7_SANDYBRIDGE): New builtin. >> (BUILT_IN_TARGET_IS_AMDFAM10_BARCELONA): New builtin. >> (BUILT_IN_TARGET_IS_AMDFAM10_SHANGHAI): New builtin. >> (BUILT_IN_TARGET_IS_AMDFAM10_ISTANBUL): New builtin. > (cut) > > Keep the port-specific bits in the port, please. I don't see why > this has to be in generic files as opposed to target hooks and > included target-specific file fragments like everything else > (well, most everything) in gcc. If not, I think we'll see > cpu_ports*variants explosion here until these bits are > rewritten... Yes, this should move into the port. Sorry, I will change it. Thanks, -Sri. > > brgds, H-P > >
Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)
On Tue, 16 Aug 2011, Sriraman Tallam wrote: (I don't see anyone else making this comment, so maybe I missed something obvious, but I don't think so...) > Support for getting CPU type and feature information at run-time. > > The following patch provides support for finding the platform type at > run-time, like cpu type and features supported. The multi-versioning > framework will use the builtins added to dispatch the right function version. > Please refer to http://gcc.gnu.org/ml/gcc/2011-08/msg00298.html for details > on function multi-versioning usability. > > * tree-pass.h (pass_tree_fold_builtin_target): New pass. > * builtins.def (BUILT_IN_TARGET_SUPPORTS_CMOV): New builtin. > (BUILT_IN_TARGET_SUPPORTS_MMX): New builtin. > (BUILT_IN_TARGET_SUPPORTS_POPCOUNT): New builtin. > (BUILT_IN_TARGET_SUPPORTS_SSE): New builtin. > (BUILT_IN_TARGET_SUPPORTS_SSE2): New builtin. > (BUILT_IN_TARGET_SUPPORTS_SSE3): New builtin. > (BUILT_IN_TARGET_SUPPORTS_SSSE3): New builtin. > (BUILT_IN_TARGET_SUPPORTS_SSE4_1): New builtin. > (BUILT_IN_TARGET_SUPPORTS_SSE4_2): New builtin. > (BUILT_IN_TARGET_IS_AMD): New builtin. > (BUILT_IN_TARGET_IS_INTEL): New builtin. > (BUILT_IN_TARGET_IS_COREI7_NEHALEM): New builtin. > (BUILT_IN_TARGET_IS_COREI7_WESTMERE): New builtin. > (BUILT_IN_TARGET_IS_COREI7_SANDYBRIDGE): New builtin. > (BUILT_IN_TARGET_IS_AMDFAM10_BARCELONA): New builtin. > (BUILT_IN_TARGET_IS_AMDFAM10_SHANGHAI): New builtin. > (BUILT_IN_TARGET_IS_AMDFAM10_ISTANBUL): New builtin. (cut) Keep the port-specific bits in the port, please. I don't see why this has to be in generic files as opposed to target hooks and included target-specific file fragments like everything else (well, most everything) in gcc. If not, I think we'll see cpu_ports*variants explosion here until these bits are rewritten... brgds, H-P
[pph] Fix child references being included multiple times (issue4904050)
I changed my mind and kept stream->includes the way it was originally meant to
be, i.e. every stream will have its list of includes not only the main pph's
stream.
More specifically I will be using this for every stream when regenerating the
linemap (and reading the includes in parallel) in my upcoming patch!
Furthermore, we could get rid of the global pph_read_image altogether now as
it's only a flat vector representation of the include tree structure saved
through the pph_streams'->includes. The only problem I see is in pph_cache_get
where we need a fix index for a stream (we could definitely map an index to the
post-order traversal of the include tree, but it won't be as fast as a simple
index in a flat vector), I didn't do it for now..
Cheers,
Gab
2011-08-17 Gabriel Charette
gcc/cp/ChangeLog.pph
* pph-streamer-in.c (pph_reading_includes): New.
(pph_in_includes): Add logic to control pph_reading_includes.
(pph_read_file_1): Only call pph_add_include if reading an include
from the main file (not from pph_in_includes).
(pph_read_file): Don't handle adding to pph_read_images here.
(pph_reader_finish): Free pph_read_images.
* pph-streamer-out.c (pph_tree_matches): Remove now unused STREAM
parameter. Update all users.
(pph_add_include): Handle adding INCLUDE to pph_read_images here.
* pph-streamer.c (pph_read_images): Moved here from pph-streamer-in.c
(pph_stream_close): Free stream->includes.
(pph_cache_lookup_in_includes): Lookup in pph_read_images.
Remove now unused STREAM parameter. Update all users.
(pph_cache_get): Index in pph_read_images.
* pph-streamer.h (pph_stream): Changed comment for field "includes".
* pph.c (pph_finish): Fixed extra space typo.
gcc/testsuite/ChangeLog.pph
* g++.dg/pph/c2deepincl.cc: Remove asm xdiff.
diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
index 013f526..58f084e 100644
--- a/gcc/cp/pph-streamer-in.c
+++ b/gcc/cp/pph-streamer-in.c
@@ -33,13 +33,6 @@ along with GCC; see the file COPYING3. If not see
#include "cppbuiltin.h"
#include "toplev.h"
-/* List of PPH images read during parsing. Images opened during #include
- processing and opened from pph_in_includes cannot be closed
- immediately after reading, because the pickle cache contained in
- them may be referenced from other images. We delay closing all of
- them until the end of parsing (when pph_reader_finish is called). */
-static VEC(pph_stream_ptr,heap) *pph_read_images = NULL;
-
typedef char *char_p;
DEF_VEC_P(char_p);
DEF_VEC_ALLOC_P(char_p,heap);
@@ -53,6 +46,12 @@ DEF_VEC_ALLOC_P(char_p,heap);
memory will remain allocated until the end of compilation. */
static VEC(char_p,heap) *string_tables = NULL;
+/* Increment when we are in the process of reading includes as we do not want
+ to add those to the parent pph stream's list of includes to be written out.
+ Decrement when done. We cannot use a simple true/false flag as read includes
+ will call pph_in_includes as well. */
+static int pph_reading_includes = 0;
+
/* Wrapper for memory allocation calls that should have their results
registered in the PPH streamer cache. DATA is the pointer returned
by the memory allocation call in ALLOC_EXPR. IX is the cache slot
@@ -1289,6 +1288,8 @@ pph_in_includes (pph_stream *stream)
{
unsigned i, num;
+ pph_reading_includes++;
+
num = pph_in_uint (stream);
for (i = 0; i < num; i++)
{
@@ -1296,6 +1297,8 @@ pph_in_includes (pph_stream *stream)
pph_stream *include = pph_read_file (include_name);
pph_add_include (stream, include);
}
+
+ pph_reading_includes--;
}
@@ -1467,7 +1470,7 @@ pph_read_file_1 (pph_stream *stream)
/* If we are generating an image, the PPH contents we just read from
STREAM will need to be read again the next time we want to read
the image we are now generating. */
- if (pph_out_file)
+ if (pph_out_file && !pph_reading_includes)
pph_add_include (NULL, stream);
}
@@ -1481,10 +1484,7 @@ pph_read_file (const char *filename)
stream = pph_stream_open (filename, "rb");
if (stream)
-{
- pph_read_file_1 (stream);
- VEC_safe_push (pph_stream_ptr, heap, pph_read_images, stream);
-}
+pph_read_file_1 (stream);
else
error ("Cannot open PPH file for reading: %s: %m", filename);
@@ -1964,4 +1964,6 @@ pph_reader_finish (void)
/* Close any images read during parsing. */
FOR_EACH_VEC_ELT (pph_stream_ptr, pph_read_images, i, image)
pph_stream_close (image);
+
+ VEC_free (pph_stream_ptr, heap, pph_read_images);
}
diff --git a/gcc/cp/pph-streamer-out.c b/gcc/cp/pph-streamer-out.c
index 2099d4e..44fe018 100644
--- a/gcc/cp/pph-streamer-out.c
+++ b/gcc/cp/pph-streamer-out.c
@@ -207,11 +207,11 @@ pph_out_start_record (pph_stream *stream, void *data)
return false;
}
- /*
[patch committed] Fix PR target/50068
Hi, The attached patch is to fix PR target/50068. sh_output_mi_thunk calls dbr_schedule which doesn't expect to be called in that situation. Although we could set the environment in output_mi_thunk in such a way to enable dbr_schedule, it looks a bit overkill for this relatively rare optimization. The patch simply removes that use of dbr_schedule. Tested on sh4-unknown-linux-gnu with no new failures. Applied on trunk. Regards, kaz -- 2011-08-17 Kaz Kojima PR target/50068 * config/sh/sh.c (sh_output_mi_thunk): Don't call dbr_schedule. --- ORIG/trunk/gcc/config/sh/sh.c 2011-07-29 09:31:42.0 +0900 +++ trunk/gcc/config/sh/sh.c2011-08-16 16:46:19.0 +0900 @@ -11711,10 +11711,6 @@ sh_output_mi_thunk (FILE *file, tree thu } sh_reorg (); - - if (optimize > 0 && flag_delayed_branch) -dbr_schedule (insns); - shorten_branches (insns); final_start_function (insns, file, 1); final (insns, file, 1);
Re: [Patch, Fortran] (Coarray) Fix constraint checks for LOCK_TYPE
On 05 August 2011 16:42, Mikael Morin wrote:
OK, I played a bit myself to see what the "right way" would look like, and I
came up with the attached patch, which is complicated, and not even correct.
And indeed, it plays with allocatable and pointer stuff.
So your approach makes some sense now.
I do here some propositions for comment and error messages which IMO explain
better where the problem lies (Iff I have understood the problem correctly).
They are quite verbose however, and possibly not correct english (many
negations).
Thanks for reviewing the patch and for the suggestions!
Attached is an updated version of the patch, I hope it is now better,
though I think there is still room for improvement.
Changes:
- coarray_lock_5.f90: Added subroutine test2 with several additional
test cases
- updated dg-error
- parse.c's parse_derived: Add one comment, updated all error texts,
fixed codimension -> coarray_comp bug, added missing check and split
some of the checks into LOCK_TYPE and lock_comp.
Build and regtested on x86-64-linux.
OK - or suggestions how to improve it further?
Tobias
2011-08-18 Tobias Burnus
PR fortran/18918
* parse.c (parse_derived): Add lock_type
checks, improve coarray_comp handling.
* resolve.c (resolve_allocate_expr,
resolve_lock_unlock, resolve_symbol): Fix lock_type
constraint checks.
2011-08-18 Tobias Burnus
PR fortran/18918
* gfortran.dg/coarray_lock_1.f90: Update dg-error.
* gfortran.dg/coarray_lock_3.f90: Fix test.
* gfortran.dg/coarray_lock_4.f90: New.
* gfortran.dg/coarray_lock_5.f90: New.
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 2910ab5..dc619c3 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -2018,7 +2018,7 @@ parse_derived (void)
gfc_statement st;
gfc_state_data s;
gfc_symbol *sym;
- gfc_component *c;
+ gfc_component *c, *lock_comp = NULL;
accept_statement (ST_DERIVED_DECL);
push_state (&s, COMP_DERIVED, gfc_new_block);
@@ -2126,19 +2126,28 @@ endType:
sym = gfc_current_block ();
for (c = sym->components; c; c = c->next)
{
+ bool coarray, lock_type, allocatable, pointer;
+ coarray = lock_type = allocatable = pointer = false;
+
/* Look for allocatable components. */
if (c->attr.allocatable
|| (c->ts.type == BT_CLASS && c->attr.class_ok
&& CLASS_DATA (c)->attr.allocatable)
|| (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.alloc_comp))
- sym->attr.alloc_comp = 1;
+ {
+ allocatable = true;
+ sym->attr.alloc_comp = 1;
+ }
/* Look for pointer components. */
if (c->attr.pointer
|| (c->ts.type == BT_CLASS && c->attr.class_ok
&& CLASS_DATA (c)->attr.class_pointer)
|| (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.pointer_comp))
- sym->attr.pointer_comp = 1;
+ {
+ pointer = true;
+ sym->attr.pointer_comp = 1;
+ }
/* Look for procedure pointer components. */
if (c->attr.proc_pointer
@@ -2148,15 +2157,76 @@ endType:
/* Looking for coarray components. */
if (c->attr.codimension
- || (c->attr.coarray_comp && !c->attr.pointer && !c->attr.allocatable))
- sym->attr.coarray_comp = 1;
+ || (c->ts.type == BT_CLASS && c->attr.class_ok
+ && CLASS_DATA (c)->attr.codimension))
+ {
+ coarray = true;
+ sym->attr.coarray_comp = 1;
+ }
+
+ if (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.coarray_comp)
+ {
+ coarray = true;
+ if (!pointer && !allocatable)
+ sym->attr.coarray_comp = 1;
+ }
/* Looking for lock_type components. */
- if (c->attr.lock_comp
- || (sym->ts.type == BT_DERIVED
+ if ((c->ts.type == BT_DERIVED
&& c->ts.u.derived->from_intmod == INTMOD_ISO_FORTRAN_ENV
- && c->ts.u.derived->intmod_sym_id == ISOFORTRAN_LOCK_TYPE))
- sym->attr.lock_comp = 1;
+ && c->ts.u.derived->intmod_sym_id == ISOFORTRAN_LOCK_TYPE)
+ || (c->ts.type == BT_CLASS && c->attr.class_ok
+ && CLASS_DATA (c)->ts.u.derived->from_intmod
+ == INTMOD_ISO_FORTRAN_ENV
+ && CLASS_DATA (c)->ts.u.derived->intmod_sym_id
+ == ISOFORTRAN_LOCK_TYPE)
+ || (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.lock_comp
+ && !allocatable && !pointer))
+ {
+ lock_type = 1;
+ lock_comp = c;
+ sym->attr.lock_comp = 1;
+ }
+
+ /* Check for F2008, C1302 - and recall that pointers may not be coarrays
+ (5.3.14) and that subobjects of coarray are coarray themselves (2.4.7),
+ unless there are nondirect [allocatable or pointer] components
+ involved (cf. 1.3.33.1 and 1.3.33.3). */
+
+ if (pointer && !coarray && lock_type)
+ gfc_error ("Pointer component %s at %L of type LOCK_TYPE must have a "
+ "codimension or be a subcomponent of a coarray, "
+ "which is not possible as the component has the "
+ "pointer attribute", c->name, &c->loc);
+ else if (pointer && !coarray && c->ts.type == BT_DERIVED
+ && c->ts.u.derived->attr.lock_comp)
+ gfc_error ("Pointer component %s at %L has a noncoarray
[pph] Fix child references being included multiple times (issue4904050)
This patch fixes the fact that referenced child includes were read more then
once before as stream->includes would contain too much.
This refactors the include structure.
pph_read_images now contains a flat vector of the pph_streams of all images
read so far.
pph_out_stream->encoder.w.includes now contains a list of the streams of the
includes coming directly from the file we are currently pph'ing (NOT their
references)
Only the main stream (pph_out_stream) has such a list, we do not need to keep
track of the include hiearchy of the non-direct includes as it is only needed
on read and is already saved in the included pphs themselves.
This fixes c2deepincl.cc which was introduced yesterday to expose this same
issue.
Tested with bootstrap and pph regression testing on x64.
Gab
2011-08-17 Gabriel Charette
gcc/cp/ChangeLog.pph
* pph-streamer-in.c (pph_reading_includes): New.
(pph_in_includes): Add logic to control pph_reading_includes.
(pph_read_file_1): Only call pph_add_include if reading an include
from the main file (not from pph_in_includes).
(pph_read_file): Don't handle adding to pph_read_images here.
(pph_reader_finish): Free pph_read_images.
* pph-streamer-out.c (pph_tree_matches): Remove now unused STREAM
parameter. Update all users.
(pph_add_include): Changed signature to (stream, bool).
Update all users.
Handle adding INCLUDE to pph_read_images here.
* gcc/cp/pph-streamer.c (pph_read_images): Moved here from
pph-streamer-in.c
(pph_stream_close): Free stream->encoder.w.includes.
(pph_cache_lookup_in_includes): Lookup in pph_read_images.
Remove now unused STREAM parameter.
Update all users.
(pph_cache_get): Index in pph_read_images.
* pph-streamer.h (pph_stream): Move field includes to
pph_stream.encoder.w.includes. Update all users.
* gcc/cp/pph.c (pph_finish): Fixed extra space typo.
gcc/testsuite/ChangeLog.pph
* g++.dg/pph/c2deepincl.cc: Remove asm xdiff.
diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
index 013f526..3b2e082 100644
--- a/gcc/cp/pph-streamer-in.c
+++ b/gcc/cp/pph-streamer-in.c
@@ -33,13 +33,6 @@ along with GCC; see the file COPYING3. If not see
#include "cppbuiltin.h"
#include "toplev.h"
-/* List of PPH images read during parsing. Images opened during #include
- processing and opened from pph_in_includes cannot be closed
- immediately after reading, because the pickle cache contained in
- them may be referenced from other images. We delay closing all of
- them until the end of parsing (when pph_reader_finish is called). */
-static VEC(pph_stream_ptr,heap) *pph_read_images = NULL;
-
typedef char *char_p;
DEF_VEC_P(char_p);
DEF_VEC_ALLOC_P(char_p,heap);
@@ -53,6 +46,12 @@ DEF_VEC_ALLOC_P(char_p,heap);
memory will remain allocated until the end of compilation. */
static VEC(char_p,heap) *string_tables = NULL;
+/* Increment when we are in the process of reading includes as we do not want
+ to add those to the parent pph stream's list of includes to be written out.
+ Decrement when done. We cannot use a simple true/false flag as read includes
+ will call pph_in_includes as well. */
+static int pph_reading_includes = 0;
+
/* Wrapper for memory allocation calls that should have their results
registered in the PPH streamer cache. DATA is the pointer returned
by the memory allocation call in ALLOC_EXPR. IX is the cache slot
@@ -1289,13 +1288,17 @@ pph_in_includes (pph_stream *stream)
{
unsigned i, num;
+ pph_reading_includes++;
+
num = pph_in_uint (stream);
for (i = 0; i < num; i++)
{
const char *include_name = pph_in_string (stream);
pph_stream *include = pph_read_file (include_name);
- pph_add_include (stream, include);
+ pph_add_include (include, false);
}
+
+ pph_reading_includes--;
}
@@ -1467,8 +1470,8 @@ pph_read_file_1 (pph_stream *stream)
/* If we are generating an image, the PPH contents we just read from
STREAM will need to be read again the next time we want to read
the image we are now generating. */
- if (pph_out_file)
-pph_add_include (NULL, stream);
+ if (pph_out_file && !pph_reading_includes)
+pph_add_include (stream, true);
}
@@ -1481,10 +1484,7 @@ pph_read_file (const char *filename)
stream = pph_stream_open (filename, "rb");
if (stream)
-{
- pph_read_file_1 (stream);
- VEC_safe_push (pph_stream_ptr, heap, pph_read_images, stream);
-}
+pph_read_file_1 (stream);
else
error ("Cannot open PPH file for reading: %s: %m", filename);
@@ -1964,4 +1964,6 @@ pph_reader_finish (void)
/* Close any images read during parsing. */
FOR_EACH_VEC_ELT (pph_stream_ptr, pph_read_images, i, image)
pph_stream_close (image);
+
+ VEC_free (pph_stream_ptr, heap, pph_read_images);
}
diff --git
Re: Vector Comparison patch
On Wed, 17 Aug 2011, Artem Shinkarov wrote:
> +For the convenience condition in the vector conditional can be just a
> +vector of signed integer type. In that case this vector is implicitly
> +compared with vectors of zeroes. Consider an example:
Where is this bit tested in the testcases added?
> + if (TREE_CODE (type1) != VECTOR_TYPE
> + || TREE_CODE (type2) != VECTOR_TYPE)
> +{
> + error_at (colon_loc, "vector comparisom arguments must be of "
> + "type vector");
"comparison"
> + /* Avoid C_MAYBE_CONST in VEC_COND_EXPR. */
> + sc = c_fully_fold (ifexp, false, &maybe_const);
> + sc = save_expr (sc);
> + if (!maybe_const)
> + ifexp = c_wrap_maybe_const (sc, true);
> + else
> + ifexp = sc;
This looks like it's duplicating c_save_expr; that is, like "ifexp =
c_save_expr (ifexp);" would suffice.
But, it's not clear that it actually achieves the effect described in the
comment; have you actually tried with function calls, assignments etc. in
the operands? The code in build_binary_op uses save_expr rather than
c_save_expr because it does some intermediate operations before calling
c_wrap_maybe_const, and if you really want to avoid C_MAYBE_CONST in
VEC_COND_EXPR then you'll need to continue calling save_expr, as here, but
delay the call to c_wrap_maybe_const so that the whole VEC_COND_EXPR is
wrapped if required.
--
Joseph S. Myers
jos...@codesourcery.com
[PATCH] Remove PREFERRED_OUTPUT_RELOAD_CLASS macro
Hi.
No one back end does not use PREFERRED_OUTPUT_RELOAD_CLASS macro now, this
patch remove it. The TARGET_PREFERRED_RELOAD_CLASS target hook should be use
instead.
The patch has been bootstrapped on and regression tested on
x86_64-unknown-linux-gnu for c and c++.
This patch is pre-approved and should be committed within a week if no
objections.
* doc/tm.texi.in (PREFERRED_OUTPUT_RELOAD_CLASS): Remove.
* doc/tm.texi: Regenerate.
* targhooks.c (default_preferred_output_reload_class): Don't use
PREFERRED_OUTPUT_RELOAD_CLASS macro.
* system.h (PREFERRED_OUTPUT_RELOAD_CLASS): Poison.
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 177791)
+++ gcc/doc/tm.texi (working copy)
@@ -2601,15 +2601,6 @@
the SSE registers (and vice versa).
@end defmac
-@defmac PREFERRED_OUTPUT_RELOAD_CLASS (@var{x}, @var{class})
-Like @code{PREFERRED_RELOAD_CLASS}, but for output reloads instead of
-input reloads. If you don't define this macro, the default is to use
-@var{class}, unchanged.
-
-You can also use @code{PREFERRED_OUTPUT_RELOAD_CLASS} to discourage
-reload from using some alternatives, like @code{PREFERRED_RELOAD_CLASS}.
-@end defmac
-
@deftypefn {Target Hook} reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx
@var{x}, reg_class_t @var{rclass})
Like @code{TARGET_PREFERRED_RELOAD_CLASS}, but for output reloads instead of
input reloads.
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in (revision 177791)
+++ gcc/doc/tm.texi.in (working copy)
@@ -2587,15 +2587,6 @@
the SSE registers (and vice versa).
@end defmac
-@defmac PREFERRED_OUTPUT_RELOAD_CLASS (@var{x}, @var{class})
-Like @code{PREFERRED_RELOAD_CLASS}, but for output reloads instead of
-input reloads. If you don't define this macro, the default is to use
-@var{class}, unchanged.
-
-You can also use @code{PREFERRED_OUTPUT_RELOAD_CLASS} to discourage
-reload from using some alternatives, like @code{PREFERRED_RELOAD_CLASS}.
-@end defmac
-
@hook TARGET_PREFERRED_OUTPUT_RELOAD_CLASS
Like @code{TARGET_PREFERRED_RELOAD_CLASS}, but for output reloads instead of
input reloads.
Index: gcc/targhooks.c
===
--- gcc/targhooks.c (revision 177791)
+++ gcc/targhooks.c (working copy)
@@ -1287,11 +1287,7 @@
default_preferred_output_reload_class (rtx x ATTRIBUTE_UNUSED,
reg_class_t rclass)
{
-#ifdef PREFERRED_OUTPUT_RELOAD_CLASS
- return PREFERRED_OUTPUT_RELOAD_CLASS (x, (enum reg_class) rclass);
-#else
return rclass;
-#endif
}
/* The default implementation of TARGET_PREFERRED_RENAME_CLASS. */
Index: gcc/system.h
===
--- gcc/system.h(revision 177791)
+++ gcc/system.h(working copy)
@@ -866,7 +866,8 @@
USING_SVR4_H SVR4_ASM_SPEC FUNCTION_ARG FUNCTION_ARG_ADVANCE \
FUNCTION_INCOMING_ARG IRA_COVER_CLASSES TARGET_VERSION \
MACHINE_TYPE TARGET_HAS_TARGETCM ASM_OUTPUT_BSS\
- SETJMP_VIA_SAVE_AREA FORBIDDEN_INC_DEC_CLASSES
+ SETJMP_VIA_SAVE_AREA FORBIDDEN_INC_DEC_CLASSES \
+ PREFERRED_OUTPUT_RELOAD_CLASS
/* Hooks that are no longer used. */
#pragma GCC poison LANG_HOOKS_FUNCTION_MARK LANG_HOOKS_FUNCTION_FREE \
Anatoly.
[patch, HPUX] Simplified patch to fix HP-UX C++ bootstrap
After some reconsideration I have changed my patch to fix the -static-libstdc++ build on HP-UX and the bootstrap with C++ build problem. Originally, I set gcc_cv_ld_static_option to "-aarchive" to only search archive libraries and this caused problems on IA64 HP-UX where we used the system unwind library and which only existed as a shared library. In this patch, I use "-aarchive_shared" instead of "-aarchive" so that the linker will look for archive libraries first and then for shared libraries. This has the advantage of fixing the HP-UX problem while not requiring any changes that are not specific to HP-UX. The reason I didn't do this initially is that when using "-aarchive_shared", the linker will search directory "a" for archive libraries, then if it didn't find one, search "a" for a shared library. Only then will it go on to search directory "b" for an archive library. I wasn't sure this would give us the behaviour we wanted but after some testing, it seems to work OK so I would like to check it in. Dave, I tested this on HPPA as well as IA64, and it looks OK to me. Does it look good to you? If so I will go ahead and check it in. Steve Ellcey s...@cup.hp.com 2011-08-17 Steve Ellcey PR target/49967 * configure.ac (gcc_cv_ld_static_dynamic): Define for *-*-hpux*. (gcc_cv_ld_static_option): Ditto. (gcc_cv_ld_dynamic_option): Ditto. * configure: Regenerate. Index: configure.ac === --- configure.ac(revision 177820) +++ configure.ac(working copy) @@ -3239,6 +3239,14 @@ elif test x$gcc_cv_ld != x; then gcc_cv_ld_static_option="-noso" gcc_cv_ld_dynamic_option="-so_archive" ;; + # HP-UX ld uses -a flags to select between shared and archive. + *-*-hpux*) + if test x"$gnu_ld" = xno; then + gcc_cv_ld_static_dynamic=yes + gcc_cv_ld_static_option="-aarchive_shared" + gcc_cv_ld_dynamic_option="-adefault" + fi + ;; # IRIX 6 ld supports -Bstatic/-Bdynamic. mips-sgi-irix6*) gcc_cv_ld_static_dynamic=yes
[cxx-mem-model] handle xfails in the memmodel test harness
With this patch we can now XFAIL tests that are expected to fail at
runtime. This is how it's used:
/* { dg-final { memmodel-gdb-test { xfail x86*-*-* } } } */
Note, that the test will still run.
This is needed for an upcoming known-to-fail test Andrew will contribute
shortly.
Committed to branch.
* lib/gcc-memmodel-gdb-test.exp (memmmodel-gdb-test): Handle
Index: lib/gcc-memmodel-gdb-test.exp
===
--- lib/gcc-memmodel-gdb-test.exp (revision 177836)
+++ lib/gcc-memmodel-gdb-test.exp (working copy)
@@ -21,9 +21,15 @@
#
# Call 'fail' if a given test printed "FAIL:", otherwise call 'pass'.
-proc memmodel-gdb-test { } {
+proc memmodel-gdb-test { args } {
if { ![isnative] || [is_remote target] } { return }
+if { [llength $args] == 1 } {
+ switch [dg-process-target [lindex $args 0]] {
+ "F" { setup_xfail "*-*-*" }
+ }
+}
+
# This assumes that we are three frames down from dg-test, and that
# it still stores the filename of the testcase in a local variable
"name".
# A cleaner solution would require a new DejaGnu release.
Re: Linemap force location and remove LINEMAP_POSITION_FOR_COLUMN (issue4801090)
Hello Gabriel, gch...@google.com (Gabriel Charette) a écrit: > Here is the updated patch. > > It nows exposes two libcpp functions to force the source_location for tokens > when desired. > > The lexer then checks for a value set by these functions in cpp_reader and > acts accordingly when needing a location for a new token (either using the > forced_location or calling the linemap as it used to). > > It turns out the fortran library made the same mistake of creating a > line_table entry for builtins, I fixed it as well in this patch. > > Tested on x64 for c++,fortran. > > (fyi: I moved the removal of LINEMAP_POSITION_FOR_COLUMN to a separate patch > which is checked-in already; thus it doesn't show up in this updated patch > obviously. > ) > > Ok for trunk? > > Gabriel > > 2011-08-15 Gabriel Charette > > gcc/c-family/ChangeLog > * c-opts.c (c_finish_options): Force BUILTINS_LOCATION for tokens > defined in cpp_init_builtins and c_cpp_builtins. > > gcc/fortran/ChangeLog > * cpp.c (gfc_cpp_init): Force BUILTINS_LOCATION for tokens > defined in cpp_define_builtins. > > libcpp/ChangeLog > * init.c (cpp_create_reader): Inititalize forced_token_location_p. > * internal.h (struct cpp_reader): Add field forced_token_location_p. > * lex.c (_cpp_lex_direct): Use forced_token_location_p. > (cpp_force_token_locations): New. > (cpp_stop_forcing_token_locations): New. I cannot approve or reject this patch, but FWIW, it looks OK to me. Thanks. -- Dodji
Re: RFA: Avoiding unprofitable speculation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/17/11 01:21, Richard Guenther wrote: > > We don't have a way to distinguish branch-taken vs. branch-not-take > costs, right? Not that I'm aware of. However, BRANCH_COST does allow the backend to change the cost of a branch based on its predictability. > I would expect that for non-pipelined archs the branch does have the > same cost all the time, so ifcvt would be correct, no? The branch we're able to eliminate is typically (always?) an unconditional branch. The unconditional branch we eliminate is only executed some percentage of the time based on the conditional branch that remains in the stream. So regardless of the underlying cost of the branch we eliminate, we still want to compare the cost of the speculated insns against the scaled cost of the branch we're able to eliminate. > Do you happen to know how valgrind counts branches here? I don't know all the low level details -- I'd have to sit down with the annotation code in the cachegrind plugin. Presumably since valgrind also attempts to model branch prediction it carries a number of counters associated with each branch which get bumped as needed by the instrumented code. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOTBW/AAoJEBRtltQi2kC70kIH/183zcbFr5NiHbM7JO9xkGoL lxiwEKsWW3m5x/PYRb+S82prPjRI/2ZzcnDE+ZzjffF+W2agOCdE29DvFjm8JkdI bUwAMPUrxip5y9iZSwreywtbm73yw/9GTkkr+oHYZupqTUbbC3rw3kV5f/DJq/xP jmzFPeK1U1Glmus9mWruiSwRloyh2o5usysdnB7aRhO/KdH1jWG7EfZ7cvfQhSWf u8IYkxRsdQD/xd+6TpxOgmRj8kjJlYw0oAMjNsGkiNnNqyqzZBjOe6sHE59IWc27 Z35HrpRvXevuImE6XQF6KmBWiK1cjExVdmlnZMTuOdy/tXklmp0zLP1EAbP5Sd8= =o4mr -END PGP SIGNATURE-
Re: RFC: [build, ada] Centralize PICFLAG configuration
On Aug 15, 2011, at 10:53 AM, Rainer Orth wrote: > * git libtool.m4 uses -fno-common on *-*-darwin. No idea if this is > required. Yes, it is.
Re: [Patch] Fix tree-optimization/49963
Paolo Carlini wrote: I sanity checked the patch on x86_64-linux and OP reported that on AVR the patch fixes the regression. Not really "on" AVR; AVR are just tiny 8-bit microcontrollers ;-) I obseved the problem when compiling for AVR on a x86-linux-gnu host where 0x8000 is negative. Johann
[PATCH] PR c++/45625 - Template parm name doesn't hide outer class scope's member name
Hello,
Consider this code snippet:
struct Outer
{
static const int value = 1 ;
template< int value >
struct Inner
{
static const int* get_value() { return &value ; } // #1 -> Error!
} ;
};
template class Outer::Inner<2>;
The line #1 should yield an error because the name "value" should
resolve to the template parameter, not the static member of the outer
class.
The problem seems to be that parameter_of_template_p (notably used by
binding_to_template_parms_of_scope_p) fails to detect that the
template parm it gets in argument is a member of the template.
For each PARM_DECL representing a non-type template parameter,
process_template_parm and push_inline_template_parms_recursive
actually create a CONST_DECL that is added to the symbol table for
that PARM_DECL.
The patch below updates parameter_of_template_p to handle non-type
template parameters.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* pt.c (parameter_of_template_p): Handle comparison with DECLs of
template parameters as created by process_template_parm.
gcc/testsuite/
* g++.dg/lookup/hidden-var1.C: New test case.
---
gcc/cp/pt.c |9 +++--
gcc/testsuite/g++.dg/lookup/hidden-var1.C | 19 +++
2 files changed, 26 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/lookup/hidden-var1.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9ab110a..ed4fe72 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -7890,8 +7890,13 @@ parameter_of_template_p (tree parm, tree templ)
parms = INNERMOST_TEMPLATE_PARMS (parms);
for (i = 0; i < TREE_VEC_LENGTH (parms); ++i)
-if (parm == TREE_VALUE (TREE_VEC_ELT (parms, i)))
- return true;
+{
+ tree p = TREE_VALUE (TREE_VEC_ELT (parms, i));
+ if (parm == p
+ || (DECL_INITIAL (parm)
+ && DECL_INITIAL (parm) == DECL_INITIAL (p)))
+ return true;
+}
return false;
}
diff --git a/gcc/testsuite/g++.dg/lookup/hidden-var1.C
b/gcc/testsuite/g++.dg/lookup/hidden-var1.C
new file mode 100644
index 000..6be32b5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lookup/hidden-var1.C
@@ -0,0 +1,19 @@
+// Origin PR c++/45625
+// { dg-do compile }
+
+struct Outer
+{
+ static const int value = 1 ;
+
+ template< int value >
+ struct Inner
+ {
+static const int*
+get_value()
+{
+ return &value ;// { dg-error "lvalue required" }
+}
+ };
+};
+
+template class Outer::Inner<2>;
--
Dodji
[Patch] Fix tree-optimization/49963
Hi,
I prepared the below basing on an hint provided by Joseph on the audit
trail: essentially, I'm replacing all (but two) uses of abs_hwi outside
hwint.c by absu_hwi, a variant which returns an unsigned HOST_WIDE_INT.
All the replacements make sense to me: either we are comparing two abs,
or we are passing the abs to a function actually expecting an unsigned
HOST_WIDE_INT, or we are comparing to another unsigned HOST_WIDE_INT, or
we are just comparing to a constant (I don't feel strongly in this case
but seems safe to use absu_hwi here too). I'm *not* replacing 2
occurrences in gimple_expand_builtin_pow, because those are safe anyway
in terms of range of the argument (it's an HOST_WIDE_INT / 2 or 3) and
the result is passed to a function expecting a plain HOST_WIDE_INT (ie,
gimple_expand_builtin_powi).
I sanity checked the patch on x86_64-linux and OP reported that on AVR
the patch fixes the regression.
Is it ok?
Thanks,
Paolo.
PS: compared to the draft version, the attached uses cast to unsigned in
both arms of the ? : operator, I think Joseph preferred that
stylistically in a snippet of him posted in an unrelated recent audit trail.
///
2011-08-17 Paolo Carlini
Joseph Myers
PR tree-optimization/49963
* hwint.c (absu_hwi): Define.
* hwint.h (absu_hwi): Declare.
* fold-const.c (fold_plusminus_mult_expr): Use absu_hwi instead
of abs_hwi.
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Likewise.
* tree-ssa-loop-prefetch.c (prune_ref_by_group_reuse): Likewise.
Index: fold-const.c
===
--- fold-const.c(revision 177834)
+++ fold-const.c(working copy)
@@ -7036,7 +7036,7 @@ fold_plusminus_mult_expr (location_t loc, enum tre
int11 = TREE_INT_CST_LOW (arg11);
/* Move min of absolute values to int11. */
- if (abs_hwi (int01) < abs_hwi (int11))
+ if (absu_hwi (int01) < absu_hwi (int11))
{
tmp = int01, int01 = int11, int11 = tmp;
alt0 = arg00, arg00 = arg10, arg10 = alt0;
@@ -7046,7 +7046,7 @@ fold_plusminus_mult_expr (location_t loc, enum tre
else
maybe_same = arg11;
- if (exact_log2 (abs_hwi (int11)) > 0 && int01 % int11 == 0
+ if (exact_log2 (absu_hwi (int11)) > 0 && int01 % int11 == 0
/* The remainder should not be a constant, otherwise we
end up folding i * 4 + 2 to (i * 2 + 1) * 2 which has
increased the number of multiplications necessary. */
Index: tree-ssa-math-opts.c
===
--- tree-ssa-math-opts.c(revision 177834)
+++ tree-ssa-math-opts.c(working copy)
@@ -1231,7 +1231,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
/* Attempt to fold powi(arg0, abs(n/2)) into multiplies. If not
possible or profitable, give up. Skip the degenerate case when
n is 1 or -1, where the result is always 1. */
- if (abs_hwi (n) != 1)
+ if (absu_hwi (n) != 1)
{
powi_x_ndiv2 = gimple_expand_builtin_powi (gsi, loc, arg0,
abs_hwi (n / 2));
@@ -1243,7 +1243,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
result of the optimal multiply sequence just calculated. */
sqrt_arg0 = build_and_insert_call (gsi, loc, &target, sqrtfn, arg0);
- if (abs_hwi (n) == 1)
+ if (absu_hwi (n) == 1)
result = sqrt_arg0;
else
result = build_and_insert_binop (gsi, loc, target, MULT_EXPR,
@@ -1285,7 +1285,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
/* Attempt to fold powi(arg0, abs(n/3)) into multiplies. If not
possible or profitable, give up. Skip the degenerate case when
abs(n) < 3, where the result is always 1. */
- if (abs_hwi (n) >= 3)
+ if (absu_hwi (n) >= 3)
{
powi_x_ndiv3 = gimple_expand_builtin_powi (gsi, loc, arg0,
abs_hwi (n / 3));
@@ -1298,14 +1298,14 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
either cbrt(x) or cbrt(x) * cbrt(x). */
cbrt_x = build_and_insert_call (gsi, loc, &target, cbrtfn, arg0);
- if (abs_hwi (n) % 3 == 1)
+ if (absu_hwi (n) % 3 == 1)
powi_cbrt_x = cbrt_x;
else
powi_cbrt_x = build_and_insert_binop (gsi, loc, target, MULT_EXPR,
cbrt_x, cbrt_x);
/* Multiply the two subexpressions, unless powi(x,abs(n)/3) = 1. */
- if (abs_hwi (n) < 3)
+ if (absu_hwi (n) < 3)
result = powi_cbrt_x;
else
result = build_and_insert_binop (gsi, loc, target, MULT_EXPR,
Index: tree-ssa-loop-prefetch.c
===
--- tree-ssa-loop-prefetch.c(revision 17783
Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)
On Wed, Aug 17, 2011 at 12:37 AM, Richard Guenther
wrote:
> On Tue, Aug 16, 2011 at 10:50 PM, Sriraman Tallam wrote:
>> Support for getting CPU type and feature information at run-time.
>>
>> The following patch provides support for finding the platform type at
>> run-time, like cpu type and features supported. The multi-versioning
>> framework will use the builtins added to dispatch the right function
>> version. Please refer to http://gcc.gnu.org/ml/gcc/2011-08/msg00298.html for
>> details on function multi-versioning usability.
>
> Please provide an overview why you need the new builtins,
For multi-versioning, the compiler can call the appropriate builtin
to dispatch the right version. The builtin call will later get folded.
For example,
int __attribute__ version ("sse4_1")
compute ()
{
// Do sse4_1 specific impkementation.
}
int
compute ()
{
// Generic implementation
}
The compiler will check if the target supports the attribute and then
convert a call to compute () into this:
if (__builtin_target_supports_sse4_1 ())
compute_sse4_1 (); // Call to the SSE4_1 implementation
else
compute_generic (); // Call to the generic implementation
Further, having it as builtin function allows it to be overridden by
the programmer. For instance, the programmer can override it to
identify newer CPU types not yet supported. Having these builtins
makes it convenient to identify platform type and features in general.
why you need
> a separate pass to fold them (instead of just expanding them) and why
I can move it into builtins.c along with where other builtins are
folded and remove the separate pass. My intention originally was to
fold them as early as possible, in this case after multi-versioning
but I guess this is not a requirement.
> you are creating
> vars behind the back of GCC:
The flow I had in mind was to have functions in libgcc which will use
CPUID to get target features and set global vars corresponding to the
features. So, the builtin should be folded by into the appropriate
variable in libgcc.
>
> + /* Set finalized to 1, otherwise it asserts in function "write_symbol" in
> + lto-streamer-out.c. */
> + vnode->finalized = 1;
>
> where I think you miss a varpool_finalize_node call somewhere. Why
> isn't this all done at target init time
I wanted to do this on demand. If none of the new builtins are called
in the program, I do not need to to do this at all. In summary, libgcc
has a function called __cpu_indicator_init which does the work of
determining target features and setting the appropriate globals. If
the new builtins are called, gcc will call __cpu_indicator_init in a
constructor so that it is called exactly once. Then, gcc will fold the
builtin to the appropriate global variable.
? If you don't mark the
> variable as to be preserved
> like you do cgraph will optimize it all away if it isn't needed.
>
> Richard.
>
>> * tree-pass.h (pass_tree_fold_builtin_target): New pass.
>> * builtins.def (BUILT_IN_TARGET_SUPPORTS_CMOV): New builtin.
>> (BUILT_IN_TARGET_SUPPORTS_MMX): New builtin.
>> (BUILT_IN_TARGET_SUPPORTS_POPCOUNT): New builtin.
>> (BUILT_IN_TARGET_SUPPORTS_SSE): New builtin.
>> (BUILT_IN_TARGET_SUPPORTS_SSE2): New builtin.
>> (BUILT_IN_TARGET_SUPPORTS_SSE3): New builtin.
>> (BUILT_IN_TARGET_SUPPORTS_SSSE3): New builtin.
>> (BUILT_IN_TARGET_SUPPORTS_SSE4_1): New builtin.
>> (BUILT_IN_TARGET_SUPPORTS_SSE4_2): New builtin.
>> (BUILT_IN_TARGET_IS_AMD): New builtin.
>> (BUILT_IN_TARGET_IS_INTEL): New builtin.
>> (BUILT_IN_TARGET_IS_COREI7_NEHALEM): New builtin.
>> (BUILT_IN_TARGET_IS_COREI7_WESTMERE): New builtin.
>> (BUILT_IN_TARGET_IS_COREI7_SANDYBRIDGE): New builtin.
>> (BUILT_IN_TARGET_IS_AMDFAM10_BARCELONA): New builtin.
>> (BUILT_IN_TARGET_IS_AMDFAM10_SHANGHAI): New builtin.
>> (BUILT_IN_TARGET_IS_AMDFAM10_ISTANBUL): New builtin.
>> * mversn-dispatch.c (do_fold_builtin_target): New function.
>> (gate_fold_builtin_target): New function.
>> (pass_tree_fold_builtin_target): New pass.
>> * timevar.def (TV_FOLD_BUILTIN_TARGET): New var.
>> * passes.c (init_optimization_passes): Add new pass to pass list.
>> * config/i386/i386.c (build_struct_with_one_bit_fields): New function.
>> (make_var_decl): New function.
>> (get_field_from_struct): New function.
>> (make_constructor_to_get_target_type): New function.
>> (fold_builtin_target): New function.
>> (ix86_fold_builtin): New function.
>> (TARGET_FOLD_BUILTIN): New macro.
>>
>> * gcc.dg/builtin_target.c: New test.
>>
>> * config/i386/i386-cpuinfo.c: New file.
>> * config/i386/t-cpuinfo: New file.
>> * config.host: Add t-cpuinfo to link i386-cpuinfo.o with libgcc
>>
>> Index: libgcc/config.host
>> ===
>> --- libgcc
Re: [patch, fortran] PR 46659 - extend conversion warnings to assignments
On 08/15/2011 07:49 PM, Thomas Koenig wrote: Am 14.08.2011 22:54, schrieb Tobias Burnus: Thomas Koenig wrote: the attached patch extends conversion warnings to assignments. OK for trunk? I get now two warnings for: complex(8), parameter :: z = cmplx (0.5, 0.5) r = z end The problem is that gfc_check_assign is called twice for this, from different code paths Well, I don't think that this is the problem - the actual warning comes from the calling of the same code path: a) Call to gfc_check_assign_symbol from add_init_expr_to_sym: This does not print a warning for "z = cmplx(0.5,0.5)" (Side note: There is a conversion from kind=4 to kind=8) b) Call from gfc_resolve for "r = z" b.1) gfc_warning call in gfc_check_assign at expr.c:3228 -- the code which you added b.2) gfc_warning_now call in gfc_convert_type_warn (intrinsic.c:4349), which is called from gfc_check_assign (line 3272). (b.2) is guarded by else if (from_ts.type == ts->type || (from_ts.type == BT_INTEGER && ts->type == BT_REAL) || (from_ts.type == BT_INTEGER && ts->type == BT_COMPLEX) || (from_ts.type == BT_REAL && ts->type == BT_COMPLEX)) while (b.1) uses if (rvalue->expr_type == EXPR_CONSTANT && (lvalue->ts.type == BT_REAL || lvalue->ts.type == BT_COMPLEX) && (rvalue->ts.type == BT_REAL || rvalue->ts.type == BT_COMPLEX)) As written, you should consider changing this to, e.g., if (rvalue->expr_type == EXPR_CONSTANT && (lvalue->ts.type == BT_REAL || lvalue->ts.type == BT_COMPLEX) && (rvalue->ts.type == rvalue->ts.type)) or at least you should exclude rvalue == BT_COMPLX and lvalue == BT_REAL. Tobias
[cxx-mem-model] A couple of testsuite modifications.
2 simple changes,
1 - the gdb-invoked tests we're sometimes getting enough text that it
would interactively ask for
---Type to continue, or q to quit---
which would either cause a hang/timeout while it waited and/or failure.
Fixed by adding 'set height 0' in the script
2 - sync-mem-invalid.c still had tests for
__sync_mem_compare_exchange which no longer exists. so removed them
checked in as obvious.
Andrew
* gcc.dg/sync-mem-invalid.c: Remove __sync_mem_compare_exchange test.
* gcc.dg/memmodel/memmodel.gdb: Avoid pagination.
Index: gcc.dg/sync-mem-invalid.c
===
*** gcc.dg/sync-mem-invalid.c (revision 177737)
--- gcc.dg/sync-mem-invalid.c (working copy)
*** main ()
*** 9,19
{
__sync_mem_exchange (&i, 1, __SYNC_MEM_CONSUME); /* { dg-error "invalid
memory model" } */
- __sync_mem_compare_exchange (&i, 1, 2, __SYNC_MEM_SEQ_CST,
__SYNC_MEM_RELEASE); /* { dg-error "invalid failure memory model" } */
- __sync_mem_compare_exchange (&i, 1, 2, __SYNC_MEM_SEQ_CST,
__SYNC_MEM_ACQ_REL); /* { dg-error "invalid failure memory model" } */
- __sync_mem_compare_exchange (&i, 1, 2, __SYNC_MEM_ACQUIRE,
__SYNC_MEM_SEQ_CST); /* { dg-error "failure memory model" } */
- __sync_mem_compare_exchange (&i, 1, 2, __SYNC_MEM_RELAXED,
__SYNC_MEM_ACQUIRE); /* { dg-error "failure memory model" } */
-
__sync_mem_load (&i, __SYNC_MEM_RELEASE); /* { dg-error "invalid memory
model" } */
__sync_mem_load (&i, __SYNC_MEM_ACQ_REL); /* { dg-error "invalid memory
model" } */
--- 9,14
Index: gcc.dg/memmodel/memmodel.gdb
===
*** gcc.dg/memmodel/memmodel.gdb(revision 177737)
--- gcc.dg/memmodel/memmodel.gdb(working copy)
***
*** 1,3
--- 1,4
+ set height 0
break main
disp/i $pc
run
Re: [PATCH][1/n] Make sizetype no longer sign-extended
> I don't expect any issues, the patch is a noop right now (because > of that sign-extension of unsigned sizetype), but I'll leave it > until tomorrow for comments anyway. > > Thanks, > Richard. > > 2011-08-17 Richard Guenther > > * expr.c (get_inner_reference): Sign-extend the constant > twos-complement offset before doing arbitrary precision > arithmetic on it. > * tree-ssa-structalias.c (get_constraint_for_ptr_offset): Likewise. > (get_constraint_for_1): Pass the offset of a MEM_REF unchanged > to get_constraint_for_ptr_offset. > * tree-cfg.c (verify_types_in_gimple_reference): Do not > compare integer constants by pointer. The verify_types_in_gimple_reference change would suggest that we now can have TYPE_SIZEs with different types. Is that true? -- Eric Botcazou
[pph] Minor cleanups (issue4908048)
These two patches clean up:
- The streaming of token values. During PTH, we did not have a generic
tree streamer, so we were implementing our own. Easier to just call
pph_out_tree/pph_in_tree now.
- pph_out_tree_or_ref and pph_out_tree_or_ref_1 were misnamed. Renamed
all references to them with pph_out_tree.
Tested on x86_64. Committed to branch
Diego.
* pph-streamer.h (pph_out_tree_1): Rename from pph_out_tree_or_ref_1.
Update all users.
(pph_out_tree): Rename from pph_out_tree_or_ref. Update all users.
* pph-streamer-in.c (pph_get_type_from_index): Remove.
(pph_in_number): Remove.
(pph_in_token_value): Handle all cases that read a tree
with pph_in_tree.
* pph-streamer-out.c (pph_out_number): Remove.
(pph_get_index_from_type): Remove.
(pph_out_token_value): Handle all cases that write a tree
with pph_out_tree.
---
gcc/cp/ChangeLog.pph |6 ++
gcc/cp/name-lookup.c |4 +-
gcc/cp/pph-streamer-out.c | 146 ++--
gcc/cp/pph-streamer.h | 15 +
gcc/cp/pt.c |6 +-
5 files changed, 87 insertions(+), 90 deletions(-)
diff --git a/gcc/cp/ChangeLog.pph b/gcc/cp/ChangeLog.pph
index edb3986..666033b 100644
--- a/gcc/cp/ChangeLog.pph
+++ b/gcc/cp/ChangeLog.pph
@@ -1,3 +1,9 @@
+2011-08-17 Diego Novillo
+
+ * pph-streamer.h (pph_out_tree_1): Rename from pph_out_tree_or_ref_1.
+ Update all users.
+ (pph_out_tree): Rename from pph_out_tree_or_ref. Update all users.
+
2011-08-16 Gabriel Charette
* pph-streamer-in.c (pph_read_file_1): Set location of replayed
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 96d41f3..ac10d44 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -6012,8 +6012,8 @@ pph_out_binding_table (pph_stream *stream, binding_table
bt)
if (bt->chain[i])
{
pph_out_record_marker (stream, PPH_RECORD_START);
- pph_out_tree_or_ref (stream, bt->chain[i]->name);
- pph_out_tree_or_ref (stream, bt->chain[i]->type);
+ pph_out_tree (stream, bt->chain[i]->name);
+ pph_out_tree (stream, bt->chain[i]->type);
}
else
pph_out_record_marker (stream, PPH_RECORD_END);
diff --git a/gcc/cp/pph-streamer-out.c b/gcc/cp/pph-streamer-out.c
index 1c5c5d4..b631825 100644
--- a/gcc/cp/pph-streamer-out.c
+++ b/gcc/cp/pph-streamer-out.c
@@ -458,9 +458,9 @@ pph_out_ld_base (pph_stream *stream, struct lang_decl_base
*ldb)
static void
pph_out_ld_min (pph_stream *stream, struct lang_decl_min *ldm)
{
- pph_out_tree_or_ref_1 (stream, ldm->template_info, 1);
+ pph_out_tree_1 (stream, ldm->template_info, 1);
if (ldm->base.u2sel == 0)
-pph_out_tree_or_ref_1 (stream, ldm->u2.access, 1);
+pph_out_tree_1 (stream, ldm->u2.access, 1);
else if (ldm->base.u2sel == 1)
pph_out_uint (stream, ldm->u2.discriminator);
else
@@ -496,7 +496,7 @@ pph_out_tree_vec (pph_stream *stream, VEC(tree,gc) *v)
pph_out_uint (stream, VEC_length (tree, v));
FOR_EACH_VEC_ELT (tree, v, i, t)
-pph_out_tree_or_ref (stream, t);
+pph_out_tree (stream, t);
}
@@ -539,8 +539,8 @@ pph_out_qual_use_vec (pph_stream *stream,
VEC(qualified_typedef_usage_t,gc) *v)
pph_out_uint (stream, VEC_length (qualified_typedef_usage_t, v));
FOR_EACH_VEC_ELT (qualified_typedef_usage_t, v, i, q)
{
- pph_out_tree_or_ref (stream, q->typedef_decl);
- pph_out_tree_or_ref (stream, q->context);
+ pph_out_tree (stream, q->typedef_decl);
+ pph_out_tree (stream, q->context);
/* FIXME pph: also write location. */
}
}
@@ -561,8 +561,8 @@ pph_out_cxx_binding_1 (pph_stream *stream, cxx_binding *cb)
if (!pph_out_start_record (stream, cb))
return;
- pph_out_tree_or_ref (stream, cb->value);
- pph_out_tree_or_ref (stream, cb->type);
+ pph_out_tree (stream, cb->value);
+ pph_out_tree (stream, cb->type);
pph_out_binding_level (stream, cb->scope, PPHF_NONE);
bp = bitpack_create (stream->encoder.w.ob->main_stream);
bp_pack_value (&bp, cb->value_is_inherited, 1);
@@ -600,7 +600,7 @@ pph_out_class_binding (pph_stream *stream, cp_class_binding
*cb)
return;
pph_out_cxx_binding (stream, cb->base);
- pph_out_tree_or_ref (stream, cb->identifier);
+ pph_out_tree (stream, cb->identifier);
}
@@ -612,8 +612,8 @@ pph_out_label_binding (pph_stream *stream, cp_label_binding
*lb)
if (!pph_out_start_record (stream, lb))
return;
- pph_out_tree_or_ref (stream, lb->label);
- pph_out_tree_or_ref (stream, lb->prev_value);
+ pph_out_tree (stream, lb->label);
+ pph_out_tree (stream, lb->prev_value);
}
@@ -628,7 +628,7 @@ pph_out_chained_tree (pph_stream *stream, tree t)
saved_chain = TREE_CHAIN (t);
TREE_CHAIN (t) = NULL_TREE;
- pph_out_tree_or_ref_1 (stream, t, 2);
+ pph_out_tree_1 (stream, t, 2);
TREE_CHAIN (t) = saved_chain;
}
@@ -688,14 +688
Re: [Patch, Fortran] PR 31461 - warn about unused implicitly imported variables/parameters
On Wed, Aug 17, 2011 at 06:13:47PM +0200, Tobias Burnus wrote: > The patch is rather obvious and simple - especially as the use_only > attribute already exists. > > Build and regtested on x86-64-linux. > OK? Yes. -- Steve
[Patch, Fortran] PR 31461 - warn about unused implicitly imported variables/parameters
The patch is rather obvious and simple - especially as the use_only
attribute already exists.
Build and regtested on x86-64-linux.
OK?
Tobias
2011-08-17 Tobias Burnus
PR fortran/31461
* trans-decl.c (generate_local_decl): Warn about
unused explicitly imported module variables/parameters.
2011-08-17 Tobias Burnus
PR fortran/31461
* gfortran.dg/warn_unused_var_2.f90: New.
* gfortran.dg/warn_unused_var_3.f90: New.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 12c5262..cdbb375 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -4453,6 +4453,9 @@ generate_local_decl (gfc_symbol * sym)
|| sym->attr.in_namelist))
gfc_warning ("Unused variable '%s' declared at %L", sym->name,
&sym->declared_at);
+ else if (warn_unused_variable && sym->attr.use_only)
+ gfc_warning ("Unused module variable '%s' which has been explicitly "
+ "imported at %L", sym->name, &sym->declared_at);
/* For variable length CHARACTER parameters, the PARM_DECL already
references the length variable, so force gfc_get_symbol_decl
@@ -4497,10 +4500,15 @@ generate_local_decl (gfc_symbol * sym)
else if (sym->attr.flavor == FL_PARAMETER)
{
if (warn_unused_parameter
- && !sym->attr.referenced
- && !sym->attr.use_assoc)
- gfc_warning ("Unused parameter '%s' declared at %L", sym->name,
- &sym->declared_at);
+ && !sym->attr.referenced)
+ {
+ if (!sym->attr.use_assoc)
+ gfc_warning ("Unused parameter '%s' declared at %L", sym->name,
+ &sym->declared_at);
+ else if (sym->attr.use_only)
+ gfc_warning ("Unused parameter '%s' which has been explicitly "
+ "imported at %L", sym->name, &sym->declared_at);
+ }
}
else if (sym->attr.flavor == FL_PROCEDURE)
{
--- /dev/null 2011-08-17 07:24:12.871882230 +0200
+++ gcc/gcc/testsuite/gfortran.dg/warn_unused_var_2.f90 2011-08-17 15:31:22.0 +0200
@@ -0,0 +1,19 @@
+! { dg-do compile }
+! { dg-options "-Wunused" }
+!
+! PR fortran/31461
+!
+! Contributed by Vivek Rao.
+!
+
+module util_mod
+ integer :: i,j
+end module util_mod
+
+program main
+ use util_mod, only: i,j ! { dg-warning "Unused module variable .i. which has been explicitly imported" }
+ j = 1
+ print*,"j=",j
+end program main
+
+! { dg-final { cleanup-modules "util_mod" } }
--- /dev/null 2011-08-17 07:24:12.871882230 +0200
+++ gcc/gcc/testsuite/gfortran.dg/warn_unused_var_3.f90 2011-08-17 17:13:05.0 +0200
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-options "-Wunused-parameter" }
+!
+! PR fortran/31461
+!
+module util_mod
+ integer, parameter :: i = 4
+end module util_mod
+
+program main
+use util_mod, only: i ! { dg-warning "Unused parameter .i. which has been explicitly imported" }
+integer, parameter :: j = 4 ! { dg-warning "Unused parameter .j. declared at" }
+end program main
+
+! { dg-final { cleanup-modules "util_mod" } }
[cxx-mem-model] Atomic C++ header file changes
Next step, change the C++ header files to use the new __sync builtins.
pretty straightforward.
mostly.
Turns out, C++ will allow you to specify the memory model as a variable
of type enum memory_order... WTF? I would expect that to be pretty
uncommon, and in order to get that right, we'd need a switch statement
and call the appropriate __sync_mem* routine with the appropriate
constant parameter.
That would be quite ugly, and you get what you deserve if you do that.
I changed the builtins so that if you dont specify a compile time
constant in the memory model parameter, it will simply default to
__SYNC_MEM_SEQ_CST, which will always be safe. That is standard
compliant (verified), and if anyone is really unhappy about it, then the
c++ headers can be really uglified by adding a bunch of switch
statements to handle this twisted case.
bootstraps and no new regressions. (In fact, it fixes one of the atomic
verification tests!)
Andrew
* gcc/builtins.c (get_memmodel): Allow non constant parameters and
default to MEMMODEL_SEQ_CST mode for these cases.
* libstdc++-v3/include/bits/atomic_2.h (__atomic2): Use new
__sync_mem routines.
Index: gcc/builtins.c
===
*** gcc/builtins.c (revision 177737)
--- gcc/builtins.c (working copy)
*** get_memmodel (tree exp)
*** 5225,5240
{
rtx op;
if (TREE_CODE (exp) != INTEGER_CST)
! {
! error ("invalid memory model argument to builtin");
! return MEMMODEL_RELAXED;
! }
op = expand_normal (exp);
if (INTVAL (op) < 0 || INTVAL (op) >= MEMMODEL_LAST)
{
error ("invalid memory model argument to builtin");
! return MEMMODEL_RELAXED;
}
return (enum memmodel) INTVAL (op);
}
--- 5225,5240
{
rtx op;
+ /* If the parameter is not a constant, it's a run time value so we'll just
+ convert it to MEMMODEL_SEQ_CST to avoid annoying runtime checking. */
if (TREE_CODE (exp) != INTEGER_CST)
! return MEMMODEL_SEQ_CST;
!
op = expand_normal (exp);
if (INTVAL (op) < 0 || INTVAL (op) >= MEMMODEL_LAST)
{
error ("invalid memory model argument to builtin");
! return MEMMODEL_SEQ_CST;
}
return (enum memmodel) INTVAL (op);
}
Index: libstdc++-v3/include/bits/atomic_2.h
===
*** libstdc++-v3/include/bits/atomic_2.h(revision 177737)
--- libstdc++-v3/include/bits/atomic_2.h(working copy)
*** namespace __atomic2
*** 60,78
bool
test_and_set(memory_order __m = memory_order_seq_cst)
{
! // Redundant synchronize if built-in for lock is a full barrier.
! if (__m != memory_order_acquire && __m != memory_order_acq_rel)
! __sync_synchronize();
! return __sync_lock_test_and_set(&_M_i, 1);
}
bool
test_and_set(memory_order __m = memory_order_seq_cst) volatile
{
! // Redundant synchronize if built-in for lock is a full barrier.
! if (__m != memory_order_acquire && __m != memory_order_acq_rel)
! __sync_synchronize();
! return __sync_lock_test_and_set(&_M_i, 1);
}
void
--- 60,72
bool
test_and_set(memory_order __m = memory_order_seq_cst)
{
! return __sync_mem_flag_test_and_set(&_M_i, __m);
}
bool
test_and_set(memory_order __m = memory_order_seq_cst) volatile
{
! return __sync_mem_flag_test_and_set(&_M_i, __m);
}
void
*** namespace __atomic2
*** 82,90
__glibcxx_assert(__m != memory_order_acquire);
__glibcxx_assert(__m != memory_order_acq_rel);
! __sync_lock_release(&_M_i);
! if (__m != memory_order_acquire && __m != memory_order_acq_rel)
! __sync_synchronize();
}
void
--- 76,82
__glibcxx_assert(__m != memory_order_acquire);
__glibcxx_assert(__m != memory_order_acq_rel);
! __sync_mem_flag_clear(&_M_i, __m);
}
void
*** namespace __atomic2
*** 94,102
__glibcxx_assert(__m != memory_order_acquire);
__glibcxx_assert(__m != memory_order_acq_rel);
! __sync_lock_release(&_M_i);
! if (__m != memory_order_acquire && __m != memory_order_acq_rel)
! __sync_synchronize();
}
};
--- 86,92
__glibcxx_assert(__m != memory_order_acquire);
__glibcxx_assert(__m != memory_order_acq_rel);
! __sync_mem_flag_clear(&_M_i, __m);
}
};
*** namespace __atomic2
*** 180,238
__int_type
operator++()
! { return __sync_add_and_fetch(&_M_i, 1); }
__int_type
operator++() volatile
! { return __sync_add_and_fetch(&_M_i, 1); }
__int_type
operator--()
! { return __sync_sub_and_fetch(&_M_i, 1);
tree hash maps and 'discards qualifiers' warnings?
I have been looking at changing UPC's method of
recording the blocking factor so that it uses less space
in the tree type node. The suggested method for
achieving this space reduction is to use a hash table to
map pointers to type nodes into UPC blocking factors
(for less commonly used blocking factor values).
In UPC, the default blocking factor for arrays is one,
and for UPC shared scalar/struct variables it is zero.
Therefore, the current approach is to only record
blocking factors greater than one in a hash table.
The basics are in place (in tree.h):
/* Non-zero if the UPC shared type refers to THREADS
in its array dimension. */
#define UPC_TYPE_HAS_THREADS_FACTOR(TYPE) TYPE_LANG_FLAG_3 (TYPE)
/* Non-zero if the UPC blocking factor is 0. */
#define UPC_TYPE_HAS_BLOCK_FACTOR_0(TYPE) TYPE_LANG_FLAG_4 (TYPE)
/* Non-zero if the UPC blocking factor is greater than 1.
In this case, the blocking factor value is stored in a hash table. */
#define UPC_TYPE_HAS_BLOCK_FACTOR_X(TYPE) TYPE_LANG_FLAG_5 (TYPE)
extern void upc_block_factor_insert (tree, tree);
extern tree upc_block_factor_lookup (tree);
/* Return the UPC blocking factor of the type given by NODE.
The default block factor is one. The additional flag bits
over-ride the default. */
#define UPC_TYPE_BLOCK_FACTOR(NODE) \
(UPC_TYPE_HAS_BLOCK_FACTOR_0 (NODE) ? size_zero_node \
: UPC_TYPE_HAS_BLOCK_FACTOR_X (NODE) ? upc_block_factor_lookup (NODE) \
: size_one_node)
Note above, that the bits used are the TYPE_LANG_FLAG bits.
This should be acceptable for UPC, because it is built as
a language variant.
Interestingly, if additional bits were allocated just for UPC,
they would likely increase the size of the tree node, because
there are no spare bits here:
struct GTY(()) tree_type_common {
[]
unsigned int precision : 10;
[...]
unsigned lang_flag_6 : 1;
The bit field sizes in the interval shown above total to 32 bits.
Therefore, it seems that any attempt to add new flag bits will
likely increase the size of a tree_type_common node.
The issue that I'm running into, however, is that the
re-implementation of UPC_TYPE_BLOCK_FACTOR() is not
plug-and-play with its previous version that used
a tree pointer in the node to record the blocking factor.
Here's why:
gcc/tree.c|5681 col 27| warning: passing argument 1 of
‘upc_block_factor_lookup’ discards qualifiers from pointer target type
gcc/tree.h|1196 col 13| note: expected ‘tree’ but argument is of type
‘const_tree’
The code referenced above is:
bool
check_qualified_type (const_tree cand, const_tree base, int type_quals)
{
return (TYPE_QUALS (cand) == type_quals
[...]
/* For UPC, the blocking factors have to be equal. */
&& tree_int_cst_equal (UPC_TYPE_BLOCK_FACTOR (cand),
UPC_TYPE_BLOCK_FACTOR (base))
[...]
}
The prototype for upc_block_factor_lookup() accepts a 'tree', not
a 'const_tree'. If the parameter is changed to 'const_tree',
then the body of the procedure will encounter another 'const' clash
because a tree_map is defined as having nodes of type 'tree',
not 'const_tree'. For example,
struct GTY(()) tree_map_base {
tree from;
};
NOTE: I looked at calls to DECL_VALUE_EXPR() to see if it ran
into this issue, however, only 'tree' nodes appear to be passed
to this function macro.
Any suggestions on how to work around this 'const' clash warning?
Thanks,
- Gary
Re: Vector Comparison patch
On Wed, Aug 17, 2011 at 3:58 PM, Richard Guenther
wrote:
> On Wed, Aug 17, 2011 at 3:30 PM, Artem Shinkarov
> wrote:
>> Hi
>>
>> Several comments before the new version of the patch.
>> 1) x != x
>> I am happy to adjust constant_boolean_node, but look at the code
>> around line 9074 in fold-const.c, you will see that x x
>> elimination, even with adjusted constant_boolean_node, will look about
>> the same as my code. Because I need to check the parameters (!FLOAT_P,
>> HONOR_NANS) on TREE_TYPE (arg0) not arg0, and I need to construct
>> constant_boolean_node (-1), not 1 in case of true.
>> But I will change constant_boolean_node to accept vector types.
>
> Hm, that should be handled transparently if you look at the defines
> of FLOAT_TYPE_P and the HONOR_* macros.
>
Ok, Currently I have this, what do you think:
int true_val = TREE_CODE (type) == VECTOR_TYPE ? -1 : 0;
tree arg0_type = TREE_CODE (type) == VECTOR_TYPE
? TREE_TYPE (TREE_TYPE (arg0)) : TREE_TYPE (arg0);
switch (code)
{
case EQ_EXPR:
if (! FLOAT_TYPE_P (arg0_type)
|| ! HONOR_NANS (TYPE_MODE (arg0_type)))
return constant_boolean_node (true_val, type);
break;
case GE_EXPR:
case LE_EXPR:
if (! FLOAT_TYPE_P (arg0_type)
|| ! HONOR_NANS (TYPE_MODE (arg0_type)))
return constant_boolean_node (true_val, type);
return fold_build2_loc (loc, EQ_EXPR, type, arg0, arg1);
case NE_EXPR:
/* For NE, we can only do this simplification if integer
or we don't honor IEEE floating point NaNs. */
if (FLOAT_TYPE_P (arg0_type)
&& HONOR_NANS (TYPE_MODE (arg0_type)))
break;
/* ... fall through ... */
case GT_EXPR:
case LT_EXPR:
return constant_boolean_node (0, type);
default:
gcc_unreachable ();
}
Works fine for both vector and scalar cases.
>>
>> 2) comparison vs vcond
>> v = v1 < v2;
>> v = v1 < v2 ? {-1,...} : {0,...};
>>
>> are not the same.
>> 16,25c16,22
>> < movdqa .LC1(%rip), %xmm1
>> < pshufd $225, %xmm1, %xmm1
>> < pshufd $39, %xmm0, %xmm0
>> < movss %xmm2, %xmm1
>> < pshufd $225, %xmm1, %xmm1
>> < pcmpgtd %xmm1, %xmm0
>> < pcmpeqd %xmm1, %xmm1
>> < pcmpeqd %xmm1, %xmm0
>> < pand %xmm1, %xmm0
>> < movdqa %xmm0, -24(%rsp)
>> ---
>>> pshufd $39, %xmm0, %xmm1
>>> movdqa .LC1(%rip), %xmm0
>>> pshufd $225, %xmm0, %xmm0
>>> movss %xmm2, %xmm0
>>> pshufd $225, %xmm0, %xmm0
>>> pcmpgtd %xmm0, %xmm1
>>> movdqa %xmm1, -24(%rsp)
>>
>> So I would keep the hook, it could be removed at any time when the
>> standard expansion will start to work fine.
>
> Which one is which?
You must be joking. :)
The first one (inefficient) is vec0 > vec1 ? {-1,...} : {0,...}
The second is vec0 > vec1. expand_vec_cond_expr is stupid, which is
fine, but it means that we need to construct it carefully.
> I'd really like to make this patch simpler at first,
> and removing that hook is an obvious thing that _should_ be possible,
> even optimally (by fixing the targets).
Ok, let's remove the hook, then could you provide some more
information rather than we just need to do it?
Simple in this case means inefficient -- I would hope to make it
efficient as well.
>> 3) mask ? vec0 : vec1
>> So no, I don't think we need to convert {3, 4, -1, 5} to {0,0,-1,0}
>> (that would surprise my anyway, I'd have expected {-1,-1,-1,-1} ;)).
>>
>> Does OpenCL somehow support you here?
>>
>> OpenCL says that vector operation mask ? vec0 : vec1 is the same as
>> select (vec0, vec1, mask). The semantics of select operation is the
>> following:
>>
>> gentype select (gentype a, gentype b, igentype c)
>> For each component of a vector type,
>> result[i] = if MSB of c[i] is set ? b[i] : a[i].
>>
>> I am not sure what they really understand using the term MSB. As far
>> as I know MSB is Most Significant Bit, so does it mean that in case of
>> 3-bit integer 100 would trigger true but 011 would be still false...
>
> Yes, MSB is Most Significant Bit - that's a somewhat odd definition ;)
>
>> My reading would be that if all bits set, then take the first element,
>> otherwise the second.
>>
>> It is also confusing when a ? vec0 : vec1, and a != 0 ? vec0 vec1
>> produce different results. So I would stick to all bits set being true
>> scenario.
>
> For the middle-end part definitely. Thus I'd simply leave the mask alone.
>
Well, it seems very unnatural to me. In the case of scalars mask ?
val0 : val1 would not work the same way as (mask & val0) | (~mask &
val1), why should we have the same behaviour for the vector stuff?
>> 4) Backend stuff. Ok, we could always fall back to reject the cases
>> when cond and operands have different type, and then fix the
Re: GIMPLE and intent of variables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/17/11 01:38, grabekm90 wrote: >> > > The question is: how can we get to know, using GIMPLE mechanism, from > which parameter a pointer derives? You'd have to build code to record the derivations. Ideally you'd work on the SSA graph and just record the derivations as you encounter them. PHIs will require a little more logic, but should be pretty straightforward. The dominator tree walker or CCP engine would be natural ways to structure this code. If you can't use the SSA graph, it gets a lot harder. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOS94mAAoJEBRtltQi2kC7xu4H/iGa/vXIrDfboFBVq/AXkkSd pCO6zM17LiNmdFtgqXrb2zU0MbAXrsEqsrefmfP9TD3iEgt9vCSB4Y0lwo7ZdRxA 0nd+tgomrCTYbgtjPGLdJrI5dH/4Vco6gaN6WjZ1R702U4ExakJjtOdEy4U8e2RI 06VG60qlnDREO/M3xhXCi/VefU1zZ3wlovxP4zf2EgL8hX+MOiAHTw0R8OYdiUTj IevJIguREhc8MxY76UxrYmL5orhXSQjUu9ZYn7T7kfqpz650JYtKOQ0ltNKXfxh0 6a8NYmTjTFuG01oBnJ4Wp5tIofuTsQL3Gd5TsIAspXrgNqawrseTK1LL4gYkNjQ= =q+oc -END PGP SIGNATURE-
[PATCH][1/n] Make sizetype no longer sign-extended
Of course when you work on one thing (do not force sizetype for
POINTER_PLUS_EXPR) you run into that other thing you had in the
works (but abandoned because it's sooo boring). Thus, here we come,
the appearant (huh!?) only pre-requesites to making sizetypes
no longer sign-extended (well, unsigned ones).
The issue is as usual - we think of these sizetype things as
twos-complement stuff (and thus are not worrying about signs),
but then go on and do arbitrary (signed) precision arithmetic
on them (using HOST_WIDE_INTs or double_ints) and interpret
the result, especially sometimes the sign-bit. To preserve
previous (albeit also questionable) behavior simply sign-extend
that twos-complement quantity if we want to end up with
something suitable for a signed HOST_WIDE_INT. That's certainly
easier than trying to think of a way to make callers of
get_inner_reference recognize that this bit_offset is a
pointer-bits + log2(BITS_PER_UNITS) twos-complement thing.
Joseph mentioned during the GCC Gathering that we shouldn't really
do so much with bit offsets (which later are usually just divided
by BITS_PER_UNIT anyway ...) and thus properly split in
a BITS_PER_UNIT and a remainder. That doesn't solve the issue
completely, but at least it would make issues less likely to show up.
Anyway, too much for now.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
I don't expect any issues, the patch is a noop right now (because
of that sign-extension of unsigned sizetype), but I'll leave it
until tomorrow for comments anyway.
Thanks,
Richard.
2011-08-17 Richard Guenther
* expr.c (get_inner_reference): Sign-extend the constant
twos-complement offset before doing arbitrary precision
arithmetic on it.
* tree-ssa-structalias.c (get_constraint_for_ptr_offset): Likewise.
(get_constraint_for_1): Pass the offset of a MEM_REF unchanged
to get_constraint_for_ptr_offset.
* tree-cfg.c (verify_types_in_gimple_reference): Do not
compare integer constants by pointer.
Index: trunk/gcc/expr.c
===
--- trunk.orig/gcc/expr.c 2011-08-17 16:28:06.0 +0200
+++ trunk/gcc/expr.c2011-08-17 16:24:58.0 +0200
@@ -6502,12 +6502,14 @@ get_inner_reference (tree exp, HOST_WIDE
/* If OFFSET is constant, see if we can return the whole thing as a
constant bit position. Make sure to handle overflow during
this conversion. */
- if (host_integerp (offset, 0))
+ if (TREE_CODE (offset) == INTEGER_CST)
{
- double_int tem = double_int_lshift (tree_to_double_int (offset),
- BITS_PER_UNIT == 8
- ? 3 : exact_log2 (BITS_PER_UNIT),
- HOST_BITS_PER_DOUBLE_INT, true);
+ double_int tem = tree_to_double_int (offset);
+ tem = double_int_sext (tem, TYPE_PRECISION (sizetype));
+ tem = double_int_lshift (tree_to_double_int (offset),
+ BITS_PER_UNIT == 8
+ ? 3 : exact_log2 (BITS_PER_UNIT),
+ HOST_BITS_PER_DOUBLE_INT, true);
tem = double_int_add (tem, bit_offset);
if (double_int_fits_in_shwi_p (tem))
{
Index: trunk/gcc/tree-cfg.c
===
--- trunk.orig/gcc/tree-cfg.c 2011-08-17 14:03:15.0 +0200
+++ trunk/gcc/tree-cfg.c2011-08-17 16:27:30.0 +0200
@@ -3030,7 +3030,8 @@ verify_types_in_gimple_reference (tree e
return true;
}
else if (TREE_CODE (op) == SSA_NAME
- && TYPE_SIZE (TREE_TYPE (expr)) != TYPE_SIZE (TREE_TYPE
(op)))
+ && !tree_int_cst_equal (TYPE_SIZE (TREE_TYPE (expr)),
+ TYPE_SIZE (TREE_TYPE (op
{
error ("conversion of register to a different size");
debug_generic_stmt (expr);
Index: trunk/gcc/tree-ssa-structalias.c
===
--- trunk.orig/gcc/tree-ssa-structalias.c 2011-08-17 14:13:21.0
+0200
+++ trunk/gcc/tree-ssa-structalias.c2011-08-17 16:08:25.0 +0200
@@ -2876,7 +2876,7 @@ get_constraint_for_ptr_offset (tree ptr,
{
struct constraint_expr c;
unsigned int j, n;
- HOST_WIDE_INT rhsunitoffset, rhsoffset;
+ HOST_WIDE_INT rhsoffset;
/* If we do not do field-sensitive PTA adding offsets to pointers
does not change the points-to solution. */
@@ -2891,15 +2891,24 @@ get_constraint_for_ptr_offset (tree ptr,
solution which includes all sub-fields of all pointed-to
variables of ptr. */
if (offset == NULL_TREE
- || !host_integerp (offset, 0))
+ || TREE_CODE (offset) != INTEGER_CST)
rhsoffset = UNKNOWN_OFFSET;
else
{
- /* Make sure the bit-offset also fits.
[PATCH] PR c++/47346 - access control for nested type is ignored in template
Hello,
Consider this code snippet:
class C
{
struct Private { };
};
template
struct exploit1
{
C::Private type;
};
exploit1 x1; //#1
At the instantiation point of exploit1 in #1, the compiler should
issue an error because C::Private is private in that context.
The infrastructure I have added a while back to do access checking of
references to types like this was limited to typedefs only. This bug
seems to suggest that the access checking of references to types, at
template instantiation should be done for references to all types, not
just typedefs.
But then, consider this other example:
class C
{
struct Private { };
};
template
struct exploit2 : C::Private
{
};
exploit2 x2;
g++ should warn here too, because access to C::Private is private in
this context. The problem is when
add_typedef_to_current_template_for_access_check is called (from
check_accessibility_of_qualified_id), during the parsing of the class
header, the "current template" representing exploit2 is not yet
created. So the reference to C::Private cannot be added to that
not-yet created template.
The patch below loosens the existing typedefs access checking
mechanisms to make it work for all type references, and defers the
scheduling of that access checking when the relevant template is not
yet created, until it becomes available.
It also adjusts two test cases that were using similar invalid
constructs that are now caught by the compiler.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* cp-tree.h (struct qualified_type_usage_s): Renamed struct
qualified_typedef_usage_s into this.
(qualified_type_usage_t): Renamed qualified_typedef_usage_t into
this.
(struct tree_template_info::type_needing_access_checking):
Renamed typedefs_needing_access_checking into this.
(TI_TYPES_NEEDING_ACCESS_CHECKING): Renamed
TI_TYPEDEFS_NEEDING_ACCESS_CHECKING into this.
(add_type_decl_to_current_template_for_access_check): Renamed
add_typedef_to_current_template_for_access_check into this.
(cp_parsing_class_head, cp_no_type_access_check_p): Declare new public
global variables.
(defer_type_access_check_for_cur_template)
(schedule_deferred_access_check_types_for_template): New
functions.
* semantics.c
(add_type_decl_to_current_template_for_access_check): Renamed
add_typedef_to_current_template_for_access_check into this. Make
it accept potentially accesses to all types, not just typedefs.
Make it defer the adding of the type access to the relevant
template when said template is not yet available.
(check_accessibility_of_qualified_id): Adjust.
* decl.c (make_typename_type): Adjust.
* parser.c (cp_parsing_class_head, cp_no_type_access_check_p):
Define new public global variables.
(cp_parser_elaborated_type_specifier): Don't schedule access
checks for qualified type names of friend declaration, when in a
template context.
(cp_parser_class_specifier_1): Schedule qualified type names
access check for type names access that happened while parsing the
class head of a class template.
(cp_parser_class_head): Notify the world when we are parsing a
class head.
* pt.c (cur_template_deferred_types_to_access_check): Define new
global static variable.
(perform_types_access_check): Renamed
perform_typedefs_access_check into this and adjust the body.
(instantiate_class_template_1, get_types_needing_access_check)
(append_type_to_template_for_access_check_1)
(append_type_to_template_for_access_check): Adjust.
(defer_type_access_check_for_cur_template)
(schedule_deferred_access_check_types_for_template): Define new
functions.
gcc/testsuite/
* g++.dg/template/access23.C: New test case.
* g++.dg/lto/20081219_1.C: Adjust.
* g++.dg/lto/20091002-1_0.C: Likewise.
---
gcc/cp/cp-tree.h | 27 +
gcc/cp/decl.c|4 +-
gcc/cp/parser.c | 27 -
gcc/cp/pt.c | 92 +++---
gcc/cp/semantics.c | 59 ---
gcc/testsuite/g++.dg/lto/20081219_1.C|1 +
gcc/testsuite/g++.dg/lto/20091002-1_0.C |1 +
gcc/testsuite/g++.dg/template/access23.C | 33 +++
8 files changed, 187 insertions(+), 57 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/template/access23.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index ff5509e..3b01573 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -696,18 +696,18 @@ struct GTY (()) tree_lambda_expr
In bar, the triplet will be (myint, foo, #1).
*/
-struct GTY(()) qualified_typ
Re: Vector Comparison patch
On Wed, Aug 17, 2011 at 3:30 PM, Artem Shinkarov
wrote:
> Hi
>
> Several comments before the new version of the patch.
> 1) x != x
> I am happy to adjust constant_boolean_node, but look at the code
> around line 9074 in fold-const.c, you will see that x x
> elimination, even with adjusted constant_boolean_node, will look about
> the same as my code. Because I need to check the parameters (!FLOAT_P,
> HONOR_NANS) on TREE_TYPE (arg0) not arg0, and I need to construct
> constant_boolean_node (-1), not 1 in case of true.
> But I will change constant_boolean_node to accept vector types.
Hm, that should be handled transparently if you look at the defines
of FLOAT_TYPE_P and the HONOR_* macros.
>
> 2) comparison vs vcond
> v = v1 < v2;
> v = v1 < v2 ? {-1,...} : {0,...};
>
> are not the same.
> 16,25c16,22
> < movdqa .LC1(%rip), %xmm1
> < pshufd $225, %xmm1, %xmm1
> < pshufd $39, %xmm0, %xmm0
> < movss %xmm2, %xmm1
> < pshufd $225, %xmm1, %xmm1
> < pcmpgtd %xmm1, %xmm0
> < pcmpeqd %xmm1, %xmm1
> < pcmpeqd %xmm1, %xmm0
> < pand %xmm1, %xmm0
> < movdqa %xmm0, -24(%rsp)
> ---
>> pshufd $39, %xmm0, %xmm1
>> movdqa .LC1(%rip), %xmm0
>> pshufd $225, %xmm0, %xmm0
>> movss %xmm2, %xmm0
>> pshufd $225, %xmm0, %xmm0
>> pcmpgtd %xmm0, %xmm1
>> movdqa %xmm1, -24(%rsp)
>
> So I would keep the hook, it could be removed at any time when the
> standard expansion will start to work fine.
Which one is which? I'd really like to make this patch simpler at first,
and removing that hook is an obvious thing that _should_ be possible,
even optimally (by fixing the targets).
> 3) mask ? vec0 : vec1
> So no, I don't think we need to convert {3, 4, -1, 5} to {0,0,-1,0}
> (that would surprise my anyway, I'd have expected {-1,-1,-1,-1} ;)).
>
> Does OpenCL somehow support you here?
>
> OpenCL says that vector operation mask ? vec0 : vec1 is the same as
> select (vec0, vec1, mask). The semantics of select operation is the
> following:
>
> gentype select (gentype a, gentype b, igentype c)
> For each component of a vector type,
> result[i] = if MSB of c[i] is set ? b[i] : a[i].
>
> I am not sure what they really understand using the term MSB. As far
> as I know MSB is Most Significant Bit, so does it mean that in case of
> 3-bit integer 100 would trigger true but 011 would be still false...
Yes, MSB is Most Significant Bit - that's a somewhat odd definition ;)
> My reading would be that if all bits set, then take the first element,
> otherwise the second.
>
> It is also confusing when a ? vec0 : vec1, and a != 0 ? vec0 vec1
> produce different results. So I would stick to all bits set being true
> scenario.
For the middle-end part definitely. Thus I'd simply leave the mask alone.
> 4) Backend stuff. Ok, we could always fall back to reject the cases
> when cond and operands have different type, and then fix the backend.
>
> Adjustments are coming.
>
>
> Artem.
>
Re: [ARM] PR 50090: aliases in libgcc.a with default visibility
On Wed, 17 Aug 2011, Richard Sandiford wrote: > libgcc/ > PR target/50090 > * config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias > instead of an assembly one. Is RENAME_LIBRARY_SET used at all after this patch or should it be removed? -- Joseph S. Myers jos...@codesourcery.com
Re: [ARM] PR 50090: aliases in libgcc.a with default visibility
On 17/08/11 11:48, Ramana Radhakrishnan wrote: > On 17 August 2011 08:59, Richard Sandiford > wrote: >> EABI functions like __aeabi_f2ulz are defined as aliases of standard >> libgcc functions like __fixunssfdi. In libgcc.a, the standard function >> gets the correct hidden visibility, but the alias retains default >> visibility. This means that DSOs linked against libgcc.a may end >> up exporting the libgcc.a definition of __aeabi_f2ulz. >> >> The bug is that bpabi-lib.h uses an asm statement to define an alias, >> so the standard ways of forcing hidden visibility at the C level have >> no effect. Fixed by using attributes instead. >> >> Tested on arm-linux-gnueabi. Also tested by making sure that libgcc.a >> defined no default-visibility symbols. OK for trunk? > > This is OK. > >> >> What about release branches? I suppose this isn't a regression, >> but it is a backwards-compatible ABI fix. > > I can't see why not. That's reason enough for me to consider the > backport but I'd like other maintainers to chime in. > Ok, provided there are no objections from the branch maintainers. R.
Re: CFT: [build] Move shlib support to toplevel libgcc
Tristan, >>>While alpha/t-vms already extracted symbol information with objdump >>>--syms, ia64/t-vms still used a hardcoded list >>>(ia64/vms_symvec_libgcc_s.opt). Since it has the comment `It would >>>be better to auto-generate this file.', I've omitted it, hoping that >>>the alpha procedure also works on ia64. This obviously needs to be >>>tested. >> >> Tristan, can you do that? > > Ok for ia64/vms as there are currently other build issue with ia64/vms that I > have to fix. I will fix that later too. ok, thanks. >> The patch is okay after it has been bootstrapped on IA64/VMS and Win32. Kai, could you please try the patch on Win32? Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] GNU/kFreeBSD systems running on MIPS
Hi Robert, > My patch still applies cleanly to current HEAD, has this migration > happened already? If not, what's the current ETA? I'll have almost > no spare time after this week, I'd like to sort this out before/during > the weekend if possible. all the relevant patches have been posted by now. One needs a bit work, the others are awaiting review. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Vector Comparison patch
Hi
Several comments before the new version of the patch.
1) x != x
I am happy to adjust constant_boolean_node, but look at the code
around line 9074 in fold-const.c, you will see that x x
elimination, even with adjusted constant_boolean_node, will look about
the same as my code. Because I need to check the parameters (!FLOAT_P,
HONOR_NANS) on TREE_TYPE (arg0) not arg0, and I need to construct
constant_boolean_node (-1), not 1 in case of true.
But I will change constant_boolean_node to accept vector types.
2) comparison vs vcond
v = v1 < v2;
v = v1 < v2 ? {-1,...} : {0,...};
are not the same.
16,25c16,22
< movdqa .LC1(%rip), %xmm1
< pshufd $225, %xmm1, %xmm1
< pshufd $39, %xmm0, %xmm0
< movss %xmm2, %xmm1
< pshufd $225, %xmm1, %xmm1
< pcmpgtd %xmm1, %xmm0
< pcmpeqd %xmm1, %xmm1
< pcmpeqd %xmm1, %xmm0
< pand%xmm1, %xmm0
< movdqa %xmm0, -24(%rsp)
---
> pshufd $39, %xmm0, %xmm1
> movdqa .LC1(%rip), %xmm0
> pshufd $225, %xmm0, %xmm0
> movss %xmm2, %xmm0
> pshufd $225, %xmm0, %xmm0
> pcmpgtd %xmm0, %xmm1
> movdqa %xmm1, -24(%rsp)
So I would keep the hook, it could be removed at any time when the
standard expansion will start to work fine.
3) mask ? vec0 : vec1
So no, I don't think we need to convert {3, 4, -1, 5} to {0,0,-1,0}
(that would surprise my anyway, I'd have expected {-1,-1,-1,-1} ;)).
Does OpenCL somehow support you here?
OpenCL says that vector operation mask ? vec0 : vec1 is the same as
select (vec0, vec1, mask). The semantics of select operation is the
following:
gentype select (gentype a, gentype b, igentype c)
For each component of a vector type,
result[i] = if MSB of c[i] is set ? b[i] : a[i].
I am not sure what they really understand using the term MSB. As far
as I know MSB is Most Significant Bit, so does it mean that in case of
3-bit integer 100 would trigger true but 011 would be still false...
My reading would be that if all bits set, then take the first element,
otherwise the second.
It is also confusing when a ? vec0 : vec1, and a != 0 ? vec0 vec1
produce different results. So I would stick to all bits set being true
scenario.
4) Backend stuff. Ok, we could always fall back to reject the cases
when cond and operands have different type, and then fix the backend.
Adjustments are coming.
Artem.
Re: CFT: [build] Move shlib support to toplevel libgcc
On Aug 11, 2011, at 1:52 PM, Paolo Bonzini wrote: > On 08/10/2011 01:14 PM, Rainer Orth wrote: >> * At the moment, SHLIB_LINK is used in gcc/Makefile.in and the various >> Make-lang.in fragments to check if the target supports a shared >> libgcc_s. I've introduced gcc/config/t-slibgcc (from t-slibgcc-dummy) >> for this, which sets SHLIB = true, adding that fragment to all targets >> in config.gcc that do. There may be a better way to handle this. > > Yes, there is no need to use $(shell) in the first place---you can use > ifeq/ifneq---and perhaps an AC_DEFINE will be even better. But I agree this > is the simplest way to fix it for now. > >> ** AIX: >> >>Both t-aix43 and t-aix52 SHLIB_* variables now live in >>rs6000/t-slibgcc-aix. They were identical except that the t-aix52 >>variant had been updated for cross-compilation. I haven't changed >>them to allow use of t-slibgcc, but that could perhaps be done as a >>followup. > > No need for that. > >> ** HP-UX: >> >>After editing the PA and IA-64 HP-UX SHLIB_* variables into a form to >>allow comparison with t-slibgcc, it turned out that the differences >>are actually minimal. I only needed to introduce INSTALL_SHLIB to >>allow for the install -m 555 of the shared libgcc_s only needed on >>HP-UX. > > Very nice. > >>BASEVER_c isn't available outside of gcc, so I need to parse $(CC) >>--version output instead. > > We could also (later) write an M4 macro to process gcc/BASE-VER and friends, > and substitute those into the Makefile. > >>While alpha/t-vms already extracted symbol information with objdump >>--syms, ia64/t-vms still used a hardcoded list >>(ia64/vms_symvec_libgcc_s.opt). Since it has the comment `It would >>be better to auto-generate this file.', I've omitted it, hoping that >>the alpha procedure also works on ia64. This obviously needs to be >>tested. > > Tristan, can you do that? Ok for ia64/vms as there are currently other build issue with ia64/vms that I have to fix. I will fix that later too. Tristan. > >> ** Windows: >> >>While the windows code hasn't been touched apart from the move, the >>various t-* fragments are so interdependent that I could easily have >>made a mistake. > > Looks good. > >> * The test for sjlj exceptions was already (almost) duplicated 3 times >> in libgo (for C), libjava (for C++), and libobjc (for Objective-C). >> I've created just another copy from the libgo variant, but it would be >> better to centralize this. > > Please add a comment on top of it, so that we can take care of this later. > >> * There's another issue I haven't attacked yet: while currently >> libgcc/Makefile.in performs a couple of substitions on SHLIB_* >> variables, this shouldn't be necessary any longer: >> >> @multilib_dir@ $(MULTIDIR) >> @multilib_flags@ $(CFLAGS) -B./ >> @shlib_base_name@ libgcc_s >> @shlib_map_file@$(mapfile) >> @shlib_objs@$(objects) >> @shlib_slibdir@ $(shlib_slibdir) >> @shlib_slibdir_qual@$(MULTIOSSUBDIR) >> >> There should be a better way to handle this. > > Indeed, but it can be done later. We can change this: > > libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts) ># @multilib_flags@ is still needed because this may use ># $(GCC_FOR_TARGET) and $(LIBGCC2_CFLAGS) directly. ># @multilib_dir@ is not really necessary, but sometimes it has ># more uses than just a directory name. >$(mkinstalldirs) $(MULTIDIR) >$(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \ >@multilib_dir@,$(MULTIDIR),$(subst \ >@shlib_objs@,$(objects),$(subst \ >@shlib_base_name@,libgcc_s,$(subst \ >@shlib_map_file@,$(mapfile),$(subst \ >@shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \ >@shlib_slibdir@,$(shlib_slibdir),$(SHLIB_LINK > > to: > > DUMMY := $(shell $(mkinstalldirs) $(MULTIDIR)) > libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts) > > and then change the definitions of SHLIB_LINK to rules for > libgcc_s$(SHLIB_EXT). Likewise for other cases. > >> Could affected OS port/target maintainers please give the patch a try? > > The patch is okay after it has been bootstrapped on IA64/VMS and Win32. > > Paolo
Re: [c++] Keep tm, div_t, ldiv_t, lconv mangling on Solaris (PR libstdc++-v3/1773)
Jason Merrill writes:
> On 08/16/2011 11:31 AM, Marc Glisse wrote:
>> It might be less invasive to have decl_mangling_context return
>> global_namespace without actually modifying the expr?
>
> Please.
Done, tested as before.
Rainer
2011-08-07 Rainer Orth
Marc Glisse
gcc:
PR libstdc++-v3/1773
* target.def (decl_mangling_context): New C++ hook.
* doc/tm.texi: Regenerate.
* config/sol2-cxx.c, config/sol2-stubs.c: New files.
* config/sol2-protos.h: Group by source file.
(solaris_cxx_decl_mangling_context): Declare.
* config/sol2.h (TARGET_CXX_DECL_MANGLING_CONTEXT): Define.
* config/t-sol2 (sol2-cxx.o, sol2-stubs.o): New targets.
Use $<.
* config.gcc (*-*-solaris2*): Add sol2-cxx.o to cxx_target_objs.
Add sol2-stubs.o to extra_objs.
gcc/cp:
PR libstdc++-v3/1773
* mangle.c (decl_mangling_context): Call
targetm.cxx.decl_mangling_context.
(write_unscoped_name): Use decl_mangling_context.
# HG changeset patch
# Parent da2cbe8d1768a3ceb7ca3b9b7a739434168793e3
Keep tm, div_t, ldiv_t, lconv mangling on Solaris (PR libstdc++-v3/1773)
diff --git a/gcc/config.gcc b/gcc/config.gcc
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -718,8 +718,8 @@ case ${target} in
tm_p_file="${tm_p_file} sol2-protos.h"
tmake_file="${tmake_file} t-sol2 t-slibgcc-dummy"
c_target_objs="${c_target_objs} sol2-c.o"
- cxx_target_objs="${cxx_target_objs} sol2-c.o"
- extra_objs="sol2.o"
+ cxx_target_objs="${cxx_target_objs} sol2-c.o sol2-cxx.o"
+ extra_objs="sol2.o sol2-stubs.o"
extra_options="${extra_options} sol2.opt"
case ${enable_threads}:${have_pthread_h}:${have_thread_h} in
"":yes:* | yes:yes:* )
diff --git a/gcc/config/sol2-cxx.c b/gcc/config/sol2-cxx.c
new file mode 100644
--- /dev/null
+++ b/gcc/config/sol2-cxx.c
@@ -0,0 +1,64 @@
+/* C++ specific Solaris system support.
+ Copyright (C) 2011 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC 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 GCC; see the file COPYING3. If not see
+
Re: [patch, ARM] Change default vector size to 128 bits - take 3
On 16/08/11 10:28, Ira Rosen wrote:
> Hi,
>
> This patch changes the default vector size for auto-vectorization on
> ARM NEON to 128 bits. This new version is a result of a discussion
> with Richard and Ramana.
>
> wwwdocs changes will follow shortly.
>
> Bootstrapped and tested on arm-linux-gnueabi. The testsuite changes
> were also checked on powerpc64-suse-linux and x86_64-suse-linux.
>
> There is one new failure:
> gcc.c-torture/execute/mode-dependent-address.c fails with -O3
> -funroll-loops with this patch or with -mvectorize-with-neon-quad.
> Ramana has a patch to fix this
> http://gcc.gnu.org/ml/gcc/2011-08/msg00284.html. I will wait with
> committing my patch until this issue is resolved.
>
> OK for mainline?
>
> Thanks,
> Ira
>
> ChangeLog:
>
>* config/arm/arm.c (arm_preferred_simd_mode): Check
>TARGET_NEON_VECTORIZE_DOUBLE instead of
>TARGET_NEON_VECTORIZE_QUAD.
>(arm_expand_sync): Likewise.
>* config/arm/arm.opt (mvectorize-with-neon-quad): Make inverse
>mask of mvectorize-with-neon-double. Add RejectNegative.
>(mvectorize-with-neon-double): New.
>
> testsuite/ChangeLog:
>
>* lib/target-supports.exp (check_effective_target_vect_multiple_sizes):
>New procedure.
>(add_options_for_quad_vectors): Replace with ...
>(add_options_for_double_vectors): ... this.
>* gfortran.dg/vect/pr19049.f90: Expect more printings on targets that
> support multiple vector sizes since the vectorizer attempts to
> vectorize with both vector sizes.
>* gcc.dg/vect/no-vfa-vect-79.c,
> gcc.dg/vect/no-vfa-vect-102a.c, gcc.dg/vect/vect-outer-1a.c,
> gcc.dg/vect/vect-outer-1b.c, gcc.dg/vect/vect-outer-2b.c,
> gcc.dg/vect/vect-outer-3a.c, gcc.dg/vect/no-vfa-vect-37.c,
> gcc.dg/vect/vect-outer-3b.c, gcc.dg/vect/no-vfa-vect-101.c,
> gcc.dg/vect/no-vfa-vect-102.c, gcc.dg/vect/vect-reduc-dot-s8b.c,
> gcc.dg/vect/vect-outer-1.c, gcc.dg/vect/vect-104.c: Likewise.
>* gcc.dg/vect/vect-42.c: Run with 64 bit vectors if applicable.
>* gcc.dg/vect/vect-multitypes-6.c, gcc.dg/vect/vect-52.c,
>gcc.dg/vect/vect-54.c, gcc.dg/vect/vect-46.c, gcc.dg/vect/vect-48.c,
>gcc.dg/vect/vect-96.c, gcc.dg/vect/vect-multitypes-3.c,
>gcc.dg/vect/vect-40.c: Likewise.
> * gcc.dg/vect/vect-outer-5.c: Remove quad-vectors option as
>redundant.
> * gcc.dg/vect/vect-109.c, gcc.dg/vect/vect-peel-1.c,
>gcc.dg/vect/vect-peel-2.c, gcc.dg/vect/slp-25.c,
>gcc.dg/vect/vect-multitypes-1.c, gcc.dg/vect/slp-3.c,
>gcc.dg/vect/no-vfa-pr29145.c, gcc.dg/vect/vect-multitypes-4.c:
>Likewise.
> * gcc.dg/vect/vect-peel-4.c: Make ia global.
>
Ok with the following change:
> static unsigned int
> arm_autovectorize_vector_sizes (void)
> {
> - return TARGET_NEON_VECTORIZE_QUAD ? 16 | 8 : 0;
> + return TARGET_NEON_VECTORIZE_DOUBLE ? 0 : 16 | 8;
> }
Please put parentheses round the expression to make the precedence explicit.
R.
Re: [PATCH] GNU/kFreeBSD systems running on MIPS
Hi! 2011/7/26 Rainer Orth : > Robert, > >> 2011/7/25 Richard Sandiford : >>> Robert Millan writes: This patch adds support for GNU/kFreeBSD systems running on MIPS. >>> >>> Looks good. However, Rainer's in the middle of moving things from gcc/ >>> to libgcc/ -- where they belong -- and committing a new port now would >>> interfere with that. If it's OK, I'd like to hold off applying this >>> until Rainer's finished his changes. > I'm in the middle of moving shlib support (another day), need to rebase > crtstuff and libgcc1, and finish libgcc2. My patch still applies cleanly to current HEAD, has this migration happened already? If not, what's the current ETA? I'll have almost no spare time after this week, I'd like to sort this out before/during the weekend if possible. Thanks! -- Robert Millan
[PATCH][3/n] Do not force sizetype for POINTER_PLUS_EXPR
This patch removes more explicit sizetype references by (but not only by) introducing convert_to_ptrofftype[_loc]. It's still trivial conversions so even with the no-op abstraction we can be sure to not introduce new errors. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2011-08-17 Richard Guenther * tree.h (convert_to_ptrofftype_loc): New function. (convert_to_ptrofftype): Define. * builtins.c (expand_builtin_bzero): Use size_type_node. (fold_builtin_bzero): Likewise. (std_gimplify_va_arg_expr): Build the BIT_AND_EXPR on the pointer. * c-typeck.c (build_unary_op): Use convert_to_ptrofftype_loc. * cgraphunit.c (thunk_adjust): Use fold_build_pointer_plus_loc. (cgraph_redirect_edge_call_stmt_to_callee): Use size_int. * expr.c (expand_expr_addr_expr_1): Use fold_build_pointer_plus. * fold-const.c (build_range_check): Negate using the original type. (fold_unary_loc): Use fold_build_pointer_plus_loc. * gimple-fold.c (gimple_adjust_this_by_delta): Use convert_to_ptrofftype. * gimplify.c (gimplify_self_mod_expr): Likewise. * graphite-clast-to-gimple.c (clast_to_gcc_expression): Likewise. (graphite_create_new_loop_guard): Likewise. * graphite-sese-to-poly.c (my_long_long): Remove. (scop_ivs_can_be_represented): Adjust. * tree-cfg.c (verify_gimple_assign_unary): Use ptrofftype_p. * tree-chrec.c (chrec_fold_plus_1): Use fold_build_pointer_plus. * tree-loop-distribution.c (build_size_arg_loc): Use size_type_node. (generate_memset_zero): Simplify. * tree-mudflap.c: Use fold_convert, not convert. * tree-predcom.c (suitable_reference_p): Expand DR_OFFSET in its own type. (determine_offset): Likewise for DR_STEP. (valid_initializer_p): Likewise. * tree-profile.c (prepare_instrumented_value): Convert the pointer to an integer type of same size. * tree-scalar-evolution.c (interpret_rhs_expr): Do not refer to sizetype without need. * tree-ssa-address.c (tree_mem_ref_addr): Likewise. * tree-ssa-loop-ivopts.c (find_bivs): Use convert_to_ptrofftype. * tree-ssa-loop-manip.c (create_iv): Likewise. (determine_exit_conditions): Adjust comment. * tree-ssa-pre.c (create_expression_by_pieces): Use convert_to_ptrofftype. * tree-ssa-structalias.c (get_constraint_for_1): Likewise. * varasm.c (array_size_for_constructor): Compute using double_ints. Index: trunk/gcc/builtins.c === *** trunk.orig/gcc/builtins.c 2011-08-17 10:17:49.0 +0200 --- trunk/gcc/builtins.c2011-08-17 12:35:56.0 +0200 *** expand_builtin_bzero (tree exp) *** 3631,3637 calling bzero instead of memset. */ return expand_builtin_memset_args (dest, integer_zero_node, !fold_convert_loc (loc, sizetype, size), const0_rtx, VOIDmode, exp); } --- 3631,3638 calling bzero instead of memset. */ return expand_builtin_memset_args (dest, integer_zero_node, !fold_convert_loc (loc, ! size_type_node, size), const0_rtx, VOIDmode, exp); } *** std_gimplify_va_arg_expr (tree valist, t *** 4225,4235 fold_build_pointer_plus_hwi (valist_tmp, boundary - 1)); gimplify_and_add (t, pre_p); - t = fold_convert (sizetype, valist_tmp); t = build2 (MODIFY_EXPR, TREE_TYPE (valist), valist_tmp, ! fold_convert (TREE_TYPE (valist), ! fold_build2 (BIT_AND_EXPR, sizetype, t, !size_int (-boundary; gimplify_and_add (t, pre_p); } else --- 4226,4235 fold_build_pointer_plus_hwi (valist_tmp, boundary - 1)); gimplify_and_add (t, pre_p); t = build2 (MODIFY_EXPR, TREE_TYPE (valist), valist_tmp, ! fold_build2 (BIT_AND_EXPR, TREE_TYPE (valist), ! valist_tmp, ! build_int_cst (TREE_TYPE (valist), -boundary))); gimplify_and_add (t, pre_p); } else *** fold_builtin_bzero (location_t loc, tree *** 7969,7975 calling bzero instead of memset. */ return fold_builtin_memset (loc, dest, integer_zero_node, ! fold_convert_loc (loc, sizetype, size), void_type_node, ignore); } --- 7969,7975 calling bzero instead of memset. */ return fold_builtin_memset (loc, dest, integer_zero_node, ! fol
Re: [PING] [PR43597, ARM, TESTCASE]
On 17 August 2011 10:34, Tom de Vries wrote: > > Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02173.html OK for trunk? This is OK. Ramana > > Thanks, > - Tom >
Re: [ARM] PR 50090: aliases in libgcc.a with default visibility
On 17 August 2011 08:59, Richard Sandiford wrote: > EABI functions like __aeabi_f2ulz are defined as aliases of standard > libgcc functions like __fixunssfdi. In libgcc.a, the standard function > gets the correct hidden visibility, but the alias retains default > visibility. This means that DSOs linked against libgcc.a may end > up exporting the libgcc.a definition of __aeabi_f2ulz. > > The bug is that bpabi-lib.h uses an asm statement to define an alias, > so the standard ways of forcing hidden visibility at the C level have > no effect. Fixed by using attributes instead. > > Tested on arm-linux-gnueabi. Also tested by making sure that libgcc.a > defined no default-visibility symbols. OK for trunk? This is OK. > > What about release branches? I suppose this isn't a regression, > but it is a backwards-compatible ABI fix. I can't see why not. That's reason enough for me to consider the backport but I'd like other maintainers to chime in. cheers Ramana
Re: [Patch 3/4] ARM 64 bit sync atomic operations [V2]
On 26 July 2011 10:01, Dr. David Alan Gilbert wrote: > Micahel K. Edwards points out in PR/48126 that the sync is in the wrong > place > relative to the branch target of the compare, since the load could float > up beyond the ldrex. > > gcc/ > * config/arm/arm.c (arm_output_sync_loop): Move label before barier, > fixes PR/48126 s/barier/barrier. This is OK for trunk and appropriate release branches after due testing. Next time note that the Changelog entry should read - The PR number really shouldn't be a part of the actual log. PR target/48126 * config/arm/arm.c (arm_output_sync_loop): Move label before barrier. with appropriate formatting. Thanks, Ramana
Re: Vector Comparison patch
On Tue, Aug 16, 2011 at 11:12 PM, Artem Shinkarov
wrote:
> Hi, here is a new version of the patch with the adjustments.
>
> Two important comments.
> 1) At the moment when I expand expression mask ? vec0 : vec1, I
> replace mask with (mask == {-1,-1,..}). The first reason is that
> expand_vec_cond_expr requires first operand to be a comparison. Second
> reason is that a mask {3, 4, -1, 5} should be transformed into
> {0,0,-1,0} in order to simulate vcond as ((vec0 & mask) | (vec1 &
> ~mask)). So in both cases we need this adjustment.
Well. From a middle-end view I'd say that mask ? vec0 : vec1
should return (vec0 & mask) | (vec1 & ~mask) which is what
the XOP vcond instructions do, btw. Only by defining
v1 < v2 to return a mask constrained to {-1|0, -1|0, ...} the
combination v1 < v2 ? vec0 : vec1 gets it's vector element
selection semantic (instead of being just a bitwise selection,
which it really is).
So no, I don't think we need to convert {3, 4, -1, 5} to {0,0,-1,0}
(that would surprise my anyway, I'd have expected {-1,-1,-1,-1} ;)).
Does OpenCL somehow support you here?
> 2) Vector comparison through optab.
> As far as I just have adjusted expand_vector_operation in
> tree-vect-generic.c, it would be called only when there is no
> sufficient optab. I is being checked in expand_vector_operations_1. So
> the only place where I try to find an optab for the comparison is
> expand_vec_cond_expr_piecewise, which I adjusted.
>
> As for the vector hook, it will be triggered only when we don't have
> an appropriate optab.
>
> bootstrapped and tested on x86_64-unknown-linux-gnu.
> Anything else?
I didn't yet look at the updated patch, I'll wait for another update that
eventually follows my comments to your earlier mail.
Richard.
>
> Artem.
>
Re: Vector Comparison patch
On Tue, Aug 16, 2011 at 6:35 PM, Artem Shinkarov
wrote:
> On Tue, Aug 16, 2011 at 4:28 PM, Richard Guenther
> wrote:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c (revision 177665)
+++ gcc/fold-const.c (working copy)
@@ -9073,34 +9073,61 @@ fold_comparison (location_t loc, enum tr
floating-point, we can only do some of these simplifications.) */
if (operand_equal_p (arg0, arg1, 0))
{
- switch (code)
+ if (TREE_CODE (TREE_TYPE (arg0)) == VECTOR_TYPE)
{
- case EQ_EXPR:
- if (! FLOAT_TYPE_P (TREE_TYPE (arg0))
- || ! HONOR_NANS (TYPE_MODE (TREE_TYPE (arg0
- return constant_boolean_node (1, type);
I think this change should go in a separate patch for improved
constant folding. It shouldn't be necessary for enabling vector compares,
no?
>>>
>>> Unfortunately no, this case must be covered here, otherwise x != x
>>> condition fails.
>>
>> How does it fail?
>
> When I have x > x, x == x, and so on, fold-const.c trigger
> operand_equal_p (arg0, arg1, 0), which returns true, and then it calls
> constant_boolean_node (, type). But the problem is that the
> result of the comparison is a vector, not a boolean. So we have an
> assertion failure:
> test.c: In function ‘foo’:
> test.c:9:3: internal compiler error: in build_int_cst_wide, at tree.c:1222
> Please submit a full bug report,
> with preprocessed source if appropriate.
Ok, so we have to either avoid folding it (which would be a shame), or
define how true / false look like for vector typed comparison results.
The documentation above the tree code defintions for comparisons in
tree.def needs updating then, with something like
and the value is either the type used by the language for booleans
or an integer vector type of the same size and with the same number
of elements as the comparison operands. True for a vector of
comparison results has all bits set while false is equal to zero.
or some better wording.
Then changing constant_boolean_node to return a proper true/false
vector would be the fix for your problem.
+ /* Currently the expansion of VEC_COND_EXPR does not allow
+ expessions where the type of vectors you compare differs
+ form the type of vectors you select from. For the time
+ being we insert implicit conversions. */
+ if ((COMPARISON_CLASS_P (ifexp)
Why only for comparison-class?
>>> Not only, there is || involved:
>>> (COMPARISON_CLASS_P (ifexp) && TREE_TYPE (TREE_OPERAND (ifexp, 0)) !=
>>> type1)
>>> || TREE_TYPE (ifexp) != type1
>>>
>>> So if this is a comparison class, we check the first operand, because
>>> the result of the comparison fits, however the operands could not. In
>>> case we have an expression of signed vector, we know that we would
>>> transform it into exp != {0,0,...} in tree-vect-generic.c, but if the
>>> types of operands do not match we convert them.
>>
>> Hm, ok ... let's hope we can sort-out the backend issues before this
>> patch goes in so we can remove this converting stuff.
>
> Hm, I would hope that we could commit this patch even with this issue,
> because my feeling is that this case would produce errors on all the
> other architectures as well, as VEC_COND_EXPR is the feature heavily
> used in auto-vectorizer. So it means that all the backends must be
> fixed. And another argument, that this conversion is harmless.
It shouldn't be hard to fix all the backends. And if we don't do it now
it will never happen. I would expect that the codegen part of the
backends doesn't need any adjustments, just the patterns that
match what is supported.
Uros, can you convert x86 as an example? Thus, for
(define_expand "vcond"
[(set (match_operand:VF 0 "register_operand" "")
(if_then_else:VF
(match_operator 3 ""
[(match_operand:VF 4 "nonimmediate_operand" "")
(match_operand:VF 5 "nonimmediate_operand" "")])
(match_operand:VF 1 "general_operand" "")
(match_operand:VF 2 "general_operand" "")))]
"TARGET_SSE"
{
bool ok = ix86_expand_fp_vcond (operands);
gcc_assert (ok);
allow any vector mode of the same size (and same number of elements?)
for the vcond mode and operand 1 and 2? Thus, only restrict the
embedded comparison to VF?
> So I really hope that someone could shed some light or help me with
> this issue, but even if not I think that the current conversion is ok.
> However, I don't have any architectures different from x86.
[...]
+ /* Expand VEC_COND_EXPR into a vector of scalar COND_EXPRs. */
+ v = VEC_alloc(constructor_elt, gc, nunits);
+ for (i = 0; i < nunits;
+ i += 1, index = int_const_binop (PLUS_EXPR, index, part_width))
+ {
+ tree tcond = tree_vec_extract (gsi, inner_type, var, p
[PING][PATCH PR43513] Replace vla with array
Hi Richard, Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02730.html and http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02733.html ok for trunk? Thanks, - Tom
[PING] [PR43597, ARM, TESTCASE]
Hi Richard, Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02173.html OK for trunk? Thanks, - Tom
Re: [Patch, Fortran] PR 50070: Segmentation fault at size_binop_loc in fold-const.c
>> In any case, the patch was regtested on x86_64-unknown-linux-gnu. Ok for >> trunk? > > OK. Thanks for the patch! Thanks, Tobias. Committed as r177825. Cheers, Janus >> 2011-08-16 Janus Weil >> >> PR fortran/50070 >> * resolve.c (resolve_fl_variable): Reject non-constant character >> lengths >> in COMMON variables. >> >> >> 2011-08-16 Janus Weil >> >> PR fortran/50070 >> * gfortran.dg/common_13.f90: New. > >
Re: GIMPLE and intent of variables
On Wed, Aug 17, 2011 at 9:38 AM, grabekm90 wrote:
>
>
>
> Jeff Law wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 08/16/11 15:35, grabekm90 wrote:
>>
>>> How to resolve a problem with pointers (especially arrays)? For
>>> example, we have a GIMPLE function:
>>>
>>> set_a (int * a) { int * D.2701; D.2701 = a + 40; *D.2701 = 7; }
>>>
>>> This is equivalent code in C:
>>>
>>> void set_a(int * a) { a[10] = 107; }
>>>
>>> GIMPLE tries to avoid operations on the left side of the assign sign.
>>> There is a problem because I want to identify local variable (D.2701)
>>> with function parameter (a). In this case "a" is output parameter. I
>>> could follow a behavior of parameters in my plugin, but I suppose
>>> that GIMPLE makes accessible better solution, doesn't it?
>> Adding/subtracting from a pointer should result in another pointer to a
>> different part of the same object. So anytime I saw
>> = +- index
>>
>> I'd record that was a derived pointer.
>>
>> jeff
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJOSuPvAAoJEBRtltQi2kC7p6AH/3x6EXhLr4os3FjFklvNdJk6
>> FsGYnl9l3ZxRzYv5TyS6Pe2hzZaRPzZyF0a6r6/pZ9KqxlBA7XQwIAxjBnW37+DK
>> LypIeCz7IeQDqPnB2OV9e271Q+b6EWPhSg/csAAeGqKtmixjwNC2Zjkgjbf5Anmn
>> WtSyo12A2b16f24I/bHw36frupcBF7adMBK5CyQVthoMkbVsporvG9Yz4NX/vmF+
>> 2UPGw3wap9SIsMEs9bG/OA13Q2WsQS7EJw2n5GH4gdlEwMmd6e8WsuQ0802SkHdX
>> aVgwIJ0xQbk2RuVnRb8244u+6AOuVT4yVVvHJ5QGfON/UoLFUKa1SPUXRSRLKaM=
>> =HggP
>> -END PGP SIGNATURE-
>>
>>
>
> The question is: how can we get to know, using GIMPLE mechanism, from which
> parameter a pointer derives?
There are none. You can use SSA mechanisms to look up the definition
chain or use points-to information (but that doesn't give you information
about the offset).
Richard.
> --
> View this message in context:
> http://old.nabble.com/GIMPLE-and-intent-of-variables-tp32275433p32277626.html
> Sent from the gcc - patches mailing list archive at Nabble.com.
>
>
Re: [PATCH, SMS] Support instructions with REG_INC_NOTE (re-submisson)
Hello,
On 16 August 2011 03:32, Ayal Zaks wrote:
> Ok, so this extends the infrastructure to support insns which set an
> arbitrary number of registers, but currently specifically handles only
> REG_INC situations (which set two registers). I'm not against
> {0,1,infinity}, but wonder if this case really deserves the
> complexity: post/pre-inc/decrementing load insns may need regmoves for
> the register loaded, due to the latency of the load and desire to
> schedule associated uses farther than ii cycles away (as do regular
> loads), but do they also need regmoves for the address register being
> post/pre-inc/decremented? Its latency should not be long, and it's
> often feeding only itself so regmoves are not needed/won't help. If
> not, perhaps a simpler solution is to allow REG_INC insns but disallow
> their address register from being regmove'd, dedicating the single
> regmove info for the value loaded.
>
> Are there actually cases where you need the address register to regmove?
Bootstrap on PowerPC did not reveal such cases so I'll try to
implement a simpler solution as you suggested.
Thanks,
Revital
[ARM] PR 50090: aliases in libgcc.a with default visibility
EABI functions like __aeabi_f2ulz are defined as aliases of standard
libgcc functions like __fixunssfdi. In libgcc.a, the standard function
gets the correct hidden visibility, but the alias retains default
visibility. This means that DSOs linked against libgcc.a may end
up exporting the libgcc.a definition of __aeabi_f2ulz.
The bug is that bpabi-lib.h uses an asm statement to define an alias,
so the standard ways of forcing hidden visibility at the C level have
no effect. Fixed by using attributes instead.
Tested on arm-linux-gnueabi. Also tested by making sure that libgcc.a
defined no default-visibility symbols. OK for trunk?
What about release branches? I suppose this isn't a regression,
but it is a backwards-compatible ABI fix.
Richard
libgcc/
PR target/50090
* config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias
instead of an assembly one.
Index: libgcc/config/arm/bpabi-lib.h
===
--- libgcc/config/arm/bpabi-lib.h 2011-08-15 16:46:13.0 +0100
+++ libgcc/config/arm/bpabi-lib.h 2011-08-15 16:50:39.052030640 +0100
@@ -28,9 +28,8 @@ #define RENAME_LIBRARY_SET ".set"
/* Make __aeabi_AEABI_NAME an alias for __GCC_NAME. */
#define RENAME_LIBRARY(GCC_NAME, AEABI_NAME) \
- __asm__ (".globl\t__aeabi_" #AEABI_NAME "\n" \
- RENAME_LIBRARY_SET "\t__aeabi_" #AEABI_NAME \
-", __" #GCC_NAME "\n");
+ typeof (__##GCC_NAME) __aeabi_##AEABI_NAME \
+__attribute__((alias ("__" #GCC_NAME)));
/* Give some libgcc functions an additional __aeabi name. */
#ifdef L_muldi3
Re: GIMPLE and intent of variables
Jeff Law wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/16/11 15:35, grabekm90 wrote:
>
>> How to resolve a problem with pointers (especially arrays)? For
>> example, we have a GIMPLE function:
>>
>> set_a (int * a) { int * D.2701; D.2701 = a + 40; *D.2701 = 7; }
>>
>> This is equivalent code in C:
>>
>> void set_a(int * a) { a[10] = 107; }
>>
>> GIMPLE tries to avoid operations on the left side of the assign sign.
>> There is a problem because I want to identify local variable (D.2701)
>> with function parameter (a). In this case "a" is output parameter. I
>> could follow a behavior of parameters in my plugin, but I suppose
>> that GIMPLE makes accessible better solution, doesn't it?
> Adding/subtracting from a pointer should result in another pointer to a
> different part of the same object. So anytime I saw
> = +- index
>
> I'd record that was a derived pointer.
>
> jeff
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOSuPvAAoJEBRtltQi2kC7p6AH/3x6EXhLr4os3FjFklvNdJk6
> FsGYnl9l3ZxRzYv5TyS6Pe2hzZaRPzZyF0a6r6/pZ9KqxlBA7XQwIAxjBnW37+DK
> LypIeCz7IeQDqPnB2OV9e271Q+b6EWPhSg/csAAeGqKtmixjwNC2Zjkgjbf5Anmn
> WtSyo12A2b16f24I/bHw36frupcBF7adMBK5CyQVthoMkbVsporvG9Yz4NX/vmF+
> 2UPGw3wap9SIsMEs9bG/OA13Q2WsQS7EJw2n5GH4gdlEwMmd6e8WsuQ0802SkHdX
> aVgwIJ0xQbk2RuVnRb8244u+6AOuVT4yVVvHJ5QGfON/UoLFUKa1SPUXRSRLKaM=
> =HggP
> -END PGP SIGNATURE-
>
>
The question is: how can we get to know, using GIMPLE mechanism, from which
parameter a pointer derives?
--
View this message in context:
http://old.nabble.com/GIMPLE-and-intent-of-variables-tp32275433p32277626.html
Sent from the gcc - patches mailing list archive at Nabble.com.
Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)
On Tue, Aug 16, 2011 at 10:50 PM, Sriraman Tallam wrote:
> Support for getting CPU type and feature information at run-time.
>
> The following patch provides support for finding the platform type at
> run-time, like cpu type and features supported. The multi-versioning
> framework will use the builtins added to dispatch the right function version.
> Please refer to http://gcc.gnu.org/ml/gcc/2011-08/msg00298.html for details
> on function multi-versioning usability.
Please provide an overview why you need the new builtins, why you need
a separate pass to fold them (instead of just expanding them) and why
you are creating
vars behind the back of GCC:
+ /* Set finalized to 1, otherwise it asserts in function "write_symbol" in
+ lto-streamer-out.c. */
+ vnode->finalized = 1;
where I think you miss a varpool_finalize_node call somewhere. Why
isn't this all done at target init time? If you don't mark the
variable as to be preserved
like you do cgraph will optimize it all away if it isn't needed.
Richard.
> * tree-pass.h (pass_tree_fold_builtin_target): New pass.
> * builtins.def (BUILT_IN_TARGET_SUPPORTS_CMOV): New builtin.
> (BUILT_IN_TARGET_SUPPORTS_MMX): New builtin.
> (BUILT_IN_TARGET_SUPPORTS_POPCOUNT): New builtin.
> (BUILT_IN_TARGET_SUPPORTS_SSE): New builtin.
> (BUILT_IN_TARGET_SUPPORTS_SSE2): New builtin.
> (BUILT_IN_TARGET_SUPPORTS_SSE3): New builtin.
> (BUILT_IN_TARGET_SUPPORTS_SSSE3): New builtin.
> (BUILT_IN_TARGET_SUPPORTS_SSE4_1): New builtin.
> (BUILT_IN_TARGET_SUPPORTS_SSE4_2): New builtin.
> (BUILT_IN_TARGET_IS_AMD): New builtin.
> (BUILT_IN_TARGET_IS_INTEL): New builtin.
> (BUILT_IN_TARGET_IS_COREI7_NEHALEM): New builtin.
> (BUILT_IN_TARGET_IS_COREI7_WESTMERE): New builtin.
> (BUILT_IN_TARGET_IS_COREI7_SANDYBRIDGE): New builtin.
> (BUILT_IN_TARGET_IS_AMDFAM10_BARCELONA): New builtin.
> (BUILT_IN_TARGET_IS_AMDFAM10_SHANGHAI): New builtin.
> (BUILT_IN_TARGET_IS_AMDFAM10_ISTANBUL): New builtin.
> * mversn-dispatch.c (do_fold_builtin_target): New function.
> (gate_fold_builtin_target): New function.
> (pass_tree_fold_builtin_target): New pass.
> * timevar.def (TV_FOLD_BUILTIN_TARGET): New var.
> * passes.c (init_optimization_passes): Add new pass to pass list.
> * config/i386/i386.c (build_struct_with_one_bit_fields): New function.
> (make_var_decl): New function.
> (get_field_from_struct): New function.
> (make_constructor_to_get_target_type): New function.
> (fold_builtin_target): New function.
> (ix86_fold_builtin): New function.
> (TARGET_FOLD_BUILTIN): New macro.
>
> * gcc.dg/builtin_target.c: New test.
>
> * config/i386/i386-cpuinfo.c: New file.
> * config/i386/t-cpuinfo: New file.
> * config.host: Add t-cpuinfo to link i386-cpuinfo.o with libgcc
>
> Index: libgcc/config.host
> ===
> --- libgcc/config.host (revision 177767)
> +++ libgcc/config.host (working copy)
> @@ -609,7 +609,7 @@ case ${host} in
> i[34567]86-*-linux* | x86_64-*-linux* | \
> i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | \
> i[34567]86-*-gnu*)
> - tmake_file="${tmake_file} t-tls"
> + tmake_file="${tmake_file} t-tls i386/t-cpuinfo"
> if test "$libgcc_cv_cfi" = "yes"; then
> tmake_file="${tmake_file} t-stack i386/t-stack-i386"
> fi
> Index: libgcc/config/i386/t-cpuinfo
> ===
> --- libgcc/config/i386/t-cpuinfo (revision 0)
> +++ libgcc/config/i386/t-cpuinfo (revision 0)
> @@ -0,0 +1,2 @@
> +# This is an endfile
> +LIB2ADD += $(srcdir)/config/i386/i386-cpuinfo.c
> Index: libgcc/config/i386/i386-cpuinfo.c
> ===
> --- libgcc/config/i386/i386-cpuinfo.c (revision 0)
> +++ libgcc/config/i386/i386-cpuinfo.c (revision 0)
> @@ -0,0 +1,275 @@
> +/* Copyright (C) 2011 Free Software Foundation, Inc.
> + * Contributed by Sriraman Tallam .
> + *
> + * This file 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 file 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.
> + *
> + * Under Section 7 of GPL version 3, you are granted additional
> + * permissions described in the GCC Runtime Library Exception, version
> + * 3.1, as published by the Free Software Foundation.
> + *
> + * You should have received a copy of the GNU General Public License and
Re: RFA: Avoiding unprofitable speculation
On Tue, Aug 16, 2011 at 11:14 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > ifcvt.c is sometimes over-aggressive in speculating instructions from a > not-predicted path. > > Given: > > if (test) goto E; // x not live > x = big(); > goto L; > E: > x = b; > goto M; > > > ifcvt wants to turn it into: > > x = b; > if (test) goto M; > x = big(); > goto L; > > ie, we speculate x = b and remove a branch. > > Similarly: > > if (test) goto over; // x not live > x = a; > goto label; > over: > > becomes > > x = a; > if (! test) goto label; > > > where again we speculate x = a and eliminate a branch. > > > ifcvt has tests to see if the code to speculate is cheap relative to the > cost of the branch we get to remove. Unfortunately, that only takes > into account a static RTX cost. We need to be looking at the branch > prediction too -- often the branch we're going to eliminate isn't going > to be executed at all! > > Specifically, we should take the cost of the branch we want to eliminate > and scale that by how often we expect to reach that branch at runtime. > That allows us to compare the runtime cost of the speculative code vs > the runtime benefit of eliminating the branch. > > Looking at branch & insn counts before/after that change is quite > interesting. I've got gcc-4.6 built with/without the attached change. > I then use that gcc-4.6 to compile a bunch of .i files under the > watchful eye of valgrind. > > Using this data we can see the actual costs... For every dynamic branch > eliminated, we had to execute an additional 300 instructions! > Again, remember these are dynamic counts, so we may have only speculated > one static instruction to eliminate one branch, but we hit that > speculated instruction far more often dynamically than the branch we > ultimately eliminated. > > > > instructions w/o patch:1267286482371 > instructions w patch:1264140292731 > > branches w/o patch: 231180206508 > branches w patch: 231190636813 > > Bootstrapped and regression tested on x86_64-unknown-linux-gnu. OK for > trunk? We don't have a way to distinguish branch-taken vs. branch-not-take costs, right? I would expect that for non-pipelined archs the branch does have the same cost all the time, so ifcvt would be correct, no? Do you happen to know how valgrind counts branches here? The patch itself looks sensible, though I am surprised ifcvt doesn't run in cfglayout mode (so you have to use reg notes to find probabilities ...) Thanks, Richard. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOSt2sAAoJEBRtltQi2kC7UZUIAJ7fthVsCXxU3JOtIVbUSX5t > grCG73peQnBB7FhB58/jW1GJWc011mExLIJf74FDrNU+gMp3gn01L0zdjcaytmY6 > sNjso7dLjW42a/wByzNlHNUy2KRMUqhobEhHYWgC0tMJFz8/ekCulI7h98pVISmT > np9G/1zRXn3uD7F3pKw7lLDS994nSUmjObPFIyFxTfVGhBTWZYY8JjKP7NsOCNli > Dr2BXFF4rahoSDUlcLHwPPBJPABLvxwvMo0dsmNkB3HEiajj7qVPGUYaGrTJ5M1g > Bvww+ozzJRT96qQ/smjVZutD2Cu/U74Ix6EX8Yj54Zp2HeX8tCJ3kXWPFI6cBpk= > =3BEA > -END PGP SIGNATURE- >
