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
* 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 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 > > * 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 . > > 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 * 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 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 * 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 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 * 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
* 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
+#
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 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 . >> >> 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 > > * 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 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
>wrote:
>
>> Cong Hou wrote:
>>
>> >GCC bootstrap failed with loop vectorizer turned on by default at
>O2.
>> >The symptom is that the comparison between stage2&3 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 2&3 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 } } */
>> > /* {
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 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 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
[PATCH] PR57878, Incorrect code: live register clobbered in split2
Hi, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57878 The bug occurs because tfreq is given higher priority than bigger mode in reload_pseudo_compare_func. When there are multiple reload pseudos in the same insn， and the pseudo with bigger mode has lower thread frequency than other reload pseudos, it is possible the bigger mode pseudo cannot find available hardregs. The proposed fix is to switch the priority of bigger mode and tfreq in reload_pseudo_compare_func. Besides I promoted lra_assert to gcc_assert at the end of to make adding testcase easier since lra_assert will not fire on 4.8.1. bootstrap and regression test are ok on x86_64-linux-gnu. Is it ok for trunk and 4.8 branch? Thanks, Wei. 2013-07-15 Wei Mi PR rtl-optimization/57878 * lra-assigns.c (reload_pseudo_compare_func): Switch the priority of bigger mode and tfreq. 2013-07-15 Wei Mi PR rtl-optimization/57878 * g++.dg/pr57518.C: New test. patch Description: Binary data patch_test Description: Binary data
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Mon, Jul 15, 2013 at 12:25:58PM -0500, Peter Bergner wrote: > 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! Looking at the patch, you've changed FIRST_PSEUDO_REGISTER (internal gcc thing, so fine), but that also changed DWARF_FRAME_REGISTER which was computed based on FIRST_PSEUDO_REGISTER. Isn't that an ABI break in the unwinder (think about having parts of unwinder linked from different versions of libgcc)? Can't we just tweak DWARF_FRAME_REGISTER not to include those registers? Jakub
Re: [Patch testsuite/objc/objc++] some objc/objcxx testsuite TLC re. PRs 55654,55656,55657
On Jul 14, 2013, at 4:58 AM, Iain Sandoe wrote: > The NeXT Objective C runtime and its interfaces have been evolving - and, in > particular, interfaces deprecated at Darwin9 have now been removed from > recent Darwin/OSX implementations. > OK for trunk? Ok. > OK for open branches? (this was reported against 4.8) Ok. It'd be nice if someone would test non-NeXT Objective-C…
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Mon, Jul 15, 2013 at 08:44:12PM +0200, Jakub Jelinek wrote:
> On Mon, Jul 15, 2013 at 12:25:58PM -0500, Peter Bergner wrote:
> > 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!
>
> Looking at the patch, you've changed FIRST_PSEUDO_REGISTER (internal gcc
> thing, so fine), but that also changed DWARF_FRAME_REGISTER which was
> computed based on FIRST_PSEUDO_REGISTER. Isn't that an ABI break in the
> unwinder (think about having parts of unwinder linked from different
> versions of libgcc)?
> Can't we just tweak DWARF_FRAME_REGISTER not to include those registers?
I'd say something like (but, untested and can't test it right now (and no
access to power8 anyway)):
2013-07-15 Jakub Jelinek
* config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTERS): Mention HTM
registers in the comment.
(DWARF_FRAME_REGISTERS): Subtract also the 3 HTM registers.
--- gcc/config/rs6000/rs6000.h.jj 2013-07-15 21:08:02.0 +0200
+++ gcc/config/rs6000/rs6000.h 2013-07-15 21:11:06.846718216 +0200
@@ -892,15 +892,17 @@ enum data_align { align_abi, align_opt,
in inline functions.
Another pseudo (not included in DWARF_FRAME_REGISTERS) is soft frame
- pointer, which is eventually eliminated in favor of SP or FP. */
+ pointer, which is eventually eliminated in favor of SP or FP.
+ The 3 HTM registers aren't also included in DWARF_FRAME_REGISTERS. */
+
#define FIRST_PSEUDO_REGISTER 117
/* This must be included for pre gcc 3.0 glibc compatibility. */
#define PRE_GCC3_DWARF_FRAME_REGISTERS 77
/* Add 32 dwarf columns for synthetic SPE registers. */
-#define DWARF_FRAME_REGISTERS ((FIRST_PSEUDO_REGISTER - 1) + 32)
+#define DWARF_FRAME_REGISTERS ((FIRST_PSEUDO_REGISTER - 4) + 32)
/* The SPE has an additional 32 synthetic registers, with DWARF debug
info numbering for these registers starting at 1200. While eh_frame
Jakub
Re: [PATCH] S/390: Hardware transactional memory support
On Fri, Jun 21, 2013 at 12:23:14PM +0200, Andreas Krebbel wrote: > the attached patch implements support for hardware transactional > memory in the S/390 backend. > > The transactional execution facility has been made available with IBM > Enterprise EC12. Documentation can be found in the Principles of > Operation manual: > http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf > > The patch implements a set of GCC style builtins as well as the > builtins provided with the IBM XL compiler for compatibility reasons. > > The GCC builtins are used to implement HTM support in libitm. All > libitm testcases succeed with this patch applied (and some libitm > bugfixes from Torvald Riegel). > > The builtins are enabled by default when compiling with -march=zEC12. > They can be disabled with the -mno-htm switch. > > Bootstrapped and regtested on s390 and s390x (configured with > --with-arch=zEC12). > > Any comments? Have you considered trying it to work even when libitm itself isn't built for zEC12 or later only? I mean, both the i?86/x86_64 and powerpc* libitm HTM don't define htm_available as unconditional true, they check in some way whether the CPU supports HTM and return true if yes, and as needed some parts or whole of libitm is compiled with some compiler option that allows the HTM instructions to be generated. I see your patch will currently error out if you have HTM builtins insode of code, -mtx and don't enable -march=zEC12, could that be changed, so that -mtx is essentially independent on the chosen CPU? Jakub
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Mon, 2013-07-15 at 21:13 +0200, Jakub Jelinek wrote: > > Looking at the patch, you've changed FIRST_PSEUDO_REGISTER (internal gcc > > thing, so fine), but that also changed DWARF_FRAME_REGISTER which was > > computed based on FIRST_PSEUDO_REGISTER. Isn't that an ABI break in the > > unwinder (think about having parts of unwinder linked from different > > versions of libgcc)? > > Can't we just tweak DWARF_FRAME_REGISTER not to include those registers? Thanks for noticing this. > I'd say something like (but, untested and can't test it right now (and no > access to power8 anyway)): Do we also need to update DWARF_REG_TO_UNWIND_COLUMN similarly, which also uses FIRST_PSEUDO_REGISTER when the dwarf reg is an SPE synthetic register? Or should we just break the dependence on FIRST_PSEUDO_REGISTER altogether so this type of thing doesn't happen again? Otherwise, we should place a comment at the definition of FIRST_PSEUDO_REGISTER warning of it's use in DWARF_FRAME_REGISTER. Peter
Re: [PATCH] S/390: Hardware transactional memory support
On Mon, 2013-07-15 at 21:32 +0200, Jakub Jelinek wrote: > Have you considered trying it to work even when libitm itself isn't built > for zEC12 or later only? I mean, both the i?86/x86_64 and powerpc* libitm > HTM don't define htm_available as unconditional true, they check in some way > whether the CPU supports HTM and return true if yes, and as needed some > parts or whole of libitm is compiled with some compiler option that > allows the HTM instructions to be generated. > > I see your patch will currently error out if you have HTM builtins > insode of code, -mtx and don't enable -march=zEC12, could that be changed, > so that -mtx is essentially independent on the chosen CPU? Now that you mention this, my Power HTM patch enabled other ISA flags too, if you used -mhtm. Like so: /* For the newer switches (vsx, dfp, etc.) set some of the older options, unless the user explicitly used the -mno- to disable the code. */ - if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO) + if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO || TARGET_HTM) rs6000_isa_flags |= (ISA_2_7_MASKS_SERVER & ~rs6000_isa_flags_explicit); I think I agree with you that we shouldn't do that, since adding in those extra flags with -mhtm basically means libitm can only really run on a power8 system instead of the default -mcpu system. David, do you prefer reverting the above hunk from the Power HTM patch or should I add the associated -mno-* options to the building of libitm? Peter
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Mon, Jul 15, 2013 at 02:46:56PM -0500, Peter Bergner wrote: > > I'd say something like (but, untested and can't test it right now (and no > > access to power8 anyway)): > > Do we also need to update DWARF_REG_TO_UNWIND_COLUMN similarly, which > also uses FIRST_PSEUDO_REGISTER when the dwarf reg is an SPE synthetic > register? Looks like it. Guess that "- 1" in there: #define DWARF_REG_TO_UNWIND_COLUMN(r) \ ((r) > 1200 ? ((r) - 1200 + FIRST_PSEUDO_REGISTER - 1) : (r)) stands for the sfp register and thus it would be "- 4". > Or should we just break the dependence on FIRST_PSEUDO_REGISTER > altogether so this type of thing doesn't happen again? Otherwise, we > should place a comment at the definition of FIRST_PSEUDO_REGISTER > warning of it's use in DWARF_FRAME_REGISTER. That is surely an option too. Or use (DWARF_FRAME_REGISTERS - 32) in the DWARF_REG_TO_UNWIND_COLUMN definition instead of the current FIRST_PSEUDO_REGISTER - 1, and perhaps make DWARF_FRAME_REGISTERS just a number (independent on FIRST_PSEUDO_REGISTER). Guess this depends on what David prefers. Jakub
Re: [PATCH, rs6000] power8 patches, patch #4 (revised), new power8 builtins
On Thu, Jun 06, 2013 at 11:57:01AM -0400, David Edelsohn wrote: > But I view this as a preliminary step. The logical instructions need > an iterator and TImode needs to be cleaned up on 32 bit. > > Thanks, David Here is my proposed cleanup of the logical support. It adds DI expanders, which on 32-bit split the insn immediately, just like the current behavior in 32-bit. It defines 128-bit logical operations for both 32/64-bit modes. If VSX is available, it uses the VSX register set, but allows fallback to GPRs. Similarly for Altivec only (which was not handled in the last patch). TImode prefers GPRs, while the vector types prefer VSX/Altivec. I've bootstrapped it and ran make check with no regressions. I'm running the 10 spec tests (gcc, hmmer, povray, milc, omnetpp, h264ref, cactusADM, libquantum, perlbench, and gromacs) that use long long in some fashion and there was no significant differences in 32-bit mode, when built with the same compiler version (I'm using subversion id 200823 as the base for the moment). Are these patches ok to install? 2013-07-15 Michael Meissner * config/rs6000/vector.md (xor3): Move 128-bit boolean expanders to rs6000.md. (ior3): Likewise. (and3): Likewise. (one_cmpl2): Likewise. (nor3): Likewise. (andc3): Likewise. (eqv3): Likewise. (nand3): Likewise. (orc3): Likewise. * config/rs6000/vsx.md (VSX_L2): Delete, no longer used. (vsx_and3_32bit): Move 128-bit logical insns to rs6000.md, and allow TImode operations in 32-bit. (vsx_and3_64bit): Likewise. (vsx_ior3_32bit): Likewise. (vsx_ior3_64bit): Likewise. (vsx_xor3_32bit): Likewise. (vsx_xor3_64bit): Likewise. (vsx_one_cmpl2_32bit): Likewise. (vsx_one_cmpl2_64bit): Likewise. (vsx_nor3_32bit): Likewise. (vsx_nor3_64bit): Likewise. (vsx_andc3_32bit): Likewise. (vsx_andc3_64bit): Likewise. (vsx_eqv3_32bit): Likewise. (vsx_eqv3_64bit): Likewise. (vsx_nand3_32bit): Likewise. (vsx_nand3_64bit): Likewise. (vsx_orc3_32bit): Likewise. (vsx_orc3_64bit): Likewise. * config/rs6000/altivec.md (altivec_and): Move 128-bit logical insns to rs6000.md, and allow TImode operations in 32-bit. (altivec_ior3): Likewise. (altivec_xor3): Likewise. (altivec_one_cmpl2): Likewise. (altivec_nor3): Likewise. (altivec_andc3): Likewise. * config/rs6000/rs6000.md (BOOL_128): New mode iterators and mode attributes for moving the 128-bit logical operations into rs6000.md. (BOOL_REGS_OUTPUT): Likewise. (BOOL_REGS_OP1): Likewise. (BOOL_REGS_OP2): Likewise. (BOOL_REGS_UNARY): Likewise. (BOOL_REGS_AND_CR0): Likewise. (one_cmpl2): Add support for DI logical operations on 32-bit, splitting the operations to 32-bit. (anddi3): Likewise. (iordi3): Likewise. (xordi3): Likewise. (and3, 128-bit types): Rewrite 2013-06-06 logical operator changes to combine the 32/64-bit code, allow logical operations on TI mode in 32-bit, and to use similar match_operator patterns like scalar mode uses. Combine the Altivec and VSX code for logical operations, and move it here. (ior3, 128-bit types): Likewise. (xor3, 128-bit types): Likewise. (one_cmpl3, 128-bit types): Likewise. (nor3, 128-bit types): Likewise. (andc3, 128-bit types): Likewise. (eqv3, 128-bit types): Likewise. (nand3, 128-bit types): Likewise. (orc3, 128-bit types): Likewise. (and3_internal): Likewise. (bool3_internal): Likewise. (boolc3_internal1): Likewise. (boolc3_internal2): Likewise. (boolcc3_internal1): Likewise. (boolcc3_internal2): Likewise. (eqv3_internal1): Likewise. (eqv3_internal2): Likewise. (one_cmpl13_internal): Likewise. * config/rs6000/rs6000-protos.h (rs6000_split_logical): New declaration. * config/rs6000/rs6000.c (rs6000_split_logical_inner): Add support to split multi-word logical operations. (rs6000_split_logical_di): Likewise. (rs6000_split_logical): Likewise. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797 Index: gcc/config/rs6000/vector.md === --- gcc/config/rs6000/vector.md (.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/gcc/config/rs6000) (revision 200823) +++ gcc/config/rs6000/vector.md (.../gcc/config/rs6000) (working copy) @@ -710,87 +710,6 @@ (define_expand "cr6_test_for_lt_reverse" "") -;; Vector logical instructions -;; Do not support TImode logical instructions on 32-bit at present,
Re: Group static constructors and destructors in specific subsections
On Mon, Jul 15, 2013 at 11:18 AM, Jan Hubicka wrote: >> On Mon, Jul 15, 2013 at 11:05 AM, Jan Hubicka 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. Perhaps I misunderstand, but you can use --section-ordering-file without knowing the complete function ordering. Just specify the functions you care about. Ian
Re: [PATCH, rs6000] PR target/57150, do not use VSX instructions for long double caller saves
On Wed, Jul 03, 2013 at 04:09:53PM +, Joseph S. Myers wrote: > On Fri, 3 May 2013, Michael Meissner wrote: > > > 2013-05-03 Michael Meissner > > > > PR target/57150 > > * config/rs6000/rs6000.h (HARD_REGNO_CALLER_SAVE_MODE): Use DFmode > > to save TFmode registers and DImode to save TImode registers for > > caller save operations. > > (HARD_REGNO_CALL_PART_CLOBBERED): TFmode and TDmode do not need to > > mark being partially clobbered since they only use the first > > double word. > > > > * config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): TFmode > > and TDmode only use the upper 64-bits of each VSX register. > > That change has the effect that reload thinks TFmode (and no doubt > TDmode) only takes two registers even when in general registers, > causing a segfault in glibc's test-ldouble built for soft float. Sorry about that. Thanks for catching it. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Re: [ubsan] Add testsuite
On Mon, Jul 15, 2013 at 07:48:59PM +0200, Marek Polacek wrote: > 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. Looks good to me. > 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.? Yeah, more tests would be helpful. Also, I'd add to the tests where you use explicit constants in the operation (where we can always (and probably do) warn at compile time already) tests where it clearly can't be a compile time decided whether to warn or not and needs to be deferred to runtime. So say volatile int shiftcount = 152; ... 1 << shiftcount; and stuff like that compared to ... 1 << 152; Side-effects in the expressions also won't hurt, different types too (so that you check the different value encoding). E.g. int will be passed by value on both -m32 and -m64, while long long will be passed by reference for -m32. Anyway, this can be done incrementally. Jakub
[PATCH] MIPS: IEEE 754-2008 features support
Hi, Complementing the binutils change recently committed here's one adding IEEE 754-2008 NaN features support to GCC. Two features are supported: 1. IEEE 754-2008 NaN encoding. As many of you have been aware it has been a long practice for software using IEEE 754 floating-point arithmetic run on MIPS processors to use an encoding of Not-a-Number (NaN) data different to one used by software run on other processors. And as of IEEE 754-2008 revision this encoding does not follow one recommended in the standard, as specified in section 6.2.1, where it is stated that quiet NaNs should have the first bit (d1) of their significand set to 1 while signalling NaNs should have that bit set to 0, but MIPS software interprets the two bits in the opposite manner. As from Sep 2012 the MIPS Architecture provides for processors that support the IEEE 754-2008 preferred NaN encoding format. Options have been provided to select between the two formats (further referred to as "legacy NaN" and "2008 NaN"), both at the run time and as an initial default. The options are only available when IEEE 754-2008 NaN encoding is also supported by the binutils version used. The requirement comes from the necessity to annotate binaries with the NaN encoding convention selected so as to prevent from linking incompatible binary objects together. The run-time selection options are -mnan=2008 and -mnan=legacy for the 2008 NaN and the legacy NaN mode respectively. The binary patterns of NaN data produced by compiler builtins or otherwise is adjusted accordingly, as is a `.nan' directive included now with the assembly source produced, used by GAS to set the NAN2008 ELF file header flag appropriately. These options are also passed down to GAS by the GCC driver so that user assembly sources have the said NAN2008 flag set correctly in the absence of a `.nan' directive. Finally the name of the dynamic linker is changed accordingly if the driver is used to invoke the linker. The default encoding mode is selected with the --with-nan=2008 and --with-nan=legacy `configure' script options. The latter differs subtly from the lack of either option in that in the absence of --with-nan= no -mnan=legacy option is passed down to the assembler by the GCC driver, as suitable for older versions of binutils that do not support the IEEE 754-2008 NaN encoding feature. Test cases have been included to make sure correct bit patterns are generated. 2. IEEE 754-2008 non-arithmetic ABS and NEG instructions. As many of you have been aware MIPS ABS.fmt and NEG.fmt instructions have not supported correct standard-compliant operation on a NaN argument as the architecture has considered them arithmetic and required to signal an Invalid Operation exception (that may or may not be trapped; in the latter case a quiet NaN is produced). As a result in cases where standard compliance is required GCC has to emit longer sequences to move the value given from the FPU to the CPU, use an integer logical operation to adjust the sign bit manually, and then move the result back to FPU. As from Sep 2012 the MIPS Architecture provides for processors that support the IEEE 754-2008 requirement that operations on bit strings, that among others include ABS and NEG, are non-arithmetic and never signal an exception. Options have been provided to select between the two modes; these are -mabs=2008 and -mabs=legacy for the 2008 ABS and the legacy ABS mode respectively. Test cases have been included to make sure the ABS.fmt and NEG.fmt instructions are or are not generated, as appropriate for the hardware compliance mode selected. I have regression-tested this change successfully with the mips-linux-gnu target, o32 ABI. Comments or questions? OK to apply? 2013-07-15 Maciej W. Rozycki gcc/ * config/mips/linux.h (GLIBC_DYNAMIC_LINKER): Handle `-mnan=2008'. (UCLIBC_DYNAMIC_LINKER): New macro. * config/mips/linux64.h (GLIBC_DYNAMIC_LINKER32): Handle `-mnan=2008'. (GLIBC_DYNAMIC_LINKER64, GLIBC_DYNAMIC_LINKERN32): Likewise. (UCLIBC_DYNAMIC_LINKER32): Undefine macro first. Handle `-mnan=2008'. (UCLIBC_DYNAMIC_LINKER64): Redefine macro. (UCLIBC_DYNAMIC_LINKERN32): Likewise. * config/mips/mips-modes.def: Remove RESET_FLOAT_FORMAT calls for SF and DF modes. Use ieee_quad_format for TF mode. * config/mips/mips-opts.h (mips_abs_setting): New enum. (mips_nan_setting): Likewise. * config/mips/mips.c (mips_file_start) [HAVE_AS_NAN]: Output a `.nan' directive. (mips_option_override): Handle `-mnan=legacy'. * config/mips/mips.h (TARGET_CPU_CPP_BUILTINS): Handle `-mabs=2008' and `-mnan=2008'. (OPTION_DEFAULT_SPECS): Add "nan" default. (ASM_SPEC): Handle `-mnan='. * config/mips/mips.md (abs2): Handle `-mabs=2008', update comment accordingly. (neg2)
Re: [ubsan] Add testsuite
On Tue, Jul 16, 2013 at 01:27:00AM +0200, Jakub Jelinek wrote: > On Mon, Jul 15, 2013 at 07:48:59PM +0200, Marek Polacek wrote: > > 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. > > Looks good to me. Thanks, commited to ubsan branch. > > 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.? > > Yeah, more tests would be helpful. Also, I'd add to the tests where you use > explicit constants in the operation (where we can always (and probably do) > warn at compile time already) tests where it clearly can't be a compile time > decided whether to warn or not and needs to be deferred to runtime. > So say > volatile int shiftcount = 152; > ... 1 << shiftcount; > and stuff like that compared to > ... 1 << 152; > Side-effects in the expressions also won't hurt, different types too > (so that you check the different value encoding). E.g. int will be passed > by value on both -m32 and -m64, while long long will be passed by reference > for -m32. > > Anyway, this can be done incrementally. Ok, will add something like that. Marek
[committed] MIPS: MULS/MSAC/MACC comment typo fixes
Hi,
Inspired by the missing "add" in the ISA_HAS_MACC description. Committed
as obvious.
2013-07-16 Maciej W. Rozycki
gcc/
* config/mips/mips.h (ISA_HAS_MULS, ISA_HAS_MSAC, ISA_HAS_MACC):
Fix comment typos.
Maciej
Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h (revision 200967)
+++ gcc/config/mips/mips.h (working copy)
@@ -929,22 +929,22 @@ struct mips_cpu_info {
|| TARGET_SR71K) \
&& !TARGET_MIPS16)
-/* ISA has three operand multiply instructions that
- negates the result and puts the result in an accumulator. */
+/* ISA has three operand multiply instructions that negate the
+ result and put the result in an accumulator. */
#define ISA_HAS_MULS ((TARGET_MIPS5400 \
|| TARGET_MIPS5500\
|| TARGET_SR71K) \
&& !TARGET_MIPS16)
-/* ISA has three operand multiply instructions that subtracts the
- result from a 4th operand and puts the result in an accumulator. */
+/* ISA has three operand multiply instructions that subtract the
+ result from a 4th operand and put the result in an accumulator. */
#define ISA_HAS_MSAC ((TARGET_MIPS5400 \
|| TARGET_MIPS5500\
|| TARGET_SR71K) \
&& !TARGET_MIPS16)
-/* ISA has three operand multiply instructions that the result
- from a 4th operand and puts the result in an accumulator. */
+/* ISA has three operand multiply instructions that add the result
+ to a 4th operand and put the result in an accumulator. */
#define ISA_HAS_MACC ((TARGET_MIPS4120 \
|| TARGET_MIPS4130\
|| TARGET_MIPS5400\
Re: [PATCH] S/390: Hardware transactional memory support
On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner wrote: > On Mon, 2013-07-15 at 21:32 +0200, Jakub Jelinek wrote: >> Have you considered trying it to work even when libitm itself isn't built >> for zEC12 or later only? I mean, both the i?86/x86_64 and powerpc* libitm >> HTM don't define htm_available as unconditional true, they check in some way >> whether the CPU supports HTM and return true if yes, and as needed some >> parts or whole of libitm is compiled with some compiler option that >> allows the HTM instructions to be generated. >> >> I see your patch will currently error out if you have HTM builtins >> insode of code, -mtx and don't enable -march=zEC12, could that be changed, >> so that -mtx is essentially independent on the chosen CPU? > > Now that you mention this, my Power HTM patch enabled other ISA flags too, > if you used -mhtm. Like so: > >/* For the newer switches (vsx, dfp, etc.) set some of the older options, > unless the user explicitly used the -mno- to disable the code. > */ > - if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO) > + if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO || TARGET_HTM) > rs6000_isa_flags |= (ISA_2_7_MASKS_SERVER & ~rs6000_isa_flags_explicit); > > I think I agree with you that we shouldn't do that, since adding in > those extra flags with -mhtm basically means libitm can only really > run on a power8 system instead of the default -mcpu system. > > David, do you prefer reverting the above hunk from the Power HTM > patch or should I add the associated -mno-* options to the building > of libitm? How is libitm built for Intel? The principle of least surprises suggests following that precedent. - David
Re: [PATCH] S/390: Hardware transactional memory support
On Mon, 2013-07-15 at 23:03 -0400, David Edelsohn wrote: > On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner wrote: > > David, do you prefer reverting the above hunk from the Power HTM > > patch or should I add the associated -mno-* options to the building > > of libitm? > > How is libitm built for Intel? The principle of least surprises > suggests following that precedent. They use -mrtm (like we use -mhtm) to build libitm, but it looks like their -mrtm does not enable any other isa flags like we currently are doing with -mhtm. Meaning their -mrtm option is independent of any -mcpu values while ours is not. If we revert the patch I mentioned, then I think we will match what Intel is doing. Hopefully Jakub will correct me if I am wrong. Peter
Re: [PATCH] S/390: Hardware transactional memory support
On Mon, Jul 15, 2013 at 10:40:04PM -0500, Peter Bergner wrote: > On Mon, 2013-07-15 at 23:03 -0400, David Edelsohn wrote: > > On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner wrote: > > > David, do you prefer reverting the above hunk from the Power HTM > > > patch or should I add the associated -mno-* options to the building > > > of libitm? > > > > How is libitm built for Intel? The principle of least surprises > > suggests following that precedent. > > They use -mrtm (like we use -mhtm) to build libitm, but it looks like > their -mrtm does not enable any other isa flags like we currently are > doing with -mhtm. Meaning their -mrtm option is independent of any > -mcpu values while ours is not. If we revert the patch I mentioned, > then I think we will match what Intel is doing. > Hopefully Jakub will correct me if I am wrong. Yes, that is my understanding of it too. On Intel we have: #define OPTION_MASK_ISA_RTM_SET OPTION_MASK_ISA_RTM #define OPTION_MASK_ISA_RTM_UNSET OPTION_MASK_ISA_RTM which means that -mrtm doesn't set any other options except for itself and -mno-rtm doesn't reset other options. libitm is built with -mrtm, assuming that the only thing the -mrtm switch affects are the HTM builtins and that those will only be found explicitly in code guarded with the htm_available () runtime check. Right now, -mhtm on PowerPC basically implies -march=power8 if I understand the code well, and libitm is built with it, which means essentially that when gcc is configured for a pre-power8 CPU, libitm will work just fine on power8 (including HTM support), but when running on power7 and earlier it might very well SIGILL, because the implicit -march=power8 could affect even code not guarded by htm_available (). And on s/390, right now we enable HTM support in libitm when configured for -march=zEC12 by default (which isn't ideal). Jakub
Re: [ubsan] Add testsuite
+# ubsan_finish -- called at the start of each subdir of tests s/the start/the end/ Thanks, Sent with AquaMail for Android http://www.aqua-mail.com
