[PATCH, i386]: Add castmode mode attribute
Hello! This patch will simplify macroization of AVX2 stuff. No functional changes. 2011-08-06 Uros Bizjak * config/i386/i386.md (ssemodesuffix): Remove V8SI mode. * config/i386/sse.md (castmode): New mode attribute. (avx__): Rename from avx__. Bootstrapped on x86_64-pc-linux-gnu, committed to mainline SVN. Uros. Index: i386.md === --- i386.md (revision 177503) +++ i386.md (working copy) @@ -935,8 +935,7 @@ [(SF "ss") (DF "sd") (V8SF "ps") (V4DF "pd") (V4SF "ps") (V2DF "pd") - (V16QI "b") (V8HI "w") (V4SI "d") (V2DI "q") - (V8SI "si")]) + (V16QI "b") (V8HI "w") (V4SI "d") (V2DI "q")]) ;; SSE vector suffix for floating point modes (define_mode_attr ssevecmodesuffix [(SF "ps") (DF "pd")]) Index: sse.md === --- sse.md (revision 177503) +++ sse.md (working copy) @@ -178,6 +178,9 @@ (define_mode_attr sserotatemax [(V16QI "7") (V8HI "15") (V4SI "31") (V2DI "63")]) +;; Mapping of mode to cast intrinsic name +(define_mode_attr castmode [(V8SI "si") (V8SF "ps") (V4DF "pd")]) + ;; Instruction suffix for sign and zero extensions. (define_code_attr extsuffix [(sign_extend "sx") (zero_extend "zx")]) @@ -10233,7 +10236,7 @@ (set_attr "prefix" "vex") (set_attr "mode" "")]) -(define_insn_and_split "avx__" +(define_insn_and_split "avx__" [(set (match_operand:AVX256MODE2P 0 "nonimmediate_operand" "=x,m") (unspec:AVX256MODE2P [(match_operand: 1 "nonimmediate_operand" "xm,x")]
Re: [patch, fortran] PR 37721, warn about target > source in TRANSFER
Am 05.08.2011 23:57, schrieb Thomas Koenig: Committed as rev. 177486. Looks like this caused a regression in c_ptr_tests_16.f90. Don't know why, am investigating. Thomas
Re: [build] Move unwinder to toplevel libgcc (v2)
I'm seeing this bootstrap failure on ia64 (configured with --with-system-libunwind): /usr/local/gcc/gcc-20110806/Build/./prev-gcc/g++ -B/usr/local/gcc/gcc-20110806/Build/./prev-gcc/ -B/usr/ia64-suse-linux/bin/ -nostdinc++ -B/usr/local/gcc/gcc-20110806/Build/prev-ia64-suse-linux/libstdc++-v3/src/.libs -B/usr/local/gcc/gcc-20110806/Build/prev-ia64-suse-linux/libstdc++-v3/libsupc++/.libs -I/usr/local/gcc/gcc-20110806/Build/prev-ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux -I/usr/local/gcc/gcc-20110806/Build/prev-ia64-suse-linux/libstdc++-v3/include -I/usr/local/gcc/gcc-20110806/libstdc++-v3/libsupc++ -L/usr/local/gcc/gcc-20110806/Build/prev-ia64-suse-linux/libstdc++-v3/src/.libs -L/usr/local/gcc/gcc-20110806/Build/prev-ia64-suse-linux/libstdc++-v3/libsupc++/.libs -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -o gengtype gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a /usr/local/gcc/gcc-20110806/Build/./prev-gcc/libgcc_s.so: undefined reference to `__libunwind__Unwind_Find_FDE' collect2: error: ld returned 1 exit status make[3]: *** [gengtype] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/usr/local/gcc/gcc-20110806/Build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/local/gcc/gcc-20110806/Build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/gcc/gcc-20110806/Build' make: *** [bootstrap] Error 2 Looks like -lunwind is missing somewhere. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
libobjc: fix for PR/49882 ("class_getSuperClass() returns nil on a newly allocated, but not registered, class")
This patch fixes PR libobjc/49882. Applied to trunk.
Thanks
Index: libobjc/ChangeLog
===
--- libobjc/ChangeLog (revision 177503)
+++ libobjc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2011-08-06 Nicola Pero
+
+ PR libobjc/49882
+ * class.c (class_getSuperclass): Return the superclass if the
+ class is in construction.
+ * objc/runtime.h (class_getSuperclass): Updated documentation.
+
2011-08-05 Rainer Orth
* Makefile.in (INCLUDES): Search
Index: libobjc/class.c
===
--- libobjc/class.c (revision 177503)
+++ libobjc/class.c (working copy)
@@ -923,10 +923,13 @@ class_getSuperclass (Class class_)
if (class_ == Nil)
return Nil;
- /* Classes that are in construction are not resolved and can not be
- resolved! */
+ /* Classes that are in construction are not resolved, and still have
+ the class name (instead of a class pointer) in the
+ class_->superclass field. In that case we need to lookup the
+ superclass name to return the superclass. We can not resolve the
+ class until it is registered. */
if (CLS_IS_IN_CONSTRUCTION (class_))
-return Nil;
+return objc_lookUpClass ((const char *)(class_->super_class));
/* If the class is not resolved yet, super_class would point to a
string (the name of the super class) as opposed to the actual
Index: libobjc/objc/runtime.h
===
--- libobjc/objc/runtime.h (revision 177503)
+++ libobjc/objc/runtime.h (working copy)
@@ -497,10 +497,10 @@ objc_EXPORT const char * class_getName (Class clas
objc_EXPORT BOOL class_isMetaClass (Class class_);
/* Return the superclass of 'class_'. If 'class_' is Nil, or it is a
- root class, return Nil. If 'class_' is a class being constructed,
- that is, a class returned by objc_allocateClassPair() but before it
- has been registered with the runtime using
- objc_registerClassPair(), return Nil. */
+ root class, return Nil. This function also works if 'class_' is a
+ class being constructed, that is, a class returned by
+ objc_allocateClassPair() but before it has been registered with the
+ runtime using objc_registerClassPair(). */
objc_EXPORT Class class_getSuperclass (Class class_);
/* Return the 'version' number of the class, which is an integer that
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 177503)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2011-08-06 Nicola Pero
+
+ PR libobjc/49882
+ * objc.dg/gnu-api-2-class.m (main): Test class_getSuperclass()
+ with classes that are in construction.
+
2011-08-05 Jason Merrill
PR c++/48993
Index: gcc/testsuite/objc.dg/gnu-api-2-class.m
===
--- gcc/testsuite/objc.dg/gnu-api-2-class.m (revision 177503)
+++ gcc/testsuite/objc.dg/gnu-api-2-class.m (working copy)
@@ -394,6 +394,14 @@ int main(int argc, void **args)
MySubClass *object = [[MySubClass alloc] init];
if (class_getSuperclass (object_getClass (object)) != objc_getClass
("MyRootClass"))
abort ();
+
+/* Test that it works on a newly created, but not registered, class. */
+{
+ Class new_class = objc_allocateClassPair (objc_getClass ("MyRootClass"),
"MySubClass3", 0);
+
+ if (class_getSuperclass (new_class) != objc_getClass ("MyRootClass"))
+ abort ();
+}
}
printf ("Testing class_getVersion ()...\n");
libobjc: Fix obvious typo in comment
Fixes a typo in a comment in my last patch. Applied to trunk. Thanks Index: ChangeLog === --- ChangeLog (revision 177505) +++ ChangeLog (working copy) @@ -1,5 +1,9 @@ 2011-08-06 Nicola Pero + * class.c (class_getSuperclass): Fixed typo in comment. + +2011-08-06 Nicola Pero + PR libobjc/49882 * class.c (class_getSuperclass): Return the superclass if the class is in construction. Index: class.c === --- class.c (revision 177505) +++ class.c (working copy) @@ -925,7 +925,7 @@ /* Classes that are in construction are not resolved, and still have the class name (instead of a class pointer) in the - class_->superclass field. In that case we need to lookup the + class_->super_class field. In that case we need to lookup the superclass name to return the superclass. We can not resolve the class until it is registered. */ if (CLS_IS_IN_CONSTRUCTION (class_))
Re: [build] Move unwinder to toplevel libgcc (v2)
On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote: > On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote: > > I suppose it is this patch that breaks bootstrap The culprit is indeed r177447. > > Adding a -I flag? I suppose that makes sense even if crtstuff is > moved soon to toplevel libgcc. How about this? It fixes the problem. Index: gcc/Makefile.in === --- gcc/Makefile.in (révision 177491) +++ gcc/Makefile.in (copie de travail) @@ -1088,7 +1088,7 @@ INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ -I$(srcdir)/../include @INCINTL@ \ $(CPPINC) $(GMPINC) $(DECNUMINC) \ - $(PPLINC) $(CLOOGINC) + $(PPLINC) $(CLOOGINC) -I$(srcdir)/../libgcc .c.o: $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $< $(OUTPUT_OPTION) Mikael
Re: [PATCH, testsuite, i386] AVX2 support for GCC
On Thu, Aug 4, 2011 at 11:20 AM, Kirill Yukhin wrote: > During last few months I was working on AVX2 support for GCC. > > Here is a patch which conforms (hopefully) to Spec which can be found at [1] Whoa, mega-patch for review. This will be attacked in stages. 1. Typo fixes to fma_ patterns (and whitespace fixes): Please split these out to separate patch. These are OK, please commit them to SVN. You can also sneak whitespace fixes in this patch ... 2. Options and flags (including driver-i386.c): These are waiting for int64 patch. Please split these out, options/flags handling will be committed first, so TARGET_AVX2 is handled correctly. ATM, you don't need to change -int ix86_isa_flags = TARGET_64BIT_DEFAULT | TARGET_SUBTARGET_ISA_DEFAULT +long long int ix86_isa_flags = TARGET_64BIT_DEFAULT | TARGET_SUBTARGET_ISA_DEFAULT 3. Testsuite changes: Please split testsuite changes to separate patch... This patch will be committed last. 4. Main patch: Review, round 1... avx2intrin.h and corresponding intrinsic handling looks OK to me. However, you should add -mavx2 to following testsuite files that check usage of intrinsics: gcc.target/i386/sse-12.c (you did already) gcc.target/i386/sse-13.c gcc.target/i386/sse-14.c gcc.target/i386/sse-22.c gcc.target/i386/sse-23.c g++.dg/other/i386-2.C g++.dg/other/i386-3.C If your patch survives this torture, you get automatic approval on new headers and intrinsics handling stuff. ;) sse.md: The "interesting" stuff... As a general advice, do not introduce new mode attributes unless *really* necessary. Extend existing attributes instead. They don't need to match exactly the particular mode iterator, it is only important that all modes handled through mode attribute are defined. +(define_mode_attr avx2modesuffix + [(SF "ss") (DF "sd") + (V8SF "ps") (V4DF "pd") + (V4SF "ps") (V2DF "pd") + (V16QI "b") (V8HI "w") (V4SI "d") (V2DI "q") + (V8SI "d") (V4DI "q")]) Add new modes to ssemodesuffix mode iterator and use it instead (it was just fixed to get rid of V8SI mode, defined to "si"). +(define_mode_attr sse_avx2 + [(V16QI "") (V32QI "avx2_") + (V8HI "") (V16HI "avx2_") + (V4SI "") (V8SI "avx2_") + (V2DI "") (V4DI "avx2_")]) Remove. Not used anywhere. +(define_code_iterator lshift [lshiftrt ashift]) +(define_code_attr lshift_insn [(lshiftrt "srl") (ashift "sll")]) +(define_code_attr lshift [(lshiftrt "lshr") (ashift "lshl")]) Missing comments, see i386.md. +(define_mode_attr SSESHORTMODE + [(V4DI "V4SI") (V2DI "V2SI")]) ssehalfmode +(define_mode_attr SSELONGMODE + [(V16HI "V16SI") (V8HI "V8SI")]) ssedoublemode +(define_mode_attr SSEBYTEMODE + [(V4DI "V32QI") (V2DI "V16QI")]) ssebytemode +(define_mode_attr AVXTOSSEMODE + [(V4DI "V2DI") (V2DI "V2DI") + (V8SI "V4SI") (V4SI "V4SI") + (V16HI "V8HI") (V8HI "V8HI") + (V32QI "V16QI") (V16QI "V16QI")]) Move near avx2_pbroadcast pattern. +(define_mode_attr shortmode + [(V4DI "v4si") (V2DI "v2si")]) Not needed, you have wrong mode iterator choice for mul insns. +;; 32 byte integral vector modes handled by AVX +(define_mode_iterator AVX256MODEI [V32QI V16HI V8SI V4DI]) Please be consistent with existing names/comments: ;; All 256bit vector integer modes (define_mode_iterator VF_256 [...]) ;; Mix-n-match (define_mode_iterator AVX256MODE2P [V8SI V8SF V4DF]) +(define_mode_iterator AVX256MODE124 [V32QI V16HI V8SI]) +(define_mode_iterator AVX256MODE1248 [V32QI V16HI V8SI V4DI]) +(define_mode_iterator AVX256MODE248 [V16HI V8SI V4DI]) I am trying to remove this section! Please move these definitions to new section (under "Random 128bit ...") ;; Random 256bit vector integer mode combinations define_mode_iterator VI124_256 [...]) ...etc. +;; For gather* insn patterns +(define_mode_iterator AVXMODE48P_SI + [V2DI V2DF V4DI V4DF V4SI V4SF V8SI V8SF]) ... Please rename these to something like VEC_GATHER_MODE and put these iterators/attributes at the top of gather* patterns. +(define_mode_attr avx2 + [(V32QI "avx2_") (V16HI "avx2_") (V8SI "avx2_") (V4DI "avx2_") + (V16QI "") (V8HI "") (V4SI "") (V2DI "")]) Remove. Dupe with sse_avx2 mode iterator, and not used anywhere anyway. +;; Mapping from integer vector mode to mnemonic suffix +(define_mode_attr ssevecsize + [(V16QI "b") (V8HI "w") (V4SI "d") (V2DI "q") + (V32QI "b") (V16HI "w") (V8SI "d") (V4DI "q")]) Use ssemodesuffix. +;; Mapping of vector modes to a vector mode of double size +(define_mode_attr ssedoublesizemode + [(V2DF "V4DF") (V2DI "V4DI") (V4SF "V8SF") (V4SI "V8SI") + (V8HI "V16HI") (V16QI "V32QI") + (V4DF "V8DF") (V8SF "V16SF") + (V4DI "V8DI") (V8SI "V16SI") (V16HI "V32HI") (V32QI "V64QI")]) Remove and use ssedoublevecmode mode iterator instead. +;; Mapping for AVX +(define_mode_attr avxvecmode + [(V16QI "TI") (V8HI "TI") (V4SI "TI") (V2DI "TI") (V1TI "TI") (TI "TI") + (V4SF "V4SF") (V8SF "V8SF") (V2DF "V2DF") (V4DF "V4DF") + (V32QI "OI") (V16HI "OI") (V8SI "OI") (V4DI "OI")]) A
Re: [PATCH] PR c++/33255 - Support -Wunused-local-typedefs warning
So I finally got back to this and updated the patch according to the comments below. Jason Merrill writes: > On 07/27/2011 01:54 PM, Dodji Seketeli wrote: >> + /* Set of typedefs that are used in this function. */ >> + struct pointer_set_t * GTY((skip)) used_local_typedefs; > > Is there a reason not to just use TREE_USED for this? Done now. >> + /* Vector of locally defined typedefs, for >> + -Wunused-local-typedefs. */ >> + VEC(tree,gc) *local_typedefs; > > If the accessors are in c-common, this field should be in > c_language_function. Done, see my comment below. > >> + /* We are only interested in a typedef declared locally. */ >> + if (DECL_CONTEXT (typedef_decl) != current_function_decl) >> +return; > > What if it's used in a nested function/local class/lambda? Oops. Good catch. I have added a local_decl_p predicated and used that instead. I have also added a test case for this. >> @@ -4175,6 +4175,9 @@ mark_used (tree decl) >> >>/* Set TREE_USED for the benefit of -Wunused. */ >>TREE_USED (decl) = 1; >> + >> + maybe_record_local_typedef_use (TREE_TYPE (decl)); > > Why is this needed? If the decl has the typedef for a type, we should > have already marked it as used in grokdeclarator. > > Actually, couldn't we just mark a typedef as used when when lookup > finds it? That would avoid having to mark in so many places and avoid > the need for walk_tree. I have done this and it's indeed much better. Thanks. > I think -Wunused and -Wall should imply -Wunused-local-typedefs unless > the user specifies -Wno-unused-local-typedefs. [...] > Does your set of linemap patches fix the issue? In that case, we can > add it when those go in. OK. "Joseph S. Myers" writes: > On Fri, 29 Jul 2011, Jason Merrill wrote: > >> > Looking a bit further, it looks like the C FE uses cfun->language only >> > to store the context of the outer function when faced with a nested >> > function. This is done by c_push_function_context, called by >> > c_parser_declaration_or_fndef. Otherwise, cfun->language is not >> > allocated. Is it appropriate that -Wunused-local-typedefs allocates it >> > as well? >> >> I think so. Joseph? > > Seems reasonable. So I have done this in the C FE. -Wunused-local-typedefs allocates cfun->language when the cfun for the current function is created, and let it be garbage-collected at the end of the current function. Tested on x86_64-unknown-linux-gnu against trunk. gcc/ * c-decl.c (lookup_name): Use the new maybe_record_local_typedef_use. (pushdecl): Use the new record_locally_defined_typedef. (store_parm_decls): Allocate cfun->language. (finish_function): Use the new maybe_warn_unused_local_typedefs, and mark cfun>language to be collected. (c_push_function_context): Allocate cfun->language here only if needed. (c_pop_function_context): Likewise, mark cfun->language for collection only when it should be done. * c-typeck.c (c_expr_sizeof_type, c_cast_expr): Use the new maybe_record_local_typedef_use. gcc/c-family * c-common.h (struct c_language_function::local_typedefs): New field. (local_decl_p, record_locally_defined_typedef) (maybe_record_local_typedef_use) (maybe_warn_unused_local_typedefs): Declare new functions. * c-common.c (local_decl_p, record_locally_defined_typedef) (maybe_record_local_typedef_use) (maybe_warn_unused_local_typedefs): Define new functions. * c.opt: Declare new -Wunused-local-typedefs flag. gcc/cp * name-lookup.c (pushdecl_maybe_friend_1): Use the new record_locally_defined_typedef. * cp-tree.h (cp_maybe_record_local_typedef_use): Declare new function. * decl.c (finish_function): Use the new maybe_warn_unused_local_typedefs. * decl2.c (cp_maybe_record_local_typedef_use): New public function. (grokfield): Use the new record_locally_defined_typedef. * parser.c (lookup_name): Use the new cp_maybe_record_local_typedef_use. maybe_record_local_typedef_use. gcc/doc/ * invoke.texi: Update documentation for -Wunused-local-typedefs. gcc/testsuite/ * g++.dg/warn/Wunused-local-typedefs.C: New test file. * c-c++-common/Wunused-local-typedefs.c: Likewise. libstdc++-v3/ * include/ext/bitmap_allocator.h (__detail::__mini_vector::__lower_bound): Remove unused typedef. * src/istream.cc (std::operator>>(basic_istream& __in, basic_string& __str)): Likewise. (std::getline): Likewise. * src/valarray.cc (__valarray_product): Likewise. --- gcc/c-decl.c | 38 +- gcc/c-family/c-common.c| 114 +++ gcc/c-family/c-common.h|8 + gcc/c-family/c.opt |4 + gcc/cp/cp-tre
Re: C++ PATCH to allow VLAs with C++0x auto
On 08/05/2011 09:10 PM, Jason Merrill wrote: Paolo asked for GCC to allow deduction of auto from a variable-length array. Since auto doesn't have the issues involved with normal template deduction from VLAs (namely, the type not being link-time constant), this seems reasonable to me. Thanks! Paolo.
[PATCH, i386]: Simplify frame->save_regs_using_mov calculation.
Hello!
No functional changes.
2011-08-06 Uros Bizjak
* config/i386/i386.c (ix86_compute_frame_layout): Simplify
frame->save_regs_using_mov calculation.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: i386.c
===
--- i386.c (revision 177507)
+++ i386.c (working copy)
@@ -8742,16 +8742,12 @@ ix86_compute_frame_layout (struct ix86_frame *fram
cfun->machine->use_fast_prologue_epilogue
= !expensive_function_p (count);
}
- if (TARGET_PROLOGUE_USING_MOVE
- && cfun->machine->use_fast_prologue_epilogue)
-frame->save_regs_using_mov = true;
- else
-frame->save_regs_using_mov = false;
- /* If static stack checking is enabled and done with probes, the registers
- need to be saved before allocating the frame. */
- if (flag_stack_check == STATIC_BUILTIN_STACK_CHECK)
-frame->save_regs_using_mov = false;
+ frame->save_regs_using_mov
+= (TARGET_PROLOGUE_USING_MOVE && cfun->machine->use_fast_prologue_epilogue
+ /* If static stack checking is enabled and done with probes,
+ the registers need to be saved before allocating the frame. */
+ && flag_stack_check != STATIC_BUILTIN_STACK_CHECK);
/* Skip return address. */
offset = UNITS_PER_WORD;
[patch testsuite]: Adjust gcc.dg/tree-ssa tests for LLP64 target
Hello,
this adjusts some testcases for LLP64 target x86_64 mingw.
ChangeLog
2011-08-06 Kai Tietz
* gcc.dg/tree-ssa/pr23455.c: Adjust testcases for LLP64 for
x86_64 mingw target.
* gcc.dg/tree-ssa/loop-1.c: Likewise.
* gcc.dg/tree-ssa/ssa-store-ccp-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-store-ccp-3.c: Likewise.
* gcc.dg/tree-ssa/loop-33.c: Likewise.
* gcc.dg/tree-ssa/ssa-store-ccp-4.c: Likewise.
* gcc.dg/tree-ssa/loop-35.c: Likewise.
* gcc.dg/tree-ssa/stdarg-2.c: Likewise.
* gcc.dg/tree-ssa/stdarg-4.c: Likewise.
* gcc.dg/tree-ssa/stdarg-5.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-11c.c: Likewise.
Tested for x86_64-w64-mingw32, and checked on x86_64-pc-linux-gnu. Ok
for apply?
Regards,
Kai
Index: pr23455.c
===
--- pr23455.c (revision 177507)
+++ pr23455.c (working copy)
@@ -1,19 +1,25 @@
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-pre-stats" } */
-unsigned long outcnt;
+#ifdef _WIN64
+#define LONG long long
+#else
+#define LONG long
+#endif
+
+unsigned LONG outcnt;
extern void flush_outbuf(void);
void
bi_windup(unsigned int *outbuf, unsigned int bi_buf)
{
-unsigned long t1 = outcnt;
+unsigned LONG t1 = outcnt;
outbuf[t1] = bi_buf;
-unsigned long t2 = outcnt;
+unsigned LONG t2 = outcnt;
if (t2 == 16384)
flush_outbuf();
-unsigned long t3 = outcnt;
+unsigned LONG t3 = outcnt;
outbuf[t3] = bi_buf;
}
/* We should eliminate one load of outcnt, which will in turn let us eliminate
Index: loop-1.c
===
--- loop-1.c(revision 177507)
+++ loop-1.c(working copy)
@@ -44,10 +44,11 @@
/* CRIS keeps the address in a register. */
/* m68k sometimes puts the address in a register, depending on CPU and PIC. */
-/* { dg-final { scan-assembler-times "foo" 5 { xfail hppa*-*-*
ia64*-*-* sh*-*-* cris-*-* crisv32-*-* fido-*-* m68k-*-* i?86-*-mingw*
i?86-*-cygwin* } } } */
+/* { dg-final { scan-assembler-times "foo" 5 { xfail hppa*-*-*
ia64*-*-* sh*-*-* cris-*-* crisv32-*-* fido-*-* m68k-*-* i?86-*-mingw*
i?86-*-cygwin* x86_64-*-mingw* } } } */
/* { dg-final { scan-assembler-times "foo,%r" 5 { target hppa*-*-* } } } */
/* { dg-final { scan-assembler-times "= foo" 5 { target ia64*-*-* } } } */
/* { dg-final { scan-assembler-times "call\[ \t\]*_foo" 5 { target
i?86-*-mingw* i?86-*-cygwin* } } } */
+/* { dg-final { scan-assembler-times "call\[ \t\]*foo" 5 { target
x86_64-*-mingw* } } } */
/* { dg-final { scan-assembler-times "jsr|bsrf|blink\ttr?,r18" 5 {
target sh*-*-* } } } */
/* { dg-final { scan-assembler-times "Jsr \\\$r" 5 { target cris-*-* } } } */
/* { dg-final { scan-assembler-times "\[jb\]sr" 5 { target fido-*-*
m68k-*-* } } } */
Index: ssa-store-ccp-2.c
===
--- ssa-store-ccp-2.c (revision 177507)
+++ ssa-store-ccp-2.c (working copy)
@@ -10,5 +10,5 @@
/* There should be a reference to conststaticvariable since it may
may be overriden at link time. */
-/* { dg-final { scan-tree-dump-times "conststaticvariable" 1 "optimized"} } */
+/* { dg-final { scan-tree-dump-times "conststaticvariable" 1
"optimized" { xfail { *-*-mingw* *-*-cygwin* } } } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: ssa-store-ccp-3.c
===
--- ssa-store-ccp-3.c (revision 177507)
+++ ssa-store-ccp-3.c (working copy)
@@ -1,7 +1,7 @@
/* { dg-do compile } */
/* Skipped on MIPS GNU/Linux and IRIX target because __PIC__ can be
defined for executables as well as shared libraries. */
-/* { dg-skip-if "" { *-*-darwin* hppa*64*-*-* mips*-*-linux*
mips*-*-irix* } { "*" } { "" } } */
+/* { dg-skip-if "" { *-*-darwin* hppa*64*-*-* mips*-*-linux*
mips*-*-irix* *-*-mingw* } { "*" } { "" } } */
/* { dg-options "-O2 -fno-common -fdump-tree-optimized" } */
const int conststaticvariable;
Index: loop-33.c
===
--- loop-33.c (revision 177507)
+++ loop-33.c (working copy)
@@ -36,5 +36,5 @@
}
}
-/* { dg-final { scan-tree-dump-times "Executing store motion of" 4
"lim1" { xfail lp64 } } } */
+/* { dg-final { scan-tree-dump-times "Executing store motion of" 4
"lim1" { xfail { lp64 || llp64 } } } } */
/* { dg-final { cleanup-tree-dump "lim1" } } */
Index: ssa-store-ccp-4.c
===
--- ssa-store-ccp-4.c (revision 177507)
+++ ssa-store-ccp-4.c (working copy)
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-require-effective-target fpic } */
-/* { dg-skip-if "" { *-*-darwin* } { "*" } { "" } } */
+/* { dg-skip-if "" { *-*-darwin* *-*-mingw* } { "*" } { "" } } */
/* { dg-options "-O2 -fno-common -fpic -fdump-tree-optimized" } */
const int conststaticvariable;
Inde
PATCH: Add testcases for PRs 48084/49504/49860
Hi,
I checked in this patch to add testcases for PRs 48084/49504/49860.
H.J.
Index: gcc.target/i386/pr49504.c
===
--- gcc.target/i386/pr49504.c (revision 0)
+++ gcc.target/i386/pr49504.c (revision 0)
@@ -0,0 +1,18 @@
+/* PR target/49504 */
+/* { dg-do run { target { x32 } } } */
+/* { dg-options "-O" } */
+
+unsigned long long
+foo (const void* p, unsigned long long q)
+{
+ unsigned long long a = (((unsigned long long) ((unsigned long) p)) + q) >>
32;
+ return a;
+}
+
+int
+main ()
+{
+ if (foo (foo, 0x1ULL) != 0x1)
+__builtin_abort ();
+ return 0;
+}
Index: gcc.target/i386/pr48084-3.c
===
--- gcc.target/i386/pr48084-3.c (revision 0)
+++ gcc.target/i386/pr48084-3.c (revision 0)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse3" } */
+
+void
+_mm_monitor (void const * __P, unsigned int __E, unsigned int __H)
+{
+ __builtin_ia32_monitor (__P, __E, __H);
+}
Index: gcc.target/i386/pr48084-5.c
===
--- gcc.target/i386/pr48084-5.c (revision 0)
+++ gcc.target/i386/pr48084-5.c (revision 0)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O0 -mrdrnd" } */
+
+int
+_rdrand16_step (unsigned short *__P)
+{
+ return __builtin_ia32_rdrand16_step (__P);
+}
Index: gcc.target/i386/pr48084-2.c
===
--- gcc.target/i386/pr48084-2.c (revision 0)
+++ gcc.target/i386/pr48084-2.c (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse2" } */
+
+typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
+typedef char __v8qi __attribute__ ((__vector_size__ (8)));
+void
+_mm_maskmove_si64 (__m64 __A, __m64 __N, char *__P)
+{
+__builtin_ia32_maskmovq ((__v8qi)__A, (__v8qi)__N, __P);
+}
Index: gcc.target/i386/pr48084-4.c
===
--- gcc.target/i386/pr48084-4.c (revision 0)
+++ gcc.target/i386/pr48084-4.c (revision 0)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O0 -msse2" } */
+
+void
+_mm_clflush (void const *__A)
+{
+ __builtin_ia32_clflush (__A);
+}
Index: gcc.target/i386/pr48084-1.c
===
--- gcc.target/i386/pr48084-1.c (revision 0)
+++ gcc.target/i386/pr48084-1.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse2" } */
+
+typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
+typedef float __v2sf __attribute__ ((__vector_size__ (8)));
+typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
+typedef float __v4sf __attribute__ ((__vector_size__ (16)));
+void
+_mm_storeh_pi (__m64 *__P, __m128 __A)
+{
+ __builtin_ia32_storehps ((__v2sf *)__P, (__v4sf)__A);
+}
Index: gcc.dg/pr49860.c
===
--- gcc.dg/pr49860.c(revision 0)
+++ gcc.dg/pr49860.c(revision 0)
@@ -0,0 +1,21 @@
+/* { dg-do assemble } */
+/* { dg-options "-O3 -funroll-all-loops" } */
+
+extern char inbuf[];
+extern char outbuf[];
+extern unsigned insize;
+extern unsigned inptr;
+static int max_len;
+static int peek_bits;
+void build_tree() {
+ int len;
+ char *prefixp;
+ max_len = inbuf[inptr++];
+ peek_bits = ((max_len) <= (12) ? (max_len) : (12));
+ prefixp = &outbuf[1< outbuf) *--prefixp = 0;
+}
Index: ChangeLog
===
--- ChangeLog (revision 177508)
+++ ChangeLog (working copy)
@@ -1,3 +1,18 @@
+2011-08-06 H.J. Lu
+
+ PR target/48084
+ * gcc.target/i386/pr48084-1.c: New.
+ * gcc.target/i386/pr48084-2.c: Likewise.
+ * gcc.target/i386/pr48084-3.c: Likewise.
+ * gcc.target/i386/pr48084-4.c: Likewise.
+ * gcc.target/i386/pr48084-5.c: Likewise.
+
+ PR rtl-optimization/49504
+ * gcc.target/i386/pr49504.c: New.
+
+ PR target/49860
+ * gcc.dg/pr49860.c: New.
+
2011-08-06 Nicola Pero
PR libobjc/49882
libobjc: Fix PR libobjc/50002 ("class_replaceMethod does not work on class methods")
This patch fixes PR libobjc/50002. The problem was that replacing an existing
class method wouldn't work
because the messaging tables weren't being refreshed for class methods when a
method was replaced.
This patch also includes three other related changes:
* a new couple of comprehensive testcases, gnu-api-2-class-meta.m and
gnu-api-2-class-meta.mm, covering
calling various runtime functions with a meta class (as opposed to a normal
class) as argument. This tests the
above-mentioned fix for libobjc/50002, but also a variety of other similar
functions and situations (this is mostly
for peace of mind - I wanted to be sure that there aren't other problems
similar to libobjc/50002).
* a fix for a small issue with class_getSuperclass() (when used on a meta
class in construction), which was
identified by the testcases above. The actual problem is actually related to
libobjc/49882 - which I fixed this
morning.
* synchronizes the ObjC++ testsuite with the ObjC one. In particular, when
fixing libobjc/49882 this morning
I added an ObjC testcase but forgot to add an ObjC++ one. This patch includes
it.
Tested with GNU and Apple runtime. Committed to trunk.
Thanks
Index: libobjc/ChangeLog
===
--- libobjc/ChangeLog (revision 177506)
+++ libobjc/ChangeLog (working copy)
@@ -1,5 +1,17 @@
2011-08-06 Nicola Pero
+ PR libobjc/50002
+ * class.c (__objc_update_classes_with_methods): Iterate over meta
+ classes as well as normal classes when refreshing the method
+ implementations. This fixes replacing class methods.
+
+2011-08-06 Nicola Pero
+
+ * class.c (class_getSuperclass): Fixed to work with meta classes
+ still in construction too.
+
+2011-08-06 Nicola Pero
+
* class.c (class_getSuperclass): Fixed typo in comment.
2011-08-06 Nicola Pero
Index: libobjc/class.c
===
--- libobjc/class.c (revision 177506)
+++ libobjc/class.c (working copy)
@@ -781,35 +781,57 @@ __objc_update_classes_with_methods (struct objc_me
while (node != NULL)
{
- /* Iterate over all methods in the class. */
- Class class = node->pointer;
- struct objc_method_list * method_list = class->methods;
+ /* We execute this loop twice: the first time, we iterate
+over all methods in the class (instance methods), while
+the second time we iterate over all methods in the meta
+class (class methods). */
+ Class class = Nil;
+ BOOL done = NO;
- while (method_list)
+ while (done == NO)
{
- int i;
+ struct objc_method_list * method_list;
- for (i = 0; i < method_list->method_count; ++i)
+ if (class == Nil)
{
- struct objc_method *method = &method_list->method_list[i];
+ /* The first time, we work on the class. */
+ class = node->pointer;
+ }
+ else
+ {
+ /* The second time, we work on the meta class. */
+ class = class->class_pointer;
+ done = YES;
+ }
- /* If the method is one of the ones we are looking
-for, update the implementation. */
- if (method == method_a)
- sarray_at_put_safe (class->dtable,
- (sidx) method_a->method_name->sel_id,
- method_a->method_imp);
+ method_list = class->methods;
- if (method == method_b)
+ while (method_list)
+ {
+ int i;
+
+ for (i = 0; i < method_list->method_count; ++i)
{
- if (method_b != NULL)
+ struct objc_method *method = &method_list->method_list[i];
+
+ /* If the method is one of the ones we are
+looking for, update the implementation. */
+ if (method == method_a)
sarray_at_put_safe (class->dtable,
- (sidx)
method_b->method_name->sel_id,
- method_b->method_imp);
+ (sidx)
method_a->method_name->sel_id,
+ method_a->method_imp);
+
+ if (method == method_b)
+ {
+ if (method_b != NULL)
+ sarray_at_put_safe (class->dtable,
+ (sidx)
method_b->method_name->sel_id,
+
PATCH: Add testcases for PRs 47766/47715
Hi,
I checked in this patch to add testcases for PRs 47766/47715.
H.J.
---
Index: gcc.dg/pr47766.c
===
--- gcc.dg/pr47766.c(revision 0)
+++ gcc.dg/pr47766.c(revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fstack-protector" } */
+/* { dg-require-effective-target fstack_protector } */
+
+int
+parse_opt (int key)
+{
+ struct
+ {
+ int arg[key];
+ } reqdata;
+ return 0;
+}
Index: gcc.dg/tls/pr47715-1.c
===
--- gcc.dg/tls/pr47715-1.c (revision 0)
+++ gcc.dg/tls/pr47715-1.c (revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-O2 -fPIC" } */
+/* { dg-require-effective-target tls } */
+
+extern __thread int h_errno;
+int *
+__h_errno_location (void)
+{
+ return &h_errno;
+}
Index: gcc.dg/tls/pr47715-2.c
===
--- gcc.dg/tls/pr47715-2.c (revision 0)
+++ gcc.dg/tls/pr47715-2.c (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-O2 -fPIC" } */
+/* { dg-require-effective-target tls } */
+
+extern __thread int *__libc_resp;
+int
+__res_init(void) {
+ return *__libc_resp;
+}
Index: gcc.dg/tls/pr47715-3.c
===
--- gcc.dg/tls/pr47715-3.c (revision 0)
+++ gcc.dg/tls/pr47715-3.c (revision 0)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-O2 -fPIC" } */
+/* { dg-require-effective-target tls } */
+
+struct initial_sp
+{
+ void *sp;
+ long len;
+};
+__thread
+struct initial_sp __morestack_initial_sp;
+void bar (void *);
+void
+foo ()
+{
+ bar (&__morestack_initial_sp.len);
+}
Index: gcc.dg/tls/pr47715-4.c
===
--- gcc.dg/tls/pr47715-4.c (revision 0)
+++ gcc.dg/tls/pr47715-4.c (revision 0)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O0" } */
+/* { dg-require-effective-target tls } */
+
+struct gomp_team_state
+{
+ struct gomp_team_state *prev_ts;
+ unsigned team_id;
+ unsigned level;
+};
+struct gomp_thread
+{
+ void *data;
+ struct gomp_team_state ts;
+};
+extern __thread struct gomp_thread gomp_tls_data;
+int
+foo (int level)
+{
+ struct gomp_team_state *ts = &gomp_tls_data.ts;
+ if (level < 0 || level > ts->level)
+return -1;
+ return ts->team_id;
+}
Index: ChangeLog
===
--- ChangeLog (revision 177510)
+++ ChangeLog (working copy)
@@ -1,3 +1,14 @@
+2011-08-06 H.J. Lu
+
+ PR target/47766
+ * gcc.dg/pr47766.c: New.
+
+ PR target/47715
+ * gcc.dg/tls/pr47715-1.c: New.
+ * gcc.dg/tls/pr47715-2.c: Likewise.
+ * gcc.dg/tls/pr47715-3.c: Likewise.
+ * gcc.dg/tls/pr47715-4.c: Likewise.
+
2011-08-06 Nicola Pero
PR libobjc/50002
Re: [build] Move unwinder to toplevel libgcc (v2)
On 08/06/2011 12:43 PM, Mikael Morin wrote: On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote: On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote: I suppose it is this patch that breaks bootstrap The culprit is indeed r177447. Adding a -I flag? I suppose that makes sense even if crtstuff is moved soon to toplevel libgcc. How about this? It fixes the problem. Index: gcc/Makefile.in === --- gcc/Makefile.in (révision 177491) +++ gcc/Makefile.in (copie de travail) @@ -1088,7 +1088,7 @@ INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ -I$(srcdir)/../include @INCINTL@ \ $(CPPINC) $(GMPINC) $(DECNUMINC) \ - $(PPLINC) $(CLOOGINC) + $(PPLINC) $(CLOOGINC) -I$(srcdir)/../libgcc .c.o: $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $< $(OUTPUT_OPTION) Thanks. Can you try this instead? Paolo 2011-08-06 Paolo Bonzini Mikael Morin * Makefile.in (INCLUDES_FOR_TARGET): New. (LIBGCC2_CFLAGS): Use it. (CRTSTUFF_CFLAGS): Use it instead of INCLUDES. Index: ../gcc/gcc/Makefile.in === --- ../gcc/gcc/Makefile.in (revision 177266) +++ ../gcc/gcc/Makefile.in (working copy) @@ -668,9 +668,9 @@ endif # Options to use when compiling libgcc2.a. # LIBGCC2_DEBUG_CFLAGS = -g -LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) $(TARGET_LIBGCC2_CFLAGS) \ - $(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) \ - -DIN_LIBGCC2 \ +LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(INCLUDES_FOR_TARGET) $(GCC_CFLAGS) \ + $(TARGET_LIBGCC2_CFLAGS) $(LIBGCC2_DEBUG_CFLAGS) \ + $(GTHREAD_FLAGS) -DIN_LIBGCC2 \ -fbuilding-libgcc -fno-stack-protector \ $(INHIBIT_LIBC_CFLAGS) @@ -682,8 +682,8 @@ LIBGCC2_INCLUDES = TARGET_LIBGCC2_CFLAGS = # Options to use when compiling crtbegin/end. -CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \ - -finhibit-size-directive -fno-inline -fno-exceptions \ +CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES_FOR_TARGET) $(MULTILIB_CFLAGS) \ + -g0 -finhibit-size-directive -fno-inline -fno-exceptions \ -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \ -fno-stack-protector \ $(INHIBIT_LIBC_CFLAGS) @@ -1102,6 +1102,9 @@ INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(s $(CPPINC) $(GMPINC) $(DECNUMINC) \ $(PPLINC) $(CLOOGINC) +INCLUDES_FOR_TARGET = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ + -I$(srcdir)/../include $(DECNUMINC) -I$(srcdir)/../libgcc + .c.o: $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $< $(OUTPUT_OPTION)
PATCH: Add testcases for PRs 47449/47446
Hi,
I checked in this patch to add testcases for PRs 47449/47446.
H.J.
Index: gcc.target/i386/pr47449.c
===
--- gcc.target/i386/pr47449.c (revision 0)
+++ gcc.target/i386/pr47449.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+void bar (void *, void *);
+int
+foo (void *p1, void *p2)
+{
+ int ret1, ret2;
+ __asm ("" : "=D" (ret1), "=S" (ret2));
+ bar (p1, p2);
+ return ret1 + ret2;
+}
Index: gcc.dg/pr47446-1.c
===
--- gcc.dg/pr47446-1.c (revision 0)
+++ gcc.dg/pr47446-1.c (revision 0)
@@ -0,0 +1,40 @@
+/* { dg-do assemble } */
+/* { dg-options "-O2" } */
+
+extern void abort (void);
+enum
+{
+ __GCONV_OK = 0,
+ __GCONV_NOCONV,
+ __GCONV_NODB,
+ __GCONV_NOMEM,
+ __GCONV_EMPTY_INPUT,
+ __GCONV_FULL_OUTPUT,
+ __GCONV_ILLEGAL_INPUT,
+ __GCONV_INCOMPLETE_INPUT,
+ __GCONV_ILLEGAL_DESCRIPTOR,
+ __GCONV_INTERNAL_ERROR
+};
+int
+foo (int result)
+{
+ int irreversible = 0;
+ switch (result)
+{
+case __GCONV_ILLEGAL_INPUT:
+ irreversible = -1L;
+ break;
+case __GCONV_FULL_OUTPUT:
+ irreversible = -2L;
+ break;
+case __GCONV_INCOMPLETE_INPUT:
+ irreversible = -3L;
+ break;
+case __GCONV_EMPTY_INPUT:
+case __GCONV_OK:
+ break;
+default:
+ abort ();
+}
+ return irreversible;
+}
Index: gcc.dg/pr47446-2.c
===
--- gcc.dg/pr47446-2.c (revision 0)
+++ gcc.dg/pr47446-2.c (revision 0)
@@ -0,0 +1,41 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-O2 -fpic" } */
+
+extern void abort (void);
+enum
+{
+ __GCONV_OK = 0,
+ __GCONV_NOCONV,
+ __GCONV_NODB,
+ __GCONV_NOMEM,
+ __GCONV_EMPTY_INPUT,
+ __GCONV_FULL_OUTPUT,
+ __GCONV_ILLEGAL_INPUT,
+ __GCONV_INCOMPLETE_INPUT,
+ __GCONV_ILLEGAL_DESCRIPTOR,
+ __GCONV_INTERNAL_ERROR
+};
+int
+foo (int result)
+{
+ int irreversible = 0;
+ switch (result)
+{
+case __GCONV_ILLEGAL_INPUT:
+ irreversible = -1L;
+ break;
+case __GCONV_FULL_OUTPUT:
+ irreversible = -2L;
+ break;
+case __GCONV_INCOMPLETE_INPUT:
+ irreversible = -3L;
+ break;
+case __GCONV_EMPTY_INPUT:
+case __GCONV_OK:
+ break;
+default:
+ abort ();
+}
+ return irreversible;
+}
Index: ChangeLog
===
--- ChangeLog (revision 177511)
+++ ChangeLog (working copy)
@@ -1,5 +1,14 @@
2011-08-06 H.J. Lu
+ PR middle-end/47449
+ * gcc.target/i386/pr47449.c: New.
+
+ PR target/47446
+ * gcc.dg/pr47446-1.c: New.
+ * gcc.dg/pr47446-2.c: Likewise.
+
+2011-08-06 H.J. Lu
+
PR target/47766
* gcc.dg/pr47766.c: New.
Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections
PING.
On Fri, Jul 22, 2011 at 7:06 AM, H.J. Lu wrote:
> On Fri, Jul 22, 2011 at 7:00 AM, H.J. Lu wrote:
>> On Fri, Jul 22, 2011 at 6:03 AM, H.J. Lu wrote:
>>> On Fri, Jul 22, 2011 at 5:30 AM, Jakub Jelinek wrote:
On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote:
> @@ -2660,6 +2664,7 @@ esac
> case ${target} in
> i[34567]86-*-linux* | x86_64-*-linux*)
> tmake_file="${tmake_file} i386/t-pmm_malloc i386/t-i386"
> + use_initfini_array=yes
> ;;
> i[34567]86-*-* | x86_64-*-*)
> tmake_file="${tmake_file} i386/t-gmm_malloc i386/t-i386"
What is i?86/x86_64 specific on it? Don't most other glibc targets
want to use it too, perhaps with some arch specific tweaks?
>>>
>>> I do have a patch for all ELF targets:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01416.html
>>>
>>> It touches many targets. . But I only have one feedback from one
>>> target maintainer. I don't know how long it will take to review it.
>>>
>>>
> --- /dev/null
> +++ b/gcc/config/initfini-array.c
This is ugly. varasm.c already has lots of ELF specific code, simply
put them there as well and only let configury set some macro which will
allow targets to choose which of the implementations in the generic code
they want to use (or if they want their own which e.g. calls the generic
routine and does something additional to it etc.). The sections probably
can be created only the first time you actually need them.
>>>
>>> I will do that.
>>>
> --- a/gcc/crtstuff.c
> +++ b/gcc/crtstuff.c
> @@ -189,6 +190,9 @@ typedef void (*func_ptr) (void);
> refer to only the __CTOR_END__ symbol in crtend.o and the
> __DTOR_LIST__
> symbol in crtbegin.o, where they are defined. */
>
> +/* No need for .ctors/.dtors section if linker can place them in
> + .init_array/.fini_array section. */
> +#ifndef NO_CTORS_DTORS_SECTIONS
> /* The -1 is a flag to __do_global_[cd]tors indicating that this table
> does not start with a count of elements. */
> #ifdef CTOR_LIST_BEGIN
> @@ -219,6 +223,7 @@ STATIC func_ptr __DTOR_LIST__[1]
> __attribute__((section(".dtors"), aligned(sizeof(func_ptr
> = { (func_ptr) (-1) };
> #endif /* __DTOR_LIST__ alternatives */
> +#endif /* NO_CTORS_DTORS_SECTIONS */
>
> #ifdef USE_EH_FRAME_REGISTRY
> /* Stick a label at the beginning of the frame unwind info so we can
> register
> @@ -489,6 +494,9 @@ __do_global_ctors_1(void)
>
> #elif defined(CRT_END) /* ! CRT_BEGIN */
>
> +/* No need for .ctors/.dtors section if linker can place them in
> + .init_array/.fini_array section. */
> +#ifndef NO_CTORS_DTORS_SECTIONS
> /* Put a word containing zero at the end of each of our two lists of
> function
> addresses. Note that the words defined here go into the .ctors and
> .dtors
> sections of the crtend.o file, and since that file is always linked in
> @@ -534,6 +542,7 @@ STATIC func_ptr __DTOR_END__[1]
> __attribute__((used, section(".dtors"), aligned(sizeof(func_ptr
> = { (func_ptr) 0 };
> #endif
> +#endif /* NO_CTORS_DTORS_SECTIONS */
>
> #ifdef EH_FRAME_SECTION_NAME
> /* Terminate the frame unwind info section with a 4byte 0 as a sentinel;
I don't see how you can do this. It would IMO break any time you link code
built by different gcc versions where some code emitted by the older gcc
used .ctors or .dtors.
>>>
>>> crtstuff.c is used to generate crt*.o, which is the part of GCC. You only
>>> use
>>> it with the GCC you are using. Since your GCC doesn't put anything in
>>> .ctors/.dtors section, you don't need them. As for .o files generated by
>>> old GCCs, that is the linker test, use_initfini_array, is for. The newer
>>> linker
>>> can put input .ctors/.dtors sections in output .init_array/,fini_array
>>> sections.
>>>
>>>
>>
>> Here is the updated patch. Any comments?
>>
>> Thanks.
>>
>> --
>> H.J.
>> ---
>> 2011-07-22 H.J. Lu
>>
>> PR target/46770
>> * config.gcc (use_initfini_array): New variable.
>> Use .init_arary/.fini_array if they are supported.
>>
>> * crtstuff.c: Don't generate .ctors nor .dtors sections if
>> USE_INITFINI_ARRAY is defined.
>>
>> * output.h (default_initfini_array_init_sections): New.
>> * varasm.c (elf_init_array_section): Likewise.
>> (elf_fini_array_section): Likewise.
>> (get_elf_initfini_array_priority_section): Likewise.
>> (default_elf_init_array_asm_out_constructor): Likewise.
>> (default_elf_fini_array_asm_out_destructor): Likewise.
>> (default_initfini_array_init_sections): Likewise.
>>
>> * config/initfini-array.h: New.
>> * config/t-initfini-array: Likewise.
>>
>
> No need for config/t-initfini-array. Here is the updated pa
Re: [PATCH] Handle BIT_NOT_EXPR in VRP
On 08/05/2011 02:31 PM, Richard Guenther wrote: This extends VRP to handle BIT_NOT_EXPR by composing ~X as -X - 1 (which should give us anti-range handling for free). Just a small detail, but why not -1 - X which saves the NEGATE_EXPR? :) Paolo
PATCH: Add testcases for PRs 47727/47372/47715
Hi,
I checkd in this patch to add testcases for PRs 47727/47372/47715.
H.J.
--
Index: gcc.dg/pr47372-2.c
===
--- gcc.dg/pr47372-2.c (revision 0)
+++ gcc.dg/pr47372-2.c (revision 0)
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-O2 -fPIC -g" } */
+
+typedef unsigned short ush;
+typedef ush Pos;
+extern ush prev[];
+void fill_window( unsigned more, unsigned m)
+{
+unsigned n;
+for (n = 0; n < (unsigned)(1<<15); n++) {
+ (prev+0x8000)[n] = (Pos)(m >= 0x8000 ? m-0x8000 : 0);
+}
+for (n = 0; n < 0x8000; n++) {
+ prev[n] = (Pos)(m >= 0x8000 ? m-0x8000 : 0);
+}
+}
Index: gcc.dg/tls/pr47715-5.c
===
--- gcc.dg/tls/pr47715-5.c (revision 0)
+++ gcc.dg/tls/pr47715-5.c (revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-require-effective-target tls } */
+
+extern __thread int __libc_errno __attribute__ ((tls_model ("initial-exec")));
+;
+int *
+__errno_location (void)
+{
+ return &__libc_errno;
+}
Index: gcc.dg/pr47727.c
===
--- gcc.dg/pr47727.c(revision 0)
+++ gcc.dg/pr47727.c(revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+typedef void (*func_ptr) (void);
+static func_ptr __CTOR_END__[1] = { (func_ptr) 0 };
+static void __attribute__((used))
+__do_global_ctors_aux (void)
+{
+ func_ptr *p;
+ for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
+(*p) ();
+}
Index: gcc.dg/pr47372-1.c
===
--- gcc.dg/pr47372-1.c (revision 0)
+++ gcc.dg/pr47372-1.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-O2 -fPIC -g" } */
+
+typedef struct FILE FILE;
+int _fwalk(int (*)(FILE *));
+int __sflush(FILE *);
+int
+fflush(FILE *fp)
+{
+ return (_fwalk(__sflush));
+}
Index: ChangeLog
===
--- ChangeLog (revision 177512)
+++ ChangeLog (working copy)
@@ -1,5 +1,14 @@
2011-08-06 H.J. Lu
+ PR middle-end/47727
+ * gcc.dg/pr47727.c: New.
+
+ PR target/47372
+ * gcc.dg/pr47372-1.c: New.
+ * gcc.dg/pr47372-2.c: Likewise.
+
+2011-08-06 H.J. Lu
+
PR middle-end/47449
* gcc.target/i386/pr47449.c: New.
@@ -17,6 +26,7 @@
* gcc.dg/tls/pr47715-2.c: Likewise.
* gcc.dg/tls/pr47715-3.c: Likewise.
* gcc.dg/tls/pr47715-4.c: Likewise.
+ * gcc.dg/tls/pr47715-5.c: Likewise.
2011-08-06 Nicola Pero
PATCH: Add testcases for PR 47381
Hi,
I checked in this patch to add testcases for PR 47381.
H.J.
---
Index: gcc.target/i386/pr47381.c
===
--- gcc.target/i386/pr47381.c (revision 0)
+++ gcc.target/i386/pr47381.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=atom" } */
+
+struct foo_t {
+ int limit;
+} foo[3];
+void
+bar () {
+ int i;
+ for (i = 0; i < 3; i++) {
+__builtin_memset (&foo[i], 0, sizeof(*foo));
+ }
+}
Index: gcc.dg/pr47381-2.c
===
--- gcc.dg/pr47381-2.c (revision 0)
+++ gcc.dg/pr47381-2.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+typedef unsigned long ulg;
+long block_start;
+typedef unsigned char uch;
+extern uch window[];
+ unsigned strstart;
+ulg flush_block (char *buf, ulg stored_len, int eof);
+ulg deflate()
+{
+return flush_block(block_start >= 0L ?
(char*)&window[(unsigned)block_start] : (char*)((void *)0), (long)strstart -
block_start, (1));
+}
Index: gcc.dg/pr47381-1.c
===
--- gcc.dg/pr47381-1.c (revision 0)
+++ gcc.dg/pr47381-1.c (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+typedef unsigned IPos;
+typedef unsigned char uch;
+extern uch window[];
+unsigned max_chain_length;
+unsigned strstart;
+int longest_match(IPos cur_match, int len, int best_len)
+{
+unsigned chain_length = max_chain_length;
+register uch *scan = window + strstart;
+register uch *match;
+register uch scan_end1 = scan[best_len-1];
+register uch scan_end = scan[best_len];
+do {
+;
+match = window + cur_match;
+if (match[best_len] != scan_end ||
+match[best_len-1] != scan_end1 ||
+*match != *scan ||
+*++match != scan[1]) continue;
+best_len = len;
+} while ( --chain_length != 0);
+return best_len;
+}
Index: ChangeLog
===
--- ChangeLog (revision 177513)
+++ ChangeLog (working copy)
@@ -1,5 +1,12 @@
2011-08-06 H.J. Lu
+ PR target/47381
+ * gcc.dg/pr47381-1.c: New.
+ * gcc.dg/pr47381-2.c: Likewise.
+ * gcc.target/i386/pr47381.c: Likewise.
+
+2011-08-06 H.J. Lu
+
PR middle-end/47727
* gcc.dg/pr47727.c: New.
Re: [build] Move unwinder to toplevel libgcc (v2)
On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote: > Can you try this instead? It works. Thanks Mikael
Re: [build] Move unwinder to toplevel libgcc (v2)
On 08/06/2011 05:07 PM, Mikael Morin wrote: On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote: Can you try this instead? It works. Thanks Committed, thanks. Paolo
[patch, Fortran, committed] Fix PR 50004
Hello world,
I have committed the attached patch as obvious after regression-testing.
The problem was that gfc_typenode_for_spec was clobbering the typespec
for the ISO C types by converting them to integer.
Don't know why I hadn't seen this before.
Regards
Thomas
2011-08-06 Thomas Koenig
PR fortran/50004
* target-memory.c (gfc_target_expr-size): Don't clobber typespec
for derived types.
* simplify.c (gfc_simplify_transfer): Don't calculate source_size
twice.
Index: target-memory.c
===
--- target-memory.c (Revision 177487)
+++ target-memory.c (Arbeitskopie)
@@ -120,8 +120,14 @@ gfc_target_expr_size (gfc_expr *e)
case BT_HOLLERITH:
return e->representation.length;
case BT_DERIVED:
- type = gfc_typenode_for_spec (&e->ts);
- return int_size_in_bytes (type);
+ {
+ /* Determine type size without clobbering the typespec for ISO C
+ binding types. */
+ gfc_typespec ts;
+ ts = e->ts;
+ type = gfc_typenode_for_spec (&ts);
+ return int_size_in_bytes (type);
+ }
default:
gfc_internal_error ("Invalid expression in gfc_target_expr_size.");
return 0;
Index: simplify.c
===
--- simplify.c (Revision 177487)
+++ simplify.c (Arbeitskopie)
@@ -6048,8 +6048,6 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr
&& gfc_array_size (source, &tmp) == FAILURE)
gfc_internal_error ("Failure getting length of a constant array.");
- source_size = gfc_target_expr_size (source);
-
/* Create an empty new expression with the appropriate characteristics. */
result = gfc_get_constant_expr (mold->ts.type, mold->ts.kind,
&source->where);
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Hi Janus,
2011/8/5 Mikael Morin:
On Friday 05 August 2011 23:02:33 Thomas Koenig wrote:
The extra
argument controls whether we check variable symbols for equality or
just their names. For the overriding checks it is sufficient to check
for names, because the arguments of the overriding procedure are
required to have the same names as in the base procedure.
Could you explain for which cases this test is too strict?
For dummy arguments. If they are "corresponding" (same position, same name),
they should compare equal. Cf the PR.
The string length expressions of overridden procedures have to be
identical, but with exchanged dummy arguments. Since the dummy
arguments of overridden procedures must have the same name as in the
base procedure, it is sufficient the check for equal names. Checking
for equal symbols would be too strict.
I just tested the following patch:
Index: dependency.c
===
--- dependency.c(Revision 177487)
+++ dependency.c(Arbeitskopie)
@@ -123,7 +123,7 @@ gfc_are_identical_variables (gfc_expr *e1, gfc_exp
{
gfc_ref *r1, *r2;
- if (e1->symtree->n.sym != e2->symtree->n.sym)
+ if (strcmp(e1->symtree->n.sym->name, e2->symtree->n.sym->name))
return false;
/* Volatile variables should never compare equal to themselves. */
without any regressions. Can anybody think of a case where the names
can be identical, but the variables different? (I can't).
Maybe we can relax the test that way and get rid of the large number
of changes for gfc_dep_compare_expr everywhere (which I confess I
dislike, but I can hardly find fault with something that I have done
only yesterday, although the number of changes was much smaller there :-)
1) I have moved 'check_typebound_override' to interface.c and prefixed
it with 'gfc_'.
OK.
2) I have added the 'var_name_only flag' also to
gfc_are_identical_variables, gfc_dep_compare_functions,
identical_array_ref, check_section_vs_section and gfc_is_same_range. I
hope there is nothing else I missed.
See above; could we avoid that?
3) I have made 'gfc_are_identical_variables' static and removed the
gfc prefix (it does not seem to be used outside of dependency.c).
OK.
4) I have made 'gfc_is_same_range' static and removed the gfc prefix
(there is only a commented out reference to it in trans-array.c, so I
commented out the declaration in dependency.h, too). Also I removed
the 'def' argument, which gets always passed a '0'.
OK.
As Thomas mentions, certain cases are still not handled correctly
(e.g. A+B+C vs C+B+A, and other mathematical transformations), but I
hope they are sufficiently exotic (so that we can wait for bug reports
to roll in). In addition I expect people to declare overridden
procedures analogously to the base procedure, and not use e.g.
len=3*(x+1) in one case and len=3*x+3 in the other.
Not OK.
It is wrong to assume that expressions are unequal because we cannot
prove they are equal, with all the limitations that we currently
have. This will introduce rejects-valid bugs.
Please change
+ /* Check string length. */
+ if (proc_target->result->ts.type == BT_CHARACTER
+ && proc_target->result->ts.u.cl && old_target->result->ts.u.cl
+ && gfc_dep_compare_expr (proc_target->result->ts.u.cl->length,
+ old_target->result->ts.u.cl->length,
+ true) != 0)
to something like (untested)
+ /* Check string length. */
+ if (proc_target->result->ts.type == BT_CHARACTER
+ && proc_target->result->ts.u.cl && old_target->result->ts.u.cl
+ {
+int len_comparision;
+len_comparison = gfc_dep_compare_expr
(proc_target->result->ts.u.cl->length,
+ old_target->result->ts.u.cl->length);
+if (len_comparison != 0 && len_comparison != -2)
...
Alternatively, you could raise an error for 1 and -1 and warn only for
-2 (... may be different).
Regards
Thomas
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
On Saturday 06 August 2011 17:39:06 Thomas Koenig wrote: > > As Thomas mentions, certain cases are still not handled correctly > > (e.g. A+B+C vs C+B+A, and other mathematical transformations), but I > > hope they are sufficiently exotic (so that we can wait for bug reports > > to roll in). In addition I expect people to declare overridden > > procedures analogously to the base procedure, and not use e.g. > > len=3*(x+1) in one case and len=3*x+3 in the other. > > Not OK. > > It is wrong to assume that expressions are unequal because we cannot > prove they are equal, with all the limitations that we currently > have. This will introduce rejects-valid bugs. In the PR at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638#c8 I quote the standard: 4.5.7.3 (type-bound procedure overriding) has: • Either both shall be subroutines or both shall be functions having the same result characteristics (12.3.3). 12.3.3 (Characteristics of function results): If a type parameter of a function result or a bound of a function result array is not a constant expression, the exact dependence on the entities in the expression is a characteristic So the standards is more restrictive than expression values being the same. It requires _the exact same dependence on the entities_. My reading of this is that 3*(x+1) vs 3*x+3 is right to be rejected, same for (a+b)+c vs a+(b+c). The only worrying case that I see is the one you pointed out: a+b+c vs c+b+a (without brackets). Mikael
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
>> It is wrong to assume that expressions are unequal because we cannot >> prove they are equal, with all the limitations that we currently >> have. This will introduce rejects-valid bugs. > In the PR at > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638#c8 > I quote the standard: > > 4.5.7.3 (type-bound procedure overriding) has: > • Either both shall be subroutines or both shall be functions having the same > result characteristics (12.3.3). > > 12.3.3 (Characteristics of function results): > If a type parameter of a function result or a bound of a function result array > is not a constant expression, the > exact dependence on the entities in the expression is a characteristic > > > So the standards is more restrictive than expression values being the same. It > requires _the exact same dependence on the entities_. My reading of this is > that 3*(x+1) vs 3*x+3 is right to be rejected, same for (a+b)+c vs a+(b+c). > The only worrying case that I see is the one you pointed out: a+b+c vs c+b+a > (without brackets). Huh, I don't see what is so different between 1) 3*(x+1) vs 3*x+3 and 2) a+b+c vs c+b+a In both cases the expressions look different at first sight, but can be transformed into each other mathematically. So I'd say they are mathematically equivalent, although the spelled-out representations of these expressions differ. The question is how you interpret the standard's formulation of "exact dependence on the entities in the expression". Naively I would have taken this to mean the *mathematical* dependence (which can be represented by different actual expressions). But I'm fine with your interpretation, too, which will make life even easier for us. Cheers, Janus
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Hi Thomas,
>> The string length expressions of overridden procedures have to be
>> identical, but with exchanged dummy arguments. Since the dummy
>> arguments of overridden procedures must have the same name as in the
>> base procedure, it is sufficient the check for equal names. Checking
>> for equal symbols would be too strict.
>
>
> I just tested the following patch:
>
> Index: dependency.c
> ===
> --- dependency.c (Revision 177487)
> +++ dependency.c (Arbeitskopie)
> @@ -123,7 +123,7 @@ gfc_are_identical_variables (gfc_expr *e1, gfc_exp
> {
> gfc_ref *r1, *r2;
>
> - if (e1->symtree->n.sym != e2->symtree->n.sym)
> + if (strcmp(e1->symtree->n.sym->name, e2->symtree->n.sym->name))
> return false;
>
> /* Volatile variables should never compare equal to themselves. */
>
> without any regressions. Can anybody think of a case where the names can be
> identical, but the variables different? (I can't).
Well, I'd say this can only happen if both variables reside in
different namespaces (i.e. different modules or procedures).
> Maybe we can relax the test that way and get rid of the large number
> of changes for gfc_dep_compare_expr everywhere (which I confess I
> dislike, but I can hardly find fault with something that I have done
> only yesterday, although the number of changes was much smaller there :-)
Ok, I don't like the large number of changes either, but I assumed
they were necessary.
I have to admit I'm not aware of all the cases that
'gfc_dep_compare_expr' was intended for originally. I was only trying
to re-use it for checking overriding procedures, which seems to work
very well, except for the "variable names vs. symbols" issue. If you
tell me it's fine to only check for variable names everywhere, this is
of course fine.
Btw, the fact that your patch has no regressions does not necessarily
mean that there are no cases where it could fail. It could just mean
that the testsuite does not cover these cases.
Cheers,
Janus
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
>> This lets me think that one should enable the comparison by name for dummy >> arguments only. Other variables should compare normally. > > Good point. I have attached a new version of the patch, which adds > this constraint, plus: > > 1) I have moved 'check_typebound_override' to interface.c and prefixed > it with 'gfc_'. > > 2) I have added the 'var_name_only flag' also to > gfc_are_identical_variables, gfc_dep_compare_functions, > identical_array_ref, check_section_vs_section and gfc_is_same_range. I > hope there is nothing else I missed. > > 3) I have made 'gfc_are_identical_variables' static and removed the > gfc prefix (it does not seem to be used outside of dependency.c). > > 4) I have made 'gfc_is_same_range' static and removed the gfc prefix > (there is only a commented out reference to it in trans-array.c, so I > commented out the declaration in dependency.h, too). Also I removed > the 'def' argument, which gets always passed a '0'. > > I will regtest this once more, construct some mildly complex test > cases and add a ChangeLog. Btw, this patch regtests cleanly (except for c_ptr_tests_16.f90, which is PR 50004). Cheers, Janus
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Am 06.08.2011 18:16, schrieb Janus Weil: without any regressions. Can anybody think of a case where the names can be > identical, but the variables different? (I can't). Well, I'd say this can only happen if both variables reside in different namespaces (i.e. different modules or procedures). gfc_are_identical variables is only called from within gfc_dep_compare_expr. It makes no sense to call this function to compare expressions from different statements, unless one has carefully analyzed that no intervening assignment to the variables has taken place. Comparing across namespaces makes even less sense. So yes, I think it is enough if we compare the variable names, and document this in a commtent. > I have to admit I'm not aware of all the cases that > 'gfc_dep_compare_expr' was intended for originally. I was only trying > to re-use it for checking overriding procedures, which seems to work > very well, except for the "variable names vs. symbols" issue. If you > tell me it's fine to only check for variable names everywhere, this is > of course fine. Well, I also wrote the function, so maybe I can claim a little bit of authority here on the way it was originally meant to be ;-) > Btw, the fact that your patch has no regressions does not necessarily > mean that there are no cases where it could fail. It could just mean > that the testsuite does not cover these cases. Of course. However, when analysis and regression test agree, it is usually a good sign :-)
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
On Saturday 06 August 2011 18:06:58 Janus Weil wrote: > >> It is wrong to assume that expressions are unequal because we cannot > >> prove they are equal, with all the limitations that we currently > >> have. This will introduce rejects-valid bugs. > > > > In the PR at > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638#c8 > > I quote the standard: > > > > 4.5.7.3 (type-bound procedure overriding) has: > > • Either both shall be subroutines or both shall be functions having the > > same result characteristics (12.3.3). > > > > 12.3.3 (Characteristics of function results): > > If a type parameter of a function result or a bound of a function result > > array is not a constant expression, the > > exact dependence on the entities in the expression is a characteristic > > > > > > So the standards is more restrictive than expression values being the > > same. It requires _the exact same dependence on the entities_. My > > reading of this is that 3*(x+1) vs 3*x+3 is right to be rejected, same > > for (a+b)+c vs a+(b+c). The only worrying case that I see is the one you > > pointed out: a+b+c vs c+b+a (without brackets). > > Huh, I don't see what is so different between > > 1) 3*(x+1) vs 3*x+3 and > 2) a+b+c vs c+b+a > > In both cases the expressions look different at first sight, but can > be transformed into each other mathematically. So I'd say they are > mathematically equivalent, although the spelled-out representations of > these expressions differ. I was looking at the standard, because I was not so sure myself. Here is what is written (7.1.5.2.4): Once the interpretation of a numeric intrinsic operation is established, the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated. Two expressions of a numeric type are mathematically equivalent if, for all possible values of their primaries, theirmathematical values are equal. So parentheses have to be respected; other than that anything is possible. This is about the evaluation of expressions though, not about the "dependences on entities". > > The question is how you interpret the standard's formulation of "exact > dependence on the entities in the expression". That is the question. > Naively I would have > taken this to mean the *mathematical* dependence (which can be > represented by different actual expressions). But I'm fine with your > interpretation, too, which will make life even easier for us. Yes, my interpretation is somewhat biased towards ease of implementation. ;-) Mikael
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
>>> without any regressions. Can anybody think of a case where the names can >>> be >>> > identical, but the variables different? (I can't). >> >> Well, I'd say this can only happen if both variables reside in >> different namespaces (i.e. different modules or procedures). >> > > gfc_are_identical variables is only called from within gfc_dep_compare_expr. > It makes no sense to call this function > to compare expressions from different statements, unless one has carefully > analyzed that no intervening assignment to the variables has taken place. > Comparing across namespaces makes even less sense. > > So yes, I think it is enough if we compare the variable names, and > document this in a commtent. Actually, on second thought, I disagree. For the original usage cases of gfc_dep_compare_expr, I'm not sure if one can guarantee the expressions to be in the same namespace. However, for the overriding checks, both expressions are guaranteed to be in *different* namespaces (namely: two different procedures). And as Mikael noted, it is crucial wether the symbols in the expressions are dummy arguments or not: 1) Dummies are guaranteed to have equal names in overridden procedures, so we can just compare names. 2) Non-dummies could have the same name, but still sit in different namespaces, so for them we really have to check for equal symbols! Here is a variant of the original test case from the PR, which will be accepted if we only check for names (but it should actually be rejected): module world implicit none type :: world_1 contains procedure, nopass :: string => w1_string end type type, extends(world_1) :: world_2 contains procedure, nopass :: string => w2_string end type contains function w1_string (m) integer, parameter :: n = 5 integer, intent(in) :: m character(n+m) :: w1_string w1_string = "world" end function function w2_string (m) integer, parameter :: n = 6 integer, intent(in) :: m character(n+m) :: w2_string w2_string = "world2" end function end module Cheers, Janus
[PATCH, i386]: Update gcc.target/i386/sse-{22,23}.c
Hello!
2011-08-06 Uros Bizjak
* gcc.target/i386/sse-22.c (dg-options): Add -march=k8.
(pragma GCC target): Add avx, fma4, lzcnt and bmi options.
* gcc.target/i386/sse-23.c (pragma GCC target): Add avx, fma4,
lzcnt and bmi options.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: gcc.target/i386/sse-23.c
===
--- gcc.target/i386/sse-23.c(revision 177507)
+++ gcc.target/i386/sse-23.c(working copy)
@@ -4,12 +4,14 @@
#include
/* Test that the intrinsics compile with optimization. All of them
- are defined as inline functions in {,x,e,p,t,s,w,a}mmintrin.h,
- xopintrin.h, lwpintrin.h, tbmintrin.h, popcntintrin.h and mm3dnow.h
- that reference the proper builtin functions. Defining away "extern"
- and "__inline" results in all of them being compiled as proper
- functions. */
+ are defined as inline functions in {,x,e,p,t,s,w,a,b,i}mmintrin.h,
+ mm3dnow.h, fma4intrin.h, xopintrin.h, abmintrin.h, bmiintrin.h,
+ tbmintrin.h, lwpintrin.h, popcntintrin.h and mm_malloc.h that
+ reference the proper builtin functions.
+ Defining away "extern" and "__inline" results in all of them being
+ compiled as proper functions. */
+
#define extern
#define __inline
@@ -145,7 +147,7 @@
#define __builtin_ia32_bextri_u32(X, Y) __builtin_ia32_bextr_u32 (X, 1)
#define __builtin_ia32_bextri_u64(X, Y) __builtin_ia32_bextr_u64 (X, 1)
-#pragma GCC target
("3dnow,sse4,sse4a,aes,pclmul,xop,abm,popcnt,lwp,tbm,fsgsbase,rdrnd,f16c")
+#pragma GCC target
("sse4a,3dnow,avx,fma4,xop,aes,pclmul,popcnt,abm,lzcnt,bmi,tbm,lwp,fsgsbase,rdrnd,f16c")
#include
#include
#include
Index: gcc.target/i386/sse-22.c
===
--- gcc.target/i386/sse-22.c(revision 177507)
+++ gcc.target/i386/sse-22.c(working copy)
@@ -1,16 +1,18 @@
/* Same as sse-14, except converted to use #pragma GCC option. */
/* { dg-do compile } */
-/* { dg-options "-O0 -Werror-implicit-function-declaration" } */
+/* { dg-options "-O0 -Werror-implicit-function-declaration -march=k8" } */
#include
-/* Test that the intrinsics compile without optimization. All of them
- are defined as inline functions in {,x,e,p,t,s,w,a}mmintrin.h,
- xopintrin.h, tbmintrin.h, lwpintrin.h, popcntintrin.h and
- mm3dnow.h that reference the proper builtin functions. Defining
- away "extern" and "__inline" results in all of them being compiled as
- proper functions. */
+/* Test that the intrinsics compile with optimization. All of them
+ are defined as inline functions in {,x,e,p,t,s,w,a,b,i}mmintrin.h,
+ mm3dnow.h, fma4intrin.h, xopintrin.h, abmintrin.h, bmiintrin.h,
+ tbmintrin.h, lwpintrin.h, popcntintrin.h and mm_malloc.h that
+ reference the proper builtin functions.
+ Defining away "extern" and "__inline" results in all of them being
+ compiled as proper functions. */
+
#define extern
#define __inline
@@ -32,6 +34,11 @@
type _CONCAT(_,func) (op1_type A, op2_type B, int const I, int const L) \
{ return func (A, B, imm1, imm2); }
+#define test_3(func, type, op1_type, op2_type, op3_type, imm) \
+ type _CONCAT(_,func) (op1_type A, op2_type B,
\
+ op3_type C, int const I)\
+ { return func (A, B, C, imm); }
+
#define test_4(func, type, op1_type, op2_type, op3_type, op4_type, imm)
\
type _CONCAT(_,func) (op1_type A, op2_type B,
\
op3_type C, op4_type D, int const I)\
@@ -39,7 +46,7 @@
#ifndef DIFFERENT_PRAGMAS
-#pragma GCC target
("mmx,3dnow,sse,sse2,sse3,ssse3,sse4.1,sse4.2,sse4a,aes,pclmul,xop,popcnt,abm,lwp,fsgsbase,rdrnd,f16c,tbm")
+#pragma GCC target
("sse4a,3dnow,avx,fma4,xop,aes,pclmul,popcnt,abm,lzcnt,bmi,tbm,lwp,fsgsbase,rdrnd,f16c")
#endif
/* Following intrinsics require immediate arguments. They
@@ -107,14 +114,18 @@
test_1x (_mm_extracti_si64, __m128i, __m128i, 1, 1)
test_2x (_mm_inserti_si64, __m128i, __m128i, __m128i, 1, 1)
-/* smmintrin.h (SSE4.1). */
-/* nmmintrin.h (SSE4.2). */
-/* Note, nmmintrin.h includes smmintrin.h, and smmintrin.h checks for the
- #ifdef. So just set the option to SSE4.2. */
+/* Note, nmmintrin.h includes smmintrin.h, and smmintrin.h
+ checks for the #ifdef. So just set the option to SSE4.2. */
#ifdef DIFFERENT_PRAGMAS
#pragma GCC target ("sse4.2")
#endif
#include
+/* smmintrin.h (SSE4.2). */
+test_1 (_mm_round_pd, __m128d, __m128d, 1)
+test_1 (_mm_round_ps, __m128, __m128, 1)
+test_2 (_mm_round_sd, __m128d, __m128d, __m128d, 1)
+test_2 (_mm_round_ss, __m128, __m128, __m128, 1)
+
test_2 (_mm_blend_epi16, __m128i, __m128i, __m128i, 1)
test_2 (_mm_blend_ps, __m128, __m128, __m128, 1)
test_2 (_mm_blend_pd, __m128d, __m128d, __m128d, 1)
@@ -148,6 +159,53 @@
test_4 (_mm_cmpestrs, int, __m12
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
> Here is a variant of the original test case from the PR, which will be > accepted if we only check for names (but it should actually be > rejected): > > > module world > > implicit none > > type :: world_1 > contains > procedure, nopass :: string => w1_string > end type > > type, extends(world_1) :: world_2 > contains > procedure, nopass :: string => w2_string > end type > > contains > > function w1_string (m) > integer, parameter :: n = 5 > integer, intent(in) :: m > character(n+m) :: w1_string > w1_string = "world" > end function > > function w2_string (m) > integer, parameter :: n = 6 > integer, intent(in) :: m > character(n+m) :: w2_string > w2_string = "world2" > end function > > end module Sorry, now I have to disagree with my own earlier claims: In this example, the 'n' variables will of course be simplified to EXPR_CONSTANTs, so the name checking does not apply to them. And since the string length can not depend on local variables which are *not* constant, name checking should still be fine! Now, if Thomas says it's fine for the other cases, too, then it seems we can really get away with a much simpler patch. Hope we're not missing anything, though ... Cheers, Janus
Re: [PATCH 9/9] dwarf2cfi: Generate and connect traces.
On Thu, Jul 14, 2011 at 4:07 PM, Richard Henderson wrote: > This kinda-sorta corresponds to Bernd's 007-dw2cfi patch. Certainly > the same concepts of splitting the instruction stream into extended > basic blocks is the same. This patch does a bit better job with the > documentation. Also, I'm a bit more explicit about matching things > up with the similar code from the regular CFG routines. > > What's missing at this point is any attempt to use DW_CFA_remember_state. > I've deferred that for the moment because it's easy to test the state > change code across epilogues, whereas the shrink-wrapping code is not > in this tree and section switching is difficult to force. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49994 -- H.J.
Re: [PATCH, libiberty]: Check result of fwrite in test-expandargv.c
On Fri, Aug 5, 2011 at 11:51 PM, Uros Bizjak wrote: > My system warns during compilation of libiberty test-expandargv.c test: > > gcc -DHAVE_CONFIG_H -g -O2 -I.. > -I../../../gcc-svn/trunk/libiberty/testsuite/../../include > -DHAVE_CONFIG_H -I.. -o test-expandargv \ > ../../../gcc-svn/trunk/libiberty/testsuite/test-expandargv.c > ../libiberty.a > ../../../gcc-svn/trunk/libiberty/testsuite/test-expandargv.c: In > function ‘writeout_test’: > ../../../gcc-svn/trunk/libiberty/testsuite/test-expandargv.c:211: > warning: ignoring return value of ‘fwrite’, declared with attribute > warn_unused_result > > Attached patch fixes this warning. > > 2011-08-05 Uros Bizjak > > * testsuite/test-expandargv.c (writeout_test): Check result of fwrite. > > Tested on alphaev68-pc-linux-gnu and x86_64-pc-linux-gnu. I have committed this patch as obvious. Please also note, that size and nitems arguments to fwrite were reversed. Uros.
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
On Saturday 06 August 2011 19:10:09 Janus Weil wrote: > Now, if Thomas says it's fine for the other cases, too, then it seems > we can really get away with a much simpler patch. Hope we're not > missing anything, though ... > What about this case: two module variables from two different modules? module world1 implicit none integer :: n type :: t1 contains procedure, nopass :: string => w1_string end type contains function w1_string (m) integer, intent(in) :: m character(n) :: w1_string w1_string = "world" end function end module world1 module world2 use world1, only : t1 implicit none integer :: n type, extends(t1) :: t2 contains procedure, nopass :: string => w2_string end type contains function w2_string (m) integer, intent(in) :: m character(n) :: w2_string w2_string = "world2" end function end module world2
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
2011/8/6 Mikael Morin :
> On Saturday 06 August 2011 19:10:09 Janus Weil wrote:
>> Now, if Thomas says it's fine for the other cases, too, then it seems
>> we can really get away with a much simpler patch. Hope we're not
>> missing anything, though ...
>>
>
> What about this case: two module variables from two different modules?
Yeah, ok. So we *do* need to distinguish between dummies and other
variables, but maybe we can still get by without additional
'var_name_only' arguments (new patch attached).
Cheers,
Janus
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 177528)
+++ gcc/fortran/interface.c (working copy)
@@ -3466,3 +3466,207 @@ gfc_free_formal_arglist (gfc_formal_arglist *p)
free (p);
}
}
+
+
+/* Check that it is ok for the typebound procedure 'proc' to override the
+ procedure 'old' (F08:4.5.7.3). */
+
+gfc_try
+gfc_check_typebound_override (gfc_symtree* proc, gfc_symtree* old)
+{
+ locus where;
+ const gfc_symbol* proc_target;
+ const gfc_symbol* old_target;
+ unsigned proc_pass_arg, old_pass_arg, argpos;
+ gfc_formal_arglist* proc_formal;
+ gfc_formal_arglist* old_formal;
+
+ /* This procedure should only be called for non-GENERIC proc. */
+ gcc_assert (!proc->n.tb->is_generic);
+
+ /* If the overwritten procedure is GENERIC, this is an error. */
+ if (old->n.tb->is_generic)
+{
+ gfc_error ("Can't overwrite GENERIC '%s' at %L",
+ old->name, &proc->n.tb->where);
+ return FAILURE;
+}
+
+ where = proc->n.tb->where;
+ proc_target = proc->n.tb->u.specific->n.sym;
+ old_target = old->n.tb->u.specific->n.sym;
+
+ /* Check that overridden binding is not NON_OVERRIDABLE. */
+ if (old->n.tb->non_overridable)
+{
+ gfc_error ("'%s' at %L overrides a procedure binding declared"
+ " NON_OVERRIDABLE", proc->name, &where);
+ return FAILURE;
+}
+
+ /* It's an error to override a non-DEFERRED procedure with a DEFERRED one. */
+ if (!old->n.tb->deferred && proc->n.tb->deferred)
+{
+ gfc_error ("'%s' at %L must not be DEFERRED as it overrides a"
+ " non-DEFERRED binding", proc->name, &where);
+ return FAILURE;
+}
+
+ /* If the overridden binding is PURE, the overriding must be, too. */
+ if (old_target->attr.pure && !proc_target->attr.pure)
+{
+ gfc_error ("'%s' at %L overrides a PURE procedure and must also be PURE",
+ proc->name, &where);
+ return FAILURE;
+}
+
+ /* If the overridden binding is ELEMENTAL, the overriding must be, too. If it
+ is not, the overriding must not be either. */
+ if (old_target->attr.elemental && !proc_target->attr.elemental)
+{
+ gfc_error ("'%s' at %L overrides an ELEMENTAL procedure and must also be"
+ " ELEMENTAL", proc->name, &where);
+ return FAILURE;
+}
+ if (!old_target->attr.elemental && proc_target->attr.elemental)
+{
+ gfc_error ("'%s' at %L overrides a non-ELEMENTAL procedure and must not"
+ " be ELEMENTAL, either", proc->name, &where);
+ return FAILURE;
+}
+
+ /* If the overridden binding is a SUBROUTINE, the overriding must also be a
+ SUBROUTINE. */
+ if (old_target->attr.subroutine && !proc_target->attr.subroutine)
+{
+ gfc_error ("'%s' at %L overrides a SUBROUTINE and must also be a"
+ " SUBROUTINE", proc->name, &where);
+ return FAILURE;
+}
+
+ /* If the overridden binding is a FUNCTION, the overriding must also be a
+ FUNCTION and have the same characteristics. */
+ if (old_target->attr.function)
+{
+ if (!proc_target->attr.function)
+ {
+ gfc_error ("'%s' at %L overrides a FUNCTION and must also be a"
+ " FUNCTION", proc->name, &where);
+ return FAILURE;
+ }
+
+ /* FIXME: Do more comprehensive checking (including, for instance,
+ the array shape). */
+ gcc_assert (proc_target->result && old_target->result);
+ if (!compare_type_rank (proc_target->result, old_target->result))
+ {
+ gfc_error ("'%s' at %L and the overridden FUNCTION should have"
+ " matching result types and ranks", proc->name, &where);
+ return FAILURE;
+ }
+
+ /* Check string length. */
+ if (proc_target->result->ts.type == BT_CHARACTER
+ && proc_target->result->ts.u.cl && old_target->result->ts.u.cl
+ && gfc_dep_compare_expr (proc_target->result->ts.u.cl->length,
+ old_target->result->ts.u.cl->length) != 0)
+ {
+ gfc_error ("Character length mismatch between '%s' at '%L' "
+ "and overridden FUNCTION", proc->name, &where);
+ return FAILURE;
+ }
+}
+
+ /* If the overridden binding is PUBLIC, the overriding one must not be
+ PRIVATE. */
+ if (old->n.tb->access == ACCESS_PUBLIC
+ && proc->n.tb->access == ACCESS_PRIVATE)
+{
+ gfc_error ("'%s' at %L overrides a PUBLIC procedure and must not be"
+ " PRIVATE", proc->name, &where);
+ return FAILURE;
+}
+
+ /* Compare the formal argument lists of both procedure
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
On Sat, Aug 06, 2011 at 06:45:36PM +0200, Mikael Morin wrote: > On Saturday 06 August 2011 18:06:58 Janus Weil wrote: > > >> It is wrong to assume that expressions are unequal because we cannot > > >> prove they are equal, with all the limitations that we currently > > >> have. This will introduce rejects-valid bugs. > > > > > > In the PR at > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638#c8 > > > I quote the standard: > > > > > > 4.5.7.3 (type-bound procedure overriding) has: > > > ? Either both shall be subroutines or both shall be functions having the > > > same result characteristics (12.3.3). > > > > > > 12.3.3 (Characteristics of function results): > > > If a type parameter of a function result or a bound of a function result > > > array is not a constant expression, the > > > exact dependence on the entities in the expression is a characteristic > > > > > > > > > So the standards is more restrictive than expression values being the > > > same. It requires _the exact same dependence on the entities_. My > > > reading of this is that 3*(x+1) vs 3*x+3 is right to be rejected, same > > > for (a+b)+c vs a+(b+c). The only worrying case that I see is the one you > > > pointed out: a+b+c vs c+b+a (without brackets). > > > > Huh, I don't see what is so different between > > > > 1) 3*(x+1) vs 3*x+3 and > > 2) a+b+c vs c+b+a > > > > In both cases the expressions look different at first sight, but can > > be transformed into each other mathematically. So I'd say they are > > mathematically equivalent, although the spelled-out representations of > > these expressions differ. > I was looking at the standard, because I was not so sure myself. > Here is what is written (7.1.5.2.4): > > Once the interpretation of a numeric intrinsic operation is established, the > processor may evaluate any mathematically equivalent expression, provided > that > the integrity of parentheses is not violated. > > Two expressions of a numeric type are mathematically equivalent if, for all > possible values of their primaries, theirmathematical values are equal. > > > So parentheses have to be respected; other than that anything is possible. See Note 7.18. X*(Y-Z) -> X*Y - X*Z is a forbidden transformation (there is no noted restriction on Z > 0). a + b + c -> b + a + c -> b + (a + c) is a sequence of allowable transformations. -- Steve
[PATCH, alpha]: Fix PR target/50001, ICE in reload_combine_note_use, at postreload.c:1538
Hello!
The problem was that exception_receiver pattern recorded a stack slot
that referred to virtual-stack-vars. Recent changes moved generation
of exception landing pads after virtuals were instantiated, so in
bbpart pass we emitted:
(insn 262 266 263 51 (unspec_volatile [
(mem/c:DI (plus:DI (reg/f:DI 65 virtual-stack-vars)
(const_int 16 [0x10])) [0 S8 A64])
] UNSPECV_EHR) 278 {*exception_receiver_2}
(nil))
Later passes choked on uninstantiated register.
Attached patch defines TARGET_INSTANTIATE_DECLS to also instantiate
registers in saved stack slot address.
2011-08-06 Uros Bizjak
PR target/50001
* config/alpha/alpha.c (alpha_instantiate_decls): New function.
(TARGET_INSTANTIATE_DECLS): New define.
Patch was bootstrapped and regtested on alphaev68-pc-linux-gnu, where
fixes g++.dg/tree-prof/partition1.C ICEs in the testsuite.
Patch was committed to SVN mainline, will be also committed to release branches.
Uros.
Index: alpha.c
===
--- alpha.c (revision 177507)
+++ alpha.c (working copy)
@@ -4632,6 +4632,13 @@ alpha_gp_save_rtx (void)
return m;
}
+static void
+alpha_instantiate_decls (void)
+{
+ if (cfun->machine->gp_save_rtx != NULL_RTX)
+instantiate_decl_rtl (cfun->machine->gp_save_rtx);
+}
+
static int
alpha_ra_ever_killed (void)
{
@@ -9811,6 +9818,9 @@ alpha_conditional_register_usage (void)
#undef TARGET_TRAMPOLINE_INIT
#define TARGET_TRAMPOLINE_INIT alpha_trampoline_init
+#undef TARGET_INSTANTIATE_DECLS
+#define TARGET_INSTANTIATE_DECLS alpha_instantiate_decls
+
#undef TARGET_SECONDARY_RELOAD
#define TARGET_SECONDARY_RELOAD alpha_secondary_reload
Re: [build] Move unwinder to toplevel libgcc (v2)
Thanks again for doing this.
Rainer Orth writes:
> * config.host (unwind_header): New variable.
> (*-*-freebsd*): Set tmake_file to t-eh-dw2-dip.
> (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu, *-*-knetbsd*-gnu,
> *-*-gnu*): Likewise, also for *-*-kopensolaris*-gnu.
> (*-*-solaris2*): Add t-eh-dw2-dip to tmake_file.
The combination of this and the soft-fp patch meant that t-mips
wasn't included by mips*-linux-gnu. The fix below seemed obvious,
especially given the solaris case, so I applied it after testing
on mips64-linux-gnu.
Richard
libgcc/
* config.host (*-*-darwin*, *-*-freebsd*, *-*-linux*, frv-*-*linux*)
(*-*-kfreebsd*-gnu, *-*-knetbsd*-gnu, *-*-gnu*, *-*-kopensolaris*-gnu):
Add to tmake_file rather than overriding it.
Index: libgcc/config.host
===
--- libgcc/config.host 2011-08-06 15:36:16.0 +0100
+++ libgcc/config.host 2011-08-06 15:36:52.0 +0100
@@ -163,7 +163,7 @@ esac
case ${host} in
*-*-darwin*)
asm_hidden_op=.private_extern
- tmake_file="t-darwin ${cpu_type}/t-darwin t-slibgcc-darwin"
+ tmake_file="$tmake_file t-darwin ${cpu_type}/t-darwin t-slibgcc-darwin"
extra_parts=crt3.o
;;
*-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
@@ -179,10 +179,10 @@ case ${host} in
# This is the generic ELF configuration of FreeBSD. Later
# machine-specific sections may refine and add to this
# configuration.
- tmake_file=t-eh-dw2-dip
+ tmake_file="$tmake_file t-eh-dw2-dip"
;;
*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-gnu* |
*-*-kopensolaris*-gnu)
- tmake_file=t-eh-dw2-dip
+ tmake_file="$tmake_file t-eh-dw2-dip"
extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
;;
*-*-netbsd*)
Re: [build] Move sync, mips16.S to toplevel libgcc
Rainer Orth writes: > Rainer Orth writes: >> Another easy part in the toplevel libgcc move was sync.c and related >> stuff. While doing this, it turned out to be easier to move the rest of >> gcc/config/mips/t-libgcc-mips16 rather than leave it behind. >> >> The patch is untested except for including it in a mips-sgi-irix6.5 >> build to make sure it is syntactically correct, but I don't have mips16 >> system to actually test. > > Since Richard had found that that patch didn't work on systems where > mips16.S is actually used since LIB1ASMSRC is only searched in > gcc/config, I'm deferring that part to a followup patch to deal with > libgcc1 (LIB1* etc.) as a whole. That patch is almost ready, just needs > a final read-over and a couple of finishing touches. > > So this patch only deals with the sync functions proper and should be > relatively straightforward. Richard, could you please try this one, > too? Sure. Tested on mips64-linux-gnu, where it works fine, thanks. > 2011-07-10 Rainer Orth > > gcc: > * config/sync.c: Move to ../libgcc. > * Makefile.in (libgcc.mvars): Remove LIBGCC_SYNC, > LIBGCC_SYNC_CFLAGS. > * config/mips/t-libgcc-mips16 (LIBGCC_SYNC, LIBGCC_SYNC_CFLAGS): > Remove. > > libgcc: > * sync.c: New file. > * config/mips/t-mips16: New file. > * config.host (mips64*-*-linux*): Add mips/t-mips16 to tmake_file. > (mips*-*-linux*): Likewise. > (mips*-sde-elf*): Likewise. > (mipsisa32-*-elf*): Join with mipsisa32r2-*-elf*, > mipsisa64-*-elf*, mipsisa64r2-*-elf*. > Add mips/t-mips16 to tmake_file. > (mipsisa64sb1-*-elf*): Add mips/t-mips16 to tmake_file. > (mips-*-elf*): Likewise. > (mips64-*-elf*): Likewise. > (mips64orion-*-elf*): Likewise. > (mips*-*-rtems*): Likewise. > (mipstx39-*-elf*): Likewise. > * Makefile.in: Use SYNC instead of LIBGCC_SYNC. > ($(libgcc-sync-size-funcs-o)): Use SYNC_CFLAGS instead of > LIBGCC_SYNC_CFLAGS. > Use $(srcdir) to refer to sync.c. > Use $<. > ($(libgcc-sync-funcs-o)): Likewise. > ($(libgcc-sync-size-funcs-s-o)): Likewise. > ($(libgcc-sync-funcs-s-o)): Likewise. OK for the MIPS parts. Richard
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Hi Janus, + /* Check string length. */ + if (proc_target->result->ts.type == BT_CHARACTER + && proc_target->result->ts.u.cl&& old_target->result->ts.u.cl + && gfc_dep_compare_expr (proc_target->result->ts.u.cl->length, + old_target->result->ts.u.cl->length) != 0) This remains incorrect. Please change that to a warning (at least) if gfc_dep_compare_expr returns -2. Regards Thomas
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Hi Thomas, >> + /* Check string length. */ >> + if (proc_target->result->ts.type == BT_CHARACTER >> + && proc_target->result->ts.u.cl&& old_target->result->ts.u.cl >> + && gfc_dep_compare_expr (proc_target->result->ts.u.cl->length, >> + old_target->result->ts.u.cl->length) != >> 0) > > This remains incorrect. well, I'm not so sure. If we assume a 'strict' interpretation of Mikael's standard quotes, then it would be ok. > Please change that to a warning (at least) if gfc_dep_compare_expr returns > -2. I don't think this is a good idea: gfc_dep_compare_expr also tries to determine whether one expr is larger or smaller than the other. Therefore the return value "-2" can have two meanings: 1) We don't know if the expressions are equal. 2) We know that they are unequal, but we don't know which one is larger. For the overriding check, we don't care about which expr is larger, we want to know whether they are the same or not. So, in many cases we will just get a warning, although we definitely know that the expr's are different. Example: Differing expr_type, e.g. one procedure has len=3, the other has len=x. It's obvious they are different, but gfc_dep_compare_expr will still return "-2" (because we can not tell which one is larger). I would tend to leave the check like it is (i.e. rejecting everything !=0), but if you insist, one could extend the output values of gfc_dep_compare_expr, e.g. like this: -3 = we know nothing (neither if they could be equal, nor which one is larger) -2 = we know they are different, but not which one is larger However, one may then have to modify the diagnostics on these return values in quite a few places(?). Note: The last version of my patch also regtests fine. Cheers, Janus
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Am 06.08.2011 21:26, schrieb Janus Weil: Hi Thomas, + /* Check string length. */ + if (proc_target->result->ts.type == BT_CHARACTER +&&proc_target->result->ts.u.cl&&old_target->result->ts.u.cl +&&gfc_dep_compare_expr (proc_target->result->ts.u.cl->length, + old_target->result->ts.u.cl->length) != 0) This remains incorrect. well, I'm not so sure. If we assume a 'strict' interpretation of Mikael's standard quotes, then it would be ok. I think that interpretation is wrong too, based on the leeway that the standard gives in interpreting expressions. a + b + c and c + b + a are mathematically equivalent, and, right now, we cannot prove them to be so. (Yes, I would dearly like to do that, but that is really hard based on the current gfc_expr format. Instead of parsing a + b + c as (+ (+ a b) c) like we do now, using (+ a b c) which would make simplification much easier. But the question is how much we would gain from this vs. the effort :-). Even hardline interpretation were correct, we are not even required to diagnose this, because this is not a constraint. The burden is on the programmer, not the compiler writer. I think it is most important to not reject correct programs. Please change that to a warning (at least) if gfc_dep_compare_expr returns -2. I don't think this is a good idea: gfc_dep_compare_expr also tries to determine whether one expr is larger or smaller than the other. Therefore the return value "-2" can have two meanings: 1) We don't know if the expressions are equal. 2) We know that they are unequal, but we don't know which one is larger. Right now, we have the following cases (assuming the expressions to be compared are a and b): 1 : We can prove that for all possible variable values, a > b 0 : We can prove that for all possible variable values, a = b -1 : We can prove that all possible variable values, a < b -2 : We cannot prove any of the above. For the overriding check, we don't care about which expr is larger, we want to know whether they are the same or not. So, in many cases we will just get a warning, although we definitely know that the expr's are different. Example: Differing expr_type, e.g. one procedure has len=3, the other has len=x. It's obvious they are different, but gfc_dep_compare_expr will still return "-2" (because we can not tell which one is larger). In the context of what gfc_dep_compare_expr usually does, these expressions may be equal, because x may be 3. I would tend to leave the check like it is (i.e. rejecting everything !=0), but if you insist, one could extend the output values of gfc_dep_compare_expr, e.g. like this: -3 = we know nothing (neither if they could be equal, nor which one is larger) -2 = we know they are different, but not which one is larger What you mean is that we should be able to prove that there exists an x so that a != b. If you can extend gfc_dep_compare_expr to prove this, great. However, for this, you must also handle a + b + c vs. c + b + a, i.e. (+ (+ a b ) c) vs. (+ (+ c b) a). However, one may then have to modify the diagnostics on these return values in quite a few places(?). I suspect that extending gfc_dep_compare_expr will be much more difficult than changing its calling sequence :-) Regards Thomas
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
>> For the overriding check, we don't care about which expr is larger, we >> want to know whether they are the same or not. So, in many cases we >> will just get a warning, although we definitely know that the expr's >> are different. >> >> Example: Differing expr_type, e.g. one procedure has len=3, the other >> has len=x. It's obvious they are different, but gfc_dep_compare_expr >> will still return "-2" (because we can not tell which one is larger). > > In the context of what gfc_dep_compare_expr usually does, these expressions > may be equal, because x may be 3. I guess that is just one way in which the things it usually does differ a bit from what I'm trying to do with it. Anyway, I think the tasks are reasonably similar to justify reusing gfc_dep_compare_expr instead of writing a new set of procedures, which would have to be of similar complexity. >> I would tend to leave the check like it is (i.e. rejecting everything >> !=0), but if you insist, one could extend the output values of >> gfc_dep_compare_expr, e.g. like this: >> -3 = we know nothing (neither if they could be equal, nor which one is >> larger) >> -2 = we know they are different, but not which one is larger > > What you mean is that we should be able to prove that there > exists an x so that a != b. Yes, if you want to express it in such a way. I'm know that this does not exactly fit in any of your categories. However, I still think that throwing an error for every case where we can not prove that the expressions are equal is a good approximation for the purpose, and everything beyond that is mostly academic. Firstly, string lengths of overridden type-bound procedures will probably never be extremely complicated expressions. Remember: The original bug report here was really just about *constant* string lengths, which is the most trivial and probably most frequent case. Second, it is easy for the programmer to lay out the expressions in analogous ways when overriding, so that gfc_dep_compare_expr is indeed able to prove they are equal. And third, in case there will really be any real-world problems with this, we can just wait for that bug report to roll in, and take care of the problem later (by refining gfc_dep_compare_expr's ability to prove two expressions are equal, e.g. by implementing more math transformations or similar things). Cheers, Janus
[PATCH, alpha]: Fix g++.dg/opt/devirt2.C, use specific scan pattern for alpha*-*-*
Hello!
2011-08-06 Uros Bizjak
PR testsuite/48727
* g++.dg/opt/devirt2.C: Use specific pattern for alpha*-*-*.
Tested on alphaev68-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: g++.dg/opt/devirt2.C
===
--- g++.dg/opt/devirt2.C(revision 177536)
+++ g++.dg/opt/devirt2.C(working copy)
@@ -1,10 +1,13 @@
// { dg-do compile }
// { dg-options "-O2" }
+// { dg-final { scan-assembler-times "xyzzy" 2 { target { ! { alpha*-*-*
hppa*-*-* ia64*-*-hpux* sparc*-*-* } } } } }
// The IA64 and HPPA compilers generate external declarations in addition
// to the call so those scans need to be more specific.
-// { dg-final { scan-assembler-times "xyzzy" 2 { target { ! { hppa*-*-*
ia64*-*-hpux* sparc*-*-* } } } } }
// { dg-final { scan-assembler-times "br\[^\n\]*xyzzy" 2 { target
ia64*-*-hpux* } } }
// { dg-final { scan-assembler-times "xyzzy\[^\n\]*,%r" 2 { target hppa*-*-* }
} }
+// If assembler supports explicit relocation directives, the alpha compiler
generates
+// literal/lituse_jsr pairs, so the scans need to be more specific.
+// { dg-final { scan-assembler-times "jsr\[^\n\]*xyzzy" 2 { target alpha*-*-*
} } }
// Unless the assembler supports -relax, the 32-bit SPARC compiler generates
// sethi/jmp instead of just call, so the scans need to be more specific.
// With subexpressions, Tcl regexp -inline -all returns both the complete
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Am 06.08.2011 23:10, schrieb Janus Weil: I'm know that this does not exactly fit in any of your categories. However, I still think that throwing an error for every case where we can not prove that the expressions are equal is a good approximation for the purpose, and everything beyond that is mostly academic. And this is where I disagree, I think we should not raise an error if we cannot prove that what the user did was wrong. This would be a rejects-valid bug. As for the a+b+c vs. c+b+a issue, I have asked on c.l.f. Regards Thomas
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
2011/8/6 Thomas Koenig :
> Am 06.08.2011 23:10, schrieb Janus Weil:
>>
>> I'm know that this does not exactly fit in any of your categories.
>> However, I still think that throwing an error for every case where we
>> can not prove that the expressions are equal is a good approximation
>> for the purpose, and everything beyond that is mostly academic.
>
> And this is where I disagree, I think we should not raise an error
> if we cannot prove that what the user did was wrong. This would
> be a rejects-valid bug.
Well, ok. After this amount of discussion, how about we start with the
easy things: Here is a preparational patch (basically a subset of the
previous one), which does not do any real changes yet, only some
preparation and cleanup:
* It moves check_typebound_override to interface.c and prefixes it
with gfc_ (I don't like moving and modifying it at the same time).
* It add the commutativity of multiplication in gfc_dep_compare_expr.
* It does some minor cleanup in dependency.c (making two routines
static and removing an unused argument).
Ok for trunk?
Cheers,
Janus
2011-08-06 Janus Weil
PR fortran/49638
* dependency.h (gfc_is_same_range,gfc_are_identical_variables): Remove
two prototypes.
* dependency.c (gfc_are_identical_variables): Made static and renamed.
(gfc_dep_compare_expr): Renamed 'gfc_are_identical_variables', handle
commutativity of multiplication.
(gfc_is_same_range): Made static and renamed, removed argument 'def'.
(check_section_vs_section): Renamed 'gfc_is_same_range'.
* gfortran.h (gfc_check_typebound_override): New prototype.
* interface.c (gfc_check_typebound_override): Moved here from ...
* resolv.c (check_typebound_override): ... here (and renamed).
(resolve_typebound_procedure): Renamed 'check_typebound_override'.
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 177528)
+++ gcc/fortran/interface.c (working copy)
@@ -3466,3 +3466,197 @@ gfc_free_formal_arglist (gfc_formal_arglist *p)
free (p);
}
}
+
+
+/* Check that it is ok for the typebound procedure proc to override the
+ procedure old. */
+
+gfc_try
+gfc_check_typebound_override (gfc_symtree* proc, gfc_symtree* old)
+{
+ locus where;
+ const gfc_symbol* proc_target;
+ const gfc_symbol* old_target;
+ unsigned proc_pass_arg, old_pass_arg, argpos;
+ gfc_formal_arglist* proc_formal;
+ gfc_formal_arglist* old_formal;
+
+ /* This procedure should only be called for non-GENERIC proc. */
+ gcc_assert (!proc->n.tb->is_generic);
+
+ /* If the overwritten procedure is GENERIC, this is an error. */
+ if (old->n.tb->is_generic)
+{
+ gfc_error ("Can't overwrite GENERIC '%s' at %L",
+ old->name, &proc->n.tb->where);
+ return FAILURE;
+}
+
+ where = proc->n.tb->where;
+ proc_target = proc->n.tb->u.specific->n.sym;
+ old_target = old->n.tb->u.specific->n.sym;
+
+ /* Check that overridden binding is not NON_OVERRIDABLE. */
+ if (old->n.tb->non_overridable)
+{
+ gfc_error ("'%s' at %L overrides a procedure binding declared"
+ " NON_OVERRIDABLE", proc->name, &where);
+ return FAILURE;
+}
+
+ /* It's an error to override a non-DEFERRED procedure with a DEFERRED one. */
+ if (!old->n.tb->deferred && proc->n.tb->deferred)
+{
+ gfc_error ("'%s' at %L must not be DEFERRED as it overrides a"
+ " non-DEFERRED binding", proc->name, &where);
+ return FAILURE;
+}
+
+ /* If the overridden binding is PURE, the overriding must be, too. */
+ if (old_target->attr.pure && !proc_target->attr.pure)
+{
+ gfc_error ("'%s' at %L overrides a PURE procedure and must also be PURE",
+ proc->name, &where);
+ return FAILURE;
+}
+
+ /* If the overridden binding is ELEMENTAL, the overriding must be, too. If it
+ is not, the overriding must not be either. */
+ if (old_target->attr.elemental && !proc_target->attr.elemental)
+{
+ gfc_error ("'%s' at %L overrides an ELEMENTAL procedure and must also be"
+ " ELEMENTAL", proc->name, &where);
+ return FAILURE;
+}
+ if (!old_target->attr.elemental && proc_target->attr.elemental)
+{
+ gfc_error ("'%s' at %L overrides a non-ELEMENTAL procedure and must not"
+ " be ELEMENTAL, either", proc->name, &where);
+ return FAILURE;
+}
+
+ /* If the overridden binding is a SUBROUTINE, the overriding must also be a
+ SUBROUTINE. */
+ if (old_target->attr.subroutine && !proc_target->attr.subroutine)
+{
+ gfc_error ("'%s' at %L overrides a SUBROUTINE and must also be a"
+ " SUBROUTINE", proc->name, &where);
+ return FAILURE;
+}
+
+ /* If the overridden binding is a FUNCTION, the overriding must also be a
+ FUNCTION and have the same characteristics. */
+ if (old_target->attr.function)
+{
+ if (!proc_target->attr.function)
+ {
+ gfc_error ("'%s' at %
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
On Sunday 07 August 2011 00:21:46 Janus Weil wrote: > Well, ok. After this amount of discussion, how about we start with the > easy things: Here is a preparational patch (basically a subset of the > previous one), which does not do any real changes yet, only some > preparation and cleanup: > * It moves check_typebound_override to interface.c and prefixes it > with gfc_ (I don't like moving and modifying it at the same time). > * It add the commutativity of multiplication in gfc_dep_compare_expr. > * It does some minor cleanup in dependency.c (making two routines > static and removing an unused argument). > > Ok for trunk? > > Cheers, > Janus > > > 2011-08-06 Janus Weil > > PR fortran/49638 > * dependency.h (gfc_is_same_range,gfc_are_identical_variables): Remove > two prototypes. > * dependency.c (gfc_are_identical_variables): Made static and renamed. I think both the old and the new name should appear. Usually I use (old, new): Rename the former to the latter > (gfc_dep_compare_expr): Renamed 'gfc_are_identical_variables', handle > commutativity of multiplication. > (gfc_is_same_range): Made static and renamed, removed argument 'def'. Same here. > (check_section_vs_section): Renamed 'gfc_is_same_range'. > * gfortran.h (gfc_check_typebound_override): New prototype. > * interface.c (gfc_check_typebound_override): Moved here from ... > * resolv.c (check_typebound_override): ... here (and renamed). > (resolve_typebound_procedure): Renamed 'check_typebound_override'. Index: gcc/fortran/dependency.h === --- gcc/fortran/dependency.h(revision 177528) +++ gcc/fortran/dependency.h(working copy) @@ -37,11 +37,8 @@ gfc_expr *gfc_get_noncopying_intrinsic_argument (g int gfc_check_fncall_dependency (gfc_expr *, sym_intent, gfc_symbol *, gfc_actual_arglist *, gfc_dep_check); int gfc_check_dependency (gfc_expr *, gfc_expr *, bool); -int gfc_is_same_range (gfc_array_ref *, gfc_array_ref *, int, int); +/*int gfc_is_same_range (gfc_array_ref *, gfc_array_ref *, int, bool);*/ int gfc_expr_is_one (gfc_expr *, int); identical_variables (gfc_expr *, gfc_expr *); I would just remove it together with the commented code in trans-array.c. Nobody is likely to use it soon, and it remains available through svn if needed. Otherwise OK. Please give Thomas (or others) some time to comment before commiting. Mikael
Re: [patch testsuite]: Adjust gcc.dg/tree-ssa tests for LLP64 target
On Aug 6, 2011, at 6:04 AM, Kai Tietz wrote: > this adjusts some testcases for LLP64 target x86_64 mingw. Ok. Please watch for any comments on stdarg... I don't have any, but others might.
Re: [PATCH] PR c++/33255 - Support -Wunused-local-typedefs warning
On 08/06/2011 06:57 AM, Dodji Seketeli wrote:
@@ -4340,6 +4340,8 @@ c_sizeof_or_alignof_type (location_t loc,
value = fold_convert_loc (loc, size_type_node, value);
gcc_assert (!TYPE_IS_SIZETYPE (TREE_TYPE (value)));
+ maybe_record_local_typedef_use (type);
Why is this still needed?
+/* Return TRUE if DECL is declared in the current function. */
+
+bool
+local_decl_p (tree decl)
I don't think we need to work so hard to compare contexts to
current_function_decl; just checking that the decl is in some function
should be enough, i.e. decl_function_context is non-null.
+ static int unused_local_typedefs_warn_count;
This could use a comment.
+/* If T is a typedef variant type or a TYPE_DECL declared locally,
+ mark it as used. */
+
+void
+maybe_record_local_typedef_use (tree t)
Does this still need to handle types? And the meaning of TREE_USED
shouldn't change depending on a warning flag or whether a decl is local
or not; let's just mark all TYPE_DECLs as used.
Seems like we don't need local_decl_p at all; at the definition point,
if we're in a function, a new declaration must be local enough for our
purposes.
+void
+cp_maybe_record_local_typedef_use (tree t)
+{
+ /* If the current function is being instantiated, bail out. */
As above, I think we shouldn't put so many conditions on setting TREE_USED.
@@ -19572,6 +19572,9 @@ cp_parser_lookup_name (cp_parser *parser, tree name,
if (DECL_P (decl))
check_accessibility_of_qualified_id (decl, object_type, parser->scope);
+ cp_maybe_record_local_typedef_use (decl);
+ cp_maybe_record_local_typedef_use (parser->scope);
Why do we need to handle parser->scope? Wasn't it previously looked up?
