[ubsan] Don't always use NORETURN
Some libubsan functions aren't really noreturn, so don't mark them as such. This prevents failures with -O1+, since we don't generate any code after calling noreturn routines, thus segfault when we actually get there. Applying to ubsan branch. 2013-07-15 Marek Polacek pola...@redhat.com * builtin-attrs.def (ATTR_COLD_NOTHROW_LEAF_LIST): Define. * sanitizer.def (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW): Don't mark as NORETURN. (BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS): Likewise. * asan.c (ATTR_COLD_NOTHROW_LEAF_LIST): Define. --- gcc/builtin-attrs.def.mp2 2013-07-15 07:52:25.339442743 +0200 +++ gcc/builtin-attrs.def 2013-07-15 08:16:45.725146824 +0200 @@ -131,6 +131,8 @@ DEF_ATTR_TREE_LIST (ATTR_NORETURN_NOTHRO ATTR_NULL, ATTR_NOTHROW_LIST) DEF_ATTR_TREE_LIST (ATTR_NORETURN_NOTHROW_LEAF_LIST, ATTR_NORETURN,\ ATTR_NULL, ATTR_NOTHROW_LEAF_LIST) +DEF_ATTR_TREE_LIST (ATTR_COLD_NOTHROW_LEAF_LIST, ATTR_COLD,\ + ATTR_NULL, ATTR_NOTHROW_LEAF_LIST) DEF_ATTR_TREE_LIST (ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST, ATTR_COLD,\ ATTR_NULL, ATTR_NORETURN_NOTHROW_LEAF_LIST) DEF_ATTR_TREE_LIST (ATTR_CONST_NORETURN_NOTHROW_LEAF_LIST, ATTR_CONST,\ --- gcc/sanitizer.def.mp2 2013-07-15 07:47:46.080293252 +0200 +++ gcc/sanitizer.def 2013-07-15 08:17:03.830219023 +0200 @@ -288,11 +288,11 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_ATOM DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW, __ubsan_handle_divrem_overflow, BT_FN_VOID_PTR_PTR_PTR, - ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST) + ATTR_COLD_NOTHROW_LEAF_LIST) DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS, __ubsan_handle_shift_out_of_bounds, BT_FN_VOID_PTR_PTR_PTR, - ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST) + ATTR_COLD_NOTHROW_LEAF_LIST) DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE, __ubsan_handle_builtin_unreachable, BT_FN_VOID_PTR, --- gcc/asan.c.mp2 2013-07-15 07:46:29.786987718 +0200 +++ gcc/asan.c 2013-07-15 08:21:21.224095627 +0200 @@ -2102,6 +2102,9 @@ initialize_sanitizer_builtins (void) #undef ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST #define ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST \ ECF_TM_PURE | ATTR_NORETURN_NOTHROW_LEAF_LIST +#undef ATTR_COLD_NOTHROW_LEAF_LIST +#define ATTR_COLD_NOTHROW_LEAF_LIST \ + /* ECF_COLD missing */ ATTR_NOTHROW_LEAF_LIST #undef ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST #define ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST \ /* ECF_COLD missing */ ATTR_NORETURN_NOTHROW_LEAF_LIST Marek
Re: [testsuite] fix powerpc alignment tests for eabi
On 07/08/2013 09:47 PM, Janis Johnson wrote: Tests gcc.target/powerpc/20020118-1.c and gcc.c-torture/execute/nest-align-1.c sometimes fail because they expect a stack alignment that is greater than that required for powerpc-eabi. This patch forces stack alignment to 128 bits by passing -mno-eabi. Is this OK for mainline and the 4.8 branch, or would it be better to skip these tests for powerpc-*-eabi*? In case it can be fixed with an additional compiler option, then this is preferable for me since this will help also targets using the EABI, but don't match with the powerpc-*-eabi* pattern, e.g. powerpc-*-rtems*. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
[PATCH] [AArch64] -mcmodel=tiny -fPIC GOT support.
Hi,
Adding support for tiny model GOT access. Regressed, committed.
/Marcus
2013-07-15 Marcus Shawcroft marcus.shawcr...@arm.com
* config/aarch64/aarch64-protos.h (aarch64_symbol_type):
Define SYMBOL_TINY_GOT, update comment.
* config/aarch64/aarch64.c
(aarch64_load_symref_appropriately): Handle SYMBOL_TINY_GOT.
(aarch64_expand_mov_immediate): Likewise.
(aarch64_print_operand): Likewise.
(aarch64_classify_symbol): Likewise.
* config/aarch64/aarch64.md (UNSPEC_GOTTINYPIC): Define.
(ldr_got_tiny): Define.diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index e749cc1..f19045d 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -75,6 +75,17 @@ enum aarch64_symbol_context
ADR x0, foo
+ SYMBOL_TINY_GOT
+
+ Generate symbol accesses via the GOT using a single PC relative
+ instruction. To compute the address of symbol foo, we generate:
+
+ ldr t0, :got:foo
+
+ The value of foo can subsequently read using:
+
+ ldrbt0, [t0]
+
SYMBOL_FORCE_TO_MEM : Global variables are addressed using
constant pool. All variable addresses are spilled into constant
pools. The constant pools themselves are addressed using PC
@@ -89,6 +100,7 @@ enum aarch64_symbol_type
SYMBOL_SMALL_GOTTPREL,
SYMBOL_SMALL_TPREL,
SYMBOL_TINY_ABSOLUTE,
+ SYMBOL_TINY_GOT,
SYMBOL_FORCE_TO_MEM
};
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 03e5f19..ec9906f 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -641,6 +641,10 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
return;
}
+case SYMBOL_TINY_GOT:
+ emit_insn (gen_ldr_got_tiny (dest, imm));
+ return;
+
default:
gcc_unreachable ();
}
@@ -920,6 +924,7 @@ aarch64_expand_mov_immediate (rtx dest, rtx imm)
case SYMBOL_SMALL_TLSDESC:
case SYMBOL_SMALL_GOTTPREL:
case SYMBOL_SMALL_GOT:
+ case SYMBOL_TINY_GOT:
if (offset != const0_rtx)
{
gcc_assert(can_create_pseudo_p ());
@@ -3694,6 +3699,10 @@ aarch64_print_operand (FILE *f, rtx x, char code)
asm_fprintf (asm_out_file, :tprel:);
break;
+ case SYMBOL_TINY_GOT:
+ gcc_unreachable ();
+ break;
+
default:
break;
}
@@ -3723,6 +3732,10 @@ aarch64_print_operand (FILE *f, rtx x, char code)
asm_fprintf (asm_out_file, :tprel_lo12_nc:);
break;
+ case SYMBOL_TINY_GOT:
+ asm_fprintf (asm_out_file, :got:);
+ break;
+
default:
break;
}
@@ -5295,7 +5308,7 @@ aarch64_classify_symbol (rtx x,
case AARCH64_CMODEL_TINY_PIC:
if (!aarch64_symbol_binds_local_p (x))
- return SYMBOL_SMALL_GOT;
+ return SYMBOL_TINY_GOT;
return SYMBOL_TINY_ABSOLUTE;
case AARCH64_CMODEL_SMALL_PIC:
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 54f4af1..233014e 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -80,6 +80,7 @@
UNSPEC_FRINTZ
UNSPEC_GOTSMALLPIC
UNSPEC_GOTSMALLTLS
+UNSPEC_GOTTINYPIC
UNSPEC_LD2
UNSPEC_LD3
UNSPEC_LD4
@@ -3783,6 +3784,16 @@
(set_attr mode DI)]
)
+(define_insn ldr_got_tiny
+ [(set (match_operand:DI 0 register_operand =r)
+ (unspec:DI [(match_operand:DI 1 aarch64_valid_symref S)]
+ UNSPEC_GOTTINYPIC))]
+
+ ldr\\t%0, %L1
+ [(set_attr v8type load1)
+ (set_attr mode DI)]
+)
+
(define_insn aarch64_load_tp_hard
[(set (match_operand:DI 0 register_operand =r)
(unspec:DI [(const_int 0)] UNSPEC_TLS))]
Re: C++ PATCH to can_convert to support user-defined conversions
On Sat, Jul 13, 2013 at 6:02 PM, Jason Merrill ja...@redhat.com wrote: As came up in the review of the concepts lite code, can_convert currently doesn't allow user-defined conversions. This is surprising, so we've renamed it to can_convert_standard and made the can_convert name allow them. Users that could potentially call can_convert with arguments of class type have also been renamed; those that can only pass in pointers or the like have been left alone. I also took the opportunity to tidy up a covariant return diagnostic. Tested x86_64-pc-linux-gnu, applying to trunk. Thanks, Jason. -- Gaby
ping: Re: [patch] fix cross building a native compiler
ping Am 12.06.2013 09:48, schrieb Matthias Klose: Trying to cross build a native compiler for arm-linux on x86_64 linux currently fails to build, if the libgmp development files are not available for the build system. This works with 4.7, but fails with 4.8. The build fails with: TARGET_CPU_DEFAULT= \ HEADERS=auto-build.h ansidecl.h DEFINES= \ /bin/bash ../../src/gcc/mkconfig.sh bconfig.h g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc -I../../src/gcc/build -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -DCLOOG_INT_GMP\ -o build/genconstants.o ../../src/gcc/genconstants.c In file included from /usr/include/x86_64-linux-gnu/sys/resource.h:25:0, from ../../src/gcc/system.h:395, from ../../src/gcc/genconstants.c:28: /usr/include/x86_64-linux-gnu/bits/resource.h:131:18: error: declaration does not declare anything [-fpermissive] In file included from ../../src/gcc/genconstants.c:28:0: ../../src/gcc/system.h:444:23: error: declaration of C function 'void* sbrk(int)' conflicts with Searching the archive and ML this is supposed to work according to PR 35051, as described in http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00041.html When building the auto-build.h, all the configure tests including the system.h header fail to build with configure:10361: gcc -c -I../../../src/gcc -I../../../src/gcc/../include conftest.c 5 In file included from ../../../src/gcc/system.h:641:0, from conftest.c:116: /usr/include/gmp.h:69:24: fatal error: gmp-x86_64.h: No such file or directory compilation terminated. And at least all the HAVE_DECL_* defines are set to 0 instead of 1. [side note: can we keep the temporary directory for this? it's a bit strange that this directory is removed during the build, and can't be looked at. The build continues after the configure, and then fails later] I checked that defining GENERATOR_FILE for this configure step to build the auto-build.h lets me to cross build the native compiler, and the resulting build seems to work on the target platform. However I can't find any other documentation for GENERATOR_FILE, so I'm unsure if that's the right thing to do. Richard did introduce the conditional include of gmp.h based on GENERATOR_FILE back in 2008, and Steven did define this for some object files built for the host, but not the build in 2012: 2012-07-08 Steven Bosscher ste...@gcc.gnu.org * Makefile.in (gengtype-lex.o, gengtype-parse.o, gengtype-state.o, gengtype.o): Add -DGENERATOR_FILE manually for host gengtype objects. Is just setting _DGENERATOR_FILE for the auto-build.h build the right thing to do? If yes, ok for the 4.8 branch and the trunk? I didn't yet figure out why this works with 4.7. Matthias
[ping 2] Re: [ping] Re: [PATCH] Remove unnecessaily included limits.h in libgcc2.c
ping 2 Am 15.05.2013 13:46, schrieb Matthias Klose: ping? regenerated the patch for the trunk, check with builds on arm-linux-gnueabihf and x86_64-linux-gnu Matthias * libgcc2.c: Don't include limits.h. Am 14.01.2013 22:54, schrieb Matthias Klose: Am 04.01.2013 20:01, schrieb Wookey: I filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55743 (my first upstream gcc bug so be gentle :-) Details are there but the short version is that the limits.h inclusion in libgcc2.c is now a relic because the constants that it brings in are no longer used (since http://repo.or.cz/w/official-gcc.git/blobdiff/49f0f270673c4512c11f72a038b84c321ae5534a..7429c938827aa98bf3b02c4ac89510f4d28ef0b1:/gcc/libgcc2.c ) And this inclusion can break --without-headers bootstrapping (which is how I noticed it). Doko poked me to send the patch to this list for consideration for inclusion in trunk. The --without-headers build failures is unrelated. To catch this mis-configuration I did propose a patch in http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00743.html I think the patch itself is correct. However - please submit your patch against trunk, and state that you did test the patch against trunk (of course, after testing it) - please provide a ChangeLog entry - thanks for your reference to the repo.or.cz repo, however it would be good to reference a GCC commit. looks like Alexandre Oliva did commit this without removing the unneeded bits in r39365. Matthias
Re: Call GNU ld with -O*
Hi, On Fri, 12 Jul 2013, Ian Lance Taylor wrote: It was probably a mistake to have a linker -O option at all. Doesn't the linker produce something that is faster to link and/or smaller, with this flag? For gold I think it has two effects. If you use compressed debug sections, it will compress them with zlib level 9 rather than 1. If you use -O2 or greater it will optimize string tables (e.g., the table holding the names of symbols) such that if the table stores two strings S1 and S2, and S2 is a suffix of S1, it will store only S1, and change pointers to S2 to point to the suffix of S1. So you are correct that the result will be smaller, but not faster to link. For bfd ld it has only one effect (except for alpha), namely to try to use shorter chains for the ELF hash buckets (string table optimization will be done unconditionally). The resulting objects are a slight bit faster to link (I don't think I could ever actually measure any improvement, though), and since the introduction of .gnu.hash the whole dance is useless. So, I'd also argue against calling the linker with -O or -O2 except if any interesting speedup can be demonstrated. Ciao, Michael.
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Thu, 2013-07-04 at 12:02 -0400, David Edelsohn wrote:
The expanders in htm.md should not include constraint letters.
That's the way I had the code originally, since they're not
needed for expand, but I added them later to improve the
error message when someone uses a builtin that takes an
integer constant argument and uses a value out of range.
Specifically, it is used by this part of the patch:
+ if (!(*insn_op-predicate) (op[nopnds], insn_op-mode))
+ {
+ if (!strcmp (insn_op-constraint, n))
+ {
+ int arg_num = (nonvoid) ? nopnds : nopnds + 1;
+ if (!CONST_INT_P (op[nopnds]))
+ error (argument %d must be an unsigned literal, arg_num);
+ else
+ error (argument %d is an unsigned literal that is
+ out of range, arg_num);
+ return const0_rtx;
+ }
+ op[nopnds] = copy_to_mode_reg (insn_op-mode, op[nopnds]);
+ }
If you want, I can remove the constraints and the extra error
message. Just let me know what you want.
Peter
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 07/14/13 21:37, David Holsgrove wrote: Hi Michael, -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Saturday, 13 July 2013 9:33 am To: David Holsgrove Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail; Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui Subject: Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove david.holsgr...@xilinx.com * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK Sorry it has taken so long to review this patch. The gcc microblaze-xilinx-elf build with this patch fails here: +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, + tree function) ... + emit_insn (gen_jump (funexp)); (actually, in output_operand() downstream from this statement) while compiling c++98/strstream.cc, with an error that the %l operand was not a label. This is the first occasion when this routine is called. I had sent a separate patch which should have been applied prior to this one which extended the jump insn to accommodate branching without the %l print operand, but I've since reworked our thunk support to avoid needing this second patch. When that patch was not accepted, I moved on to the next submission. Please make sure that patches identify that they are dependent on previous patches. Thanks for reworking the patch to be independent. I'll post updated patches on the other threads out for review now. Thanks. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Mon, Jul 15, 2013 at 11:23 AM, Peter Bergner berg...@vnet.ibm.com wrote:
On Thu, 2013-07-04 at 12:02 -0400, David Edelsohn wrote:
The expanders in htm.md should not include constraint letters.
That's the way I had the code originally, since they're not
needed for expand, but I added them later to improve the
error message when someone uses a builtin that takes an
integer constant argument and uses a value out of range.
Specifically, it is used by this part of the patch:
+ if (!(*insn_op-predicate) (op[nopnds], insn_op-mode))
+ {
+ if (!strcmp (insn_op-constraint, n))
+ {
+ int arg_num = (nonvoid) ? nopnds : nopnds + 1;
+ if (!CONST_INT_P (op[nopnds]))
+ error (argument %d must be an unsigned literal,
arg_num);
+ else
+ error (argument %d is an unsigned literal that is
+ out of range, arg_num);
+ return const0_rtx;
+ }
+ op[nopnds] = copy_to_mode_reg (insn_op-mode, op[nopnds]);
+ }
If you want, I can remove the constraints and the extra error
message. Just let me know what you want.
Thanks for the explanation. Leave it in.
Jakub was asking about the status of the HTM patch and support, so
please check it in.
Thanks, David
[Google 4.8] Fix up size of pubnames in the presence of pruned enumerators
Hi Cary, Google 4.8 calculates the size of pubnames incorrectly in the presence of pruned enumerators. The logic in size_of_pubnames should match that in output_pubnames. The enclosed patch fixes that. OK for google 4.8? Sterling gcc/ChangeLog 2013-07-12 Sterling Augustine saugust...@google.com * dwarf2out.c (include_pubname_in_output): Consider die tags and parents. pubnames.patch Description: Binary data
[c++-concepts] Merge from trunk
Trunk was merged to the c++-concept branch at revision 200958. Andrew -- There aere a few conflicts surronding introduction of can_convert_standard, between your version and the one Jason committed. I resolved them in favour of Jason's because his version followed the GNU coding convention (when a binary expression spans several lines, the binary operator starts the new line, etc.) The split of cp/semantics.c into cp/lambda.c and the rest introduced a conflict at the Makefile level. Resolved. -- Gaby
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Mon, 2013-07-15 at 11:55 -0400, David Edelsohn wrote: Thanks for the explanation. Leave it in. Jakub was asking about the status of the HTM patch and support, so please check it in. Ok, committed to mainline (after another bootstrap) as revision 200960. Thanks! Peter
Re: Group static constructors and destructors in specific subsections
I am not sure how to update gold - I basically copied existing code in binutils for .text.unlikely group in GNU LD linker script, but I think gold is doing independent decisions somewhere. Ian committed this patch a few months ago, after a lengthy discussion around a patch originally submitted by Sriraman: http://sourceware.org/ml/binutils/2012-12/msg00227.html That should have gold handling .text.startup, .text.exit, and .text.hot the same as Gnu ld. -cary
Re: [Google 4.8] Fix up size of pubnames in the presence of pruned enumerators
On Mon, Jul 15, 2013 at 9:32 AM, Sterling Augustine saugust...@google.com wrote: Hi Cary, Google 4.8 calculates the size of pubnames incorrectly in the presence of pruned enumerators. The logic in size_of_pubnames should match that in output_pubnames. After some discussion off line, I have reworked this patch as below. This version is cleaner and ensures the logic is just in one place. OK for Google 4.7 and 4.8? Sterling 2013-07-15 Sterling Augustine saugust...@google.com * dwarf2out.c (output_pubnames): Rework assertion. Move logic checking DW_TAG_enumerator and die_parent ... (include_pubname_in_output): ...to here. pubnames.patch Description: Binary data
[ubsan] Add testsuite
Ubsan testsuite is something we've been missing for some time now, so
this patch adds it. Fortunately the dejagnu part was
quite simple, since ubsan doesn't need similar tweaks as asan does.
But I had to tweak gcc.c to include -lubsan.
The tests are testing pretty basic stuff, however, in LLVM testsuite they
don't check much more. Maybe we should test also stuff like ++a (v * x)
etc.?
Tested with
make check RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
Any comments before I put this on ubsan branch?
2013-07-15 Marek Polacek pola...@redhat.com
* gcc.c (ADD_STATIC_LIBUBSAN_LIBS): Define.
(LIBUBSAN_SPEC): Likewise.
(LIBUBSAN_EARLY_SPEC): Likewise.
(SANITIZER_SPEC): Handle libubsan.
(SANITIZER_EARLY_SPEC): Likewise.
testsuite/
* lib/ubsan-dg.exp: New file.
* g++.dg/ubsan/ubsan.exp: New file.
* gcc.dg/ubsan/ubsan.exp: New file.
* g++.dg/ubsan/cxx11-shift-1.C: New test.
* g++.dg/ubsan/cxx11-shift-2.C: New test.
* c-c++-common/ubsan/div-by-zero-3.c: New test.
* c-c++-common/ubsan/div-by-zero-1.c: New test.
* c-c++-common/ubsan/div-by-zero-4.c: New test.
* c-c++-common/ubsan/shift-3.c: New test.
* c-c++-common/ubsan/unreachable-1.c: New test.
* c-c++-common/ubsan/shift-1.c: New test.
* c-c++-common/ubsan/shift-2.c: New test.
* c-c++-common/ubsan/div-by-zero-2.c: New test.
* gcc.dg/ubsan/c99-shift-2.c: New test.
* gcc.dg/ubsan/c99-shift-1.c: New test.
--- gcc/gcc.c.mp2013-07-15 04:30:13.038677937 +0200
+++ gcc/gcc.c 2013-07-15 04:42:32.257592503 +0200
@@ -591,6 +591,28 @@ proper position among the other output f
#define LIBTSAN_EARLY_SPEC
#endif
+#ifndef LIBUBSAN_SPEC
+#ifdef STATIC_LIBUBSAN_LIBS
+#define ADD_STATIC_LIBUBSAN_LIBS \
+ %{static-libubsan: STATIC_LIBUBSAN_LIBS }
+#else
+#define ADD_STATIC_LIBUBSAN_LIBS
+#endif
+#ifdef LIBUBSAN_EARLY_SPEC
+#define LIBUBSAN_SPEC ADD_STATIC_LIBUBSAN_LIBS
+#elif defined(HAVE_LD_STATIC_DYNAMIC)
+#define LIBUBSAN_SPEC %{static-libubsan: LD_STATIC_OPTION \
+} -lubsan %{static-libubsan: LD_DYNAMIC_OPTION } \
+ADD_STATIC_LIBUBSAN_LIBS
+#else
+#define LIBUBSAN_SPEC -lubsan ADD_STATIC_LIBUBSAN_LIBS
+#endif
+#endif
+
+#ifndef LIBUBSAN_EARLY_SPEC
+#define LIBUBSAN_EARLY_SPEC
+#endif
+
/* config.h can define LIBGCC_SPEC to override how and when libgcc.a is
included. */
#ifndef LIBGCC_SPEC
@@ -714,7 +736,8 @@ proper position among the other output f
#ifndef SANITIZER_EARLY_SPEC
#define SANITIZER_EARLY_SPEC \
%{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address): LIBASAN_EARLY_SPEC } \
-%{%:sanitize(thread): LIBTSAN_EARLY_SPEC }}}
+%{%:sanitize(thread): LIBTSAN_EARLY_SPEC } \
+%{%:sanitize(undefined): LIBUBSAN_EARLY_SPEC }}}
#endif
/* Linker command line options for -fsanitize= late on the command line. */
@@ -724,7 +747,8 @@ proper position among the other output f
%{static:%ecannot specify -static with -fsanitize=address}\
%{%:sanitize(thread):%e-fsanitize=address is incompatible with
-fsanitize=thread}}\
%{%:sanitize(thread): LIBTSAN_SPEC \
-%{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or
-shared}
+%{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or
-shared}}}\
+%{%:sanitize(undefined): LIBUBSAN_SPEC }}}
#endif
/* -u* was put back because both BSD and SysV seem to support it. */
--- gcc/testsuite/lib/ubsan-dg.exp.mp 2013-07-14 20:19:05.445091076 +0200
+++ gcc/testsuite/lib/ubsan-dg.exp 2013-07-15 04:25:00.476445749 +0200
@@ -0,0 +1,104 @@
+# Copyright (C) 2013 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# http://www.gnu.org/licenses/.
+
+#
+# ubsan_link_flags -- compute library path and flags to find libubsan.
+# (originally from g++.exp)
+#
+
+proc ubsan_link_flags { paths } {
+global srcdir
+global ld_library_path
+global shlib_ext
+
+set gccpath ${paths}
+set flags
+
+set shlib_ext [get_shlib_extension]
+
+if { $gccpath != } {
+ if { [file exists ${gccpath}/libsanitizer/ubsan/.libs/libubsan.a]
+ || [file exists
${gccpath}/libsanitizer/ubsan/.libs/libubsan.${shlib_ext}] } {
+ append flags -B${gccpath}/libsanitizer/ubsan/
+ append flags
Re: [ping 2] Re: [ping] Re: [PATCH] Remove unnecessaily included limits.h in libgcc2.c
This patch is OK. Sorry for not looking at it earlier. Thanks. Ian On Mon, Jul 15, 2013 at 5:40 AM, Matthias Klose d...@ubuntu.com wrote: ping 2 Am 15.05.2013 13:46, schrieb Matthias Klose: ping? regenerated the patch for the trunk, check with builds on arm-linux-gnueabihf and x86_64-linux-gnu Matthias * libgcc2.c: Don't include limits.h. Am 14.01.2013 22:54, schrieb Matthias Klose: Am 04.01.2013 20:01, schrieb Wookey: I filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55743 (my first upstream gcc bug so be gentle :-) Details are there but the short version is that the limits.h inclusion in libgcc2.c is now a relic because the constants that it brings in are no longer used (since http://repo.or.cz/w/official-gcc.git/blobdiff/49f0f270673c4512c11f72a038b84c321ae5534a..7429c938827aa98bf3b02c4ac89510f4d28ef0b1:/gcc/libgcc2.c ) And this inclusion can break --without-headers bootstrapping (which is how I noticed it). Doko poked me to send the patch to this list for consideration for inclusion in trunk. The --without-headers build failures is unrelated. To catch this mis-configuration I did propose a patch in http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00743.html I think the patch itself is correct. However - please submit your patch against trunk, and state that you did test the patch against trunk (of course, after testing it) - please provide a ChangeLog entry - thanks for your reference to the repo.or.cz repo, however it would be good to reference a GCC commit. looks like Alexandre Oliva did commit this without removing the unneeded bits in r39365. Matthias
Re: [Google 4.8] Fix up size of pubnames in the presence of pruned enumerators
After some discussion off line, I have reworked this patch as below. This version is cleaner and ensures the logic is just in one place. OK for Google 4.7 and 4.8? Sterling 2013-07-15 Sterling Augustine saugust...@google.com * dwarf2out.c (output_pubnames): Rework assertion. Move logic checking DW_TAG_enumerator and die_parent ... (include_pubname_in_output): ...to here. OK for google branches. Thanks! -cary
Re: Fix GCC bug causing bootstrap failure with vectorizer turned on
Cong Hou co...@google.com wrote:
Hi Richard
Thank you for you reply. The code generation is affected when
generating
conditions for alias checks using the function
static void vect_create_cond_for_alias_checks (loop_vec_info
loop_vinfo,
tree * cond_expr)
from the file
*tree-vect-loop-manip.c*
where a loop inside iterates a set of DRs and builds conditions for
each
one. However, those DRs are already sorted by the function
Hm, ok.
bool vect_analyze_data_ref_accesses (loop_vec_info loop_vinfo,
bb_vec_info
bb_vinfo)
from the file
*tree-vect-data-refs.c*
and as I mentioned the comparison function used in the sort has some
problems and our patch is trying to fix it.
Yes, I know - I introduced the lame compare using the hashes...
If you have any other problem please let me know.
Not at this time. The patch is ok as-is.
Thanks,
Richard.
Thank you!
*
*
*
*
Cong
On Sat, Jul 13, 2013 at 2:06 AM, Richard Biener
richard.guent...@gmail.comwrote:
Cong Hou co...@google.com wrote:
GCC bootstrap failed with loop vectorizer turned on by default at
O2.
The symptom is that the comparison between stage23 compilers fails.
The root cause is a bug in the file tree-vect-data-refs.c, where a
qsort() function call is used to sort a group of data references
using
a comparison function called dr_group_sort_cmp(). In this
function,
the iterative hash values of tree nodes are used for comparisons.
For
a declaration tree node, its UID participates in the calculation of
the hash value. However, a specific declaration may have different
UIDs whether the debug information is switched on/off (-gtoggle). In
consequence, the results of comparisons may vary in stage 23 during
bootstrapping.
The following patch fixed the bug. Compiler bootstraps and there is
no
regressions in regression test. Compiler also bootstraps fine when
turning on vectorizer by default. Since this patch may produce
difference result (but still correct) than before due to the
modification to the comparison function, four test cases are
adjusted
accordingly. OK for trunk?
Where does the order of DRs affect code generation? I think there is
the
correct place to fix this bug.
Richard.
Cong
Index: gcc/testsuite/gcc.target/i386/l_fma_double_1.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_double_1.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_double_1.c (working copy)
@@ -10,9 +10,9 @@
#include l_fma_1.h
/* { dg-final { scan-assembler-times vfmadd132pd 4 } } */
-/* { dg-final { scan-assembler-times vfmadd213pd 4 } } */
+/* { dg-final { scan-assembler-times vfmadd231pd 4 } } */
/* { dg-final { scan-assembler-times vfmsub132pd 4 } } */
-/* { dg-final { scan-assembler-times vfmsub213pd 4 } } */
+/* { dg-final { scan-assembler-times vfmsub231pd 4 } } */
/* { dg-final { scan-assembler-times vfnmadd132pd 4 } } */
/* { dg-final { scan-assembler-times vfnmadd231pd 4 } } */
/* { dg-final { scan-assembler-times vfnmsub132pd 4 } } */
Index: gcc/testsuite/gcc.target/i386/l_fma_float_1.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_float_1.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_float_1.c (working copy)
@@ -9,9 +9,9 @@
#include l_fma_1.h
/* { dg-final { scan-assembler-times vfmadd132ps 4 } } */
-/* { dg-final { scan-assembler-times vfmadd213ps 4 } } */
+/* { dg-final { scan-assembler-times vfmadd231ps 4 } } */
/* { dg-final { scan-assembler-times vfmsub132ps 4 } } */
-/* { dg-final { scan-assembler-times vfmsub213ps 4 } } */
+/* { dg-final { scan-assembler-times vfmsub231ps 4 } } */
/* { dg-final { scan-assembler-times vfnmadd132ps 4 } } */
/* { dg-final { scan-assembler-times vfnmadd231ps 4 } } */
/* { dg-final { scan-assembler-times vfnmsub132ps 4 } } */
Index: gcc/testsuite/gcc.target/i386/l_fma_double_3.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_double_3.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_double_3.c (working copy)
@@ -10,9 +10,9 @@
#include l_fma_3.h
/* { dg-final { scan-assembler-times vfmadd132pd 4 } } */
-/* { dg-final { scan-assembler-times vfmadd213pd 4 } } */
+/* { dg-final { scan-assembler-times vfmadd231pd 4 } } */
/* { dg-final { scan-assembler-times vfmsub132pd 4 } } */
-/* { dg-final { scan-assembler-times vfmsub213pd 4 } } */
+/* { dg-final { scan-assembler-times vfmsub231pd 4 } } */
/* { dg-final { scan-assembler-times vfnmadd132pd 4 } } */
/* { dg-final { scan-assembler-times vfnmadd231pd 4 } } */
/* { dg-final { scan-assembler-times vfnmsub132pd 4 } } */
Index: gcc/testsuite/gcc.target/i386/l_fma_float_3.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_float_3.c (revision 200893)
+++
Re: Group static constructors and destructors in specific subsections
I am not sure how to update gold - I basically copied existing code in binutils for .text.unlikely group in GNU LD linker script, but I think gold is doing independent decisions somewhere. Ian committed this patch a few months ago, after a lengthy discussion around a patch originally submitted by Sriraman: http://sourceware.org/ml/binutils/2012-12/msg00227.html That should have gold handling .text.startup, .text.exit, and .text.hot the same as Gnu ld. Thanks a lot! It seems that this versio nof gold did not hit our distro yet. I will update my local installation. The next thing is how to tell GNU LD/Gold the relative order of functions. I.e. my_function_section.order.125 or something like that? Honza -cary
Re: Group static constructors and destructors in specific subsections
On Mon, Jul 15, 2013 at 11:05 AM, Jan Hubicka hubi...@ucw.cz wrote: The next thing is how to tell GNU LD/Gold the relative order of functions. I.e. my_function_section.order.125 or something like that? Gold has a --section-ordering-file option that lets you specify the order in which sections should appear in the executable. Sections not listed there follow the default rules. Ian
Re: Group static constructors and destructors in specific subsections
On Mon, Jul 15, 2013 at 11:05 AM, Jan Hubicka hubi...@ucw.cz wrote: The next thing is how to tell GNU LD/Gold the relative order of functions. I.e. my_function_section.order.125 or something like that? Gold has a --section-ordering-file option that lets you specify the order in which sections should appear in the executable. Sections not listed there follow the default rules. Yep, the problem is where to produce the section ordering file. The scheme is as follows: - with -fprofile-generate instrument every function entry point and record time of first and last invocation of the functoin - At compile time we take functions that are executed during the startup and we want to order them in the increasing order of the first invocation time measured at FDO time. So we know the relative position of given function in the program, but not the complette function order. Honza Ian
