Re: [PATCH] Fix PR53703
On Sun, 17 Jun 2012, William J. Schmidt wrote:
> The test case exposes a bug that occurs only when a diamond control flow
> pattern has the arguments of the joining phi in a different order from
> the successor arcs of the entry block. My logic for setting
> bb_for_def[12] was just brain-dead. This cleans that up and also
> prevents wasting time examining phis of virtual ops, which I noticed
> happening while debugging this.
>
> Bootstrapped and regtested on powerpc64-unknown-linux-gnu with no new
> failures. Ok for trunk?
Ok.
Thanks,
Richard.
> Thanks,
> Bill
>
>
> gcc:
>
> 2012-06-17 Bill Schmidt
>
> PR tree-optimization/53703
> * tree-ssa-phiopt.c (hoist_adjacent_loads): Skip virtual phis;
> correctly set bb_for_def[12].
>
> gcc/testsuite:
>
> 2012-06-17 Bill Schmidt
>
> PR tree-optimization/53703
> * gcc.dg/torture/pr53703.c: New test.
>
>
> Index: gcc/testsuite/gcc.dg/torture/pr53703.c
> ===
> --- gcc/testsuite/gcc.dg/torture/pr53703.c(revision 0)
> +++ gcc/testsuite/gcc.dg/torture/pr53703.c(revision 0)
> @@ -0,0 +1,149 @@
> +/* Reduced test case from PR53703. Used to ICE. */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-w" } */
> +
> +typedef long unsigned int size_t;
> +typedef unsigned short int sa_family_t;
> +struct sockaddr {};
> +typedef unsigned char __u8;
> +typedef unsigned short __u16;
> +typedef unsigned int __u32;
> +struct nlmsghdr {
> + __u32 nlmsg_len;
> + __u16 nlmsg_type;
> +};
> +struct ifaddrmsg {
> + __u8 ifa_family;
> +};
> +enum {
> + IFA_ADDRESS,
> + IFA_LOCAL,
> +};
> +enum {
> + RTM_NEWLINK = 16,
> + RTM_NEWADDR = 20,
> +};
> +struct rtattr {
> + unsigned short rta_len;
> + unsigned short rta_type;
> +};
> +struct ifaddrs {
> + struct ifaddrs *ifa_next;
> + unsigned short ifa_flags;
> +};
> +typedef unsigned short int uint16_t;
> +typedef unsigned int uint32_t;
> +struct nlmsg_list {
> + struct nlmsg_list *nlm_next;
> + int size;
> +};
> +struct rtmaddr_ifamap {
> + void *address;
> + void *local;
> + int address_len;
> + int local_len;
> +};
> +int usagi_getifaddrs (struct ifaddrs **ifap)
> +{
> + struct nlmsg_list *nlmsg_list, *nlmsg_end, *nlm;
> + size_t dlen, xlen, nlen;
> + int build;
> + for (build = 0; build <= 1; build++)
> +{
> + struct ifaddrs *ifl = ((void *)0), *ifa = ((void *)0);
> + struct nlmsghdr *nlh, *nlh0;
> + uint16_t *ifflist = ((void *)0);
> + struct rtmaddr_ifamap ifamap;
> + for (nlm = nlmsg_list; nlm; nlm = nlm->nlm_next)
> + {
> + int nlmlen = nlm->size;
> + for (nlh = nlh0;
> +((nlmlen) >= (int)sizeof(struct nlmsghdr)
> + && (nlh)->nlmsg_len >= sizeof(struct nlmsghdr)
> + && (nlh)->nlmsg_len <= (nlmlen));
> +nlh = ((nlmlen) -= ( (((nlh)->nlmsg_len)+4U -1) & ~(4U -1) ),
> + (struct nlmsghdr*)(((char*)(nlh))
> + + ( (((nlh)->nlmsg_len)+4U -1)
> + & ~(4U -1)
> + {
> + struct ifinfomsg *ifim = ((void *)0);
> + struct ifaddrmsg *ifam = ((void *)0);
> + struct rtattr *rta;
> + sa_family_t nlm_family = 0;
> + uint32_t nlm_scope = 0, nlm_index = 0;
> + memset (&ifamap, 0, sizeof (ifamap));
> + switch (nlh->nlmsg_type)
> + {
> + case RTM_NEWLINK:
> + ifim = (struct ifinfomsg *)
> + ((void*)(((char*)nlh)
> + + ((0)+( int)
> + ( ((sizeof(struct nlmsghdr))+4U -1)
> +& ~(4U -1) )))+4U -1)
> + & ~(4U -1) ;
> + case RTM_NEWADDR:
> + ifam = (struct ifaddrmsg *)
> + ((void*)(((char*)nlh)
> + + ((0)+( int)
> + ( ((sizeof(struct nlmsghdr))+4U -1)
> +& ~(4U -1) )))+4U -1)
> + & ~(4U -1) ;
> + nlm_family = ifam->ifa_family;
> + if (build)
> + ifa->ifa_flags = ifflist[nlm_index];
> + break;
> + default:
> + continue;
> + }
> + if (!build)
> + {
> + void *rtadata = ((void*)(((char*)(rta))
> ++ (( ((sizeof(struct rtattr))+4 -1)
> + & ~(4 -1) ) + (0;
> + size_t rtapayload = ((int)((rta)->rta_len)
> +- (( ((sizeof(struct rtattr))+4 -1)
> + & ~(4 -1) ) + (0)));
> + switch (nlh->nlmsg_type)
> + {
> + case RTM_NEWLINK:
> +
PR 53698: missing address conversion in expand_expr_addr_expr_1
The result of expand_expr_addr_expr_1 is eventually converted to tmode,
and any variable offset is likewise applied in tmode, so tmode also seems
like the natural mode for applying constant offsets. This patch makes sure
that the operand is converted to tmode first, just like we do for
variable offsets. It fixes a case where the new plus_constant
assert triggers.
Tested on x86_64-linux-gnu. Also tested by HJ on x32 (thanks).
OK to install?
Richard
gcc/
PR middle-end/53698
* expr.c (expand_expr_addr_expr_1): Convert to tmode before
performing an addition.
gcc/testsuite/
PR middle-end/53698
* gcc.target/i386/pr53698.c: New test.
Index: gcc/expr.c
===
--- gcc/expr.c 2012-06-06 10:09:21.0 +0100
+++ gcc/expr.c 2012-06-18 09:35:35.361926943 +0100
@@ -7631,6 +7631,7 @@ expand_expr_addr_expr_1 (tree exp, rtx t
of such an object. */
gcc_assert ((bitpos % BITS_PER_UNIT) == 0);
+ result = convert_memory_address_addr_space (tmode, result, as);
result = plus_constant (tmode, result, bitpos / BITS_PER_UNIT);
if (modifier < EXPAND_SUM)
result = force_operand (result, target);
Index: gcc/testsuite/gcc.target/i386/pr53698.c
===
--- /dev/null 2012-05-16 15:38:36.131804707 +0100
+++ gcc/testsuite/gcc.target/i386/pr53698.c 2012-06-18 09:36:01.033855874
+0100
@@ -0,0 +1,16 @@
+/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-options "-O -mx32 -maddress-mode=long -fno-tree-dominator-opts" } */
+
+extern char foo[];
+
+void
+test2 (void)
+{
+ int s;
+ for (s = 0;; ++s)
+{
+ if (foo[s] != s)
+ __builtin_abort ();
+ foo[s] = s;
+}
+}
Re: [Patch 4.6] In system.h, wrap include of C++ header in 'extern C++'
On Sun, Jun 17, 2012 at 2:56 PM, Gabriel Dos Reis wrote: > On Sun, Jun 17, 2012 at 6:55 AM, Richard Guenther > wrote: >> On Fri, Jun 15, 2012 at 5:18 PM, Gabriel Dos Reis >> wrote: >>> On Fri, Jun 15, 2012 at 10:13 AM, Duncan Sands wrote: Hi Gabriel, >>> Richard just reminded me that we have two fancy_aborts. >>> Could you tell which one your code is indirectly using? >> >> >> >> the one installed as plugin/include/system.h, which seems to be >> gcc/include/system.h. > > > OK. I think that declaration has to have the C language spec. > Would you prepare a patch for that? you mean: wrap the fancy_abort declaration in system.h in 'extern C'? >>> >>> Yes. Thanks. >> >> I don't think that's correct - if GCC is built with a C++ compiler >> fancy_abort has >> C++ linkage. > > But tthen, that would prevent a C plugins from working, as Duncan > initially reported. Well, sure. No design part of the (basically not existent) plugin API caters for mixing C++/C C/C++ plugin vs. GCC. Trying to paper over a single issue is not a way to make that magically work. Richard.
Re: PR 53698: missing address conversion in expand_expr_addr_expr_1
On Mon, Jun 18, 2012 at 11:18 AM, Richard Sandiford
wrote:
> The result of expand_expr_addr_expr_1 is eventually converted to tmode,
> and any variable offset is likewise applied in tmode, so tmode also seems
> like the natural mode for applying constant offsets. This patch makes sure
> that the operand is converted to tmode first, just like we do for
> variable offsets. It fixes a case where the new plus_constant
> assert triggers.
>
> Tested on x86_64-linux-gnu. Also tested by HJ on x32 (thanks).
> OK to install?
Ok.
Thanks,
Richard.
> Richard
>
>
> gcc/
> PR middle-end/53698
> * expr.c (expand_expr_addr_expr_1): Convert to tmode before
> performing an addition.
>
> gcc/testsuite/
> PR middle-end/53698
> * gcc.target/i386/pr53698.c: New test.
>
> Index: gcc/expr.c
> ===
> --- gcc/expr.c 2012-06-06 10:09:21.0 +0100
> +++ gcc/expr.c 2012-06-18 09:35:35.361926943 +0100
> @@ -7631,6 +7631,7 @@ expand_expr_addr_expr_1 (tree exp, rtx t
> of such an object. */
> gcc_assert ((bitpos % BITS_PER_UNIT) == 0);
>
> + result = convert_memory_address_addr_space (tmode, result, as);
> result = plus_constant (tmode, result, bitpos / BITS_PER_UNIT);
> if (modifier < EXPAND_SUM)
> result = force_operand (result, target);
> Index: gcc/testsuite/gcc.target/i386/pr53698.c
> ===
> --- /dev/null 2012-05-16 15:38:36.131804707 +0100
> +++ gcc/testsuite/gcc.target/i386/pr53698.c 2012-06-18 09:36:01.033855874
> +0100
> @@ -0,0 +1,16 @@
> +/* { dg-do compile { target { ! { ia32 } } } } */
> +/* { dg-options "-O -mx32 -maddress-mode=long -fno-tree-dominator-opts" } */
> +
> +extern char foo[];
> +
> +void
> +test2 (void)
> +{
> + int s;
> + for (s = 0;; ++s)
> + {
> + if (foo[s] != s)
> + __builtin_abort ();
> + foo[s] = s;
> + }
> +}
Re: [Patch 4.6] In system.h, wrap include of C++ header in 'extern C++'
On Mon, Jun 18, 2012 at 4:18 AM, Richard Guenther wrote: > On Sun, Jun 17, 2012 at 2:56 PM, Gabriel Dos Reis > wrote: >> On Sun, Jun 17, 2012 at 6:55 AM, Richard Guenther >> wrote: >>> On Fri, Jun 15, 2012 at 5:18 PM, Gabriel Dos Reis >>> wrote: On Fri, Jun 15, 2012 at 10:13 AM, Duncan Sands wrote: > Hi Gabriel, > Richard just reminded me that we have two fancy_aborts. Could you tell which one your code is indirectly using? >>> >>> >>> >>> the one installed as plugin/include/system.h, which seems to be >>> gcc/include/system.h. >> >> >> OK. I think that declaration has to have the C language spec. >> Would you prepare a patch for that? > > > you mean: wrap the fancy_abort declaration in system.h in 'extern C'? Yes. Thanks. >>> >>> I don't think that's correct - if GCC is built with a C++ compiler >>> fancy_abort has >>> C++ linkage. >> >> But tthen, that would prevent a C plugins from working, as Duncan >> initially reported. > > Well, sure. No design part of the (basically not existent) plugin API caters > for mixing C++/C C/C++ plugin vs. GCC. Trying to paper over a single > issue is not a way to make that magically work. That is a pretty loaded assertion with little evidence. -- Gaby
[PING ARM Patches] PR53447: optimizations of 64bit ALU operation with constant
Hi Could ARM maintainers review following patches? http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00497.html 64bit add/sub constants. http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01834.html 64bit and with constants. http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01974.html 64bit xor with constants. http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00287.html 64bit ior with constants. thanks Carrot
[patch] Remove NO_IMPLICIT_EXTERN_C target macro
Hello,
For targets that do not define NO_IMPLICIT_EXTERN_C, GCC assumes that
included system headers are implicitly wrapped in 'extern "C" {...}'.
I could not find where this target macro was introduced, but it is
very old (it is already mentioned in FSFChangeLog.10 for a change in
1995). AFAICT, today all supported targets have C++-compatible headers
(according to one comment, even hpux8 had C++-compatible system
headers :-), so NO_IMPLICIT_EXTERN_C shouldn't be necessary anymore.
The only target that explicitly undefines NO_IMPLICIT_EXTERN_C is
sparc64-openbsd, and I find it hard to believe that the system headers
on openbsd are not also already C++-compatible. Marc, could you have a
look at this, please?
The attached patch removes NO_IMPLICIT_EXTERN_C, and replaces its sole
user with IMPLICIT_EXTERN_C to avoid the double negations (#ifndef
NO_IMPLICIT_EXTERN_C, etc.).
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
fixup_NO_IMPLICIT_EXTERN_C.diff
Description: Binary data
Re: [PATCH] GCC Ada/GNAT configuration for GNU/Hurd
> Here is a patch that adds a basic GCC Ada/GNAT configuration for x86
> GNU/Hurd. This has originally been created by Svante Signell for use
> with Debian's GCC 4.6 package, and now I have ported it to trunk, and
> also applied some further changes.
>
> 2012-06-16 Svante Signell
> Thomas Schwinge
>
> gcc/ada/
> * gcc-interface/Makefile.in: Add configuration for x86 GNU/Hurd.
> * gsocket.h [__GNU__] (Has_Sockaddr_Len): #define to 1.
> * s-oscons-tmplt.c: Add checks for __GNU__ next to several __linux__
> and linux conditionals.
> * terminals.c [__GNU__]: Don't #include . #define USE_GETPT.
> * s-osinte-gnu.ads: New file.
> * s-taprop-gnu.adb: Likewise.
Well, the main question is: who is volunteering to maintain this code
and fix it when things break?
Also, is s-taprop-gnu.adb really necessary? Assuming GNU Hurd provides
a posix pthread interface, then you should be using s-taprop-posix.adb,
NOT s-taprop-gnu.adb
Another comment:
> --- a/gcc/ada/s-oscons-tmplt.c
> +++ b/gcc/ada/s-oscons-tmplt.c
> @@ -80,7 +80,7 @@ pragma Style_Checks ("M32766");
>
> /* Feature macro definitions */
>
> -#if defined (__linux__) && !defined (_XOPEN_SOURCE)
> +#if (defined (__linux__) || defined (__GNU__)) && !defined
> (_XOPEN_SOURCE)
> /** For Linux _XOPEN_SOURCE must be defined, otherwise IOV_MAX is not
> defined
> **/
> #define _XOPEN_SOURCE 500
You need to update the comment here, since the section so far only
applied to GNU/Linux and not GNU/Hurd.
So assuming the above comment update, my main objection is to introduce
a s-taprop-gnu.adb which will cause maintenance troubles.
If you use s-taprop-posix.adb instead and you or someone else volunteers
for maintaining these files, then this could work.
Arno
Re: [PATCH] GCC Ada/GNAT configuration for GNU/Hurd
Hi!
On Mon, 18 Jun 2012 12:23:47 +0200, Arnaud Charlet wrote:
> > Here is a patch that adds a basic GCC Ada/GNAT configuration for x86
> > GNU/Hurd. This has originally been created by Svante Signell for use
> > with Debian's GCC 4.6 package, and now I have ported it to trunk, and
> > also applied some further changes.
> >
> > 2012-06-16 Svante Signell
> > Thomas Schwinge
> >
> > gcc/ada/
> > * gcc-interface/Makefile.in: Add configuration for x86 GNU/Hurd.
> > * gsocket.h [__GNU__] (Has_Sockaddr_Len): #define to 1.
> > * s-oscons-tmplt.c: Add checks for __GNU__ next to several __linux__
> > and linux conditionals.
> > * terminals.c [__GNU__]: Don't #include . #define USE_GETPT.
> > * s-osinte-gnu.ads: New file.
> > * s-taprop-gnu.adb: Likewise.
>
> Well, the main question is: who is volunteering to maintain this code
> and fix it when things break?
I'm available; I also maintain other GNU/Hurd toolchain bits.
> Also, is s-taprop-gnu.adb really necessary? Assuming GNU Hurd provides
> a posix pthread interface, then you should be using s-taprop-posix.adb,
> NOT s-taprop-gnu.adb
Thanks for the suggestion, I'll look into that.
> Another comment:
>
> > --- a/gcc/ada/s-oscons-tmplt.c
> > +++ b/gcc/ada/s-oscons-tmplt.c
> > @@ -80,7 +80,7 @@ pragma Style_Checks ("M32766");
> >
> > /* Feature macro definitions */
> >
> > -#if defined (__linux__) && !defined (_XOPEN_SOURCE)
> > +#if (defined (__linux__) || defined (__GNU__)) && !defined
> > (_XOPEN_SOURCE)
> > /** For Linux _XOPEN_SOURCE must be defined, otherwise IOV_MAX is not
> > defined
> > **/
> > #define _XOPEN_SOURCE 500
>
> You need to update the comment here, since the section so far only
> applied to GNU/Linux and not GNU/Hurd.
In fact, should that perhaps (unverified) simply say »For glibc,
_XOPEN_SOURCE must be defined [...]« -- or is this code meant to be
usable on GNU/Linux with a C library different from glibc?
> So assuming the above comment update, my main objection is to introduce
> a s-taprop-gnu.adb which will cause maintenance troubles.
>
> If you use s-taprop-posix.adb instead and you or someone else volunteers
> for maintaining these files, then this could work.
Ack, thanks.
Grüße,
Thomas
pgp2Vwx2JeoZB.pgp
Description: PGP signature
Re: [PATCH] GCC Ada/GNAT configuration for GNU/Hurd
> > Another comment:
> >
> > > --- a/gcc/ada/s-oscons-tmplt.c
> > > +++ b/gcc/ada/s-oscons-tmplt.c
> > > @@ -80,7 +80,7 @@ pragma Style_Checks ("M32766");
> > >
> > > /* Feature macro definitions */
> > >
> > > -#if defined (__linux__) && !defined (_XOPEN_SOURCE)
> > > +#if (defined (__linux__) || defined (__GNU__)) && !defined
> > > (_XOPEN_SOURCE)
> > > /** For Linux _XOPEN_SOURCE must be defined, otherwise IOV_MAX is not
> > > defined
> > > **/
> > > #define _XOPEN_SOURCE 500
> >
> > You need to update the comment here, since the section so far only
> > applied to GNU/Linux and not GNU/Hurd.
>
> In fact, should that perhaps (unverified) simply say »For glibc,
> _XOPEN_SOURCE must be defined [...]« -- or is this code meant to be
> usable on GNU/Linux with a C library different from glibc?
Posibly yes. Thomas (Quinot), any comment on the above?
Arno
[PATCH resend] Add implicit C linkage for win32-specific entry points
gcc/ChangeLog:
* config/i386/mingw-w64.h: Specify entry points with implicit C linkage
gcc/cp/ChangeLog:
* decl.c: Allow custom target implicit C linkage
gcc/testsuite/ChangeLog:
* g++.dg/ext/main.C: Added implicit C linkage tests
---
gcc/config/i386/mingw-w64.h |6 ++
gcc/cp/decl.c |8 ++--
gcc/testsuite/g++.dg/ext/main.C | 24
3 files changed, 36 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/ext/main.C
diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h
index a45ce28..1ce940a 100644
--- a/gcc/config/i386/mingw-w64.h
+++ b/gcc/config/i386/mingw-w64.h
@@ -85,3 +85,9 @@ along with GCC; see the file COPYING3. If not see
%{static:-Bstatic} %{!static:-Bdynamic} \
%{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \
%(shared_libgcc_undefs)"
+
+#define CPP_IMPLICIT_TARGET_CLANG(ident) \
+( !strcmp(ident, "wmain") \
+|| !strcmp(ident, "DllMain") \
+|| !strcmp(ident, "WinMain") \
+|| !strcmp(ident, "wWinMain"))
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index da23bda..ddbe9b0 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7279,12 +7279,16 @@ grokfndecl (tree ctype,
else if (!ctype)
DECL_CONTEXT (decl) = FROB_CONTEXT (current_decl_namespace ());
- /* `main' and builtins have implicit 'C' linkage. */
+ /* `main', builtins and some target specific functions have implicit 'C' linkage. */
if ((MAIN_NAME_P (declarator)
|| (IDENTIFIER_LENGTH (declarator) > 10
&& IDENTIFIER_POINTER (declarator)[0] == '_'
&& IDENTIFIER_POINTER (declarator)[1] == '_'
- && strncmp (IDENTIFIER_POINTER (declarator)+2, "builtin_", 8) == 0))
+ && strncmp (IDENTIFIER_POINTER (declarator)+2, "builtin_", 8) == 0)
+#ifdef CPP_IMPLICIT_TARGET_CLANG
+ || CPP_IMPLICIT_TARGET_CLANG(IDENTIFIER_POINTER (declarator))
+#endif
+ )
&& current_lang_name == lang_name_cplusplus
&& ctype == NULL_TREE
&& DECL_FILE_SCOPE_P (decl))
diff --git a/gcc/testsuite/g++.dg/ext/main.C b/gcc/testsuite/g++.dg/ext/main.C
new file mode 100644
index 000..4c5f1ea
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/main.C
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+
+/* Check if entry points get implicit C linkage. If they don't, compiler will
+ * error on incompatible declarations */
+
+int main();
+extern "C" int main();
+
+#ifdef __MINGW32__
+
+int wmain();
+extern "C" int wmain();
+
+int DllMain();
+extern "C" int DllMain();
+
+int WinMain();
+extern "C" int WinMain();
+
+int wWinMain();
+extern "C" int wWinMain();
+
+#endif
+
[patch] Remove VMS_TARGET
Hello,
There are exactly 2 references to the target macro VMS_TARGET:
cp/decl.c:#if VMS_TARGET
config/vax/vax.h:#define VMS_TARGET 0
I'm not sure what the macro is for. GCC seems to support a couple of
VMS targets, but none of them define VMS_TARGET.
This patch remove the macro. I can't test this because I have no
access to a VMS machine, but it is pretty obvious that the macro is
dead code.
OK for trunk?
Ciao!
Steven
gcc/
* config/vax/vax.h (VMS_TARGET): Remove.
cp/
* decl.c (finish_function): Remove code conditional on VMS_TARGET.
Index: config/vax/vax.h
===
--- config/vax/vax.h(revision 188724)
+++ config/vax/vax.h(working copy)
@@ -35,8 +35,6 @@ along with GCC; see the file COPYING3. If not see
} \
while (0)
-#define VMS_TARGET 0
-
/* Use -J option for long branch support with Unix assembler. */
#define ASM_SPEC "-J"
Index: cp/decl.c
===
--- cp/decl.c (revision 188724)
+++ cp/decl.c (working copy)
@@ -13461,16 +13461,9 @@ finish_function (int flags)
there's no need to add any extra bits. */
if (!DECL_CLONED_FUNCTION_P (fndecl))
{
+ /* Make it so that `main' always returns 0 by default. */
if (DECL_MAIN_P (current_function_decl))
- {
- /* Make it so that `main' always returns 0 by default (or
-1 for VMS). */
-#if VMS_TARGET
- finish_return_stmt (integer_one_node);
-#else
- finish_return_stmt (integer_zero_node);
-#endif
- }
+ finish_return_stmt (integer_zero_node);
if (use_eh_spec_block (current_function_decl))
finish_eh_spec_block (TYPE_RAISES_EXCEPTIONS
Re: [PATCH resend] Add implicit C linkage for win32-specific entry points
On Mon, Jun 18, 2012 at 12:54 PM, Jacek Caban wrote: > > gcc/ChangeLog: > * config/i386/mingw-w64.h: Specify entry points with implicit C linkage > > gcc/cp/ChangeLog: > * decl.c: Allow custom target implicit C linkage > > gcc/testsuite/ChangeLog: > * g++.dg/ext/main.C: Added implicit C linkage tests Can you make this a C-family target hook instead of a macro, please? See c-family/c-target.* and users of targetcm. Ciao! Steven
Re: [PATCH][4/n] VRP and anti-range handling
On Fri, 15 Jun 2012, Richard Guenther wrote:
>
> This tries to completely implement the intersect primitive for
> VRP (what extract_range_from_assert does at its end when merging
> new and old knowledge).
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
>
> I plan to re-organize vrp_meet in a similar fashion as a followup.
The following is what I ended up applying, less conservative in the
[ () ] and ( [] ) cases.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Richard.
2012-06-18 Richard Guenther
* tree-vrp.c (extract_range_from_assert): Split out range
intersecting code.
(intersect_ranges): New function.
(vrp_intersect_ranges): Likewise.
Index: trunk/gcc/tree-vrp.c
===
*** trunk.orig/gcc/tree-vrp.c 2012-06-18 11:23:34.0 +0200
--- trunk/gcc/tree-vrp.c2012-06-18 11:37:39.117212903 +0200
*** live_on_edge (edge e, tree name)
*** 95,100
--- 95,101
static int compare_values (tree val1, tree val2);
static int compare_values_warnv (tree val1, tree val2, bool *);
static void vrp_meet (value_range_t *, value_range_t *);
+ static void vrp_intersect_ranges (value_range_t *, value_range_t *);
static tree vrp_evaluate_conditional_warnv_with_ops (enum tree_code,
tree, tree, bool, bool *,
bool *);
*** static void
*** 1515,1521
extract_range_from_assert (value_range_t *vr_p, tree expr)
{
tree var, cond, limit, min, max, type;
! value_range_t *var_vr, *limit_vr;
enum tree_code cond_code;
var = ASSERT_EXPR_VAR (expr);
--- 1516,1522
extract_range_from_assert (value_range_t *vr_p, tree expr)
{
tree var, cond, limit, min, max, type;
! value_range_t *limit_vr;
enum tree_code cond_code;
var = ASSERT_EXPR_VAR (expr);
*** extract_range_from_assert (value_range_t
*** 1777,2014
else
gcc_unreachable ();
! /* If VAR already had a known range, it may happen that the new
! range we have computed and VAR's range are not compatible. For
! instance,
!
! if (p_5 == NULL)
! p_6 = ASSERT_EXPR ;
! x_7 = p_6->fld;
! p_8 = ASSERT_EXPR ;
!
! While the above comes from a faulty program, it will cause an ICE
! later because p_8 and p_6 will have incompatible ranges and at
! the same time will be considered equivalent. A similar situation
! would arise from
!
! if (i_5 > 10)
! i_6 = ASSERT_EXPR 10>;
! if (i_5 < 5)
! i_7 = ASSERT_EXPR ;
!
! Again i_6 and i_7 will have incompatible ranges. It would be
! pointless to try and do anything with i_7's range because
! anything dominated by 'if (i_5 < 5)' will be optimized away.
! Note, due to the wa in which simulation proceeds, the statement
! i_7 = ASSERT_EXPR <...> we would never be visited because the
! conditional 'if (i_5 < 5)' always evaluates to false. However,
! this extra check does not hurt and may protect against future
! changes to VRP that may get into a situation similar to the
! NULL pointer dereference example.
!
! Note that these compatibility tests are only needed when dealing
! with ranges or a mix of range and anti-range. If VAR_VR and VR_P
! are both anti-ranges, they will always be compatible, because two
! anti-ranges will always have a non-empty intersection. */
!
! var_vr = get_value_range (var);
!
! /* We may need to make adjustments when VR_P and VAR_VR are numeric
! ranges or anti-ranges. */
! if (vr_p->type == VR_VARYING
! || vr_p->type == VR_UNDEFINED
! || var_vr->type == VR_VARYING
! || var_vr->type == VR_UNDEFINED
! || symbolic_range_p (vr_p)
! || symbolic_range_p (var_vr))
! return;
!
! if (var_vr->type == VR_RANGE && vr_p->type == VR_RANGE)
! {
! /* If the two ranges have a non-empty intersection, we can
!refine the resulting range. Since the assert expression
!creates an equivalency and at the same time it asserts a
!predicate, we can take the intersection of the two ranges to
!get better precision. */
! if (value_ranges_intersect_p (var_vr, vr_p))
! {
! /* Use the larger of the two minimums. */
! if (compare_values (vr_p->min, var_vr->min) == -1)
! min = var_vr->min;
! else
! min = vr_p->min;
!
! /* Use the smaller of the two maximums. */
! if (compare_values (vr_p->max, var_vr->max) == 1)
! max = var_vr->max;
! else
! max = vr_p->max;
!
! set_value_range (vr_p, vr_p->type, min, max, vr_p->equiv);
! }
! else
! {
! /* The two ranges do not intersect, set the new range to
!VARYING, because we wi
Re: [patch] Remove NO_IMPLICIT_EXTERN_C target macro
On Mon, 18 Jun 2012, Steven Bosscher wrote:
> For targets that do not define NO_IMPLICIT_EXTERN_C, GCC assumes that
> included system headers are implicitly wrapped in 'extern "C" {...}'.
> I could not find where this target macro was introduced, but it is
> very old (it is already mentioned in FSFChangeLog.10 for a change in
> 1995). AFAICT, today all supported targets have C++-compatible headers
May have been introduced by:
Fri Nov 5 05:48:04 1993 Richard Stallman (r...@mole.gnu.ai.mit.edu)
* cccp.c (main): Handle NO_IMPLICIT_EXTERN_C.
> (according to one comment, even hpux8 had C++-compatible system
> headers :-), so NO_IMPLICIT_EXTERN_C shouldn't be necessary anymore.
It was previously said that AIX headers needed it
. That of course was AIX
headers as of 2005; I don't know whether seven years later any version of
AIX supported by GCC trunk still needs this.
> The only target that explicitly undefines NO_IMPLICIT_EXTERN_C is
> sparc64-openbsd, and I find it hard to believe that the system headers
> on openbsd are not also already C++-compatible. Marc, could you have a
> look at this, please?
What targets (such as AIX?) did not explicitly undefine it, but did not
get a definition from any header they used either? It's quite likely some
such targets *should* have had NO_IMPLICIT_EXTERN_C defined, but not
necessarily all of them.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [patch] Remove VMS_TARGET
On Mon, 18 Jun 2012, Steven Bosscher wrote: > gcc/ > * config/vax/vax.h (VMS_TARGET): Remove. > > cp/ > * decl.c (finish_function): Remove code conditional on VMS_TARGET. OK. Both C and C++ specify an implicit return of 0 from main; it's for the C runtime to convert return values from main into whatever form the underlying platform expects, rather than for the compiler to generate something different from what "return 0;" would do. -- Joseph S. Myers jos...@codesourcery.com
Re: [patch] Remove VMS_TARGET
On Jun 18, 2012, at 1:01 PM, Steven Bosscher wrote: > Hello, > > There are exactly 2 references to the target macro VMS_TARGET: > > cp/decl.c:#if VMS_TARGET > config/vax/vax.h:#define VMS_TARGET 0 > > I'm not sure what the macro is for. GCC seems to support a couple of > VMS targets, but none of them define VMS_TARGET. > > This patch remove the macro. I can't test this because I have no > access to a VMS machine, but it is pretty obvious that the macro is > dead code. The return code conversion is performed by vms-ucrt0.c and indeed this code is not used. Tristan.
[Patch] Adjustments for Windows x64 SEH
Hi,
at AdaCore, we are now using native SEH exceptions for Windows x64 based on
Richard's patch
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01966.html
I plan to submit a rebased version of this work soon, but we have found a few
issues in the port:
* Registers cannot be pushed once the frame pointer is set. Otherwise the
unwinder is not able to read the old values.
* There was no protection against very large frame size. We have a few tests
declaring huge local array (> 2 GB) for the purpose of testing stack checking.
Without rework, this created either ICE or gas errors, because unwind info
cannot handle such large values or because an extra register is needed to save
or spill a register. I fixed this issue by allocating a small area just to
save the registers and then allocating the remaining. There is no unwind info
emitted for the second (and large) area, as if it were allocated by alloca.
* In order to implement setjmp/longjmp via RtlUnwindEx, we need to pass to
setjmp the value of the establish frame address for the current function. I
added for this purpose a new builtin (__builtin_establisher_frame). This was
manually tested by building and using gdb which uses setjmp/longjmp internally
for its exception mechanism.
Bootstrapped and regtested on x86_64 GNU/Linux.
Comments are welcome.
Tristan.
2012-06-18 Tristan Gingold
* doc/extend.texi (X86 Built-in Functions): Document
__builtin_establisher_frame.
* config/i386/winnt.c (i386_pe_seh_end_prologue): Move code to ...
(seh_cfa_adjust_cfa): ... that function.
(seh_emit_stackalloc): Do not emit out of range values.
* config/i386/i386.md: Delete unused UNSPEC_REG_SAVE,
UNSPEC_DEF_CFA constants.
Add UNSPEC_ESTABLISHER_FRAME.
(establisher_frame): Add insn.
* config/i386/i386.h (SEH_MAX_FRAME_SIZE): Define.
* config/i386/i386.c (ix86_frame_pointer_required): Required
for very large frames on SEH target.
(ix86_compute_frame_layout): Save area is before frame pointer
on SEH target. Handle very large frames.
(ix86_expand_prologue): Likewise.
(enum ix86_builtins): Add IX86_BUILTIN_ESTABLISHER_FRAME.
(ix86_init_builtins): Add __builtin_establisher_frame.
(ix86_expand_builtin): Handle IX86_BUILTIN_ESTABLISHER_FRAME.
(ix86_output_establisher_frame): New function.
* config/i386/i386-protos.h (ix86_output_establisher_frame): Declare.
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index f300a56..28aa928 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -79,6 +79,7 @@ extern const char *output_fix_trunc (rtx, rtx*, bool);
extern const char *output_fp_compare (rtx, rtx*, bool, bool);
extern const char *output_adjust_stack_and_probe (rtx);
extern const char *output_probe_stack_range (rtx, rtx);
+extern const char *ix86_output_establisher_frame (rtx);
extern void ix86_expand_clear (rtx);
extern void ix86_expand_move (enum machine_mode, rtx[]);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index e2f5740..126c0cd 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
return true;
+ /* Win64 SEH, very large frames need a frame-pointer as maximum stack
+ allocation is 4GB (add a safety guard for saved registers). */
+ if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE)
+return true;
+
/* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER
turns off the frame pointer by default. Turn it back on now if
we've not got a leaf function. */
@@ -9051,6 +9056,11 @@ ix86_compute_frame_layout (struct ix86_frame *frame)
offset += frame->nregs * UNITS_PER_WORD;
frame->reg_save_offset = offset;
+ /* On SEH target, registers are pushed just before the frame pointer
+ location. */
+ if (TARGET_SEH)
+frame->hard_frame_pointer_offset = offset;
+
/* Align and set SSE register save area. */
if (frame->nsseregs)
{
@@ -9144,7 +9154,7 @@ ix86_compute_frame_layout (struct ix86_frame *frame)
/* If we can leave the frame pointer where it is, do so. */
diff = frame->stack_pointer_offset - frame->hard_frame_pointer_offset;
- if (diff > 240 || (diff & 15) != 0)
+ if (diff <= SEH_MAX_FRAME_SIZE && (diff > 240 || (diff & 15) != 0))
{
/* Ideally we'd determine what portion of the local stack frame
(within the constraint of the lowest 240) is most heavily used.
@@ -10146,6 +10156,7 @@ ix86_expand_prologue (void)
struct ix86_frame frame;
HOST_WIDE_INT allocate;
bool int_registers_saved;
+ bool sse_registers_saved;
ix86_finalize_stack_realign_flags ();
@@ -10298,6 +10309,9 @@ ix86_expand_prologue (void)
m->fs.realigned = true;
}
+
[PATCH] Fix PR53693
When the vectorizer detects a widening shift pattern it has to
make sure the widening operation is used only once as it will
make it part of the recognized pattern.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-06-18 Richard Guenther
PR tree-optimization/53693
* tree-vect-patterns.c (vect_operation_fits_smaller_type):
Reject operands with more than one use.
* g++.dg/torture/pr53693.C: New testcase.
Index: gcc/tree-vect-patterns.c
===
*** gcc/tree-vect-patterns.c(revision 188725)
--- gcc/tree-vect-patterns.c(working copy)
*** vect_operation_fits_smaller_type (gimple
*** 991,996
--- 991,1001
|| TREE_CODE (const_oprnd) != INTEGER_CST)
return false;
+ /* If oprnd has other uses besides that in stmt we cannot mark it
+ as being part of a pattern only. */
+ if (!has_single_use (oprnd))
+ return false;
+
/* If we are in the middle of a sequence, we use DEF from a previous
statement. Otherwise, OPRND has to be a result of type promotion. */
if (*new_type)
Index: gcc/testsuite/g++.dg/torture/pr53693.C
===
*** gcc/testsuite/g++.dg/torture/pr53693.C (revision 0)
--- gcc/testsuite/g++.dg/torture/pr53693.C (revision 0)
***
*** 0
--- 1,21
+ // { dg-do compile }
+
+ void
+ filter_scanlines (void *src_buffer, void *dst_buffer, int dst_pitch, int
width)
+ {
+ int x;
+ unsigned short *src, *dst_a, *dst_b;
+
+ src = (unsigned short *) src_buffer;
+ dst_a = (unsigned short *) dst_buffer;
+ dst_b = ((unsigned short *) dst_buffer) + (dst_pitch >> 1);
+
+ for (x = 0; x < width; x++)
+ {
+ unsigned char gs, gh;
+ gs = src[x];
+ gh = gs + (gs >> 1);
+ dst_a[x] = (gh << 5) | (gh);
+ dst_b[x] = ((gs - gh) << 5) | (gs - gh);
+ }
+ }
Re: [patch] Remove NO_IMPLICIT_EXTERN_C target macro
On Mon, Jun 18, 2012 at 1:12 PM, Joseph S. Myers
wrote:
> On Mon, 18 Jun 2012, Steven Bosscher wrote:
>
>> For targets that do not define NO_IMPLICIT_EXTERN_C, GCC assumes that
>> included system headers are implicitly wrapped in 'extern "C" {...}'.
>> I could not find where this target macro was introduced, but it is
>> very old (it is already mentioned in FSFChangeLog.10 for a change in
>> 1995). AFAICT, today all supported targets have C++-compatible headers
>
> May have been introduced by:
>
> Fri Nov 5 05:48:04 1993 Richard Stallman (r...@mole.gnu.ai.mit.edu)
>
> * cccp.c (main): Handle NO_IMPLICIT_EXTERN_C.
>
>> (according to one comment, even hpux8 had C++-compatible system
>> headers :-), so NO_IMPLICIT_EXTERN_C shouldn't be necessary anymore.
>
> It was previously said that AIX headers needed it
> . That of course was AIX
> headers as of 2005; I don't know whether seven years later any version of
> AIX supported by GCC trunk still needs this.
AFAICT, the oldest supported version is AIX 4.3, from 1997. Given
that HP-UX 8 already had C++ compatible headers in 1991, one would
hope that AIX 4.3 had its headers fixed also, several years after
HP-UX 8.
>> The only target that explicitly undefines NO_IMPLICIT_EXTERN_C is
>> sparc64-openbsd, and I find it hard to believe that the system headers
>> on openbsd are not also already C++-compatible. Marc, could you have a
>> look at this, please?
>
> What targets (such as AIX?) did not explicitly undefine it, but did not
> get a definition from any header they used either? It's quite likely some
> such targets *should* have had NO_IMPLICIT_EXTERN_C defined, but not
> necessarily all of them.
The following OSs all have NO_IMPLICIT_EXTERN_C defined:
darwin.h:#define NO_IMPLICIT_EXTERN_C
freebsd.h:#define NO_IMPLICIT_EXTERN_C 1
gnu-user.h:#define NO_IMPLICIT_EXTERN_C (covers all glibc and
glibc-derived targets).
lynx.h:# define NO_IMPLICIT_EXTERN_C
netbsd.h:#define NO_IMPLICIT_EXTERN_C1
rtems.h:#define NO_IMPLICIT_EXTERN_C
sol2.h:#define NO_IMPLICIT_EXTERN_C
vx-common.h:#define NO_IMPLICIT_EXTERN_C
So all the major OSs are covered. I'm not sure how Bionic is covered, though.
Since your list (http://gcc.gnu.org/ml/gcc/2005-05/msg00377.html) the
following things have changed:
The following targets have been fixed (i.e. now do define NO_IMPLICIT_EXTERN_C):
arm-wrs-vxworks
i[34567]86-*-darwin*
i[4567]86-wrs-vxworks
m68k-*-uclinux*
mipsisa32-*-elf* (via config/mips/elf.h)
mipsisa32el-*-elf*
mipsisa32r2-*-elf*
mipsisa32r2el-*-elf*
mipsisa64-*-elf*
mipsisa64el-*-elf*
mipsisa64sr71k-*-elf*
mipsisa64sb1-*-elf*
mipsisa64sb1el-*-elf*
mips-*-elf*
mipsel-*-elf*
mips64-*-elf*
mips64el-*-elf*
mips64vr-*-elf*
mips64vrel-*-elf*
mips64orion-*-elf*
mips64orionel-*-elf*
mips-wrs-vxworks
mips-wrs-windiss
mipstx39-*-elf*
mipstx39el-*-elf*
powerpc-*-darwin*
v850e1-*-* (via config/v850/v850.h)
v850e-*-*
v850-*-*
The following have been removed:
arc-*-elf*
arm-*-coff*
armel-*-coff*
arm-semi-aof
armel-semi-aof
arm*-*-ecos-elf
arm*-*-elf
ep9312-*-elf (this is a --with-arch for arm*-*-*)
arm*-wince-pe*
arm-*-pe*
arm*-*-kaos*
c4x-* (other than c4x-*-rtems*)
tic4x-* (other than tic4x-*-rtems*)
hppa1.1-*-osf*
hppa1.1-*-bsd*
i[34567]86-sequent-ptx4*
i[34567]86-sequent-sysv4*
i[34567]86-*-aout*
i[34567]86-*-coff*
i[3456x]86-*-netware*
i[34567]86-*-sysv5*
i[34567]86-*-sysv4*
i[34567]86-*-uwin*
i[34567]86-*-kaos*
i860-*-sysv4*
ip2k-*-elf
m68hc11-*-*
m6811-*-*
m68hc12-*-*
m6812-*-*
m68k-*-aout*
m68k-*-coff*
m68020-*-elf*
mcore-*-pe*
mn10300-*-*
pdp11-*-bsd
powerpc-*-beos*
sparc-*-openbsd* (apparently only sparc64-openbsd is still supported)
sparc-*-sysv4*
strongarm-*-elf*
strongarm-*-pe
strongarm-*-kaos*
vax-*-bsd*
vax-*-sysv*
vax-*-ultrix*
xscale-*-elf
xscale-*-coff
The following targets do not define NO_IMPLICIT_EXTERN_C (mostly
openbsd, aix, and generic ELF targets):
arm*-*-eabi*
arm*-*-symbianelf*
avr-*-* (other than avr-*-rtems*)
bfin*-elf*
bfin*-*
fr30-*-elf
frv-*-elf
h8300-*-* (other than h8300-*-rtems*)
i[34567]86-*-elf*
ia64*-*-elf*
iq2000*-*-elf*
m32r-*-elf*
m32rle-*-elf*
m68k-*-elf*
mcore-*-elf
pdp11-*-*
sh*-*-* (other than sh*-*-linux*, sh*-*-netbsd*, sh-wrs-vxworks, and
sh*-*-rtems*)
rs6000-ibm-aix4.[12]*
powerpc-ibm-aix4.[12]*
rs6000-ibm-aix4.[3456789]*
powerpc-ibm-aix4.[3456789]*
rs6000-ibm-aix5.1.*
powerpc-ibm-aix5.1.*
rs6000-ibm-aix[56789].*
powerpc-ibm-aix[56789].*
i[34567]86-*-openbsd2.*
i[34567]86-*openbsd3.[0123]
i[34567]86-*-openbsd*
m68k*-*-openbsd*
mips*-*-openbsd*
sparc64-*-openbsd* (deliberate #undef)
vax-*-openbsd*
Ciao!
Steven
[RFC C++ / PR51033 ] Handle __builtin_shuffle in constexpr properly in the C++ frontend.
Hi, This patch following on from the fix for turning on __builtin_shuffle for c++ , enables folding of vec_perm_exprs in the front-end for constexpr and constructor style values. I was originally going to go with Marc's patch but then took a look at what it would take to support this properly which appeared to me to be just calling fold with the right parameters. With simple tests based on variations from c-c++-common/vshuf*.c using constexpr execution tests appear to pass - There is still an issue with the compiler giving an error on seeing a subscript operation with a __builtin_shuffle - I'm going to let that one for someone else to pick up because I don't have the time to pick this up right at this minute and the fact is that folks could use an extra vector for the time being. Regression tested with a bootstrap and testrun on powerpc / x86_64-linux-gnu and cross-tested on arm-linux-gnueabi Thoughts ? regards, Ramana cp/ PR C++/51033 * semantics.c (constexpr_call): Fix typo in comment. (cxx_eval_vec_perm_expr): New. (cxx_eval_constant_expression): Fold VEC_PERM_EXPRs. testsuite/ * g++.dg/torture/vshuf-16.inc: New test. * g++.dg/torture/vshuf-2.inc: New test. * g++.dg/torture/vshuf-4.inc: New test. * g++.dg/torture/vshuf-8.inc: New test. * g++.dg/torture/vshuf-main.inc: New test. * g++.dg/torture/vshuf-v16hi.C: New test. * g++.dg/torture/vshuf-v16qi.C: New test. * g++.dg/torture/vshuf-v2df.C: New test. * g++.dg/torture/vshuf-v2di.C: New test. * g++.dg/torture/vshuf-v2sf.C: New test. * g++.dg/torture/vshuf-v2si.C: New test. * g++.dg/torture/vshuf-v4df.C: New test. * g++.dg/torture/vshuf-v4di.C: New test. * g++.dg/torture/vshuf-v4sf.C: New test. * g++.dg/torture/vshuf-v4si.C: New test. * g++.dg/torture/vshuf-v8hi.C: New test. * g++.dg/torture/vshuf-v8qi.C: New test. * g++.dg/torture/vshuf-v8si.C: New test. constexpr-vshuf.patch Description: Binary data
Re: [RFC C++] Turn on builtin_shuffle for C++.
On 15 June 2012 20:04, Marc Glisse wrote:
> On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
>
>> On 15 June 2012 18:18, Marc Glisse wrote:
>>>
>>> On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
>>>
> I just noticed this part. Rereading my comment in
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033#c22
I haven't been able to make it break with -std=c++11 . Is there
something I'm missing here ?
>>>
>>>
>>>
>>> I don't remember. It might just be that trying to create a constexpr
>>> vector
>>> variable or calling __builtin_shuffle on it ICEs instead of giving an
>>> error.
>>> I can keep a note to make some tests at the end of July (I will be mostly
>>> away until then), but I believe the code from comment 22 is safer than
>>> the
>>> one from comment 20, if memory serves.
>>
>>
>> I'm not qualified enough to take a call on what's better in this case
>> and will have to defer to Jason and the C++ maintainers on this one.
>>
>> Now that you've said this I decided to go back and throw more tests
>> through it
>> I've tried to chug through most of the testcases for __builtin_shuffle
>> including a few of my own the simplest of which I show below trying to
>> trigger this issue but can't seem to do so.
>
>
> Maybe something like:
>
> #include
> int main(){
> constexpr __m128d x={1.,2.};
> constexpr __m128i y={1,0};
> constexpr __m128d z=__builtin_shuffle(x,y);
> }
>
> ?
> (sorry for the x86 specific code, should be easy to adapt)
>
> See also:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094
>
> Long term, vectors should be literals. But we need something to avoid
> crashes on operator[] and __builtin_shuffle (ideally implementing the
> constant version of them). Keeping vectors as non-literals (what I was
> suggesting) is quite a crude hack. Maybe having them as literals now is a
> good thing, but it would be good to avoid the ICEs.
I've submitted a fresh patch for that over at
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01165.html . thought it
better than conflating the 2 threads.
regards,
Ramana
[Patch] Don't test for pr53425 on mingw
Hi,
I am told that this ABI test does not apply to mingw targets. OK to apply?
Index: gcc/testsuite/gcc.target/i386/pr53425-1.c
===
--- gcc/testsuite/gcc.target/i386/pr53425-1.c (revision 188384)
+++ gcc/testsuite/gcc.target/i386/pr53425-1.c (working copy)
@@ -1,6 +1,7 @@
/* PR target/53425 */
/* { dg-do compile { target { ! { ia32 } } } } */
/* { dg-options "-O2 -mno-sse" } */
+/* { dg-skip-if "" { { i?86-*-mingw* x86_64-*-mingw* } && ! ilp32 } { "*" } {
"" } } */
typedef double __v2df __attribute__ ((__vector_size__ (16)));
Index: gcc/testsuite/gcc.target/i386/pr53425-2.c
===
--- gcc/testsuite/gcc.target/i386/pr53425-2.c (revision 188384)
+++ gcc/testsuite/gcc.target/i386/pr53425-2.c (working copy)
@@ -1,6 +1,7 @@
/* PR target/53425 */
/* { dg-do compile { target { ! { ia32 } } } } */
/* { dg-options "-O2 -mno-sse" } */
+/* { dg-skip-if "" { { i?86-*-mingw* x86_64-*-mingw* } && ! ilp32 } { "*" } {
"" } } */
typedef float __v2sf __attribute__ ((__vector_size__ (8)));
signature.asc
Description: OpenPGP digital signature
Re: [PATCH][4/n] VRP and anti-range handling
Hi, Before revision 188728, the test gcc.dg/tree-ssa/vrp68.c failed because link_error appeared twice in the dump file. After r188728 it fails also at link time and link_error appears three time: FAIL: gcc.dg/tree-ssa/vrp68.c (test for excess errors) Excess errors: Undefined symbols: "_link_error", referenced from: _test1 in ccyK5YD6.o ld: symbol(s) not found XFAIL: gcc.dg/tree-ssa/vrp68.c scan-tree-dump-times vrp1 "link_error" 0 FAIL: gcc.dg/tree-ssa/vrp68.c scan-tree-dump-times vrp1 "link_error" 1 Dominique
Re: [Patch] Don't test for pr53425 on mingw
2012/6/18 JonY : > Hi, > > I am told that this ABI test does not apply to mingw targets. OK to apply? Hi JonY, The test doesn't apply to x64 windows targets, as for it sse is part of its ABI. As test already checks for !ia32, we could simply check for x86_64/i?86-*-mingw* targets instead. We don't need to check for ilp32 here again. Regards, Kai
Re: [Patch] Adjustments for Windows x64 SEH
Hello Tristan, patch works for me, too. Just one nit about the patch. 2012/6/18 Tristan Gingold : > @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void) > if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp) > return true; > > + /* Win64 SEH, very large frames need a frame-pointer as maximum stack > + allocation is 4GB (add a safety guard for saved registers). */ > + if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE) > + return true; Where does this magic 4096 comes from? Is it intended to be the page-size, or is it meant to be the maximum stack-frame consumed by prologue? I would suggest to use here instead: + if (TARGET_64BIT_MS_ABI && get_frame_size () > (SEH_MAX_FRAME_SIZE - 4096)) +return true; Additional a testcase for big-stackframe would be interesting. You won't need to make here a execution test, a assembler-scan would be enough.
Re: [4.6][ARM] Backport fix PR48126
On 18/06/12 04:11, Joey Ye wrote: > OK for 4.6? > > 2012-06-18 Joey Ye > > Backport from mainline > 2011-10-14 David Alan Gilbert > > PR target/48126 > * config/arm/arm.c (arm_output_sync_loop): Move label before > barrier. > > > Index: gcc/config/arm/arm.c > === > --- gcc/config/arm/arm.c (revision 188331) > +++ gcc/config/arm/arm.c (working copy) > @@ -23423,8 +23423,11 @@ > } > } > > + /* Note: label is before barrier so that in cmp failure case we still get > + a barrier to stop subsequent loads floating upwards past the ldrex > + PR target/48126. */ > + arm_output_asm_insn (emit, 1, operands, "%sLSYB%%=:", > LOCAL_LABEL_PREFIX); >arm_process_output_memory_barrier (emit, NULL); > - arm_output_asm_insn (emit, 1, operands, "%sLSYB%%=:", > LOCAL_LABEL_PREFIX); > } > This bit is OK... > static rtx > Index: gcc/config/arm/arm.h > === > --- gcc/config/arm/arm.h (revision 188331) > +++ gcc/config/arm/arm.h (working copy) > @@ -294,7 +294,8 @@ > #define TARGET_HAVE_DMB (arm_arch7) > > /* Nonzero if this chip implements a memory barrier via CP15. */ > -#define TARGET_HAVE_DMB_MCR (arm_arch6k && ! TARGET_HAVE_DMB) > +#define TARGET_HAVE_DMB_MCR (arm_arch6 && ! TARGET_HAVE_DMB \ > + && ! TARGET_THUMB1) > > /* Nonzero if this chip implements a memory barrier instruction. */ > #define TARGET_HAVE_MEMORY_BARRIER (TARGET_HAVE_DMB || TARGET_HAVE_DMB_MCR) > ... but this bit has nothing to do with what you've described. R.
RFA: Fix PR53688
Hi,
now that we regard MEM_EXPR as a conservative approximation for MEM_SIZE
(and MEM_OFFSET) we must ensure that this is really the case. It isn't
currently for the string expanders, as they use the MEM_REF (whose address
was taken) directly as the one to use for MEM_EXPR on the MEM rtx. That's
wrong, on gimple side we take the address only and hence its size is
arbitrary.
So, we have to build a memref always and rewrite its type to one
representing the real size. Note that TYPE_MAX_VALUE may be NULL, so we
don't need to check for 'len' being null or not.
This fixes the C testcase (don't know about fma 3d), and is in
regstrapping on x86_64-linux. Okay if that passes?
Ciao,
Michael.
PR middle-end/53688
* builtins.c (get_memory_rtx): Always build a MEM_REF and override
its type with one of correct range.
testsuite/
* gcc.c-torture/execute/pr53688.c: New test.
Index: builtins.c
===
--- builtins.c (revision 188734)
+++ builtins.c (working copy)
@@ -1274,11 +1274,11 @@ get_memory_rtx (tree exp, tree len)
&& TREE_CODE (TREE_OPERAND (exp, 0)) == ADDR_EXPR
&& host_integerp (TREE_OPERAND (exp, 1), 0)
&& (off = tree_low_cst (TREE_OPERAND (exp, 1), 0)) > 0)
-exp = TREE_OPERAND (TREE_OPERAND (exp, 0), 0);
+exp = build_simple_mem_ref (TREE_OPERAND (exp, 0));
else if (TREE_CODE (exp) == ADDR_EXPR)
-exp = TREE_OPERAND (exp, 0);
+exp = build_simple_mem_ref (exp);
else if (POINTER_TYPE_P (TREE_TYPE (exp)))
-exp = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (exp)), exp);
+exp = build_simple_mem_ref (exp);
else
exp = NULL;
@@ -1287,6 +1287,11 @@ get_memory_rtx (tree exp, tree len)
(as stringops may access multiple array elements). */
if (exp)
{
+ /* Reset the type to something spanning the whole thing. EXP
+ is always a MEM_REF, hence unshared. */
+ TREE_TYPE (exp)
+ = build_array_type (char_type_node,
+ build_range_type (sizetype, size_one_node, len));
set_mem_attributes (mem, exp, 0);
if (off)
Index: testsuite/gcc.c-torture/execute/pr53688.c
===
--- testsuite/gcc.c-torture/execute/pr53688.c (revision 0)
+++ testsuite/gcc.c-torture/execute/pr53688.c (revision 0)
@@ -0,0 +1,32 @@
+char headline[256];
+struct hdr {
+ char part1[9];
+ char part2[8];
+} p;
+
+void __attribute__((noinline,noclone))
+init()
+{
+ __builtin_memcpy (p.part1, "FOOBARFOO", sizeof (p.part1));
+ __builtin_memcpy (p.part2, "SPEC CPU", sizeof (p.part2));
+}
+
+int main()
+{
+ char *x;
+ int c;
+ init();
+ __builtin_memcpy (&headline[0], p.part1, 9);
+ c = 9;
+ x = &headline[0];
+ x = x + c;
+ __builtin_memset (x, ' ', 245);
+ __builtin_memcpy (&headline[10], p.part2, 8);
+ c = 18;
+ x = &headline[0];
+ x = x + c;
+ __builtin_memset (x, ' ', 238);
+ if (headline[10] != 'S')
+__builtin_abort ();
+ return 0;
+}
Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore
On 16/06/12 13:42, Richard Sandiford wrote: > Roland McGrath writes: >> On Thu, Jun 14, 2012 at 1:13 PM, Mike Stump wrote: >>> On Jun 14, 2012, at 10:16 AM, Roland McGrath wrote: But if e.g. I use -ffixed-r9 then I think it's a reasonable expectation that no code is generated that touches r9 in any way, shape, or form. >>> >>> Also, I can't help but wonder if global_regs is respected. >> >> It's clearly not. Making the added condition !fixed_regs[i] && >> !global_regs[i] seems sensible to me. > > All global registers have to be fixed though. The original seemed > fine to me FWIW. > > Richard > Indeed, see globalize_reg() in reginfo.c. R.
[arm] Remove obsolete FPA support (6/n): fix warnings
[I composed this message on Friday, before I left for the weekend, but
somehow forgot to press send. The good news is that as a result I can
now confirm that this has fixed the outstanding bootstrap issue.]
This patch cleans up some build warnings that break native bootstrap.
One of the warnings wasn't related to my changes (the iwmmxt one), but
the rest are mine. Mea culpa!
* arm.c (note_invalid_constants): Don't return a result.
(arm_memory_load_p): Delete function.
(arm_const_double_rtx): Delete iterator variable i;
(fp_immediate_constant): Likewise.
(fp_const_from_val): Likewise.
* arm.c (arm_init_iwmmxt_builtins): Delete void_ftype_void.
R.Index: arm.c
===
--- arm.c (revision 188662)
+++ arm.c (working copy)
@@ -117,7 +117,7 @@ static void push_minipool_barrier (rtx,
static void push_minipool_fix (rtx, HOST_WIDE_INT, rtx *, enum machine_mode,
rtx);
static void arm_reorg (void);
-static bool note_invalid_constants (rtx, HOST_WIDE_INT, int);
+static void note_invalid_constants (rtx, HOST_WIDE_INT, int);
static unsigned long arm_compute_save_reg0_reg12_mask (void);
static unsigned long arm_compute_save_reg_mask (void);
static unsigned long arm_isr_value (tree);
@@ -166,7 +166,6 @@ static bool arm_rtx_costs (rtx, int, int
static int arm_address_cost (rtx, bool);
static int arm_register_move_cost (enum machine_mode, reg_class_t,
reg_class_t);
static int arm_memory_move_cost (enum machine_mode, reg_class_t, bool);
-static bool arm_memory_load_p (rtx);
static void arm_init_builtins (void);
static void arm_init_iwmmxt_builtins (void);
static rtx safe_vector_operand (rtx, enum machine_mode);
@@ -8695,7 +8694,6 @@ int
arm_const_double_rtx (rtx x)
{
REAL_VALUE_TYPE r;
- int i;
if (!fp_consts_inited)
init_fp_table ();
@@ -9745,41 +9743,6 @@ arm_return_in_msb (const_tree valtype)
|| FIXED_POINT_TYPE_P (valtype)));
}
-/* Returns TRUE if INSN is an "LDR REG, ADDR" instruction.
- Use by the Cirrus Maverick code which has to workaround
- a hardware bug triggered by such instructions. */
-static bool
-arm_memory_load_p (rtx insn)
-{
- rtx body, lhs, rhs;;
-
- if (insn == NULL_RTX || GET_CODE (insn) != INSN)
-return false;
-
- body = PATTERN (insn);
-
- if (GET_CODE (body) != SET)
-return false;
-
- lhs = XEXP (body, 0);
- rhs = XEXP (body, 1);
-
- lhs = REG_OR_SUBREG_RTX (lhs);
-
- /* If the destination is not a general purpose
- register we do not have to worry. */
- if (GET_CODE (lhs) != REG
- || REGNO_REG_CLASS (REGNO (lhs)) != GENERAL_REGS)
-return false;
-
- /* As well as loads from memory we also have to react
- to loads of invalid constants which will be turned
- into loads from the minipool. */
- return (GET_CODE (rhs) == MEM
- || GET_CODE (rhs) == SYMBOL_REF
- || note_invalid_constants (insn, -1, false));
-}
-
/* Return TRUE if X references a SYMBOL_REF. */
int
symbol_mentioned_p (rtx x)
@@ -13245,13 +13208,10 @@ arm_const_double_by_immediates (rtx val)
/* Scan INSN and note any of its operands that need fixing.
If DO_PUSHES is false we do not actually push any of the fixups
- needed. The function returns TRUE if any fixups were needed/pushed.
- This is used by arm_memory_load_p() which needs to know about loads
- of constants that will be converted into minipool loads. */
-static bool
+ needed. */
+static void
note_invalid_constants (rtx insn, HOST_WIDE_INT address, int do_pushes)
{
- bool result = false;
int opno;
extract_insn (insn);
@@ -13260,7 +13220,7 @@ note_invalid_constants (rtx insn, HOST_W
fatal_insn_not_found (insn);
if (recog_data.n_alternatives == 0)
-return false;
+return;
/* Fill in recog_op_alt with information about the constraints of
this insn. */
@@ -13285,7 +13245,6 @@ note_invalid_constants (rtx insn, HOST_W
if (do_pushes)
push_minipool_fix (insn, address, recog_data.operand_loc[opno],
recog_data.operand_mode[opno], op);
- result = true;
}
else if (GET_CODE (op) == MEM
&& GET_CODE (XEXP (op, 0)) == SYMBOL_REF
@@ -13308,12 +13267,11 @@ note_invalid_constants (rtx insn, HOST_W
recog_data.operand_mode[opno], cop);
}
- result = true;
}
}
}
- return result;
+ return;
}
/* Convert instructions to their cc-clobbering variant if possible, since
@@ -13670,7 +13628,6 @@ const char *
fp_immediate_constant (rtx x)
{
REAL_VALUE_TYPE r;
- int i;
if (!fp_consts_inited)
init_fp_table ();
@@ -13685,8 +13642,6 @@ fp_immediate_constant (rtx x)
static const char *
fp_const_from_val (REAL_VALUE_TYPE *r)
{
- int i;
-
if (!fp_consts_inited)
in
[Patch, Testsuite, ARM] Improve test gcc.target/arm/handler-align.c
This test checks that the stack pointer is handled correctly in
prologue/epilogue of Cortex-M interrupt handlers. An interrupt handler may
be called when stack is not double-word aligned. The prologue of the
interrupt handler aligns the stack pointer and the epilogue restores the
original stack pointer.
However, in this test, the stack is always double-word aligned when the
handler function foo is called. As a result, the test is not very effective,
for example it passes even if the epilogue does not restore the stack
pointer. This patch forces the stack pointer to be not double-word aligned
on the call to foo.
Tested on qemu -cpu cortex-m3.
Ok for trunk?
Thanks,
Greta
ChangeLog:
gcc/testsuite
2012-06-18 Greta Yorsh
* gcc.target/arm/handler-align.c (main): Force the stack pointer
to be not double-word aligned on the call to the interrupt handler.diff --git a/gcc/testsuite/gcc.target/arm/handler-align.c
b/gcc/testsuite/gcc.target/arm/handler-align.c
index 6c5187b..b0efa58 100644
--- a/gcc/testsuite/gcc.target/arm/handler-align.c
+++ b/gcc/testsuite/gcc.target/arm/handler-align.c
@@ -29,8 +29,15 @@ int main()
/* Check stack pointer before/after calling the interrupt
* handler. Not equal means that handler doesn't restore
* stack correctly. */
save_sp = sp;
- foo();
+
+/* The stack is always double-word aligned here. To test interrupt
handling,
+ force the stack to be not double-word aligned. */
+asm volatile ("sub\tsp, sp, #4" : : : "memory" );
+foo ();
+/* Restore the stack. */
+asm volatile ("add\t sp, sp, #4" : : : "memory" );
+
/* Abort here instead of return non-zero. Due to wrong sp, lr value,
* returning from main may not work. */
if (save_sp != sp)
[patch, testsuite] new test for arm epilogue
This test relies on epilogue generated in RTL to provide register liveness
information that enables peephole optimization.
OK for trunk?
Thanks,
Greta
2012-06-18 Joey Ye
Greta Yorsh
* gcc.target/arm/epilog-1.c: New test.
diff --git a/gcc/testsuite/gcc.target/arm/epilog-1.c
b/gcc/testsuite/gcc.target/arm/epilog-1.c
new file mode 100644
index 000..f97f1eb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/epilog-1.c
@@ -0,0 +1,17 @@
+/* Register liveness information from epilgoue enables peephole optimization.
*/
+/* { dg-do compile } */
+/* { dg-options "-mthumb -Os" } */
+/* { dg-require-effective-target arm_thumb2_ok } */
+
+volatile int g_k;
+extern void bar(int, int, int, int);
+
+int foo(int a, int b, int c, int d)
+{
+ if (g_k & 4) c++;
+ bar (a, b, c, d);
+ return 0;
+}
+
+/* { dg-final { scan-assembler-times "lsls.*#29" 1 } } */
+/* { dg-final { scan-assembler-not "tst" } } */
Re: [PATCH 2/3] Add XLP-specific atomic instructions and tweaks.
On 2012-06-17 13:01, Richard Sandiford wrote: >> > Not required if you use the proper predicate in the expander. >> > The middle-end will take care of this for you. > I might be misunderstanding, sorry, but this expander is shared with > the normal LL/SC path, which can accept plain memory_operands. > I was thinking we'd want to keep the expander predicates the same > and apply these SWAP-style restrictions only when needed. Ah right. That's a different question then. r~
[patch] Use IDENTIFIER_LENGTH instead of strlen(IDENTIFIER_POINTER) in a few places
Hello,
Obvious enough that I'll commit this a week or so from now, unless
someone objects.
Ciao!
Steven
gcc/
* tree-emultls.c (prefix_name): Use IDENTIFIER_LENGTH instead of
strlen(IDENTIFIER_POINTER).
objc/
* objc-encoding.c (encode_aggregate_fields): Use IDENTIFIER_LENGTH
instead of strlen(IDENTIFIER_POINTER).
(encode_aggregate_within): Likewise.
Index: tree-emutls.c
===
--- tree-emutls.c (revision 188724)
+++ tree-emutls.c (working copy)
@@ -83,7 +83,7 @@ static tree
prefix_name (const char *prefix, tree name)
{
unsigned plen = strlen (prefix);
- unsigned nlen = strlen (IDENTIFIER_POINTER (name));
+ unsigned nlen = IDENTIFIER_LENGTH (name);
char *toname = (char *) alloca (plen + nlen + 1);
memcpy (toname, prefix, plen);
Index: objc/objc-encoding.c
===
--- objc/objc-encoding.c(revision 188724)
+++ objc/objc-encoding.c(working copy)
@@ -471,7 +471,7 @@ encode_aggregate_fields (tree type, bool pointed_t
if (fname && TREE_CODE (fname) == IDENTIFIER_NODE)
obstack_grow (&util_obstack,
IDENTIFIER_POINTER (fname),
- strlen (IDENTIFIER_POINTER (fname)));
+ IDENTIFIER_LENGTH (fname));
obstack_1grow (&util_obstack, '"');
}
@@ -561,7 +561,7 @@ encode_aggregate_within (tree type, int curtype, i
if (name && TREE_CODE (name) == IDENTIFIER_NODE)
obstack_grow (&util_obstack,
IDENTIFIER_POINTER (name),
- strlen (IDENTIFIER_POINTER (name)));
+ IDENTIFIER_LENGTH (name));
#endif
else
obstack_1grow (&util_obstack, '?');
RE: [Patch, ARM][0/8] Epilogue in RTL: introduction (Sameera's patches, Part I)
Paul, I did additional testing of the patches, as you suggested. For iwmmxt, no regression on qemu (using -cpu pxa270) for arm-none-eabi taget configured --with-cpu iwmmxt --with-float soft --with-arch iwmmxt --with-abi iwmmxt --disable-multilib. There is already a test for mmx stack alignment in gcc.target/arm/mmx-1.c. I have also tested a few other options (including -mtcps-frame and -mtpcs-leaf-frame) on several examples and haven't found any problems with the patches (at least, not yet :) Separately, I submitted a couple of testsuite patches related to RTL epilogue: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01175.html http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01176.html FPA support is in the process of being removed from ARM backend trunk: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00825.html I hope it addresses your concerns. Following Richard's comments, I removed FPA support from RTL epilogue patches, rebased patches to trunk, and fixed some formatting problems. I'll go ahead and apply individual patches that have already been approved. Thank you, Greta > -Original Message- > From: Paul Brook [mailto:p...@codesourcery.com] > Sent: 31 May 2012 19:18 > To: Greta Yorsh > Cc: GCC Patches; jos...@codesourcery.com; Richard Earnshaw; > sameera.deshpa...@gmail.com; Ramana Radhakrishnan; ni...@redhat.com > Subject: Re: [Patch, ARM][0/8] Epilogue in RTL: introduction (Sameera's > patches, Part I) > > > Testing: > > * Crossbuild for target arm-none-eabi with cpu cortex-a9 neon softfp > and > > tested in three configuration: -marm (default), -mthumb, -mapcs- > frame. No > > regression on qemu. > > * Crossbuild for target arm-none-eabi thumb2 with cpu cortex-m3. No > > regression on qemu. > > * Crossbuild for target arm-none-eabi thumb1 with cpu arm7tdmi and > > arm1136jf-s. No regression on qemu. > > * Crossbuild for target arm-linux-gnueabi with cpu cortex-a9 with > eglibc > > and used this compiler to build AEL linux kernel. It boots > successfully. * > > Bootstrap the compiler on cortex-a8 successfully for > > --languages=c,c++,fortran and used this compiler to build gdb. No > > regression with check-gcc and check-gdb. > > What other testing have you done? Thate's a good number of > combinations not > covered by your above list. In particular: > - Coverage of old cores looks pretty thin. In particular ARMv4t has > different > interworking requirements. > - iWMMXT has special alignment requirements. > - Interrupt functions with special prologue/epilogue. Both traditional > ARM > and Cortex-M3. > - -mtpcs-frame and -mtpcs-leaf-frame > > Some of these options are orthogonal. > > As you've proved with -mapcs-frame it's near impossible to get these > right > without actually testing them.I'm not saying you have to do a full > testrun > in every combination, but it's worth testing a representative selection > of > functions (large and small frame, leaf or not, with and without frame > pointer, > uses alloca, etc). Also worth explicitly clobbering a selection (both > odd and > even numbers) of callee saved registers to make sure we get that right. > Any > difference in the output should be manually verified (ideally the > assembly > output would be identical). > > > * The patches have not been explicitly tested with any FPA variants > (which > > are deprecated in 4.7 and expected to become obsolete in 4.8). > > I'm not keen on breaking these without actually removing them. > > Paul
Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore
OK then. If you like the original patch, would you like to commit it for me? Thanks, Roland
[PATCH] backport darwin12 fixes to gcc-4_7-branch
The attached patch backports...
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01710.html
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01707.html
which implement changes for darwin12 and later. Bootstrap
and regression tested on current x86_64-apple-darwin12.
http://gcc.gnu.org/ml/gcc-testresults/2012-06/msg01547.html
Okay for gcc-4_7-branch?
Jack
2012-06-17 Jack Howarth
Backport from mainline
2012-05-29 Jack Howarth
* config/darwin.h (STARTFILE_SPEC): Use -no_new_main with -lgcrt1.o
on Darwin >= 12.
(DARWIN_CRT1_SPEC): Use -lcrt1.10.6.o when Darwin >= 10 and < 12.
2012-05-29 Jack Howarth
PR debug/53453
* doc/tm.texi: Update.
* doc/tm.texi.in (SDB and DWARF) : Add @hook.
* target.def (force_at_comp_dir): New hook.
* config/darwin.h (TARGET_FORCE_AT_COMP_DIR): Define.
* dwarf2out.c (dwarf2out_finish): Check targetm.force_at_comp_dir.
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in (revision 188717)
+++ gcc/doc/tm.texi.in (working copy)
@@ -9386,6 +9386,8 @@ tables, and hence is desirable if it wor
@hook TARGET_WANT_DEBUG_PUB_SECTIONS
+@hook TARGET_FORCE_AT_COMP_DIR
+
@hook TARGET_DELAY_SCHED2
@hook TARGET_DELAY_VARTRACK
Index: gcc/target.def
===
--- gcc/target.def (revision 188717)
+++ gcc/target.def (working copy)
@@ -2748,6 +2748,13 @@ DEFHOOKPOD
bool, false)
DEFHOOKPOD
+(force_at_comp_dir,
+ "True if the @code{DW_AT_comp_dir} attribute should be emitted for each \
+ compilation unit. This attribute is required for the darwin linker \
+ to emit debug information.",
+ bool, false)
+
+DEFHOOKPOD
(delay_sched2, "True if sched2 is not to be run at its normal place. \
This usually means it will be run as part of machine-specific reorg.",
bool, false)
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 188717)
+++ gcc/dwarf2out.c (working copy)
@@ -22501,7 +22501,7 @@ dwarf2out_finish (const char *filename)
/* Add the name for the main input file now. We delayed this from
dwarf2out_init to avoid complications with PCH. */
add_name_attribute (comp_unit_die (), remap_debug_filename (filename));
- if (!IS_ABSOLUTE_PATH (filename))
+ if (!IS_ABSOLUTE_PATH (filename) || targetm.force_at_comp_dir)
add_comp_dir_attribute (comp_unit_die ());
else if (get_AT (comp_unit_die (), DW_AT_comp_dir) == NULL)
{
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 188717)
+++ gcc/config/darwin.h (working copy)
@@ -356,7 +356,9 @@ extern GTY(()) int darwin_ms_struct;
%{!Zbundle:%{pg:%{static:-lgcrt0.o} \
%{!static:%{object:-lgcrt0.o} \
%{!object:%{preload:-lgcrt0.o} \
- %{!preload:-lgcrt1.o %(darwin_crt2)\
+ %{!preload:-lgcrt1.o \
+ %:version-compare(>= 10.8
mmacosx-version-min= -no_new_main) \
+ %(darwin_crt2)\
%{!pg:%{static:-lcrt0.o} \
%{!static:%{object:-lcrt0.o} \
%{!object:%{preload:-lcrt0.o} \
@@ -379,7 +381,7 @@ extern GTY(()) int darwin_ms_struct;
#define DARWIN_CRT1_SPEC \
"%:version-compare(!> 10.5 mmacosx-version-min= -lcrt1.o)\
%:version-compare(>< 10.5 10.6 mmacosx-version-min= -lcrt1.10.5.o) \
- %:version-compare(>= 10.6 mmacosx-version-min= -lcrt1.10.6.o) \
+ %:version-compare(>< 10.6 10.8 mmacosx-version-min= -lcrt1.10.6.o) \
%{fgnu-tm: -lcrttms.o}"
/* Default Darwin ASM_SPEC, very simple. */
@@ -414,6 +416,8 @@ extern GTY(()) int darwin_ms_struct;
#define TARGET_WANT_DEBUG_PUB_SECTIONS true
+#define TARGET_FORCE_AT_COMP_DIR true
+
/* When generating stabs debugging, use N_BINCL entries. */
#define DBX_USE_BINCL
Re: [Patch, Testsuite, ARM] Improve test gcc.target/arm/handler-align.c
On 18/06/12 16:39, Greta Yorsh wrote:
> This test checks that the stack pointer is handled correctly in
> prologue/epilogue of Cortex-M interrupt handlers. An interrupt handler may
> be called when stack is not double-word aligned. The prologue of the
> interrupt handler aligns the stack pointer and the epilogue restores the
> original stack pointer.
>
> However, in this test, the stack is always double-word aligned when the
> handler function foo is called. As a result, the test is not very effective,
> for example it passes even if the epilogue does not restore the stack
> pointer. This patch forces the stack pointer to be not double-word aligned
> on the call to foo.
>
> Tested on qemu -cpu cortex-m3.
>
> Ok for trunk?
>
> Thanks,
> Greta
>
> ChangeLog:
>
> gcc/testsuite
>
> 2012-06-18 Greta Yorsh
>
> * gcc.target/arm/handler-align.c (main): Force the stack pointer
> to be not double-word aligned on the call to the interrupt handler.
>
>
Please add a new test for this; the existing test is still valid.
I'd also prefer a test that didn't mess directly with SP within a
function -- this looks very unsafe, even if it works today.
R.
> test-handler-align.v1.patch.txt
>
>
> diff --git a/gcc/testsuite/gcc.target/arm/handler-align.c
> b/gcc/testsuite/gcc.target/arm/handler-align.c
> index 6c5187b..b0efa58 100644
> --- a/gcc/testsuite/gcc.target/arm/handler-align.c
> +++ b/gcc/testsuite/gcc.target/arm/handler-align.c
> @@ -29,8 +29,15 @@ int main()
> /* Check stack pointer before/after calling the interrupt
> * handler. Not equal means that handler doesn't restore
> * stack correctly. */
> save_sp = sp;
> - foo();
> +
> +/* The stack is always double-word aligned here. To test interrupt
> handling,
> + force the stack to be not double-word aligned. */
> +asm volatile ("sub\tsp, sp, #4" : : : "memory" );
> +foo ();
> +/* Restore the stack. */
> +asm volatile ("add\t sp, sp, #4" : : : "memory" );
> +
> /* Abort here instead of return non-zero. Due to wrong sp, lr value,
>* returning from main may not work. */
> if (save_sp != sp)
Re: [patch, testsuite] new test for arm epilogue
On 18/06/12 16:40, Greta Yorsh wrote:
> This test relies on epilogue generated in RTL to provide register liveness
> information that enables peephole optimization.
>
> OK for trunk?
>
> Thanks,
> Greta
>
>
> 2012-06-18 Joey Ye
> Greta Yorsh
>
> * gcc.target/arm/epilog-1.c: New test.
>
>
> test-epilog-1.patch.txt
>
>
> diff --git a/gcc/testsuite/gcc.target/arm/epilog-1.c
> b/gcc/testsuite/gcc.target/arm/epilog-1.c
> new file mode 100644
> index 000..f97f1eb
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/epilog-1.c
> @@ -0,0 +1,17 @@
> +/* Register liveness information from epilgoue enables peephole
> optimization. */
> +/* { dg-do compile } */
> +/* { dg-options "-mthumb -Os" } */
> +/* { dg-require-effective-target arm_thumb2_ok } */
> +
> +volatile int g_k;
> +extern void bar(int, int, int, int);
> +
> +int foo(int a, int b, int c, int d)
> +{
> + if (g_k & 4) c++;
> + bar (a, b, c, d);
> + return 0;
> +}
> +
> +/* { dg-final { scan-assembler-times "lsls.*#29" 1 } } */
> +/* { dg-final { scan-assembler-not "tst" } } */
OK.
R.
Re: *PING**2 [Patch, Fortran] Reject coarrays in MOVE_ALLOC
Dear Tobias, Good catch on the non-polymorphic 'TO'! >> Updated version (cf. below). Build and regtested on x86-64-linux. >> OK for the trunk? Indeed - OK for trunk. >> >> I asked at J3 and John Reid kindly pointed me to the pending >> interpretation request F08/0040 at >> http://j3-fortran.org/doc/year/12/12-006A.txt >> >> According to the IR, coarray arguments are allowed, if the FROM and TO >> have the same corank. (Hence, Damian's example remains invalid.) That seems entirely logical. >> >> Additionally, MOVE_ALLOC becomes an image control statement as TO might >> get deallocated. I filled a PR to track the implications for -fcoarray=lib: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526 Thanks for doing that and for the patch. Cheers Paul -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
[patch] Fix PR48109 using artificial top-level asm statements (darwin/objc)
Hello,
This patch started as an attempt to remove #include "output.h" from
objc/: Instead of writing references directly to asm_out_file, the
references are output as top-level asm statements. It's a bit of a
hack, but it works and it's a "better hack" than writing to
asm_out_file from a front end, and it also happens to fix PR
objc/48109 to make ObjC on darwin/-m32 LTO-compatible.
Bootstrapped&tested on darwin by Iain, and bootstrapped&tested by me
on x86_64-unknown-linux-gnu.
OK for trunk?
Ciao!
Steven
2012-06-18 Steven Bosscher
Iain Sandoe
gcc/
* doc/tm.texi.in (TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE,
TARGET_OBJC_DECLARE_CLASS_DEFINITION): Add @hooks.
(ASM_DECLARE_CLASS_REFERENCE, ASM_DECLARE_UNRESOLVED_REFERENCE):
Remove.
* doc/tm.texi: Regenerate.
* config/darwin.h (ASM_OUTPUT_LABELREF): Remove special case for
.objc_class_name_*.
* config/darwin-c.c: Include target.h.
(darwin_objc_declare_unresolved_class_reference): New function.
(darwin_objc_declare_class_definition): New function.
(TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE): Define.
(TARGET_OBJC_DECLARE_CLASS_DEFINITION): Define.
c-family/
* c-target.def (objc_declare_unresolved_class_reference,
objc_declare_class_definition): Add new hooks.
objc/
* objc-next-runtime-abi-01.c: Do not include tm.h and output.h.
Include c-family/c-target.h.
(handle_next_class_ref): Rewrite to emit top-level asm statements.
(handle_next_impent): Likewise.
Index: gcc/c-family/c-target.def
===
--- gcc/c-family/c-target.def (revision 188216)
+++ gcc/c-family/c-target.def (working copy)
@@ -59,8 +59,22 @@ DEFHOOK
common-format string object when the target provides one.",
tree, (tree string),
NULL)
-
+
DEFHOOK
+(objc_declare_unresolved_class_reference,
+ "Declare that Objective C class @var{classname} is referenced\
+ by the current TU.",
+ void, (const char *classname),
+ NULL)
+
+DEFHOOK
+(objc_declare_class_definition,
+ "Declare that Objective C class @var{classname} is defined\
+ by the current TU.",
+ void, (const char *classname),
+ NULL)
+
+DEFHOOK
(string_object_ref_type_p,
"If a target implements string objects then this hook should return\
@code{true} if @var{stringref} is a valid reference to such an object.",
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in (revision 188216)
+++ gcc/doc/tm.texi.in (working copy)
@@ -690,6 +690,10 @@ should use @code{TARGET_HANDLE_C_OPTION} instead.
@hook TARGET_OBJC_CONSTRUCT_STRING_OBJECT
+@hook TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE
+
+@hook TARGET_OBJC_DECLARE_CLASS_DEFINITION
+
@hook TARGET_STRING_OBJECT_REF_TYPE_P
@hook TARGET_CHECK_STRING_OBJECT_FORMAT_ARG
@@ -8163,20 +8167,6 @@ On systems where the assembler can handle quoted n
macro to provide more human-readable names.
@end defmac
-@defmac ASM_DECLARE_CLASS_REFERENCE (@var{stream}, @var{name})
-A C statement (sans semicolon) to output to the stdio stream
-@var{stream} commands to declare that the label @var{name} is an
-Objective-C class reference. This is only needed for targets whose
-linkers have special support for NeXT-style runtimes.
-@end defmac
-
-@defmac ASM_DECLARE_UNRESOLVED_REFERENCE (@var{stream}, @var{name})
-A C statement (sans semicolon) to output to the stdio stream
-@var{stream} commands to declare that the label @var{name} is an
-unresolved Objective-C class reference. This is only needed for targets
-whose linkers have special support for NeXT-style runtimes.
-@end defmac
-
@node Initialization
@subsection How Initialization Functions Are Handled
@cindex initialization routines
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 188216)
+++ gcc/doc/tm.texi (working copy)
@@ -694,6 +694,14 @@ should use @code{TARGET_HANDLE_C_OPTION} instead.
Targets may provide a string object type that can be used within and between
C, C++ and their respective Objective-C dialects. A string object might, for
example, embed encoding and length information. These objects are considered
opaque to the compiler and handled as references. An ideal implementation makes
the composition of the string object match that of the Objective-C
@code{NSString} (@code{NXString} for GNUStep), allowing efficient interworking
between C-only and Objective-C code. If a target implements string objects then
this hook should return a reference to such an object constructed from the
normal `C' string representation provided in @var{string}. At present, the hook
is used by Objective-C only, to obtain a common-format string object when the
target provides one.
@end deftypefn
+@deftypefn {C Target Hook} void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFE
Re: **PING**2 [Patch, Fortran] PR53526 - Fix MOVE_ALLOC for coarrays
Dear Tobias, >> OK for the trunk? Yes indeed - thanks for the patch. Cheers Paul
Re: [Patch, Fortran] PR53692 - Fix passing an absent array to an elemental procedure
Dear Tobias, > OK for the trunk? Yes, particularly with the development relative to the draft patch in the PR. OK for trunk. Thanks Paul
Re: [Patch, Fortran] Implement RANK
Hi Tobias, > > Build and regtested on x86-64-gnu-linux. > OK for the trunk? Yes, of course it's OK for trunk. It verges on obvious! Thanks Paul
[PATCH, i386]: Fix PR 53712, Does not combine unaligned load with _mm_cmpistri
Hello!
Attached patch teaches gcc how to merge unaligned load (UNSPEC_MOVU)
with pcmpistr/pcmpestr instructions.
2012-06-18 Uros Bizjak
PR target/53712
* config/i386/sse.md (*sse4_2_pcmpestr_unaligned): New.
(*sse4_2_pcmpistr_unaligned): New.
testsuite/ChangeLog:
2012-06-18 Uros Bizjak
PR target/53712
* gcc.target/i386/pr53712.c: New test.
Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32},
also with followup lex.c patch that substitutes asm with builtins.
Committed to mainline SVN.
Uros.
Index: testsuite/gcc.target/i386/pr53712.c
===
--- testsuite/gcc.target/i386/pr53712.c (revision 0)
+++ testsuite/gcc.target/i386/pr53712.c (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse4.2" } */
+
+typedef char v16qi __attribute__ ((__vector_size__ (16)));
+
+int test (const char *s1, const char *s2)
+{
+ v16qi s1chars = __builtin_ia32_loaddqu ((const char *) s2);
+ v16qi s2chars = __builtin_ia32_loaddqu ((const char *) s1);
+ return __builtin_ia32_pcmpistri128 (s1chars, s2chars, 0);
+}
+
+/* { dg-final { scan-assembler-times "movdqu" 1 } } */
Index: config/i386/sse.md
===
--- config/i386/sse.md (revision 188736)
+++ config/i386/sse.md (working copy)
@@ -9679,6 +9679,68 @@
(set_attr "memory" "none,load")
(set_attr "mode" "TI")])
+(define_insn_and_split "*sse4_2_pcmpestr_unaligned"
+ [(set (match_operand:SI 0 "register_operand" "=c")
+ (unspec:SI
+ [(match_operand:V16QI 2 "reg_not_xmm0_operand" "x")
+ (match_operand:SI 3 "register_operand" "a")
+ (unspec:V16QI
+[(match_operand:V16QI 4 "memory_operand" "m")]
+UNSPEC_MOVU)
+ (match_operand:SI 5 "register_operand" "d")
+ (match_operand:SI 6 "const_0_to_255_operand" "n")]
+ UNSPEC_PCMPESTR))
+ (set (match_operand:V16QI 1 "register_operand" "=Yz")
+ (unspec:V16QI
+ [(match_dup 2)
+ (match_dup 3)
+ (unspec:V16QI [(match_dup 4)] UNSPEC_MOVU)
+ (match_dup 5)
+ (match_dup 6)]
+ UNSPEC_PCMPESTR))
+ (set (reg:CC FLAGS_REG)
+ (unspec:CC
+ [(match_dup 2)
+ (match_dup 3)
+ (unspec:V16QI [(match_dup 4)] UNSPEC_MOVU)
+ (match_dup 5)
+ (match_dup 6)]
+ UNSPEC_PCMPESTR))]
+ "TARGET_SSE4_2
+ && can_create_pseudo_p ()"
+ "#"
+ "&& 1"
+ [(const_int 0)]
+{
+ int ecx = !find_regno_note (curr_insn, REG_UNUSED, REGNO (operands[0]));
+ int xmm0 = !find_regno_note (curr_insn, REG_UNUSED, REGNO (operands[1]));
+ int flags = !find_regno_note (curr_insn, REG_UNUSED, FLAGS_REG);
+
+ if (ecx)
+emit_insn (gen_sse4_2_pcmpestri (operands[0], operands[2],
+operands[3], operands[4],
+operands[5], operands[6]));
+ if (xmm0)
+emit_insn (gen_sse4_2_pcmpestrm (operands[1], operands[2],
+operands[3], operands[4],
+operands[5], operands[6]));
+ if (flags && !(ecx || xmm0))
+emit_insn (gen_sse4_2_pcmpestr_cconly (NULL, NULL,
+ operands[2], operands[3],
+ operands[4], operands[5],
+ operands[6]));
+ if (!(flags || ecx || xmm0))
+emit_note (NOTE_INSN_DELETED);
+
+ DONE;
+}
+ [(set_attr "type" "sselog")
+ (set_attr "prefix_data16" "1")
+ (set_attr "prefix_extra" "1")
+ (set_attr "length_immediate" "1")
+ (set_attr "memory" "load")
+ (set_attr "mode" "TI")])
+
(define_insn "sse4_2_pcmpestri"
[(set (match_operand:SI 0 "register_operand" "=c,c")
(unspec:SI
@@ -9809,6 +9871,59 @@
(set_attr "memory" "none,load")
(set_attr "mode" "TI")])
+(define_insn_and_split "*sse4_2_pcmpistr_unaligned"
+ [(set (match_operand:SI 0 "register_operand" "=c")
+ (unspec:SI
+ [(match_operand:V16QI 2 "reg_not_xmm0_operand" "x")
+ (unspec:V16QI
+[(match_operand:V16QI 3 "memory_operand" "m")]
+UNSPEC_MOVU)
+ (match_operand:SI 4 "const_0_to_255_operand" "n")]
+ UNSPEC_PCMPISTR))
+ (set (match_operand:V16QI 1 "register_operand" "=Yz")
+ (unspec:V16QI
+ [(match_dup 2)
+ (unspec:V16QI [(match_dup 3)] UNSPEC_MOVU)
+ (match_dup 4)]
+ UNSPEC_PCMPISTR))
+ (set (reg:CC FLAGS_REG)
+ (unspec:CC
+ [(match_dup 2)
+ (unspec:V16QI [(match_dup 3)] UNSPEC_MOVU)
+ (match_dup 4)]
+ UNSPEC_PCMPISTR))]
+ "TARGET_SSE4_2
+ && can_create_pseudo_p ()"
+ "#"
+ "&& 1"
+ [(const_int 0)]
+{
+ int ecx = !find_regno_note (curr_insn, REG_UNUSED, REGNO (operands[0]));
+ int xmm0 = !find_regno_note (curr_insn, REG_UNUSED, REGNO (operands[1]));
+ int flags
Re: [patch] Remove NO_IMPLICIT_EXTERN_C target macro
On Mon, Jun 18, 2012 at 7:12 AM, Joseph S. Myers
wrote:
> On Mon, 18 Jun 2012, Steven Bosscher wrote:
>
>> For targets that do not define NO_IMPLICIT_EXTERN_C, GCC assumes that
>> included system headers are implicitly wrapped in 'extern "C" {...}'.
>> I could not find where this target macro was introduced, but it is
>> very old (it is already mentioned in FSFChangeLog.10 for a change in
>> 1995). AFAICT, today all supported targets have C++-compatible headers
>
> May have been introduced by:
>
> Fri Nov 5 05:48:04 1993 Richard Stallman (r...@mole.gnu.ai.mit.edu)
>
> * cccp.c (main): Handle NO_IMPLICIT_EXTERN_C.
>
>> (according to one comment, even hpux8 had C++-compatible system
>> headers :-), so NO_IMPLICIT_EXTERN_C shouldn't be necessary anymore.
>
> It was previously said that AIX headers needed it
> . That of course was AIX
> headers as of 2005; I don't know whether seven years later any version of
> AIX supported by GCC trunk still needs this.
Users continue to build recent versions of GCC on AIX 4.3, 5.1 and 5.2.
Recent versions of AIX may be C++-safe, but I do not know how to
verify that. Some headers have
extern "C" { } wrappers and other do not.
Thanks, David
gcc4.7 backport committed (PR53700)
The following patch was backported to gcc4.7. The patch solves PR53700.
It was successfully bootstrapped on x86/x86-64.
2012-06-18 Vladimir Makarov
PR rtl-optimization/53700
Backport from mainline
2012-03-29 Vladimir Makarov
* ira-color.c (setup_left_conflict_sizes_p): Process all
conflicting objects.
Index: ira-color.c
===
--- ira-color.c (revision 188736)
+++ ira-color.c (working copy)
@@ -821,7 +821,6 @@ setup_left_conflict_sizes_p (ira_allocno
node_preorder_num = node->preorder_num;
COPY_HARD_REG_SET (node_set, node->hard_regs->set);
node_check_tick++;
- curr_allocno_process++;
for (k = 0; k < nobj; k++)
{
ira_object_t obj = ALLOCNO_OBJECT (a, k);
@@ -838,12 +837,10 @@ setup_left_conflict_sizes_p (ira_allocno
conflict_data = ALLOCNO_COLOR_DATA (conflict_a);
if (! ALLOCNO_COLOR_DATA (conflict_a)->in_graph_p
- || conflict_data->last_process == curr_allocno_process
|| ! hard_reg_set_intersect_p (profitable_hard_regs,
conflict_data
->profitable_hard_regs))
continue;
- conflict_data->last_process = curr_allocno_process;
conflict_node = conflict_data->hard_regs_node;
COPY_HARD_REG_SET (conflict_node_set, conflict_node->hard_regs->set);
if (hard_reg_set_subset_p (node_set, conflict_node_set))
Re: [PATCH] boehm-gc configuration support for GNU/Hurd
> "Thomas" == Thomas Schwinge writes: Thomas> This is a backport of upstream boehm-gc configuration support for Thomas> GNU/Hurd. The equivalent thing has been used in Debian's GCC packages Thomas> since GCC 4.2 already, and I decided that *NOW* ought to be the time to Thomas> put it into the GCC tree. Ok. Tom
Re: [PATCH] Add vector cost model density heuristic
On Mon, 2012-06-11 at 13:40 +0200, Richard Guenther wrote:
> On Fri, 8 Jun 2012, William J. Schmidt wrote:
>
>
> Hmm. I don't like this patch or its general idea too much. Instead
> I'd like us to move more of the cost model detail to the target, giving
> it a chance to look at the whole loop before deciding on a cost. ISTR
> posting the overall idea at some point, but let me repeat it here instead
> of trying to find that e-mail.
>
> The basic interface of the cost model should be, in targetm.vectorize
>
> /* Tell the target to start cost analysis of a loop or a basic-block
> (if the loop argument is NULL). Returns an opaque pointer to
> target-private data. */
> void *init_cost (struct loop *loop);
>
> /* Add cost for N vectorized-stmt-kind statements in vector_mode. */
> void add_stmt_cost (void *data, unsigned n,
> vectorized-stmt-kind,
> enum machine_mode vector_mode);
>
> /* Tell the target to compute and return the cost of the accumulated
> statements and free any target-private data. */
> unsigned finish_cost (void *data);
>
> with eventually slightly different signatures for add_stmt_cost
> (like pass in the original scalar stmt?).
>
> It allows the target, at finish_cost time, to evaluate things like
> register pressure and resource utilization.
>
> Thanks,
> Richard.
I've been looking at this in between other projects. I wanted to be
sure I understood the SLP infrastructure and whether it would cause any
problems. It looks to me like it will be mostly ok. One issue I
noticed is a possible difference in the order in which SLP instructions
are analyzed and the order in which the instructions are "issued" during
transformation.
For both loop analysis and basic block analysis, SLP trees are
constructed and analyzed prior to examining other vectorizable
instructions. Their costs are calculated and stored in the SLP trees at
this time. Later, when transforming statements to their vector
equivalents, instructions in the block (or loop body) are processed in
order until the first instruction that's part of an SLP tree is
encountered. At that point, every instruction that's part of any SLP
tree is transformed; then the vectorizer continues with the remaining
non-SLP vectorizable statements.
So if we do the natural and easy thing of placing calls to add_stmt_cost
everywhere that costs are calculated today, the order that those costs
are presented to the back end model will possibly be different than the
order they are actually "emitted."
For a first cut at this, I suggest ignoring the problem other than to
document it as an opportunity for improvement. Later we could improve
it by using an add_stmt_slp_cost () interface (or adding an is_slp
flag), and another interface to be called at the time during analysis
when the SLP statements will be issued during transformation. This
would allow the back end model to queue up the SLP costs in a separate
vector and later place them in its internal structures at the
appropriate place.
It should eventually be possible to remove these fields/accessors:
* STMT_VINFO_{IN,OUT}SIDE_OF_LOOP_COST
* SLP_TREE_{IN,OUT}SIDE_OF_LOOP_COST
* SLP_INSTANCE_{IN,OUT}SIDE_OF_LOOP_COST
However, I think this should be delayed until we have the basic
infrastructure in place for the new model and well-tested.
The other issue is that we should have the model track both the inside
and outside costs if we're going to get everything into the target
model. For a first pass we can ignore this and keep the existing logic
for the outside costs. Later we should add some interfaces analogous to
add_stmt_cost such as add_stmt_prolog_cost and add_stmt_epilog_cost so
the model can track this stuff as carefully as it wants to.
So, I'd propose going at this in several phases:
(1) Add calls to the new interface without disturbing existing logic;
modify the profitability algorithms to query the new model for inside
costs. Default algorithm for the model is to just sum costs as is done
today.
(x) Add heuristics to target models as desired.
(2) Handle the SLP ordering problem.
(3) Handle outside costs in the target model.
(4) Remove the now unnecessary cost fields and the calls that set them.
Item (x) can happen anytime after item (1).
I don't think this work is terribly difficult, just a bit tedious. The
only really time-consuming aspect of it will be in very careful testing
to keep from changing existing behavior.
All comments welcome -- please let me know what you think.
Thanks,
Bill
Re: [PATCH] Add vector cost model density heuristic
On Mon, 2012-06-18 at 13:49 -0500, William J. Schmidt wrote: > On Mon, 2012-06-11 at 13:40 +0200, Richard Guenther wrote: > > On Fri, 8 Jun 2012, William J. Schmidt wrote: > > > > > > > Hmm. I don't like this patch or its general idea too much. Instead > > I'd like us to move more of the cost model detail to the target, giving > > it a chance to look at the whole loop before deciding on a cost. ISTR > > posting the overall idea at some point, but let me repeat it here instead > > of trying to find that e-mail. > > > > The basic interface of the cost model should be, in targetm.vectorize > > > > /* Tell the target to start cost analysis of a loop or a basic-block > > (if the loop argument is NULL). Returns an opaque pointer to > > target-private data. */ > > void *init_cost (struct loop *loop); > > > > /* Add cost for N vectorized-stmt-kind statements in vector_mode. */ > > void add_stmt_cost (void *data, unsigned n, > > vectorized-stmt-kind, > > enum machine_mode vector_mode); > > > > /* Tell the target to compute and return the cost of the accumulated > > statements and free any target-private data. */ > > unsigned finish_cost (void *data); By the way, I don't see much point in passing the void *data around here. Too many levels of interfaces that we'd have to pass it around in the vectorizer, so it would just sit in a static variable. Might as well let the data be wholly private to the target. > > > > with eventually slightly different signatures for add_stmt_cost > > (like pass in the original scalar stmt?). > > > > It allows the target, at finish_cost time, to evaluate things like > > register pressure and resource utilization. > > > > Thanks, > > Richard.
Re: [PATCH] GCC Ada/GNAT configuration for GNU/Hurd
On Mon, 2012-06-18 at 12:23 +0200, Arnaud Charlet wrote: > > Here is a patch that adds a basic GCC Ada/GNAT configuration for x86 > > GNU/Hurd. This has originally been created by Svante Signell for use > > with Debian's GCC 4.6 package, and now I have ported it to trunk, and > > also applied some further changes. > > > > 2012-06-16 Svante Signell > > Thomas Schwinge > > > > gcc/ada/ > > * gcc-interface/Makefile.in: Add configuration for x86 GNU/Hurd. > > * gsocket.h [__GNU__] (Has_Sockaddr_Len): #define to 1. > > * s-oscons-tmplt.c: Add checks for __GNU__ next to several __linux__ > > and linux conditionals. > > * terminals.c [__GNU__]: Don't #include . #define USE_GETPT. > > * s-osinte-gnu.ads: New file. > > * s-taprop-gnu.adb: Likewise. > > Well, the main question is: who is volunteering to maintain this code > and fix it when things break? > > Also, is s-taprop-gnu.adb really necessary? Assuming GNU Hurd provides > a posix pthread interface, then you should be using s-taprop-posix.adb, > NOT s-taprop-gnu.adb Hi, I tried with s-taprop-posix.adb earlier (among many tries), but GNU/Hurd does not seem to be fully POSIX pthread compliant yet, unfortunately. At least to my findings.
Re: [PATCH] GCC Ada/GNAT configuration for GNU/Hurd
> Hi, I tried with s-taprop-posix.adb earlier (among many tries), but > GNU/Hurd does not seem to be fully POSIX pthread compliant yet, > unfortunately. At least to my findings. Well, would be good to understnad in more details what's missing. Some trivial missing wrappers are better put in s-osinte-gnu to still allow usage/sharing of s-taprop-posix.adb Arno
[PATCH] Bad code generation: incorrect folding of TARGET_MEM_REF into a constant
Hi all,
I have tracked down a bug which results in invalid code being
generated for indexed TARGET_MEM_REF expressions during dominator
optimization.
The conditions are: accessing objects adjacent in memory in a loop (in
order to generate the TARGET_MEM_REF gimple) and optimizing this tree
item during dom optimization (to trigger folding). There might be
another set of conditions which get to the same state through a
different
The problem is that get_ref_base_and_extent() for TARGET_MEM_REF with
variable index sets `maxsize' to -1 to signal that "via index or
index2, the whole object can be reached" and returns. But before that,
if the target object is a declaration with known size and `maxsize' is
-1, it is updated, which can be taken by the caller (if `maxsize'
equals to basic `size') as possibility to fold the expression into a
constant.
Assuming I understood the code and comments right, the solution is
then to really take a quick exit in the abovementioned "indexed" case
instead of just breaking the loop and letting the rest of function
change the `maxsize' parameter.
A quick search did not reveal any existing ticket for this problem.
The bug was originally found in GCC 4.6.1 while compiling x86 code
under MinGW, which is what the attached simplified testcase is based
upon (compilation with -O1 is OK, anything higher fails).
GCC 3.4.6 seems unaffected.
Also the relevant code parts seem unchanged in current trunk.
Patched build of 4.7.1 survived bootstrap on x86_64-rhel fine.
The attached patch and all changes provided therein are released to
public domain and can be freely used or modified by anyone.
(This is my first time dealing with GCC bowels, please excuse my
superficial understanding of everything I have written above.)
Thanks,
Jiri Hruska
mem-ref-maxsize-with-index.patch
Description: Binary data
/* x86: gcc -O1 -m32 testcase.c */
#include
__attribute__((section(".rodata$int0"))) const int fooS = 0;
__attribute__((section(".rodata$int1"))) const int foo1 = 1;
__attribute__((section(".rodata$int2"))) const int foo2 = 2;
__attribute__((section(".rodata$int3"))) const int foo3 = 3;
__attribute__((section(".rodata$int4"))) const int fooE = 0;
static int ret(int v)
{
asm(""); /* Force no inlining */
return v;
}
int main(void)
{
int i = 0;
do {
int x = ret(*(&fooS + i));
int y = ret(*(&fooS + i));
if (x != y)
return 1;
i++;
} while(*(&fooS + i));
return 0;
}
Re: [PATCH, testsuite]: Fix scan-tree-dump-times argument order in gcc.dg/tree-ssa/vrp68.c.
On 06/17/2012 05:03 AM, Richard Guenther wrote: > On Sun, Jun 17, 2012 at 10:41 AM, Uros Bizjak wrote: >> Hello! >> >> The testcase still fails on x86_64-pc-linux-gnu with: >> >> FAIL: gcc.dg/tree-ssa/vrp68.c scan-tree-dump-times vrp1 "link_error" 1 >> >> since there are two calls to link_error. > > Oops. I wonder how I did not see those failures myself ... > > Richard. I'm confused about what this test is supposed to do. It uses "dg-do link" which means the compile (test for excess errors) will fail if there is a reference to link_error. There are two uses of scan-tree-dump-times for the same string in the same file, so one of those is guaranteed to fail. It looks like the scans aren't needed, and "dg-do link" is the thing that needs the xfail. Janis
Re: [PATCH 3/3] Handle const_vector in mulv4si3 for pre-sse4.1.
On 2012-06-17 11:37, Uros Bizjak wrote: > Hello! > > Please note that you will probably hit PR33329, this is the reason > that we expand multiplications after reload. Please see [1] for > further explanation. There is gcc.target/i386/pr33329.c test to cover > this issue, but it is not effective anymore since the simplification > happens at tree level. > > [1] http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00668.html Well, even with the test case changed s/*2/*12345/ so that the test case continues to use a multiply instead of devolving to a shift, does not fail. There have been a lot of changes since 2007; I might hope that the underlying bug has been fixed. r~
[PATCH, libcpp]: Use x86 __builtin_ia32_pcmpestri128 instead of asm.
Hello!
Following the patch that allows unaligned operands in pcmpestri [1],
we can substitute x86 asm in lex.c with equivalent builtin functions.
2011-06-18 Uros Bizjak
* lex.c (search_line_sse42): Use __builtin_ia32_loaddqu and
__builtin_ia32_pcmpestri128 instead of asm.
Bootstrapped and regression tested on x86_64-pc-linux-gnu SSE4.2
target. Also, I have checked that the same code is generated for
changed function.
OK for mainline?
[1] http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01189.html
Uros.
Index: lex.c
===
--- lex.c (revision 188750)
+++ lex.c (working copy)
@@ -420,6 +420,7 @@ search_line_sse42 (const uchar *s, const uchar *en
{
typedef char v16qi __attribute__ ((__vector_size__ (16)));
static const v16qi search = { '\n', '\r', '?', '\\' };
+ v16qi sv;
uintptr_t si = (uintptr_t)s;
uintptr_t index;
@@ -439,8 +440,9 @@ search_line_sse42 (const uchar *s, const uchar *en
/* ??? The builtin doesn't understand that the PCMPESTRI read from
memory need not be aligned. */
- __asm ("%vpcmpestri $0, (%1), %2"
-: "=c"(index) : "r"(s), "x"(search), "a"(4), "d"(16));
+ sv = __builtin_ia32_loaddqu ((const char *) s);
+ index = __builtin_ia32_pcmpestri128 (search, 4, sv, 16, 0);
+
if (__builtin_expect (index < 16, 0))
goto found;
Re: [RFA] dwarf2.def (DW_OP): Add DW_OP_GNU_const_index.
Ping. On Thu, Jun 14, 2012 at 12:48 PM, Doug Evans wrote: > Hi. > > Ok to commit? > > 2012-06-14 Doug Evans > > * dwarf2.def (DW_OP): Add DW_OP_GNU_const_index. > > Index: dwarf2.def > === > --- dwarf2.def (revision 188634) > +++ dwarf2.def (working copy) > @@ -588,6 +588,7 @@ > DW_OP (DW_OP_GNU_parameter_ref, 0xfa) > /* Extension for Fission. See http://gcc.gnu.org/wiki/DebugFission. */ > DW_OP (DW_OP_GNU_addr_index, 0xfb) > +DW_OP (DW_OP_GNU_const_index, 0xfc) > /* HP extensions. */ > DW_OP_DUP (DW_OP_HP_unknown, 0xe0) /* Ouch, the same as > GNU_push_tls_address. */ > DW_OP (DW_OP_HP_is_value, 0xe1)
[PATCH 4/4] - Merging gdc (GNU D Compiler) into gcc
[PATCH 4/4]: Add D frontend and library to build - configure - configure.ac - Makefile.def - Makefile.in Add mention of D compiler and Phobos in documentation - gcc/doc/frontends.texi - gcc/doc/install.texi - gcc/doc/invoke.texi - gcc/doc/sourcebuild.texi - gcc/doc/standards.texi Backend support for D compiler - gcc/config/rs6000/rs6000.c - gcc/dwarf2out.c - gcc/gcc.c -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; gdc_gcc.patch.gz Description: GNU Zip compressed data
[PATCH, gdc] - Merging gdc (GNU D Compiler) into gcc
Hi, Seems that I can't upload the files individually due to a size limit, so I've put the files up on my site. Sorry for any initial noise. Long story short: So I have been working on this for quite some time, and now I feel it is approaching some state of readiness for inclusion. Any feedback or advice to help push this little project along would be greatly appreciated. Thanks. Former discussion about possible inclusion: http://gcc.gnu.org/ml/gcc/2011-10/msg00037.html Current development of GDC is hosted on github: https://github.com/D-Programming-GDC/GDC Summary of patches These series of patches are for the D compiler frontend for inclusion into GCC. http://www.gdcproject.org/files/gdc_frontend.patch.gz http://www.gdcproject.org/files/gdc_libphobos.patch.gz http://www.gdcproject.org/files/gdc_testsuite.patch.gz http://www.gdcproject.org/files/gdc_gcc.patch.gz [PATCH 1/4]: The D compiler frontend - gcc/d [PATCH 2/4]: Phobos and the D runtime library - gcc/libphobos - gcc/libphobos/libdruntime [PATCH 3/4]: The D compiler testsuite - gcc/testsuite/gdc.exp - gcc/testsuite/lib/gdc-dg.exp - gcc/testsuite/lib/gdc.exp [PATCH 4/4]: Add D frontend and library to build - configure - configure.ac - Makefile.def - Makefile.in Add mention of D compiler and Phobos in documentation - gcc/doc/frontends.texi - gcc/doc/install.texi - gcc/doc/invoke.texi - gcc/doc/sourcebuild.texi - gcc/doc/standards.texi Backend support for D compiler - gcc/config/rs6000/rs6000.c - gcc/dwarf2out.c - gcc/gcc.c Again, sorry for the initial noise, I look forwarded to future discussions. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
fix libstdc++/53678 - namespace pollution on NetBSD
This fixes a regression on NetBSD.
2012-06-18 Jörg Sonnenberger
Jonathan Wakely
PR libstdc++/53678
* config/os/bsd/netbsd/ctype_base.h: Check for _CTYPE_U.
* testsuite/22_locale/ctype_base/53678.cc: New.
Tested x86_64-unknown-netbsd5.1, committed to trunk, 4.7 and 4.6 to follow
commit ec3a5e13dc6d1e3c1cf963baefbcf9fb89d15873
Author: Jonathan Wakely
Date: Fri Jun 15 00:53:21 2012 +0100
2012-06-18 Jörg Sonnenberger
Jonathan Wakely
PR libstdc++/53678
* config/os/bsd/netbsd/ctype_base.h: Check for _CTYPE_U.
* testsuite/22_locale/ctype_base/53678.cc: New.
diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
index d75cb79..cd654d6 100644
--- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
+++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
@@ -1,6 +1,6 @@
// Locale support -*- C++ -*-
-// Copyright (C) 2000, 2009 Free Software Foundation, Inc.
+// Copyright (C) 2000, 2009, 2011, 2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
@@ -31,8 +31,6 @@
// anon...@anoncvs.netbsd.org:/cvsroot/basesrc/include/ctype.h
// See www.netbsd.org for details of access.
-#include
-
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -47,7 +45,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// on the mask type. Because of this, we don't use an enum.
typedef unsigned char mask;
-#if __NetBSD_Version__ < 599004100
+#ifndef _CTYPE_U
static const mask upper= _U;
static const mask lower= _L;
static const mask alpha= _U | _L;
diff --git a/libstdc++-v3/testsuite/22_locale/ctype_base/53678.cc
b/libstdc++-v3/testsuite/22_locale/ctype_base/53678.cc
new file mode 100644
index 000..e4a9f07
--- /dev/null
+++ b/libstdc++-v3/testsuite/22_locale/ctype_base/53678.cc
@@ -0,0 +1,28 @@
+// Copyright (C) 2012 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [RFA] dwarf2.def (DW_OP): Add DW_OP_GNU_const_index.
On 2012-06-14 12:48, Doug Evans wrote: > Hi. > > Ok to commit? > > 2012-06-14 Doug Evans > > * dwarf2.def (DW_OP): Add DW_OP_GNU_const_index. Ok. r~
Re: [PATCH, libcpp]: Use x86 __builtin_ia32_pcmpestri128 instead of asm.
On 2012-06-18 13:19, Uros Bizjak wrote:
>/* ??? The builtin doesn't understand that the PCMPESTRI read from
>memory need not be aligned. */
> - __asm ("%vpcmpestri $0, (%1), %2"
> - : "=c"(index) : "r"(s), "x"(search), "a"(4), "d"(16));
> + sv = __builtin_ia32_loaddqu ((const char *) s);
> + index = __builtin_ia32_pcmpestri128 (search, 4, sv, 16, 0);
> +
Surely the comment can be removed too then?
r~
Re: [wwwdocs] Update coding conventions for C++
This patch updates the coding conventions to C++. The primary
source file is codingconventions.html. The coding conventions now
refer to a new file, codingrationale.html, providing the rationale
for some of the C++ conventions. The two files in question are
attached whole for your convenience.
The "Portability" section has some changes. The "Miscellaneous
Conventions" section moves later and become part of the "C and C++
Language Conventions" section. The bulk of the change consists of
additions to the "C and C++ Language Conventions" section and the
addition of an entirely new "C++ Language Conventions" section.
I added a table of contents.
I have removed lines from the around the html tag, as they are
causing my mail to be rejected. If you get this message twice, you
now know why. :-)
Please review.
Index: codingconventions.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.66
diff -u -u -r1.66 codingconventions.html
--- codingconventions.html 19 Feb 2012 00:45:34 - 1.66
+++ codingconventions.html 18 Jun 2012 22:04:49 -
@@ -1,4 +1,8 @@
GCC Coding Conventions
@@ -15,8 +19,56 @@
code to follow these conventions, it is best to send changes to follow
the conventions separately from any other changes to the code.
+
+Documentation
+ChangeLogs
+Portability
+Makefiles
+Testsuite Conventions
+Diagnostics Conventions
+Spelling, terminology and markup
+C and C++ Language Conventions
+Compiler Options
+Language Use
+Assertions
+Character Testing
+Error Node Testing
+Parameters Affecting Generated Code
+Inlining Functions
+Formatting
Conventions
+Line
Length
+Names
+Expressions
+Function Calls
+C++ Language Conventions
+Language Use
+Variable Definitions
+Struct Definitions
+Class Definitions
+Constructors and Destructors
+Conversions
+Overloading Functions
+Overloading Operators
+Default Arguments
+Inlining Functions
+Templates
+Namespaces
+RTTI
and dynamic_cast
+Other Casts
+Exceptions
+The Standard Library
+Formatting
Conventions
+Names
+Struct Definitions
+Class Definitions
+Class Member Definitions
+Templates
+Extern "C"
+Namespaces
+
-Documentation
+
+Documentation
Documentation, both of user interfaces and of internals, must be
maintained and kept up to date. In particular:
@@ -43,7 +95,7 @@
-ChangeLogs
+ChangeLogs
GCC requires ChangeLog entries for documentation changes; for the web
pages (apart from java/ and libstdc++/) the CVS
@@ -71,20 +123,61 @@
java/58 is the actual number of the PR) at the top
of the ChangeLog entry.
-Portability
+Portability
There are strict requirements for portability of code in GCC to
-older systems whose compilers do not implement all of the ISO C standard.
-GCC requires at least an ANSI C89 or ISO C90 host compiler, and code
-should avoid pre-standard style function definitions, unnecessary
-function prototypes and use of the now deprecated @code{PARAMS} macro.
+older systems whose compilers do not implement all of the
+latest ISO C and C++ standards.
+
+
+
+The directories
+gcc, libcpp and fixincludes
+may use C++03.
+They may also use the long long type
+if the host C++ compiler supports it.
+Furthermore,
+these directories should also be compatible with C++11.
+
+
+
+The directories libiberty and libdecnumber must use C
+and require at least an ANSI C89 or ISO C90 host compiler.
+C code should avoid pre-standard style function definitions, unnecessary
+function prototypes and use of the now deprecated PARAMS
macro.
See http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/gcc/README.Portability?content-type=text/plain&only_with_tag=HEAD";>README.Portability
for details of some of the portability problems that may arise. Some
of these problems are warned about by gcc -Wtraditional,
which is included in the default warning options in a bootstrap.
-(Code outside the C front end is only compiled by GCC, so such
-requirements do not apply to it.)
+
+
+
+Every version of GCC must be buildable by the previous version of GCC.
+This rule helps ensure smooth development of the next version.
+However, it doesn't help so much when you do not have a previous version.
+So, the more important rule is that every version must bootstrap,
+which means that version can develop itself.
+Note that this statement does not preclude
+a need to build GCC with other compilers.
+
+
+
+We will periodically pick a stable version of GCC,
+and require that that version of GCC be able to build
+all versions of GCC up to and including the next stable version.
+E.g., we may decide that all newer versions of GCC
+should be buildable with GCC 4.3.5.
+
+
+
+It is desirable that it be poss
Reorganized documentation for warnings -- attempt 2
Some friendly users in the gcc irc chat informed me that I may be more likely to get a review for my patch if it weren't a 100 KiB file. This is my attempt at making the patch a little easier to read. I'm not sure how important it is for documentation, but I have already sent in my copyright assignment forms. ChangeLog text: Documentation: Reorganized warning options for invoking GCC. Warning options turned on by -Wall, -Wextra, and -Wpedantic are now grouped together. Note that some of the earlier patches don't make sense on their own. They require the later patches for the text to flow. How to read the patches: 1-rearrange.diff is a reorganization-only patch. It consists entirely of adding a few new lines and moving other lines around. If you ignore whitespace-only lines, you should be able to use sort on a patched version of invoke.texi and the original and not have any differences. I changed the top of the page to be an overview of -Wall, then -Wextra, then -Wpedantic. After that, individual warnings are listed with all of the options turned on by -Wall first, then -Wextra, then -Wpedantic, then warnings not turned on by any of those, and finally negative warning options to turn off the defaults. The one intentional exception is -Wformat=2, which I put right after -Wformat, even though it is not turned on by -Wall. I made a note that -Wformat=2 is not turned on by any other option. 2-turned-on-by-other.diff applies uniform formatting to all options that are turned on by other options, and explicitly specifies it for those options. For instance, all warnings turned on by -Wall state in their description that they are turned on by -Wall. 3-explicit-Wpedantic lists all warnings that are turned on by -Wpedantic in the description for that meta-option. 4-0-uniform-turn-off.diff and 4-1-uniform-turn-off.diff list the negative option for all warnings that are on by default and the positive version for all other warnings. This is how the overview specifies all warnings are, and most warnings are like that. This just brings some consistency to the few outliers. 5-Wunused.diff rewords the description of -Wunused to list out all warnings turned on by it. 6-Wstrict-aliasing.diff removes some redundancy. -Wstrict-aliasing previously repeated almost all of the same information as -Wstrict-aliasing=N. I combined them in the same manner as -Wstrict-overflow. 7-Wformat.diff is a little more explicit with what Wformat turns on (and what it doesn't). 8-Wformat-2-note.diff mentions that Wformat=2 is not turned on by any other warning option. 1-rearranage.diff.bz2 Description: BZip2 compressed data 2-turned-on-by-other.diff Description: Binary data 3-explicit-Wpedantic.diff Description: Binary data 4-0-uniform-turn-off.diff Description: Binary data 4-1-uniform-turn-off.diff Description: Binary data 5-Wunused.diff Description: Binary data 6-Wstrict-aliasing.diff Description: Binary data 7-Wformat.diff Description: Binary data 8-Wformat-2-note.diff Description: Binary data
Re: [PATCH] Improve pattern recognizer for division by constant (PR tree-optimization/51581)
On 2012-06-14 13:58, Jakub Jelinek wrote: > + if (!supportable_widening_operation (WIDEN_MULT_EXPR, last_stmt, > +vecwtype, vectype, > +&dummy, &dummy, &dummy_code, > +&dummy_code, &dummy_int, &dummy_vec)) > +return NULL; It would be nice to be able to handle high-part multiplies as well, e.g. VEC_WIDEN_MULT_HI_EXPR. Which is what Altivec provides, and not VEC_WIDEN_MULT. I note that the sse pattern for mul3_highpart (pmulhuw) is apparently mis-named under this scheme. r~
[testsuite] profopt.exp and friends: use expected list of options
There are tests in g++.tree-prof that have non-unique lines in test
summaries for scan-*-dump checks. Investigation showed that these tests
were being run multiple times, for a list of options that had leaked
over from another set of profile-directed optimization tests. This
patch doesn't fix duplicate lines for checks in profiled tests that are
run multiple times, but it does avoid the problem and, in so doing, fix
tests that use profopt.exp so they are run with the correct sets of
options.
Without this patch, tests in g++.dg/tree-prof are run with
[ { -g } { -O0 } { -O1 } { -O2 } { -O3 } { -O3 -g } { -Os } ] instead
of the expected [list {}]. Each test provides its own options, so
the ones from PROFOPT_OPTIONS were ignored.
Tests gcc.misc-tests/bprob*.c were supposed to be run with a set of
options that was instead overridden by an empty list. This patch makes
it use [ { -O2 } {-O3 } ] so the options tested there will get some
coverage with optimization, although not as much as originally planned
when the tests were added years and years ago.
The other sets of tests that use profopt.exp continue to be tested with
the same options they've been using.
OK for mainline?
Janis
2012-06-18 Janis Johnson
* lib/profopt.exp: Make prof_option_list local to profopt-execute.
* g++.dg/tree-prof/tree-prof.exp (PROFOPT_OPTIONS): Define after
including profopt.opt; save and restore existing value.
* g++.dg/bprob/bprob.exp: Likewise.
* gcc.dg/matrix/matrix.exp: Likewise.
* gcc.dg/tree-prof/tree-prof.exp: Likewise.
* gcc.misc-tests/bprob.exp: Likewise; also replace formerly-ignored
PROFOPT_OPTIONS.
Index: lib/profopt.exp
===
--- lib/profopt.exp (revision 188753)
+++ lib/profopt.exp (working copy)
@@ -64,8 +64,6 @@
{ -Os } ]
}
-set prof_option_list $PROFOPT_OPTIONS
-
#
# profopt-cleanup -- remove profiling or performance results files.
#
@@ -215,7 +213,7 @@
#
proc profopt-execute { src } {
global srcdir tmpdir
-global prof_option_list
+global PROFOPT_OPTIONS
global tool profile_option feedback_option prof_ext perf_ext perf_delta
global generate_final_code use_final_code
global verbose
@@ -227,6 +225,12 @@
error "No feedback option specified for second compile."
}
+# Use the default option list or one defined for a set of tests.
+if ![info exists PROFOPT_OPTIONS] {
+ error "PROFOPT_OPTIONS is not defined"
+}
+set prof_option_list $PROFOPT_OPTIONS
+
regsub "(?q)$srcdir/" $src "" testcase
# If we couldn't rip $srcdir out of `src' then just do the best we can.
# The point is to reduce the unnecessary noise in the logs. Don't strip
Index: g++.dg/tree-prof/tree-prof.exp
===
--- g++.dg/tree-prof/tree-prof.exp (revision 188753)
+++ g++.dg/tree-prof/tree-prof.exp (working copy)
@@ -29,9 +29,6 @@
set tool g++
set prof_ext "gcda"
-# Override the list defined in profopt.exp.
-set PROFOPT_OPTIONS [list {}]
-
if $tracelevel then {
strace $tracelevel
}
@@ -39,6 +36,10 @@
# Load support procs.
load_lib profopt.exp
+# Save and override the default list defined in profopt.exp.
+set treeprof_save_profopt_options $PROFOPT_OPTIONS
+set PROFOPT_OPTIONS [list {}]
+
# These are globals used by profopt-execute. The first is options
# needed to generate profile data, the second is options to use the
# profile data.
@@ -52,3 +53,5 @@
}
profopt-execute $src
}
+
+set PROFOPT_OPTIONS $treeprof_save_profopt_options
Index: g++.dg/bprob/bprob.exp
===
--- g++.dg/bprob/bprob.exp (revision 188753)
+++ g++.dg/bprob/bprob.exp (working copy)
@@ -33,7 +33,11 @@
strace $tracelevel
}
-# Override the list defined in profopt.exp.
+# Load support procs.
+load_lib profopt.exp
+
+# Save and override the default list defined in profopt.exp.
+set bprob_save_profopt_options $PROFOPT_OPTIONS
set PROFOPT_OPTIONS [list \
{ -g } \
{ -O0 } \
@@ -47,9 +51,6 @@
strace $tracelevel
}
-# Load support procs.
-load_lib profopt.exp
-
set profile_options "-fprofile-arcs"
set feedback_options "-fbranch-probabilities"
@@ -63,3 +64,5 @@
profopt-execute $src
}
}
+
+set PROFOPT_OPTIONS $bprob_save_profopt_options
Index: gcc.dg/matrix/matrix.exp
===
--- gcc.dg/matrix/matrix.exp(revision 188753)
+++ gcc.dg/matrix/matrix.exp(working copy)
@@ -39,9 +39,6 @@
set tool gcc
set prof_ext "gcda"
-# Override the list defined in profopt.exp.
-set PROFOPT_OPTIONS [list {}]
-
if $tracelevel then {
strace $tracelevel
}
@@ -49,6 +46,10 @@
# Load support procs.
load_lib profopt.exp
+# Save and override the default list defined in profopt.exp.
+set matr
Re: Make timevar phases mutually exclusive. (issue6302064)
On 6/13/12, Diego Novillo wrote: > On 12-06-13 08:46 , Diego Novillo wrote: > > The LTO bits are fine. I would prefer if an FE maintainer takes > > a second look over the other bits. Jason, Joseph? > > Incidentally, could you please test it with an LTO-enabled bootstrap? > > $ ../src/configure --with-build-config=bootstrap-lto > --enable-languages=c++,fortran > $ make profiledbootstrap > > If you cut and paste one of the -flto compiles you see during > bootstrap, you can add -ftime-report to it to make sure that the > LTO timers are properly setup. I had to make a slight adjustment here. LTO runs as a front-end, and the parse timers are automatically started for the front ends. But LTO is not parsing. Rather than change every front end to handle those timers, I turned the timers off and then back on again within LTO. Committed. -- Lawrence Crowl
[4.6][ARM] Backport "MCR Not available in Thumb1"
Backporting trunk r179979 OK for 4.6? Backported from mainline 2011-10-14 David Alan Gilbert PR target/48126 * config/arm/arm.c (arm_output_sync_loop): Move label before barrier. Index: gcc/config/arm/arm.h === --- gcc/config/arm/arm.h(revision 188331) +++ gcc/config/arm/arm.h(working copy) @@ -294,7 +294,8 @@ #define TARGET_HAVE_DMB(arm_arch7) /* Nonzero if this chip implements a memory barrier via CP15. */ -#define TARGET_HAVE_DMB_MCR(arm_arch6k && ! TARGET_HAVE_DMB) +#define TARGET_HAVE_DMB_MCR(arm_arch6 && ! TARGET_HAVE_DMB \ +&& ! TARGET_THUMB1) /* Nonzero if this chip implements a memory barrier instruction. */ #define TARGET_HAVE_MEMORY_BARRIER (TARGET_HAVE_DMB || TARGET_HAVE_DMB_MCR)
Re: [PATCH, libcpp]: Use x86 __builtin_ia32_pcmpestri128 instead of asm.
On Tue, Jun 19, 2012 at 12:07 AM, Richard Henderson wrote:
> On 2012-06-18 13:19, Uros Bizjak wrote:
>> /* ??? The builtin doesn't understand that the PCMPESTRI read from
>> memory need not be aligned. */
>> - __asm ("%vpcmpestri $0, (%1), %2"
>> - : "=c"(index) : "r"(s), "x"(search), "a"(4), "d"(16));
>> + sv = __builtin_ia32_loaddqu ((const char *) s);
>> + index = __builtin_ia32_pcmpestri128 (search, 4, sv, 16, 0);
>> +
>
>
> Surely the comment can be removed too then?
I'm not sure there. The builtin, as defined, expects V16QI operand
with xm constraint. Using:
int test (const char *s1)
{
const v16qi *p = (const v16qi *)(unsigned long) s1;
return __builtin_ia32_pcmpistri128 (*p, ...);
}
will generate movdqa before pcmpistri.
With x86 pcmp[ie]str patch, we trick gcc to pass unaligned memory to
the pcmp[ie]str RTX, but we still need __builtin_ia32_loaddqu in front
of __builtin_ia32_pcmpestri128.
Uros.
Re: [PATCH 2/3] Add XLP-specific atomic instructions and tweaks.
On 16/06/2012, at 7:45 PM, Richard Sandiford wrote:
> Maxim Kuvyrkov writes:
>> Updated patch attached. Any further comments?
>
> It's due to my bad explanation, sorry, but this isn't what I meant.
> The two main changes I was looking for were:
>
> 1) Your pattern uses:
>
>[(mem:GPR (match_operand:P 1 "register_operand" "d"))]
>
> Instead, we should define a new memory predicate/constraint pair
> for memories that only accept register addresses. I.e. there
> should be a new predicate to go alongside things like
> memory_operand and stack_operand, except that the new one would
> be even more restrictive in the set of addresses that it allows.
> mem_reg_operand seems as good a name as any, but I'm not wedded
> to a particular name.
>
> The new memory constraint would likewise go alongside "m", "W", etc.,
> except that (like the predicate) it too would only allow register
> addresses. We're running low on constraint latters, so a two-operand
> one like "ZR" might be OK. We can then use "Z" as a prefix for other
> MIPS-specific memory and address constraints in future.
>
> The atomic_exchange and atomic_fetch_add expanders should use
> the code I quoted in the earlier message to force the original
> memory_operand into this more restrictive form:
>
>if (!mem_reg_operand (operands[1], mode))
> {
>addr = force_reg (Pmode, XEXP (operands[1], 0));
>operands[1] = replace_equiv_address (operands[1], addr);
> }
>
> The reason is that hard-coding (mem ...) in named define_insns
> (i.e. those with a gen_* function) is usually a mistake. We end
> up discarding the original MEM and losing track of its MEM_ATTRs.
>
> (Note that this change means we don't need separate Pmode == SImode
> and Pmode == DImode patterns.)
>
> 2) Your pattern has:
>
> (match_operand:GPR 2 "arith_operand" "0")
>
> to match:
>
> (match_operand:GPR 0 "register_operand" "=d")
>
> Operand 2 doesn't accept constants, so it should be a register_operand
> rather than an arith_operand. Then the atomic_exchange and
> atomic_fetch_add
> expanders should use force_reg to turn _their_ arith_operands into
> register_operands before calling gen_atomic_fetch_add_ldadd
> and gen_atomic_fetch_swap.
>
> Your new comment says:
>
> /* Spill the address to a register upfront to simplify reload's job. */
>
> But this isn't about making reload's job easier. Reload can cope just
> fine with the arith_operand above and would cope just fine with:
>
> (match_operand ... "memory_operand" "ZR")
>
> with ZR defined as above. Instead. we're trying to describe the
> instruction as accurately as possible so that the pre-reload passes
> (including IRA) are in a position to make good optimisation decisions.
> They're less able to do that if patterns claim to accept more things
> than they actually do.
>
> I.e. it's the same reason that we don't just use "general_operand"
> for all reloadable rvalues and "nonimmediate_operand" for all
> reloadable lvalues. Trying to use accurate predicates is such
> standard practice that I think it'd be better to drop the comment here.
> Having one gives the impression that we're trying to cope with some
> special case, which AFAICT we're not.
Richard,
Thank you for a thoughtful write-up. I really appreciate the time you are
taking to educate me.
I've incorporated yours and Richard H.'s comments (stole pieces from ARM port)
and attached is the updated patch.
The only other change that I made that was not in your comments is the addition
of "b" mips_print_operand specifier. The LDADD and SWAP instructions accept
their address as a plain register without parenthesis, so I've added the
specifier to skip outputting parenthesis.
Any further comments?
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
0002-Add-XLP-specific-atomic-instructions-and-tweaks.patch
Description: Binary data
