[patch][wwwdocs] gcc 4.8 changes - AMD new cores
Hello, This patch adds short words about the new AMD cores that got enabled in GCC-4.8. OK for the wwwdocs? Regards Ganesh Index: gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.96 diff -u -r1.96 changes.html --- gcc-4.8/changes.html12 Feb 2013 16:33:58 - 1.96 +++ gcc-4.8/changes.html13 Feb 2013 08:24:53 - @@ -529,6 +529,10 @@ information. /li li Windows MinGW-w64 targets (code*-w64-mingw*/code) require at least r5437 from the Mingw-w64 trunk. /li +liSupport for new AMD family 15h processors (Steamroller core) is now available + through code-march=bdver3/code and code-mtune=bdver3/code options./li +liSupport for new AMD family 16h processors (Jaguar core) is now available + through code-march=btver2/code and code-mtune=btver2/code options./li /ul h3 id=frvFRV/h3
Re: [PATCH] Fix PR56181, rewrite fix_loop_structure
On Tue, 12 Feb 2013, Marcus Shawcroft wrote: On 12 February 2013 15:38, Richard Biener rguent...@suse.de wrote: On Tue, 12 Feb 2013, Marcus Shawcroft wrote: Sorry, I'll send that again copying gcc-patches in this time... -- Forwarded message -- From: Marcus Shawcroft marcus.shawcr...@gmail.com Date: 12 February 2013 15:17 Subject: Re: [PATCH] Fix PR56181, rewrite fix_loop_structure To: Richard Biener rguent...@suse.de On 12 February 2013 14:54, Richard Biener rguent...@suse.de wrote: I can't reproduce this with a cross-compiler (--target=arm-non-eabi). How exactly did you configure? Please provide -v output. Richard. I don't see the issue in arm-none-eabi either, just arm-none-linux-gnueabi. --enable-shared --disable-libssp --disable-libmudflap --with-plugin-ld=arm-none-linux-gnueabi-ld --enable-languages=c,c++,fortran --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp I still can't reproduce it. I tried with pristine trunk rev. 195979. --target=arm-none-linux-gnueabi --enable-languages=c,c++,fortran --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp gcc ./cc1 -quiet pr54458.c -O3 -fomit-frame-pointer -g -I include gcc Richard. Richard, could you try that with -fPIC ? That works! I mean, it fails. Investigating. Richard.
Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)
Sriraman Tallam tmsri...@google.com writes:
Index: gcc/testsuite/g++.dg/ext/mv12-aux.C
===
--- gcc/testsuite/g++.dg/ext/mv12-aux.C (revision 0)
+++ gcc/testsuite/g++.dg/ext/mv12-aux.C (revision 0)
@@ -0,0 +1,11 @@
+// Test case to check if multiversioning works as expected when the versions
+// are defined in different files. Auxiliary file for mv12.C.
+// { dg-do compile }
+
+#include mv12.h
+
+__attribute__ ((target (sse4.2)))
+int foo ()
FAIL: g++.dg/ext/mv12-aux.C -std=c++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20130213/gcc/testsuite/g++.dg/ext/mv12.h:5:47: warning:
target attribute is not supported on this machine [-Wattributes]
/daten/aranym/gcc/gcc-20130213/gcc/testsuite/g++.dg/ext/mv12.h:6:46: warning:
target attribute is not supported on this machine [-Wattributes]
/daten/aranym/gcc/gcc-20130213/gcc/testsuite/g++.dg/ext/mv12-aux.C:8:10:
warning: target attribute is not supported on this machine [-Wattributes]
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
And now for something completely different.
[PATCH] Fix mn10300 compile
The following fixes compilation of mn10300 which broke when the interface to flow_loops_find changed (as reported in a comment in PR56294). I took the liberty to use the proper interface for initializing the loop tree. Built a mn10300 cc1, committed as obvious. Richard. 2013-02-13 Richard Biener rguent...@suse.de * config/mn10300/mn10300.c (mn10300_scan_for_setlb_lcc): Fix loop discovery code. Index: gcc/config/mn10300/mn10300.c === --- gcc/config/mn10300/mn10300.c(revision 195997) +++ gcc/config/mn10300/mn10300.c(working copy) @@ -3235,9 +3235,7 @@ mn10300_scan_for_setlb_lcc (void) compute_bb_for_insn (); /* Find the loops. */ - if (flow_loops_find ( loops) 1) -DUMP (No loops found, NULL_RTX); - current_loops = loops; + loop_optimizer_init (AVOID_CFG_MODIFICATIONS); /* FIXME: For now we only investigate innermost loops. In practice however if an inner loop is not suitable for use with the SETLB/Lcc insns, it may @@ -3287,15 +3285,7 @@ mn10300_scan_for_setlb_lcc (void) reason); } -#if 0 /* FIXME: We should free the storage we allocated, but -for some unknown reason this leads to seg-faults. */ - FOR_EACH_LOOP (liter, loop, 0) -free_simple_loop_desc (loop); - - flow_loops_free (current_loops); -#endif - - current_loops = NULL; + loop_optimizer_finalize (); df_finish_pass (false);
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 01:19:47PM +0400, Konstantin Serebryany wrote:
The attached patch is the libsanitizer merge from upstream r175042.
Lots of changes. Among other things:
- x86_64 linux: change the shadow offset to 0x7fff8000 (~5% speedup)
- the new asan allocator is enabled on Mac (was enabled on Linux before).
- tsan finds races between atomic and plain accesses
- better scanf interceptor, enabled by default
- don't include linux/futex.h (fixes PR56128)
- simple tests seem to work (again?) on PowerPC64 with 44-bit address
space (46 AS not tested)
Patch for libsanitizer is automatically generated by libsanitizer/merge.sh
Tested with
rm -rf */{*/,}libsanitizer \
make -j 50 \
make -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
Our internal LLVM bots (Linux, Mac and Android) are green.
Ok to commit?
--- libsanitizer/asan/asan_mapping.h(revision 195997)
+++ libsanitizer/asan/asan_mapping.h(working copy)
@@ -34,27 +34,16 @@
# if defined(__powerpc64__)
#define SHADOW_OFFSET (1ULL 41)
# else
-#define SHADOW_OFFSET (1ULL 44)
+#define SHADOW_OFFSET 0x7fff8000ULL
# endif
# endif
# endif
#endif // ASAN_FLEXIBLE_MAPPING_AND_OFFSET
This is inconsistent with the i386.c change. You said the 0x7fff8000ULL
shadow offset doesn't work on Darwin, so either the above should be
+#if ASAN_MAC
+# define SHADOW_OFFSET (1ULL 44)
+#else
+# define SHADOW_OFFSET 0x7fff8000ULL
+#endif
or i386.c should use 0x7fff8000 even for TARGET_MACHO TARGET_LP64.
--- gcc/config/i386/i386.c (revision 195997)
+++ gcc/config/i386/i386.c (working copy)
@@ -5436,7 +5436,9 @@
static unsigned HOST_WIDE_INT
ix86_asan_shadow_offset (void)
{
- return (unsigned HOST_WIDE_INT) 1 (TARGET_LP64 ? 44 : 29);
+ return TARGET_LP64 ? (TARGET_MACHO ? (HOST_WIDE_INT_1 44)
+ : HOST_WIDE_INT_C (0x7fff8000))
+ : (HOST_WIDE_INT_1 29);
Please use tabs instead of 8 spaces, and indent it properly (second line
: below the second ?, third line : below first ?).
+2013-02-13 Kostya Serebryany k...@google.com
+
+ * config/i386/i386.c: use 0x7fff8000 as asan_shadow_offset on x86_64
+ linux.
Start sentence, so Use instead of use.
+ * sanitizer.def: rename __asan_init to __asan_init_v1.
Likewise, Rename.
+ * testsuite/c-c++-common/asan/strncpy-overflow-1.c: update the test
+ to match the fresh asan run-time.
Update. Also, these two go into gcc/testsuite/ChangeLog, without
testsuite/ prefix in the pathnames.
+ * testsuite/c-c++-common/asan/rlimit-mmap-test-1.c: Ditto.
+
Jakub
Re: [Patch,avr]: Add more devices take #2: 1/2
Let me drop this, I was thinking too complicated.
src/gas/config/tc-avr.c
reads:
static struct mcu_type_s mcu_types[] =
{
{avr1, AVR_ISA_AVR1,bfd_mach_avr1},
/* TODO: insruction set for avr2 architecture should be AVR_ISA_AVR2,
but set to AVR_ISA_AVR25 for some following version
of GCC (from 4.3) for backward compatibility. */
{avr2, AVR_ISA_AVR25, bfd_mach_avr2},
{avr25, AVR_ISA_AVR25, bfd_mach_avr25},
/* TODO: insruction set for avr3 architecture should be AVR_ISA_AVR3,
but set to AVR_ISA_AVR3_ALL for some following version
of GCC (from 4.3) for backward compatibility. */
{avr3, AVR_ISA_AVR3_ALL, bfd_mach_avr3},
{avr31, AVR_ISA_AVR31, bfd_mach_avr31},
{avr35, AVR_ISA_AVR35, bfd_mach_avr35},
{avr4, AVR_ISA_AVR4,bfd_mach_avr4},
/* TODO: insruction set for avr5 architecture should be AVR_ISA_AVR5,
but set to AVR_ISA_AVR51 for some following version
of GCC (from 4.3) for backward compatibility. */
{avr5, AVR_ISA_AVR51, bfd_mach_avr5},
{avr51, AVR_ISA_AVR51, bfd_mach_avr51},
{avr6, AVR_ISA_AVR6,bfd_mach_avr6},
This means that cores liek avr31, avr35 etc. are supported by binutils and
there is no more the need for avr-gcc to do mappings like avr31 - avr3.
It appears that avr-gcc implemented these mappings to overcome missing binutils
support for specific cores, and in turn binutils arranged for that kludge...
This means that avr_arch_t need not to be extended to hold the arch mapping for
gas calls and the gas call can use the core name from avr_arch_t.
I broke the patch into two parts:
1/2: New devices
2/2: Map device to core to disentangle gcc/binutils interdependencies.
Okay for trunk and 4.7 backport?
Johann
* avr/avr-mcus.def (ata5272, ata5505, attiny1634, ata6285)
(ata6286, atmega8a, atmega48pa, ata5790, ata5790n, ata5795)
(atmega164pa, atmega165pa, atmega168pa, atmega16hva, atmega16hvb)
(atmega16hvbrevb, atmega16m1, atmega16u4, atmega26hvg, atmega32a)
(atmega32a, atmega3250pa, atmega3290pa, atmega32c1, atmega32m1)
(atmega32u4, atmega32u6, atmega64a, atmega6490a, atmega6490p)
(atmega64c1, atmega64m1, atmega64rfa2, atmega64rfr2, atmega32hvb)
(atmega32hvbrevb, atmega16hva2, atmega48hvf, at90pwm161)
(atmega128a, atmega1284, atmxt112sl, atmxt224, atmxt224e)
(atmxt336s, atxmega16a4u, atxmega16c4, atxmega32a4u, atxmega32c4)
(atxmega32e5, atxmega64a3u, atxmega64a4u, atxmega64b1, atxmega64b3)
(atxmega64c3, atxmega64d4, atxmega128a3u, atxmega128b1)
(atxmega128b3, atxmega128c3, atxmega128d4, atmxt540s, atmxt540sreva)
(atxmega192a3u, atxmega192c3, atxmega256a3u, atxmega256c3)
(atxmega384c3, atxmega384d3, atxmega128a4u): New AVR_MCU.
(avrxmega6): Increase max flash segments from 5 to 6.
* config/avr/t-multilib: Regenerate.
* config/avr/avr-tables.opt: Regenerate.
* doc/avr-mmcu.texi: Regenerate.
Georg-Johann Lay wrote:
This patch adds more devices to avr-mcus.def and regenerates depending files.
There is a new spec function that is the worker for ASM_SPEC and that
transforms -mmcu=device to -mmcu=arch for avr-as.
This transformation was already performed for avr25, avr31, avr35 and avr51
and
is now performed for all devices so that avr-as only need to support
-mmcu=arch.
Rationale is to reduce tool dependencies: as need not to know what device it
compiles for, the core is enough. The only cases where the core arch is no
enough is
- Tell whether the device suffers from skip silicon bug
- Tell whether the device supporte DES, XCH, LAS, LAC, LAT instruction.
The first case is handled by device_to_as that issues -mno-skip-bug as needed.
The second case is not handled. Binutils is agnostic w.r.t. availability of
these instructions if the exact device is supplied. If binutils will wver be
extended to know about these instructions, the preferred way is as described
in
http://sourceware.org/PR15043
i.e. add new ISA options to binutils. That way, tools dependencies can be
disentangled and binutils need not to be changed for every new device.
Ok for trunk?
Even though this is new feature, I'd propose to backport the additions to
avr-mcus.def to 4.7. The changes to avr-mcus.def are obvious enough, IMO.
Okay to backport avr-mcus.def and docs part to 4.7 then?
Johann
* config/avr/avr-arch.h (avr_arch_t) arch_for_as: New component.
* config/avr/avr-devices.c: Initialize it.
* config/avr/avr.h (device_to_arch): Rename to device_to_ld.
(avr_device_to_arch): Rename to avr_device_to_ld.
(avr_device_to_as): New prototype.
(EXTRA_SPEC_FUNCTIONS): Add device_to_as.
(ASM_SPEC): Use device_to_as to get -mmcu= and -mno-skip-bug=.
* config/avr/driver-avr.c (avr_device_to_as): New.
(avr_device_to_arch): Rename to avr_device_to_ld.
*
[PATCH] Fix RTL unswitching loop verification ICE
This fixes the reported ICE on arm. Similar to tree level unswitching
RTL level unswitching can expose formerly irreducible regions as new
loops. The following patch makes sure to discover them (we now
verify we do).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2013-02-13 Richard Biener rguent...@suse.de
* loop-init.c (loop_optimizer_init): Clear loop state when
re-initializing preserved loops.
* loop-unswitch.c (unswitch_single_loop): Return whether
we unswitched the loop. Do not verify loop state here.
(unswitch_loops): When we unswitched a loop discover new
loops.
Index: gcc/loop-init.c
===
*** gcc/loop-init.c (revision 195997)
--- gcc/loop-init.c (working copy)
*** loop_optimizer_init (unsigned flags)
*** 99,104
--- 99,107
#ifdef ENABLE_CHECKING
verify_loop_structure ();
#endif
+
+ /* Clear all flags. */
+ loops_state_clear (~0U);
}
/* Apply flags to loops. */
Index: gcc/loop-unswitch.c
===
*** gcc/loop-unswitch.c (revision 195997)
--- gcc/loop-unswitch.c (working copy)
*** along with GCC; see the file COPYING3.
*** 78,84
with handling this case. */
static struct loop *unswitch_loop (struct loop *, basic_block, rtx, rtx);
! static void unswitch_single_loop (struct loop *, rtx, int);
static rtx may_unswitch_on (basic_block, struct loop *, rtx *);
/* Prepare a sequence comparing OP0 with OP1 using COMP and jumping to LABEL
if
--- 78,84
with handling this case. */
static struct loop *unswitch_loop (struct loop *, basic_block, rtx, rtx);
! static bool unswitch_single_loop (struct loop *, rtx, int);
static rtx may_unswitch_on (basic_block, struct loop *, rtx *);
/* Prepare a sequence comparing OP0 with OP1 using COMP and jumping to LABEL
if
*** unswitch_loops (void)
*** 140,152
{
loop_iterator li;
struct loop *loop;
/* Go through inner loops (only original ones). */
FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
! unswitch_single_loop (loop, NULL_RTX, 0);
iv_analysis_done ();
}
/* Checks whether we can unswitch LOOP on condition at end of BB -- one of its
--- 140,161
{
loop_iterator li;
struct loop *loop;
+ bool changed = false;
/* Go through inner loops (only original ones). */
FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
! changed |= unswitch_single_loop (loop, NULL_RTX, 0);
iv_analysis_done ();
+
+ /* If we unswitched any loop discover new loops that are eventually
+ exposed by making irreducible regions reducible. */
+ if (changed)
+ {
+ calculate_dominance_info (CDI_DOMINATORS);
+ fix_loop_structure (NULL);
+ }
}
/* Checks whether we can unswitch LOOP on condition at end of BB -- one of its
*** reversed_condition (rtx cond)
*** 241,248
/* Unswitch single LOOP. COND_CHECKED holds list of conditions we already
unswitched on and are therefore known to be true in this LOOP. NUM is
number of unswitchings done; do not allow it to grow too much, it is too
!easy to create example on that the code would grow exponentially. */
! static void
unswitch_single_loop (struct loop *loop, rtx cond_checked, int num)
{
basic_block *bbs;
--- 250,258
/* Unswitch single LOOP. COND_CHECKED holds list of conditions we already
unswitched on and are therefore known to be true in this LOOP. NUM is
number of unswitchings done; do not allow it to grow too much, it is too
!easy to create example on that the code would grow exponentially.
!Returns true LOOP was unswitched. */
! static bool
unswitch_single_loop (struct loop *loop, rtx cond_checked, int num)
{
basic_block *bbs;
*** unswitch_single_loop (struct loop *loop,
*** 258,264
{
if (dump_file)
fprintf (dump_file, ;; Not unswitching anymore, hit max level\n);
! return;
}
/* Only unswitch innermost loops. */
--- 268,274
{
if (dump_file)
fprintf (dump_file, ;; Not unswitching anymore, hit max level\n);
! return false;
}
/* Only unswitch innermost loops. */
*** unswitch_single_loop (struct loop *loop,
*** 266,272
{
if (dump_file)
fprintf (dump_file, ;; Not unswitching, not innermost loop\n);
! return;
}
/* We must be able to duplicate loop body. */
--- 276,282
{
if (dump_file)
fprintf (dump_file, ;; Not unswitching, not innermost loop\n);
! return false;
}
/* We must be able to duplicate loop body. */
*** unswitch_single_loop (struct loop *loop,
*** 274,280
{
if (dump_file)
fprintf
Re: [Patch,avr]: Add more devices take #2: 2/2
And here 2/2 with the device - arch mapping for gas.
Ok for trunk?
Johann
* config/avr/avr.h (device_to_arch): Rename to device_to_ld.
(avr_device_to_arch): Rename to avr_device_to_ld.
(avr_device_to_as): New prototype.
(EXTRA_SPEC_FUNCTIONS): Add device_to_as.
(ASM_SPEC): Use device_to_as to get -mmcu= and -mno-skip-bug=.
* config/avr/driver-avr.c (avr_device_to_as): New.
(avr_device_to_arch): Rename to avr_device_to_ld.
Index: config/avr/avr.h
===
--- config/avr/avr.h (revision 195877)
+++ config/avr/avr.h (working copy)
@@ -486,14 +486,16 @@ typedef struct avr_args
#define ADJUST_INSN_LENGTH(INSN, LENGTH)\
(LENGTH = avr_adjust_insn_length (INSN, LENGTH))
-extern const char *avr_device_to_arch (int argc, const char **argv);
+extern const char *avr_device_to_as (int argc, const char **argv);
+extern const char *avr_device_to_ld (int argc, const char **argv);
extern const char *avr_device_to_data_start (int argc, const char **argv);
extern const char *avr_device_to_startfiles (int argc, const char **argv);
extern const char *avr_device_to_devicelib (int argc, const char **argv);
extern const char *avr_device_to_sp8 (int argc, const char **argv);
#define EXTRA_SPEC_FUNCTIONS\
- { device_to_arch, avr_device_to_arch }, \
+ { device_to_as, avr_device_to_as }, \
+ { device_to_ld, avr_device_to_ld }, \
{ device_to_data_start, avr_device_to_data_start }, \
{ device_to_startfile, avr_device_to_startfiles }, \
{ device_to_devicelib, avr_device_to_devicelib }, \
@@ -507,14 +509,9 @@ extern const char *avr_device_to_sp8 (in
#define CC1PLUS_SPEC %{!frtti:-fno-rtti} \
%{!fenforce-eh-specs:-fno-enforce-eh-specs} \
%{!fexceptions:-fno-exceptions}
-/* A C string constant that tells the GCC driver program options to
- pass to `cc1plus'. */
-
-#define ASM_SPEC %{mmcu=avr25:-mmcu=avr2;mmcu=avr35:-mmcu=avr3;mmcu=avr31:-mmcu=avr3;mmcu=avr51:-mmcu=avr5;\
-mmcu=*:-mmcu=%*} \
-%{mmcu=*:%{!mmcu=avr2:%{!mmcu=at90s8515:%{!mmcu=avr31:%{!mmcu=atmega103:\
--mno-skip-bug}
+#define ASM_SPEC %:device_to_as(%{mmcu=*:%*})
+
#define LINK_SPEC \
%{mrelax:--relax\
%{mpmem-wrap-around:%{mmcu=at90usb8*:--pmem-wrap-around=8k}\
@@ -524,7 +521,7 @@ mmcu=*:-mmcu=%*} \
%{mmcu=atmega64*|\
mmcu=at90can64*|\
mmcu=at90usb64*:--pmem-wrap-around=64k}}}\
-%:device_to_arch(%{mmcu=*:%*})\
+%:device_to_ld(%{mmcu=*:%*})\
%:device_to_data_start(%{mmcu=*:%*})
#define LIB_SPEC \
Index: config/avr/driver-avr.c
===
--- config/avr/driver-avr.c (revision 195877)
+++ config/avr/driver-avr.c (working copy)
@@ -48,10 +48,25 @@ avr_set_current_device (const char *name
avr_current_arch = avr_arch_types[avr_current_device-arch];
}
-/* Returns command line parameters that describe the device architecture. */
+/* Returns command line parameters to pass to as. */
-const char *
-avr_device_to_arch (int argc, const char **argv)
+const char*
+avr_device_to_as (int argc, const char **argv)
+{
+ if (0 == argc)
+return NULL;
+
+ avr_set_current_device (argv[0]);
+
+ return concat (-mmcu=, avr_current_arch-arch_name,
+ avr_current_device-errata_skip ? : -mno-skip-bug,
+ NULL);
+}
+
+/* Returns command line parameters to pass to ld. */
+
+const char*
+avr_device_to_ld (int argc, const char **argv)
{
if (0 == argc)
return NULL;
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 02:28:25PM +0400, Konstantin Serebryany wrote: Right. In LLVM we test only with ASAN_FLEXIBLE_MAPPING_AND_OFFSET==1, so this came unnoticed. Fixed in r175049. ... This is ok, thanks. Jakub
Re: expansion of vector shifts...
On Tue, Feb 12, 2013 at 11:31 PM, David Miller da...@davemloft.net wrote:
From: David Miller da...@redhat.com
Date: Fri, 16 Nov 2012 00:33:05 -0500 (EST)
From: Richard Sandiford rdsandif...@googlemail.com
Date: Mon, 29 Oct 2012 10:14:53 +
...given that the code is like you say written:
if (SHIFT_COUNT_TRUNCATED)
{
if (CONST_INT_P (op1)
...
else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1
op1 = SUBREG_REG (op1);
}
INTEGRAL_MODE_P (GET_MODE (op1)) might be better than an explicit
VECTOR_MODE_P check. The code really doesn't make sense for anything
other than integers.
(It amounts to the same thing in practice, of course...)
Agreed, I've just committed the following. Thanks!
Fix gcc.c-torture/compile/pr53410-2.c on sparc.
* expmed.c (expand_shift_1): Don't strip non-integral SUBREGs.
This is broken on sparc again, although I'm confused about how this
has happened.
The suggestion was to use INTEGRAL_MODE_P as the test, so what's there
in expand_shift_1() is:
else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
INTEGRAL_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);
but INTEGRAL_MODE_P accepts vectors. This is really confusing because
I was absolutely sure I re-ran the test case with the fix I committed
and it didn't crash any more.
Maybe what we really mean to do here is check both op1 and SUBREG_REG
(op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P?
Yes.
Something like this:
gcc/
2013-02-12 David S. Miller da...@davemloft.net
* expmed.c (expand_shift_1): Only strip scalar integer subregs.
diff --git a/gcc/expmed.c b/gcc/expmed.c
index 4a6ddb0..954a360 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -2116,8 +2116,8 @@ expand_shift_1 (enum tree_code code, enum machine_mode
mode, rtx shifted,
% GET_MODE_BITSIZE (mode));
else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
- INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
- INTEGRAL_MODE_P (GET_MODE (op1)))
+ SCALAR_INT_MODE_P (GET_MODE (SUBREG_REG (op1)))
+ SCALAR_INT_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);
}
Re: [GCC 4.8 changes] PATCH: Mention several user-visible changes for x86
Please also mention new -mfxsr, -mxsave and -mxsaveopt options. li New built-in functions to detect run-time CPU type and ISA: ul liA built-in function code__builtin_cpu_is/code has been added to *** *** 524,529 --- 530,538 a href=http://gcc.gnu.org/wiki/FunctionMultiVersioning;wiki/a for more information. /li + li Problem with instability of pre-reload scheduler on x86 targets was fixed. Now option -fschedule-insn + can be used loosely to reach better performance. used loosely in what sense? Thanks, Uros. Updated version. Does it look ok? Thanks, Igor Index: htdocs/gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.95 diff -c -r1.95 changes.html *** htdocs/gcc-4.8/changes.html 11 Feb 2013 15:12:58 - 1.95 --- htdocs/gcc-4.8/changes.html 12 Feb 2013 15:10:41 - *** *** 460,465 --- 460,471 wrong results. You must build all modules with code-mpreferred-stack-boundary=3/code, including any libraries. This includes the system libraries and startup modules./li + liSupport for the new Intel processor codename Broadwell with RDSEED, + ADCX, ADOX, PREFETCHW is available through code-madx/code, + code-mprfchw/code, code-mrdseed/code. + /li + li Support for Intel RTM and HLE intrinsics, built-in functions and code generation is available via code-mrtm/code and code-mhle/code. + /li + li Support for Intel FXSR, XSAVE and XSAVEOPT instruction sets. Intrinsics and built-in functions are available + via code-mfxsr/code, code-mxsave/code and code-mxsaveopt/code respectively. + /li li New built-in functions to detect run-time CPU type and ISA: ul liA built-in function code__builtin_cpu_is/code has been added to *** *** 524,529 --- 530,538 a href=http://gcc.gnu.org/wiki/FunctionMultiVersioning;wiki/a for more information. /li + li x86 backend was improved to allow option code-fscedule-insns/code to work reliably. + This option can be used to schedule instructions better and can lead to improved performace in certain cases. + /li li Windows MinGW-w64 targets (code*-w64-mingw*/code) require at least r5437 from the Mingw-w64 trunk. /li /ul
Re: [GCC 4.8 changes] PATCH: Mention several user-visible changes for x86
On Wed, Feb 13, 2013 at 12:17 PM, Igor Zamyatin izamya...@gmail.com wrote: Please also mention new -mfxsr, -mxsave and -mxsaveopt options. li New built-in functions to detect run-time CPU type and ISA: ul liA built-in function code__builtin_cpu_is/code has been added to *** *** 524,529 --- 530,538 a href=http://gcc.gnu.org/wiki/FunctionMultiVersioning;wiki/a for more information. /li + li Problem with instability of pre-reload scheduler on x86 targets was fixed. Now option -fschedule-insn + can be used loosely to reach better performance. used loosely in what sense? Thanks, Uros. Updated version. Does it look ok? Looks OK to me. I have CC'd Gerald for a grammar and style check. Thanks, Uros. Thanks, Igor Index: htdocs/gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.95 diff -c -r1.95 changes.html *** htdocs/gcc-4.8/changes.html 11 Feb 2013 15:12:58 - 1.95 --- htdocs/gcc-4.8/changes.html 12 Feb 2013 15:10:41 - *** *** 460,465 --- 460,471 wrong results. You must build all modules with code-mpreferred-stack-boundary=3/code, including any libraries. This includes the system libraries and startup modules./li + liSupport for the new Intel processor codename Broadwell with RDSEED, + ADCX, ADOX, PREFETCHW is available through code-madx/code, + code-mprfchw/code, code-mrdseed/code. + /li + li Support for Intel RTM and HLE intrinsics, built-in functions and code generation is available via code-mrtm/code and code-mhle/code. + /li + li Support for Intel FXSR, XSAVE and XSAVEOPT instruction sets. Intrinsics and built-in functions are available + via code-mfxsr/code, code-mxsave/code and code-mxsaveopt/code respectively. + /li li New built-in functions to detect run-time CPU type and ISA: ul liA built-in function code__builtin_cpu_is/code has been added to *** *** 524,529 --- 530,538 a href=http://gcc.gnu.org/wiki/FunctionMultiVersioning;wiki/a for more information. /li + li x86 backend was improved to allow option code-fscedule-insns/code to work reliably. + This option can be used to schedule instructions better and can lead to improved performace in certain cases. + /li li Windows MinGW-w64 targets (code*-w64-mingw*/code) require at least r5437 from the Mingw-w64 trunk. /li /ul
Re: [PATCH] Fix RTL unswitching loop verification ICE
On 13 February 2013 10:11, Richard Biener rguent...@suse.de wrote: This fixes the reported ICE on arm. Similar to tree level unswitching RTL level unswitching can expose formerly irreducible regions as new loops. The following patch makes sure to discover them (we now verify we do). Bootstrap and regtest pending on x86_64-unknown-linux-gnu. Richard. Thanks for looking at this. The proposed patch resolves the issue on both arm and aarch64. Cheers /Marcus
Re: FW: [PATCH] [MIPS] microMIPS gcc support
Moore, Catherine catherine_mo...@mentor.com writes:
Index: config/mips/mips.c
==
=
--- config/mips/mips.c (revision 195351)
+++ config/mips/mips.c (working copy)
@@ -77,6 +77,9 @@ along with GCC; see the file COPYING3. If not see
preserve the maximum stack alignment. We therefore use a value
of 0x7ff0 in this case.
+ microMIPS LWM and SWM support 12-bit offsets (from -0x800 to 0x7ff),
+ so we use a maximum of 0x7f0 for TARGET_MICROMIPS.
+
MIPS16e SAVE and RESTORE instructions can adjust the stack pointer by
up to 0x7f8 bytes and can usually save or restore all the registers
that we need to save or restore. (Note that we can only use these
@@ -87,7 +90,8 @@ along with GCC; see the file COPYING3. If not see
to save and restore registers, and to allocate and deallocate the top
part of the frame. */
#define MIPS_MAX_FIRST_STACK_STEP
\
- (!TARGET_MIPS16 ? 0x7ff0
\
+ ((!TARGET_MIPS16 !TARGET_MICROMIPS) ? 0x7ff0
\
+ : TARGET_MICROMIPS ? 0x7f0
\
: GENERATE_MIPS16E_SAVE_RESTORE ? 0x7f8
\
: TARGET_64BIT ? 0x100 : 0x400)
I'd prefer:
(TARGET_MICROMIPS ? 0x7f0 \
: !TARGET_MIPS16 ? 0x7ff0 \
: GENERATE_MIPS16E_SAVE_RESTORE ? 0x7f8 \
: TARGET_64BIT ? 0x100 : 0x400)
Thanks for doing this, but...
The comment doesn't really explain the reason for 0x7f0 rather than 0x7f8.
Is this in anticipation of future n32 and n64 support, where the stack must
be
16-byte aligned? If so, that's OK, but worth mentioning.
...it looks like you haven't addressed this part. What I mean is:
the stack alignment is 8 bytes rather than 16 bytes on 32-bit ABIs,
so I would have expected 0x7f8 rather than 0x7f0, as for the MIPS16
case quoted above. I wasn't sure why you went for 0x7f0 instead.
I'm not saying it must be 0x7f8, just that the comment ought to give
the reason for using 0x7f0 instead.
+; For movep
+(define_peephole2
+ [(set (match_operand:MOVEP1 0 register_operand )
+(match_operand:MOVEP1 1 movep_operand ))
+ (set (match_operand:MOVEP2 2 register_operand )
+(match_operand:MOVEP2 3 movep_operand ))]
+ TARGET_MICROMIPS
+umips_movep_target_p (operands[0], operands[2])
+ [(parallel [(set (match_dup 0) (match_dup 1))
+ (set (match_dup 2) (match_dup 3))])]
+)
Probably not worth having movep_operand, because all the checking is done
by umips_movep_target_p. reg_or_0_operand should be OK.
The source and target register criteria are not identical. I've now
renamed the movep_operand predicate to movep_src_operand.
Ah, yeah, sorry.
+ /* If DECL is nocompression set the nomips16 and
+ nomicromips attributes. */
+ if (nocompression_p MASK_MIPS16
+ nocompression_p MASK_MICROMIPS)
+ {
+name = nomips16;
+*attributes = tree_cons (get_identifier (name), NULL, *attributes);
+name = nomicromips;
+*attributes = tree_cons (get_identifier (name), NULL, *attributes);
+ }
Hmm, why is this necessary? Anything that cares should be using
mips_get_compress_off_flags.
It looks like you haven't addressed this part. Why do we need to add
tree-level nomips16 and nomicromips attributes to a function that
has nocompression?
+ addr.type == ADDRESS_REG
+ CONST_INT_P (addr.offset)
+ UMIPS_12BIT_OFFSET_P (addr.offset));
Isn't there a missing INTVAL here? Please check the patch to make sure
there are no compiler warnings.
This too. The point is that addr.offset is an rtx, while UMIPS_12BIT_OFFSET_P
takes a HOST_WIDE_INT:
#define UMIPS_12BIT_OFFSET_P(OFFSET) (IN_RANGE (OFFSET, -2048, 2047))
So you're comparing an rtx pointer against [-2048, 2047], rather than
the integer that the rtx contains.
As it stands, I don't see how umips_12bit_offset_address_p would ever
return true on normal hosts. That in turn should mean that ZC and ZD
never accept anything for microMIPS, so I would have expected this to
show up as a reload failure during the microMIPS testsuite run.
Please add tests that ZC and ZD work for microMIPS. E.g. the ZC
one could be something like:
MICROMIPS void
foo (int *x)
{
asm volatile (insn1\t%0 :: ZC (x[0]));
asm volatile (insn2\t%0 :: ZC (x[511]));
asm volatile (insn3\t%0 :: ZC (x[512]));
}
/* { dg-final { scan-assembler \tinsn1\t0\\( } } */
/* { dg-final { scan-assembler \tinsn2\t2044\\( } } */
/* { dg-final { scan-assembler-not \tinsn3\t2048\\( } } */
Completely untested :-) Similar idea for ZD.
+@item -minterlink-compressed
+@item -mno-interlink-compressed
+@item -minterlink-uncompressed
+@item -mno-interlink-uncompressed
+@opindex minterlink-compressed
+@opindex
[PATCH] Fix PR56295, part 2
This fixes part 2 of PR56295, it un-does MEM_REF wrapping on the
writer side. Otherwise code-generation differences at compile-time
appear -flto vs. -fno-lto (with fat LTO objects).
LTO bootstrap regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-02-13 Richard Biener rguent...@suse.de
PR lto/56295
* gimple-streamer-out.c (output_gimple_stmt): Undo wrapping
globals in MEM_REFs.
Index: gcc/gimple-streamer-out.c
===
*** gcc/gimple-streamer-out.c (revision 195997)
--- gcc/gimple-streamer-out.c (working copy)
*** output_gimple_stmt (struct output_block
*** 116,128
for (i = 0; i gimple_num_ops (stmt); i++)
{
tree op = gimple_op (stmt, i);
/* Wrap all uses of non-automatic variables inside MEM_REFs
so that we do not have to deal with type mismatches on
merged symbols during IL read in. The first operand
of GIMPLE_DEBUG must be a decl, not MEM_REF, though. */
if (op (i || !is_gimple_debug (stmt)))
{
! tree *basep = op;
while (handled_component_p (*basep))
basep = TREE_OPERAND (*basep, 0);
if (TREE_CODE (*basep) == VAR_DECL
--- 116,129
for (i = 0; i gimple_num_ops (stmt); i++)
{
tree op = gimple_op (stmt, i);
+ tree *basep = NULL;
/* Wrap all uses of non-automatic variables inside MEM_REFs
so that we do not have to deal with type mismatches on
merged symbols during IL read in. The first operand
of GIMPLE_DEBUG must be a decl, not MEM_REF, though. */
if (op (i || !is_gimple_debug (stmt)))
{
! basep = op;
while (handled_component_p (*basep))
basep = TREE_OPERAND (*basep, 0);
if (TREE_CODE (*basep) == VAR_DECL
*** output_gimple_stmt (struct output_block
*** 136,143
--- 137,149
(TREE_TYPE (*basep)), 0));
TREE_THIS_VOLATILE (*basep) = volatilep;
}
+ else
+ basep = NULL;
}
stream_write_tree (ob, op, true);
+ /* Restore the original base if we wrapped it inside a MEM_REF. */
+ if (basep)
+ *basep = TREE_OPERAND (TREE_OPERAND (*basep, 0), 0);
}
if (is_gimple_call (stmt))
{
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 11:32:00AM +0100, Jakub Jelinek wrote: On Wed, Feb 13, 2013 at 02:28:25PM +0400, Konstantin Serebryany wrote: Right. In LLVM we test only with ASAN_FLEXIBLE_MAPPING_AND_OFFSET==1, so this came unnoticed. Fixed in r175049. ... This is ok, thanks. Unfortunately, it seems everything fails with that change :( on Linux. The problem is that the default prelink library range for x86_64 is 0x30LL to 0x40LL, and that unfortunately overlaps with the 0x7fff8000LL to 0x10007fff8000LL range that asan wants to use for the shadow mapping. And the reason for that prelink default range is that earlier (see e.g. http://lwn.net/Articles/106177/ ) Linux on x86_64 used much smaller virtual address space than it does now. Not sure if there are still systems running pre-2.6.9 kernels or whenever the PML4 change made it into Linux kernel on x86-64 and whether people use prelink on them. But in any case, even if I change the prelink range now (perhaps conditionally on the size of address space detected by prelink), it will still cause issues. So, either we need to revert that i386.c and asan_mapping.h (SHADOW_OFFSET) change, or support non-contiguous shadow memory for the Linux x86-64 case. What could work is if we had: 0x - 0x7fff8000 low memory 0x7fff8000 - 0x8fff7000 shadow mem for low memory 0x8fff7000 - 0x00067fff8000 protected 0x00067fff8000 - 0x00087fff8000 shadow mem for mid memory 0x00087fff8000 - 0x0030 protected 0x0030 - 0x0040 mid memory 0x0040 - 0x02008fff7000 protected 0x02008fff7000 - 0x10007fff8000 shadow mem for high memory 0x10007fff8000 - 0x7fff high memory asan_mapping.h then would need to introduce AddrIsInMidMem and AddrIsInMidShadow inlines (perhaps defined to false for configurations that don't need 3 part memory), use those in AddrIsInMem and AddrIsInShadow, tweak AddrIsInShadowGap (as it has now more gaps) for this configuration and tweak the mapping code. Jakub
[PATCH] Fix PR50494
This should fix PR50494 - when we gimplify a local initializer
via a block copy and emit a constant to the constant pool we
stream the representative VAR_DECL with LTO, including its
eventually changed alignment. When we then lookup RTL for this
constant at
/* If this variable belongs to the global constant pool, retrieve the
pre-computed RTL or recompute it in LTO mode. */
if (TREE_CODE (decl) == VAR_DECL DECL_IN_CONSTANT_POOL (decl))
{
SET_DECL_RTL (decl, output_constant_def (DECL_INITIAL (decl), 1));
return;
we create yet another VAR_DECL for the constant representation.
But we ignore the alignment of the originally used representative
and instead use default alignment. This breaks on powerpc
where the vectorizer increases alignment of such a representative
VAR_DECL coming from LTO (and thus not yet registered with the
constant output machinery), as the generated constant will not
have that increased alignment.
The fix should be to never create a new VAR_DECL for the
constant representation in the above path but re-use 'decl'
which has whatever alignment it has.
LTO bootstrap and regtest on x86_64-unknown-linux-gnu running
(not sure if this will excercise this a lot), I'm waiting for
ppc folks to confirm the bug is gone with the patch.
Eric, does this look correct?
Thanks,
Richard.
2013-02-13 Richard Biener rguent...@suse.de
PR lto/50494
* varasm.c (output_constant_def_1): Get the decl representing
the constant as argument.
(output_constant_def): Wrap output_constant_def_1.
(make_decl_rtl): Use output_constant_def_1 with the decl
representing the constant.
(build_constant_desc): Optionally re-use a decl already
representing the constant.
(tree_output_constant_def): Adjust.
Index: gcc/varasm.c
===
*** gcc/varasm.c(revision 195997)
--- gcc/varasm.c(working copy)
*** static void asm_output_aligned_bss (FILE
*** 126,131
--- 126,132
#endif /* BSS_SECTION_ASM_OP */
static void mark_weak (tree);
static void output_constant_pool (const char *, tree);
+ static rtx output_constant_def_1 (tree, tree, int);
/* Well-known sections, each one associated with some sort of *_ASM_OP. */
section *text_section;
*** make_decl_rtl (tree decl)
*** 1186,1192
pre-computed RTL or recompute it in LTO mode. */
if (TREE_CODE (decl) == VAR_DECL DECL_IN_CONSTANT_POOL (decl))
{
! SET_DECL_RTL (decl, output_constant_def (DECL_INITIAL (decl), 1));
return;
}
--- 1187,1194
pre-computed RTL or recompute it in LTO mode. */
if (TREE_CODE (decl) == VAR_DECL DECL_IN_CONSTANT_POOL (decl))
{
! SET_DECL_RTL (decl, output_constant_def_1 (DECL_INITIAL (decl),
!decl, 1));
return;
}
*** get_constant_size (tree exp)
*** 3073,3088
Make a constant descriptor to enter EXP in the hash table.
Assign the label number and construct RTL to refer to the
constant's location in memory.
Caller is responsible for updating the hash table. */
static struct constant_descriptor_tree *
! build_constant_desc (tree exp)
{
struct constant_descriptor_tree *desc;
rtx symbol, rtl;
char label[256];
int labelno;
- tree decl;
desc = ggc_alloc_constant_descriptor_tree ();
desc-value = copy_constant (exp);
--- 3075,3090
Make a constant descriptor to enter EXP in the hash table.
Assign the label number and construct RTL to refer to the
constant's location in memory.
+If DECL is non-NULL use it as VAR_DECL associated with the constant.
Caller is responsible for updating the hash table. */
static struct constant_descriptor_tree *
! build_constant_desc (tree exp, tree decl)
{
struct constant_descriptor_tree *desc;
rtx symbol, rtl;
char label[256];
int labelno;
desc = ggc_alloc_constant_descriptor_tree ();
desc-value = copy_constant (exp);
*** build_constant_desc (tree exp)
*** 3096,3123
ASM_GENERATE_INTERNAL_LABEL (label, LC, labelno);
/* Construct the VAR_DECL associated with the constant. */
! decl = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifier (label),
!TREE_TYPE (exp));
! DECL_ARTIFICIAL (decl) = 1;
! DECL_IGNORED_P (decl) = 1;
! TREE_READONLY (decl) = 1;
! TREE_STATIC (decl) = 1;
! TREE_ADDRESSABLE (decl) = 1;
! /* We don't set the RTL yet as this would cause varpool to assume that the
! variable is referenced. Moreover, it would just be dropped in LTO mode.
! Instead we set the flag that will be recognized in make_decl_rtl. */
! DECL_IN_CONSTANT_POOL (decl) = 1;
! DECL_INITIAL (decl) = desc-value;
! /* ??? CONSTANT_ALIGNMENT hasn't been updated for vector types on most
!
[Patch, Fortran, Committed] PR testsuite/56082 / PR fortran/56304 (libquad) Test-case fixes
I have committed a fix for PR 56082, where the test case assumed that C_Bool is a byte wide (kind=1); however, on 32bit Darwin, C_Bool is by default an int (kind=4) – hence, a warning is not printed. The change was to use logical(kind=2) for the example, assuming C_Bool is never kind=2. Committed as http://gcc.gnu.org/viewcvs?view=revisionrevision=195984 For PR 56204, the test case assumed that I/O uses by default the same rounding for input and output. That worked well, except on Solaris – well, using an epsilon criterion is also fine. Patched by the attached patch. (Committed as Rev. 196011.) Tobias Index: ChangeLog === --- ChangeLog (Revision 196010) +++ ChangeLog (Arbeitskopie) @@ -1,3 +1,10 @@ +2013-02-13 Tobias Burnus bur...@net-b.de + Rainer Orth r...@cebitec.uni-bielefeld.de + + PR fortran/56204 + * gfortran.dg/quad_2.f90: Use epsilon instead of ==. + * gfortran.dg/quad_3.f90: Ditto. + 2013-02-13 Kostya Serebryany k...@google.com * c-c++-common/asan/strncpy-overflow-1.c: Update the test @@ -20,7 +27,7 @@ 2013-02-12 Dominique d'Humieres domi...@lps.ens.fr Tobias Burnus bur...@net-b.de - PR fortran/56082 + PR testsuite/56082 * gfortran.dg/bind_c_bool_1.f90 (sub): Change kind=4 to kind=2. Index: gfortran.dg/quad_2.f90 === --- gfortran.dg/quad_2.f90 (Revision 196010) +++ gfortran.dg/quad_2.f90 (Arbeitskopie) @@ -31,9 +31,9 @@ read (str2, *) fp3 if (fp1 /= fp3) call abort() read (str3, *) fp4 - if (fp2 /= fp4) call abort() + if (abs (fp2 - fp4)/fp2 epsilon(fp2)) call abort() read (str4, *) fp4 - if (fp2 /= fp4) call abort() + if (abs (fp2 - fp4)/fp2 epsilon(fp2)) call abort() select case (qp) case (8) Index: gfortran.dg/quad_3.f90 === --- gfortran.dg/quad_3.f90 (Revision 196010) +++ gfortran.dg/quad_3.f90 (Arbeitskopie) @@ -25,6 +25,7 @@ read (tmp, *) a, c ! print *, 'same value read again: ', a, c ! print *, 'difference: looks OK now ', a-b(1) - if (a-b(1) /= 0.0_qp .or. c-b(1) /= 0.0_qp) call abort() + if (abs (a-b(1))/a epsilon(0.0_qp) + .or. abs (c-b(1))/c epsilon (0.0_qp)) call abort() end if end program test_qp
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 3:59 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Feb 13, 2013 at 11:32:00AM +0100, Jakub Jelinek wrote: On Wed, Feb 13, 2013 at 02:28:25PM +0400, Konstantin Serebryany wrote: Right. In LLVM we test only with ASAN_FLEXIBLE_MAPPING_AND_OFFSET==1, so this came unnoticed. Fixed in r175049. ... This is ok, thanks. Unfortunately, it seems everything fails with that change :( on Linux. The problem is that the default prelink library range for x86_64 is 0x30LL to 0x40LL, and that unfortunately overlaps Forgive my ignorance, what is the default prelink library range? with the 0x7fff8000LL to 0x10007fff8000LL range that asan wants to use for the shadow mapping. And the reason for that prelink default range is that earlier (see e.g. http://lwn.net/Articles/106177/ ) Linux on x86_64 used much smaller virtual address space than it does now. Not sure if there are still systems running pre-2.6.9 kernels or whenever the PML4 change made it into Linux kernel on x86-64 and whether people use prelink on them. But in any case, even if I change the prelink range now (perhaps conditionally on the size of address space detected by prelink), it will still cause issues. So, either we need to revert that i386.c and asan_mapping.h (SHADOW_OFFSET) change, or support non-contiguous shadow memory for the Linux x86-64 case. I suggest to either revert or (better) to support flexible mapping and revert the offset only in the gcc compiler module (leaving asan-rt unchanged). non-contiguous shadow memory sounds too scary and costly to support, not worth the benefit. What could work is if we had: 0x - 0x7fff8000 low memory 0x7fff8000 - 0x8fff7000 shadow mem for low memory 0x8fff7000 - 0x00067fff8000 protected 0x00067fff8000 - 0x00087fff8000 shadow mem for mid memory 0x00087fff8000 - 0x0030 protected 0x0030 - 0x0040 mid memory 0x0040 - 0x02008fff7000 protected 0x02008fff7000 - 0x10007fff8000 shadow mem for high memory 0x10007fff8000 - 0x7fff high memory asan_mapping.h then would need to introduce AddrIsInMidMem and AddrIsInMidShadow inlines (perhaps defined to false for configurations that don't need 3 part memory), use those in AddrIsInMem and AddrIsInShadow, tweak AddrIsInShadowGap (as it has now more gaps) for this configuration and tweak the mapping code. Jakub
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote: Unfortunately, it seems everything fails with that change :( on Linux. The problem is that the default prelink library range for x86_64 is 0x30LL to 0x40LL, and that unfortunately overlaps Forgive my ignorance, what is the default prelink library range? Prelink is a program of mine (see e.g. http://people.redhat.com/jakub/prelink.pdf ) that speeds up dynamic linking of programs. It is used by default on various Linux distributions. prelinked shared libraries (and dynamic linker) have their base addresses chosen by the prelink program (and, by default in the default range of shared libraries for the architecture, which is 0x30LL to 0x40LL for x86_64). The addresses are usually (depending on prelink options) randomized upon prelinking, so different hosts use different addresses and the same host even after a while uses different addresses too, but by default for a few weeks, if say glibc isn't upgraded in between, you get the same addresses for the libraries all the time. So, you get something like: cat /proc/self/maps 0040-0040b000 r-xp 08:02 1201920 /usr/bin/cat 0060a000-0060b000 r--p a000 08:02 1201920 /usr/bin/cat 0060b000-0060c000 rw-p b000 08:02 1201920 /usr/bin/cat 01431000-01452000 rw-p 00:00 0 [heap] 3fe940-3fe942 r-xp 08:02 1179965 /usr/lib64/ld-2.15.so 3fe961f000-3fe962 r--p 0001f000 08:02 1179965 /usr/lib64/ld-2.15.so 3fe962-3fe9621000 rw-p 0002 08:02 1179965 /usr/lib64/ld-2.15.so 3fe9621000-3fe9622000 rw-p 00:00 0 3fe980-3fe99ac000 r-xp 08:02 1180697 /usr/lib64/libc-2.15.so 3fe99ac000-3fe9bac000 ---p 001ac000 08:02 1180697 /usr/lib64/libc-2.15.so 3fe9bac000-3fe9bb r--p 001ac000 08:02 1180697 /usr/lib64/libc-2.15.so 3fe9bb-3fe9bb2000 rw-p 001b 08:02 1180697 /usr/lib64/libc-2.15.so 3fe9bb2000-3fe9bb7000 rw-p 00:00 0 7fae406f5000-7fae46b22000 r--p 08:02 1215605 /usr/lib/locale/locale-archive 7fae46b22000-7fae46b25000 rw-p 00:00 0 7fae46b42000-7fae46b43000 rw-p 00:00 0 7fffe04f7000-7fffe0518000 rw-p 00:00 0 [stack] 7fffe05e6000-7fffe05e7000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Perhaps Ubuntu doesn't enable prelink by default, but all the world isn't Ubuntu. I suggest to either revert or (better) to support flexible mapping and revert the offset only in the gcc compiler module (leaving asan-rt unchanged). I don't see how could flexible mapping help in this case, it just can't work either. The only exception are PIE binaries, which by design aren't prelinked and kernel for them disregards the prelinking of the dynamic linker, so the dynamic linker for PIEs isn't loaded at the prelink chosen address, but at some randomized address. If you try -Wl,-Ttext* with flexible mapping and use either zero base, or say 0x7fff8000, you run into the exactly same issues, wether with gcc or clang. non-contiguous shadow memory sounds too scary and costly to support, not worth the benefit. Why do you think it should be too costly? Jakub
Re: [patch][wwwdocs] gcc 4.8 changes - AMD new cores
Le 13/02/2013 09:32, Gopalasubramanian, Ganesh a écrit : +liSupport for new AMD family 16h processors (Jaguar core) is now available + through code-march=btver2/code and code-mtune=btver2/code options./li s/btver2/bdver2/ ?
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote: Unfortunately, it seems everything fails with that change :( on Linux. The problem is that the default prelink library range for x86_64 is 0x30LL to 0x40LL, and that unfortunately overlaps Forgive my ignorance, what is the default prelink library range? Prelink is a program of mine (see e.g. http://people.redhat.com/jakub/prelink.pdf ) that speeds up dynamic linking of programs. It is used by default on various Linux distributions. Can it be disabled somehow (for asan)? prelinked shared libraries (and dynamic linker) have their base addresses chosen by the prelink program (and, by default in the default range of shared libraries for the architecture, which is 0x30LL to 0x40LL for x86_64). The addresses are usually (depending on prelink options) randomized upon prelinking, so different hosts use different addresses and the same host even after a while uses different addresses too, but by default for a few weeks, if say glibc isn't upgraded in between, you get the same addresses for the libraries all the time. So, you get something like: cat /proc/self/maps 0040-0040b000 r-xp 08:02 1201920 /usr/bin/cat 0060a000-0060b000 r--p a000 08:02 1201920 /usr/bin/cat 0060b000-0060c000 rw-p b000 08:02 1201920 /usr/bin/cat 01431000-01452000 rw-p 00:00 0 [heap] 3fe940-3fe942 r-xp 08:02 1179965 /usr/lib64/ld-2.15.so 3fe961f000-3fe962 r--p 0001f000 08:02 1179965 /usr/lib64/ld-2.15.so 3fe962-3fe9621000 rw-p 0002 08:02 1179965 /usr/lib64/ld-2.15.so 3fe9621000-3fe9622000 rw-p 00:00 0 3fe980-3fe99ac000 r-xp 08:02 1180697 /usr/lib64/libc-2.15.so 3fe99ac000-3fe9bac000 ---p 001ac000 08:02 1180697 /usr/lib64/libc-2.15.so 3fe9bac000-3fe9bb r--p 001ac000 08:02 1180697 /usr/lib64/libc-2.15.so 3fe9bb-3fe9bb2000 rw-p 001b 08:02 1180697 /usr/lib64/libc-2.15.so 3fe9bb2000-3fe9bb7000 rw-p 00:00 0 7fae406f5000-7fae46b22000 r--p 08:02 1215605 /usr/lib/locale/locale-archive 7fae46b22000-7fae46b25000 rw-p 00:00 0 7fae46b42000-7fae46b43000 rw-p 00:00 0 7fffe04f7000-7fffe0518000 rw-p 00:00 0 [stack] 7fffe05e6000-7fffe05e7000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Perhaps Ubuntu doesn't enable prelink by default, but all the world isn't Ubuntu. I suggest to either revert or (better) to support flexible mapping and revert the offset only in the gcc compiler module (leaving asan-rt unchanged). I don't see how could flexible mapping help in this case, it just can't work either. If we enabled flexible mapping in the gcc build (making it more similar to the llvm build) we will be able to use the old 2^44 offset w/o changing the asan-rt. The only exception are PIE binaries, which by design aren't prelinked and kernel for them disregards the prelinking of the dynamic linker, so the dynamic linker for PIEs isn't loaded at the prelink chosen address, but at some randomized address. If you try -Wl,-Ttext* with flexible mapping and use either zero base, or say 0x7fff8000, you run into the exactly same issues, wether with gcc or clang. non-contiguous shadow memory sounds too scary and costly to support, not worth the benefit. Why do you think it should be too costly? That's yet another set of spaghetti ifdefs. I'd rather revert the whole thing back to 2^44 than do that. --kcc
Re: [patch][wwwdocs] gcc 4.8 changes - AMD new cores
On Wed, Feb 13, 2013 at 1:55 PM, Mikael Morin mikael.mo...@sfr.fr wrote: Le 13/02/2013 09:32, Gopalasubramanian, Ganesh a écrit : +liSupport for new AMD family 16h processors (Jaguar core) is now available + through code-march=btver2/code and code-mtune=btver2/code options./li s/btver2/bdver2/ ? Of course not. Next they'll add blver ... Richard.
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 04:57:30PM +0400, Konstantin Serebryany wrote: On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote: Unfortunately, it seems everything fails with that change :( on Linux. The problem is that the default prelink library range for x86_64 is 0x30LL to 0x40LL, and that unfortunately overlaps Forgive my ignorance, what is the default prelink library range? Prelink is a program of mine (see e.g. http://people.redhat.com/jakub/prelink.pdf ) that speeds up dynamic linking of programs. It is used by default on various Linux distributions. Can it be disabled somehow (for asan)? No. You can disable it for the whole system (prelink -ua), but that is not a sane requirement to running sanitized programs. There is also LD_USE_LOAD_BIAS=0 env variable, but 1) that has to be set before running the program, setting it from within libasan ctor is too late, and more importantly 2) it still doesn't affect the mapping of the dynamic linker. So, with LD_USE_LOAD_BIAS=0 cat /proc/self/maps the dynamic linker will be still mapped somewhere in the 0x30 to 0x40 range, just other shared libraries mapped in by the dynamic linker, rather than kernel directly, will be placed at the randomized (and usually high) addresses, typically 0x7fXX. If we enabled flexible mapping in the gcc build (making it more similar to the llvm build) we will be able to use the old 2^44 offset w/o changing the asan-rt. Sure, but it will be then slower, I thought you are looking for ASAN speed improvements. That's yet another set of spaghetti ifdefs. I'd rather revert the whole thing back to 2^44 than do that. Please revert the two hunks now. I'll try to implement it eventually and try to convince you ;) Jakub
Re: [patch][wwwdocs] gcc 4.8 changes - AMD new cores
Le 13/02/2013 14:00, Richard Biener a écrit : Of course not. Next they'll add blver ... Sorry
[AArch64-4.7] Backport: Implement section anchors
Hi,
This patch is a backport of the section anchors support introduced
to aarch64-branch here:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00384.html
The patch has been tested for aarch64-none-elf with only a known
regression, fixed by backporting this patch by Andrew Pinski:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00580.html
Is this OK to commit to aarch64-4.7-branch?
Thanks,
James Greenhalgh
---
gcc/
2013-02-13 James Greenhalgh james.greenha...@arm.com
Backport from aarch64-branch.
2012-09-06 James Greenhalgh james.greenha...@arm.com
Richard Earnshaw rearn...@arm.com
* common/config/aarch64/aarch64-common.c
(aarch_option_optimization_table): New.
(TARGET_OPTION_OPTIMIZATION_TABLE): Define.
* gcc/config/aarch64/aarch64-elf.h (ASM_OUTPUT_DEF): New definition.
* gcc/config/aarch64/aarch64.c (TARGET_MIN_ANCHOR_OFFSET): Define.
(TARGET_MAX_ANCHOR_OFFSET): Likewise.
diff --git a/gcc/common/config/aarch64/aarch64-common.c b/gcc/common/config/aarch64/aarch64-common.c
index df72406..bd249e1 100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -36,6 +36,17 @@
#undef TARGET_HANDLE_OPTION
#define TARGET_HANDLE_OPTION aarch64_handle_option
+#undef TARGET_OPTION_OPTIMIZATION_TABLE
+#define TARGET_OPTION_OPTIMIZATION_TABLE aarch_option_optimization_table
+
+/* Set default optimization options. */
+static const struct default_options aarch_option_optimization_table[] =
+ {
+/* Enable section anchors by default at -O1 or higher. */
+{ OPT_LEVELS_1_PLUS, OPT_fsection_anchors, NULL, 1 },
+{ OPT_LEVELS_NONE, 0, NULL, 0 }
+ };
+
/* Implement TARGET_HANDLE_OPTION.
This function handles the target specific options for CPU/target selection.
diff --git a/gcc/config/aarch64/aarch64-elf.h b/gcc/config/aarch64/aarch64-elf.h
index 6d8b933..1c021d0 100644
--- a/gcc/config/aarch64/aarch64-elf.h
+++ b/gcc/config/aarch64/aarch64-elf.h
@@ -25,6 +25,15 @@
#define ASM_OUTPUT_LABELREF(FILE, NAME) \
aarch64_asm_output_labelref (FILE, NAME)
+#define ASM_OUTPUT_DEF(FILE, NAME1, NAME2) \
+ do \
+{ \
+ assemble_name (FILE, NAME1); \
+ fputs ( = , FILE); \
+ assemble_name (FILE, NAME2); \
+ fputc ('\n', FILE); \
+} while (0)
+
#define TEXT_SECTION_ASM_OP \t.text
#define DATA_SECTION_ASM_OP \t.data
#define BSS_SECTION_ASM_OP \t.bss
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 1e546cc..ed5b6bb 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -7950,6 +7950,17 @@ aarch64_vectorize_vec_perm_const_ok (enum machine_mode vmode,
#define TARGET_VECTORIZE_VEC_PERM_CONST_OK \
aarch64_vectorize_vec_perm_const_ok
+/* Section anchor support. */
+
+#undef TARGET_MIN_ANCHOR_OFFSET
+#define TARGET_MIN_ANCHOR_OFFSET -256
+
+/* Limit the maximum anchor offset to 4k-1, since that's the limit for a
+ byte offset; we can do much more for larger data types, but have no way
+ to determine the size of the access. We assume accesses are aligned. */
+#undef TARGET_MAX_ANCHOR_OFFSET
+#define TARGET_MAX_ANCHOR_OFFSET 4095
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include gt-aarch64.h
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 2:07 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Feb 13, 2013 at 04:57:30PM +0400, Konstantin Serebryany wrote: On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote: Unfortunately, it seems everything fails with that change :( on Linux. The problem is that the default prelink library range for x86_64 is 0x30LL to 0x40LL, and that unfortunately overlaps Forgive my ignorance, what is the default prelink library range? Prelink is a program of mine (see e.g. http://people.redhat.com/jakub/prelink.pdf ) that speeds up dynamic linking of programs. It is used by default on various Linux distributions. Can it be disabled somehow (for asan)? No. You can disable it for the whole system (prelink -ua), but that is not a sane requirement to running sanitized programs. There is also LD_USE_LOAD_BIAS=0 env variable, but 1) that has to be set before running the program, setting it from within libasan ctor is too late, and more importantly 2) it still doesn't affect the mapping of the dynamic linker. So, with LD_USE_LOAD_BIAS=0 cat /proc/self/maps the dynamic linker will be still mapped somewhere in the 0x30 to 0x40 range, just other shared libraries mapped in by the dynamic linker, rather than kernel directly, will be placed at the randomized (and usually high) addresses, typically 0x7fXX. ASAN could set an ELF flag on the executable to tell the kernel not to use prelinked objects? That is, similar to how we handle executable stacks? Richard. If we enabled flexible mapping in the gcc build (making it more similar to the llvm build) we will be able to use the old 2^44 offset w/o changing the asan-rt. Sure, but it will be then slower, I thought you are looking for ASAN speed improvements. That's yet another set of spaghetti ifdefs. I'd rather revert the whole thing back to 2^44 than do that. Please revert the two hunks now. I'll try to implement it eventually and try to convince you ;) Jakub
Re: [AArch64-4.7] Backport: Implement section anchors
On 13 February 2013 13:26, James Greenhalgh james.greenha...@arm.com wrote: Hi, This patch is a backport of the section anchors support introduced to aarch64-branch here: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00384.html The patch has been tested for aarch64-none-elf with only a known regression, fixed by backporting this patch by Andrew Pinski: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00580.html Is this OK to commit to aarch64-4.7-branch? Yes. /Marcus
[AArch64-4.7] Backport: Fix g++.dg/abi/aarch64_guard1.C
Hi,
If we enable section anchors by default we must fix the
ABI testcase which is not expecting section anchors.
This was fixed by Andrew Pinski on trunk here:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00580.html
So we backport that fix.
I've tested this with no regressions on aarch64-none-elf.
Is this OK to commit to aarch64-4.7-branch?
Thanks,
James Greenhalgh
---
gcc/
2013-02-13 James Greenhalgh james.greenha...@arm.com
Backport from mainline.
2012-11-06 Andrew Pinski apin...@cavium.com
* g++.dg/abi/aarch64_guard1.C: Add -fno-section-anchors.
diff --git a/gcc/testsuite/g++.dg/abi/aarch64_guard1.C b/gcc/testsuite/g++.dg/abi/aarch64_guard1.C
index af82ad2..ca1778b 100644
--- a/gcc/testsuite/g++.dg/abi/aarch64_guard1.C
+++ b/gcc/testsuite/g++.dg/abi/aarch64_guard1.C
@@ -2,7 +2,7 @@
// 8-byte doubleword and that only the least significant bit is used
// for initialization guard variables.
// { dg-do compile { target aarch64*-*-* } }
-// { dg-options -O -fdump-tree-original }
+// { dg-options -O -fdump-tree-original -fno-section-anchors }
int bar();
Re: [AArch64-4.7] Backport: Fix g++.dg/abi/aarch64_guard1.C
On 13 February 2013 13:28, James Greenhalgh james.greenha...@arm.com wrote: Hi, If we enable section anchors by default we must fix the ABI testcase which is not expecting section anchors. This was fixed by Andrew Pinski on trunk here: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00580.html So we backport that fix. I've tested this with no regressions on aarch64-none-elf. Is this OK to commit to aarch64-4.7-branch? Yes gcc/ gcc/testsuite /Marcus
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 02:27:56PM +0100, Richard Biener wrote: ASAN could set an ELF flag on the executable to tell the kernel not to use prelinked objects? That is, similar to how we handle executable stacks? But we don't have such a flag right now, and what should old kernels that don't support it do with that flag? Should it be some kind of flag that causes the programs not to run at all on kernel 3.9 or whenever the flag would be handled (can be done with .note.ABI-tag section, plus some flag somewhere), or something else? In any case, that would mean changes all through the toolchain (glibc, linkers, kernel), compared to changing two files in libsanitizer/asan/ (asan_mapping.h and asan_rtl.cc I believe). Jakub
[PATCH,ARM] Peephole individual LDR/STD into LDRD/STRD
This patch defines peephole2 patterns that merge two individual LDR
instructions into LDRD instruction (resp. STR into STRD) whenever possible
using the following transformations:
* reorder two memory accesses,
* rename registers when storing two constants, and
* reorder target registers of a load when they are used by a commutative
operation.
In ARM mode only, the pair of registers IP and SP is allowed as operands in
LDRD/STRD. To handle it, this patch defines a new constraint q to be
CORE_REGS in ARM mode and GENERAL_REGS (i.e., equivalent to r) otherwise.
Note that in ARM mode q is not equivalent to rk because of the way
constraints are matched. The new constraint q is used in place of r for
DImode move between register and memory.
This is a new version of the patch posted for review a long time ago:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00914.html
All the dependencies mentioned in the previous patch have already been
upstreamed.
Compared to the previous version, the new patch
* handles both ARM and Thumb modes in the same peephole pattern,
* does not attempt to generate LDRD/STRD when optimizing for size and non of
the LDM/STM patterns match (but it would be easy to add),
* does not include scan-assembly tests specific for cortex-a15 and
cortex-a9, because they are not stable and highly sensitive to other
optimizations.
No regression on qemu for arm-none-eabi with cpu cortex-a15.
Bootstrap successful on Cortex-A15 TC2.
Spec2k results:
Performance: slight improvement in overall scores (less than 1%) in both
CINT2000 and CFP2000.
For individual benchmarks, there is a slight variation in performance,
within less than 1%, which I consider to be just noise.
Object size: there is a slight reduction in size in all the benchmarks -
overall 0.2% and at most 0.5% for individual benchmarks.
Baseline compiler is gcc r194473 from December 2012.
Compiled in thumb mode with hardfp.
Run on Cortex-A15 hardware.
Ok for gcc4.9 stage 1?
Thanks,
Greta
gcc/
2013-02-13 Greta Yorsh greta.yo...@arm.com
* config/arm/constraints.md (q): New constraint.
* config/arm/ldrdstrd.md: New file.
* config/arm/arm.md (ldrdstrd.md) New include.
(arm_movdi): Use q instead of r constraint
for double-word memory access.
(movdf_soft_insn): Likewise.
* config/arm/vfp.md (movdi_vfp): Likewise.
* config/arm/t-arm (MD_INCLUDES): Add ldrdstrd.md.
* config/arm/arm-protos.h (gen_operands_ldrd_strd): New declaration.
* config/arm/arm.c (gen_operands_ldrd_strd): New function.
(mem_ok_for_ldrd_strd): Likewise.
(output_move_double): Update assertion.
gcc/testsuite
2013-02-13 Greta Yorsh greta.yo...@arm.com
* gcc.target/arm/peep-ldrd-1.c: New test.
* gcc.target/arm/peep-strd-1.c: Likewise.diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index d942c5b..41199c1 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -118,6 +118,7 @@ extern rtx arm_gen_load_multiple (int *, int, rtx, int,
rtx, HOST_WIDE_INT *);
extern rtx arm_gen_store_multiple (int *, int, rtx, int, rtx, HOST_WIDE_INT *);
extern bool offset_ok_for_ldrd_strd (HOST_WIDE_INT);
extern bool operands_ok_ldrd_strd (rtx, rtx, rtx, HOST_WIDE_INT, bool, bool);
+extern bool gen_operands_ldrd_strd (rtx *, bool, bool, bool);
extern int arm_gen_movmemqi (rtx *);
extern enum machine_mode arm_select_cc_mode (RTX_CODE, rtx, rtx);
extern enum machine_mode arm_select_dominance_cc_mode (rtx, rtx,
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 84ce56f..423dddc 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -12288,6 +12288,277 @@ operands_ok_ldrd_strd (rtx rt, rtx rt2, rtx rn,
HOST_WIDE_INT offset,
return true;
}
+/* Helper for gen_operands_ldrd_strd. Returns true iff the memory
+ operand ADDR is an immediate offset from the base register and is
+ not volatile, in which case it sets BASE and OFFSET
+ accordingly. */
+bool
+mem_ok_for_ldrd_strd (rtx addr, rtx *base, rtx *offset)
+{
+ /* TODO: Handle more general memory operand patterns, such as
+ PRE_DEC and PRE_INC. */
+
+ /* Convert a subreg of mem into mem itself. */
+ if (GET_CODE (addr) == SUBREG)
+addr = alter_subreg (addr, true);
+
+ gcc_assert (MEM_P (addr));
+
+ /* Don't modify volatile memory accesses. */
+ if (MEM_VOLATILE_P (addr))
+return false;
+
+ *offset = const0_rtx;
+
+ addr = XEXP (addr, 0);
+ if (REG_P (addr))
+{
+ *base = addr;
+ return true;
+}
+ else if (GET_CODE (addr) == PLUS || GET_CODE (addr) == MINUS)
+{
+ *base = XEXP (addr, 0);
+ *offset = XEXP (addr, 1);
+ return (REG_P (*base) CONST_INT_P (*offset));
+}
+
+ return false;
+}
+
+#define SWAP_RTX(x,y) do { rtx tmp = x; x = y; y = tmp; } while (0)
+
+/* Called from a peephole2 to replace two word-size accesses with a
+ single LDRD/STRD instruction. Returns true iff we can generate a
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 5:07 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Feb 13, 2013 at 04:57:30PM +0400, Konstantin Serebryany wrote: On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote: Unfortunately, it seems everything fails with that change :( on Linux. The problem is that the default prelink library range for x86_64 is 0x30LL to 0x40LL, and that unfortunately overlaps Forgive my ignorance, what is the default prelink library range? Prelink is a program of mine (see e.g. http://people.redhat.com/jakub/prelink.pdf ) that speeds up dynamic linking of programs. It is used by default on various Linux distributions. Can it be disabled somehow (for asan)? No. You can disable it for the whole system (prelink -ua), but that is not a sane requirement to running sanitized programs. Why not? :) There is also LD_USE_LOAD_BIAS=0 env variable, but 1) that has to be set before running the program, setting it from within libasan ctor is too late, This we can deal with. We already setenv+reexec on Mac to solve similar issue with Mac's dynamic run-time. and more importantly 2) it still doesn't affect the mapping of the dynamic linker. So, with LD_USE_LOAD_BIAS=0 cat /proc/self/maps the dynamic linker will be still mapped somewhere in the 0x30 to 0x40 range, just other shared libraries mapped in by the dynamic linker, rather than kernel directly, will be placed at the randomized (and usually high) addresses, typically 0x7fXX. If we enabled flexible mapping in the gcc build (making it more similar to the llvm build) we will be able to use the old 2^44 offset w/o changing the asan-rt. Sure, but it will be then slower, I thought you are looking for ASAN speed improvements. Yes, and we already achieved it on ubuntu :) That's yet another set of spaghetti ifdefs. I'd rather revert the whole thing back to 2^44 than do that. Please revert the two hunks now. That's a bummer. We've already deployed Clang with the new setting and will likely not want to revert it there. If we revert the two hunks in gcc (in gcc/config/i386/i386.c and in asan_mapping.h) we will have larger inconsistency between gcc and clang variants. But if we switch to flexible mapping in gcc (will require gcc to emit the two globals) we will only need to revert gcc/config/i386/i386.c and the run-times in clang and gcc will remain the same. I'll try to implement it eventually and try to convince you ;) That's surely not hard to implement, but very hard to support. --kcc Jakub
Re: [Patch, Fortran, Committed] PR testsuite/56082 / PR fortran/56304 (libquad) Test-case fixes
Hi Tobias, since you're fixing test cases: What about PR 55852 comment 10? The test case fails because the match is too strict. $ grep iszs intrinsic_size_3.f90.003t.original integer(kind=2) iszs; iszs = (integer(kind=2)) MAX_EXPR (D.854-dim[0].ubound - D.854-dim[0].lbound) + 1, 0; You were the who committed this test case. Could you have a look? Thanks, Janus 2013/2/13 Tobias Burnus bur...@net-b.de: I have committed a fix for PR 56082, where the test case assumed that C_Bool is a byte wide (kind=1); however, on 32bit Darwin, C_Bool is by default an int (kind=4) – hence, a warning is not printed. The change was to use logical(kind=2) for the example, assuming C_Bool is never kind=2. Committed as http://gcc.gnu.org/viewcvs?view=revisionrevision=195984 For PR 56204, the test case assumed that I/O uses by default the same rounding for input and output. That worked well, except on Solaris – well, using an epsilon criterion is also fine. Patched by the attached patch. (Committed as Rev. 196011.) Tobias
C++ PATCH for c++/56135 (wrong 'this' capture)
When the only use of 'this' is implicitly by a dependent name, we don't
see the capture until instantiation time. Don't clobber its capture
list entry when we instantiate the ones seen at template definition time.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit cdcb44a750af3921d6883832892dd8cd5e2d22b4
Author: Jason Merrill ja...@redhat.com
Date: Tue Feb 12 21:47:56 2013 -0500
PR c++/56135
* pt.c (tsubst_copy_and_build): Don't forget any new
captures that arose from use of dependent names.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a3359ad..2aadd4d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14457,9 +14457,11 @@ tsubst_copy_and_build (tree t,
complete_type (type);
/* The capture list refers to closure members, so this needs to
- wait until after we finish instantiating the type. */
+ wait until after we finish instantiating the type. Also keep
+ any captures that may have been added during instantiation. */
LAMBDA_EXPR_CAPTURE_LIST (r)
- = RECUR (LAMBDA_EXPR_CAPTURE_LIST (t));
+ = chainon (RECUR (LAMBDA_EXPR_CAPTURE_LIST (t)),
+ LAMBDA_EXPR_CAPTURE_LIST (r));
LAMBDA_EXPR_THIS_CAPTURE (r) = NULL_TREE;
RETURN (build_lambda_object (r));
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this8.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this8.C
new file mode 100644
index 000..9309a44
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this8.C
@@ -0,0 +1,39 @@
+// PR c++/56135
+// { dg-do run { target c++11 } }
+
+#include functional
+
+extern C void abort() throw();
+
+struct test {
+ templatetypename T
+ std::functionvoid() broken(int x) {
+return [=] { +x; printT(); };
+ }
+
+ std::functionvoid() works0() {
+return [=] { printint(); };
+ }
+
+ templatetypename T
+ std::functionvoid() works1() {
+return [=] { printint(); };
+ }
+
+ templatetypename T
+ std::functionvoid() works2() {
+return [=] { this-printT(); };
+ }
+
+ templatetypename T
+ void print() { if (this == NULL) abort (); }
+};
+
+int main(void) {
+ test().brokenint(1)();
+ test().works0()();
+ test().works1int()();
+ test().works2int()();
+
+ return 0;
+}
C++ PATCH for c++/56155 (wrong type for enumerator)
Within the { } of an enum-specifier with a fixed underlying type, the
enumerators are supposed to have that type. A comment in
build_enumerator mentioned that requirement, but nothing actually
implemented it.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4944c862e7cd742a4d963bc50ce4ac10707d686b
Author: Jason Merrill ja...@redhat.com
Date: Tue Feb 12 22:07:34 2013 -0500
PR c++/56155
* decl.c (build_enumerator): Always convert the value to a
fixed underlying type.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 5a9ad2c..eb6c490 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -12786,15 +12786,14 @@ incremented enumerator value is too large for %long%);
does not fit, the program is ill-formed [C++0x dcl.enum]. */
if (ENUM_UNDERLYING_TYPE (enumtype)
value
- TREE_CODE (value) == INTEGER_CST
- !int_fits_type_p (value, ENUM_UNDERLYING_TYPE (enumtype)))
+ TREE_CODE (value) == INTEGER_CST)
{
- error (enumerator value %E is too large for underlying type %%T%,
- value, ENUM_UNDERLYING_TYPE (enumtype));
+ if (!int_fits_type_p (value, ENUM_UNDERLYING_TYPE (enumtype)))
+ error (enumerator value %E is too large for underlying type %%T%,
+ value, ENUM_UNDERLYING_TYPE (enumtype));
- /* Silently convert the value so that we can continue. */
- value = perform_implicit_conversion (ENUM_UNDERLYING_TYPE (enumtype),
- value, tf_none);
+ /* Convert the value to the appropriate type. */
+ value = convert (ENUM_UNDERLYING_TYPE (enumtype), value);
}
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/enum22.C b/gcc/testsuite/g++.dg/cpp0x/enum22.C
new file mode 100644
index 000..e87a31c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/enum22.C
@@ -0,0 +1,12 @@
+// PR c++/56155
+// { dg-do compile { target c++11 } }
+
+enum e_ : unsigned char { Z_, E_=sizeof(Z_) };
+static_assert( E_ == 1, E_ should be 1);
+
+template class T
+struct A {
+ enum e_ : unsigned char { Z_, E_=sizeof(Z_) };
+};
+
+static_assert ( Adouble::E_ == 1, E_ should be 1);
C++ PATCH for c++/55993 (wrong error with constexpr)
When we added empty base handling to the ADDR_EXPR case in
cxx_fold_indirect_ref, we forgot to add it to the POINTER_PLUS_EXPR case
as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit ed30015624f7d3f396e11fd5d96b548348a74688
Author: Jason Merrill ja...@redhat.com
Date: Tue Feb 12 23:12:10 2013 -0500
PR c++/55993
* semantics.c (cxx_fold_indirect_ref): Handle empty bases at
non-zero offsets, too.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index e31ae30..59a50f2 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7440,6 +7440,15 @@ cxx_fold_indirect_ref (location_t loc, tree type, tree op0, bool *empty_base)
return build4_loc (loc, ARRAY_REF, type, op00, op01,
NULL_TREE, NULL_TREE);
}
+ /* Also handle conversion to an empty base class, which
+ is represented with a NOP_EXPR. */
+ else if (is_empty_class (type)
+ CLASS_TYPE_P (op00type)
+ DERIVED_FROM_P (type, op00type))
+ {
+ *empty_base = true;
+ return op00;
+ }
/* ((foo *)struct_with_foo_field)[1] = COMPONENT_REF */
else if (RECORD_OR_UNION_TYPE_P (op00type))
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-empty6.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-empty6.C
new file mode 100644
index 000..be9a6c6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-empty6.C
@@ -0,0 +1,11 @@
+// PR c++/55993
+// { dg-do compile { target c++11 } }
+
+struct A {};
+struct B:A {};
+struct C:A {};
+struct D:B,C {};
+
+constexpr D d {};
+constexpr const C e=d; // OK
+constexpr auto f=static_castconst C(d); // FAIL
Re: RFA: v3 PATCH to add on_quick_exit/quick_exit to std
On 02/12/2013 07:55 AM, Paolo Carlini wrote: Again, the current status is in a sense good because when the _GLIBCXX_HAVE_AT_QUICK_EXIT and _GLIBCXX_HAVE_QUICK_EXIT are defined, thus the system has the functions in its c library, including cstdlib makes available the functions in namespace std irrespective of the configury. But then why having c_std in the first place? I'll leave this to Benjamin... As I understand it, the difference between c_std and c_global is supposed to be that c_std keeps the C library in std, whereas c_global has it in both std and the global namespace. All the other differences that have arisen between them seem unintended and wrong. There is, however, a question whether we need c_std at all now that the standard allows the C library to be in the global namespace as well. Jason
[Patch] Cleanup gcc.target/arm/interrupt-*.c for thumb mode
The tests gcc.target/arm/interrupt-*.c are for ARM mode only.
This patch uses effective target arm_notthumb instead of __thumb_ predefine,
removes unreachable code, and fixes typos.
Ok for trunk?
Thanks,
Greta
ChangeLog
gcc/testsuite/
2012-02-13 Greta Yorsh greta.yo...@arm.com
* gcc.target/arm/interrupt-1.c: Fix for thumb mode.
* gcc.target/arm/interrupt-2.c: Likewise.
diff --git a/gcc/testsuite/gcc.target/arm/interrupt-1.c
b/gcc/testsuite/gcc.target/arm/interrupt-1.c
index 18379de..a384242 100644
--- a/gcc/testsuite/gcc.target/arm/interrupt-1.c
+++ b/gcc/testsuite/gcc.target/arm/interrupt-1.c
@@ -1,10 +1,10 @@
/* Verify that prologue and epilogue are correct for functions with
__attribute__ ((interrupt)). */
/* { dg-do compile } */
-/* { dg-options -O0 } */
+/* { dg-require-effective-target arm_nothumb } */
+/* { dg-options -O0 -marm } */
-/* This test is not valid when -mthumb. We just cheat. */
-#ifndef __thumb__
+/* This test is not valid when -mthumb. */
extern void bar (int);
extern void foo (void) __attribute__ ((interrupt(IRQ)));
@@ -12,12 +12,6 @@ void foo ()
{
bar (0);
}
-#else
-void foo ()
-{
- asm (stmfd\tsp!, {r0, r1, r2, r3, r4, fp, ip, lr});
- asm (ldmfd\tsp!, {r0, r1, r2, r3, r4, fp, ip, pc}^);
-}
-#endif
+
/* { dg-final { scan-assembler stmfd\tsp!, {r0, r1, r2, r3, r4, fp, ip, lr}
} } */
/* { dg-final { scan-assembler ldmfd\tsp!, {r0, r1, r2, r3, r4, fp, ip,
pc}\\^ } } */
diff --git a/gcc/testsuite/gcc.target/arm/interrupt-2.c
b/gcc/testsuite/gcc.target/arm/interrupt-2.c
index b979bf1..61d3130 100644
--- a/gcc/testsuite/gcc.target/arm/interrupt-2.c
+++ b/gcc/testsuite/gcc.target/arm/interrupt-2.c
@@ -1,26 +1,19 @@
/* Verify that prologue and epilogue are correct for functions with
__attribute__ ((interrupt)). */
/* { dg-do compile } */
-/* { dg-options -O1 } */
+/* { dg-require-effective-target arm_nothumb } */
+/* { dg-options -O1 -marm } */
-/* This test is not valid when -mthum. We just cheat. */
-#ifndef __thumb__
+/* This test is not valid when -mthumb. */
extern void bar (int);
extern void test (void) __attribute__((__interrupt__));
int foo;
void test()
{
- funcptrs(foo);
+ bar (foo);
foo = 0;
}
-#else
-void test ()
-{
- asm (stmfd\tsp!, {r0, r1, r2, r3, r4, r5, ip, lr});
- asm (ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, ip, pc}^);
-}
-#endif
/* { dg-final { scan-assembler stmfd\tsp!, {r0, r1, r2, r3, r4, r5, ip, lr}
} } */
/* { dg-final { scan-assembler ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, ip,
pc}\\^ } } */
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 11:32:00AM +0100, Jakub Jelinek wrote: On Wed, Feb 13, 2013 at 02:28:25PM +0400, Konstantin Serebryany wrote: Right. In LLVM we test only with ASAN_FLEXIBLE_MAPPING_AND_OFFSET==1, so this came unnoticed. Fixed in r175049. ... This is ok, thanks. Jakub FYI, asan.exp shows no regression at -m32/-m64 on x86_64-apple-darwin12 using gcc svn at r196013. Thanks for the new allocator support on darwin. Jack
Re: RFA: v3 PATCH to add on_quick_exit/quick_exit to std
Hi, On 02/13/2013 03:38 PM, Jason Merrill wrote: On 02/12/2013 07:55 AM, Paolo Carlini wrote: Again, the current status is in a sense good because when the _GLIBCXX_HAVE_AT_QUICK_EXIT and _GLIBCXX_HAVE_QUICK_EXIT are defined, thus the system has the functions in its c library, including cstdlib makes available the functions in namespace std irrespective of the configury. But then why having c_std in the first place? I'll leave this to Benjamin... As I understand it, the difference between c_std and c_global is supposed to be that c_std keeps the C library in std, whereas c_global has it in both std and the global namespace. All the other differences that have arisen between them seem unintended and wrong. The fact is, for many, many years we didn't even try to keep the C library in std only. On the other hand the split c_std / c_global is relatively recent (was born in 4.3). Yes, I'm quite confused ;) There is, however, a question whether we need c_std at all now that the standard allows the C library to be in the global namespace as well. Indeed. We could maybe imagine do away with c_std in 4.9... Paolo.
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 05:39:15PM +0400, Konstantin Serebryany wrote:
No. You can disable it for the whole system (prelink -ua), but that is not
a sane requirement to running sanitized programs.
Why not?
:)
Because that is a fully system operation, requires root access, etc.
The fact that some user wants to test one of his programs with Asan
shouldn't need to affect other users.
This we can deal with.
We already setenv+reexec on Mac to solve similar issue with Mac's
dynamic run-time.
The reexec is problematic, what if the program already in constructors run
before __asan_init (perhaps ctors of other libraries etc.) does something
that really shouldn't be done twice?
Sure, but it will be then slower, I thought you are looking for ASAN speed
improvements.
Yes, and we already achieved it on ubuntu :)
AFAIK prelink is available even on ubuntu, perhaps not the default.
I'll try to implement it eventually and
try to convince you ;)
That's surely not hard to implement, but very hard to support.
Why?
Here is the patch, works just fine for me here during asan.exp testing.
You can very easily either install and enable prelink on one of your
x86_64-linux testing boxes, or just install it and add test that
will say prelink -r 0x36 some test shared library and then
just use it in sanitized program (that will also verify that you can mmap
libraries in that range), or even just write a test that will in a
non-instrumented ctor with lower priority than asan's priority
mmap a few pages at 0x30 and close to 0x3f
and store some data into those buffers later on in sanitized code.
--- asan_mapping.h.jj 2013-02-13 11:53:43.0 +0100
+++ asan_mapping.h 2013-02-13 16:00:22.821413836 +0100
@@ -61,13 +61,31 @@ extern SANITIZER_INTERFACE_ATTRIBUTE upt
#define kHighShadowBeg MEM_TO_SHADOW(kHighMemBeg)
#define kHighShadowEnd MEM_TO_SHADOW(kHighMemEnd)
+#if ASAN_LINUX defined(__x86_64__)
+# define kMidMemBeg(kLowMemEnd 0x30ULL ? 0x30ULL : 0)
+# define kMidMemEnd(kLowMemEnd 0x30ULL ? 0x3fULL : 0)
+# define kMidShadowBeg MEM_TO_SHADOW(kMidMemBeg)
+# define kMidShadowEnd MEM_TO_SHADOW(kMidMemEnd)
+#else
+# define kMidMemBeg0
+# define kMidMemEnd0
+# define kMidShadowBeg 0
+# define kMidShadowEnd 0
+#endif
+
// With the zero shadow base we can not actually map pages starting from 0.
// This constant is somewhat arbitrary.
#define kZeroBaseShadowStart (1 18)
#define kShadowGapBeg (kLowShadowEnd ? kLowShadowEnd + 1 \
: kZeroBaseShadowStart)
-#define kShadowGapEnd (kHighShadowBeg - 1)
+#define kShadowGapEnd ((kMidMemBeg ? kMidShadowBeg : kHighShadowBeg) - 1)
+
+#define kShadowGap2Beg (kMidMemBeg ? kMidShadowEnd + 1 : 0)
+#define kShadowGap2End (kMidMemBeg ? kMidMemBeg - 1 : 0)
+
+#define kShadowGap3Beg (kMidMemBeg ? kMidMemEnd + 1 : 0)
+#define kShadowGap3End (kMidMemBeg ? kHighShadowBeg - 1 : 0)
namespace __asan {
@@ -86,8 +104,12 @@ static inline bool AddrIsInHighMem(uptr
return a = kHighMemBeg a = kHighMemEnd;
}
+static inline bool AddrIsInMidMem(uptr a) {
+ return kMidMemBeg a = kMidMemBeg a = kMidMemEnd;
+}
+
static inline bool AddrIsInMem(uptr a) {
- return AddrIsInLowMem(a) || AddrIsInHighMem(a);
+ return AddrIsInLowMem(a) || AddrIsInMidMem(a) || AddrIsInHighMem(a);
}
static inline uptr MemToShadow(uptr p) {
@@ -99,11 +121,22 @@ static inline bool AddrIsInHighShadow(up
return a = kHighShadowBeg a = kHighMemEnd;
}
+static inline bool AddrIsInMidShadow(uptr a) {
+ return kMidMemBeg a = kMidShadowBeg a = kMidMemEnd;
+}
+
static inline bool AddrIsInShadow(uptr a) {
- return AddrIsInLowShadow(a) || AddrIsInHighShadow(a);
+ return AddrIsInLowShadow(a) || AddrIsInMidShadow(a) || AddrIsInHighShadow(a);
}
static inline bool AddrIsInShadowGap(uptr a) {
+ if (kMidMemBeg)
+{
+ if (a = kShadowGapEnd)
+ return SHADOW_OFFSET == 0 || a = kShadowGapBeg;
+ return (a = kShadowGap2Beg a = kShadowGap2End)
+|| (a = kShadowGap3Beg a = kShadowGap3End);
+}
// In zero-based shadow mode we treat addresses near zero as addresses
// in shadow gap as well.
if (SHADOW_OFFSET == 0)
--- asan_rtl.cc.jj 2013-02-13 11:53:44.0 +0100
+++ asan_rtl.cc 2013-02-13 16:00:10.815483846 +0100
@@ -35,8 +35,14 @@ static void AsanDie() {
Report(Sleeping for %d second(s)\n, flags()-sleep_before_dying);
SleepForSeconds(flags()-sleep_before_dying);
}
- if (flags()-unmap_shadow_on_exit)
-UnmapOrDie((void*)kLowShadowBeg, kHighShadowEnd - kLowShadowBeg);
+ if (flags()-unmap_shadow_on_exit) {
+if (!kMidMemBeg)
+ UnmapOrDie((void*)kLowShadowBeg, kHighShadowEnd - kLowShadowBeg);
+else {
+ UnmapOrDie((void*)kLowShadowBeg, kMidMemBeg - kLowShadowBeg);
+ UnmapOrDie((void*)kMidMemEnd, kHighShadowEnd - kMidMemEnd);
+}
+ }
if (death_callback)
death_callback();
[PATCH] For asm n and similar constraints use maybe_const_value (PR c++/56302)
Hi!
My SIZEOF_EXPR deferred folding changes regressed some sys/sdt.h macros
at -O0, the sizeof in there is no longer folded, so instead of
say n (-8) we ended up with n (-1 * (int) sizeof (void *)) and similar,
and as at -O0 we don't really optimize, the asm got rejected.
Fixed thusly, constexpr-56302.C is a bonus, something that didn't work
before but now works. Bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2013-02-13 Jakub Jelinek ja...@redhat.com
PR c++/56302
* semantics.c (finish_asm_stmt): If input constraints allow
neither register nor memory, try maybe_constant_value to get
a constant if possible.
* g++.dg/torture/pr56302.C: New test.
* g++.dg/cpp0x/constexpr-56302.C: New test.
* c-c++-common/pr56302.c: New test.
--- gcc/cp/semantics.c.jj 2013-02-12 19:02:48.0 +0100
+++ gcc/cp/semantics.c 2013-02-13 10:04:14.615998647 +0100
@@ -1402,6 +1402,14 @@ finish_asm_stmt (int volatile_p, tree st
if (!cxx_mark_addressable (operand))
operand = error_mark_node;
}
+ else if (!allows_reg !allows_mem)
+ {
+ /* If constraint allows neither register nor memory,
+try harder to get a constant. */
+ tree constop = maybe_constant_value (operand);
+ if (TREE_CONSTANT (constop))
+ operand = constop;
+ }
}
else
operand = error_mark_node;
--- gcc/testsuite/g++.dg/torture/pr56302.C.jj 2013-02-13 10:18:58.785974294
+0100
+++ gcc/testsuite/g++.dg/torture/pr56302.C 2013-02-13 10:22:19.901837358
+0100
@@ -0,0 +1,41 @@
+// PR c++/56302
+// { dg-do compile }
+
+typedef __SIZE_TYPE__ size_t;
+# define STAP_SDT_ARG_CONSTRAINTnor
+# define _SDT_STRINGIFY(x) #x
+# define _SDT_ARG_CONSTRAINT_STRING(x) _SDT_STRINGIFY(x)
+# define _SDT_ARG(n, x)\
+ [_SDT_S##n] n ((_SDT_ARGSIGNED (x) ? 1 : -1) * (int) _SDT_ARGSIZE (x)), \
+ [_SDT_A##n] _SDT_ARG_CONSTRAINT_STRING (STAP_SDT_ARG_CONSTRAINT)
(_SDT_ARGVAL (x))
+#define _SDT_ARGARRAY(x) (__builtin_classify_type (x) == 14 \
+|| __builtin_classify_type (x) == 5)
+# define _SDT_ARGSIGNED(x) (!_SDT_ARGARRAY (x) \
+ __sdt_type__typeof (x)::__sdt_signed)
+# define _SDT_ARGSIZE(x) (_SDT_ARGARRAY (x) \
+? sizeof (void *) : sizeof (x))
+# define _SDT_ARGVAL(x)(x)
+templatetypename __sdt_T
+struct __sdt_type
+{
+ static const bool __sdt_signed = false;
+};
+#define __SDT_ALWAYS_SIGNED(T) \
+template struct __sdt_typeT { static const bool __sdt_signed = true; };
+__SDT_ALWAYS_SIGNED(signed char)
+__SDT_ALWAYS_SIGNED(short)
+__SDT_ALWAYS_SIGNED(int)
+__SDT_ALWAYS_SIGNED(long)
+__SDT_ALWAYS_SIGNED(long long)
+templatetypename __sdt_E
+struct __sdt_type__sdt_E[] : public __sdt_type__sdt_E * {};
+templatetypename __sdt_E, size_t __sdt_N
+struct __sdt_type__sdt_E[__sdt_N] : public __sdt_type__sdt_E * {};
+
+struct S { char p[8]; };
+
+void
+foo (const S str)
+{
+ __asm__ __volatile__ ( : : _SDT_ARG (0, str));
+}
--- gcc/testsuite/g++.dg/cpp0x/constexpr-56302.C2012-11-17
15:43:17.572007394 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-56302.C2013-02-13
10:28:41.462666774 +0100
@@ -0,0 +1,12 @@
+// PR c++/56302
+// { dg-do compile }
+// { dg-options -std=c++11 -O0 }
+
+constexpr int foo () { return 42; }
+constexpr int x = foo () + 2;
+
+void
+bar ()
+{
+ __asm ( : : n (x), n (foo () * 7 + x));
+}
--- gcc/testsuite/c-c++-common/pr56302.c.jj 2013-02-13 10:10:42.980799956
+0100
+++ gcc/testsuite/c-c++-common/pr56302.c2013-02-13 10:11:17.906598785
+0100
@@ -0,0 +1,9 @@
+/* PR c++/56302 */
+/* { dg-do compile } */
+/* { dg-options -O0 } */
+
+void
+foo (int x)
+{
+ __asm__ __volatile__ ( : : n (-1 * (int) sizeof (x)));
+}
Jakub
[PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
Hi!
As agreed on in the PR, here is the revertion of 3 commits, so that
PCH works again for -gstabs and other debug info formats for 4.8
release. For 4.9 we should either remove support for anything non-DWARF, or
hope somebody steps up and fixes dbxout.c etc. not to emit debug info right
away, but queue it till end of compilation.
Bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested
with
make check
RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-gstabs,-m64,-m64/-gstabs} pch.exp'
Ok for trunk? I'll add reversion of this reversion to the 4.9 queued patches
PR.
2013-02-13 Jakub Jelinek ja...@redhat.com
PR pch/54117
Revert
2012-07-14 Steven Bosscher ste...@gcc.gnu.org
* toplev.c (init_asm_output): Open asm_out_file in 'w' mode.
* c-pch.c (CHECK_NO_ASM_OUT_DURING_PCH): Do not define.
Remove code conditional on it.
2012-07-01 Uros Bizjak ubiz...@gmail.com
* c-pch.c (c_common_write_pch): Remove unused variables.
2012-06-21 Steven Bosscher ste...@gcc.gnu.org
* c-common.h (c_common_print_pch_checksum): Remove.
* c-pch.c: Do not include output.h.
(CHECK_NO_ASM_OUT_DURING_PCH): Define and add FIXME.
(asm_out_file): Define iff CHECK_NO_ASM_OUT_DURING_PCH isdefined.
(asm_file_startpos): Define iff CHECK_NO_ASM_OUT_DURING_PCH is defined.
(struct c_pch_header): Remove.
(get_ident): Update gpch version.
(pch_init): Do not print executable_checksum to asm_out_file.
Do not fail if there is no asm_out_file to read back from. Set
asm_file_startpos only if CHECK_NO_ASM_OUT_DURING_PCH is defined.
(c_common_write_pch): Verify that nothing was written to asm_out_file
since pch_init was called. Do not write a c_pch_header, and do not
copy from asm_out_file to the PCH.
(c_common_read_pch): Do not read a c_pch_header, and do not restore
the content of asm_out_file from the PCH.
(c_common_print_pch_checksum): Remove.
* c-opts.c (c_common_init): Print out executable_checksum directly.
--- gcc/toplev.c.jj 2013-02-13 09:29:16.197757222 +0100
+++ gcc/toplev.c2013-02-13 11:34:38.855800182 +0100
@@ -912,7 +912,7 @@ init_asm_output (const char *name)
if (!strcmp (asm_file_name, -))
asm_out_file = stdout;
else
- asm_out_file = fopen (asm_file_name, w);
+ asm_out_file = fopen (asm_file_name, w+b);
if (asm_out_file == 0)
fatal_error (can%'t open %s for writing: %m, asm_file_name);
}
--- gcc/c-family/c-pch.c.jj 2013-02-13 09:29:16.065757956 +0100
+++ gcc/c-family/c-pch.c2013-02-13 11:34:45.552761549 +0100
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.
#include tree.h
#include flags.h
#include c-common.h
+#include output.h /* for asm_out_file */
#include debug.h
#include c-pragma.h
#include ggc.h
@@ -67,11 +68,19 @@ struct c_pch_validity
size_t target_data_length;
};
+struct c_pch_header
+{
+ unsigned long asm_size;
+};
+
#define IDENT_LENGTH 8
/* The file we'll be writing the PCH to. */
static FILE *pch_outfile;
+/* The position in the assembler output file when pch_init was called. */
+static long asm_file_startpos;
+
static const char *get_ident (void);
/* Compute an appropriate 8-byte magic number for the PCH file, so that
@@ -83,7 +92,7 @@ static const char *
get_ident (void)
{
static char result[IDENT_LENGTH];
- static const char templ[] = gpch.014;
+ static const char templ[] = gpch.013;
static const char c_language_chars[] = Co+O;
memcpy (result, templ, IDENT_LENGTH);
@@ -97,7 +106,9 @@ get_ident (void)
static bool pch_ready_to_save_cpp_state = false;
/* Prepare to write a PCH file, if one is being written. This is
- called at the start of compilation. */
+ called at the start of compilation.
+
+ Also, print out the executable checksum if -fverbose-asm is in effect. */
void
pch_init (void)
@@ -107,6 +118,15 @@ pch_init (void)
void *target_validity;
static const char partial_pch[] = gpcWrite;
+#ifdef ASM_COMMENT_START
+ if (flag_verbose_asm)
+{
+ fprintf (asm_out_file, %s , ASM_COMMENT_START);
+ c_common_print_pch_checksum (asm_out_file);
+ fputc ('\n', asm_out_file);
+}
+#endif
+
if (!pch_file)
return;
@@ -136,6 +156,14 @@ pch_init (void)
|| fwrite (target_validity, v.target_data_length, 1, f) != 1)
fatal_error (can%'t write to %s: %m, pch_file);
+ /* We need to be able to re-read the output. */
+ /* The driver always provides a valid -o option. */
+ if (asm_file_name == NULL
+ || strcmp (asm_file_name, -) == 0)
+fatal_error (%qs is not a valid output file, asm_file_name);
+
+ asm_file_startpos = ftell (asm_out_file);
+
/* Let the debugging format deal with the PCHness. */
(*debug_hooks-handle_pch) (0);
@@ -172,6 +200,11 @@ pch_cpp_save_state (void)
void
Re: [PATCH] For asm n and similar constraints use maybe_const_value (PR c++/56302)
OK.
[committed] Revert 0x7fff8000 shadow offset for now
Hi!
So that we don't keep GCC trunk in known broken state, I've
bootstrapped/regtested this change and installed it.
2013-02-13 Jakub Jelinek ja...@redhat.com
* config/i386/i386.c (ix86_asan_shadow_offset): Revert last change.
* asan/asan_mapping.h (SHADOW_OFFSET): Set to (1ULL 44) on x86-64.
--- gcc/config/i386/i386.c.jj 2013-02-13 11:53:42.0 +0100
+++ gcc/config/i386/i386.c 2013-02-13 14:15:19.670007874 +0100
@@ -5436,8 +5436,7 @@ ix86_legitimate_combined_insn (rtx insn)
static unsigned HOST_WIDE_INT
ix86_asan_shadow_offset (void)
{
- return TARGET_LP64 ? (TARGET_MACHO ? (HOST_WIDE_INT_1 44)
-: HOST_WIDE_INT_C (0x7fff8000))
+ return TARGET_LP64 ? (HOST_WIDE_INT_1 44)
: (HOST_WIDE_INT_1 29);
}
--- libsanitizer/asan/asan_mapping.h.jj 2013-02-13 11:53:43.0 +0100
+++ libsanitizer/asan/asan_mapping.h2013-02-13 14:20:34.032179688 +0100
@@ -36,11 +36,7 @@ extern SANITIZER_INTERFACE_ATTRIBUTE upt
# if defined(__powerpc64__)
#define SHADOW_OFFSET (1ULL 41)
# else
-#if ASAN_MAC
-# define SHADOW_OFFSET (1ULL 44)
-#else
-# define SHADOW_OFFSET 0x7fff8000ULL
-#endif
+#define SHADOW_OFFSET (1ULL 44)
# endif
# endif
# endif
Jakub
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 04:19:14PM +0100, Jakub Jelinek wrote: The reexec is problematic, what if the program already in constructors run before __asan_init (perhaps ctors of other libraries etc.) does something that really shouldn't be done twice? Jakub, Wouldn't sorting all of the constructors and destructors by priority, while retaining the original order, in collect2 solve this issue (as was proposed for implementing intra-modular init priority support on darwin)? Jack
C++ PATCH for c++/55879 (constexpr confusion with invisible references)
In this PR, the constexpr evaluator was confused by a parameter that
changed to a reference type after the constant expression body was saved
for later evaluation; we ended up trying to evaluate an address of an
address, since we added one address on the caller side to pass to the
invisible reference and another on the callee side to pass the value
parameter to a reference parameter. Fixed by stripping the reference on
the caller side.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 34ef3b1602847bb7e1af4b7c0eb918dcdfcfea97
Author: Jason Merrill ja...@redhat.com
Date: Wed Feb 13 00:01:52 2013 -0500
PR c++/55879
* semantics.c (cxx_bind_parameters_in_call): Undo DECL_BY_REFERENCE.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 59a50f2..7d93d72 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6512,6 +6512,15 @@ cxx_bind_parameters_in_call (const constexpr_call *old_call, tree t,
if (i == 0 DECL_CONSTRUCTOR_P (fun))
goto next;
x = get_nth_callarg (t, i);
+ if (parms DECL_BY_REFERENCE (parms))
+ {
+ /* cp_genericize made this a reference for argument passing, but
+ we don't want to treat it like one for constexpr evaluation. */
+ gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
+ gcc_assert (TREE_CODE (TREE_TYPE (x)) == REFERENCE_TYPE);
+ type = TREE_TYPE (type);
+ x = convert_from_reference (x);
+ }
arg = cxx_eval_constant_expression (old_call, x, allow_non_constant,
TREE_CODE (type) == REFERENCE_TYPE,
non_constant_p, overflow_p);
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-invisiref1.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-invisiref1.C
new file mode 100644
index 000..e0ede73
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-invisiref1.C
@@ -0,0 +1,36 @@
+// PR c++/55879
+// { dg-do compile { target c++11 } }
+
+class CAddress
+{
+public:
+ constexpr CAddress(unsigned long begin) : m_Begin(begin) {}
+ constexpr CAddress(const CAddress other) : m_Begin(other.m_Begin) {}
+
+private:
+ unsigned long m_Begin;
+};
+
+extern C char _lnkDDRRAM;
+/* internal compiler error on gcc 4.6.3 */
+const CAddress s_Memmap[2]
+{
+ {(unsigned long)_lnkDDRRAM}, /* segmentation fault */
+ {0x4000},
+};
+
+class CNested {
+public:
+ constexpr CNested(const CAddress primary)
+: m_PrimaryBlock(primary) {}
+
+private:
+ CAddress m_PrimaryBlock;
+};
+
+/* internal compiler error on gcc 4.7.2 */
+const CNested s_taskDescriptions[2]
+{
+ {{0x4200}},
+ {{0x4300}},
+};
Re: PR target/52555: attribute optimize is overriding command line options
Richard.
I made all the changes you suggested.
I also changed other instances of s/this_target_optabs/this_fn_optabs/
which I forgot in the previous iteration. And I also changed
save_optabs_if_changed() to use this_fn_optabs, since init_all_optabs()
will generate the optabs into this_fn_optabs.
Tested on x86-64 Linux.
OK?
+ PR target/52555
+ * genopinit.c (main): Use this_fn_optabs in generated
+ init_all_optabs, raw_optab_handler, and swap_optab_enable.
+ * tree.h (struct tree_optimization_option): New field
+ target_optabs.
+ (TREE_OPTIMIZATION_OPTABS): New.
+ (save_optabs_if_changed): Protoize.
+ * optabs.h: Declare this_fn_optabs.
+ * optabs.c (save_optabs_if_changed): New.
+ Declare this_fn_optabs.
+ * function.c (invoke_set_current_function_hook): Set
+ this_fn_optabs if there is one in the optimization node.
c-family/
+ PR target/52555
+ * c-common.c (handle_optimize_attribute): Call
+ save_optabs_if_changed.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 1e6afaa..3711e69 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -8925,6 +8925,8 @@ handle_optimize_attribute (tree *node, tree name, tree
args,
DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node)
= build_optimization_node ();
+ save_optabs_if_changed (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node));
+
/* Restore current options. */
cl_optimization_restore (global_options, cur_opts);
}
diff --git a/gcc/function.c b/gcc/function.c
index 4ce2259..688242a 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -4383,6 +4383,7 @@ static bool in_dummy_function;
static void
invoke_set_current_function_hook (tree fndecl)
{
+ this_fn_optabs = this_target_optabs;
if (!in_dummy_function)
{
tree opts = ((fndecl)
@@ -4397,6 +4398,11 @@ invoke_set_current_function_hook (tree fndecl)
{
optimization_current_node = opts;
cl_optimization_restore (global_options, TREE_OPTIMIZATION (opts));
+
+ /* Change optabs if needed. */
+ if (TREE_OPTIMIZATION_OPTABS (opts))
+ this_fn_optabs
+ = (struct target_optabs *) TREE_OPTIMIZATION_OPTABS (opts);
}
targetm.set_current_function (fndecl);
diff --git a/gcc/genopinit.c b/gcc/genopinit.c
index 1bb2f77..13ebdc5 100644
--- a/gcc/genopinit.c
+++ b/gcc/genopinit.c
@@ -423,7 +423,7 @@ main (int argc, char **argv)
fprintf (s_file, };\n\n);
fprintf (s_file, void\ninit_all_optabs (void)\n{\n);
- fprintf (s_file, bool *ena = this_target_optabs-pat_enable;\n);
+ fprintf (s_file, bool *ena = this_fn_optabs-pat_enable;\n);
for (i = 0; patterns.iterate (i, p); ++i)
fprintf (s_file, ena[%u] = HAVE_%s;\n, i, p-name);
fprintf (s_file, }\n\n);
@@ -456,7 +456,7 @@ main (int argc, char **argv)
raw_optab_handler (unsigned scode)\n
{\n
int i = lookup_handler (scode);\n
-return (i = 0 this_target_optabs-pat_enable[i]\n
+return (i = 0 this_fn_optabs-pat_enable[i]\n
? pats[i].icode : CODE_FOR_nothing);\n
}\n\n);
@@ -468,8 +468,8 @@ main (int argc, char **argv)
int i = lookup_handler (scode);\n
if (i = 0)\n
{\n
-bool ret = this_target_optabs-pat_enable[i];\n
-this_target_optabs-pat_enable[i] = set;\n
+bool ret = this_fn_optabs-pat_enable[i];\n
+this_fn_optabs-pat_enable[i] = set;\n
return ret;\n
}\n
else\n
diff --git a/gcc/optabs.c b/gcc/optabs.c
index c1dacf4..145930f 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3. If not see
struct target_optabs default_target_optabs;
struct target_libfuncs default_target_libfuncs;
+struct target_optabs *this_fn_optabs = default_target_optabs;
#if SWITCHABLE_TARGET
struct target_optabs *this_target_optabs = default_target_optabs;
struct target_libfuncs *this_target_libfuncs = default_target_libfuncs;
@@ -6207,6 +6208,40 @@ init_optabs (void)
targetm.init_libfuncs ();
}
+/* Recompute the optabs. If they have changed, save the new set of
+ optabs in the optimization node OPTNODE. */
+
+void
+save_optabs_if_changed (tree optnode)
+{
+ struct target_optabs *save_fn_optabs = this_fn_optabs;
+ struct target_optabs *tmp_target_optabs = XCNEW (struct target_optabs);
+
+ /* Generate a new set of optabs into tmp_target_optabs. */
+ this_fn_optabs = tmp_target_optabs;
+ init_all_optabs ();
+ this_fn_optabs = save_fn_optabs;
+
+ /* If the optabs changed, record it in the node. */
+ if (memcmp (tmp_target_optabs, default_target_optabs,
+ sizeof (struct target_optabs)))
+{
+ /* ?? An existing entry in TREE_OPTIMIZATION_OPTABS indicates
+multiple ((optimize)) attributes for the same
patch to fix PR56184
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184
The problem was in that reg equiv was not corrected for a split pseudo
because of incorrect code for recognition of situation when a split
pseudo was created.
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 196019.
2013-02-13 Vladimir Makarov vmaka...@redhat.com
PR target/56184
* ira.c (max_regno_before_ira): Move from ...
(ira): ... here.
(fix_reg_equiv_init): Use max_regno_before_ira instead of
vec_safe_length.
2013-02-13 Vladimir Makarov vmaka...@redhat.com
PR target/56184
* gcc.target/arm/pr56184.C: New test.
Index: ira.c
===
--- ira.c (revision 196018)
+++ ira.c (working copy)
@@ -419,6 +419,11 @@ int ira_move_loops_num, ira_additional_j
HARD_REG_SET eliminable_regset;
+/* Value of max_reg_num () before IRA work start. This value helps
+ us to recognize a situation when new pseudos were created during
+ IRA work. */
+static int max_regno_before_ira;
+
/* Temporary hard reg set used for a different calculation. */
static HARD_REG_SET temp_hard_regset;
@@ -2264,11 +2269,11 @@ ira_update_equiv_info_by_shuffle_insn (i
static void
fix_reg_equiv_init (void)
{
- unsigned int max_regno = max_reg_num ();
+ int max_regno = max_reg_num ();
int i, new_regno, max;
rtx x, prev, next, insn, set;
- if (vec_safe_length (reg_equivs) max_regno)
+ if (max_regno_before_ira max_regno)
{
max = vec_safe_length (reg_equivs);
grow_reg_equivs ();
@@ -4350,7 +4355,7 @@ static void
ira (FILE *f)
{
bool loops_p;
- int max_regno_before_ira, ira_max_point_before_emit;
+ int ira_max_point_before_emit;
int rebuild_p;
bool saved_flag_caller_saves = flag_caller_saves;
enum ira_region saved_flag_ira_region = flag_ira_region;
Index: testsuite/gcc.target/arm/pr56184.C
===
--- testsuite/gcc.target/arm/pr56184.C (revision 0)
+++ testsuite/gcc.target/arm/pr56184.C (working copy)
@@ -0,0 +1,257 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -mthumb -march=armv7-a -mfpu=neon -mfloat-abi=softfp
-mtune=cortex-a9 -fno-section-anchors } */
+
+typedef unsigned int size_t;
+__extension__ typedef int __intptr_t;
+typedef __intptr_t intptr_t;
+typedef union tree_node *tree;
+typedef const union tree_node *const_tree;
+extern void *ggc_internal_cleared_alloc_stat (size_t )
+ __attribute__ ((__malloc__));
+enum tree_code {
+TREE_LIST=2,
+FUNCTION_DECL,
+MAX_TREE_CODES=254
+};
+extern unsigned char tree_contains_struct[MAX_TREE_CODES][64];
+struct tree_base {
+ enum tree_code code : 16;
+};
+struct tree_common {
+ tree chain;
+};
+enum tree_node_structure_enum {
+TS_COMMON,
+TS_DECL_COMMON,
+};
+extern void tree_contains_struct_check_failed (const_tree,
+const enum tree_node_structure_enum,
+const char *, int, const char *)
+ __attribute__ ((__noreturn__));
+extern void tree_check_failed (const_tree, const char *, int, const char *,
+ ...) __attribute__ ((__noreturn__));
+struct tree_list {
+ tree value;
+};
+struct tree_decl_common {
+ tree initial;
+};
+struct tree_function_decl {
+ struct function *f;
+};
+union
+ tree_node {
+ struct tree_base base;
+ struct tree_common common;
+ struct tree_decl_common decl_common;
+ struct tree_function_decl function_decl;
+ struct tree_list list;
+};
+inline tree
+tree_check (tree __t, const char *__f, int __l, const char *__g, enum
tree_code __c)
+{
+ if (((enum tree_code) (__t)-base.code) != __c)
+tree_check_failed (__t, __f, __l, __g, __c, 0);
+}
+inline tree
+contains_struct_check (tree __t, const enum tree_node_structure_enum __s,
+ const char *__f, int __l, const char *__g)
+{
+ if (tree_contains_struct[((enum tree_code) (__t)-base.code)][__s] != 1)
+ tree_contains_struct_check_failed (__t, __s, __f, __l, __g);
+}
+struct function {
+ tree static_chain_decl;
+};
+enum gimple_code {
+LAST_AND_UNUSED_GIMPLE_CODE
+};
+struct eh_catch_d
+{
+ struct eh_catch_d *next_catch;
+ struct eh_catch_d *prev_catch;
+ tree type_list;
+ tree filter_list;
+ tree label;
+};
+struct eh_region_d
+{
+ struct eh_region_d *outer;
+ struct eh_region_d *inner;
+ int index;
+ union eh_region_u {
+struct eh_region_u_try {
+ struct eh_catch_d *first_catch;
+} eh_try;
+ } u;
+};
+typedef struct eh_catch_d *eh_catch;
+typedef struct eh_region_d *eh_region;
+extern void add_type_for_runtime (tree);
+enum LTO_tags
+{
+ LTO_null = 0,
+ LTO_bb0 = 1 + MAX_TREE_CODES + LAST_AND_UNUSED_GIMPLE_CODE,
+ LTO_ert_cleanup,
+ LTO_NUM_TAGS
+};
+enum lto_section_type
+{
+ LTO_section_function_body,
+};
+struct lto_input_block
+{
+ const char *data;
+ unsigned int p;
+ unsigned int len;
+};
Re: PR target/52555: attribute optimize is overriding command line options
Aldy Hernandez al...@redhat.com writes: Richard. I made all the changes you suggested. I also changed other instances of s/this_target_optabs/this_fn_optabs/ which I forgot in the previous iteration. And I also changed save_optabs_if_changed() to use this_fn_optabs, since init_all_optabs() will generate the optabs into this_fn_optabs. Sorry, just noticed: + /* If the optabs changed, record it in the node. */ + if (memcmp (tmp_target_optabs, default_target_optabs, + sizeof (struct target_optabs))) This should be this_target_optabs rather than default_target_optabs. Nothing but target code and initialisers should use default_target_optabs directly. I don't think that needs a retest though. It only makes a difference on MIPS. Looks good to me otherwise. If there's any fallout on MIPS (hopefully not) I'll fix it up after the commit. Thanks, Richard
[PATCH] : Fix for PR 52123 additional patch for 32bit mingw
Here's a simple additional patch against trunk for 32bit mingw. OK to apply? Rainer 2013-02-13 Rainer Emrich rai...@emrich-ebersheim.de PR target/52123 * tracebak.c: Cast from pointer via FARPROC Index: ada/tracebak.c === --- ada/tracebak.c (revision 195803) +++ ada/tracebak.c (working copy) @@ -415,7 +415,7 @@ struct layout #if defined (__WIN32) #include windows.h -#define IS_BAD_PTR(ptr) (IsBadCodePtr((void *)ptr)) +#define IS_BAD_PTR(ptr) (IsBadCodePtr((FARPROC)ptr)) #elif defined (sun) #define IS_BAD_PTR(ptr) ((unsigned long)ptr == -1UL) #else
Re: [PATCH] : Fix for PR 52123 additional patch for 32bit mingw
Here's a simple additional patch against trunk for 32bit mingw. OK to apply? OK, thanks. Rainer 2013-02-13 Rainer Emrich rai...@emrich-ebersheim.de PR target/52123 * tracebak.c: Cast from pointer via FARPROC
Re: patch to fix PR56184
On 02/13/13 10:44, Vladimir Makarov wrote: The following patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184 The problem was in that reg equiv was not corrected for a split pseudo because of incorrect code for recognition of situation when a split pseudo was created. The patch was successfully bootstrapped and tested on x86/x86-64. Committed as rev. 196019. 2013-02-13 Vladimir Makarov vmaka...@redhat.com PR target/56184 * ira.c (max_regno_before_ira): Move from ... (ira): ... here. (fix_reg_equiv_init): Use max_regno_before_ira instead of vec_safe_length. 2013-02-13 Vladimir Makarov vmaka...@redhat.com PR target/56184 * gcc.target/arm/pr56184.C: New test. Don't forget to change the state of the PR. Thanks, Jeff
Re: PR target/52555: attribute optimize is overriding command line options
Sorry, just noticed:
+ /* If the optabs changed, record it in the node. */
+ if (memcmp (tmp_target_optabs, default_target_optabs,
+ sizeof (struct target_optabs)))
This should be this_target_optabs rather than default_target_optabs.
Nothing but target code and initialisers should use default_target_optabs
directly.
Fixed.
I don't think that needs a retest though. It only makes a difference
on MIPS.
I verified that the testcase is still fixed by this patch (just in
case). Thanks so much for the review.
Final patch attached.
Jakub, OK?
+ PR target/52555
+ * genopinit.c (main): Use this_fn_optabs in generated
+ init_all_optabs, raw_optab_handler, and swap_optab_enable.
+ * tree.h (struct tree_optimization_option): New field
+ target_optabs.
+ (TREE_OPTIMIZATION_OPTABS): New.
+ (save_optabs_if_changed): Protoize.
+ * optabs.h: Declare this_fn_optabs.
+ * optabs.c (save_optabs_if_changed): New.
+ Declare this_fn_optabs.
+ * function.c (invoke_set_current_function_hook): Set
+ this_fn_optabs if there is one in the optimization node.
c-family/
+ PR target/52555
+ * c-common.c (handle_optimize_attribute): Call
+ save_optabs_if_changed.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 1e6afaa..3711e69 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -8925,6 +8925,8 @@ handle_optimize_attribute (tree *node, tree name, tree
args,
DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node)
= build_optimization_node ();
+ save_optabs_if_changed (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node));
+
/* Restore current options. */
cl_optimization_restore (global_options, cur_opts);
}
diff --git a/gcc/function.c b/gcc/function.c
index 4ce2259..688242a 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -4383,6 +4383,7 @@ static bool in_dummy_function;
static void
invoke_set_current_function_hook (tree fndecl)
{
+ this_fn_optabs = this_target_optabs;
if (!in_dummy_function)
{
tree opts = ((fndecl)
@@ -4397,6 +4398,11 @@ invoke_set_current_function_hook (tree fndecl)
{
optimization_current_node = opts;
cl_optimization_restore (global_options, TREE_OPTIMIZATION (opts));
+
+ /* Change optabs if needed. */
+ if (TREE_OPTIMIZATION_OPTABS (opts))
+ this_fn_optabs
+ = (struct target_optabs *) TREE_OPTIMIZATION_OPTABS (opts);
}
targetm.set_current_function (fndecl);
diff --git a/gcc/genopinit.c b/gcc/genopinit.c
index 1bb2f77..13ebdc5 100644
--- a/gcc/genopinit.c
+++ b/gcc/genopinit.c
@@ -423,7 +423,7 @@ main (int argc, char **argv)
fprintf (s_file, };\n\n);
fprintf (s_file, void\ninit_all_optabs (void)\n{\n);
- fprintf (s_file, bool *ena = this_target_optabs-pat_enable;\n);
+ fprintf (s_file, bool *ena = this_fn_optabs-pat_enable;\n);
for (i = 0; patterns.iterate (i, p); ++i)
fprintf (s_file, ena[%u] = HAVE_%s;\n, i, p-name);
fprintf (s_file, }\n\n);
@@ -456,7 +456,7 @@ main (int argc, char **argv)
raw_optab_handler (unsigned scode)\n
{\n
int i = lookup_handler (scode);\n
-return (i = 0 this_target_optabs-pat_enable[i]\n
+return (i = 0 this_fn_optabs-pat_enable[i]\n
? pats[i].icode : CODE_FOR_nothing);\n
}\n\n);
@@ -468,8 +468,8 @@ main (int argc, char **argv)
int i = lookup_handler (scode);\n
if (i = 0)\n
{\n
-bool ret = this_target_optabs-pat_enable[i];\n
-this_target_optabs-pat_enable[i] = set;\n
+bool ret = this_fn_optabs-pat_enable[i];\n
+this_fn_optabs-pat_enable[i] = set;\n
return ret;\n
}\n
else\n
diff --git a/gcc/optabs.c b/gcc/optabs.c
index c1dacf4..00a13da 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3. If not see
struct target_optabs default_target_optabs;
struct target_libfuncs default_target_libfuncs;
+struct target_optabs *this_fn_optabs = default_target_optabs;
#if SWITCHABLE_TARGET
struct target_optabs *this_target_optabs = default_target_optabs;
struct target_libfuncs *this_target_libfuncs = default_target_libfuncs;
@@ -6207,6 +6208,40 @@ init_optabs (void)
targetm.init_libfuncs ();
}
+/* Recompute the optabs. If they have changed, save the new set of
+ optabs in the optimization node OPTNODE. */
+
+void
+save_optabs_if_changed (tree optnode)
+{
+ struct target_optabs *save_fn_optabs = this_fn_optabs;
+ struct target_optabs *tmp_target_optabs = XCNEW (struct target_optabs);
+
+ /* Generate a new set of optabs into tmp_target_optabs. */
+ this_fn_optabs = tmp_target_optabs;
+ init_all_optabs ();
+ this_fn_optabs = save_fn_optabs;
+
+ /* If the optabs changed, record it in the
[PATCH] : Fix for PR 52123 backport for gcc-4.7.3
Backport to 4.7.3, tested on i686-w64-mingw32, x86_64-w64-mingw32 and
x86_64-unknown-gnu-linux.
OK to apply?
Rainer
2013-02-13 Rainer Emrich rai...@emrich-ebersheim.de
PR target/52123
* adaint.c (__gnat_check_OWNER_ACL): Cast from pointer via
SECURITY_DESCRIPTOR *
(__gnat_set_OWNER_ACL): Cast from DWORD to ACCESS_MODE
(__gnat_portable_spawn): Fix cast to char* const*
(add_handle): Cast from pointer via void **
(add_handle): Cast from pointer via int *
(__gnat_locate_exec_on_path): Cast from pointer via TCHAR *
(__gnat_locate_exec_on_path): Cast from pointer via char *
* initialize.c (append_arg): Cast from pointer via LPWSTR
(__gnat_initialize): Cast from pointer via LPWSTR
* seh_init.c (__gnat_SEH_error_handler): Cast from pointer via FARPROC
* tracebak.c: Cast from pointer via FARPROC
Index: ada/adaint.c
===
--- ada/adaint.c(revision 195803)
+++ ada/adaint.c(working copy)
@@ -1982,7 +1982,7 @@ __gnat_check_OWNER_ACL
GROUP_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION,
NULL, 0, nLength);
- if ((pSD = (PSECURITY_DESCRIPTOR) HeapAlloc
+ if ((pSD = (SECURITY_DESCRIPTOR *) HeapAlloc
(GetProcessHeap (), HEAP_ZERO_MEMORY, nLength)) == NULL)
return 0;
@@ -2059,7 +2059,7 @@ __gnat_set_OWNER_ACL
return;
BuildExplicitAccessWithName
-(ea, username, AccessPermissions, AccessMode, NO_INHERITANCE);
+(ea, username, AccessPermissions, (ACCESS_MODE) AccessMode,
NO_INHERITANCE);
if (AccessMode == SET_ACCESS)
{
@@ -2384,7 +2384,7 @@ __gnat_portable_spawn (char *args[])
strcat (args[0], args_0);
strcat (args[0], \);
- status = spawnvp (P_WAIT, args_0, (const char* const*)args);
+ status = spawnvp (P_WAIT, args_0, (char* const*)args);
/* restore previous value */
free (args[0]);
@@ -2544,9 +2544,9 @@ add_handle (HANDLE h, int pid)
{
plist_max_length += 1000;
HANDLES_LIST =
-xrealloc (HANDLES_LIST, sizeof (HANDLE) * plist_max_length);
+(void **) xrealloc (HANDLES_LIST, sizeof (HANDLE) * plist_max_length);
PID_LIST =
-xrealloc (PID_LIST, sizeof (int) * plist_max_length);
+(int *) xrealloc (PID_LIST, sizeof (int) * plist_max_length);
}
HANDLES_LIST[plist_length] = h;
@@ -2935,7 +2935,7 @@ __gnat_locate_exec_on_path (char *exec_n
#define EXPAND_BUFFER_SIZE 32767
- wapath_val = alloca (EXPAND_BUFFER_SIZE);
+ wapath_val = (TCHAR *) alloca (EXPAND_BUFFER_SIZE);
wapath_val [0] = '.';
wapath_val [1] = ';';
@@ -2945,7 +2945,7 @@ __gnat_locate_exec_on_path (char *exec_n
if (!res) wapath_val [0] = _T('\0');
- apath_val = alloca (EXPAND_BUFFER_SIZE);
+ apath_val = (char *) alloca (EXPAND_BUFFER_SIZE);
WS2SC (apath_val, wapath_val, EXPAND_BUFFER_SIZE);
return __gnat_locate_exec (exec_name, apath_val);
Index: ada/initialize.c
===
--- ada/initialize.c(revision 195803)
+++ ada/initialize.c(working copy)
@@ -88,14 +88,14 @@ append_arg (int *index, LPWSTR dir, LPWS
{
/* no dir prefix */
dirlen = 0;
- fullvalue = xmalloc ((vallen + 1) * sizeof(TCHAR));
+ fullvalue = (LPWSTR) xmalloc ((vallen + 1) * sizeof(TCHAR));
}
else
{
/* Add dir first */
dirlen = _tcslen (dir);
- fullvalue = xmalloc ((dirlen + vallen + 1) * sizeof(TCHAR));
+ fullvalue = (LPWSTR) xmalloc ((dirlen + vallen + 1) * sizeof(TCHAR));
_tcscpy (fullvalue, dir);
}
@@ -203,7 +203,7 @@ __gnat_initialize (void *eh ATTRIBUTE_UN
if (ldir != NULL)
{
int n = ldir - wargv[k] + 1;
-dir = xmalloc ((n + 1) * sizeof (TCHAR));
+dir = (LPWSTR) xmalloc ((n + 1) * sizeof (TCHAR));
_tcsncpy (dir, wargv[k], n);
dir[n] = _T('\0');
}
Index: ada/seh_init.c
===
--- ada/seh_init.c (revision 195803)
+++ ada/seh_init.c (working copy)
@@ -90,7 +90,7 @@ __gnat_SEH_error_handler (struct _EXCEPT
*/
if ((ExceptionRecord-ExceptionInformation[1] 3) != 0
|| IsBadCodePtr
- ((void *)(ExceptionRecord-ExceptionInformation[1] + 4096)))
+ ((FARPROC)(ExceptionRecord-ExceptionInformation[1] + 4096)))
{
exception = program_error;
msg = EXCEPTION_ACCESS_VIOLATION;
Index: ada/tracebak.c
===
--- ada/tracebak.c (revision 195803)
+++ ada/tracebak.c (working copy)
@@ -326,7 +326,7 @@ struct layout
#if defined (__WIN32)
#include windows.h
-#define IS_BAD_PTR(ptr) (IsBadCodePtr((void *)ptr))
+#define IS_BAD_PTR(ptr)
Re: [PATCH] : Fix for PR 52123 backport for gcc-4.7.3
Backport to 4.7.3, tested on i686-w64-mingw32, x86_64-w64-mingw32 and x86_64-unknown-gnu-linux. OK to apply? OK 2013-02-13 Rainer Emrich rai...@emrich-ebersheim.de PR target/52123 * adaint.c (__gnat_check_OWNER_ACL): Cast from pointer via SECURITY_DESCRIPTOR * (__gnat_set_OWNER_ACL): Cast from DWORD to ACCESS_MODE (__gnat_portable_spawn): Fix cast to char* const* (add_handle): Cast from pointer via void ** (add_handle): Cast from pointer via int * (__gnat_locate_exec_on_path): Cast from pointer via TCHAR * (__gnat_locate_exec_on_path): Cast from pointer via char * * initialize.c (append_arg): Cast from pointer via LPWSTR (__gnat_initialize): Cast from pointer via LPWSTR * seh_init.c (__gnat_SEH_error_handler): Cast from pointer via FARPROC * tracebak.c: Cast from pointer via FARPROC
C++ PATCH for c++/55720 (link error with lambda conversion)
Most of the G++ linkage code really needs to be torn out in favor of
just using cgraph. Until that happens, we need to set TREE_USED here so
that decl_needed_p will return true and allow cgraph to consider the
function.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 701e03d86ffb5c36e1c907e84b8b0dc504ebe5b2
Author: Jason Merrill ja...@redhat.com
Date: Wed Feb 13 12:52:51 2013 -0500
PR c++/55720
* semantics.c (maybe_add_lambda_conv_op): Mark static thunk
TREE_USED.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 46c2e64..95158a5 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -9559,6 +9559,8 @@ maybe_add_lambda_conv_op (tree type)
body = begin_function_body ();
compound_stmt = begin_compound_stmt (0);
+ /* decl_needed_p needs to see that it's used. */
+ TREE_USED (statfn) = 1;
finish_return_stmt (decay_conversion (statfn, tf_warning_or_error));
finish_compound_stmt (compound_stmt);
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv7.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv7.C
new file mode 100644
index 000..861c91c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv7.C
@@ -0,0 +1,20 @@
+// PR c++/55720
+// { dg-do link { target c++11 } }
+
+template class T
+struct X {
+ static void (*code) ();
+};
+
+template class T
+void (*XT::code) () = []{}; // Line 7
+
+struct Y {
+ void (*code) () = []{} ; // Line 10
+ void operator()() { code(); }
+};
+
+int main () {
+ Xint::code();
+ Y()();
+}
Re: expansion of vector shifts...
From: Richard Biener richard.guent...@gmail.com Date: Wed, 13 Feb 2013 12:15:13 +0100 On Tue, Feb 12, 2013 at 11:31 PM, David Miller da...@davemloft.net wrote: Maybe what we really mean to do here is check both op1 and SUBREG_REG (op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P? Yes. Ok, I'll commit this after doing some regstraps, thanks. Something like this: gcc/ 2013-02-12 David S. Miller da...@davemloft.net * expmed.c (expand_shift_1): Only strip scalar integer subregs. diff --git a/gcc/expmed.c b/gcc/expmed.c index 4a6ddb0..954a360 100644 --- a/gcc/expmed.c +++ b/gcc/expmed.c @@ -2116,8 +2116,8 @@ expand_shift_1 (enum tree_code code, enum machine_mode mode, rtx shifted, % GET_MODE_BITSIZE (mode)); else if (GET_CODE (op1) == SUBREG subreg_lowpart_p (op1) - INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1))) - INTEGRAL_MODE_P (GET_MODE (op1))) + SCALAR_INT_MODE_P (GET_MODE (SUBREG_REG (op1))) + SCALAR_INT_MODE_P (GET_MODE (op1))) op1 = SUBREG_REG (op1); }
Re: [Patch, Fortran] Remove the Fortran-only flag -fno-whole-file
*** PING *** I think it is now a bit late for 4.8. Thus, I change my request to: OK for the 4.9 trunk? Tobias On January 5, 2013 00:31, Tobias Burnus wrote: This patch removes -fno-whole-file. (Actually, it turns it into Ignore.) Reasoning: * -fwhole-file/-fno-whole-file was added in 4.5 to make the transition easier; -fwhole-file is the default since 4.6. * There are many wrong-code issues and probably also some ICEs with -fno-whole file. * The generated code of -fwhole-file is faster as it allows for inlining. * -fno-whole-file has been deprecated since 4.6 and announced for removal. * Code cleanup is always nice (diff -w): 17 insertions(+), 80 deletions(-) Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias PS: Dominique pointed out that PR 45128 is a -fwhole-file regression. However, it mainly shows that gfortran needs the new array descriptor to fix such subpointer issues (and other PRs).
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On 02/13/13 08:54, Jakub Jelinek wrote:
Hi!
As agreed on in the PR, here is the revertion of 3 commits, so that
PCH works again for -gstabs and other debug info formats for 4.8
release. For 4.9 we should either remove support for anything non-DWARF, or
hope somebody steps up and fixes dbxout.c etc. not to emit debug info right
away, but queue it till end of compilation.
Bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested
with
make check
RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-gstabs,-m64,-m64/-gstabs} pch.exp'
Ok for trunk? I'll add reversion of this reversion to the 4.9 queued patches
PR.
That looks just like the patch I have here. Yet, I'm still seeing failures:
Running target unix/-m32/-gstabs
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for
target.
Using /home/gcc/GIT/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /home/gcc/GIT/gcc/gcc/testsuite/gcc.dg/pch/pch.exp ...
FAIL: gcc.dg/pch/decl-3.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O0 assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O1 assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O2 assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O3 -fomit-frame-pointer assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O3 -g assembly comparison
FAIL: gcc.dg/pch/decl-3.c -Os assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O0 assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O1 assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O2 assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O3 -fomit-frame-pointer assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O3 -g assembly comparison
FAIL: gcc.dg/pch/decl-4.c -Os assembly comparison
[ ... ]
Can you double-check your testing output?
Jeff
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 1:19 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Hi,
The attached patch is the libsanitizer merge from upstream r175042.
Lots of changes. Among other things:
- x86_64 linux: change the shadow offset to 0x7fff8000 (~5% speedup)
- the new asan allocator is enabled on Mac (was enabled on Linux before).
- tsan finds races between atomic and plain accesses
- better scanf interceptor, enabled by default
- don't include linux/futex.h (fixes PR56128)
- simple tests seem to work (again?) on PowerPC64 with 44-bit address
space (46 AS not tested)
Patch for libsanitizer is automatically generated by libsanitizer/merge.sh
Tested with
rm -rf */{*/,}libsanitizer \
make -j 50 \
make -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
Our internal LLVM bots (Linux, Mac and Android) are green.
Ok to commit?
--kcc
This breaks build on Linux/x32 where off_t is 64bit:
In file included from
/export/gnu/import/git/gcc/libsanitizer/interception/interception.h:20:0,
from
/export/gnu/import/git/gcc/libsanitizer/interception/interception_type_test.cc:15:
/export/gnu/import/git/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:221:72:
error: size of array ‘assertion_failed__34’ is negative
typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
/export/gnu/import/git/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:215:30:
note: in expansion of macro ‘IMPL_COMPILER_ASSERT’
#define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
^
/export/gnu/import/git/gcc/libsanitizer/interception/interception_type_test.cc:34:1:
note: in expansion of macro ‘COMPILER_CHECK’
COMPILER_CHECK(sizeof(OFF_T) == sizeof(off_t));
^
make[7]: *** [interception_type_test.lo] Error 1
This patch fixes it. OK to install?
Thanks.
--
H.J.
---
diff --git a/libsanitizer/interception/interception.h
b/libsanitizer/interception/interception.h
index b4c4137..c4c5026 100644
--- a/libsanitizer/interception/interception.h
+++ b/libsanitizer/interception/interception.h
@@ -28,8 +28,8 @@ typedef __sanitizer::s64 INTMAX_T;
// WARNING: OFF_T may be different from OS type off_t, depending on
the value of
// _FILE_OFFSET_BITS. This definition of OFF_T matches the ABI of system calls
// like pread and mmap, as opposed to pread64 and mmap64.
-// Mac is special.
-#ifdef __APPLE__
+// Mac and Linux/x86-64 are special.
+#if defined(__APPLE__) || (defined(__linux__) defined(__x86_64__))
typedef __sanitizer::u64 OFF_T;
#else
typedef __sanitizer::uptr OFF_T;
Re: [PATCH][C++11][ PR55582] Let string literals starting with lower-case 's' be a user-defined literal instead of string + macro.
I just noticed this patch. Since it was submitted well before the end of stage 3 and looks quite safe, it's OK to go in for 4.8. Please remember to CC/ping me for C++ patches. Thanks, Jason
Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)
On Wed, Feb 13, 2013 at 7:46 AM, Sriraman Tallam tmsri...@google.com wrote:
On Feb 13, 2013 1:21 AM, Andreas Schwab sch...@suse.de wrote:
Sriraman Tallam tmsri...@google.com writes:
Index: gcc/testsuite/g++.dg/ext/mv12-aux.C
===
--- gcc/testsuite/g++.dg/ext/mv12-aux.C (revision 0)
+++ gcc/testsuite/g++.dg/ext/mv12-aux.C (revision 0)
@@ -0,0 +1,11 @@
+// Test case to check if multiversioning works as expected when the
versions
+// are defined in different files. Auxiliary file for mv12.C.
+// { dg-do compile }
+
+#include mv12.h
+
+__attribute__ ((target (sse4.2)))
+int foo ()
FAIL: g++.dg/ext/mv12-aux.C -std=c++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20130213/gcc/testsuite/g++.dg/ext/mv12.h:5:47:
warning: target attribute is not supported on this machine [-Wattributes]
/daten/aranym/gcc/gcc-20130213/gcc/testsuite/g++.dg/ext/mv12.h:6:46:
warning: target attribute is not supported on this machine [-Wattributes]
/daten/aranym/gcc/gcc-20130213/gcc/testsuite/g++.dg/ext/mv12-aux.C:8:10:
warning: target attribute is not supported on this machine [-Wattributes]
I will fix this asap. Sorry about this.
I committed a trivial patch to fix this problem. mv12-aux.C is
auxiliary to mv12.C and should have the same test directives as
mv12.C.
2013-02-13 Sriraman Tallam tmsri...@google.com
* g++.dg/ext/mv12-aux.C: Add directives to match mv12.C.
Index: g++.dg/ext/mv12-aux.C
===
--- g++.dg/ext/mv12-aux.C (revision 196025)
+++ g++.dg/ext/mv12-aux.C (working copy)
@@ -1,7 +1,10 @@
// Test case to check if multiversioning works as expected when the versions
// are defined in different files. Auxiliary file for mv12.C.
-// { dg-do compile }
+// { dg-do compile { target i?86-*-* x86_64-*-* } }
+// { dg-require-ifunc }
+// { dg-options -O2 }
+
#include mv12.h
This should fix the problem.
Thanks
Sri
Sri
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
And now for something completely different.
[PATCH] Small asan improvement
Hi!
This is just a small improvement for Dodji's work. We can flush the hash
table with memory references known to be instrumented only at extended basic
block boundaries, no need to flush it at every bb (of course, for 4.9 we
want to do something better). And, now that we have nonfreeing_call_p
predicate, we can avoid also flushing at builtin calls that are known not to
free memory or use callbacks etc.
The first 5 hunks are there because I've noticed that we were creating a
fallthru edge from basic blocks with __asan_report_* call (which is
noreturn) - we shouldn't have any edge there.
Where these change make a difference is e.g.:
void baz (long *, int);
long
foo (long *p, int q)
{
long a = *p;
if (q)
{
*p = 6;
baz (p, 7);
}
else
{
*p = 25;
baz (p + 1, 17);
}
return a;
}
long
bar (long *p, double q, double r)
{
long a = *p;
a += __builtin_pow (q, r);
*p = 6;
return a;
}
Without the patch, in asan1 pass there are two load instrumentations
(one in each fn) and 3 store insturmentations, with the patch 2 load
and one store instrumentation (only one of then and else bbs are
considered extended bb). For foo later optimizations actually optimize
away all of store instrumentations, but it doesn't have to happen always.
2013-02-13 Jakub Jelinek ja...@redhat.com
* asan.c (create_cond_insert_point): Add create_then_fallthru_edge
argument. If it is false, don't create edge from then_bb to
fallthru_bb.
(insert_if_then_before_iter): Pass true to it.
(build_check_stmt): Pass false to it.
(transform_statements): Flush hash table only on extended basic
block boundaries, rather than at the beginning of every bb.
Don't flush hash table on nonfreeing_call_p calls.
* tree-flow.h (nonfreeing_call_p): New prototype.
* tree-ssa-phiopt.c (nonfreeing_call_p): No longer static.
--- gcc/asan.c.jj 2013-02-13 11:53:42.0 +0100
+++ gcc/asan.c 2013-02-13 19:46:20.033555655 +0100
@@ -1185,6 +1185,9 @@ report_error_func (bool is_store, int si
'then block' of the condition statement to be inserted by the
caller.
+ If CREATE_THEN_FALLTHRU_EDGE is false, no edge will be created from
+ *THEN_BLOCK to *FALLTHROUGH_BLOCK.
+
Similarly, the function will set *FALLTRHOUGH_BLOCK to the 'else
block' of the condition statement to be inserted by the caller.
@@ -1201,6 +1204,7 @@ static gimple_stmt_iterator
create_cond_insert_point (gimple_stmt_iterator *iter,
bool before_p,
bool then_more_likely_p,
+ bool create_then_fallthru_edge,
basic_block *then_block,
basic_block *fallthrough_block)
{
@@ -1226,7 +1230,8 @@ create_cond_insert_point (gimple_stmt_it
? PROB_VERY_UNLIKELY
: PROB_ALWAYS - PROB_VERY_UNLIKELY;
e-probability = PROB_ALWAYS - fallthrough_probability;
- make_single_succ_edge (then_bb, fallthru_bb, EDGE_FALLTHRU);
+ if (create_then_fallthru_edge)
+make_single_succ_edge (then_bb, fallthru_bb, EDGE_FALLTHRU);
/* Set up the fallthrough basic block. */
e = find_edge (cond_bb, fallthru_bb);
@@ -1277,6 +1282,7 @@ insert_if_then_before_iter (gimple cond,
create_cond_insert_point (iter,
/*before_p=*/true,
then_more_likely_p,
+ /*create_then_fallthru_edge=*/true,
then_bb,
fallthrough_bb);
gsi_insert_after (cond_insert_point, cond, GSI_NEW_STMT);
@@ -1314,6 +1320,7 @@ build_check_stmt (location_t location, t
statement for the instrumentation. */
gsi = create_cond_insert_point (iter, before_p,
/*then_more_likely_p=*/false,
+ /*create_then_fallthru_edge=*/false,
then_bb,
else_bb);
@@ -1883,15 +1890,31 @@ maybe_instrument_call (gimple_stmt_itera
static void
transform_statements (void)
{
- basic_block bb;
+ basic_block bb, last_bb = NULL;
gimple_stmt_iterator i;
int saved_last_basic_block = last_basic_block;
FOR_EACH_BB (bb)
{
- empty_mem_ref_hash_table ();
+ basic_block prev_bb = bb;
if (bb-index = saved_last_basic_block) continue;
+
+ /* Flush the mem ref hash table, if current bb doesn't have
+exactly one predecessor, or if that predecessor (skipping
+over asan created basic blocks) isn't the last processed
+basic block. Thus we effectively flush on extended basic
+block boundaries. */
+ while (single_pred_p (prev_bb))
+ {
+ prev_bb = single_pred (prev_bb);
+ if (prev_bb-index saved_last_basic_block)
+ break;
+ }
+ if (prev_bb != last_bb)
+ empty_mem_ref_hash_table ();
+ last_bb
Re: [patch, Fortran] Fix PR 56224
*ping* I'd like to get this into 4.8 before release. This version of the patch should fix that particular issue, and also has no test cases. Regression-tested. OK? I can leave out the FIXME if people object. Thomas
Re: [Patch, Fortran] Remove the Fortran-only flag -fno-whole-file
On Wed, Feb 13, 2013 at 07:20:10PM +0100, Tobias Burnus wrote: *** PING *** I think it is now a bit late for 4.8. Thus, I change my request to: OK for the 4.9 trunk? IMHO, yes. Don't know if others have an opinion, but waiting any longer would seem to be counter productive. -- Steve
Re: [patch, Fortran] Fix PR 56224
Thomas Koenig wrote: *ping* * pong * I'd like to get this into 4.8 before release. Others as well, given that it is a release-blocking P1 regression … However, I have already approved it: http://gcc.gnu.org/ml/fortran/2013-02/msg00061.html Tobias
Re: [cxx-conversion] Add Record Builder Class
On Tue, Feb 12, 2013 at 2:47 PM, Lawrence Crowl cr...@google.com wrote:
@@ -182,24 +163,9 @@ default_emutls_var_init (tree to, tree d
static tree
get_emutls_object_type (void)
{
- tree type, type_name, field;
-
- type = emutls_object_type;
- if (type)
-return type;
-
- emutls_object_type = type = lang_hooks.types.make_type (RECORD_TYPE);
- type_name = NULL;
- field = targetm.emutls.var_fields (type, type_name);
- if (!type_name)
-type_name = get_identifier (__emutls_object);
- type_name = build_decl (UNKNOWN_LOCATION,
- TYPE_DECL, type_name, type);
- TYPE_NAME (type) = type_name;
- TYPE_FIELDS (type) = field;
- layout_type (type);
-
- return type;
+ if (!emutls_object_type)
+emutls_object_type = targetm.emutls.object_type ();
+ return emutls_object_type;
Hm, this does not look like an idempotent change. Where did I get lost?
===
--- gcc/coverage.c (revision 195904)
+++ gcc/coverage.c (working copy)
@@ -121,8 +121,8 @@ static const char *const ctr_names[GCOV_
/* Forward declarations. */
static void read_counts_file (void);
static tree build_var (tree, tree, int);
-static void build_fn_info_type (tree, unsigned, tree);
-static void build_info_type (tree, tree);
+static tree build_fn_info_type (unsigned, tree);
+static tree build_info_type (record_builder , tree);
I don't really like unnecessary forward declarations. But I guess
it's OK, since you are replacing existing ones.
-static void
-build_fn_info_type (tree type, unsigned counters, tree gcov_info_type)
+static tree
+build_fn_info_type (unsigned counters, tree gcov_info_type)
So, here you are changing the signature because the caller used to
create an empty record and now it doesn't need to? We are going to be
creating it in the constructor, right?
Diego.
Keep the macro complex in C++03
Hello,
this patch was tested on x86_64-linux-gnu. For the testcase, I randomly
picked c99.cc which I copied and c++11 - c++98, _Complex - complex, but
anything using the macro would do.
2013-02-13 Marc Glisse marc.gli...@inria.fr
PR libstdc++/56111
* include/std/complex (complex): Undefine.
* include/c_compatibility/complex.h (complex): Only undefine if
complex has been included.
* testsuite/26_numerics/complex/56111.cc: New testcase.
--
Marc GlisseIndex: include/std/complex
===
--- include/std/complex (revision 196018)
+++ include/std/complex (working copy)
@@ -37,20 +37,23 @@
#define _GLIBCXX_COMPLEX 1
#pragma GCC system_header
#include bits/c++config.h
#include bits/cpp_type_traits.h
#include ext/type_traits.h
#include cmath
#include sstream
+// Get rid of a macro possibly defined in complex.h
+#undef complex
+
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
* @defgroup complex_numbers Complex Numbers
* @ingroup numerics
*
* Classes and functions for complex numbers.
* @{
Index: include/c_compatibility/complex.h
===
--- include/c_compatibility/complex.h (revision 196018)
+++ include/c_compatibility/complex.h (working copy)
@@ -27,17 +27,20 @@
*/
#include bits/c++config.h
#if __cplusplus = 201103L
# include ccomplex
#endif
#if _GLIBCXX_HAVE_COMPLEX_H
# include_next complex.h
-# undef complex
+# ifdef _GLIBCXX_COMPLEX
+// See PR56111, keep the macro in C++03 if possible.
+# undef complex
+# endif
#endif
#ifndef _GLIBCXX_COMPLEX_H
#define _GLIBCXX_COMPLEX_H 1
#endif
Index: testsuite/26_numerics/complex/56111.cc
===
--- testsuite/26_numerics/complex/56111.cc (revision 0)
+++ testsuite/26_numerics/complex/56111.cc (revision 0)
@@ -0,0 +1,38 @@
+// { dg-do compile }
+// { dg-options -std=c++98 }
+
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+// http://www.gnu.org/licenses/.
+
+// libstdc++/56111
+// In C++03, we try to keep the macro complex as long as it does not
+// conflict (std::complex).
+#include bits/c++config.h
+#if _GLIBCXX_HAVE_COMPLEX_H
+# include complex.h
+#endif
+
+int main()
+{
+ bool test __attribute__((unused)) = true;
+
+#if _GLIBCXX_HAVE_COMPLEX_H
+ double complex x = .5;
+ double complex y = cacos (x);
+ (void)y;
+#endif
+}
Property changes on: testsuite/26_numerics/complex/56111.cc
___
Added: svn:keywords
+ Author Date Id Revision URL
Added: svn:eol-style
+ native
Re: PR target/52555: attribute optimize is overriding command line options
On Wed, Feb 13, 2013 at 12:07:52PM -0600, Aldy Hernandez wrote: Sorry, just noticed: + /* If the optabs changed, record it in the node. */ + if (memcmp (tmp_target_optabs, default_target_optabs, + sizeof (struct target_optabs))) This should be this_target_optabs rather than default_target_optabs. Nothing but target code and initialisers should use default_target_optabs directly. Fixed. I don't think that needs a retest though. It only makes a difference on MIPS. I verified that the testcase is still fixed by this patch (just in case). Thanks so much for the review. Final patch attached. Actually, thinking more about SWITCHABLE_TARGETS, I don't think this works at all on those targets. this_target_optab is some random optab from whatever has been left there by previous function, it can be either the same, or different target (mips vs. mips16?). So, for SWITCHABLE_TARGETS, I'm afraid you really can't save the optabs in the optimization node (because, there could be different optabs for say all of -Ofast + mips, -Ofast + mips16, -O2 + mips and -O2 + mips16 combinations), but you probably can't save it even from within the target hook, because some non-default optimization node might be in effect. So, for SWITCHABLE_TARGETS, I think you can only save it in cfun-this_fn_optab or similar, and perhaps cache the default for mips16 only when you know the default optimization node is in effect (or force it into effect temporarily). For !SWITCHABLE_TARGETS, you can easily remember it in the optimization nodes and just copy the pointer over to cfun-this_fn_optab. And unfortunately it seems optimize attribute is supported everywhere, just the target attribute is not. But, as soon as it is reachable from cfun-this_fn_optab, we might need to GC allocate it, while optimization nodes are never freed, cfun is freed I think. Jakub
Re: [cxx-conversion] Add Record Builder Class
On 2/13/13, Diego Novillo dnovi...@google.com wrote:
On Tue, Feb 12, 2013 at 2:47 PM, Lawrence Crowl cr...@google.com wrote:
@@ -182,24 +163,9 @@ default_emutls_var_init (tree to, tree d
static tree
get_emutls_object_type (void)
{
- tree type, type_name, field;
-
- type = emutls_object_type;
- if (type)
-return type;
-
- emutls_object_type = type = lang_hooks.types.make_type (RECORD_TYPE);
- type_name = NULL;
- field = targetm.emutls.var_fields (type, type_name);
- if (!type_name)
-type_name = get_identifier (__emutls_object);
- type_name = build_decl (UNKNOWN_LOCATION,
- TYPE_DECL, type_name, type);
- TYPE_NAME (type) = type_name;
- TYPE_FIELDS (type) = field;
- layout_type (type);
-
- return type;
+ if (!emutls_object_type)
+emutls_object_type = targetm.emutls.object_type ();
+ return emutls_object_type;
Hm, this does not look like an idempotent change. Where did I
get lost?
The responsibility for creating the type has moved into the new hook.
The old hook only had responsibility for adding fields. And changing
the name if it wasn't right. The new structure has a much clearer
division of responsibility.
===
--- gcc/coverage.c (revision 195904)
+++ gcc/coverage.c (working copy)
@@ -121,8 +121,8 @@ static const char *const ctr_names[GCOV_
/* Forward declarations. */
static void read_counts_file (void);
static tree build_var (tree, tree, int);
-static void build_fn_info_type (tree, unsigned, tree);
-static void build_info_type (tree, tree);
+static tree build_fn_info_type (unsigned, tree);
+static tree build_info_type (record_builder , tree);
I don't really like unnecessary forward declarations. But I guess
it's OK, since you are replacing existing ones.
Yeah. I figure applying style changes should be a separate patch.
-static void
-build_fn_info_type (tree type, unsigned counters, tree gcov_info_type)
+static tree
+build_fn_info_type (unsigned counters, tree gcov_info_type)
So, here you are changing the signature because the caller used
to create an empty record and now it doesn't need to? We are
going to be creating it in the constructor, right?
Correct.
--
Lawrence Crowl
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Wed, Feb 13, 2013 at 11:23:24AM -0700, Jeff Law wrote:
On 02/13/13 08:54, Jakub Jelinek wrote:
That looks just like the patch I have here. Yet, I'm still seeing failures:
Running target unix/-m32/-gstabs
Using /usr/share/dejagnu/baseboards/unix.exp as board description
file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file
for target.
Using /home/gcc/GIT/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /home/gcc/GIT/gcc/gcc/testsuite/gcc.dg/pch/pch.exp ...
FAIL: gcc.dg/pch/decl-3.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O0 assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O1 assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O2 assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O3 -fomit-frame-pointer assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O3 -g assembly comparison
FAIL: gcc.dg/pch/decl-3.c -Os assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O0 assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O1 assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O2 assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O3 -fomit-frame-pointer assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O3 -g assembly comparison
FAIL: gcc.dg/pch/decl-4.c -Os assembly comparison
[ ... ]
Can you double-check your testing output?
Yes, I've double checked it. Fresh trunk, got all of
gcc.dg/pch/{decl-{3,4},struct-1,system-1,valid-1}.c failures
for -m32/-gstabs as well as -m64/-gstabs, both with gcc
that has #define HAVE_GAS_CFI_DIRECTIVE {0,1} in auto-host.h.
Applying the patch cured all of those failures, except for
valid-1.c (which is fine, as that test assumes no -g* switches
be present by default).
Jakub
Re: [cxx-conversion] Add Record Builder Class
Thanks. The patch is OK for the branch. You can address Nathan's review after he's back and gets a chance to look at it. Let me know when the patch is in. I've got another merge in process. Diego.
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 11:48:32AM -0500, Jack Howarth wrote: On Wed, Feb 13, 2013 at 04:19:14PM +0100, Jakub Jelinek wrote: The reexec is problematic, what if the program already in constructors run before __asan_init (perhaps ctors of other libraries etc.) does something that really shouldn't be done twice? Wouldn't sorting all of the constructors and destructors by priority, while retaining the original order, in collect2 solve this issue (as was proposed for implementing intra-modular init priority support on darwin)? I wasn't talking about darwin at all, and on Linux inter-CU init priority works just fine. I'm just saying that reexec isn't always safe, because what the program does before __asan_init can be something undesirable to be done multiple times. Jakub
Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)
On Wed, Feb 13, 2013 at 10:57:42AM -0800, Sriraman Tallam wrote:
I committed a trivial patch to fix this problem. mv12-aux.C is
auxiliary to mv12.C and should have the same test directives as
mv12.C.
2013-02-13 Sriraman Tallam tmsri...@google.com
* g++.dg/ext/mv12-aux.C: Add directives to match mv12.C.
Better would be to rename
g++.dg/ext/mv12-aux.C to g++.dg/ext/mv12-aux.cc and remove all dg-*
directives from it, plus adjust dg-additional-sources in mv12.C.
The dg.exp driver is only looking for *.C testcases, so it will skip
*.cc, which is what you want.
--- g++.dg/ext/mv12-aux.C (revision 196025)
+++ g++.dg/ext/mv12-aux.C (working copy)
@@ -1,7 +1,10 @@
// Test case to check if multiversioning works as expected when the versions
// are defined in different files. Auxiliary file for mv12.C.
-// { dg-do compile }
+// { dg-do compile { target i?86-*-* x86_64-*-* } }
+// { dg-require-ifunc }
+// { dg-options -O2 }
+
#include mv12.h
This should fix the problem.
Jakub
[PATCH] [asan] Fix a thinko leading to a crash
Hello,
It appeared that in my previous patch, a stupid thinko can lead to a
crash when instrumenting some builtin functionsK. Fixed thus.
Tested against trunk on x86_64-unknown-linux-gnu, and a bootstrap is underway.
gcc/
* asan.c (instrument_builtin_call): Really put the length of the
second source argument into src1_len.
gcc/testsuite/
* c-c++-common/asan/memcmp-2.c: New test.
---
gcc/asan.c | 2 +-
gcc/testsuite/c-c++-common/asan/memcmp-2.c | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/c-c++-common/asan/memcmp-2.c
diff --git a/gcc/asan.c b/gcc/asan.c
index 3cb9511..7783723 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1764,7 +1764,7 @@ instrument_builtin_call (gimple_stmt_iterator *iter)
if (get_mem_refs_of_builtin_call (call,
src0, src0_len, src0_is_store,
- src1, src0_len, src1_is_store,
+ src1, src1_len, src1_is_store,
dest, dest_len, dest_is_store,
dest_is_deref))
{
diff --git a/gcc/testsuite/c-c++-common/asan/memcmp-2.c
b/gcc/testsuite/c-c++-common/asan/memcmp-2.c
new file mode 100644
index 000..be20cd8
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/memcmp-2.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+
+int
+foo ()
+{
+ char s0[5] = {0};
+ char s1[5] = {1};
+
+ return __builtin_memcmp (s0, s1, 2);
+}
--
Dodji
Re: [PATCH] Small asan improvement
Jakub Jelinek ja...@redhat.com writes:
This is just a small improvement for Dodji's work. We can flush the hash
table with memory references known to be instrumented only at extended basic
block boundaries, no need to flush it at every bb (of course, for 4.9 we
want to do something better).
This makes a lot of sense, thank you for doing this.
And, now that we have nonfreeing_call_p predicate,
I didn't even know this existed ...
we can avoid also flushing at builtin calls that are known not to
free memory or use callbacks etc.
Right.
The first 5 hunks are there because I've noticed that we were creating a
fallthru edge from basic blocks with __asan_report_* call (which is
noreturn) - we shouldn't have any edge there.
Good catch.
Where these change make a difference is e.g.:
void baz (long *, int);
long
foo (long *p, int q)
{
long a = *p;
if (q)
{
*p = 6;
baz (p, 7);
}
else
{
*p = 25;
baz (p + 1, 17);
}
return a;
}
long
bar (long *p, double q, double r)
{
long a = *p;
a += __builtin_pow (q, r);
*p = 6;
return a;
}
Without the patch, in asan1 pass there are two load instrumentations
(one in each fn) and 3 store insturmentations, with the patch 2 load
and one store instrumentation (only one of then and else bbs are
considered extended bb). For foo later optimizations actually optimize
away all of store instrumentations, but it doesn't have to happen
always.
Maybe we could have this added to he GCC test suite?
2013-02-13 Jakub Jelinek ja...@redhat.com
* asan.c (create_cond_insert_point): Add create_then_fallthru_edge
argument. If it is false, don't create edge from then_bb to
fallthru_bb.
(insert_if_then_before_iter): Pass true to it.
(build_check_stmt): Pass false to it.
(transform_statements): Flush hash table only on extended basic
block boundaries, rather than at the beginning of every bb.
Don't flush hash table on nonfreeing_call_p calls.
* tree-flow.h (nonfreeing_call_p): New prototype.
* tree-ssa-phiopt.c (nonfreeing_call_p): No longer static.
This looks OK to me. Thanks.
--
Dodji
Re: [PATCH] [asan] Fix a thinko leading to a crash
On Wed, Feb 13, 2013 at 09:37:42PM +0100, Dodji Seketeli wrote: Hello, It appeared that in my previous patch, a stupid thinko can lead to a crash when instrumenting some builtin functionsK. Fixed thus. Tested against trunk on x86_64-unknown-linux-gnu, and a bootstrap is underway. gcc/ * asan.c (instrument_builtin_call): Really put the length of the second source argument into src1_len. gcc/testsuite/ * c-c++-common/asan/memcmp-2.c: New test. Ok, thanks. Jakub
Re: [patch] fix libstdc++/56278
Committed then.
2013-02-13 François Dumont fdum...@gcc.gnu.org
* include/bits/hashtable_policy.h (_Hash_code_base): Restore
default constructor protected.
* include/bits/hashtable.h: static assert that _Hash_code_base has
a default constructor available through inheritance.
On 02/13/2013 12:36 PM, Jonathan Wakely wrote:
On 13 February 2013 10:19, Paolo Carlini wrote:
On 02/12/2013 09:54 PM, François Dumont wrote:
Of course this is not mandatory but I think _Hash_code_base would be
cleaner this way only exposing as public what is required by C++11. It can
also wait for 4.9.
I like it. Thanks Francois. If Jon has no objections over the next day or
so, please go ahead.
No objection, I agree it's suitable for 4.8 as it's refining my
regression fix, but I don't think it really makes any difference.
There is nothing required by C++11 for _Hash_code_base's constructors
because it's an implementation detail, and the only way a user can
tell the difference between a public and protected constructor is
trying to construct _Hash_code_base directly, which is obviously
unsupported.
Index: include/bits/hashtable_policy.h
===
--- include/bits/hashtable_policy.h (revision 195955)
+++ include/bits/hashtable_policy.h (working copy)
@@ -918,15 +918,13 @@
using __ebo_extract_key = _Hashtable_ebo_helper0, _ExtractKey;
using __ebo_hash = _Hashtable_ebo_helper1, _Hash;
-public:
- // We need the default constructor for the local iterators.
- _Hash_code_base() = default;
-
protected:
typedef void* __hash_code;
typedef _Hash_node_Value, false __node_type;
-protected:
+ // We need the default constructor for the local iterators.
+ _Hash_code_base() = default;
+
_Hash_code_base(const _ExtractKey __ex, const _H1, const _H2,
const _Hash __h)
: __ebo_extract_key(__ex), __ebo_hash(__h) { }
@@ -1004,13 +1002,13 @@
hash_function() const
{ return _M_h1(); }
- // We need the default constructor for the local iterators.
- _Hash_code_base() = default;
-
protected:
typedef std::size_t __hash_code;
typedef _Hash_node_Value, false __node_type;
+ // We need the default constructor for the local iterators.
+ _Hash_code_base() = default;
+
_Hash_code_base(const _ExtractKey __ex,
const _H1 __h1, const _H2 __h2,
const _Default_ranged_hash)
Index: include/bits/hashtable.h
===
--- include/bits/hashtable.h (revision 195955)
+++ include/bits/hashtable.h (working copy)
@@ -266,7 +266,10 @@
// __hash_code_base above to compute node bucket index so it has to be
// default constructible.
static_assert(__if_hash_not_cached
- is_default_constructible__hash_code_base::value,
+ is_default_constructible
+ // We use _Hashtable_ebo_helper to access the protected
+ // default constructor.
+ __detail::_Hashtable_ebo_helper0, __hash_code_base::value,
Cache the hash code or make functors involved in hash code
and bucket index computation default constructible);
Re: Keep the macro complex in C++03
Hi, 2013-02-13 Marc Glisse marc.gli...@inria.fr PR libstdc++/56111 * include/std/complex (complex): Undefine. * include/c_compatibility/complex.h (complex): Only undefine if complex has been included. * testsuite/26_numerics/complex/56111.cc: New testcase. Patch is Ok, thanks. You may want to remove the test variable: it serves no purpose in a dg-do compile testcase with no VERIFYs in it. Thanks again! Paolo
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Wed, Feb 13, 2013 at 4:54 PM, Jakub Jelinek wrote: Hi! As agreed on in the PR, here is the revertion of 3 commits, so that PCH works again for -gstabs and other debug info formats for 4.8 release. For 4.9 we should either remove support for anything non-DWARF, or hope somebody steps up and fixes dbxout.c etc. not to emit debug info right away, but queue it till end of compilation. Hello, I'd still like to propose deprecating all stabs support for GCC 4.8 and remove it for GCC 4.9 (i.e. dbxout, sdbout, xcoffout). It's not a very useful debug info format, after all. The only argument against DWARF, that it is so much larger than stabs, is something I haven't been able to reproduce (see http://sourceware.org/ml/binutils/2013-01/msg00221.html and http://sourceware.org/ml/binutils/2013-01/msg00239.html). DWARF compression via dwz, and debug-fission will improve things even further. An important question is of course: Who still *needs* stabs? If there are important platforms that need stabs support to continue to work, then deprecating is probably not a realistic option yet... The list of platforms that are IMHO blockers rights now, with possible solutions for GCC 4.9, are: * hppa2.0w-hp-hpux11.11 - no solution immediately available * powerpc-ibm-aix* - only support AIX7 and later - deprecate AIX6 and older in GCC 4.8 * ix86-*-openbsd2.*, ix86-*openbsd3.[0123] - OpenBSD 3.3 was released in May 2003 - deprecate for GCC 4.8 * m68k*-*-openbsd - port has seen no active maintenance, and has no test results posted, ever - deprecate for GCC 4.8 * pdp11-*-* - toy port - default to DEBUG_NONE * ix86-*-interix* - no solution immediately available, and no-one listed in MAINTAINERS to ask for help, so maybe Doug can say something about this one? Platforms that support DWARF2+ but currently have another default preferred debug info type, would be changed to default to DWARF2+. So older AIX and 32-bits HPUX are the only real problem cases. Ciao! Steven All GCC 4.8 primary platforms support DWARF2+, and AFAICT they all have it as their PREFERRED_DEBUGGING_TYPE (including freebsd): * arm-linux-gnueabi * i386-unknown-freebsd * i686-pc-linux-gnu * mipsisa64-elf * powerpc64-unknown-linux-gnu * sparc-sun-solaris2.10 * x86_64-unknown-linux-gnu Most of the above also include other debug info types by default, but DWARF2+ is the default. For the secondary platforms list things are not so simple. Some of them have a non-DWARF PREFERRED_DEBUGGING_TYPE by default, and some only conditionally (old configurations): * hppa2.0w-hp-hpux11.11 - DBX_DEBUGGING_INFO For 32-bits only, but that's the most common subtarget. According to Dave, it should be possible to add DRAWF2+ support: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117#c14 Perhaps Dave can explain what would have to be done to move this platform to DWARF2...? * powerpc-ibm-aix7.1.0.0 - XCOFF_DEBUGGING_INFO I think this is for historical reasons. AIX7 has DWARF support, but it looks like that's not yet implemented in GCC. Older AIX do not support DWARF, AFAICT (David E.?). * i686-apple-darwin - DBX_DEBUGGING_INFO MacOSX10.4, 32-bits (darwin8). All 64bits and darwin9+ prefer DWARF2. * i686-pc-cygwin, i686-mingw32 - DBX_DEBUGGING_INFO With binutils 2.16 and later, DWARF2_DEBUGGING_INFO is the default: http://sourceware.org/ml/binutils/2004-04/msg00327.html http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01885.html http://cygwin.com/ml/cygwin/2006-06/msg00865.html * s390x-linux-gnu - DWARF2_DEBUGGING_INFO Other platforms that support DWARF2+ and have it as the preferred type: * *-*-elf* via: config/elfos.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG This is practically all ELF platforms. A few target headers redefine PREFERRED_DEBUGGING_TYPE, usually to DWARF2_DEBUG again... Exceptions are microblaze*-*-rtems*, microblaze*-*-elf* * tic6x-*-*, ix86-*-nto-qnx* via: config/tm-dwarf2.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG * *-*-vxworks* via: config/vx-common.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG * alpha*-dec-*vms* via: config/alpha/vms.h:#define PREFERRED_DEBUGGING_TYPE VMS_AND_DWARF2_DEBUG * hppa*64*-*-hpux11* via: config/pa/pa64-hpux.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG Other platforms that support DWARF2+ but prefer another debug info type by default: * rx-*-elf* if using TARGET_AS100_SYNTAX, via: config/rx/rx.h:#define PREFERRED_DEBUGGING_TYPE (TARGET_AS100_SYNTAX \ config/rx/rx.h:? DBX_DEBUG : DWARF2_DEBUG) * avr-*-* includes elfos.h but changes preffered debug info type via: config/avr/elf.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG * powerpc-*-lynxos*, ix86-*-lynxos* include elfos.h but change the preffered debug info type via: config/lynx.h:# define PREFERRED_DEBUGGING_TYPE DBX_DEBUG * ix86-pc-msdosdjgpp*, supports DWARF2+ via: config/i386/djgpp.h:#define DWARF2_DEBUGGING_INFO 1 but
Re: [PING^5] PR 54805: __gthread_tsd* in vxlib-tls.c
On 18-Jan-13 20:35, Maxim Kuvyrkov wrote: On 19/01/2013, at 9:18 AM, rbmj wrote: -150,7 +158,7 @@ static __gthread_once_t tls_init_guard = need to read tls_keys.dtor[key] atomically. */ static void -tls_delete_hook (void *tcb ATTRIBUTE_UNUSED) +tls_delete_hook (void *tcb) Don't remove ATTRIBUTE_UNUSED. TCB was and will remain unused #ifdef __RTP__. And #ifndef __RTP__ ? No, simply leave that line as is. ATTRIBUTE_UNUSED tells the compiler that a variable can be unused, but not necessarily is unused. It's fine to have this attribute set on variables that are used under certain preprocessor configurations. Seems like I kept this email in drafts and never sent it out... Sorry about that. Here's the updated, (trivial) patch. -- Robert Mason diff a/libgcc/config/vxlib-tls.c b/libgcc/config/vxlib-tls.c --- a/libgcc/config/vxlib-tls.c +++ b/libgcc/config/vxlib-tls.c @@ -102,6 +102,14 @@ extern void __gthread_set_tls_data (void extern void __gthread_enter_tls_dtor_context (void); extern void __gthread_leave_tls_dtor_context (void); +#ifndef __RTP__ + +extern void *__gthread_get_tsd_data (WIND_TCB *tcb); +extern void __gthread_set_tsd_data (WIND_TCB *tcb, void *data); +extern void __gthread_enter_tsd_dtor_context (WIND_TCB *tcb); +extern void __gthread_leave_tsd_dtor_context (WIND_TCB *tcb); + +#endif /* __RTP__ */ /* This is a global structure which records all of the active keys. @@ -185,7 +193,7 @@ tls_delete_hook (void *tcb ATTRIBUTE_UNU #ifdef __RTP__ __gthread_leave_tls_dtor_context (); #else - __gthread_leave_tsd_dtor_context (); + __gthread_leave_tsd_dtor_context (tcb); #endif #ifdef __RTP__ -- 1.7.10.4
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
The AIX system supports DWARF debugging, but GCC does not generate it on AIX and GDB does not consume it on AIX. There is no way that I will allow experimental DWARF support to be enabled at the same time STABS support is removed. This is a non-starter. If you want to disable PCH on STABS systems on just AIX, that is fine. Thanks, David On Wed, Feb 13, 2013 at 4:12 PM, Steven Bosscher stevenb@gmail.com wrote: On Wed, Feb 13, 2013 at 4:54 PM, Jakub Jelinek wrote: Hi! As agreed on in the PR, here is the revertion of 3 commits, so that PCH works again for -gstabs and other debug info formats for 4.8 release. For 4.9 we should either remove support for anything non-DWARF, or hope somebody steps up and fixes dbxout.c etc. not to emit debug info right away, but queue it till end of compilation. Hello, I'd still like to propose deprecating all stabs support for GCC 4.8 and remove it for GCC 4.9 (i.e. dbxout, sdbout, xcoffout). It's not a very useful debug info format, after all. The only argument against DWARF, that it is so much larger than stabs, is something I haven't been able to reproduce (see http://sourceware.org/ml/binutils/2013-01/msg00221.html and http://sourceware.org/ml/binutils/2013-01/msg00239.html). DWARF compression via dwz, and debug-fission will improve things even further. An important question is of course: Who still *needs* stabs? If there are important platforms that need stabs support to continue to work, then deprecating is probably not a realistic option yet... The list of platforms that are IMHO blockers rights now, with possible solutions for GCC 4.9, are: * hppa2.0w-hp-hpux11.11 - no solution immediately available * powerpc-ibm-aix* - only support AIX7 and later - deprecate AIX6 and older in GCC 4.8 * ix86-*-openbsd2.*, ix86-*openbsd3.[0123] - OpenBSD 3.3 was released in May 2003 - deprecate for GCC 4.8 * m68k*-*-openbsd - port has seen no active maintenance, and has no test results posted, ever - deprecate for GCC 4.8 * pdp11-*-* - toy port - default to DEBUG_NONE * ix86-*-interix* - no solution immediately available, and no-one listed in MAINTAINERS to ask for help, so maybe Doug can say something about this one? Platforms that support DWARF2+ but currently have another default preferred debug info type, would be changed to default to DWARF2+. So older AIX and 32-bits HPUX are the only real problem cases. Ciao! Steven All GCC 4.8 primary platforms support DWARF2+, and AFAICT they all have it as their PREFERRED_DEBUGGING_TYPE (including freebsd): * arm-linux-gnueabi * i386-unknown-freebsd * i686-pc-linux-gnu * mipsisa64-elf * powerpc64-unknown-linux-gnu * sparc-sun-solaris2.10 * x86_64-unknown-linux-gnu Most of the above also include other debug info types by default, but DWARF2+ is the default. For the secondary platforms list things are not so simple. Some of them have a non-DWARF PREFERRED_DEBUGGING_TYPE by default, and some only conditionally (old configurations): * hppa2.0w-hp-hpux11.11 - DBX_DEBUGGING_INFO For 32-bits only, but that's the most common subtarget. According to Dave, it should be possible to add DRAWF2+ support: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117#c14 Perhaps Dave can explain what would have to be done to move this platform to DWARF2...? * powerpc-ibm-aix7.1.0.0 - XCOFF_DEBUGGING_INFO I think this is for historical reasons. AIX7 has DWARF support, but it looks like that's not yet implemented in GCC. Older AIX do not support DWARF, AFAICT (David E.?). * i686-apple-darwin - DBX_DEBUGGING_INFO MacOSX10.4, 32-bits (darwin8). All 64bits and darwin9+ prefer DWARF2. * i686-pc-cygwin, i686-mingw32 - DBX_DEBUGGING_INFO With binutils 2.16 and later, DWARF2_DEBUGGING_INFO is the default: http://sourceware.org/ml/binutils/2004-04/msg00327.html http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01885.html http://cygwin.com/ml/cygwin/2006-06/msg00865.html * s390x-linux-gnu - DWARF2_DEBUGGING_INFO Other platforms that support DWARF2+ and have it as the preferred type: * *-*-elf* via: config/elfos.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG This is practically all ELF platforms. A few target headers redefine PREFERRED_DEBUGGING_TYPE, usually to DWARF2_DEBUG again... Exceptions are microblaze*-*-rtems*, microblaze*-*-elf* * tic6x-*-*, ix86-*-nto-qnx* via: config/tm-dwarf2.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG * *-*-vxworks* via: config/vx-common.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG * alpha*-dec-*vms* via: config/alpha/vms.h:#define PREFERRED_DEBUGGING_TYPE VMS_AND_DWARF2_DEBUG * hppa*64*-*-hpux11* via: config/pa/pa64-hpux.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG Other platforms that support DWARF2+ but prefer another debug info type by default: * rx-*-elf* if using TARGET_AS100_SYNTAX, via: config/rx/rx.h:#define
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On 02/13/2013 01:12 PM, Steven Bosscher wrote: * ix86-*-interix* - no solution immediately available, and no-one listed in MAINTAINERS to ask for help, so maybe Doug can say something about this one? Microsoft has pulled the plug on Interix, Windows 7 will be the last version of Windows in which it will be available. There's a 64-bit gcc/binutils port to Interix, yet to be contributed, for which the plan is to use Dwarf but the GDB work hasn't been done. I suppose that if does get done, then it would be straightforward to backport Dwarf support to 32bit Interix. So I'm ok with losing stabs in the medium term, or the short term if Interix is the lone hold out. --Doug
Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)
On Wed, Feb 13, 2013 at 12:14 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb 13, 2013 at 10:57:42AM -0800, Sriraman Tallam wrote:
I committed a trivial patch to fix this problem. mv12-aux.C is
auxiliary to mv12.C and should have the same test directives as
mv12.C.
2013-02-13 Sriraman Tallam tmsri...@google.com
* g++.dg/ext/mv12-aux.C: Add directives to match mv12.C.
Better would be to rename
g++.dg/ext/mv12-aux.C to g++.dg/ext/mv12-aux.cc and remove all dg-*
directives from it, plus adjust dg-additional-sources in mv12.C.
The dg.exp driver is only looking for *.C testcases, so it will skip
*.cc, which is what you want.
Committed patch which does exactly this.
2013-02-13 Sriraman Tallam tmsri...@google.com
* g++.dg/ext/mv12-aux.C: Delete, move to mv12-aux.cc.
* g++.dg/ext/mv12-aux.cc: New file.
* g++.dg/ext/mv12.h: Remove directives. Fix comment.
* g++.dg/ext/mv12.C: Fix file name.
Index: mv12-aux.cc
===
--- mv12-aux.cc (revision 0)
+++ mv12-aux.cc (revision 0)
@@ -0,0 +1,10 @@
+// Test case to check if multiversioning works as expected when the versions
+// are defined in different files. Auxiliary file for mv12.C.
+
+#include mv12.h
+
+__attribute__ ((target (sse4.2)))
+int foo ()
+{
+ return 1;
+}
Index: mv12.C
===
--- mv12.C (revision 196025)
+++ mv12.C (working copy)
@@ -4,7 +4,7 @@
// { dg-do run { target i?86-*-* x86_64-*-* } }
// { dg-require-ifunc }
// { dg-options -O2 }
-// { dg-additional-sources mv12-aux.C }
+// { dg-additional-sources mv12-aux.cc }
#include mv12.h
Index: mv12.h
===
--- mv12.h (revision 196025)
+++ mv12.h (working copy)
@@ -1,6 +1,4 @@
-// Header file used by mv12.C and mv12-aux.C.
-// { dg-do compile { target i?86-*-* x86_64-*-* } }
-// { dg-options }
+// Header file used by mv12.C and mv12-aux.cc.
int foo () __attribute__ ((target (default)));
int foo () __attribute__ ((target (sse4.2)));
Index: mv12-aux.C
===
--- mv12-aux.C (revision 196025)
+++ mv12-aux.C (working copy)
@@ -1,14 +0,0 @@
-// Test case to check if multiversioning works as expected when the versions
-// are defined in different files. Auxiliary file for mv12.C.
-
-// { dg-do compile { target i?86-*-* x86_64-*-* } }
-// { dg-require-ifunc }
-// { dg-options -O2 }
-
-#include mv12.h
-
-__attribute__ ((target (sse4.2)))
-int foo ()
-{
- return 1;
-}
Thanks
Sri
--- g++.dg/ext/mv12-aux.C (revision 196025)
+++ g++.dg/ext/mv12-aux.C (working copy)
@@ -1,7 +1,10 @@
// Test case to check if multiversioning works as expected when the versions
// are defined in different files. Auxiliary file for mv12.C.
-// { dg-do compile }
+// { dg-do compile { target i?86-*-* x86_64-*-* } }
+// { dg-require-ifunc }
+// { dg-options -O2 }
+
#include mv12.h
This should fix the problem.
Jakub
Re: [cxx-conversion] Add Record Builder Class
On 2/13/13, Diego Novillo dnovi...@google.com wrote: Thanks. The patch is OK for the branch. You can address Nathan's review after he's back and gets a chance to look at it. Let me know when the patch is in. I've got another merge in process. Committed. -- Lawrence Crowl
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On 02/13/13 13:07, Jakub Jelinek wrote:
On Wed, Feb 13, 2013 at 11:23:24AM -0700, Jeff Law wrote:
On 02/13/13 08:54, Jakub Jelinek wrote:
That looks just like the patch I have here. Yet, I'm still seeing failures:
Running target unix/-m32/-gstabs
Using /usr/share/dejagnu/baseboards/unix.exp as board description
file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file
for target.
Using /home/gcc/GIT/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /home/gcc/GIT/gcc/gcc/testsuite/gcc.dg/pch/pch.exp ...
FAIL: gcc.dg/pch/decl-3.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O0 assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O1 assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O2 assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O3 -fomit-frame-pointer assembly comparison
FAIL: gcc.dg/pch/decl-3.c -O3 -g assembly comparison
FAIL: gcc.dg/pch/decl-3.c -Os assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O0 assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O1 assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O2 assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O3 -fomit-frame-pointer assembly comparison
FAIL: gcc.dg/pch/decl-4.c -O3 -g assembly comparison
FAIL: gcc.dg/pch/decl-4.c -Os assembly comparison
[ ... ]
Can you double-check your testing output?
Yes, I've double checked it. Fresh trunk, got all of
gcc.dg/pch/{decl-{3,4},struct-1,system-1,valid-1}.c failures
for -m32/-gstabs as well as -m64/-gstabs, both with gcc
that has #define HAVE_GAS_CFI_DIRECTIVE {0,1} in auto-host.h.
Applying the patch cured all of those failures, except for
valid-1.c (which is fine, as that test assumes no -g* switches
be present by default).
I just wiped clean and tried again using your patch and I still see
massive failures with -gstabs.
I'd like to know why we're getting different results before approving
the patch.
jeff
RFC: [MIPS] Add an option to disable ldc1/sdc1
Hello All, Once in a while we got reports about programs (ex: WebKit, FireFox) crash due to ldc1/sdc1 unaligned accesses on MIPS targets. The root cause is that programmers neglect the alignment issue and cast arbitrary pointers to point to double variables. Although the correct solution is to fix application source code to fulfill alignment requirements, we want to add a GCC option to disable ldc1 and sdc1 (for the testing purpose or for workaround). On 32-bit MIPS targets, GCC generates lwc1 and swc1 when -mno-ldc1-sdc1 is used, so that the memory address can be just 4-byte aligned to avoid ldc1/sdc1 address exceptions. Ex: (The proposed patch) Index: mips.opt === --- mips.opt(revision 196026) +++ mips.opt(working copy) @@ -233,6 +233,10 @@ Target Report RejectNegative Mask(MIPS3D) Use MIPS-3D instructions +mldc1-sdc1 +Target Report Var(TARGET_LDC1_SDC1) Init(1) +Use ldc1 and sdc1 instruction + mllsc Target Report Mask(LLSC) Use ll, sc and sync instructions Index: mips.h === --- mips.h (revision 196026) +++ mips.h (working copy) @@ -840,8 +840,9 @@ ST Loongson 2E/2F. */ #define ISA_HAS_CONDMOVE(ISA_HAS_FP_CONDMOVE || TARGET_LOONGSON_2EF) -/* ISA has LDC1 and SDC1. */ -#define ISA_HAS_LDC1_SDC1 (!ISA_MIPS1 !TARGET_MIPS16) +/* ISA has LDC1 and SDC1 and they are enabled. */ +#define ISA_HAS_LDC1_SDC1 \ + (!ISA_MIPS1 !TARGET_MIPS16 TARGET_LDC1_SDC1) /* ISA has the mips4 FP condition code instructions: FP-compare to CC, branch on CC, and move (both FP and non-FP) on CC. */ Any feedback? Thanks a lot! Regards, Chao-ying
Re: [PATCH][IRA] Analysis of register usage of functions for usage by IRA.
On 13-02-07 2:11 PM, Tom de Vries wrote: Vladimir, On 25/01/13 16:36, Vladimir Makarov wrote: On 01/25/2013 08:05 AM, Tom de Vries wrote: Vladimir, this patch adds analysis of register usage of functions for usage by IRA. The patch: - adds analysis in pass_final to track which hard registers are set or clobbered by the function body, and stores that information in a struct cgraph_node. - adds a target hook fn_other_hard_reg_usage to list hard registers that are set or clobbered by a call to a function, but are not listed as such in the function body, such as f.i. registers clobbered by veneers inserted by the linker. - adds a reg-note REG_CALL_DECL, to be able to easily link call_insns to their corresponding declaration, even after the calls may have been split into an insn (set register to function address) and a call_insn (call register), which can happen for f.i. sh, and mips with -mabi-calls. - uses the register analysis in IRA. - adds an option -fuse-caller-save to control the optimization, on by default at -Os and -O2 and higher. SNIP Bootstrapped and reg-tested on x86_64, Ada inclusive. Build and reg-tested on mips, arm, ppc and sh. No issues found. OK for stage1 trunk? Thanks for the patch. I'll look at it during the next week. Did you get a chance to look at this? Sorry for the delay with the answer. I was and am quite busy with other more urgent things. I'll work on it when I have more free time. In any case, I'll do it before stage1 to have your patch ready. Right now I see that the code is based on reload which uses caller-saves.c. LRA does not use caller-saves.c at all. Right now we have LRA support only for x86/x86-64 but the next version will probably have a few more targets based on LRA. Fortunately, LRA modification will be pretty easy with all this machinery. I see, thanks for noticing that. Btw I'm now working on a testsuite construct dg-size-compare to be able to do dg-size-compare text -fuse-caller-save -fno-use-caller-save which I could have used to create a generic testcase, which would have demonstrated that the optimization didn't work for x86_64. I thought about implementing your optimization for LRA by myself. But it is ok if you decide to work on it. At least, I am not going to start this work for a month. I'm also currently looking at how to use the analysis in LRA. AFAIU, in lra-constraints.c we do a backward scan over the insns, and keep track of how many calls we've seen (calls_num), and mark insns with that number. Then when looking at a live-range segment consisting of a def or use insn a and a following use insn b, we can compare the number of calls seen for each insn, and if they're not equal there is at least one call between the 2 insns, and if the corresponding hard register is clobbered by calls, we spill after insn a and restore before insn b. That is too coarse-grained to use with our analysis, since we need to know which calls occur in between insn a and insn b, and more precisely which registers those calls clobbered. I wonder though if we can do something similar: we keep an array call_clobbers_num[FIRST_PSEUDO_REG], initialized at 0 when we start scanning. When encountering a call, we increase the call_clobbers_num entries for the hard registers clobbered by the call. When encountering a use, we set the call_clobbers_num field of the use to call_clobbers_num[reg_renumber[original_regno]]. And when looking at a live-range segment, we compare the clobbers_num field of insn a and insn b, and if it is not equal, the hard register was clobbered by at least one call between insn a and insn b. Would that work? WDYT? As I understand you looked at live-range splitting code in lra-constraints.c. To get necessary info you should look at ira-lives.c. I am going to use ira-improv branch for some my future work for gcc4.9. And I am going to regularly (about once per month) merge trunk into it. So if you want you could use the branch for your work too. But this is absolutely up to you. I don't mind if you put this patch directly to the trunk at stage1 when the review is finished. OK, I'd say stage1 then unless during review a reason pops up why it's better to use the ira-improv branch. That is ok. Stage1 then.
Document ?: for vectors
Hello,
today I found this patch that I had written a couple months ago, and I am
wondering whether we want it for 4.8. I am tempted to keep ?: undocumented
as long as the C front-end doesn't have it. The fact that very few
optimizations are done on it (and some might still be broken) is another
argument in this direction. On the other hand, it is there, we might as
well document it.
2013-02-13 Marc Glisse marc.gli...@inria.fr
* doc/extend.texi (Vector Extensions): Document ?: in C++.
--
Marc GlisseIndex: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 196034)
+++ gcc/doc/extend.texi (working copy)
@@ -6990,20 +6990,30 @@ otherwise. Consider the following exampl
typedef int v4si __attribute__ ((vector_size (16)));
v4si a = @{1,2,3,4@};
v4si b = @{3,2,1,4@};
v4si c;
c = a b; /* The result would be @{0, 0,-1, 0@} */
c = a == b; /* The result would be @{0,-1, 0,-1@} */
@end smallexample
+In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
+@code{b} and @code{c} are vectors of the same type and @code{a} is an
+integer vector of the same size and number of elements as @code{b} and
+@code{c}, computes all three arguments and creates a vector
+@code{@{a[0]?b[0]:c[0], a[1]?b[1]:c[1], @dots{}@}}. Note that unlike in
+OpenCL, @code{a} is thus interpreted as @code{a != 0} and not @code{a 0}.
+As in the case of binary operations, this syntax is also accepted when
+one of @code{b} or @code{c} is a scalar that is then transformed into a
+vector.
+
Vector shuffling is available using functions
@code{__builtin_shuffle (vec, mask)} and
@code{__builtin_shuffle (vec0, vec1, mask)}.
Both functions construct a permutation of elements from one or two
vectors and return a vector of the same type as the input vector(s).
The @var{mask} is an integral vector with the same width (@var{W})
and element count (@var{N}) as the output vector.
The elements of the input vectors are numbered in memory ordering of
@var{vec0} beginning at 0 and @var{vec1} beginning at @var{N}. The
Re: RFC: [MIPS] Add an option to disable ldc1/sdc1
On Wed, Feb 13, 2013 at 2:14 PM, Chao-Ying Fu chao-ying...@imgtec.com wrote: Hello All, Once in a while we got reports about programs (ex: WebKit, FireFox) crash due to ldc1/sdc1 unaligned accesses on MIPS targets. The root cause is that programmers neglect the alignment issue and cast arbitrary pointers to point to double variables. And the code is undefined C/C++ anyways and should really be fixed rather this workaround. If the upstream vendor is not willing to fix undefined code then it is their fault the code does not work rather than the compiler's. Thanks, Andrew Pinski Although the correct solution is to fix application source code to fulfill alignment requirements, we want to add a GCC option to disable ldc1 and sdc1 (for the testing purpose or for workaround). On 32-bit MIPS targets, GCC generates lwc1 and swc1 when -mno-ldc1-sdc1 is used, so that the memory address can be just 4-byte aligned to avoid ldc1/sdc1 address exceptions. Ex: (The proposed patch) Index: mips.opt === --- mips.opt(revision 196026) +++ mips.opt(working copy) @@ -233,6 +233,10 @@ Target Report RejectNegative Mask(MIPS3D) Use MIPS-3D instructions +mldc1-sdc1 +Target Report Var(TARGET_LDC1_SDC1) Init(1) +Use ldc1 and sdc1 instruction + mllsc Target Report Mask(LLSC) Use ll, sc and sync instructions Index: mips.h === --- mips.h (revision 196026) +++ mips.h (working copy) @@ -840,8 +840,9 @@ ST Loongson 2E/2F. */ #define ISA_HAS_CONDMOVE(ISA_HAS_FP_CONDMOVE || TARGET_LOONGSON_2EF) -/* ISA has LDC1 and SDC1. */ -#define ISA_HAS_LDC1_SDC1 (!ISA_MIPS1 !TARGET_MIPS16) +/* ISA has LDC1 and SDC1 and they are enabled. */ +#define ISA_HAS_LDC1_SDC1 \ + (!ISA_MIPS1 !TARGET_MIPS16 TARGET_LDC1_SDC1) /* ISA has the mips4 FP condition code instructions: FP-compare to CC, branch on CC, and move (both FP and non-FP) on CC. */ Any feedback? Thanks a lot! Regards, Chao-ying
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On 2013-02-13 3:33 PM, David Edelsohn wrote: Perhaps Dave can explain what would have to be done to move this platform to DWARF2...? I had looked at this a bit in the past. I don't think it's that difficult to add DWARF2 support to GCC on hppa. Although we don't support named sections, we can create named subspaces for the dwarf info. More of an issue in my mind is the changes needed to gdb to recognize this support. I agree with David that it might be better to give up pch.
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Thu, Feb 14, 2013 at 12:17 AM, John David Anglin wrote:
On 2013-02-13 3:33 PM, David Edelsohn wrote:
Perhaps Dave can explain what would have to be done to move this
platform to DWARF2...?
I had looked at this a bit in the past. I don't think it's that difficult
to add DWARF2 support
to GCC on hppa. Although we don't support named sections, we can create
named subspaces
for the dwarf info. More of an issue in my mind is the changes needed to
gdb to recognize
this support.
I agree with David that it might be better to give up pch.
That'd be a really a good start.
How about something like the attached patch for trunk?
Tested on powerpc64-linux pch.exp with -gstabs.
Ciao!
Steven
c-family/
* c-opts.c (c_common_handle_option): Warn that pre-compiled headers
with debug formats other than DWARF are deprecated.
testsuite/
* lib/dg-pch.exp: Compile the PCH with extra flag -Wno-deprecated.
c-family/
* c-opts.c (c_common_handle_option): Warn that pre-compiled headers
with debug formats other than DWARF are deprecated.
testsuite/
* lib/dg-pch.exp: Compile the PCH with extra flag -Wno-deprecated.
Index: c-family/c-opts.c
===
--- c-family/c-opts.c (revision 196032)
+++ c-family/c-opts.c (working copy)
@@ -268,6 +268,10 @@ c_common_handle_option (size_t scode, const char *
break;
case OPT__output_pch_:
+ if (write_symbols != NO_DEBUG write_symbols != DWARF2_DEBUG)
+ warning (OPT_Wdeprecated,
+the \%s\ debug format cannot be used with pre-compiled
headers,
+debug_type_names[write_symbols]);
pch_file = arg;
break;
Index: testsuite/lib/dg-pch.exp
===
--- testsuite/lib/dg-pch.exp(revision 196032)
+++ testsuite/lib/dg-pch.exp(working copy)
@@ -39,8 +39,12 @@ proc dg-flags-pch { subdir test otherflags options
set dg-do-what-default precompile
catch { file_on_host delete $bname$suffix }
gcc_copy_files [file rootname $test]${suffix}s $bname$suffix
- dg-test -keep-output ./$bname$suffix $otherflags $flags
+ # Suppress -Wdeprecated to allow PCH tests to work with non-DWARF2
+ # debug formats. Support for such combinations has been deprecated
+ # for GCC 4.8.
+ dg-test -keep-output ./$bname$suffix $otherflags $flags
-Wno-deprecated
+
# For the rest, the default is to compile to .s.
set dg-do-what-default compile
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Thu, Feb 14, 2013 at 12:41:30AM +0100, Steven Bosscher wrote: I agree with David that it might be better to give up pch. That'd be a really a good start. You can do it with say following patch instead, PCH is just a compile time optimization, so for -gstabs IMHO it is just fine if we just give up. --- gcc/c-family/c-opts.c.jj2013-02-13 23:48:14.0 +0100 +++ gcc/c-family/c-opts.c 2013-02-14 00:41:05.325625590 +0100 @@ -943,8 +943,11 @@ c_common_post_options (const char **pfil /* When writing a PCH file, avoid reading some other PCH file, because the default address space slot then can't be used -for the output PCH file. */ - if (pch_file) +for the output PCH file. Also, avoid reading PCH files when +debug info in format other than DWARF is requested. */ + if (pch_file + || (write_symbols != NO_DEBUG + write_symbols != DWARF2_DEBUG)) c_common_no_more_pch (); /* Yuk. WTF is this? I do know ObjC relies on it somewhere. */ Jakub
[google][4.7] Minor Function reordering plugin enhancements.
Hi,
I have attached a patch for the reordering plugin to display
appropriate error messages when incorrect options are passed or when
some API is unavailable.
The plugin will use the ld_plugin_message linker API to flag errors
(fatal or non-fatal) when incorrect options are passed or when the
required API is not available in the invoking linker. If the message
API is missing, then it falls back to using fprintf.
Thanks
Sri
Index: function_reordering_plugin.c
===
--- function_reordering_plugin.c(revision 196036)
+++ function_reordering_plugin.c(working copy)
@@ -69,6 +69,7 @@ enum ld_plugin_status claim_file_hook (const struc
int *claimed);
enum ld_plugin_status all_symbols_read_hook ();
+static ld_plugin_message message = NULL;
static ld_plugin_register_claim_file register_claim_file_hook = NULL;
static ld_plugin_register_all_symbols_read
register_all_symbols_read_hook = NULL;
@@ -88,8 +89,6 @@ static ld_plugin_unique_segment_for_sections uniqu
static char *out_file = NULL;
-static int is_api_exist = 0;
-
/* The plugin does nothing when no-op is 1. */
static int no_op = 0;
@@ -105,12 +104,30 @@ void get_filename (const char *name)
strcpy (out_file, name);
}
+/* MSG_FATAL prints a format string and aborts. Uses the plugin API if
+ available, otherwise falls back to using fprintf. */
+
+#define MSG_FATAL(...) \
+ if (message) { \
+message (LDPL_FATAL, __VA_ARGS__); } \
+ else { \
+fprintf (stderr, fatal: __VA_ARGS__); abort (); }
+
+/* MSG_ERROR prints a format string. Uses the plugin API if
+ available, otherwise falls back to using fprintf. */
+
+#define MSG_ERROR(...) \
+ if (message) { \
+message (LDPL_ERROR, __VA_ARGS__); } \
+ else { \
+fprintf (stderr, error: __VA_ARGS__); }
+
/* Process options to plugin. Options with prefix group= are special.
They specify the type of grouping. The option group=none makes the
plugin do nothing. Options with prefix file= set the output file
where the final function order must be stored. Option segment=none
does not place the cold code in a separate ELF segment. */
-void
+static int
process_option (const char *name)
{
const char *option_group = group=;
@@ -124,13 +141,13 @@ process_option (const char *name)
no_op = 1;
else
no_op = 0;
- return;
+ return 0;
}
/* Check if option is file= */
else if (strncmp (name, option_file, strlen (option_file)) == 0)
{
get_filename (name + strlen (option_file));
- return;
+ return 0;
}
/* Check if options is split_segment=[yes|no] */
else if (strncmp (name, option_segment, strlen (option_segment)) == 0)
@@ -139,19 +156,18 @@ process_option (const char *name)
if (strcmp (option_val, no) == 0)
{
split_segment = 0;
- return;
+ return 0;
}
else if (strcmp (option_val, yes) == 0)
{
split_segment = 1;
- return;
+ return 0;
}
}
- /* Unknown option, set no_op to 1. */
- no_op = 1;
- fprintf (stderr, Unknown option to function reordering plugin :%s\n,
- name);
+ /* Flag error on unknown plugin option. */
+ MSG_ERROR (Unknown option to function reordering plugin :%s\n, name);
+ return 1;
}
/* Plugin entry point. */
@@ -168,10 +184,14 @@ onload (struct ld_plugin_tv *tv)
case LDPT_GOLD_VERSION:
break;
case LDPT_OPTION:
- process_option (entry-tv_u.tv_string);
+ if (process_option (entry-tv_u.tv_string) == 1)
+ return LDPS_ERR;
/* If no_op is set, do not do anything else. */
if (no_op) return LDPS_OK;
break;
+ case LDPT_MESSAGE:
+ message = *entry-tv_u.tv_message;
+ break;
case LDPT_REGISTER_CLAIM_FILE_HOOK:
register_claim_file_hook = *entry-tv_u.tv_register_claim_file;
break;
@@ -211,21 +231,29 @@ onload (struct ld_plugin_tv *tv)
assert (!no_op);
- if (register_all_symbols_read_hook != NULL
- register_claim_file_hook != NULL
- get_input_section_count != NULL
- get_input_section_type != NULL
- get_input_section_name != NULL
- get_input_section_contents != NULL
- update_section_order != NULL
- allow_section_ordering != NULL
- allow_unique_segment_for_sections != NULL
- unique_segment_for_sections != NULL)
-is_api_exist = 1;
- else
-return LDPS_OK;
+ /* If the API for code reordering is missing, abort! */
+ if (register_all_symbols_read_hook == NULL
+ || register_claim_file_hook == NULL
+ || get_input_section_count == NULL
+ || get_input_section_type == NULL
+ || get_input_section_name == NULL
+ || get_input_section_contents == NULL
+ || update_section_order == NULL
+ || allow_section_ordering ==
Re: [google][4.7] Minor Function reordering plugin enhancements.
when split_segment is specified but the API does not exist, why not making it fatal ? Will it crash at some point when the null pointer is referenced later? David On Wed, Feb 13, 2013 at 4:19 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, I have attached a patch for the reordering plugin to display appropriate error messages when incorrect options are passed or when some API is unavailable. The plugin will use the ld_plugin_message linker API to flag errors (fatal or non-fatal) when incorrect options are passed or when the required API is not available in the invoking linker. If the message API is missing, then it falls back to using fprintf. Thanks Sri
Re: [google][4.7] Minor Function reordering plugin enhancements.
On Wed, Feb 13, 2013 at 4:32 PM, Xinliang David Li davi...@google.com wrote: when split_segment is specified but the API does not exist, why not making it fatal ? Will it crash at some point when the null pointer is referenced later? It cannot be referenced later as the handlers will not get registered. I will make this fatal too however. Thanks Sri David On Wed, Feb 13, 2013 at 4:19 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, I have attached a patch for the reordering plugin to display appropriate error messages when incorrect options are passed or when some API is unavailable. The plugin will use the ld_plugin_message linker API to flag errors (fatal or non-fatal) when incorrect options are passed or when the required API is not available in the invoking linker. If the message API is missing, then it falls back to using fprintf. Thanks Sri
Re: [google][4.7] Minor Function reordering plugin enhancements.
Updated patch attached.
Thanks
Sri
On Wed, Feb 13, 2013 at 4:39 PM, Sriraman Tallam tmsri...@google.com wrote:
On Wed, Feb 13, 2013 at 4:32 PM, Xinliang David Li davi...@google.com wrote:
when split_segment is specified but the API does not exist, why not
making it fatal ? Will it crash at some point when the null pointer is
referenced later?
It cannot be referenced later as the handlers will not get registered.
I will make this fatal too however.
Thanks
Sri
David
On Wed, Feb 13, 2013 at 4:19 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
I have attached a patch for the reordering plugin to display
appropriate error messages when incorrect options are passed or when
some API is unavailable.
The plugin will use the ld_plugin_message linker API to flag errors
(fatal or non-fatal) when incorrect options are passed or when the
required API is not available in the invoking linker. If the message
API is missing, then it falls back to using fprintf.
Thanks
Sri
Index: function_reordering_plugin.c
===
--- function_reordering_plugin.c(revision 196036)
+++ function_reordering_plugin.c(working copy)
@@ -69,6 +69,7 @@ enum ld_plugin_status claim_file_hook (const struc
int *claimed);
enum ld_plugin_status all_symbols_read_hook ();
+static ld_plugin_message message = NULL;
static ld_plugin_register_claim_file register_claim_file_hook = NULL;
static ld_plugin_register_all_symbols_read
register_all_symbols_read_hook = NULL;
@@ -88,8 +89,6 @@ static ld_plugin_unique_segment_for_sections uniqu
static char *out_file = NULL;
-static int is_api_exist = 0;
-
/* The plugin does nothing when no-op is 1. */
static int no_op = 0;
@@ -105,12 +104,30 @@ void get_filename (const char *name)
strcpy (out_file, name);
}
+/* MSG_FATAL prints a format string and aborts. Uses the plugin API if
+ available, otherwise falls back to using fprintf. */
+
+#define MSG_FATAL(...) \
+ if (message) { \
+message (LDPL_FATAL, __VA_ARGS__); } \
+ else { \
+fprintf (stderr, fatal: __VA_ARGS__); abort (); }
+
+/* MSG_ERROR prints a format string. Uses the plugin API if
+ available, otherwise falls back to using fprintf. */
+
+#define MSG_ERROR(...) \
+ if (message) { \
+message (LDPL_ERROR, __VA_ARGS__); } \
+ else { \
+fprintf (stderr, error: __VA_ARGS__); }
+
/* Process options to plugin. Options with prefix group= are special.
They specify the type of grouping. The option group=none makes the
plugin do nothing. Options with prefix file= set the output file
where the final function order must be stored. Option segment=none
does not place the cold code in a separate ELF segment. */
-void
+static int
process_option (const char *name)
{
const char *option_group = group=;
@@ -124,13 +141,13 @@ process_option (const char *name)
no_op = 1;
else
no_op = 0;
- return;
+ return 0;
}
/* Check if option is file= */
else if (strncmp (name, option_file, strlen (option_file)) == 0)
{
get_filename (name + strlen (option_file));
- return;
+ return 0;
}
/* Check if options is split_segment=[yes|no] */
else if (strncmp (name, option_segment, strlen (option_segment)) == 0)
@@ -139,19 +156,18 @@ process_option (const char *name)
if (strcmp (option_val, no) == 0)
{
split_segment = 0;
- return;
+ return 0;
}
else if (strcmp (option_val, yes) == 0)
{
split_segment = 1;
- return;
+ return 0;
}
}
- /* Unknown option, set no_op to 1. */
- no_op = 1;
- fprintf (stderr, Unknown option to function reordering plugin :%s\n,
- name);
+ /* Flag error on unknown plugin option. */
+ MSG_ERROR (Unknown option to function reordering plugin :%s\n, name);
+ return 1;
}
/* Plugin entry point. */
@@ -168,10 +184,14 @@ onload (struct ld_plugin_tv *tv)
case LDPT_GOLD_VERSION:
break;
case LDPT_OPTION:
- process_option (entry-tv_u.tv_string);
+ if (process_option (entry-tv_u.tv_string) == 1)
+ return LDPS_ERR;
/* If no_op is set, do not do anything else. */
if (no_op) return LDPS_OK;
break;
+ case LDPT_MESSAGE:
+ message = *entry-tv_u.tv_message;
+ break;
case LDPT_REGISTER_CLAIM_FILE_HOOK:
register_claim_file_hook = *entry-tv_u.tv_register_claim_file;
break;
@@ -211,20 +231,27 @@ onload (struct ld_plugin_tv *tv)
assert (!no_op);
- if (register_all_symbols_read_hook != NULL
- register_claim_file_hook != NULL
- get_input_section_count != NULL
- get_input_section_type != NULL
- get_input_section_name != NULL
- get_input_section_contents != NULL
- update_section_order != NULL
-
Re: [google][4.7] Minor Function reordering plugin enhancements.
ok. thanks, David On Wed, Feb 13, 2013 at 4:41 PM, Sriraman Tallam tmsri...@google.com wrote: Updated patch attached. Thanks Sri On Wed, Feb 13, 2013 at 4:39 PM, Sriraman Tallam tmsri...@google.com wrote: On Wed, Feb 13, 2013 at 4:32 PM, Xinliang David Li davi...@google.com wrote: when split_segment is specified but the API does not exist, why not making it fatal ? Will it crash at some point when the null pointer is referenced later? It cannot be referenced later as the handlers will not get registered. I will make this fatal too however. Thanks Sri David On Wed, Feb 13, 2013 at 4:19 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, I have attached a patch for the reordering plugin to display appropriate error messages when incorrect options are passed or when some API is unavailable. The plugin will use the ld_plugin_message linker API to flag errors (fatal or non-fatal) when incorrect options are passed or when the required API is not available in the invoking linker. If the message API is missing, then it falls back to using fprintf. Thanks Sri
