[patch libffi]: Make sure code is position-independent for x64 targets
Hi, this patch fixes the Win64-code so that we use only pc-relative addressing. This is of importance if code gets linked to an pe-image with an image-base above 2GB. ChangeLog 2013-03-22 Kai Tietz kti...@redhat.com * src/x86/win64.S: Make use of ffi_closure_win64_inner symbol pc-relative. Tested for x86_64-w64-mingw32, and for upcoming x86_64-pc-cygwin target. Ok for apply? Regards, Kai Index: src/x86/win64.S === --- src/x86/win64.S (Revision 196898) +++ src/x86/win64.S (Arbeitskopie) @@ -295,7 +295,7 @@ mov %rax, %rcx # context is first parameter mov %rsp, %rdx # stack is second parameter add $48, %rdx # point to start of arguments - mov $SYMBOL_NAME(ffi_closure_win64_inner), %rax + leaqSYMBOL_NAME(ffi_closure_win64_inner)(%rip), %rax callq *%rax # call the real closure function add $40, %rsp movq%rax, %xmm0 # If the closure returned a float,
[patch i386]: Treat dllimported symbol as external in predicates
Hi, A dllimported symbol is always external. So treat that proper in local_symbolic_operand. ChangeLog 2013-03-22 Kai Tietz kti...@redhat.com * config/i386/predicates.md (local_symbolic_operand): Interprete dll-imported symbols as none-local. Tested for x86_64-w64-mingw32, i686-w64-mingw32, and upcoming x86_64-pc-cygwin. Ok for apply? Regards, Kai Index: gcc/config/i386/predicates.md === --- gcc/config/i386/predicates.md (Revision 196898) +++ gcc/config/i386/predicates.md (Arbeitskopie) @@ -436,6 +436,9 @@ if (SYMBOL_REF_TLS_MODEL (op)) return false; + /* Dll-imported symbols are always external. */ + if (TARGET_DLLIMPORT_DECL_ATTRIBUTES SYMBOL_REF_DLLIMPORT_P (op)) +return false; if (SYMBOL_REF_LOCAL_P (op)) return true; -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination
[patch mingw]: Make POSIX-printf for mingw-based builds default
Hi, this patch enables the POSIX-printf variant for mingw-hosts by default. ChangeLog 2013-03-22 Kai Tietz kti...@redhat.com * config/i386/xm-mingw32.h (__USE_MINGW_ANSI_STDIO): Enable POSIX-printf for mingw-hosted builds. Tested for i686-w64-mingw32, and x86_64-w64-mingw32. I will apply tomorrow, if there aren't any objections by other Windows-maintainers. Regards, Kai Index: gcc/config/i386/xm-mingw32.h === --- gcc/config/i386/xm-mingw32.h(Revision 196898) +++ gcc/config/i386/xm-mingw32.h(Arbeitskopie) @@ -29,6 +29,12 @@ along with GCC; see the file COPYING3. If not see /* The st_ino field of struct stat is always 0. */ #define HOST_LACKS_INODE_NUMBERS +#ifdef __MINGW32__ +#undef __USE_MINGW_ANSI_STDIO +#define __USE_MINGW_ANSI_STDIO 1 +#else /* MSVCRT does not support the ll format specifier for printing long long values. Instead, we use I64. */ #define HOST_LONG_LONG_FORMAT I64 +#endif +
[patch java]: Avoid looping over the end_params_node in put_decl_node
Hi,
this patch makes sure we don't walk in put_decl_node of the
end_params_node element.
ChangeLog
2013-03-22 Kai Tietz kti...@redhat.com
* lang.c (put_decl_node): Don't iterate over end_params_node.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
Index: gcc/java/lang.c
===
--- gcc/java/lang.c (Revision 196898)
+++ gcc/java/lang.c (Arbeitskopie)
@@ -419,7 +419,8 @@ put_decl_node (tree node, int verbosity)
if (TREE_CODE (TREE_TYPE (node)) == METHOD_TYPE)
args = TREE_CHAIN (args);
put_decl_string ((, 1);
- for ( ; args != end_params_node; args = TREE_CHAIN (args), i++)
+ for ( ; args != NULL_TREE args != end_params_node;
+ args = TREE_CHAIN (args), i++)
{
if (i 0)
put_decl_string (,, 1);
Re: [Patch, libfortran] PR 52512 - Cannot match namelist object name
On Fri, Mar 22, 2013 at 12:52 AM, Tilo Schwarz t...@tilo-schwarz.de wrote: Hi, this patch fixes PR 52512. Built and regtested on Linux 3.2.0-4-686-pae. Ok for trunk (4.9). Thanks for the patch! PS: Common procedure is to report the target triplet you regtested on rather than the Linux kernel version. You can see your target triplet e.g. with gfortran -v 21 /dev/null |grep Target (For me, that's x86_64-unknown-linux-gnu, since you seem to have a 32-bit Linux system I assume it'll be something like i686-pc-linux-gnu) Also, please copy-paste the changelog inline into your message rather than as part of the diff file. -- Janne Blomqvist
[patch testsuite]: g++.dg
Hi,
this patch fixes an LLP64 issue in g++.dg's testsuite.
ChangeLog
2013-03-22 Kai Tietz kti...@redhat.com
* g++.dg/torture/20121105-1.C: Adjust for LLP64 targets.
Ok for apply?
Regards,
Kai
Index: gcc/testsuite/g++.dg/torture/20121105-1.C
===
--- gcc/testsuite/g++.dg/torture/20121105-1.C (Revision 196898)
+++ gcc/testsuite/g++.dg/torture/20121105-1.C (Arbeitskopie)
@@ -2,6 +2,8 @@
// Reported by Remi Vanicat vani...@debian.org
// Reduced testcase by Markus Trippelsdorf mar...@trippelsdorf.de
+__extension__ typedef __INTPTR_TYPE__ intptr_t;
+
struct A;
struct B
{
@@ -25,7 +27,7 @@ struct D
};
D c(0);
-const long d = (long)c;
+const intptr_t d = (intptr_t)c;
B *const e = (B *)d;
static bool
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
On Mar 21 2013, Joseph S. Myers wrote: now that the Fortran frontend is C++ we can use the primitive bool type instead of inventing our own. Well, C99's bool (_Bool) was already used before. ... Er, that is making a serious mistake or, at least, running the risk of one. C++'s bool and C99's _Bool are NOT compatible types. The UK tried to get _Bool either made compatible with C++ or (preferably) dropped, but failed in both. They have been ABI-compatible in GCC ever since I implemented C99 _Bool That is another matter entirely. The code of gcc/gfortran is supposed to be compilable with other compilers, and it is foolish to make unnecessary assumptions by relying on undefined behaviour. The simple facts are that C++ does NOT define bool to be compatible with _Bool, and there are enough differences in specification and semantics to make it likely that they are not the same in at least some compilers. This mess has caused and still causes no end of problems for Fortran interoperability and in standards like MPI. Regards, Nick Maclaren.
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
N.M. Maclaren n...@cam.ac.uk writes: That is another matter entirely. The code of gcc/gfortran is supposed to be compilable with other compilers, and it is foolish to make unnecessary assumptions by relying on undefined behaviour. The simple facts are that C++ does NOT define bool to be compatible with _Bool, and there are enough differences in specification and semantics to make it likely that they are not the same in at least some compilers. This mess has caused and still causes no end of problems for Fortran interoperability and in standards like MPI. Er, maybe so, but is there actually an issue in _this_ case? From original message, it sounds like these are internal compiler interfaces, so all that matters is that they be self-consistent, and there's no external ABI involved... So as long as all the code in question is compiled with C++ and uses C++ bool, or is compiled with C99 and uses _Bool, and doesn't use any functionality that isn't in the intersection of those two types, there shouldn't be any problem, right? -miles -- Congratulation, n. The civility of envy.
[patch libstdc++ testsuite]: Add new option dg-additional-options and make use of it for mingw targets
Hi,
this patch adds option dg-additional-options for libstdc++-v3's testsuite and
make use of this option for some mingw-tests. Those tests are just possible for
pe-coff for static-library use. The shared version for pe-coff is
finally linked and therefore
no override of operators is possible within DLL.
ChangeLog
2013-03-22 Kai Tietz kti...@redhat.com
* 18_support/50594.cc: For mingw-targets use only static
libstdc++-version.
* 19_diagnostics/error_category/operators/equal.cc
* 19_diagnostics/error_code/cons/1.cc
* 19_diagnostics/error_code/operators/bool.cc
* 19_diagnostics/error_code/operators/equal.cc
* 19_diagnostics/error_code/operators/not_equal.cc
* 19_diagnostics/error_condition/cons/1.cc
* 19_diagnostics/error_condition/operators/bool.cc
* 19_diagnostics/error_condition/operators/equal.cc
* 19_diagnostics/error_condition/operators/not_equal.cc
* 23_containers/set/requirements/exception/basic.cc
* 26_numerics/headers/cmath/c99_classification_macros_c.cc
* lib/dg-options.exp (dg-additional-options): New option.
Tested for i686-w64-mingw32, x86_64-w64-mingw32,
x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
Index: libstdc++-v3/testsuite/18_support/50594.cc
===
--- libstdc++-v3/testsuite/18_support/50594.cc (Revision 196898)
+++ libstdc++-v3/testsuite/18_support/50594.cc (Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options -fwhole-program }
+// { dg-additional-options -static-libstdc++ { target *-*-mingw* } }
// Copyright (C) 2011-2013 Free Software Foundation, Inc.
//
Index: libstdc++-v3/testsuite/19_diagnostics/error_category/operators/equal.cc
===
--- libstdc++-v3/testsuite/19_diagnostics/error_category/operators/equal.cc
(Revision
196898)
+++ libstdc++-v3/testsuite/19_diagnostics/error_category/operators/equal.cc
(Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options -std=gnu++0x }
+// { dg-additional-options -static-libgcc { target *-*-mingw* } }
// 2007-08-22 Benjamin Kosnik b...@redhat.com
// Copyright (C) 2007-2013 Free Software Foundation, Inc.
Index: libstdc++-v3/testsuite/19_diagnostics/error_code/cons/1.cc
===
--- libstdc++-v3/testsuite/19_diagnostics/error_code/cons/1.cc (Revision
196898)
+++ libstdc++-v3/testsuite/19_diagnostics/error_code/cons/1.cc (Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options -std=gnu++0x }
+// { dg-additional-options -static-libstdc++ { target *-*-mingw* } }
// 2007-08-22 Benjamin Kosnik b...@redhat.com
// Copyright (C) 2007-2013 Free Software Foundation, Inc.
Index: libstdc++-v3/testsuite/19_diagnostics/error_code/operators/bool.cc
===
--- libstdc++-v3/testsuite/19_diagnostics/error_code/operators/bool.cc
(Revision
196898)
+++ libstdc++-v3/testsuite/19_diagnostics/error_code/operators/bool.cc
(Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options -std=gnu++0x }
+// { dg-additional-options -static-libstdc++ { target *-*-mingw* } }
// 2007-08-22 Benjamin Kosnik b...@redhat.com
// Copyright (C) 2007-2013 Free Software Foundation, Inc.
Index: libstdc++-v3/testsuite/19_diagnostics/error_code/operators/equal.cc
===
--- libstdc++-v3/testsuite/19_diagnostics/error_code/operators/equal.cc
(Revision
196898)
+++ libstdc++-v3/testsuite/19_diagnostics/error_code/operators/equal.cc
(Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options -std=gnu++0x }
+// { dg-additional-options -static-libstdc++ { target *-*-mingw* } }
// 2007-08-22 Benjamin Kosnik b...@redhat.com
// Copyright (C) 2007-2013 Free Software Foundation, Inc.
Index: libstdc++-v3/testsuite/19_diagnostics/error_code/operators/not_equal.cc
===
--- libstdc++-v3/testsuite/19_diagnostics/error_code/operators/not_equal.cc
(Revision
196898)
+++ libstdc++-v3/testsuite/19_diagnostics/error_code/operators/not_equal.cc
(Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options -std=gnu++0x }
+// { dg-additional-options -static-libstdc++ { target *-*-mingw* } }
// 2007-08-22 Benjamin Kosnik b...@redhat.com
// Copyright (C) 2007-2013 Free Software Foundation, Inc.
Index: libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/1.cc
===
--- libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/1.cc
(Revision
196898)
+++ libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/1.cc
(Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options -std=gnu++0x }
+// { dg-additional-options -static-libstdc++ { target *-*-mingw* } }
// Copyright (C) 2008-2013 Free Software Foundation, Inc.
//
Index:
[patch libgcc]: Prepare cygwin.S file to share code with cygwin64
Hi, this patch replaces use of _WIN64 by __x86_64__ so mingw x64 and cygwin x64 version can share same source. ChangeLog 2013-03-22 Kai Tietz kti...@redhat.com * config/i386/cygwin.S: Replace use of _WIN64 by __x86_64__. Tested for x86_64-w64-mingw32, x86_64-pc-cygwin, and i686-w64-mingw32. I will apply tomorrow if there are no objections by other Windows-maintainers. Regards, Kai Index: libgcc/config/i386/cygwin.S === --- libgcc/config/i386/cygwin.S (Revision 196898) +++ libgcc/config/i386/cygwin.S (Arbeitskopie) @@ -32,7 +32,7 @@ # define cfi_adjust_cfa_offset(X) .cfi_adjust_cfa_offset X # define cfi_def_cfa_register(X) .cfi_def_cfa_register X # define cfi_register(D,S) .cfi_register D, S -# ifdef _WIN64 +# ifdef __x86_64__ # define cfi_push(X) .cfi_adjust_cfa_offset 8; .cfi_rel_offset X, 0 # define cfi_pop(X) .cfi_adjust_cfa_offset -8; .cfi_restore X # else @@ -57,7 +57,7 @@ .global ___chkstk .global __alloca -#ifdef _WIN64 +#ifdef __x86_64__ /* __alloca is a normal function call, which uses %rcx as the argument. */ cfi_startproc() __alloca: @@ -123,7 +123,7 @@ __alloca: pushl 4(%eax) ret cfi_endproc() -#endif /* _WIN64 */ +#endif /* __x86_64__ */ #endif /* L_chkstk */ #ifdef L_chkstk_ms @@ -131,7 +131,7 @@ __alloca: We avoid clobbering any registers. Unlike ___chkstk, it just probes the stack and does no stack allocation. */ .global ___chkstk_ms -#ifdef _WIN64 +#ifdef __x86_64__ cfi_startproc() ___chkstk_ms: pushq %rcx/* save temps */ @@ -183,5 +183,5 @@ ___chkstk_ms: cfi_pop(%ecx) ret cfi_endproc() -#endif /* _WIN64 */ +#endif /* __x86_64__ */ #endif /* L_chkstk_ms */
[patch libgcc]: Adjust cygming-crtbegin code to use weak
Hi,
this change is actual used by cygwin and is required for upcoming x64
cygwin target.
ChangeLog
2013-03-22 Kai Tietz kti...@redhat.com
* config/i386/cygming-crtbegin.c (__register_frame_info): Make weak.
(__deregister_frame_info): Likewise.
Tested for i686-pc-cygwin, and x86_64-pc-cygwin. I will apply this
code tomorrow if there are no objections by other
Windows-target-maintainers.
Regards,
Kai
Index: libgcc/config/i386/cygming-crtbegin.c
===
--- libgcc/config/i386/cygming-crtbegin.c (Revision 196898)
+++ libgcc/config/i386/cygming-crtbegin.c (Arbeitskopie)
@@ -46,15 +46,33 @@ see the files COPYING3 and COPYING.RUNTIME respect
#define LIBGCJ_SONAME libgcj_s.dll
#endif
-
+#if DWARF2_UNWIND_INFO
/* Make the declarations weak. This is critical for
_Jv_RegisterClasses because it lives in libgcj.a */
-extern void __register_frame_info (const void *, struct object *)
+extern void __register_frame_info (__attribute__((unused)) const void *,
+ __attribute__((unused)) struct object *)
TARGET_ATTRIBUTE_WEAK;
-extern void *__deregister_frame_info (const void *)
+extern void *__deregister_frame_info (__attribute__((unused)) const void *)
TARGET_ATTRIBUTE_WEAK;
-extern void _Jv_RegisterClasses (const void *) TARGET_ATTRIBUTE_WEAK;
+TARGET_ATTRIBUTE_WEAK void
+__register_frame_info (__attribute__((unused)) const void *p,
+ __attribute__((unused)) struct object *o)
+{}
+TARGET_ATTRIBUTE_WEAK void *
+__deregister_frame_info (__attribute__((unused)) const void *p)
+{ return (void*) 0; }
+#endif /* DWARF2_UNWIND_INFO */
+
+#if TARGET_USE_JCR_SECTION
+extern void _Jv_RegisterClasses (__attribute__((unused)) const void *)
+ TARGET_ATTRIBUTE_WEAK;
+
+TARGET_ATTRIBUTE_WEAK void
+_Jv_RegisterClasses (__attribute__((unused)) const void *p)
+{}
+#endif /* TARGET_USE_JCR_SECTION */
+
#if defined(HAVE_LD_RO_RW_SECTION_MIXING)
# define EH_FRAME_SECTION_CONST const
#else
[patch cygwin64]: Add and adjust some initial sources for x64 cygwin
Hi,
Hi,
the first part of required code-changes for upcoming cygwin x64 target.
ChangeLog
2013-03-22 Kai Tietz kti...@redhat.com
* config/i386/cygwin-stdint.h: Add support for cygwin x64 target.
* config/i386/t-cygwin-w64: New file.
* config/i386/cygwin-w64.h: New file.
* config/i386/cygwin.h (EXTRA_OS_CPP_BUILTINS): Extend
and add support for x64-cygwin target.
(CPP_SPEC): Likewise.
(CXX_WRAP_SPEC_LIST): Undefine before define.
(LIBGCJ_SONAME): Make name minor-build-version dependent.
Tested for i686-pc-cygwin, and x86_64-pc-cygwin. Dave, please
especially a look to LIBGCJ_SONAME change. I think we should include
MAJOR_VERSION here, too. Ok for apply?
Regards,
Kai
Tested with i686-pc-cygwin, and x86_64-pc-cygwin. I will apply
tomorrow, if there are no objections by other
Windows-target-maintainers.
Regards,
Kai
Index: gcc/config/i386/cygwin-stdint.h
===
--- gcc/config/i386/cygwin-stdint.h (Revision 196898)
+++ gcc/config/i386/cygwin-stdint.h (Arbeitskopie)
@@ -24,39 +24,71 @@ along with GCC; see the file COPYING3. If not see
#define INT8_TYPE signed char
#define INT16_TYPE short int
#define INT32_TYPE int
+#ifdef __x86_64__
+#define INT64_TYPE long int
+#else
#define INT64_TYPE long long int
+#endif
#define UINT8_TYPE unsigned char
#define UINT16_TYPE short unsigned int
#define UINT32_TYPE unsigned int
+#ifdef __x86_64__
+#define UINT64_TYPE long unsigned int
+#else
#define UINT64_TYPE long long unsigned int
+#endif
/* Minimum-width integer types */
#define INT_LEAST8_TYPE signed char
#define INT_LEAST16_TYPE short int
#define INT_LEAST32_TYPE int
+#ifdef __x86_64__
+#define INT_LEAST64_TYPE long int
+#else
#define INT_LEAST64_TYPE long long int
+#endif
#define UINT_LEAST8_TYPE unsigned char
#define UINT_LEAST16_TYPE short unsigned int
#define UINT_LEAST32_TYPE unsigned int
+#ifdef __x86_64__
+#define UINT_LEAST64_TYPE long unsigned int
+#else
#define UINT_LEAST64_TYPE long long unsigned int
+#endif
/* Fastest minimum-width integer types */
#define INT_FAST8_TYPE signed char
+#ifdef __x86_64__
+#define INT_FAST16_TYPE long int
+#define INT_FAST32_TYPE long int
+#define INT_FAST64_TYPE long int
+#else
#define INT_FAST16_TYPE int
#define INT_FAST32_TYPE int
#define INT_FAST64_TYPE long long int
+#endif
#define UINT_FAST8_TYPE unsigned char
+#ifdef __x86_64__
+#define UINT_FAST16_TYPE long unsigned int
+#define UINT_FAST32_TYPE long unsigned int
+#define UINT_FAST64_TYPE long unsigned int
+#else
#define UINT_FAST16_TYPE unsigned int
#define UINT_FAST32_TYPE unsigned int
#define UINT_FAST64_TYPE long long unsigned int
+#endif
/* Integer types capable of holding object pointers */
+#ifdef __x86_64__
+#define INTPTR_TYPE long int
+#define UINTPTR_TYPE long unsigned int
+#else
#define INTPTR_TYPE int
#define UINTPTR_TYPE unsigned int
-
+#endif
Index: gcc/config/i386/cygwin.h
===
--- gcc/config/i386/cygwin.h(revision 196791)
+++ gcc/config/i386/cygwin.h(working copy)
@@ -18,11 +18,20 @@
along with GCC; see the file COPYING3. If not see
http://www.gnu.org/licenses/. */
-#define EXTRA_OS_CPP_BUILTINS() /* Nothing. */
+#define EXTRA_OS_CPP_BUILTINS()\
+ do \
+{ \
+ builtin_define (__CYGWIN__); \
+ if (!TARGET_64BIT) \
+ builtin_define (__CYGWIN32__);\
+ builtin_define (__unix__); \
+ builtin_define (__unix); \
+} \
+ while (0)
#undef CPP_SPEC
#define CPP_SPEC %(cpp_cpu) %{posix:-D_POSIX_SOURCE} \
- -D__CYGWIN32__ -D__CYGWIN__ %{!ansi:-Dunix} -D__unix__ -D__unix \
+ %{!ansi:-Dunix} \
%{mwin32:-DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ %{!ansi:-DWINNT}} \
%{!nostdinc:%{!mno-win32:-idirafter ../include/w32api%s -idirafter
../../include/w32api%s}}\
@@ -73,6 +82,7 @@
/* To implement C++ function replacement we always wrap the cxx
malloc-like operators. See N2800 #17.6.4.6 [replacement.functions] */
+#undef CXX_WRAP_SPEC_LIST
#define CXX_WRAP_SPEC_LIST \
--wrap _Znwj \
--wrap _Znaj \
@@ -132,6 +142,13 @@
#endif
#define LIBGCC_SONAME cyggcc_s LIBGCC_EH_EXTN -1.dll
-/* We should find a way to not have to update this manually. */
-#define LIBGCJ_SONAME cyggcj /*LIBGCC_EH_EXTN*/ -13.dll
-
+#ifndef BUILDING_GCC_MAJOR
+#include bversion.h
+#endif
+#define ___cyg_mkstr(x)#x
+#define __cyg_mkstr(x) ___cyg_mkstr(x)
+#if BUILDING_GCC_MAJOR == 4
+#define LIBGCJ_SONAME cyggcj- __cyg_mkstr (BUILDING_GCC_MINOR+6) .dll
+#else
+#error LIBGCJ_SONAME
Re: [patch java]: Avoid looping over the end_params_node in put_decl_node
On 03/22/2013 08:13 AM, Kai Tietz wrote: Tested for i686-w64-mingw32, x86_64-w64-mingw32, and x86_64-unknown-linux-gnu. Ok for apply? Yes, thanks. Andrew.
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
On Mar 22 2013, Miles Bader wrote: That is another matter entirely. The code of gcc/gfortran is supposed to be compilable with other compilers, and it is foolish to make unnecessary assumptions by relying on undefined behaviour. The simple facts are that C++ does NOT define bool to be compatible with _Bool, and there are enough differences in specification and semantics to make it likely that they are not the same in at least some compilers. This mess has caused and still causes no end of problems for Fortran interoperability and in standards like MPI. Er, maybe so, but is there actually an issue in _this_ case? Yes. There are many ways of resolving it, one of which is to state that gfortran MUST be compiled in a second pass using gcc, after having built gcc. Another is described below. From original message, it sounds like these are internal compiler interfaces, so all that matters is that they be self-consistent, and there's no external ABI involved... So as long as all the code in question is compiled with C++ and uses C++ bool, or is compiled with C99 and uses _Bool, and doesn't use any functionality that isn't in the intersection of those two types, there shouldn't be any problem, right? And that is precisely the point. The risk isn't in either of them, but in any interface that passes C++ bool from the front-end to C99 _Bool in the back end. If you exclude that, there is no problem. This is a symptom of a much wider and more serious malaise, which I do NOT think should be discussed in this thread. I am going to mention it only if someone wants to contact me about it by Email, or start a new thread. There are much more and fouller gotchas to do with C++ and C99. complex is worse, because there are serious differences in the alignment requirements, and I know that affects some systems quite badly. But the real nasties are to do with cmath and errno and, worst of all, the horrors of C99 Annex F. My point here is that it is VERY important not to read the political sound-bite that C++ is now based on C99 and assume that they are actually compatible in all respects where they have 'equivalent' facilities. They aren't. Regards, Nick Maclaren.
Re: [patch libffi]: Make sure code is position-independent for x64 targets
On 03/22/2013 07:42 AM, Kai Tietz wrote: Tested for x86_64-w64-mingw32, and for upcoming x86_64-pc-cygwin target. Ok for apply? Yes, that's fine. Andrew.
Re: C++ PATCH: use identifier_p instead of naked TREE_CODE == IDENTIFIER_NODE
On Fri, Mar 22, 2013 at 4:50 AM, Gabriel Dos Reis g...@axiomatics.org wrote:
This patch introduces identified_p (t) in lieu of
TREE_CODE (t) == IDENTIFIER_NODE
Generally we have macros like IDENTIFIER_P for this kind of checks.
in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST
except that it returns a typed pointer instead of a boolean value.
Hm? So you are replacing TREE_CODE (t) == IDENTIFIER_NODE
with kind-of dynamic_castidentifier (t) (in C++ terms)? Then
naming it identifier_p is bad. We have is-a.h now, so please try to use
a single style of C++-style casting throughout GCC.
Thanks,
Richard.
There is NO change in functionality. With this patch, I measured that
bootsrapping takes slightly less time than without, and the object size
of cc1plus decreases by more than 5K.
Bootstrapped and texted on an x86_64-suse-linux.
Applying to trunk. Follow up patches will exploit the typed pointer.
-- Gaby
2013-03-21 Gabriel Dos Reis g...@integrable-solutions.net
* cp-tree.h (identifier_p): New.
* call.c: Throughout, call identifier_p insstead of direct
comparaison of TREE_CODE against IDENTIFIER_NODE.
* decl.c: Likewisse.
* decl2.c: Likewise.
* init.c: Likewise.
* mangle.c: Likewise.
* name-lookup.c: Likewise.
* parser.c: Likewise.
* pt.c: Likewise.
* search.c: Likewise.
* semantics.c: Likewise.
* tree.c: Likewise.
* typeck.c: Likewise.
* typeck2.c: Likewise.
Index: call.c
===
--- call.c (revision 196891)
+++ call.c (working copy)
@@ -233,7 +233,7 @@
name = TREE_TYPE (name);
else if (TYPE_P (name))
/* OK */;
- else if (TREE_CODE (name) == IDENTIFIER_NODE)
+ else if (identifier_p (name))
{
if ((MAYBE_CLASS_TYPE_P (basetype)
name == constructor_name (basetype))
@@ -3147,7 +3147,7 @@
: ACONCAT ((msgstr, , NULL)));
location_t cloc = location_of (candidate-fn);
- if (TREE_CODE (candidate-fn) == IDENTIFIER_NODE)
+ if (identifier_p (candidate-fn))
{
cloc = loc;
if (candidate-num_convs == 3)
@@ -8563,8 +8563,7 @@
- do not have the same parameter type list as any non-template
non-member candidate. */
- if (TREE_CODE (cand1-fn) == IDENTIFIER_NODE
- || TREE_CODE (cand2-fn) == IDENTIFIER_NODE)
+ if (identifier_p (cand1-fn) || identifier_p (cand2-fn))
{
for (i = 0; i len; ++i)
if (!same_type_p (cand1-convs[i]-type,
@@ -8575,7 +8574,7 @@
if (cand1-fn == cand2-fn)
/* Two built-in candidates; arbitrarily pick one. */
return 1;
- else if (TREE_CODE (cand1-fn) == IDENTIFIER_NODE)
+ else if (identifier_p (cand1-fn))
/* cand1 is built-in; prefer cand2. */
return -1;
else
Index: cp-tree.h
===
--- cp-tree.h (revision 196891)
+++ cp-tree.h (working copy)
@@ -241,6 +241,16 @@
tree label_value;
};
+/* Return a typed pointer version of T if it designates a
+ C++ front-end identifier. */
+inline lang_identifier*
+identifier_p (tree t)
+{
+ if (TREE_CODE (t) == IDENTIFIER_NODE)
+return (lang_identifier*) t;
+ return NULL;
+}
+
/* In an IDENTIFIER_NODE, nonzero if this identifier is actually a
keyword. C_RID_CODE (node) is then the RID_* value of the keyword,
and C_RID_YYCODE is the token number wanted by Yacc. */
Index: decl.c
===
--- decl.c (revision 196891)
+++ decl.c (working copy)
@@ -3296,7 +3296,7 @@
error (%qD used without template parameters, name);
return error_mark_node;
}
- gcc_assert (TREE_CODE (name) == IDENTIFIER_NODE);
+ gcc_assert (identifier_p (name));
gcc_assert (TYPE_P (context));
if (!MAYBE_CLASS_TYPE_P (context))
@@ -3402,7 +3402,7 @@
name = TYPE_IDENTIFIER (name);
else if (DECL_P (name))
name = DECL_NAME (name);
- gcc_assert (TREE_CODE (name) == IDENTIFIER_NODE);
+ gcc_assert (identifier_p (name));
if (!dependent_type_p (context)
|| currently_open_class (context))
@@ -4781,7 +4781,7 @@
}
else
{
- gcc_assert (TREE_CODE (ce-index) == IDENTIFIER_NODE);
+ gcc_assert (identifier_p (ce-index));
error (name %qD used in a GNU-style designated
initializer for an array, ce-index);
}
@@ -7413,8 +7413,7 @@
== current_class_type);
fns = TREE_OPERAND (fns, 1);
}
- gcc_assert (TREE_CODE (fns) == IDENTIFIER_NODE
- || TREE_CODE (fns) == OVERLOAD);
+ gcc_assert (identifier_p (fns) || TREE_CODE
[patch i386 windows]: Fix PR/52790 also required for workig upcoming cygwin x64 target
Hi,
this patch fixes PR/52790 and supports for x64 Windows targets the use
of large and medium code-model.
This feature is required for upcoming new cygwin x64 target, which
uses full 48-bit available address-space of x64 Windows.
The cygwin-target depends on pseudo-relocation-feature, which operates
on instruction relocations. This can lead for x86_64 to issues, due
instructions are in general signed-32bit-pc-relative relocated. So
distances can become too wide for pseudo-relocation.
Due for functions we generate anyway on pe-coff targets jump-stubs, we
just need to make sure that variables are accessed via
reference-pointer-variables. So we add for them in medium model
.refptr-variables.
In large model we using for external (therefore possibly
pseudo-relocated) symbols also indirect-addressing via refptr-stubs.
To avoid same issues as we noticed on cygwin64, I want to change
code-model default to medium also for native-windows x64 target.
ChangeLog
2013-03-22 Kai Tietz kti...@redhat.com
PR target/52790
* config/i386/cygming.h (SUB_TARGET_RECORD_STUB): New sub-target macro.
* config/i386/i386-protos.h (i386_pe_record_stub): Add new prototype.
* config/i386/i386.c (legitimize_pe_coff_extern_decl): New static
function.
(legitimize_pe_coff_symbol): Likewise.
(is_imported_p): New helper-function.
(ix86_option_override_internal): Make MEDIUM_PIC the default code-model
for Windows x64 targets.
(ix86_expand_prologue): Optimize for pe-coff targets.
(ix86_expand_split_stack_prologue): Adjust for pe-coff targets.
(legitimate_pic_address_disp_p): Adjust for x64 pe-coff to support
medium/large code-model.
(legitimize_pic_address): Likewise.
(legitimize_tls_address): Likewise.
(ix86_expand_call): Likewise.
(x86_output_mi_thunk): Likewise.
(get_dllimport_decl): Add new beimport argument.
(construct_plt_address): Don't assert for x64 pe-coff targets.
* config/i386/i386.h (PIC_OFFSET_TABLE_REGNUM): Adjust for x64 pe-coff
targets.
(SYMBOL_FLAG_STUBVAR): New macro.
(SYMBOL_REF_STUBVAR_P): Likewise.
* config/i386/winnt.c (stub_list): New structure.
(stub_head): New local variable.
(i386_pe_record_stub): New function.
(i386_pe_file_end): Emit refptr-stubs.
This patch is tested for x86_64-pc-cygwin, x86_64-w64-mingw32.
Additional tested for x86_64-unknown-linux-gnu to see that no
regression were introduced by this patch.
Ok for apply?
Regards,
Kai
Index: gcc/config/i386/cygming.h
===
--- gcc/config/i386/cygming.h (Revision 196898)
+++ gcc/config/i386/cygming.h (Arbeitskopie)
@@ -474,5 +474,8 @@ do {\
#undef TARGET_ASM_ASSEMBLE_VISIBILITY
#define TARGET_ASM_ASSEMBLE_VISIBILITY i386_pe_assemble_visibility
+#undef SUB_TARGET_RECORD_STUB
+#define SUB_TARGET_RECORD_STUB i386_pe_record_stub
+
/* Static stack checking is supported by means of probes. */
#define STACK_CHECK_STATIC_BUILTIN 1
Index: gcc/config/i386/i386-protos.h
===
--- gcc/config/i386/i386-protos.h (Revision 196898)
+++ gcc/config/i386/i386-protos.h (Arbeitskopie)
@@ -260,6 +260,7 @@ extern void i386_pe_end_function (FILE *, const ch
extern void i386_pe_assemble_visibility (tree, int);
extern tree i386_pe_mangle_decl_assembler_name (tree, tree);
extern tree i386_pe_mangle_assembler_name (const char *);
+extern void i386_pe_record_stub (const char *);
extern void i386_pe_seh_init (FILE *);
extern void i386_pe_seh_end_prologue (FILE *);
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (Revision 196898)
+++ gcc/config/i386/i386.c (Arbeitskopie)
@@ -64,6 +64,8 @@ along with GCC; see the file COPYING3. If not see
#include tree-flow.h
static rtx legitimize_dllimport_symbol (rtx, bool);
+static rtx legitimize_pe_coff_extern_decl (rtx, bool);
+static rtx legitimize_pe_coff_symbol (rtx, bool);
#ifndef CHECK_STACK_LIMIT
#define CHECK_STACK_LIMIT (-1)
@@ -3233,9 +3235,7 @@ ix86_option_override_internal (bool main_args_p)
use of rip-relative addressing. This eliminates fixups that
would otherwise be needed if this object is to be placed in a
DLL, and is essentially just as efficient as direct addressing. */
- if (TARGET_64BIT DEFAULT_ABI == MS_ABI)
- ix86_cmodel = CM_SMALL_PIC, flag_pic = 1;
- else if (TARGET_64BIT TARGET_RDOS)
+ if (TARGET_64BIT (TARGET_RDOS || DEFAULT_ABI == MS_ABI))
ix86_cmodel = CM_MEDIUM_PIC, flag_pic = 1;
else if (TARGET_64BIT)
ix86_cmodel = flag_pic ? CM_SMALL_PIC : CM_SMALL;
@@ -10575,7 +10575,9 @@ ix86_expand_prologue (void)
ix86_emit_save_sse_regs_using_mov
Re: C++ PATCH: use identifier_p instead of naked TREE_CODE == IDENTIFIER_NODE
On Fri, Mar 22, 2013 at 10:21:05AM +0100, Richard Biener wrote: On Fri, Mar 22, 2013 at 4:50 AM, Gabriel Dos Reis g...@axiomatics.org wrote: This patch introduces identified_p (t) in lieu of TREE_CODE (t) == IDENTIFIER_NODE Generally we have macros like IDENTIFIER_P for this kind of checks. in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST except that it returns a typed pointer instead of a boolean value. Hm? So you are replacing TREE_CODE (t) == IDENTIFIER_NODE with kind-of dynamic_castidentifier (t) (in C++ terms)? Then naming it identifier_p is bad. We have is-a.h now, so please try to use a single style of C++-style casting throughout GCC. Anyway, if you see better code generated with your change compared to the old style, I'd say you should file a PR with some preferrably short preprocessed routine where it makes a difference, because that would show that either VRP or other optimization pass just isn't doing good job. It is better code for --enable-checking=yes anyway, right? Jakub
Re: [patch] Fix ICE during RTL expansion at -O1
On Thu, Mar 21, 2013 at 5:24 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
this fixes an ICE on the mainline at -O1:
eric@polaris:~/gnat/bugs/M129-026 ~/install/gcc/bin/gcc -S p.adb -O
+===GNAT BUG DETECTED==+
| 4.9.0 20130320 (experimental) [trunk revision 196816] (x86_64-suse-linux)
GCC error:|
| in expand_assignment, at expr.c:4761 |
| Error detected around p.ads:11:9
MEM[(struct p__rec )ret].d = 0;
MEM[(struct p__rec )ret].b1 = 0;
_26 = MEM[(struct p__rec )ret].d;
p0.8_27 = (integer) _26;
_28 = (sizetype) p0.8_27;
_29 = _28 * 8;
_30 = _29 + _29;
_31 = _30 + 8;
_32 = _31 /[ex] 8;
MEM[(struct p__rec )ret].b2{off: _32 * 8} = 1;
The ICE occurs because ret is put into a register instead of memory (it has
an integral mode) and you cannot have a variable offset within an object in
a register.
But, if you look at the above GIMPLE from .optimized, you'll see that the
offset is actually fixed and that the GIMPLE optimizers weren't powerful
enough to see it. Ironically enough, the RTL optimizers would have been!
So the attached patch adds a clone of nonoverlapping_component_refs_p from
alias.c to tree-ssa-alias.c to disambiguate the memory accesses. It also
contains a small tweak to both functions to cater to a LTO-specific quirk.
With it, a bunch of testcases of the vectorization testsuite are optimized
so the patch also contains counter-measures for them.
Tested on x86_64-suse-linux, OK for the mainline?
This is a quadratic algorithm and as such not ok. We already have
aliasing_component_refs_p in tree-ssa-alias.c which is supposed to be
the non-quadratic replacement. It's not used via decl_refs_may_alias_p,
so that may be the thing to fix.
nonoverlapping_component_refs_of_decl_p on RTL should go - in fact
we do call the tree oracle from all its callers so we only ever do redundant
work (after your proposed patch even more so).
(I recently tried to cache the ao_ref in mem-attrs but failed because of
weird gengtype issues ... we could avoid the repeated get_ref_base_and_extent
calls done via ao_ref_from_mem that way).
Richard.
2013-03-21 Eric Botcazou ebotca...@adacore.com
* alias.c (nonoverlapping_component_refs_p): Protect again LTO quirk.
* tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p): New.
(decl_refs_may_alias_p): Add REF1 and REF2 parameters.
Use it to disambiguate component references.
(refs_may_alias_p_1): Adjust call to decl_refs_may_alias_p.
2013-03-21 Eric Botcazou ebotca...@adacore.com
* gnat.dg/discr41.ad[sb]: New test.
* gcc.dg/vect/slp-24-big-array.c: Beef up anti-vectorization trick.
* gcc.dg/vect/slp-24.c: Likewise.
* gcc.dg/vect/vect-strided-a-mult.c: Likewise.
* gcc.dg/vect/vect-strided-a-u16-i2.c: Likewise.
* gcc.dg/vect/vect-strided-a-u16-i4.c: Likewise.
* gcc.dg/vect/vect-strided-a-u16-mult.c: Likewise.
* gcc.dg/vect/vect-strided-a-u8-i2-gap.c: Likewise.
* gcc.dg/vect/vect-strided-a-u8-i8-gap2-big-array.c: Likewise.
* gcc.dg/vect/vect-strided-a-u8-i8-gap2.c: Likewise.
* gcc.dg/vect/vect-strided-a-u8-i8-gap7-big-array.c: Likewise.
* gcc.dg/vect/vect-strided-a-u8-i8-gap7.c: Likewise.
* gcc.dg/vect/vect-strided-mult-char-ls.c: Likewise.
* gcc.dg/vect/vect-strided-mult.c: Likewise.
* gcc.dg/vect/vect-strided-same-dr.c: Likewise.
* gcc.dg/vect/vect-strided-u16-i2.c: Likewise.
* gcc.dg/vect/vect-strided-u16-i4.c: Likewise.
* gcc.dg/vect/vect-strided-u32-i4.c: Likewise.
* gcc.dg/vect/vect-strided-u32-i8.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i2-gap.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i2.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i8-gap2-big-array.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i8-gap2.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i8-gap4-big-array.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i8-gap4.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i8-gap7-big-array.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i8-gap7.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i8.c: Likewise.
--
Eric Botcazou
Re: [patch] df-scan: split df_insn_delete for clearer dumps and better speed
On Mon, Mar 18, 2013 at 1:01 AM, Steven Bosscher wrote: On Thu, Feb 21, 2013 at 1:33 PM, Paolo Bonzini wrote: someone else DF aware anyway. If it is 4.9 material perhaps it is simpler to place it after the patches that kill the basic block argument. Here is the updated patch. Bootstrappedtested on powerpc64-unknown-linux-gnu. OK for trunk? Ping? Ciao! Steven
Re: [patch] df-scan: split df_insn_delete for clearer dumps and better speed
Il 18/03/2013 01:01, Steven Bosscher ha scritto: someone else DF aware anyway. If it is 4.9 material perhaps it is simpler to place it after the patches that kill the basic block argument. Here is the updated patch. Bootstrappedtested on powerpc64-unknown-linux-gnu. OK for trunk? Ok. Paolo
Re: [PATCH] Fix PR56434
On Fri, Mar 22, 2013 at 11:06:53AM +0100, Richard Biener wrote: This fixes PR56434 - the use of BIGGEST_ALIGNMENT to annotate the pointer returned by malloc is wrong - BIGGEST_ALIGNMENT has nothing to do with the alignment guaranteed by the ABI for allocated memory. For example on x86_64 it depends on -mavx and thus can result in wrong code being generated. The following patch fixes it to use what we use on the GIMPLE level - MALLOC_ABI_ALIGNMENT. Ok for trunk? IMHO the change should be accompanied by defining MALLOC_ABI_ALIGNMENT on at least a couple of popular targets. E.g. glibc will guarantee at least 2 * sizeof (void *) alignment on all architectures, and even if one uses some other malloc implementation, it should be better ISO C99 conforming on Linux (perhaps ignoring long double type (known to be non-conforming e.g. on ppc32) and _Decimal* types). So, at least for Linux I'd say MALLOC_ABI_ALIGNMENT should be defined as maximum alignment of long, long long, double and void *. Because, right now, MALLOC_ABI_ALIGNMENT is only defined to non-__alignof__(char) on VMS. 2013-03-22 Richard Biener rguent...@suse.de PR middle-end/56434 * calls.c (expand_call): Use MALLOC_ABI_ALIGNMENT to annotate the pointer returned by calls with ECF_MALLOC set. Index: gcc/calls.c === --- gcc/calls.c (revision 196899) +++ gcc/calls.c (working copy) @@ -3186,7 +3186,7 @@ expand_call (tree exp, rtx target, int i /* The return value from a malloc-like function is a pointer. */ if (TREE_CODE (rettype) == POINTER_TYPE) - mark_reg_pointer (temp, BIGGEST_ALIGNMENT); + mark_reg_pointer (temp, MALLOC_ABI_ALIGNMENT); emit_move_insn (temp, valreg); Jakub
[PATCH] Update changes.html about -Wno-aggressive-loop-optimizations
Hi! This new warning switch hasn't been mentioned in changes.html, the following patch fixes that. Is this ok, or do you have better wording? --- htdocs/gcc-4.8/changes.html 14 Mar 2013 01:13:56 - 1.108 +++ htdocs/gcc-4.8/changes.html 22 Mar 2013 10:22:37 - @@ -32,7 +32,12 @@ the number of iterations of loops using standards. This may cause non-conforming programs to no longer work as expected, such as SPEC CPU 2006 464.h264ref and 416.gamess. A new option, code-fno-aggressive-loop-optimizations/code, was added -to disable this aggressive analysis./p +to disable this aggressive analysis. In some loops that have known +constant number of iterations, but undefined behavior is known to occur +in the loop before reaching or during the last iteration, GCC will warn +about the undefined behavior in the loop instead of deriving lower upper +bound of the number of iterations for the loop. The warning +can be disabled with code-Wno-aggressive-loop-optimizations/code./p pOn ARM, a bug has been fixed in GCC's implementation of the AAPCS rules for the layout of vectors that could lead to wrong code being Jakub
Re: [PATCH] Fix PR56434
On Fri, 22 Mar 2013, Jakub Jelinek wrote: On Fri, Mar 22, 2013 at 11:06:53AM +0100, Richard Biener wrote: This fixes PR56434 - the use of BIGGEST_ALIGNMENT to annotate the pointer returned by malloc is wrong - BIGGEST_ALIGNMENT has nothing to do with the alignment guaranteed by the ABI for allocated memory. For example on x86_64 it depends on -mavx and thus can result in wrong code being generated. The following patch fixes it to use what we use on the GIMPLE level - MALLOC_ABI_ALIGNMENT. Ok for trunk? IMHO the change should be accompanied by defining MALLOC_ABI_ALIGNMENT on at least a couple of popular targets. E.g. glibc will guarantee at least 2 * sizeof (void *) alignment on all architectures, and even if one uses some other malloc implementation, it should be better ISO C99 conforming on Linux (perhaps ignoring long double type (known to be non-conforming e.g. on ppc32) and _Decimal* types). So, at least for Linux I'd say MALLOC_ABI_ALIGNMENT should be defined as maximum alignment of long, long long, double and void *. Because, right now, MALLOC_ABI_ALIGNMENT is only defined to non-__alignof__(char) on VMS. I think the wrong-code fix is orthogonal to code improvements which will also trigger on the GIMPLE level (and where they will have a bigger impact). We can for example, in config/linux.h do #if OPTION_GLIBC #undef MALLOC_ABI_ALIGNMENT #define MALLOC_ABI_ALIGNMENT (2 * sizeof (void *)) #endif if that's what glibc really guarantees (does it maybe have a feature macro for this?) Richard. 2013-03-22 Richard Biener rguent...@suse.de PR middle-end/56434 * calls.c (expand_call): Use MALLOC_ABI_ALIGNMENT to annotate the pointer returned by calls with ECF_MALLOC set. Index: gcc/calls.c === --- gcc/calls.c (revision 196899) +++ gcc/calls.c (working copy) @@ -3186,7 +3186,7 @@ expand_call (tree exp, rtx target, int i /* The return value from a malloc-like function is a pointer. */ if (TREE_CODE (rettype) == POINTER_TYPE) - mark_reg_pointer (temp, BIGGEST_ALIGNMENT); + mark_reg_pointer (temp, MALLOC_ABI_ALIGNMENT); emit_move_insn (temp, valreg); Jakub -- Richard Biener rguent...@suse.de SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
N.M. Maclaren wrote: On Mar 22 2013, Miles Bader wrote: That is another matter entirely. The code of gcc/gfortran is supposed to be compilable with other compilers, and it is foolish to make unnecessary assumptions by relying on undefined behaviour. The simple facts are that C++ does NOT define bool to be compatible with _Bool, and there are enough differences in specification and semantics to make it likely that they are not the same in at least some compilers. This mess has caused and still causes no end of problems for Fortran interoperability and in standards like MPI. Er, maybe so, but is there actually an issue in _this_ case? Yes. There are many ways of resolving it, one of which is to state that gfortran MUST be compiled in a second pass using gcc, after having built gcc. Another is described below. Well, the recommend way to compile GCC is to bootstrap it. That uses the system compiler (or whatever the user has) to compile GCC's C and C++ compilers; those are then used to compile GCC (this time including the Fortran front end) - for the compiler: twice, once without (stage 2) and once with (stage 3) debugging symbols. Then, the generated code is compared and shall not differ. Users can compile GCC also without bootstrapping. However, I also do not see problems: Older GCC are compiled by C, newer by C++. But C and C++ are not mixed and this bool is really only used internally in the compiler and internally in the libgfortran run-time library (the latter is always compiled by GCC 's just created C compiler). Thus, I do not see how this can cause problems. That's different to user code, where mixing Fortran's LOGICAL, C's and C++'s bool can cause problems - as can passing an C or C++'s int to a Fortran LOGICAL (or without prototype: To C/C++'s bool). Or using different Fortran compilers with LOGICAL. I concur that this is an underestimated problem, but I fail to see how it applys here. And that is precisely the point. The risk isn't in either of them, but in any interface that passes C++ bool from the front-end to C99 _Bool in the back end. If you exclude that, there is no problem. The front end and the backend are both compiled with the same compiler and in the same binary. Even without bootstrapping, trying to compile them with different compilers, will require some heavy editing of makefiles. Thus, it seems to be extremely unlikely that different compilers have ever been used. The change from C99's bool to C++'s bool occurred for the whole compiler. Before 4.7 the default was to compile GCC with C (though it had been modified to be also compilable with C++); in 4.7, the default compiler was C++ but C was still supported. And since GCC 4.8 C++ features are used, which makes GCC only compilable with C++. Actually, the FE itself so far uses nearly no C++ features, it is the middle end which used them (which 'leak' to the front end via some helper macros/functions). My point here is that it is VERY important not to read the political sound-bite that C++ is now based on C99 and assume that they are actually compatible in all respects where they have 'equivalent' facilities. They aren't. In terms of the discussion, bool is used for quite some time in gfortran (the frontend) and libgfortran. When GCC was compiled with C, that was C99's _Bool. Since the compiler is compiled as C++, it is C++'s bool. Thus, C/C++'s bool are never mixed. Tobias
New German PO file for 'gcc' (version 4.8-b20130224)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/gcc/de.po (This file, 'gcc-4.8-b20130224.de.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
On Mar 22 2013, Tobias Burnus wrote: The front end and the backend are both compiled with the same compiler and in the same binary. Even without bootstrapping, trying to compile them with different compilers, will require some heavy editing of makefiles. Thus, it seems to be extremely unlikely that different compilers have ever been used. The change from C99's bool to C++'s bool occurred for the whole compiler. Before 4.7 the default was to compile GCC with C (though it had been modified to be also compilable with C++); in 4.7, the default compiler was C++ but C was still supported. And since GCC 4.8 C++ features are used, which makes GCC only compilable with C++. Actually, the FE itself so far uses nearly no C++ features, it is the middle end which used them (which 'leak' to the front end via some helper macros/functions). Ah. I misunderstood what people said. Yes, if C++ mode is used for the whole compiler, everything is fine. And it remains so even if the code plays fairly clever games. I don't know if there are any compilers that generate incompatible bool types in C and C++ modes, but it wouldn't surprise me if there were. In terms of the discussion, bool is used for quite some time in gfortran (the frontend) and libgfortran. When GCC was compiled with C, that was C99's _Bool. Since the compiler is compiled as C++, it is C++'s bool. Thus, C/C++'s bool are never mixed. Then there is no problem. Sorry about the red herring - I misunderstood what people said. Unfortunately, from personal experience, the majority of people even on WG14 and WG21 do not understand the incompatibilities, which is why I posted. Regards, Nick Maclaren.
[PATCH] Re-organize toplevel LIM dependence query
This re-organizes the toplevel LIM dependence query which is
to ask whether a reference is independent in a whole loop nest.
The patch makes it compute the answer for all sub-loops of the
nest and compute an overall answer based on the answers from
the sub-loops. This avoids repeated dependence tests on
references contained in subloops, making the reference dependence
check cache even more useless as can be seen from instrumentation
on the PR39326 testcase. Before the patch we do
101 lim loop cache queries == 155636 1
101 lim loop cache hitrate == 11 1
101 lim ref cache queries == 1572939576 1
101 lim ref cache hitrate == 12 1
124 lim loop cache queries == 143444 1
124 lim loop cache hitrate == 12 1
124 lim ref cache queries == 294471688 1
124 lim ref cache hitrate == 24 1
and after it (the first LIM pass does quite some store-motion)
101 lim loop cache queries == 2011316 1
101 lim loop cache hitrate == 3 1
101 lim ref cache queries == 1490087040 1
101 lim ref cache hitrate == 7 1
124 lim loop cache queries == 1199348 1
124 lim loop cache hitrate == 6 1
124 lim ref cache queries == 222856846 1
124 lim ref cache hitrate == 0 1
so we increase the load (and cost) of the loop cache (because its
querying is more fine-grained now) and reduce the number of
redundant reference dependence checks significantly, down to
the point where the caches benefit does no longer outweight
its quadratic cost in memory (removing it speeds up compile-time
of the PR39326 testcase by 50% as well!)
With the recursive nature we also avoid using the all_refs bitmaps
which are a source of quadratic memory use in LIM and the more
costly one of both is now easily removed (separate patch).
Bootstrapped and tested on x86_64-unknown-linux-gnu and committed.
Richard.
2013-03-22 Richard Biener rguent...@suse.de
* tree-ssa-loop-im.c (memory_references): Add refs_stored_in_loop
bitmaps.
(gather_mem_refs_in_loops): Perform store accumulation here.
(create_vop_ref_mapping_loop): Remove.
(create_vop_ref_mapping): Likewise.
(analyze_memory_references): Initialize refs_stored_in_loop.
(LOOP_DEP_BIT): New define to map to bits in (in)dep_loop
bitmaps.
(record_indep_loop): Remove.
(record_dep_loop): New function.
(ref_indep_loop_p_1): Adjust to only walk over references
in the loop, not its subloops.
(ref_indep_loop_p): Rename to ...
(ref_indep_loop_p_2): ... this and recurse over the loop tree,
maintaining a more fine-grained cache.
(ref_indep_loop_p): Wrap ref_indep_loop_p_2.
(tree_ssa_lim_finalize): Free refs_stored_in_loop.
Index: trunk/gcc/tree-ssa-loop-im.c
===
*** trunk.orig/gcc/tree-ssa-loop-im.c 2013-03-22 10:13:16.0 +0100
--- trunk/gcc/tree-ssa-loop-im.c2013-03-22 10:35:18.347671377 +0100
*** typedef struct mem_ref
*** 140,145
--- 140,150
bitmap dep_ref; /* The complement of INDEP_REF. */
} *mem_ref_p;
+ /* We use two bits per loop in the ref-{in,}dep_loop bitmaps, the first
+to record (in)dependence against stores in the loop and its subloops, the
+second to record (in)dependence against all references in the loop
+and its subloops. */
+ #define LOOP_DEP_BIT(loopnum, storedp) (2 * (loopnum) + (storedp ? 1 : 0))
*** static struct
*** 156,167
/* The set of memory references accessed in each loop. */
vecbitmap refs_in_loop;
/* The set of memory references accessed in each loop, including
subloops. */
vecbitmap all_refs_in_loop;
! /* The set of memory references stored in each loop, including
! subloops. */
vecbitmap all_refs_stored_in_loop;
/* Cache for expanding memory addresses. */
--- 161,174
/* The set of memory references accessed in each loop. */
vecbitmap refs_in_loop;
+ /* The set of memory references stored in each loop. */
+ vecbitmap refs_stored_in_loop;
+
/* The set of memory references accessed in each loop, including
subloops. */
vecbitmap all_refs_in_loop;
! /* The set of memory references stored in each loop, including subloops .
*/
vecbitmap all_refs_stored_in_loop;
/* Cache for expanding memory addresses. */
*** gather_mem_refs_stmt (struct loop *loop,
*** 1575,1581
}
bitmap_set_bit (memory_accesses.refs_in_loop[loop-num], ref-id);
if (is_stored)
! mark_ref_stored (ref, loop);
return;
}
--- 1582,1591
}
bitmap_set_bit (memory_accesses.refs_in_loop[loop-num], ref-id);
if (is_stored)
! {
! bitmap_set_bit (memory_accesses.refs_stored_in_loop[loop-num],
ref-id);
! mark_ref_stored (ref, loop);
! }
return;
}
*** gather_mem_refs_in_loops (void)
*** 1602,1610
{
gimple_stmt_iterator bsi;
basic_block
RE: [PATCH][ARM][2/2] Load-acquire, store-release atomics in AArch32 ARMv8
Ping? http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00023.html I thought this was ok'd for 4.9 but I can't seem to find the ok email in the archives Thanks, Kyrill -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov Sent: 01 February 2013 17:39 To: gcc-patches@gcc.gnu.org Cc: Ramana Radhakrishnan; Richard Earnshaw; Marcus Shawcroft Subject: RE: [PATCH][ARM][2/2] Load-acquire, store-release atomics in AArch32 ARMv8 Ummm... forgot the patch, sorry! -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov Sent: 01 February 2013 17:37 To: gcc-patches@gcc.gnu.org Cc: Ramana Radhakrishnan; Richard Earnshaw; Marcus Shawcroft Subject: [PATCH][ARM][2/2] Load-acquire, store-release atomics in AArch32 ARMv8 Hi all, This patch adds the tests for the ARMv8 AArch32 implementation of atomics. It refactors some aarch64 tests and reuses them. Ok for trunk or for the next stage 1 (together with part 1 at http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01441.html)? Thanks, Kyrill gcc/testsuite/ChangeLog 2013-01-25 Kyrylo Tkachov kyrylo.tkachov at arm.com * gcc.target/aarch64/atomic-comp-swap-release-acquire.c: Move test body from here... * gcc.target/aarch64/atomic-comp-swap-release-acquire.x: ... to here. * gcc.target/aarch64/atomic-op-acq_rel.c: Move test body from here... * gcc.target/aarch64/atomic-op-acq_rel.x: ... to here. * gcc.target/aarch64/atomic-op-acquire.c: Move test body from here... * gcc.target/aarch64/atomic-op-acquire.x: ... to here. * gcc.target/aarch64/atomic-op-char.c: Move test body from here... * gcc.target/aarch64/atomic-op-char.x: ... to here. * gcc.target/aarch64/atomic-op-consume.c: Move test body from here... * gcc.target/aarch64/atomic-op-consume.x: ... to here. * gcc.target/aarch64/atomic-op-int.c: Move test body from here... * gcc.target/aarch64/atomic-op-int.x: ... to here. * gcc.target/aarch64/atomic-op-relaxed.c: Move test body from here... * gcc.target/aarch64/atomic-op-relaxed.x: ... to here. * gcc.target/aarch64/atomic-op-release.c: Move test body from here... * gcc.target/aarch64/atomic-op-release.x: ... to here. * gcc.target/aarch64/atomic-op-seq_cst.c: Move test body from here... * gcc.target/aarch64/atomic-op-seq_cst.x: ... to here. * gcc.target/aarch64/atomic-op-short.c: Move test body from here... * gcc.target/aarch64/atomic-op-short.x: ... to here. * gcc.target/arm/atomic-comp-swap-release-acquire.c: New test. * gcc.target/arm/atomic-op-acq_rel.c: Likewise. * gcc.target/arm/atomic-op-acquire.c: Likewise. * gcc.target/arm/atomic-op-char.c: Likewise. * gcc.target/arm/atomic-op-consume.c: Likewise. * gcc.target/arm/atomic-op-int.c: Likewise. * gcc.target/arm/atomic-op-relaxed.c: Likewise. * gcc.target/arm/atomic-op-release.c: Likewise. * gcc.target/arm/atomic-op-seq_cst.c: Likewise. * gcc.target/arm/atomic-op-short.c: Likewise.
RE: [PATCH][ARM][1/2] Load-acquire, store-release atomics in AArch32 ARMv8
Ping?
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01441.html
I thought this was ok'd for 4.9 but I can't seem to find the ok email in the
archives.
Thanks,
Kyrill
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
Sent: 30 January 2013 15:55
To: gcc-patches@gcc.gnu.org
Cc: Ramana Radhakrishnan; Richard Earnshaw
Subject: [PATCH][ARM][1/2] Load-acquire, store-release atomics in
AArch32 ARMv8
Hi all,
This patch implements the atomic built-ins using the new ARMv8 load-
acquire
and store-release instructions.
They allow us to generate barrier-free code for a variety of atomic
operations such as: atomic load, atomic store, atomic compare and swap,
atomic {or, and, add, sub, xor}.
Tests will come in a separate patch soon.
No regressions on arm-none-eabi. Bootstrap on armv7l-unknown-linux-
gnueabihf
successful.
Ok for trunk (now or when stage 1 reopens)?
Thanks,
Kyrill
gcc/ChangeLog
2013-01-23 Kyrylo Tkachov kyrylo.tkachov at arm.com
* config/arm/arm.c (arm_emit_load_exclusive): Add acq parameter.
Emit load-acquire versions when acq is true.
(arm_emit_store_exclusive): Add rel parameter.
Emit store-release versions when rel is true.
(arm_split_compare_and_swap): Use acquire-release instructions
instead
of barriers when appropriate.
(arm_split_atomic_op): Likewise.
* config/arm/arm.h (TARGET_HAVE_LDACQ): New macro.
* config/arm/unspecs.md (VUNSPEC_LAX): New unspec.
(VUNSPEC_SLX): Likewise.
(VUNSPEC_LDA): Likewise.
(VUNSPEC_STL): Likewise.
* config/arm/sync.md (atomic_loadmode): New pattern.
(atomic_storemode): Likewise.
(arm_load_acquire_exclusivemode): Likewise.
(arm_load_acquire_exclusivesi): Likewise.
(arm_load_acquire_exclusivedi): Likewise.
(arm_store_release_exclusivemode): Likewise.
[PATCH] Remove LIM all_refs_in_loop bitmaps
This removes the all_refs_in_loop bitmaps. They add a O(loop-depth)
memory cost to the refs_in_loop bitmaps. It removes the last
user, a query that is used to avoid walking subloops. But that
query is costly compared to just walking the subloops.
No observable memory usage difference for PR39326, but
LIM compile-time improves by 10%.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-03-22 Richard Biener rguent...@suse.de
* tree-ssa-loop-im.c (memory_references): Drop all_refs_in_loop.
(gather_mem_refs_in_loops): Do not compute it.
(analyze_memory_references): Do not allocate it.
(tree_ssa_lim_finalize): Do not free it.
(for_all_locs_in_loop): Do not query all_refs_in_loop.
Index: gcc/tree-ssa-loop-im.c
===
*** gcc/tree-ssa-loop-im.c (revision 196956)
--- gcc/tree-ssa-loop-im.c (working copy)
*** static struct
*** 164,173
/* The set of memory references stored in each loop. */
vecbitmap refs_stored_in_loop;
- /* The set of memory references accessed in each loop, including
- subloops. */
- vecbitmap all_refs_in_loop;
-
/* The set of memory references stored in each loop, including subloops .
*/
vecbitmap all_refs_stored_in_loop;
--- 164,169
*** gather_mem_refs_in_loops (void)
*** 1649,1656
FOR_EACH_LOOP (li, loop, LI_FROM_INNERMOST)
{
/* Finalize the overall touched references (including subloops). */
- bitmap_ior_into (memory_accesses.all_refs_in_loop[loop-num],
- memory_accesses.refs_in_loop[loop-num]);
bitmap_ior_into (memory_accesses.all_refs_stored_in_loop[loop-num],
memory_accesses.refs_stored_in_loop[loop-num]);
--- 1645,1650
*** gather_mem_refs_in_loops (void)
*** 1660,1667
if (outer == current_loops-tree_root)
continue;
- bitmap_ior_into (memory_accesses.all_refs_in_loop[outer-num],
- memory_accesses.all_refs_in_loop[loop-num]);
bitmap_ior_into (memory_accesses.all_refs_stored_in_loop[outer-num],
memory_accesses.all_refs_stored_in_loop[loop-num]);
}
--- 1654,1659
*** analyze_memory_references (void)
*** 1683,1689
memory_accesses.refs_in_loop.create (number_of_loops ());
memory_accesses.refs_stored_in_loop.create (number_of_loops ());
- memory_accesses.all_refs_in_loop.create (number_of_loops ());
memory_accesses.all_refs_stored_in_loop.create (number_of_loops ());
for (i = 0; i number_of_loops (); i++)
--- 1675,1680
*** analyze_memory_references (void)
*** 1693,1700
empty = BITMAP_ALLOC (lim_bitmap_obstack);
memory_accesses.refs_stored_in_loop.quick_push (empty);
empty = BITMAP_ALLOC (lim_bitmap_obstack);
- memory_accesses.all_refs_in_loop.quick_push (empty);
- empty = BITMAP_ALLOC (lim_bitmap_obstack);
memory_accesses.all_refs_stored_in_loop.quick_push (empty);
}
--- 1684,1689
*** for_all_locs_in_loop (struct loop *loop,
*** 1749,1760
{
unsigned i;
mem_ref_loc_p loc;
- bitmap refs = memory_accesses.all_refs_in_loop[loop-num];
struct loop *subloop;
- if (!bitmap_bit_p (refs, ref-id))
- return false;
-
if (ref-accesses_in_loop.length () (unsigned) loop-num)
FOR_EACH_VEC_ELT (ref-accesses_in_loop[loop-num], i, loc)
if (fn (loc))
--- 1738,1745
*** tree_ssa_lim_finalize (void)
*** 2630,2636
memory_accesses.refs_in_loop.release ();
memory_accesses.refs_stored_in_loop.release ();
- memory_accesses.all_refs_in_loop.release ();
memory_accesses.all_refs_stored_in_loop.release ();
if (memory_accesses.ttae_cache)
--- 2615,2620
[PATCH] Remove the reference dependence check cache from LIM
The following patch finally removes the reference dependence check cache.
Its benefit is too low for its cost. LIM Compile-time for PR39326
improves from 100s to 50s and LIMs memory use drops to unnoticable
(from 915MB memory use after LIM to 380MB memory use after LIM).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-03-22 Richard Biener rguent...@suse.de
* tree-ssa-loop-im.c (struct mem_ref): Remove indep_ref and
dep_ref members.
(mem_ref_alloc): Do not allocate them.
(refs_independent_p): Do not query or maintain a cache.
Index: trunk/gcc/tree-ssa-loop-im.c
===
*** trunk.orig/gcc/tree-ssa-loop-im.c 2013-03-22 12:25:13.633716049 +0100
--- trunk/gcc/tree-ssa-loop-im.c2013-03-22 12:35:18.086448436 +0100
*** typedef struct mem_ref
*** 134,143
If it is only loaded, then it is independent
on all stores in the loop. */
bitmap dep_loop;/* The complement of INDEP_LOOP. */
-
- bitmap indep_ref; /* The set of memory references on that
- this reference is independent. */
- bitmap dep_ref; /* The complement of INDEP_REF. */
} *mem_ref_p;
/* We use two bits per loop in the ref-{in,}dep_loop bitmaps, the first
--- 134,139
*** mem_ref_alloc (tree mem, unsigned hash,
*** 1482,1489
ref-stored = BITMAP_ALLOC (lim_bitmap_obstack);
ref-indep_loop = BITMAP_ALLOC (lim_bitmap_obstack);
ref-dep_loop = BITMAP_ALLOC (lim_bitmap_obstack);
- ref-indep_ref = BITMAP_ALLOC (lim_bitmap_obstack);
- ref-dep_ref = BITMAP_ALLOC (lim_bitmap_obstack);
ref-accesses_in_loop.create (0);
return ref;
--- 1478,1483
*** refs_independent_p (mem_ref_p ref1, mem_
*** 2228,2260
if (ref1 == ref2)
return true;
- /* Reference dependence in a loop is symmetric. */
- if (ref1-id ref2-id)
- {
- mem_ref_p tem = ref1;
- ref1 = ref2;
- ref2 = tem;
- }
-
- if (bitmap_bit_p (ref1-indep_ref, ref2-id))
- return true;
- if (bitmap_bit_p (ref1-dep_ref, ref2-id))
- return false;
-
if (dump_file (dump_flags TDF_DETAILS))
fprintf (dump_file, Querying dependency of refs %u and %u: ,
ref1-id, ref2-id);
if (mem_refs_may_alias_p (ref1, ref2, memory_accesses.ttae_cache))
{
- bitmap_set_bit (ref1-dep_ref, ref2-id);
if (dump_file (dump_flags TDF_DETAILS))
fprintf (dump_file, dependent.\n);
return false;
}
else
{
- bitmap_set_bit (ref1-indep_ref, ref2-id);
if (dump_file (dump_flags TDF_DETAILS))
fprintf (dump_file, independent.\n);
return true;
--- ,2239
Re: C++ PATCH: use identifier_p instead of naked TREE_CODE == IDENTIFIER_NODE
Jakub Jelinek ja...@redhat.com writes: | On Fri, Mar 22, 2013 at 10:21:05AM +0100, Richard Biener wrote: | On Fri, Mar 22, 2013 at 4:50 AM, Gabriel Dos Reis g...@axiomatics.org wrote: | | This patch introduces identified_p (t) in lieu of | | TREE_CODE (t) == IDENTIFIER_NODE | | Generally we have macros like IDENTIFIER_P for this kind of checks. I know we have macros for this kind of test, and what what I can tell looking at the source code, nobody actually bothered using it. The point of the change isn't to do that test exactly. As I explained earlier, the change was prompted by looking at patterns of usage inf the existing source code: it is very frequent that we would test XXX_P (t) and immediately do XXX_GET_YYY (t) when XXX_GET_YYY will do a XXX_CHECK (t), which morally tests again XXX_P (t), and this is all over the places. The reason why XXX_GET_YYY (t) does XXX_CHECK (t) is because it could be mistakenly used on a different node since t isn't typed. | | in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST | except that it returns a typed pointer instead of a boolean value. | | Hm? So you are replacing TREE_CODE (t) == IDENTIFIER_NODE | with kind-of dynamic_castidentifier (t) (in C++ terms)? Then | naming it identifier_p is bad. We have is-a.h now, so please try to use | a single style of C++-style casting throughout GCC. | | Anyway, if you see better code generated with your change compared to the | old style, I'd say you should file a PR with some preferrably short | preprocessed routine where it makes a difference, because that would show | that either VRP or other optimization pass just isn't doing good job. We are talking about files in cp/ right? They don't know what short means:-) With the next change, I'll try to find a short file, although currently I am working on cp/name-lookup.c | It is better code for --enable-checking=yes anyway, right? Yes. -- Gaby
Re: C++ PATCH: use identifier_p instead of naked TREE_CODE == IDENTIFIER_NODE
Richard Biener richard.guent...@gmail.com writes: [...] | in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST | except that it returns a typed pointer instead of a boolean value. | | Hm? So you are replacing TREE_CODE (t) == IDENTIFIER_NODE | with kind-of dynamic_castidentifier (t) (in C++ terms)? It would be a mistake to name it dynamic_cast or anything like cast (I know it is popular in certain C++ circles to name everything xxx_cast), because dynamic_cast is an implementation detail. I should probably have called it give_me_identifier_pointer_if_operand_points_to_a_cxx_identifier_object | Then | naming it identifier_p is bad. We have is-a.h now, so please try to use | a single style of C++-style casting throughout GCC. I strongly agree with consistent style, On the other hand, isn't someone going to object that is_xxx has a predicate connotation therefore a bad naming because it isn't returning a bool? I think a naming that focuses too much on implementation detail is no good, -- Gaby
Re: [PATCH] Fix for movmode_internal pattern
Do you have a testcase to show there is a problem?
The misaligned case should only be generated from
ix86_avx256_split_vector_move_misalign.
I faced it when playing with optimized expanding of memmov (with
vector instructions). There I generated v2di-move with emit_strmov,
which later used *movv2di_internal pattern, and there aligned
version was chosen because (TARGET_AVX) was false. Probably, that's
not how emit_strmov should've been used, but then it'd be cool to have
an assert or an additional check somewhere, which would tell me, that
I'm using some function in a wrong way.
So, I guess it's true that in trunk everything is ok here and the
misaligned case could only come from
ix86_avx256_split_vector_move_misalign - nevertheless, this place
seems to me a bit untidy.
On 21 March 2013 21:27, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Mar 21, 2013 at 9:36 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi,
I've found a little bit strange code in movmode_internal
RTL-pattern from config/i386/sse.md:
case MODE_V2DF:
if (TARGET_AVX
(misaligned_operand (operands[0], MODEmode)
|| misaligned_operand (operands[1], MODEmode)))
return vmovupd\t{%1, %0|%0, %1};
else
return %vmovapd\t{%1, %0|%0, %1};
That could lead to generation of vmovapd for misaligned operands. Was
there any special intention behind that, or is that just a bug?
Attached is a patch that removes TARGET_AVX from the condition, thus
preventing generation of movapd for misaligned operands and enabling
generation of movupd for them.
If the patch is ok, could anyone please commit it? Of course, that
could wait until 4.8 is released.
Bootstrapped and tested on x86_64-unknown-linux-gnu and i686-linux.
Changelog:
2013-03-21 Michael Zolotukhin michael.v.zolotuk...@gmail.com
* config/i386/sse.md (*movmode_internal): Fix condition.
--
Do you have a testcase to show there is a problem?
The misaligned case should only be generated from
ix86_avx256_split_vector_move_misalign.
--
H.J.
--
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.
Re: C++ PATCH: use identifier_p instead of naked TREE_CODE == IDENTIFIER_NODE
On Fri, Mar 22, 2013 at 1:44 PM, Gabriel Dos Reis g...@axiomatics.org wrote:
Richard Biener richard.guent...@gmail.com writes:
[...]
| in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST
| except that it returns a typed pointer instead of a boolean value.
|
| Hm? So you are replacing TREE_CODE (t) == IDENTIFIER_NODE
| with kind-of dynamic_castidentifier (t) (in C++ terms)?
It would be a mistake to name it dynamic_cast or anything like cast (I
know it is popular in certain C++ circles to name everything xxx_cast),
because dynamic_cast is an implementation detail. I should probably
have called it
give_me_identifier_pointer_if_operand_points_to_a_cxx_identifier_object
| Then
| naming it identifier_p is bad. We have is-a.h now, so please try to use
| a single style of C++-style casting throughout GCC.
I strongly agree with consistent style, On the other hand, isn't someone
going
to object that is_xxx has a predicate connotation therefore a bad naming
because it isn't returning a bool?
I think a naming that focuses too much on implementation detail is no good,
Neither is one that is confusing ;)
That said - your specific identifier case should be generalized. The cgraph
people had exactly the same issue, given a symtab * return a cgraph *
if the symbol is a function, otherwise NULL, combining the previous
if (symbol == function) fn = get-me-a-function (symbol)
And they invented is-a.h as we settled for a template approach which
more readily mimics what the C++ language provides (in form of
static_cast, dynamic_cast, etc.).
The tree node case is subtly different because we are not actually casting
anything (you are not returning a more specific type than tree) but still
you provide a more C++-ish form to the standard tree.h interfaces.
That is, plain use of is-a.h is possible for your case:
template
inline lang_identifier *
as_a (tree p)
{
if (TREE_CODE (p) == IDENTIFIER_NODE)
return (lang_identifier *)p;
return NULL;
}
following existing GCC style (and yes, we've bikeshedded over that
already).
Thus you'd write
as_alang_identifier (id)
instead of your
identifier_p (id)
(which should have been lang_identifier_p instead).
Richard.
-- Gaby
[PATCH] Use gcc_checking_assert in as_a
Committed as obvious.
Richard.
2013-03-22 Richard Biener rguent...@suse.de
* is-a.h (as_a): Use gcc_checking_assert.
Index: gcc/is-a.h
===
--- gcc/is-a.h (revision 196955)
+++ gcc/is-a.h (working copy)
@@ -181,7 +181,7 @@ template typename T, typename U
inline T *
as_a (U *p)
{
- gcc_assert (is_a T (p));
+ gcc_checking_assert (is_a T (p));
return is_a_helper T::cast (p);
}
Re: [PATCH] Fix PR56434
On Fri, Mar 22, 2013 at 3:27 AM, Richard Biener rguent...@suse.de wrote: I think the wrong-code fix is orthogonal to code improvements which will also trigger on the GIMPLE level (and where they will have a bigger impact). I agree. I think the patch to calls is fine unless Jakub objects. We can for example, in config/linux.h do #if OPTION_GLIBC #undef MALLOC_ABI_ALIGNMENT #define MALLOC_ABI_ALIGNMENT (2 * sizeof (void *)) #endif if that's what glibc really guarantees (does it maybe have a feature macro for this?) The code in glibc seems to be in malloc.c only. The most conservative version seems to be #define INTERNAL_SIZE_T size_t #define SIZE_SZ(sizeof(INTERNAL_SIZE_T)) # define MALLOC_ALIGNMENT (2 * SIZE_SZ) In GCC terms this would be 2 * int_size_in_bytes (size_type_node). Ian
Re: [PATCH] Fix PR56434
On Fri, 22 Mar 2013, Ian Lance Taylor wrote: On Fri, Mar 22, 2013 at 3:27 AM, Richard Biener rguent...@suse.de wrote: I think the wrong-code fix is orthogonal to code improvements which will also trigger on the GIMPLE level (and where they will have a bigger impact). I agree. I think the patch to calls is fine unless Jakub objects. We can for example, in config/linux.h do #if OPTION_GLIBC #undef MALLOC_ABI_ALIGNMENT #define MALLOC_ABI_ALIGNMENT (2 * sizeof (void *)) #endif if that's what glibc really guarantees (does it maybe have a feature macro for this?) The code in glibc seems to be in malloc.c only. The most conservative version seems to be #define INTERNAL_SIZE_T size_t #define SIZE_SZ(sizeof(INTERNAL_SIZE_T)) # define MALLOC_ALIGNMENT (2 * SIZE_SZ) In GCC terms this would be 2 * int_size_in_bytes (size_type_node). Or, given /* Define what type to use for size_t. */ if (strcmp (SIZE_TYPE, unsigned int) == 0) size_type_node = unsigned_type_node; ... #define MALLOC_ABI_ALIGNMENT (2 * sizeof (### magic un-stringify SIZE_TYPE)) eh ... is there a more convenient way to access the targets size_t? It's a target macro still ... not often used, so even #define MALLOC_ABI_ALIGNMENT (2 * TREE_INT_CST_LOW (TYPE_SIZE_UNIT (size_type_node))) would probably work, but ... Richard.
[committed] Use automake no-dist for libsanitizer (PR other/43620)
Hi!
Ugh, this hit us again, going to note it into releasing.html later.
libsanitizer Makefiles/configure are owned by GCC, so we can use no-dist
here on the trunk too. Committed as obvious.
2013-03-22 Jakub Jelinek ja...@redhat.com
PR other/43620
libsanitizer/
* configure.ac (AM_INIT_AUTOMAKE): Add no-dist.
* Makefile.in: Regenerated.
* asan/Makefile.in: Regenerated.
* interception/Makefile.in: Regenerated.
* sanitizer_common/Makefile.in: Regenerated.
* tsan/Makefile.in: Regenerated.
--- libsanitizer/configure.ac (revision 196963)
+++ libsanitizer/configure.ac (working copy)
@@ -23,7 +23,7 @@ target_alias=${target_alias-$host_alias}
AC_SUBST(target_alias)
GCC_LIBSTDCXX_RAW_CXX_FLAGS
-AM_INIT_AUTOMAKE(foreign)
+AM_INIT_AUTOMAKE(foreign no-dist)
AM_ENABLE_MULTILIB(, ..)
AM_MAINTAINER_MODE
--- libsanitizer/Makefile.in(revision 196963)
+++ libsanitizer/Makefile.in(working copy)
@@ -35,11 +35,9 @@ build_triplet = @build@
host_triplet = @host@
target_triplet = @target@
subdir = .
-DIST_COMMON = $(am__configure_deps) $(srcdir)/../config.guess \
- $(srcdir)/../config.sub $(srcdir)/../install-sh \
- $(srcdir)/../ltmain.sh $(srcdir)/../missing \
- $(srcdir)/../mkinstalldirs $(srcdir)/Makefile.am \
- $(srcdir)/Makefile.in $(top_srcdir)/configure ChangeLog
+DIST_COMMON = ChangeLog $(srcdir)/Makefile.in $(srcdir)/Makefile.am \
+ $(top_srcdir)/configure $(am__configure_deps) \
+ $(srcdir)/../mkinstalldirs
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
$(top_srcdir)/../config/depstand.m4 \
@@ -59,7 +57,6 @@ mkinstalldirs = $(SHELL) $(top_srcdir)/.
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
SOURCES =
-DIST_SOURCES =
MULTISRCTOP =
MULTIBUILDTOP =
MULTIDIRS =
@@ -76,47 +73,10 @@ RECURSIVE_TARGETS = all-recursive check-
RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive\
distclean-recursive maintainer-clean-recursive
AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
- $(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
- distdir dist dist-all distcheck
+ $(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS
ETAGS = etags
CTAGS = ctags
DIST_SUBDIRS = interception sanitizer_common asan tsan
-DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
-distdir = $(PACKAGE)-$(VERSION)
-top_distdir = $(distdir)
-am__remove_distdir = \
- { test ! -d $(distdir) \
-|| { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
- rm -fr $(distdir); }; }
-am__relativize = \
- dir0=`pwd`; \
- sed_first='s,^\([^/]*\)/.*$$,\1,'; \
- sed_rest='s,^[^/]*/*,,'; \
- sed_last='s,^.*/\([^/]*\)$$,\1,'; \
- sed_butlast='s,/*[^/]*$$,,'; \
- while test -n $$dir1; do \
-first=`echo $$dir1 | sed -e $$sed_first`; \
-if test $$first != .; then \
- if test $$first = ..; then \
-dir2=`echo $$dir0 | sed -e $$sed_last`/$$dir2; \
-dir0=`echo $$dir0 | sed -e $$sed_butlast`; \
- else \
-first2=`echo $$dir2 | sed -e $$sed_first`; \
-if test $$first2 = $$first; then \
- dir2=`echo $$dir2 | sed -e $$sed_rest`; \
-else \
- dir2=../$$dir2; \
-fi; \
-dir0=$$dir0/$$first; \
- fi; \
-fi; \
-dir1=`echo $$dir1 | sed -e $$sed_rest`; \
- done; \
- reldir=$$dir2
-DIST_ARCHIVES = $(distdir).tar.gz
-GZIP_ENV = --best
-distuninstallcheck_listfiles = find . -type f -print
-distcleancheck_listfiles = find . -type f -print
ACLOCAL = @ACLOCAL@
AMTAR = @AMTAR@
AR = @AR@
@@ -490,182 +450,6 @@ GTAGS:
distclean-tags:
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
-
-distdir: $(DISTFILES)
- $(am__remove_distdir)
- test -d $(distdir) || mkdir $(distdir)
- @srcdirstrip=`echo $(srcdir) | sed 's/[].[^$$\\*]//g'`; \
- topsrcdirstrip=`echo $(top_srcdir) | sed 's/[].[^$$\\*]//g'`; \
- list='$(DISTFILES)'; \
- dist_files=`for file in $$list; do echo $$file; done | \
- sed -e s|^$$srcdirstrip/||;t \
- -e s|^$$topsrcdirstrip/|$(top_builddir)/|;t`; \
- case $$dist_files in \
- */*) $(MKDIR_P) `echo $$dist_files | \
- sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
- sort -u` ;; \
- esac; \
- for file in $$dist_files; do \
- if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
- if test -d $$d/$$file; then \
- dir=`echo /$$file | sed -e 's,/[^/]*$$,,'`; \
- if test -d $(distdir)/$$file; then \
- find $(distdir)/$$file -type d ! -perm -700 -exec chmod u+rwx
{} \;; \
- fi; \
- if test -d $(srcdir)/$$file test $$d != $(srcdir); then \
- cp -fpR $(srcdir)/$$file $(distdir)$$dir || exit 1; \
- find $(distdir)/$$file -type d ! -perm -700
Re: C++ PATCH: use identifier_p instead of naked TREE_CODE == IDENTIFIER_NODE
Richard Biener richard.guent...@gmail.com writes:
| On Fri, Mar 22, 2013 at 1:44 PM, Gabriel Dos Reis g...@axiomatics.org wrote:
| Richard Biener richard.guent...@gmail.com writes:
|
| [...]
|
| | in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST
| | except that it returns a typed pointer instead of a boolean value.
| |
| | Hm? So you are replacing TREE_CODE (t) == IDENTIFIER_NODE
| | with kind-of dynamic_castidentifier (t) (in C++ terms)?
|
| It would be a mistake to name it dynamic_cast or anything like cast (I
| know it is popular in certain C++ circles to name everything xxx_cast),
| because dynamic_cast is an implementation detail. I should probably
| have called it
give_me_identifier_pointer_if_operand_points_to_a_cxx_identifier_object
|
| | Then
| | naming it identifier_p is bad. We have is-a.h now, so please try to use
| | a single style of C++-style casting throughout GCC.
|
| I strongly agree with consistent style, On the other hand, isn't someone
going
| to object that is_xxx has a predicate connotation therefore a bad naming
| because it isn't returning a bool?
|
| I think a naming that focuses too much on implementation detail is no good,
|
| Neither is one that is confusing ;)
You make good points below.
I have one quibble -- since I was provoked into bike shedding :-)
|
| That said - your specific identifier case should be generalized. The cgraph
| people had exactly the same issue, given a symtab * return a cgraph *
| if the symbol is a function, otherwise NULL, combining the previous
| if (symbol == function) fn = get-me-a-function (symbol)
|
| And they invented is-a.h as we settled for a template approach which
| more readily mimics what the C++ language provides (in form of
| static_cast, dynamic_cast, etc.).
|
| The tree node case is subtly different because we are not actually casting
| anything (you are not returning a more specific type than tree) but still
| you provide a more C++-ish form to the standard tree.h interfaces.
|
| That is, plain use of is-a.h is possible for your case:
|
| template
| inline lang_identifier *
| as_a (tree p)
| {
| if (TREE_CODE (p) == IDENTIFIER_NODE)
| return (lang_identifier *)p;
| return NULL;
| }
|
| following existing GCC style (and yes, we've bikeshedded over that
| already).
I would have dropped the suffix _a on both is_a and as_a, did
I get a chance to bike shed when is-a.h was introduced.
I will add the specialization and use it the appropriate places.
|
| Thus you'd write
|
|as_alang_identifier (id)
|
| instead of your
|
|identifier_p (id)
|
| (which should have been lang_identifier_p instead).
-- Gaby
Re: [PATCH][ARM][2/2] Load-acquire, store-release atomics in AArch32 ARMv8
On 01/02/13 17:38, Kyrylo Tkachov wrote: Ummm... forgot the patch, sorry! -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov Sent: 01 February 2013 17:37 To: gcc-patches@gcc.gnu.org Cc: Ramana Radhakrishnan; Richard Earnshaw; Marcus Shawcroft Subject: [PATCH][ARM][2/2] Load-acquire, store-release atomics in AArch32 ARMv8 Hi all, This patch adds the tests for the ARMv8 AArch32 implementation of atomics. It refactors some aarch64 tests and reuses them. Ok for trunk or for the next stage 1 (together with part 1 at http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01441.html)? Thanks, Kyrill gcc/testsuite/ChangeLog 2013-01-25 Kyrylo Tkachov kyrylo.tkachov at arm.com * gcc.target/aarch64/atomic-comp-swap-release-acquire.c: Move test body from here... * gcc.target/aarch64/atomic-comp-swap-release-acquire.x: ... to here. * gcc.target/aarch64/atomic-op-acq_rel.c: Move test body from here... * gcc.target/aarch64/atomic-op-acq_rel.x: ... to here. * gcc.target/aarch64/atomic-op-acquire.c: Move test body from here... * gcc.target/aarch64/atomic-op-acquire.x: ... to here. * gcc.target/aarch64/atomic-op-char.c: Move test body from here... * gcc.target/aarch64/atomic-op-char.x: ... to here. * gcc.target/aarch64/atomic-op-consume.c: Move test body from here... * gcc.target/aarch64/atomic-op-consume.x: ... to here. * gcc.target/aarch64/atomic-op-int.c: Move test body from here... * gcc.target/aarch64/atomic-op-int.x: ... to here. * gcc.target/aarch64/atomic-op-relaxed.c: Move test body from here... * gcc.target/aarch64/atomic-op-relaxed.x: ... to here. * gcc.target/aarch64/atomic-op-release.c: Move test body from here... * gcc.target/aarch64/atomic-op-release.x: ... to here. * gcc.target/aarch64/atomic-op-seq_cst.c: Move test body from here... * gcc.target/aarch64/atomic-op-seq_cst.x: ... to here. * gcc.target/aarch64/atomic-op-short.c: Move test body from here... * gcc.target/aarch64/atomic-op-short.x: ... to here. * gcc.target/arm/atomic-comp-swap-release-acquire.c: New test. * gcc.target/arm/atomic-op-acq_rel.c: Likewise. * gcc.target/arm/atomic-op-acquire.c: Likewise. * gcc.target/arm/atomic-op-char.c: Likewise. * gcc.target/arm/atomic-op-consume.c: Likewise. * gcc.target/arm/atomic-op-int.c: Likewise. * gcc.target/arm/atomic-op-relaxed.c: Likewise. * gcc.target/arm/atomic-op-release.c: Likewise. * gcc.target/arm/atomic-op-seq_cst.c: Likewise. * gcc.target/arm/atomic-op-short.c: Likewise. OK. R.
Re: [patch i386]: Treat dllimported symbol as external in predicates
On 03/22/2013 01:03 AM, Kai Tietz wrote: * config/i386/predicates.md (local_symbolic_operand): Interprete dll-imported symbols as none-local. Ok. r~
Re: [PATCH][ARM][1/2] Load-acquire, store-release atomics in AArch32 ARMv8
On 30/01/13 15:54, Kyrylo Tkachov wrote:
Hi all,
This patch implements the atomic built-ins using the new ARMv8 load-acquire
and store-release instructions.
They allow us to generate barrier-free code for a variety of atomic
operations such as: atomic load, atomic store, atomic compare and swap,
atomic {or, and, add, sub, xor}.
Tests will come in a separate patch soon.
No regressions on arm-none-eabi. Bootstrap on armv7l-unknown-linux-gnueabihf
successful.
Ok for trunk (now or when stage 1 reopens)?
Thanks,
Kyrill
gcc/ChangeLog
2013-01-23 Kyrylo Tkachov kyrylo.tkachov at arm.com
* config/arm/arm.c (arm_emit_load_exclusive): Add acq parameter.
Emit load-acquire versions when acq is true.
(arm_emit_store_exclusive): Add rel parameter.
Emit store-release versions when rel is true.
(arm_split_compare_and_swap): Use acquire-release instructions
instead
of barriers when appropriate.
(arm_split_atomic_op): Likewise.
* config/arm/arm.h (TARGET_HAVE_LDACQ): New macro.
* config/arm/unspecs.md (VUNSPEC_LAX): New unspec.
(VUNSPEC_SLX): Likewise.
(VUNSPEC_LDA): Likewise.
(VUNSPEC_STL): Likewise.
* config/arm/sync.md (atomic_loadmode): New pattern.
(atomic_storemode): Likewise.
(arm_load_acquire_exclusivemode): Likewise.
(arm_load_acquire_exclusivesi): Likewise.
(arm_load_acquire_exclusivedi): Likewise.
(arm_store_release_exclusivemode): Likewise.
atomics.txt
@@ -26067,6 +26099,15 @@ arm_expand_compare_and_swap (rtx operands[])
mod_f = operands[7];
mode = GET_MODE (mem);
+ /* Normally the succ memory model must be stronger than fail, but in the
+ unlikely event of fail being ACQUIRE and succ being RELEASE we need to
+ promote succ to ACQ_REL so that we don't lose the acquire semantics. */
Can you double check the indentation here. The 'u' from 'unlikely'
should line up with the 'N' from 'Normally'.
Otherwise OK.
R.
Ca
Re: [PATCH] Fix for movmode_internal pattern
On Fri, Mar 22, 2013 at 5:49 AM, Michael Zolotukhin michael.v.zolotuk...@gmail.com wrote: Do you have a testcase to show there is a problem? The misaligned case should only be generated from ix86_avx256_split_vector_move_misalign. I faced it when playing with optimized expanding of memmov (with vector instructions). There I generated v2di-move with emit_strmov, You can't use aligned vector move if alignment is unknown or not properly aligned. which later used *movv2di_internal pattern, and there aligned version was chosen because (TARGET_AVX) was false. Probably, that's not how emit_strmov should've been used, but then it'd be cool to have an assert or an additional check somewhere, which would tell me, that I'm using some function in a wrong way. So, I guess it's true that in trunk everything is ok here and the misaligned case could only come from ix86_avx256_split_vector_move_misalign - nevertheless, this place seems to me a bit untidy. In ix86_expand_vector_move_misalign, we generate different SSE unaligned load/store, depending on optimization option. For AVX, we just use 256-bit unaligned load/store or split it to 128-bit normal load/store since there is no performance difference between normal load/store vs unaligned load/store on aligned memory. -- H.J.
Re: [PATCH] Fix for movmode_internal pattern
You can't use aligned vector move if alignment is unknown or not properly aligned. Yes, sure. But I just emit V2DI move for an operands, which are aligned to 64-bit (not 128-bit!) - and it's encoded into movdqa which is obviously incorrect. The compiler knows, that operands are misaligned, but the check is (TARGET_AVX (misaligned_operand(op0) || misaligned_operand(op1)) - in case when TARGET_AVX is false it doesn't matter whether operands are misaligned or not (in this check) - the compiler will always emit movdqa. I understand that this check wasn't used for such cases before and probably isn't intended for that. But in this case, it needs some guarding checks I guess. On 22 March 2013 20:30, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Mar 22, 2013 at 5:49 AM, Michael Zolotukhin michael.v.zolotuk...@gmail.com wrote: Do you have a testcase to show there is a problem? The misaligned case should only be generated from ix86_avx256_split_vector_move_misalign. I faced it when playing with optimized expanding of memmov (with vector instructions). There I generated v2di-move with emit_strmov, You can't use aligned vector move if alignment is unknown or not properly aligned. which later used *movv2di_internal pattern, and there aligned version was chosen because (TARGET_AVX) was false. Probably, that's not how emit_strmov should've been used, but then it'd be cool to have an assert or an additional check somewhere, which would tell me, that I'm using some function in a wrong way. So, I guess it's true that in trunk everything is ok here and the misaligned case could only come from ix86_avx256_split_vector_move_misalign - nevertheless, this place seems to me a bit untidy. In ix86_expand_vector_move_misalign, we generate different SSE unaligned load/store, depending on optimization option. For AVX, we just use 256-bit unaligned load/store or split it to 128-bit normal load/store since there is no performance difference between normal load/store vs unaligned load/store on aligned memory. -- H.J. -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation.
[cilkplus-merge] fix various wrapping issues and correct some docs wording
I am committing the following changes as obvious. They include some
wrapping issues, as well as some minor wording issues I found while
peeking around.
Joseph, I am posting this as an incremental patch, to avoid posting a 7k
line patch for everything. I have also asked Balaji to post incremental
patches as he iterates with you-- at least on these initial style
reviews-- to aid in reviewing. Then perhaps after this round is done,
we can post a toplevel patch once again with everything so far in the
branch, and start the process again. If you dislike this approach let
me know, and we revert to toplevel patches, or perhaps something else.
Aldy
commit 4f4932be8230284919d197cccb4b10201f82a0b3
Author: Aldy Hernandez al...@redhat.com
Date: Fri Mar 22 13:07:57 2013 -0500
Cleanup various typos and wrapping issues.
diff --git a/gcc/c-family/c-common.def b/gcc/c-family/c-common.def
index a5e3220..4d14fcf 100644
--- a/gcc/c-family/c-common.def
+++ b/gcc/c-family/c-common.def
@@ -56,7 +56,8 @@ DEFTREECODE (USERDEF_LITERAL, userdef_literal,
tcc_exceptional, 3)
DEFTREECODE (SIZEOF_EXPR, sizeof_expr, tcc_expression, 1)
/* Array Notation expression.
- Operand 0 is the array; operand 1 is the starting array index
+ Operand 0 is the array.
+ Operand 1 is the starting array index.
Operand 2 contains the number of elements you need to access.
Operand 3 is the stride.
Operand 4 is the element size measured in units of alignments of
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 1726a4b..edcff2e 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1137,8 +1137,8 @@ enum stv_conv {
extern enum stv_conv scalar_to_vector (location_t loc, enum tree_code code,
tree op0, tree op1, bool);
-/* These #defines allow users to access different operands of the
- array notation tree. */
+/* These #defines allow users to access different operands of the
+ array notation tree. */
#define ARRAY_NOTATION_CHECK(NODE) TREE_CHECK (NODE, ARRAY_NOTATION_REF)
#define ARRAY_NOTATION_ARRAY(NODE) \
diff --git a/gcc/doc/generic.texi b/gcc/doc/generic.texi
index e4699ca..6f6f792 100644
--- a/gcc/doc/generic.texi
+++ b/gcc/doc/generic.texi
@@ -1140,13 +1140,14 @@ directly; call @code{array_ref_low_bound} and
@code{array_ref_element_size}
instead.
@item ARRAY_NOTATION_REF
-These nodes represent array notation expressions that are part of the Cilk Plus
-language extensions (enabled by @option{-fcilkplus} flag). The first operand
-is the array. Second, third and fourth operands are the start-index, number of
-elements accessed (also called length) and the stride, respectively. The
-fifth operand holds the array type. Around the end of the parsing stage,
-these array notations are broken up into array references (@code{ARRAY_REF})
-enclosed inside a loop iterating from 0 to the number of elements accessed.
+These nodes represent array notation expressions that are part of the
+Cilk Plus language extensions (enabled by the @option{-fcilkplus}
+flag). The first operand is the array. The second, third, and fourth
+operands are the start-index, number of elements accessed (also called
+length) and the stride, respectively. The fifth operand holds the
+array type. Near the end of the parsing stage, these array notations
+are broken up into array references (@code{ARRAY_REF}) enclosed inside
+a loop iterating from 0 to the number of elements accessed.
@item ARRAY_RANGE_REF
These nodes represent access to a range (or ``slice'') of an array. The
RE: FW: [PATCH] [MIPS] microMIPS gcc support
-Original Message- From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Sent: Thursday, March 21, 2013 8:04 PM To: Moore, Catherine Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support Thanks, this is almost there now. It was only the problem with the new version of the move pattern (see below) that stopped this from being OK with The next round should be a formality though. Okay, modifications now made and patch attached. Moore, Catherine catherine_mo...@mentor.com writes: +(define_constraint Uuw6 + @internal + An unsigned constant of 6 bits. + (match_operand 0 uw6_operand)) , shifted left two places. + (and (ior (eq_attr compression micromips) + (eq_attr compression all)) Please use (eq_attr compression micromips,all) instead. (define_insn submode3 - [(set (match_operand:GPR 0 register_operand =d) - (minus:GPR (match_operand:GPR 1 register_operand d) - (match_operand:GPR 2 register_operand d)))] + [(set (match_operand:GPR 0 register_operand =!u,d) + (minus:GPR (match_operand:GPR 1 register_operand !u,d) + (match_operand:GPR 2 register_operand !u,d)))] - dsubu\t%0,%1,%2 + @ + dsubu\t%0,%1,%2 + dsubu\t%0,%1,%2 This change isn't needed. It's OK (and IMO better) to keep a single asm string when the string is the same for all alternatives. @@ -4362,13 +4400,14 @@ ;; in FP registers (off by default, use -mdebugh to enable). (define_insn *movmode_internal - [(set (match_operand:IMOVE32 0 nonimmediate_operand =d,d,e,d,m,*f,*f,*d,*m,*d,*z,*a,*d,*B*C*D,*B*C*D,*d,*m) - (match_operand:IMOVE32 1 move_operand d,Yd,Yf,m,dJ,*d*J,*m,*f,*f,*z,*d,*J*d,*a,*d,*m,*B*C*D,*B*C*D))] + [(set (match_operand:IMOVE32 0 nonimmediate_operand =d,!u,d,e,!u,!u,!u,!u,!ks,d,ZS,ZV,ZU,ZT,m,*f,*f,*d,*m,*d,*z,*a,*d,*B*C*D, *B*C*D,*d,*m) + (match_operand:IMOVE32 1 move_operand +d,J,Yd,Yf,Udb7,ZW,ZU,ZT,ZS,m,!ks,!u,!u,!u,dJ,*d*J,*m,*f,*f,*z,*d,*J* +d,*a,*d,*m,*B*C*D,*B*C*D))] This pattern is only for 32-bit moves, so should only use ZS and ZT. (I don't mind keeping the definitions of the ZU...ZW constraints in this patch - - even though they start out unused -- because it's obvious they'll be needed eventually. I'd prefer leaving the 8-bit and 16-move patterns themselves to a different patch though.) Sorry, I should have noticed last time, but alternative 5 (u-Udb7) should come before alternative 3 (d-Yd), because d-Yd includes everything that u-Udb7 does. +extern bool m16_based_address_p (rtx, enum machine_mode, int +(*)(rtx_def*, machine_mode)); Line too long: should be split after the first enum machine_mode. Thanks, Richard short-delay-03-22.cl Description: short-delay-03-22.cl short-delay-03-22.patch Description: short-delay-03-22.patch
[PATCH 4/n, i386]: Merge and rewrite MMX move patterns using x64 and nox64 isa attribute
Hello!
Attached patch merges _rex64 MMX move patterns with base MMX move
patters using x64 and nox64 isa attribute. Additionally, the patch
rewrites MMX move patterns to look like DImove move pattern (keeping
all decorations of various alternatives), introducing all recent
improvements. The patch also handles MMX/SSE interunit moves in a
correct way for non-TARGET_INTER_UNIT_MOVES targets (this is the
reason for testsuite change).
A follow-up patch will merge V2SF move pattern.
2013-03-22 Uros Bizjak ubiz...@gmail.com
* config/i386/sse.md (*movmode_internal): Merge with
*movmode_internal_rex64. Use x64 and nox64 isa attributes.
Emit insn template depending on type attribute. Use
HAVE_AS_IX86_INTERUNIT_MOVQ to handle broken assemblers that require
movd instead of movq mnemonic for interunit moves. Rewrite mode
attribute calculation. Remove unit attribute calculation.
Set prefix attribute to maybe_vex for sselog1 and ssemov types.
Set prefix_data16 attribute for DImode ssemov types.
Use Ym instead of y for SSE-MMX conversion alternatives.
Reorder operand constraints.
testsuite/ChangeLog:
2013-03-22 Uros Bizjak ubiz...@gmail.com
* gcc.target/i386/pr22152.c (dg-options): Add -mtune=core2.
Patch was tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline.
Uros.
Index: config/i386/mmx.md
===
--- config/i386/mmx.md (revision 196970)
+++ config/i386/mmx.md (working copy)
@@ -76,129 +76,127 @@
DONE;
})
-;; movd instead of movq is required to handle broken assemblers.
-(define_insn *movmode_internal_rex64
+(define_insn *movmode_internal
[(set (match_operand:MMXMODEI8 0 nonimmediate_operand
-=rm,r,!?y,!y,!?y,m ,!y ,*x,x,x ,m,r ,Yi)
+=r ,o ,r,r ,m ,!?y,!y,!?y,m ,x,x,x,m,*x,*x,*x,m ,r ,Yi,!Ym,*Yi)
(match_operand:MMXMODEI8 1 vector_move_operand
-Cr ,m,C ,!y,m ,!?y,*x,!y ,C,xm,x,Yi,r))]
- TARGET_64BIT TARGET_MMX
+rCo,rC,C,rm,rC,C ,!y,m ,!?y,C,x,m,x,C ,*x,m ,*x,Yi,r ,*Yi,!Ym))]
+ TARGET_MMX
!(MEM_P (operands[0]) MEM_P (operands[1]))
- @
-mov{q}\t{%1, %0|%0, %1}
-mov{q}\t{%1, %0|%0, %1}
-pxor\t%0, %0
-movq\t{%1, %0|%0, %1}
-movq\t{%1, %0|%0, %1}
-movq\t{%1, %0|%0, %1}
-movdq2q\t{%1, %0|%0, %1}
-movq2dq\t{%1, %0|%0, %1}
-%vpxor\t%0, %d0
-%vmovq\t{%1, %0|%0, %1}
-%vmovq\t{%1, %0|%0, %1}
-%vmovd\t{%1, %0|%0, %1}
-%vmovd\t{%1, %0|%0, %1}
- [(set (attr type)
+{
+ switch (get_attr_type (insn))
+{
+case TYPE_MULTI:
+ return #;
+
+case TYPE_IMOV:
+ if (get_attr_mode (insn) == MODE_SI)
+ return mov{l}\t{%1, %k0|%k0, %1};
+ else
+ return mov{q}\t{%1, %0|%0, %1};
+
+case TYPE_MMX:
+ return pxor\t%0, %0;
+
+case TYPE_MMXMOV:
+#ifndef HAVE_AS_IX86_INTERUNIT_MOVQ
+ /* Handle broken assemblers that require movd instead of movq. */
+ if (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1]))
+ return movd\t{%1, %0|%0, %1};
+#endif
+ return movq\t{%1, %0|%0, %1};
+
+case TYPE_SSECVT:
+ if (SSE_REG_P (operands[0]))
+ return movq2dq\t{%1, %0|%0, %1};
+ else
+ return movdq2q\t{%1, %0|%0, %1};
+
+case TYPE_SSELOG1:
+ return standard_sse_constant_opcode (insn, operands[1]);
+
+case TYPE_SSEMOV:
+ switch (get_attr_mode (insn))
+ {
+ case MODE_DI:
+#ifndef HAVE_AS_IX86_INTERUNIT_MOVQ
+ /* Handle broken assemblers that require movd instead of movq. */
+ if (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1]))
+ return %vmovd\t{%1, %0|%0, %1};
+#endif
+ return %vmovq\t{%1, %0|%0, %1};
+ case MODE_TI:
+ return %vmovdqa\t{%1, %0|%0, %1};
+
+ case MODE_V2SF:
+ gcc_assert (!TARGET_AVX);
+ return movlps\t{%1, %0|%0, %1};
+ case MODE_V4SF:
+ return %vmovaps\t{%1, %0|%0, %1};
+
+ default:
+ gcc_unreachable ();
+ }
+
+default:
+ gcc_unreachable ();
+}
+}
+ [(set (attr isa)
(cond [(eq_attr alternative 0,1)
+ (const_string nox64)
+ (eq_attr alternative 2,3,4,9,10,11,12,17,18)
+ (const_string x64)
+ ]
+ (const_string *)))
+ (set (attr type)
+ (cond [(eq_attr alternative 0,1)
+ (const_string multi)
+ (eq_attr alternative 2,3,4)
(const_string imov)
- (eq_attr alternative 2)
+ (eq_attr alternative 5)
(const_string mmx)
- (eq_attr alternative 3,4,5)
+ (eq_attr alternative 6,7,8)
(const_string mmxmov)
- (eq_attr alternative 6,7)
+ (eq_attr alternative 9,13)
+ (const_string sselog1)
+ (eq_attr alternative 19,20)
(const_string ssecvt)
- (eq_attr alternative 8)
- (const_string
Add Go notes for GCC 4.8 release
I committed some notes on Go to the GCC 4.8 changes file. Ian Index: gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.109 diff -u -r1.109 changes.html --- gcc-4.8/changes.html 22 Mar 2013 10:36:06 - 1.109 +++ gcc-4.8/changes.html 22 Mar 2013 18:49:54 - @@ -416,6 +416,16 @@ /ul/li /ul +h3 id=goGo/h3 + ul +liGCC 4.8.0 implements a preliminary version of the upcoming Go + 1.1 release. The library support is not quite complete, due to + release timing./li +liGo has been tested on GNU/Linux and Solaris platforms for + various processors including x86, x86_64, PowerPC, SPARC, and + Alpha. It may work on other platforms as well./li + /ul + !-- h3Java (GCJ)/h3 --
Re: [PATCH] Fix for movmode_internal pattern
On Fri, Mar 22, 2013 at 9:58 AM, Michael Zolotukhin michael.v.zolotuk...@gmail.com wrote: You can't use aligned vector move if alignment is unknown or not properly aligned. Yes, sure. But I just emit V2DI move for an operands, which are aligned to 64-bit (not 128-bit!) - and it's encoded into movdqa which Can you try gen_movv2di for V2DI move? -- H.J.
Re: [patch testsuite]: g++.dg
On Mar 22, 2013, at 1:17 AM, Kai Tietz ktiet...@googlemail.com wrote: this patch fixes an LLP64 issue in g++.dg's testsuite. ChangeLog 2013-03-22 Kai Tietz kti...@redhat.com * g++.dg/torture/20121105-1.C: Adjust for LLP64 targets. Ok for apply? Ok.
Re: [patch libstdc++ testsuite]: Add new option dg-additional-options and make use of it for mingw targets
On Mar 22, 2013, at 1:31 AM, Kai Tietz ktiet...@googlemail.com wrote: this patch adds option dg-additional-options for libstdc++-v3's testsuite and make use of this option for some mingw-tests. Those tests are just possible for pe-coff for static-library use. The shared version for pe-coff is finally linked and therefore no override of operators is possible within DLL. Ok for apply? So, don't know if the libstdc++ want to ponder this any, but let me approve it, subject to overrides from the libstdc++ people and invite them to say if they like the general idea or if they like some other way to resolve the issue.
C++ PATCH for c++/56684 (ICE with const local in template)
We were treating a constant VAR_DECL as non-dependent because it has a
non-dependent type, even though it has a value-dependent initializer.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d3a8f99d0ae9caf8d344b44a8e66632181a20157
Author: Jason Merrill ja...@redhat.com
Date: Fri Mar 22 12:27:01 2013 -0400
PR c++/56684
* pt.c (instantiation_dependent_r): Check DECL_INITIAL of VAR_DECL
and CONST_DECL.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b44c632..b6066c1 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19942,6 +19942,13 @@ instantiation_dependent_r (tree *tp, int *walk_subtrees,
case TREE_VEC:
return NULL_TREE;
+case VAR_DECL:
+case CONST_DECL:
+ /* A constant with a dependent initializer is dependent. */
+ if (value_dependent_expression_p (*tp))
+ return *tp;
+ break;
+
case TEMPLATE_PARM_INDEX:
return *tp;
diff --git a/gcc/testsuite/g++.dg/template/const6.C b/gcc/testsuite/g++.dg/template/const6.C
new file mode 100644
index 000..3c40d26
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/const6.C
@@ -0,0 +1,7 @@
+// PR c++/56684
+
+template int T struct S
+{
+ static const int Ti = T;
+ S() { 1 Ti; }
+};
[wwwdocs] 4.8.0 libstdc++ links
Slight update to links, reflecting more attempts by libstdc++ to blend in with the native layout and compression choices for gcc releases. Links check so seems fine. While at this, I figured I might as well do the GDL/GPL dupe for the libstdc++-api XML file, as discussed at Cauldron last year. -benjamin2013-03-22 Benjamin Kosnik b...@redhat.com * htdocs/onlinedocs/index.html: More update locations for 4.8.0. Index: htdocs/onlinedocs/4.8.0/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/onlinedocs/4.8.0/index.html,v retrieving revision 1.1 diff -c -3 -p -r1.1 index.html *** htdocs/onlinedocs/4.8.0/index.html 22 Mar 2013 14:54:01 - 1.1 --- htdocs/onlinedocs/4.8.0/index.html 22 Mar 2013 20:20:18 - *** *** 52,70 HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/manual/;GCC 4.8.0 Standard C++ Library Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-manual.pdf.bz2;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-manual.xml.bz2;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-manual-html.tar.bz2;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/api/;GCC 4.8.0 Standard C++ Library Reference Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-api.pdf.bz2;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-api.xml.bz2;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-api-html.tar.bz2;an HTML tarball/a)/li ! lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo/;GCCGO 4.8.0 Manual/a (a href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo.pdf;also in PDF/a or a href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo.ps.gz;PostScript/a or a --- 52,72 HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/manual/;GCC 4.8.0 Standard C++ Library Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-manual.pdf.gz;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-manual.xml.gz;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-manual-html.tar.gz;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/api/;GCC 4.8.0 Standard C++ Library Reference Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api.pdf.gz;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api.xml.gz;XML GPL/a or ! a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-gdl.xml.gz;XML GDL/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-html.tar.gz;an HTML tarball/a)/li !lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo/;GCCGO 4.8.0 Manual/a (a href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo.pdf;also in PDF/a or a href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo.ps.gz;PostScript/a or a 2013-03-22 Benjamin Kosnik b...@redhat.com * htdocs/onlinedocs/index.html: Update locations for 4.8.0. Index: htdocs/onlinedocs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/onlinedocs/index.html,v retrieving revision 1.131 diff -c -3 -p -r1.131 index.html *** htdocs/onlinedocs/index.html 22 Mar 2013 14:54:01 - 1.131 --- htdocs/onlinedocs/index.html 22 Mar 2013 20:07:30 - *** *** 62,78 HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/manual/;GCC 4.8.0 Standard C++ Library Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-manual.pdf.bz2;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-manual.xml.bz2;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-manual-html.tar.bz2;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/api/;GCC 4.8.0 Standard C++ Library Reference Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-api.pdf.bz2;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-api.xml.bz2;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/libstdc++-api-html.tar.bz2;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo/;GCCGO 4.8.0 Manual/a (a
[PATCH] Sort targets alphabetically
gcc/testsuite/ChangeLog
2013-03-22 Sebastian Huber sebastian.hu...@embedded-brains.de
* gcc.c-torture/execute/builtins/builtins.exp: Sort targets
alphabetically.
---
gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
b/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
index 1e3359c..d157fe3 100644
--- a/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
+++ b/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
@@ -43,8 +43,8 @@ if [istarget powerpc-*-darwin*] {
}
if { [istarget *-*-eabi*]
|| [istarget *-*-elf]
- || [istarget *-*-rtems*]
- || [istarget *-*-mingw*] } {
+ || [istarget *-*-mingw*]
+ || [istarget *-*-rtems*] } {
lappend additional_flags -Wl,--allow-multiple-definition
}
--
1.7.10.4
Re: [Patch, libfortran] PR 52512 - Cannot match namelist object name
On Fri, 22 Mar 2013 09:13:17 +0100, Janne Blomqvist blomqvist.ja...@gmail.com wrote: On Fri, Mar 22, 2013 at 12:52 AM, Tilo Schwarz t...@tilo-schwarz.de wrote: Hi, this patch fixes PR 52512. Built and regtested on Linux 3.2.0-4-686-pae. Ok for trunk (4.9). Thanks for the patch! PS: Common procedure is to report the target triplet you regtested on rather than the Linux kernel version. You can see your target triplet e.g. with gfortran -v 21 /dev/null |grep Target Ok., it is: % ./gfortran -v 21 /dev/null |grep Target Target: i686-pc-linux-gnu Also, please copy-paste the changelog inline into your message rather than as part of the diff file. Ok, next time I'll do it. Regards, Tilo
Re: [PATCH v2] Fix builtin tests for RTEMS targets
On Mar 21, 2013, at 7:08 AM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: This patch should be applied to GCC 4.8 and 4.9. Ok for trunk. Ok for 4.8.1. 4.8.0 would require RM approval I think.
Re: [patch] cilkplus array notation for C (clean, independent patchset, take 1)
On Mar 21, 2013, at 4:33 PM, Aldy Hernandez al...@redhat.com wrote: I can look into this later on, but this problem happened even when I replaced cilkplus' compile.exp, errors.exp, and execute.exp into just an exit. So it seems unrelated to the cilk patch set. Ah, I withdraw my objection. The bug can't be in those file, if those files say exit and the problem persists. Then, we're into conflation of filenames if I had to guess, which I hate doing, but, if it proves accurate, then changing the spelling is exactly the right fix, or, at least, it isn't unreasonable. Thanks.
[GOOGLE] Fix the error when backporting r193857 from trunk
Hi, This patch fixes the error in r193861, which backported r193857 from trunk. Bootstrapped and passed all gcc regression tests. Is it okay for google-4_7? Thanks, Dehao
Re: [GOOGLE] Fix the error when backporting r193857 from trunk
forgot to attach the patch... Index: gcc/ipa-prop.c === --- gcc/ipa-prop.c (revision 196984) +++ gcc/ipa-prop.c (working copy) @@ -2473,7 +2473,6 @@ base = gimple_call_arg (stmt, adj-base_index); loc = DECL_P (base) ? DECL_SOURCE_LOCATION (base) : EXPR_LOCATION (base); - loc = EXPR_LOCATION (base); if (TREE_CODE (base) != ADDR_EXPR POINTER_TYPE_P (TREE_TYPE (base))) On Fri, Mar 22, 2013 at 3:46 PM, Dehao Chen de...@google.com wrote: Hi, This patch fixes the error in r193861, which backported r193857 from trunk. Bootstrapped and passed all gcc regression tests. Is it okay for google-4_7? Thanks, Dehao
Re: [PATCH v2] Fix builtin tests for RTEMS targets
On Mar 21, 2013, at 7:08 AM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: This patch should be applied to GCC 4.8 and 4.9. Ok for trunk. Ok for 4.8.1. 4.8.0 would require RM approval I think.
Re: [GOOGLE] Fix the error when backporting r193857 from trunk
ok. David On Fri, Mar 22, 2013 at 3:58 PM, Dehao Chen de...@google.com wrote: forgot to attach the patch... Index: gcc/ipa-prop.c === --- gcc/ipa-prop.c (revision 196984) +++ gcc/ipa-prop.c (working copy) @@ -2473,7 +2473,6 @@ base = gimple_call_arg (stmt, adj-base_index); loc = DECL_P (base) ? DECL_SOURCE_LOCATION (base) : EXPR_LOCATION (base); - loc = EXPR_LOCATION (base); if (TREE_CODE (base) != ADDR_EXPR POINTER_TYPE_P (TREE_TYPE (base))) On Fri, Mar 22, 2013 at 3:46 PM, Dehao Chen de...@google.com wrote: Hi, This patch fixes the error in r193861, which backported r193857 from trunk. Bootstrapped and passed all gcc regression tests. Is it okay for google-4_7? Thanks, Dehao
[patch, mips] Patch to control the use of integer madd/msub instructions
While testing GCC on a 74k MIPS chip I noticed that by default the -mtune=74k*
flags cause GCC to not use the integer madd/msub instructions. According to
the checkin comments these were found to cause a performance hit over using
individual mult and add/sub instructions. I think there are some programs
though where using madd/msub would be a win on the 74k and I would like to
have a flag to allow users to override the default behaviour (either turning
it on for 74k or turning it off for other achitectures). This patch allows
-mimadd or -mno-imadd to override the default behaviour but does not change
that default behaviour.
OK for checkin?
Steve Ellcey
sell...@imgtec.com
2013-03-22 Steve Ellcey sell...@mips.com
* config/mips/mips.md (mimadd): New flag for integer madd/msub.
* config/mips/mips.h (GENERATE_MADD_MSUB): Check -mimadd flag.
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 0acce14..62a7701 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -875,7 +875,9 @@ struct mips_cpu_info {
!TARGET_MIPS16)
/* Integer multiply-accumulate instructions should be generated. */
-#define GENERATE_MADD_MSUB (ISA_HAS_MADD_MSUB !TUNE_74K)
+#define GENERATE_MADD_MSUB (ISA_HAS_MADD_MSUB \
+ (target_flags_explicit MASK_IMADD \
+ ? TARGET_IMADD : !TUNE_74K))
/* ISA has floating-point madd and msub instructions 'd = a * b [+-] c'. */
#define ISA_HAS_FP_MADD4_MSUB4 ISA_HAS_FP4
diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index d8ef2e7..6b3024b 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -58,6 +58,10 @@ mmad
Target Report Var(TARGET_MAD)
Use PMC-style 'mad' instructions
+mimadd
+Target Report Mask(IMADD)
+Use integer madd/msub instructions
+
march=
Target RejectNegative Joined Var(mips_arch_option) ToLower
Enum(mips_arch_opt_value)
-march=ISA Generate code for the given ISA
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
On 22/03/2013 08:44, Kai Tietz wrote: Hi, this change is actual used by cygwin and is required for upcoming x64 cygwin target. ChangeLog 2013-03-22 Kai Tietz kti...@redhat.com * config/i386/cygming-crtbegin.c (__register_frame_info): Make weak. (__deregister_frame_info): Likewise. Tested for i686-pc-cygwin, and x86_64-pc-cygwin. I will apply this code tomorrow if there are no objections by other Windows-target-maintainers. I don't think the ChangeLog entry is right; it doesn't make the declarations weak, it supplies definitions. Also, can you explain the motivation for this change? I don't see how it's going to work right; from what I remember, we don't have weak definitions in PE-COFF, just weak references. How does the correct definition get chosen when we may have two definitions in a final link? cheers, DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 22/03/2013 09:00, Kai Tietz wrote: (LIBGCJ_SONAME): Make name minor-build-version dependent. Tested for i686-pc-cygwin, and x86_64-pc-cygwin. Dave, please especially a look to LIBGCJ_SONAME change. I think we should include MAJOR_VERSION here, too. Ok for apply? I'm not sure about it: -/* We should find a way to not have to update this manually. */ -#define LIBGCJ_SONAME cyggcj /*LIBGCC_EH_EXTN*/ -13.dll - +#ifndef BUILDING_GCC_MAJOR +#include bversion.h +#endif +#define ___cyg_mkstr(x) #x +#define __cyg_mkstr(x) ___cyg_mkstr(x) +#if BUILDING_GCC_MAJOR == 4 +#define LIBGCJ_SONAME cyggcj- __cyg_mkstr (BUILDING_GCC_MINOR+6) .dll +#else +#error LIBGCJ_SONAME versioning scheme needs attention +#endif AIUI, the libgcj soversion has no fixed relation to the GCC major/minor version of necessity, but is specified by the parameters in $srcdir/libjava/libtool-version, which is manually updated. We really ought to run a script to extract the version info fields from there and do the calculation ourselves if we're going to try to automate it. Even if it is policy to bump the libgcj soversion with every minor release of GCC, there's no use us having the right value if someone neglects to update libjava; only generating it from the libjava file will guarantee everything stays in absolute lockstep. cheers, DaveK
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 22/03/2013 08:44, Kai Tietz wrote: Hi, this change is actual used by cygwin and is required for upcoming x64 cygwin target. ChangeLog 2013-03-22 Kai Tietz kti...@redhat.com * config/i386/cygming-crtbegin.c (__register_frame_info): Make weak. (__deregister_frame_info): Likewise. Tested for i686-pc-cygwin, and x86_64-pc-cygwin. I will apply this code tomorrow if there are no objections by other Windows-target-maintainers. I don't think the ChangeLog entry is right; it doesn't make the declarations weak, it supplies definitions. Also, can you explain the motivation for this change? I don't see how it's going to work right; from what I remember, we don't have weak definitions in PE-COFF, just weak references. How does the correct definition get chosen when we may have two definitions in a final link? Well, weak undefs are possible with pe-coff. We ran into that by porting cygwin to x64. But you are right that pe-coff doesn't support undefines (weak or none-weak) within final-link, so for a weak we need always a default implementation. This we added here. If in a different TU a none-weak implementation is present, ld will resolve that as usual. cheers, DaveK Cheers, Kai
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 22/03/2013 09:00, Kai Tietz wrote: (CXX_WRAP_SPEC_LIST): Undefine before define. @@ -73,6 +82,7 @@ /* To implement C++ function replacement we always wrap the cxx malloc-like operators. See N2800 #17.6.4.6 [replacement.functions] */ +#undef CXX_WRAP_SPEC_LIST #define CXX_WRAP_SPEC_LIST \ --wrap _Znwj \ --wrap _Znaj \ Also, I don't think this is really necessary. Isn't it the case that cygwin.h provides base definitions, and cygwin-w64.h overrides them, and it would always be an error to include cygwin-w64.h before cygwin.h? In which case the macro redefinition error would be a useful warning that somebody was using the headers wrong. cheers, DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 22/03/2013 09:00, Kai Tietz wrote: (LIBGCJ_SONAME): Make name minor-build-version dependent. Tested for i686-pc-cygwin, and x86_64-pc-cygwin. Dave, please especially a look to LIBGCJ_SONAME change. I think we should include MAJOR_VERSION here, too. Ok for apply? I'm not sure about it: -/* We should find a way to not have to update this manually. */ -#define LIBGCJ_SONAME cyggcj /*LIBGCC_EH_EXTN*/ -13.dll - +#ifndef BUILDING_GCC_MAJOR +#include bversion.h +#endif +#define ___cyg_mkstr(x) #x +#define __cyg_mkstr(x) ___cyg_mkstr(x) +#if BUILDING_GCC_MAJOR == 4 +#define LIBGCJ_SONAME cyggcj- __cyg_mkstr (BUILDING_GCC_MINOR+6) .dll +#else +#error LIBGCJ_SONAME versioning scheme needs attention +#endif AIUI, the libgcj soversion has no fixed relation to the GCC major/minor version of necessity, but is specified by the parameters in $srcdir/libjava/libtool-version, which is manually updated. We really ought to run a script to extract the version info fields from there and do the calculation ourselves if we're going to try to automate it. Even if it is policy to bump the libgcj soversion with every minor release of GCC, there's no use us having the right value if someone neglects to update libjava; only generating it from the libjava file will guarantee everything stays in absolute lockstep. cheers, DaveK Hmm, well, not sure about that too. We shouldn't put hard dependencies into gcc's build about target-libraries, but yes - if unavoidable - a automated way to detect version-number I would welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Cheers, Kai
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
On 23/03/2013 00:08, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: Also, can you explain the motivation for this change? I don't see how it's going to work right; from what I remember, we don't have weak definitions in PE-COFF, just weak references. How does the correct definition get chosen when we may have two definitions in a final link? Well, weak undefs are possible with pe-coff. We ran into that by porting cygwin to x64. But you are right that pe-coff doesn't support undefines (weak or none-weak) within final-link, so for a weak we need always a default implementation. This we added here. I thought it does (support weak undefines within final link). Weak references with no definition resolve to zero, no? cheers, DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 22/03/2013 09:00, Kai Tietz wrote: (CXX_WRAP_SPEC_LIST): Undefine before define. @@ -73,6 +82,7 @@ /* To implement C++ function replacement we always wrap the cxx malloc-like operators. See N2800 #17.6.4.6 [replacement.functions] */ +#undef CXX_WRAP_SPEC_LIST #define CXX_WRAP_SPEC_LIST \ --wrap _Znwj \ --wrap _Znaj \ Also, I don't think this is really necessary. Isn't it the case that cygwin.h provides base definitions, and cygwin-w64.h overrides them, and it would always be an error to include cygwin-w64.h before cygwin.h? In which case the macro redefinition error would be a useful warning that somebody was using the headers wrong. cheers, DaveK Yes, that's a fair point. Cheers, Kai
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 23/03/2013 00:16, Kai Tietz wrote: welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Somebody has to register the default classes at startup, or attempts to classload them will fail. cheers, DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:16, Kai Tietz wrote: welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Somebody has to register the default classes at startup, or attempts to classload them will fail. cheers, DaveK Right, but shouldn't that be done by libjava-DLL itself on loading (and deregistration on unloading)? I see no good point to add this into a different dll? But well, I might miss here an important point. Kai
Re: [patch]: Add configure and required host/target definitions for new cygwin x64 target
On 22/03/2013 09:56, Kai Tietz wrote:
Hi,
this patch adds required configure changes for new cygwin x64 target.
Index: gcc/configure.ac
===
--- gcc/configure.ac (Revision 196898)
+++ gcc/configure.ac (Arbeitskopie)
@@ -3623,7 +3623,7 @@ changequote([,])dnl
# wrappers to aid in interposing and redirecting operators new, delete,
# etc., as per n2800 #17.6.4.6 [replacement.functions]. Check if we
# are configuring for a version of Cygwin that exports the wrappers.
- if test x$host = x$target; then
+ if test x$host = x$target test x$host_cpu = xi686; then
AC_CHECK_FUNC([__wrap__Znaj],[gcc_ac_cygwin_dll_wrappers=yes],[gcc_ac_cygwin_dll_wrappers=no])
else
# Can't check presence of libc functions during cross-compile, so
Rather than just bailing on x86_64, shouldn't this code check for the
presence of one of the 64-bit versions of the C++ wrapper functions such as
__wrap__Znam instead?
Index: libgcc/config.host
===
--- libgcc/config.host(Revision 196898)
+++ libgcc/config.host(Arbeitskopie)
@@ -564,13 +564,30 @@ i[34567]86-*-cygwin*)
tmake_eh_file=i386/t-dw2-eh
fi
# Shared libgcc DLL install dir depends on cross/native build.
- if test x${build} = x${host} ; then
+ if test x${host} = x${target} ; then
I don't get this. We're compiling a target library, so only build and host
are correct to use, AIUI; $target may still be set by accident, but it's not
meaningful when building a target lib.
# Shared libgcc DLL install dir depends on cross/native build.
- if test x${build} = x${host} ; then
+ if test x${host} = x${target} ; then
Same here.
cheers,
DaveK
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:08, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: Also, can you explain the motivation for this change? I don't see how it's going to work right; from what I remember, we don't have weak definitions in PE-COFF, just weak references. How does the correct definition get chosen when we may have two definitions in a final link? Well, weak undefs are possible with pe-coff. We ran into that by porting cygwin to x64. But you are right that pe-coff doesn't support undefines (weak or none-weak) within final-link, so for a weak we need always a default implementation. This we added here. I thought it does (support weak undefines within final link). Weak references with no definition resolve to zero, no? cheers, DaveK No, actual they aren't zero value, they are reported as undefined symbol, which seems to me from perpective of pe-coff weak definition the right thing to do. Cheers, Kai
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 23/03/2013 00:24, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:16, Kai Tietz wrote: welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Somebody has to register the default classes at startup, or attempts to classload them will fail. cheers, DaveK Right, but shouldn't that be done by libjava-DLL itself on loading (and deregistration on unloading)? I see no good point to add this into a different dll? But well, I might miss here an important point. Well, libgcc is always there, and libjava doesn't have any specific hooks where we could add startup code, which is why all targets do it by default in libgcc/crtstuff.c along with the C++ default ctor stuff. cheers, DaveK
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
On 23/03/2013 00:27, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:08, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: Also, can you explain the motivation for this change? I don't see how it's going to work right; from what I remember, we don't have weak definitions in PE-COFF, just weak references. How does the correct definition get chosen when we may have two definitions in a final link? Well, weak undefs are possible with pe-coff. We ran into that by porting cygwin to x64. But you are right that pe-coff doesn't support undefines (weak or none-weak) within final-link, so for a weak we need always a default implementation. This we added here. I thought it does (support weak undefines within final link). Weak references with no definition resolve to zero, no? No, actual they aren't zero value, they are reported as undefined symbol, which seems to me from perpective of pe-coff weak definition the right thing to do. I think something's going wrong. From the PE-COFF specs: “Weak externals” are a mechanism for object files that allows flexibility at link time. A module can contain an unresolved external symbol (sym1), but it can also include an auxiliary record that indicates that if sym1 is not present at link time, another external symbol (sym2) is used to resolve references instead. If a definition of sym1 is linked, then an external reference to the symbol is resolved normally. If a definition of sym1 is not linked, then all references to the weak external for sym1 refer to sym2 instead. The external symbol, sym2, must always be linked; typically, it is defined in the module that contains the weak reference to sym1. In gcc/binutils, what we do is automatically provide an aux record (sym2) with the value *ABS* zero. If a definition (strong, because we only have strong definitions in PE-COFF) of the weakly-referenced symbol is provided, that overrides the aux value of zero, but otherwise the zero value is used. IIRC, there's a binutils bugzilla entry about things not going well if two strong definitions are provided to resolve a weak external. I'll try and dig it up. cheers, DaveK
Re: [patch]: Add configure and required host/target definitions for new cygwin x64 target
2013/3/23 Dave Korn dave.korn.cyg...@gmail.com:
On 22/03/2013 09:56, Kai Tietz wrote:
Hi,
this patch adds required configure changes for new cygwin x64 target.
Index: gcc/configure.ac
===
--- gcc/configure.ac (Revision 196898)
+++ gcc/configure.ac (Arbeitskopie)
@@ -3623,7 +3623,7 @@ changequote([,])dnl
# wrappers to aid in interposing and redirecting operators new, delete,
# etc., as per n2800 #17.6.4.6 [replacement.functions]. Check if we
# are configuring for a version of Cygwin that exports the wrappers.
- if test x$host = x$target; then
+ if test x$host = x$target test x$host_cpu = xi686; then
AC_CHECK_FUNC([__wrap__Znaj],[gcc_ac_cygwin_dll_wrappers=yes],[gcc_ac_cygwin_dll_wrappers=no])
else
# Can't check presence of libc functions during cross-compile, so
Rather than just bailing on x86_64, shouldn't this code check for the
presence of one of the 64-bit versions of the C++ wrapper functions such as
__wrap__Znam instead?
Sure, this should be a follow-up patch. For now we should get initial
version into repository. There are some other places we need to visit
later, too.
Index: libgcc/config.host
===
--- libgcc/config.host(Revision 196898)
+++ libgcc/config.host(Arbeitskopie)
@@ -564,13 +564,30 @@ i[34567]86-*-cygwin*)
tmake_eh_file=i386/t-dw2-eh
fi
# Shared libgcc DLL install dir depends on cross/native build.
- if test x${build} = x${host} ; then
+ if test x${host} = x${target} ; then
I don't get this. We're compiling a target library, so only build and host
are correct to use, AIUI; $target may still be set by accident, but it's not
meaningful when building a target lib.
Well, I think the idea here was that cygwin installs anyway
(especially for candian-cross AFAIR) into native (bin/) location.
That's a kludge.
Actual the x64 mingw hunk is wrong, and I notice that for 32-bit
default mingw we install for cross into wrong location.
# Shared libgcc DLL install dir depends on cross/native build.
- if test x${build} = x${host} ; then
+ if test x${host} = x${target} ; then
Same here.
cheers,
DaveK
Cheers,
Kai
Re: [patch] Use NOTE_P, CALL_P, etc. instead of GET_CODE in a bunch of files
On Fri, Mar 22, 2013 at 8:09 PM, Steven Bosscher wrote:
Hello,
This is an almost completely mechanical replacement of GET_CODE(thing)
== ... with the equivalent predicate macro from rtl.h. This particular
set of files fell victim to my plans for GCC 4.9 to make
JUMP_TABLE_DATA_P a separate rtx instead of a JUMP_INSN. The script I
used is in the patch. I checked and cleaned up the changes by hand and
modified a few places by hand.
Bootstrappedtested on powerpc64-unknown-linux-gnu and on
ia64-unknown-linux-gnu. Also did a quick cross to a few of the
affected ports (sparc, bfin).
OK for trunk?
Can I please have pre-approval for similar changes to other files,
subject to posting and waiting at least 2 days for
comments/objections?
FWIW, the only other instance where the silly script triggers (apart
from a few wrong INSN_LIST changes) is in mmix.c:
Index: config/mmix/mmix.c
===
--- config/mmix/mmix.c (revision 196975)
+++ config/mmix/mmix.c (working copy)
@@ -1728,7 +1728,7 @@ mmix_print_operand (FILE *stream, rtx x, int code)
if (CONSTANT_P (modified_x)
/* Strangely enough, this is not included in CONSTANT_P.
FIXME: Ask/check about sanity here. */
- || GET_CODE (modified_x) == CODE_LABEL)
+ || LABEL_P (modified_x))
{
output_addr_const (stream, modified_x);
return;
It looks like the gcc/ directory was already completely converted to
the _P idiom.
Ciao!
Steven
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:24, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:16, Kai Tietz wrote: welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Somebody has to register the default classes at startup, or attempts to classload them will fail. cheers, DaveK Right, but shouldn't that be done by libjava-DLL itself on loading (and deregistration on unloading)? I see no good point to add this into a different dll? But well, I might miss here an important point. Well, libgcc is always there, and libjava doesn't have any specific hooks where we could add startup code, which is why all targets do it by default in libgcc/crtstuff.c along with the C++ default ctor stuff. cheers, DaveK Hmm, we have DllMain. it is enough for native Windows. And cygwin has same feature via DECLARE_CYGWIN_DLL( DllMain ); AFAIK. Cheers, Kai
Re: [patch]: Add configure and required host/target definitions for new cygwin x64 target
On 23/03/2013 00:41, Kai Tietz wrote:
2013/3/23 Dave Korn dave.korn.cyg...@gmail.com:
On 22/03/2013 09:56, Kai Tietz wrote:
Hi,
this patch adds required configure changes for new cygwin x64 target.
Index: gcc/configure.ac
===
--- gcc/configure.ac (Revision 196898)
+++ gcc/configure.ac (Arbeitskopie)
@@ -3623,7 +3623,7 @@ changequote([,])dnl
# wrappers to aid in interposing and redirecting operators new,
delete,
# etc., as per n2800 #17.6.4.6 [replacement.functions]. Check if we
# are configuring for a version of Cygwin that exports the wrappers.
- if test x$host = x$target; then
+ if test x$host = x$target test x$host_cpu = xi686; then
AC_CHECK_FUNC([__wrap__Znaj],[gcc_ac_cygwin_dll_wrappers=yes],[gcc_ac_cygwin_dll_wrappers=no])
else
# Can't check presence of libc functions during cross-compile, so
Rather than just bailing on x86_64, shouldn't this code check for the
presence of one of the 64-bit versions of the C++ wrapper functions such as
__wrap__Znam instead?
Sure, this should be a follow-up patch. For now we should get initial
version into repository. There are some other places we need to visit
later, too.
Ok, fair enough.
Index: libgcc/config.host
===
--- libgcc/config.host(Revision 196898)
+++ libgcc/config.host(Arbeitskopie)
@@ -564,13 +564,30 @@ i[34567]86-*-cygwin*)
tmake_eh_file=i386/t-dw2-eh
fi
# Shared libgcc DLL install dir depends on cross/native build.
- if test x${build} = x${host} ; then
+ if test x${host} = x${target} ; then
I don't get this. We're compiling a target library, so only build and host
are correct to use, AIUI; $target may still be set by accident, but it's not
meaningful when building a target lib.
Well, I think the idea here was that cygwin installs anyway
(especially for candian-cross AFAIR) into native (bin/) location.
That's a kludge.
Eh? The whole point of this bit is to avoid installing into the native
location in any kind of cross build. This was the fix for PR40125; the libgcc
equivalent of $srcdir/config/lthostflags.m4.
cheers,
DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 23/03/2013 00:57, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:24, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:16, Kai Tietz wrote: welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Somebody has to register the default classes at startup, or attempts to classload them will fail. Right, but shouldn't that be done by libjava-DLL itself on loading (and deregistration on unloading)? I see no good point to add this into a different dll? But well, I might miss here an important point. Well, libgcc is always there, and libjava doesn't have any specific hooks where we could add startup code, which is why all targets do it by default in libgcc/crtstuff.c along with the C++ default ctor stuff. Hmm, we have DllMain. it is enough for native Windows. And cygwin has same feature via DECLARE_CYGWIN_DLL( DllMain ); AFAIK. Well, yes we do, but why not just do it the same way every other target does it? Also, DllMain is very risky to do anything complex in. Without having some strong guarantees about how the default java class registration code might or might not behave, I don't want to call it from DllMain. (You've read http://www.microsoft.com/whdc/driver/kernel/DLL_bestprac.mspx?) cheers, DaveK
RE: [patch] cilkplus array notation for C (clean, independent patchset, take 1)
From: gcc-patches-ow...@gcc.gnu.org [gcc-patches-ow...@gcc.gnu.org] on behalf of Mike Stump [m...@mrs.kithrup.com] Sent: Friday, March 22, 2013 6:36 PM To: Aldy Hernandez Cc: Jakub Jelinek; Jeff Law; Joseph S. Myers; Iyer, Balaji V; gcc-patches Subject: Re: [patch] cilkplus array notation for C (clean, independent patchset, take 1) On Mar 21, 2013, at 4:33 PM, Aldy Hernandez al...@redhat.com wrote: I can look into this later on, but this problem happened even when I replaced cilkplus' compile.exp, errors.exp, and execute.exp into just an exit. So it seems unrelated to the cilk patch set. Ah, I withdraw my objection. The bug can't be in those file, if those files say exit and the problem persists. Then, we're into conflation of filenames if I had to guess, which I hate doing, but, if it proves accurate, then changing the spelling is exactly the right fix, or, at least, it isn't unreasonable. Thanks. Hi Mike, I can confirm that renaming scripts to something unique fixed the issue. Thanks, Balaji V. Iyer.
Re: [patch] Use NOTE_P, CALL_P, etc. instead of GET_CODE in a bunch of files
On 03/22/2013 06:44 PM, Steven Bosscher wrote: On Fri, Mar 22, 2013 at 8:09 PM, Steven Bosscher wrote: Hello, This is an almost completely mechanical replacement of GET_CODE(thing) == ... with the equivalent predicate macro from rtl.h. This particular set of files fell victim to my plans for GCC 4.9 to make JUMP_TABLE_DATA_P a separate rtx instead of a JUMP_INSN. The script I used is in the patch. I checked and cleaned up the changes by hand and modified a few places by hand. Bootstrappedtested on powerpc64-unknown-linux-gnu and on ia64-unknown-linux-gnu. Also did a quick cross to a few of the affected ports (sparc, bfin). OK for trunk? Can I please have pre-approval for similar changes to other files, subject to posting and waiting at least 2 days for comments/objections? FWIW, the only other instance where the silly script triggers (apart from a few wrong INSN_LIST changes) is in mmix.c: I'll pre-approve the mechanical replacements. jeff
PATCH: Restore GCC 4.7 bootstrap on x86
BOOL_BITFIELD isn't defined when building libgcc. I checked in this
patch to restore GCC 4.7 bootstrap on x86. GCC 4.6 is OK.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 196998)
+++ ChangeLog (working copy)
@@ -1,5 +1,10 @@
2013-03-22 H.J. Lu hongjiu...@intel.com
+ * config/i386/i386.h (ix86_args): Define only if USED_FOR_TARGET
+ isn't defined.
+
+2013-03-22 H.J. Lu hongjiu...@intel.com
+
PR target/56560
* config/i386/i386.c (init_cumulative_args): Also set
cum-callee_return_avx256_p.
Index: config/i386/i386.h
===
--- config/i386/i386.h (revision 196998)
+++ config/i386/i386.h (working copy)
@@ -1474,6 +1474,7 @@ enum reg_class
/* 1 if N is a possible register number for function argument passing. */
#define FUNCTION_ARG_REGNO_P(N) ix86_function_arg_regno_p (N)
+#ifndef USED_FOR_TARGET
/* Define a data type for recording info about an argument list
during the scan of that argument list. This data type should
hold all necessary information about the function itself
@@ -1507,6 +1508,7 @@ typedef struct ix86_args {
/* Nonzero if it returns 256bit AVX modes. */
BOOL_BITFIELD callee_return_avx256_p : 1;
} CUMULATIVE_ARGS;
+#endif
/* Initialize a variable CUM of type CUMULATIVE_ARGS
for a call to a function whose data type is FNTYPE.
Re: [patch] cilkplus array notation for C (clean, independent patchset, take 1)
On Mar 22, 2013, at 6:36 PM, Iyer, Balaji V balaji.v.i...@intel.com wrote: I can confirm that renaming scripts to something unique fixed the issue. That's what others have said, I've not see it first hand.
