[avr,committed] Fix PR target/56445
http://gcc.gnu.org/r196332 This is obvious fix for problem with empty macro parameter. Instead of an empty parameter, 'n' is used. Johann PR target/56445 * config/avr/avr.c (avr_init_builtins): Use 'n' instead of empty macro parameters with: FX_FTYPE_FX, FX_FTYPE_FX_INT, INT_FTYPE_FX, INTX_FTYPE_FX, FX_FTYPE_INTX. * config/avr/builtins.def: Adjust respective DEF_BUILTIN. Index: config/avr/builtins.def === --- config/avr/builtins.def (revision 196331) +++ config/avr/builtins.def (revision 196332) @@ -62,78 +62,78 @@ DEF_BUILTIN (FLASH_SEGMENT, 1, char_ftyp /* 7.18a.6.2 The fixed-point absolute value functions. */ DEF_BUILTIN (ABSHR, 1, hr_ftype_hr, ssabsqq2, __ssabs_1) -DEF_BUILTIN (ABSR,1, r_ftype_r, ssabshq2, __ssabs_2) +DEF_BUILTIN (ABSR,1, nr_ftype_nr, ssabshq2, __ssabs_2) DEF_BUILTIN (ABSLR, 1, lr_ftype_lr, ssabssq2, __ssabs_4) DEF_BUILTIN (ABSLLR, -1, llr_ftype_llr, nothing, __ssabsdq2) // GCC extension DEF_BUILTIN (ABSHK, 1, hk_ftype_hk, ssabsha2, __ssabs_2) -DEF_BUILTIN (ABSK,1, k_ftype_k, ssabssa2, __ssabs_4) +DEF_BUILTIN (ABSK,1, nk_ftype_nk, ssabssa2, __ssabs_4) DEF_BUILTIN (ABSLK, -1, lk_ftype_lk, nothing, __ssabsda2) DEF_BUILTIN (ABSLLK, -1, llk_ftype_llk, nothing, __ssabsta2) // GCC extension /* 7.18a.6.3 The fixed-point round functions. */ DEF_BUILTIN (ROUNDHR,2, hr_ftype_hr_int, roundqq3, __roundhr) -DEF_BUILTIN (ROUNDR, 2, r_ftype_r_int, roundhq3, __roundr) +DEF_BUILTIN (ROUNDR, 2, nr_ftype_nr_int, roundhq3, __roundr) DEF_BUILTIN (ROUNDLR,2, lr_ftype_lr_int, roundsq3, __roundlr) DEF_BUILTIN (ROUNDLLR, -1, llr_ftype_llr_int, nothing, __rounddq3) // GCC extension DEF_BUILTIN (ROUNDUHR, 2, uhr_ftype_uhr_int, rounduqq3, __rounduhr) -DEF_BUILTIN (ROUNDUR,2, ur_ftype_ur_int, rounduhq3, __roundur) +DEF_BUILTIN (ROUNDUR,2, unr_ftype_unr_int, rounduhq3, __roundur) DEF_BUILTIN (ROUNDULR, 2, ulr_ftype_ulr_int, roundusq3, __roundulr) DEF_BUILTIN (ROUNDULLR, -1, ullr_ftype_ullr_int, nothing, __roundudq3) // GCC extension DEF_BUILTIN (ROUNDHK,2, hk_ftype_hk_int, roundha3, __roundhk) -DEF_BUILTIN (ROUNDK, 2, k_ftype_k_int, roundsa3, __roundk) +DEF_BUILTIN (ROUNDK, 2, nk_ftype_nk_int, roundsa3, __roundk) DEF_BUILTIN (ROUNDLK, -1, lk_ftype_lk_int, nothing, __roundda3) DEF_BUILTIN (ROUNDLLK, -1, llk_ftype_llk_int, nothing, __roundta3) // GCC extension DEF_BUILTIN (ROUNDUHK, 2, uhk_ftype_uhk_int, rounduha3, __rounduhk) -DEF_BUILTIN (ROUNDUK,2, uk_ftype_uk_int, roundusa3, __rounduk) +DEF_BUILTIN (ROUNDUK,2, unk_ftype_unk_int, roundusa3, __rounduk) DEF_BUILTIN (ROUNDULK, -1, ulk_ftype_ulk_int, nothing, __rounduda3) DEF_BUILTIN (ROUNDULLK, -1, ullk_ftype_ullk_int, nothing, __rounduta3) // GCC extension /* 7.18a.6.4 The fixed-point bit countls functions. */ DEF_BUILTIN (COUNTLSHR, -1, int_ftype_hr, nothing, __countlsqi2) -DEF_BUILTIN (COUNTLSR,-1, int_ftype_r,nothing, __countlshi2) +DEF_BUILTIN (COUNTLSR,-1, int_ftype_nr, nothing, __countlshi2) DEF_BUILTIN (COUNTLSLR, -1, int_ftype_lr, nothing, __countlssi2) DEF_BUILTIN (COUNTLSLLR, -1, int_ftype_llr, nothing, __countlsdi2) // GCC extension DEF_BUILTIN (COUNTLSUHR, -1, int_ftype_uhr, nothing, __countlsuqi2) -DEF_BUILTIN (COUNTLSUR, -1, int_ftype_ur, nothing, __countlsuhi2) +DEF_BUILTIN (COUNTLSUR, -1, int_ftype_unr, nothing, __countlsuhi2) DEF_BUILTIN (COUNTLSULR, -1, int_ftype_ulr, nothing, __countlsusi2) DEF_BUILTIN (COUNTLSULLR, -1, int_ftype_ullr, nothing, __countlsudi2) // GCC extension DEF_BUILTIN (COUNTLSHK, -1, int_ftype_hk, nothing, __countlshi2) -DEF_BUILTIN (COUNTLSK,-1, int_ftype_k,nothing, __countlssi2) +DEF_BUILTIN (COUNTLSK,-1, int_ftype_nk, nothing, __countlssi2) DEF_BUILTIN (COUNTLSLK, -1, int_ftype_lk, nothing, __countlsdi2) DEF_BUILTIN (COUNTLSLLK, -1, int_ftype_llk, nothing, __countlsdi2) // GCC extension DEF_BUILTIN (COUNTLSUHK, -1, int_ftype_uhk, nothing, __countlsuhi2) -DEF_BUILTIN (COUNTLSUK, -1, int_ftype_uk, nothing, __countlsusi2) +DEF_BUILTIN (COUNTLSUK, -1, int_ftype_unk, nothing, __countlsusi2) DEF_BUILTIN (COUNTLSULK, -1, int_ftype_ulk, nothing, __countlsudi2) DEF_BUILTIN (COUNTLSULLK, -1, int_ftype_ullk, nothing, __countlsudi2) // GCC extension /* 7.18a.6.5 The bitwise fixed-point to integer conversion functions. */ DEF_BUILTIN (BITSHR, -1, inthr_ftype_hr, nothing, __ret) -DEF_BUILTIN (BITSR,-1,intr_ftype_r,nothing, __ret) +DEF_BUILTIN (BITSR,-1, intnr_ftype_nr, nothing, __ret) DEF_BUILTIN (BITSLR, -1, intlr_ftype_lr, nothing, __ret) DEF_BUILTIN (BITSLLR, -1, intllr_ftype_llr, nothing, __ret) // GCC extension DEF_BUILTIN (BITSUHR, -1, intuhr_ftype_uhr, nothing, __ret)
[AArch64/AArch64-4.7] Fix warning - No previous prototype for aarch64_init_simd_builtins.
Hi,
aarch64_init_simd_buitlins is not declared with a prototype, but it
doesn't need one as it should be declared static.
This patch fixes the warning:
config/aarch64/aarch64-builtins.c:314:1: warning: no previous prototype for
‘aarch64_init_simd_builtins’ [-Wmissing-prototypes]
Which is hidden when building with g++, but looks like:
config/aarch64/aarch64-builtins.c:313:1: warning: no previous declaration for
‘aarch64_init_simd_builtins’ [-Wmissing-declarations]
On Trunk.
Regression tested with no regressions on aarch64-none-elf.
OK to apply to trunk and aarch64-4.7-branch?
Thanks,
James Greenhalgh
---
gcc/
2013-02-28 James Greenhalgh james.greenha...@arm.com
* config/aarch64/aarch64-builtins.c
(aarch64_init_simd_builtins): Make static.
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index dfa7b8c..1ea55a8 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -309,7 +309,7 @@ static GTY(()) tree aarch64_builtin_decls[AARCH64_BUILTIN_MAX];
#define NUM_DREG_TYPES 6
#define NUM_QREG_TYPES 6
-void
+static void
aarch64_init_simd_builtins (void)
{
unsigned int i, fcode = AARCH64_SIMD_BUILTIN_BASE + 1;
[AArch64/AArch64-4.7] Fix warning - aarch64_mangle_type has no prototype.
Hi,
aarch64_mangle_type has no prototype, but it doesn't need one as
it should be declared static.
This patch fixes the warning:
config/aarch64/aarch64.c:5974:1: warning: no previous prototype for
‘aarch64_mangle_type’ [-Wmissing-prototypes]
Which is hidden when building with g++, but looks like:
config/aarch64/aarch64:5990:1: warning: no previous declaration for ‘const
char* aarch64_mangle_type’ [-Wmissing-declarations]
On Trunk.
Regression tested on aarch64-none-elf with no regressions.
OK for trunk and aarch64-4.7-branch?
Thanks,
James Greenhalgh
---
gcc/
2013-02-28 James Greenhalgh james.greenha...@arm.com
* config/aarch64/aarch64.c (aarch64_mangle_type): Make static.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index f091297..a1e4cdd 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5986,7 +5986,7 @@ static aarch64_simd_mangle_map_entry aarch64_simd_mangle_map[] = {
/* Implement TARGET_MANGLE_TYPE. */
-const char *
+static const char *
aarch64_mangle_type (const_tree type)
{
/* The AArch64 ABI documents say that __va_list has to be
[AArch64/AArch64-4.7] Fix warning - Unused variable in aarch64_float_const_representable.
Hi, In aarch64_float_const_representable, `sign' is unused. This patch removes all references to it. The patch is equally applicable to trunk and aarch64-4.7-branch. This patch fixes the warning: config/aarch64/aarch64.c: In function ‘aarch64_float_const_representable_p’: config/aarch64/aarch64.c:7075:7: warning: variable ‘sign’ set but not used [-Wunused-but-set-variable] Regression tested on aarch64-none-elf with no regressions. OK for trunk and aarch64-4.7-branch? Thanks, James Greenhalgh --- gcc/ 2013-02-28 James Greenhalgh james.greenha...@arm.com * config/aarch64/aarch64.c (aarch64_float_const_representable): Remove unused variable. diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index a1e4cdd..8c8532c 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -7088,7 +7088,7 @@ aarch64_float_const_representable_p (rtx x) /* This represents our current view of how many bits make up the mantissa. */ int point_pos = 2 * HOST_BITS_PER_WIDE_INT - 1; - int sign, exponent; + int exponent; unsigned HOST_WIDE_INT mantissa, mask; HOST_WIDE_INT m1, m2; REAL_VALUE_TYPE r, m; @@ -7105,8 +7105,7 @@ aarch64_float_const_representable_p (rtx x) || REAL_VALUE_MINUS_ZERO (r)) return false; - /* Extract sign and exponent. */ - sign = REAL_VALUE_NEGATIVE (r) ? 1 : 0; + /* Extract exponent. */ r = real_value_abs (r); exponent = REAL_EXP (r);
[AArch64/AArch64-4.7] Fix warning - aarch64_simd_make_constant has no prototype.
Hi,
aarch64_simd_make_constant has no prototype, but it doesn't
need one as it should be declared static.
This patch fixes the warning:
config/aarch64/aarch64.c:6574:1: warning: no previous prototype for
‘aarch64_simd_make_constant’ [-Wmissing-prototypes]
Which is hidden when building with g++, but looks like:
config/aarch64/aarch64.c:6590:1: warning: no previous declaration for
‘aarch64_simd_make_constant’ [-Wmissing-declarations]
On Trunk.
Regression tested with no regressions on aarch64-none-elf.
OK for trunk and aarch64-4.7-branch?
Thanks,
James Greenhalgh
---
gcc/
2013-02-28 James Greenhalgh james.greenha...@arm.com
* config/aarch64/aarch64.c
(aarch64_simd_make_constant): Make static.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 85668da..f091297 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6586,7 +6586,7 @@ aarch64_simd_dup_constant (rtx vals)
constants (for vec_init) or CONST_VECTOR, efficiently into a
register. Returns an RTX to copy into the register, or NULL_RTX
for a PARALLEL that can not be converted into a CONST_VECTOR. */
-rtx
+static rtx
aarch64_simd_make_constant (rtx vals)
{
enum machine_mode mode = GET_MODE (vals);
Re: [PATCH] Fix PR56466
On Thu, Feb 28, 2013 at 02:32:02PM +0900, Miles Bader wrote: Marek Polacek pola...@redhat.com writes: + bool changed = false; + changed |= true; + changed |= true; + changed |= true; + changed |= true; +if (changed) Why do you use |= ...? Isn't it equivalent to just = (which is more clear) for a boolean? Ah, yeah, it's a remnant; I had changed = false; there as well. Will adjust, thanks, Marek
Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode
On Wed, 27 Feb 2013 11:04:04 -0800
Janis Johnson janis_john...@mentor.com wrote:
On 02/27/2013 09:29 AM, Julian Brown wrote:
Index: gcc/testsuite/gcc.dg/vect/slp-cond-3.c
===
--- gcc/testsuite/gcc.dg/vect/slp-cond-3.c (revision 196170)
+++ gcc/testsuite/gcc.dg/vect/slp-cond-3.c (working copy)
@@ -79,6 +79,6 @@ int main ()
return 0;
}
-/* { dg-final { scan-tree-dump-times vectorizing stmts using SLP
1 vect } } */ +/* { dg-final { scan-tree-dump-times vectorizing
stmts using SLP 1 vect { xfail { ! vect_unpack } } } } */ /*
{ dg-final { cleanup-tree-dump vect } } */
If this and other modified checks only fail for ARM big-endian then
they should check for that so they don't XPASS for other targets.
It's also possible now to do things like { target vect_blah xfail
arm_big_endian }, which might be useful for some tests.
I don't think I understand -- my expectation was e.g. that that test
would fail for any target which doesn't support vect_unpack. Surely
you'd only get an XPASS if the test passed when vect_unpack was not
true?
I'm not sure why checking for a particular architecture-specific
predicate would be preferable to checking that a general feature is
supported. As time progresses, it might well be that e.g. vect_unpack
becomes supported for big-endian ARM, at which point we shouldn't need
to edit all the individual tests again...
Thanks,
Julian
[Patch ARM] Call final_start_function and final_end_function in arm_output_mi_thunk.
Hi,
Ports should call final_start_function and final_end_function to get
proper debug info for the thunk as per
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55257#c3 . Fixes failing
tests in g++.dg for arm-*-*eabi.
Tested on arm-linux-gnueabi cross for armv7-a, arm/thumb2 and armv5t on
qemu. Applied.
Thanks,
Ramana
2013-02-28 Ramana Radhakrishnan ramana.radhakrish...@arm.com
* config/arm/arm.c (arm_output_mi_thunk): Call final_start_function and
final_end_function.
---
gcc/config/arm/arm.c |4
1 file changed, 4 insertions(+)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 3e7bd7f..44fefb0 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -24314,6 +24314,8 @@ arm_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED,
if (mi_delta 0)
mi_delta = - mi_delta;
+ final_start_function (emit_barrier (), file, 1);
+
if (TARGET_THUMB1)
{
int labelno = thunk_label++;
@@ -24430,6 +24432,8 @@ arm_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED,
fputs ((PLT), file);
fputc ('\n', file);
}
+
+ final_end_function ();
}
int
Re: RFC: add some static probes to libstdc++
On 27/02/2013 21:52, Tom Tromey wrote:
I'm posting this now to get reactions to the probe before cleaning up
the corresponding gdb patches for submission. I've built it both with
and without sys/sdt.h, but I haven't yet run the test suite.
How did it build in the without sys/sdt.h case?
+#ifdef HAVE_SYS_SDT_H
+#include sys/sdt.h
+/* We only want to use stap probes starting with v3. Earlier versions
+ added too much startup cost. */
+#if defined (STAP_PROBE2) _SDT_NOTE_TYPE = 3
+#define PROBE2(name, arg1, arg2) STAP_PROBE2 (libstdcxx, name, arg1, arg2)
+#else
+#define PROBE2(name, arg1, arg2)
+#endif
+#endif
+
Without HAVE_SYS_SDT_H, there's no definition of PROBE2 at all, but you use
it unconditionally in eh_{catch,throw}.cc. Am I missing something?
cheers,
DaveK
Re: libsanitizer merge from upstream r175042
On Fri, Feb 22, 2013 at 8:32 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Feb 15, 2013 at 12:47:30PM +0400, Konstantin Serebryany wrote: Sure. ASAN_FIXED_MAPPING should be used for performance measurements only -- this is not a release option. (Added a more precise comment). BTW, today I think I've discovered what looks like a prelink bug, but perhaps we need to bump kMidMemEnd a little bit. With prelink -R, the libraries are randomized in the selected range of addresses, by picking a random number in between the boundaries of the address range and first assigning addresses to libraries above that random offset and when there is no longer any room above it, starting from the beginning of the range. Unfortunately the code seems to have some issues if the random address is chosen close to the end of the range, then in some cases some libraries could start before the range, but end after the range. On one of my boxes there is (only 4 libraries out of 822 have this problem, only discovered it because gdb is linked against one of them and I've tried to LD_PRELOAD=libasan.so.0 to gdb so that the debugged program would inherit that): prelink -pv 21 | grep 0x003.*-.*0x004 /usr/lib64/libgmlib.so.1.0.7 [0x1ea5b3cf] 0x003fffe0-0x00408460: /usr/lib64/libiec61883.so.0.1.1 [0x56363ffc] 0x003fffe0-0x0040c3e0: /usr/lib64/libncurses.so.5.9 [0x120e1b8a] 0x003fffe0-0x00423860: /usr/lib64/libsoup-2.4.so.1.5.0 [0x99ff4d51] 0x003fffe0-0x0046a258: while on others none. So, can kMidMemEnd be slightly incremented above this? Either 0x4fULL, or 0x40ULL (or replace that 0f with 1f, 2f, etc.). Small model shared libraries can be only up to 2GB in size, so even 0x40ULL should be big enough for most cases, but 0x4fULL could be even safer. I've justed tested and 0x4fULL results in || `[0x10007fff8000, 0x7fff]` || HighMem|| || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || || `[0x0050, 0x02008fff6fff]` || ShadowGap3 || || `[0x0030, 0x004f]` || MidMem || || `[0x000a7fff8000, 0x002f]` || ShadowGap2 || || `[0x00067fff8000, 0x000a7fff7fff]` || MidShadow || || `[0x8fff7000, 0x00067fff7fff]` || ShadowGap || || `[0x7fff8000, 0x8fff6fff]` || LowShadow || || `[0x, 0x7fff7fff]` || LowMem || MemToShadow(shadow): 0x8fff7000 0x91ff6dff 0x004091ff6e00 0x02008fff6fff 0x00014fff7000 0x0001cfff6fff and seems to work just fine. I am sorry, I missed this message. Indeed, the change looks safe, http://llvm.org/viewvc/llvm-project?rev=176250view=rev Thanks! --kcc Jakub
Re: [v3] Update Solaris baselines
Hi, On 02/26/2013 12:33 PM, Rainer Orth wrote: Ok for mainline? I suppose you don't need an approval for the Solaris-specific files, like such baselines. Paolo.
Re: [v3] Update Solaris baselines
Hi Paolo, On 02/26/2013 12:33 PM, Rainer Orth wrote: Ok for mainline? I suppose you don't need an approval for the Solaris-specific files, like such baselines. probably not, but it's certainly good to have the changes sanity-checked by someone with knowledge of the libstdc++ ABI, even if they look sane to the untrained eye :-) Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[c++-concepts] Reserving new keywords for concepts
Reserving a handful of new keywords for concepts and several new type traits in preparation for future work on concepts. Andrew 2013-02-05 Andrew Sutton andrew.n.sut...@gmail.com * c-common.h (rid): New resreserved words for concepts. * c-common.c (c_common_reswords): Definitions thereof. reswords.patch Description: Binary data
Re: RFC: add some static probes to libstdc++
Dave == Dave Korn dave.korn.cyg...@gmail.com writes:
Dave How did it build in the without sys/sdt.h case?
Dave Without HAVE_SYS_SDT_H, there's no definition of PROBE2 at all,
Dave but you use it unconditionally in eh_{catch,throw}.cc. Am I
Dave missing something?
Ugh. I must have made some mistake in my testing.
I will fix it up.
Tom
Re: [c++-concepts] Reserving new keywords for concepts
On Thu, Feb 28, 2013 at 8:07 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: Reserving a handful of new keywords for concepts and several new type traits in preparation for future work on concepts. Andrew 2013-02-05 Andrew Sutton andrew.n.sut...@gmail.com * c-common.h (rid): New resreserved words for concepts. * c-common.c (c_common_reswords): Definitions thereof. For all patches for the c++-concepts branch, CC: me and Jason. Can we also have corresponding documentation for the new keywords? E.g. in doc/extend.texi. For the moment, you probably just want to add a menu node for C++ concepts, and list these new tokens as reserved. -- Gaby
Re: [c++-concepts] Reserving new keywords for concepts
Of course. I'll send that along shortly. Andrew On Thu, Feb 28, 2013 at 8:51 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Thu, Feb 28, 2013 at 8:07 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: Reserving a handful of new keywords for concepts and several new type traits in preparation for future work on concepts. Andrew 2013-02-05 Andrew Sutton andrew.n.sut...@gmail.com * c-common.h (rid): New resreserved words for concepts. * c-common.c (c_common_reswords): Definitions thereof. For all patches for the c++-concepts branch, CC: me and Jason. Can we also have corresponding documentation for the new keywords? E.g. in doc/extend.texi. For the moment, you probably just want to add a menu node for C++ concepts, and list these new tokens as reserved. -- Gaby -- Andrew Sutton andrew.n.sut...@gmail.com
Re: [c++-concepts] Reserving new keywords for concepts
On Thu, Feb 28, 2013 at 9:01 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: Of course. I'll send that along shortly. Patch OK. -- Gaby Andrew On Thu, Feb 28, 2013 at 8:51 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Thu, Feb 28, 2013 at 8:07 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: Reserving a handful of new keywords for concepts and several new type traits in preparation for future work on concepts. Andrew 2013-02-05 Andrew Sutton andrew.n.sut...@gmail.com * c-common.h (rid): New resreserved words for concepts. * c-common.c (c_common_reswords): Definitions thereof. For all patches for the c++-concepts branch, CC: me and Jason. Can we also have corresponding documentation for the new keywords? E.g. in doc/extend.texi. For the moment, you probably just want to add a menu node for C++ concepts, and list these new tokens as reserved. -- Gaby -- Andrew Sutton andrew.n.sut...@gmail.com
Re: RFC: add some static probes to libstdc++
Dave How did it build in the without sys/sdt.h case?
Sorry about that again.
I must have made some change after testing it.
Here is an updated version.
One thing I found out while fixing this up is that changes to
unwind-cxx.h do not cause anything to rebuild if I just run make. I
have to make clean each time.
On the plus side, while digging around after being confused by this, I
found that I didn't actually need ../config.h -- the code now checks
_GLIBCXX_HAVE_SYS_SDT_H instead.
Tom
2013-02-27 Tom Tromey tro...@redhat.com
* libsupc++/unwind-cxx.h: Include sys/sdt.h if detected.
(PROBE2): New macro.
* libsupc++/eh_throw.cc (__cxa_throw, __cxa_rethrow): Add probe.
* libsupc++/eh_catch.cc (__cxa_begin_catch): Add probe.
* configure.ac: Check for sys/sdt.h.
* configure, config.h.in: Rebuild.
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index a64fee2..de66406 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -216,7 +216,7 @@ GLIBCXX_CHECK_SYSCTL_HW_NCPU
AC_CHECK_HEADERS([endian.h execinfo.h float.h fp.h ieeefp.h inttypes.h \
locale.h machine/endian.h machine/param.h nan.h stdint.h stdlib.h string.h \
strings.h sys/ipc.h sys/isa_defs.h sys/machine.h sys/param.h \
-sys/resource.h sys/sem.h sys/stat.h sys/time.h sys/types.h unistd.h \
+sys/resource.h sys/sdt.h sys/sem.h sys/stat.h sys/time.h sys/types.h unistd.h \
wchar.h wctype.h])
# Only do link tests if native. Else, hardcode.
diff --git a/libstdc++-v3/libsupc++/eh_catch.cc
b/libstdc++-v3/libsupc++/eh_catch.cc
index 779f5a3..43e875a 100644
--- a/libstdc++-v3/libsupc++/eh_catch.cc
+++ b/libstdc++-v3/libsupc++/eh_catch.cc
@@ -80,6 +80,9 @@ __cxxabiv1::__cxa_begin_catch (void *exc_obj_in)
_GLIBCXX_NOTHROW
}
objectp = __gxx_caught_object(exceptionObject);
+
+ PROBE2 (catch, objectp, header-exceptionType);
+
#ifdef __ARM_EABI_UNWINDER__
_Unwind_Complete(exceptionObject);
#endif
diff --git a/libstdc++-v3/libsupc++/eh_throw.cc
b/libstdc++-v3/libsupc++/eh_throw.cc
index 297aa04..a79a025 100644
--- a/libstdc++-v3/libsupc++/eh_throw.cc
+++ b/libstdc++-v3/libsupc++/eh_throw.cc
@@ -60,6 +60,8 @@ extern C void
__cxxabiv1::__cxa_throw (void *obj, std::type_info *tinfo,
void (_GLIBCXX_CDTOR_CALLABI *dest) (void *))
{
+ PROBE2 (throw, obj, tinfo);
+
// Definitely a primary.
__cxa_refcounted_exception *header
= __get_refcounted_exception_header_from_obj (obj);
@@ -97,7 +99,12 @@ __cxxabiv1::__cxa_rethrow ()
if (!__is_gxx_exception_class(header-unwindHeader.exception_class))
globals-caughtExceptions = 0;
else
- header-handlerCount = -header-handlerCount;
+ {
+ header-handlerCount = -header-handlerCount;
+ // Only notify probe for C++ exceptions.
+ PROBE2 (rethrow, __get_object_from_ambiguous_exception(header),
+ header-exceptionType);
+ }
#ifdef _GLIBCXX_SJLJ_EXCEPTIONS
_Unwind_SjLj_Resume_or_Rethrow (header-unwindHeader);
diff --git a/libstdc++-v3/libsupc++/unwind-cxx.h
b/libstdc++-v3/libsupc++/unwind-cxx.h
index e2b945d..ed4eea5 100644
--- a/libstdc++-v3/libsupc++/unwind-cxx.h
+++ b/libstdc++-v3/libsupc++/unwind-cxx.h
@@ -37,6 +37,19 @@
#include bits/atomic_word.h
#include cxxabi.h
+#ifdef _GLIBCXX_HAVE_SYS_SDT_H
+#include sys/sdt.h
+/* We only want to use stap probes starting with v3. Earlier versions
+ added too much startup cost. */
+#if defined (STAP_PROBE2) _SDT_NOTE_TYPE = 3
+#define PROBE2(name, arg1, arg2) STAP_PROBE2 (libstdcxx, name, arg1, arg2)
+#endif
+#endif
+
+#ifndef PROBE2
+#define PROBE2(name, arg1, arg2)
+#endif
+
#pragma GCC visibility push(default)
namespace __cxxabiv1
Re: [c++-concepts] Reserving new keywords for concepts
Attached is the initial documentation for the previous patch. Andrew 2013-02-28 Andrew Sutton andrew.n.sut...@gmail.com * doc/extend.texi (write_symbol): Initial concept docs. On Thu, Feb 28, 2013 at 9:11 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Thu, Feb 28, 2013 at 9:01 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: Of course. I'll send that along shortly. Patch OK. -- Gaby Andrew On Thu, Feb 28, 2013 at 8:51 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Thu, Feb 28, 2013 at 8:07 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: Reserving a handful of new keywords for concepts and several new type traits in preparation for future work on concepts. Andrew 2013-02-05 Andrew Sutton andrew.n.sut...@gmail.com * c-common.h (rid): New resreserved words for concepts. * c-common.c (c_common_reswords): Definitions thereof. For all patches for the c++-concepts branch, CC: me and Jason. Can we also have corresponding documentation for the new keywords? E.g. in doc/extend.texi. For the moment, you probably just want to add a menu node for C++ concepts, and list these new tokens as reserved. -- Gaby -- Andrew Sutton andrew.n.sut...@gmail.com -- Andrew Sutton andrew.n.sut...@gmail.com concepts-doc.patch Description: Binary data
Re: [c++-concepts] Reserving new keywords for concepts
On Thu, Feb 28, 2013 at 9:54 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: Attached is the initial documentation for the previous patch. Patch OK. Thanks! -- Gaby Andrew 2013-02-28 Andrew Sutton andrew.n.sut...@gmail.com * doc/extend.texi (write_symbol): Initial concept docs. On Thu, Feb 28, 2013 at 9:11 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Thu, Feb 28, 2013 at 9:01 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: Of course. I'll send that along shortly. Patch OK. -- Gaby Andrew On Thu, Feb 28, 2013 at 8:51 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Thu, Feb 28, 2013 at 8:07 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: Reserving a handful of new keywords for concepts and several new type traits in preparation for future work on concepts. Andrew 2013-02-05 Andrew Sutton andrew.n.sut...@gmail.com * c-common.h (rid): New resreserved words for concepts. * c-common.c (c_common_reswords): Definitions thereof. For all patches for the c++-concepts branch, CC: me and Jason. Can we also have corresponding documentation for the new keywords? E.g. in doc/extend.texi. For the moment, you probably just want to add a menu node for C++ concepts, and list these new tokens as reserved. -- Gaby -- Andrew Sutton andrew.n.sut...@gmail.com -- Andrew Sutton andrew.n.sut...@gmail.com
Re: [C++ Patch] Fix c++/56243
On 02/25/2013 06:25 PM, Jason Merrill wrote:
On 02/25/2013 06:24 PM, Jason Merrill wrote:
I think my preference would be to avoid calling fixed_type_or_null at
all when we're in a template. I already changed
resolves_to_fixed_type_p that way, now we need to fix build_vtbl_ref_1.
Oops, now I see the discussion on the PR. I'll take a look.
I'm applying this patch. When we're in fold_non_dependent_expr we care
about doing the right thing for possible constant-expressions, but a
virtual function call can't be part of a constant-expression, so we
don't need to worry about virtual lookup.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8d561a71fbe141ad4d5b4f1ff9160e4f4c81a061
Author: Jason Merrill ja...@redhat.com
Date: Tue Feb 26 10:06:31 2013 -0500
PR c++/56243
* call.c (build_over_call): Avoid virtual lookup in a template.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 7c41421..4eb38ec 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7033,7 +7033,10 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
if (!already_used)
mark_used (fn);
- if (DECL_VINDEX (fn) (flags LOOKUP_NONVIRTUAL) == 0)
+ if (DECL_VINDEX (fn) (flags LOOKUP_NONVIRTUAL) == 0
+ /* Don't mess with virtual lookup in fold_non_dependent_expr; virtual
+ functions can't be constexpr. */
+ !in_template_function ())
{
tree t;
tree binfo = lookup_base (TREE_TYPE (TREE_TYPE (argarray[0])),
diff --git a/gcc/testsuite/g++.dg/template/virtual4.C b/gcc/testsuite/g++.dg/template/virtual4.C
new file mode 100644
index 000..a2c7420b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/virtual4.C
@@ -0,0 +1,30 @@
+// PR c++/56243
+
+struct A
+{
+ virtual int String ();
+};
+
+struct F: A { };
+
+struct G
+{
+ F value;
+};
+
+struct D
+{
+ template int
+ void Verify()
+ {
+G x;
+F name = x.value;
+name.String();
+ }
+};
+
+int main()
+{
+ D d;
+ d.Verify42();
+}
Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode
On 02/28/2013 02:06 AM, Julian Brown wrote:
On Wed, 27 Feb 2013 11:04:04 -0800
Janis Johnson janis_john...@mentor.com wrote:
On 02/27/2013 09:29 AM, Julian Brown wrote:
Index: gcc/testsuite/gcc.dg/vect/slp-cond-3.c
===
--- gcc/testsuite/gcc.dg/vect/slp-cond-3.c (revision 196170)
+++ gcc/testsuite/gcc.dg/vect/slp-cond-3.c (working copy)
@@ -79,6 +79,6 @@ int main ()
return 0;
}
-/* { dg-final { scan-tree-dump-times vectorizing stmts using SLP
1 vect } } */ +/* { dg-final { scan-tree-dump-times vectorizing
stmts using SLP 1 vect { xfail { ! vect_unpack } } } } */ /*
{ dg-final { cleanup-tree-dump vect } } */
If this and other modified checks only fail for ARM big-endian then
they should check for that so they don't XPASS for other targets.
It's also possible now to do things like { target vect_blah xfail
arm_big_endian }, which might be useful for some tests.
I don't think I understand -- my expectation was e.g. that that test
would fail for any target which doesn't support vect_unpack. Surely
you'd only get an XPASS if the test passed when vect_unpack was not
true?
Right. Please ignore my mail, I was confused.
I'm not sure why checking for a particular architecture-specific
predicate would be preferable to checking that a general feature is
supported. As time progresses, it might well be that e.g. vect_unpack
becomes supported for big-endian ARM, at which point we shouldn't need
to edit all the individual tests again...
Right. Once again, I was confused, ignore me.
Janis
Re: [AArch64/AArch64-4.7] Fix warning - No previous prototype for aarch64_init_simd_builtins.
OK On 28 February 2013 09:34, James Greenhalgh james.greenha...@arm.com wrote: Hi, aarch64_init_simd_buitlins is not declared with a prototype, but it doesn't need one as it should be declared static. This patch fixes the warning: config/aarch64/aarch64-builtins.c:314:1: warning: no previous prototype for ‘aarch64_init_simd_builtins’ [-Wmissing-prototypes] Which is hidden when building with g++, but looks like: config/aarch64/aarch64-builtins.c:313:1: warning: no previous declaration for ‘aarch64_init_simd_builtins’ [-Wmissing-declarations] On Trunk. Regression tested with no regressions on aarch64-none-elf. OK to apply to trunk and aarch64-4.7-branch? Thanks, James Greenhalgh --- gcc/ 2013-02-28 James Greenhalgh james.greenha...@arm.com * config/aarch64/aarch64-builtins.c (aarch64_init_simd_builtins): Make static.
Re: [AArch64/AArch64-4.7] Fix warning - aarch64_simd_make_constant has no prototype.
OK On 28 February 2013 09:40, James Greenhalgh james.greenha...@arm.com wrote: Hi, aarch64_simd_make_constant has no prototype, but it doesn't need one as it should be declared static. This patch fixes the warning: config/aarch64/aarch64.c:6574:1: warning: no previous prototype for ‘aarch64_simd_make_constant’ [-Wmissing-prototypes] Which is hidden when building with g++, but looks like: config/aarch64/aarch64.c:6590:1: warning: no previous declaration for ‘aarch64_simd_make_constant’ [-Wmissing-declarations] On Trunk. Regression tested with no regressions on aarch64-none-elf. OK for trunk and aarch64-4.7-branch? Thanks, James Greenhalgh --- gcc/ 2013-02-28 James Greenhalgh james.greenha...@arm.com * config/aarch64/aarch64.c (aarch64_simd_make_constant): Make static.
Re: [AArch64/AArch64-4.7] Fix warning - Unused variable in aarch64_float_const_representable.
OK On 28 February 2013 09:38, James Greenhalgh james.greenha...@arm.com wrote: Hi, In aarch64_float_const_representable, `sign' is unused. This patch removes all references to it. The patch is equally applicable to trunk and aarch64-4.7-branch. This patch fixes the warning: config/aarch64/aarch64.c: In function ‘aarch64_float_const_representable_p’: config/aarch64/aarch64.c:7075:7: warning: variable ‘sign’ set but not used [-Wunused-but-set-variable] Regression tested on aarch64-none-elf with no regressions. OK for trunk and aarch64-4.7-branch? Thanks, James Greenhalgh --- gcc/ 2013-02-28 James Greenhalgh james.greenha...@arm.com * config/aarch64/aarch64.c (aarch64_float_const_representable): Remove unused variable.
Re: [AArch64/AArch64-4.7] Fix warning - aarch64_mangle_type has no prototype.
OK On 28 February 2013 09:36, James Greenhalgh james.greenha...@arm.com wrote: Hi, aarch64_mangle_type has no prototype, but it doesn't need one as it should be declared static. This patch fixes the warning: config/aarch64/aarch64.c:5974:1: warning: no previous prototype for ‘aarch64_mangle_type’ [-Wmissing-prototypes] Which is hidden when building with g++, but looks like: config/aarch64/aarch64:5990:1: warning: no previous declaration for ‘const char* aarch64_mangle_type’ [-Wmissing-declarations] On Trunk. Regression tested on aarch64-none-elf with no regressions. OK for trunk and aarch64-4.7-branch? Thanks, James Greenhalgh --- gcc/ 2013-02-28 James Greenhalgh james.greenha...@arm.com * config/aarch64/aarch64.c (aarch64_mangle_type): Make static.
Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
On Wed, Feb 27, 2013 at 5:52 PM, Ian Lance Taylor i...@google.com wrote: I think that the libgcc unwinder only calls malloc if somebody calls __register_frame_info. So I looked. Indeed it doesn't call malloc in our environment, but does call dl_iterate_phdr, which is just as deadly. To be fair, libunwind does that as well, and we have to provide a workaround for that. Still, out-of-the-box libgcc unwinder is not suitable for our unwind requirements. I thought a more serious issue is that the libgcc unwinder has no way of dealing with a corrupt stack--it will simply crash. That too ... Thanks, -- Paul Pluzhnikov
Re: RFC: [PATCH,ARM] Fix 56110
Tilman Sauerbeck [2013-02-24 17:00]: Richard Earnshaw [2013-02-20 11:00]: On 19/02/13 22:26, Tilman Sauerbeck wrote: I don't get why relaxing the restrictions for the andsi3_compare0_scratch pattern results in a mismatch for the zeroextractsi_compare0_scratch one. Any ideas? Because of the way combine works. It first tries to find a pattern that doesn't have a clobber expression. It finds your new pattern and then uses that. But since that can't handle immediates, reload then comes along and forces the constant into a register. You need one pattern to deal with all the cases. You mean the pattern should include calls to arm_split_constant() to do the loading itself, like e.g. the iorsi3 pattern does? Why can't we let reload do the load? FWIW the patch in http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00920.html works for my testcases, survives a bootstrap in qemu and passes the test suite (I only built/tested the C and C++ frontends though). Sorry to be a pain, but ... ping? I don't know how to proceed with this patch. Thanks. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
On Thu, Feb 28, 2013 at 8:23 AM, Paul Pluzhnikov ppluzhni...@google.com wrote: On Wed, Feb 27, 2013 at 5:52 PM, Ian Lance Taylor i...@google.com wrote: I think that the libgcc unwinder only calls malloc if somebody calls __register_frame_info. So I looked. Indeed it doesn't call malloc in our environment, but does call dl_iterate_phdr, which is just as deadly. Hmmm, I guess I can't remember why. dl_iterate_phdr uses a recursive lock so there shouldn't be any deadlock problem. If the problem is the dynamic lookup of the dl_iterate_phdr symbol for lazy PLT evaluation, that could be finessed by calling it beforehand. Ian
Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
On Thu, Feb 28, 2013 at 9:28 AM, Ian Lance Taylor i...@google.com wrote: does call dl_iterate_phdr, which is just as deadly. Hmmm, I guess I can't remember why. Let me refresh your memory. You've seen this deadlock before: Thread 1Thread 2 dlopen malloc ... takes loader lock ... takes malloc lock malloc _Unwind_Backtrace ... needs malloc lock dl_iterate_phdr held by T2... needs loader lock held by T1 -- Paul Pluzhnikov
[PATCH] Fix PR56478
The following testcase ICEd because we were trying to negate
-9223372036854775808, which results in UB, since it's LLONG_MAX + 1.
Then we got a SIGFPE on
-LLONG_MIN / -1
So fixed by doing the arithmetics on trees, and in case we got
an overflow, we bail out.
The hunk
probability = (double) REG_BR_PROB_BASE * compare_count / loop_count;
in there should be probably handled in the same way. But I'll handle
that separately.
In the first hunk, I did s/int/HOST_WIDE_INT/, because HWI is what
tree_low_cst returns. For why that could be a problem, see the
Jakub's comment in the PR.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2013-02-28 Marek Polacek pola...@redhat.com
PR tree-optimization/56478
* predict.c (is_comparison_with_loop_invariant_p): Change the
type of step to HOST_WIDE_INT.
(predict_iv_comparison): Do the computation on trees, return
in case of an overflow.
* gcc.dg/torture/pr56478.c: New test.
--- gcc/predict.c.mp2013-02-28 17:26:47.950247877 +0100
+++ gcc/predict.c 2013-02-28 17:26:56.855275792 +0100
@@ -1034,7 +1034,7 @@ is_comparison_with_loop_invariant_p (gim
tree op0, op1, bound, base;
affine_iv iv0, iv1;
enum tree_code code;
- int step;
+ HOST_WIDE_INT step;
code = gimple_cond_code (stmt);
*loop_invariant = NULL;
@@ -1224,11 +1224,29 @@ predict_iv_comparison (struct loop *loop
host_integerp (compare_base, 0))
{
int probability;
+ tree step_var, loop_count_var;
HOST_WIDE_INT compare_count;
HOST_WIDE_INT loop_bound = tree_low_cst (loop_bound_var, 0);
HOST_WIDE_INT compare_bound = tree_low_cst (compare_var, 0);
HOST_WIDE_INT base = tree_low_cst (compare_base, 0);
- HOST_WIDE_INT loop_count = (loop_bound - base) / compare_step;
+
+ /* We want to do the arithmetics on trees (and punt in
+ case of an overflow). */
+ step_var = build_int_cst (NULL_TREE, compare_step);
+ gcc_assert (TREE_CODE (step_var) == INTEGER_CST);
+
+ /* Compute (loop_bound - base) / compare_step. */
+ loop_count_var
+= int_const_binop (TRUNC_DIV_EXPR,
+ int_const_binop (MINUS_EXPR,
+ loop_bound_var,
+ compare_base),
+ step_var);
+
+ if (TREE_OVERFLOW_P (loop_count_var))
+ return;
+
+ HOST_WIDE_INT loop_count = tree_low_cst (loop_count_var, 0);
if ((compare_step 0)
^ (compare_code == LT_EXPR || compare_code == LE_EXPR))
--- gcc/testsuite/gcc.dg/torture/pr56478.c.mp 2013-02-28 17:32:26.430308968
+0100
+++ gcc/testsuite/gcc.dg/torture/pr56478.c 2013-02-28 18:15:41.641379179
+0100
@@ -0,0 +1,12 @@
+/* PR tree-optimization/56478 */
+/* { dg-do compile } */
+
+int a;
+
+void
+foo ()
+{
+ int b;
+ for (b = 0;; b++)
+a = 0 -__LONG_LONG_MAX__ - 1 - b ? : 0;
+}
Marek
Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
On Thu, Feb 28, 2013 at 10:10 AM, Paul Pluzhnikov ppluzhni...@google.com wrote: On Thu, Feb 28, 2013 at 9:28 AM, Ian Lance Taylor i...@google.com wrote: does call dl_iterate_phdr, which is just as deadly. Hmmm, I guess I can't remember why. Let me refresh your memory. You've seen this deadlock before: Thread 1Thread 2 dlopen malloc ... takes loader lock ... takes malloc lock malloc _Unwind_Backtrace ... needs malloc lock dl_iterate_phdr held by T2... needs loader lock held by T1 Oh yeah. Thanks. Ian
Re: [PATCH] Fix PR56478
On Thu, Feb 28, 2013 at 07:27:48PM +0100, Marek Polacek wrote: The hunk probability = (double) REG_BR_PROB_BASE * compare_count / loop_count; in there should be probably handled in the same way. But I'll handle that separately. In the first hunk, I did s/int/HOST_WIDE_INT/, because HWI is what tree_low_cst returns. For why that could be a problem, see the Jakub's comment in the PR. That doesn't help, because it is assigned into int *loop_step; *loop_step = step; IMHO the argument should be tree *loop_step, then you don't need to convert it back from int to tree. --- gcc/predict.c.mp 2013-02-28 17:26:47.950247877 +0100 +++ gcc/predict.c 2013-02-28 17:26:56.855275792 +0100 + /* We want to do the arithmetics on trees (and punt in + case of an overflow). */ + step_var = build_int_cst (NULL_TREE, compare_step); + gcc_assert (TREE_CODE (step_var) == INTEGER_CST); See above, this would be unnecessary. + + /* Compute (loop_bound - base) / compare_step. */ + loop_count_var += int_const_binop (TRUNC_DIV_EXPR, +int_const_binop (MINUS_EXPR, + loop_bound_var, + compare_base), +step_var); + + if (TREE_OVERFLOW_P (loop_count_var)) + return; + + HOST_WIDE_INT loop_count = tree_low_cst (loop_count_var, 0); I thought you'd do the rest of the computations on trees too, there are the risks of overflows or undefined behavior. So if ((tree_int_cst_sgn (compare_step) == 1) etc., integer_zerop (loop_count), and the only conversion from tree to HWI would be after you convert the floating point tree to integer when you assign it to probability. Jakub
Re: [v3] Update Solaris baselines
On 28 February 2013 13:28, Rainer Orth wrote: Hi Paolo, On 02/26/2013 12:33 PM, Rainer Orth wrote: Ok for mainline? I suppose you don't need an approval for the Solaris-specific files, like such baselines. probably not, but it's certainly good to have the changes sanity-checked by someone with knowledge of the libstdc++ ABI, even if they look sane to the untrained eye :-) They look sane to me, thanks for updating them.
Re: [PATCH] Fix up _cpp_find_file
Jakub == Jakub Jelinek ja...@redhat.com writes: Jakub 2013-02-27 Jakub Jelinek ja...@redhat.com Jakub * files.c (_cpp_find_file): If returning early, before storing Jakub something to *hash_slot and *hash_slot is NULL, call htab_clear_slot Jakub on it. Access *hash_slot using void * type rather than Jakub struct file_hash_entry * to avoid aliasing issues. This is ok. Thanks. Tom
Re: libsanitizer merge from upstream r175042
On Thu, Feb 28, 2013 at 04:30:13PM +0400, Konstantin Serebryany wrote:
I am sorry, I missed this message.
Indeed, the change looks safe,
http://llvm.org/viewvc/llvm-project?rev=176250view=rev
Thanks, here is what I've committed to gcc:
2013-02-28 Jakub Jelinek ja...@redhat.com
* asan/asan_mapping.h (kMidMemEnd): Increase to 0x4fULL.
* asan/asan_rtl.cc (__asan_init): Increase kMidMemEnd to
0x4fULL.
--- libsanitizer/asan/asan_mapping.h(revision 176249)
+++ libsanitizer/asan/asan_mapping.h(revision 176250)
@@ -32,13 +32,13 @@
// || `[0x0004, 0x01ff]` || ShadowGap ||
//
// Special case when something is already mapped between
-// 0x0030 and 0x0040 (e.g. when prelink is installed):
+// 0x0030 and 0x0050 (e.g. when prelink is installed):
// || `[0x10007fff8000, 0x7fff]` || HighMem||
// || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
-// || `[0x0040, 0x02008fff6fff]` || ShadowGap3 ||
-// || `[0x0030, 0x003f]` || MidMem ||
-// || `[0x00087fff8000, 0x002f]` || ShadowGap2 ||
-// || `[0x00067fff8000, 0x00087fff7fff]` || MidShadow ||
+// || `[0x0050, 0x02008fff6fff]` || ShadowGap3 ||
+// || `[0x0030, 0x004f]` || MidMem ||
+// || `[0x000a7fff8000, 0x002f]` || ShadowGap2 ||
+// || `[0x00067fff8000, 0x000a7fff7fff]` || MidShadow ||
// || `[0x8fff7000, 0x00067fff7fff]` || ShadowGap ||
// || `[0x7fff8000, 0x8fff6fff]` || LowShadow ||
// || `[0x, 0x7fff7fff]` || LowMem ||
@@ -131,7 +131,7 @@ extern uptr AsanMappingProfile[];
// difference between fixed and non-fixed mapping is below the noise level.
static uptr kHighMemEnd = 0x7fffULL;
static uptr kMidMemBeg =0x30ULL;
-static uptr kMidMemEnd =0x3fULL;
+static uptr kMidMemEnd =0x4fULL;
#else
SANITIZER_INTERFACE_ATTRIBUTE
extern uptr kHighMemEnd, kMidMemBeg, kMidMemEnd; // Initialized in
__asan_init.
--- libsanitizer/asan/asan_rtl.cc (revision 176249)
+++ libsanitizer/asan/asan_rtl.cc (revision 176250)
@@ -459,7 +459,7 @@ void __asan_init() {
#if ASAN_LINUX defined(__x86_64__) !ASAN_FIXED_MAPPING
if (!full_shadow_is_available) {
kMidMemBeg = kLowMemEnd 0x30ULL ? 0x30ULL : 0;
-kMidMemEnd = kLowMemEnd 0x30ULL ? 0x3fULL : 0;
+kMidMemEnd = kLowMemEnd 0x30ULL ? 0x4fULL : 0;
}
#endif
Jakub
Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
Thread 1Thread 2 dlopen malloc ... takes loader lock ... takes malloc lock malloc _Unwind_Backtrace ... needs malloc lock dl_iterate_phdr held by T2... needs loader lock held by T1 Am I missing something, or wouldn't it be feasible when instrumenting malloc to call _Unwind_Backtrace before obtaining the malloc lock (or drop the malloc lock while calling _Unwind_Backtrace)? Similarly, couldn't dlopen drop the loader lock while calling malloc? -cary
Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
On Thu, Feb 28, 2013 at 11:57:48AM -0800, Cary Coutant wrote: Similarly, couldn't dlopen drop the loader lock while calling malloc? It can't, but perhaps it could call some alternative malloc instead (the simpler malloc version in ld.so or similar). Jakub
[PATCH] Fix a slp leak caused by vec.h conversion (PR middle-end/56461)
Hi!
This is small, but quite common memory leak in slp vectorization.
vec_alloc (vec_defs, number_of_vects);
on vl_ptr-ish vectree *vec_defs; first calls new on the vectree
(i.e. allocates sizeof (void *) bytes), and then actually creates vector
pointed to by that. Later on we copy the content of what it points to,
but don't actually free the void * sized allocation.
Fixed by changing the vector to be actually vecvectree *, which also
simplifies the callers.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-02-28 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* tree-vectorizer.h (vect_get_slp_defs): Change 3rd argument
type to vecvectree *.
* tree-vect-slp.c (vect_get_slp_defs): Likewise. Change vec_defs
to be vectree instead of vectree *, set vec_defs
to vNULL and call vec_defs.create (number_of_vects), adjust other
uses of vec_defs.
* tree-vect-stmts.c (vect_get_vec_defs, vectorizable_call,
vectorizable_condition): Adjust vect_get_slp_defs callers.
--- gcc/tree-vectorizer.h.jj2013-02-05 16:45:40.0 +0100
+++ gcc/tree-vectorizer.h 2013-02-28 14:17:45.276135327 +0100
@@ -978,7 +978,7 @@ extern bool vect_analyze_slp (loop_vec_i
extern bool vect_make_slp_decision (loop_vec_info);
extern void vect_detect_hybrid_slp (loop_vec_info);
extern void vect_get_slp_defs (vectree , slp_tree,
- vecslp_void_p *, int);
+ vecvectree *, int);
extern LOC find_bb_location (basic_block);
extern bb_vec_info vect_slp_analyze_bb (basic_block);
--- gcc/tree-vect-slp.c.jj 2013-01-31 18:28:54.0 +0100
+++ gcc/tree-vect-slp.c 2013-02-28 14:18:48.339791016 +0100
@@ -2614,14 +2614,14 @@ vect_get_slp_vect_defs (slp_tree slp_nod
void
vect_get_slp_defs (vectree ops, slp_tree slp_node,
- vecslp_void_p *vec_oprnds, int reduc_index)
+ vecvectree *vec_oprnds, int reduc_index)
{
gimple first_stmt;
int number_of_vects = 0, i;
unsigned int child_index = 0;
HOST_WIDE_INT lhs_size_unit, rhs_size_unit;
slp_tree child = NULL;
- vectree *vec_defs;
+ vectree vec_defs;
tree oprnd;
bool vectorized_defs;
@@ -2676,19 +2676,20 @@ vect_get_slp_defs (vectree ops, slp_tr
}
/* Allocate memory for vectorized defs. */
- vec_alloc (vec_defs, number_of_vects);
+ vec_defs = vNULL;
+ vec_defs.create (number_of_vects);
/* For reduction defs we call vect_get_constant_vectors (), since we are
looking for initial loop invariant values. */
if (vectorized_defs reduc_index == -1)
/* The defs are already vectorized. */
-vect_get_slp_vect_defs (child, vec_defs);
+ vect_get_slp_vect_defs (child, vec_defs);
else
/* Build vectors from scalar defs. */
-vect_get_constant_vectors (oprnd, slp_node, vec_defs, i,
+ vect_get_constant_vectors (oprnd, slp_node, vec_defs, i,
number_of_vects, reduc_index);
- vec_oprnds-quick_push ((slp_void_p) vec_defs);
+ vec_oprnds-quick_push (vec_defs);
/* For reductions, we only need initial values. */
if (reduc_index != -1)
--- gcc/tree-vect-stmts.c.jj2013-02-26 10:58:16.0 +0100
+++ gcc/tree-vect-stmts.c 2013-02-28 14:23:38.181910467 +0100
@@ -1583,7 +1583,7 @@ vect_get_vec_defs (tree op0, tree op1, g
int nops = (op1 == NULL_TREE) ? 1 : 2;
vectree ops;
ops.create (nops);
- vecslp_void_p vec_defs;
+ vecvectree vec_defs;
vec_defs.create (nops);
ops.quick_push (op0);
@@ -1592,9 +1592,9 @@ vect_get_vec_defs (tree op0, tree op1, g
vect_get_slp_defs (ops, slp_node, vec_defs, reduc_index);
- *vec_oprnds0 = *((vectree *) vec_defs[0]);
+ *vec_oprnds0 = vec_defs[0];
if (op1)
-*vec_oprnds1 = *((vectree *) vec_defs[1]);
+ *vec_oprnds1 = vec_defs[1];
ops.release ();
vec_defs.release ();
@@ -1882,14 +1882,14 @@ vectorizable_call (gimple stmt, gimple_s
if (slp_node)
{
- vecslp_void_p vec_defs;
+ vecvectree vec_defs;
vec_defs.create (nargs);
vectree vec_oprnds0;
for (i = 0; i nargs; i++)
vargs.quick_push (gimple_call_arg (stmt, i));
vect_get_slp_defs (vargs, slp_node, vec_defs, -1);
- vec_oprnds0 = *((vectree *) vec_defs[0]);
+ vec_oprnds0 = vec_defs[0];
/* Arguments are ready. Create the new vector stmt. */
FOR_EACH_VEC_ELT (vec_oprnds0, i, vec_oprnd0)
@@ -1897,7 +1897,7 @@ vectorizable_call (gimple stmt, gimple_s
size_t k;
for (k = 0; k nargs; k++)
{
- vectree vec_oprndsk = *((vectree *) vec_defs[k]);
+ vectree vec_oprndsk =
[PATCH] Fix libcpp memory leak (PR middle-end/56461)
Hi!
On #include signal.h on Linux we leak memory in the preprocessor.
The problem is that signal.h doesn't have standard multiple inclusion
guards, the multiple inclusion guard is defined only conditionally
and the whole header isn't protected by that guard, just big part of it.
Furthermore, signal.h includes sys/context.h, which later includes signal.h
again. That means we call read_file on the signal.h header while it is
stacked (so file-buffer != NULL !file-buffer_valid) and just overwrite
file-buffer with a newly allocated memory. Later on when doing
_cpp_pop_file_buffer on the inner signal.h we free the second buffer
and clear file-buffer{,_start,_valid} fields, then later on when the outer
signal.h (same _cpp_file structure) is being unstacked, those fields are
already NULL and we don't free anything, thus we leak the memory.
Fixed by making struct cpp_buffer be the owner of the buffer, responsible
for freeing it, rather than struct _cpp_file. Bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
2013-02-28 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* internal.h (struct cpp_buffer): Add to_free field.
(_cpp_pop_file_buffer): Add third argument.
* files.c (_cpp_stack_file): Set buffer-to_free.
(_cpp_pop_file_buffer): Add to_free argument. Free to_free
if non-NULL, and if equal to file-buffer_start, also clear
file-buffer{,_start,_valid}.
* directives.c (_cpp_pop_buffer): Pass buffer-to_free
to _cpp_pop_file_buffer.
--- libcpp/internal.h.jj2013-02-27 14:05:39.0 +0100
+++ libcpp/internal.h 2013-02-28 17:09:41.263168009 +0100
@@ -301,6 +301,8 @@ struct cpp_buffer
const unsigned char *buf;/* Entire character buffer. */
const unsigned char *rlimit; /* Writable byte at end of file. */
+ const unsigned char *to_free; /* Pointer that should be freed when
+ popping the buffer. */
_cpp_line_note *notes; /* Array of notes. */
unsigned int cur_note; /* Next note to process. */
@@ -635,7 +637,8 @@ extern int _cpp_compare_file_date (cpp_r
extern void _cpp_report_missing_guards (cpp_reader *);
extern void _cpp_init_files (cpp_reader *);
extern void _cpp_cleanup_files (cpp_reader *);
-extern void _cpp_pop_file_buffer (cpp_reader *, struct _cpp_file *);
+extern void _cpp_pop_file_buffer (cpp_reader *, struct _cpp_file *,
+ const unsigned char *);
extern bool _cpp_save_file_entries (cpp_reader *pfile, FILE *f);
extern bool _cpp_read_file_entries (cpp_reader *, FILE *);
extern const char *_cpp_get_file_name (_cpp_file *);
--- libcpp/files.c.jj 2013-02-28 10:57:50.0 +0100
+++ libcpp/files.c 2013-02-28 17:10:06.023024353 +0100
@@ -877,6 +877,7 @@ _cpp_stack_file (cpp_reader *pfile, _cpp
!CPP_OPTION (pfile, directives_only));
buffer-file = file;
buffer-sysp = sysp;
+ buffer-to_free = file-buffer_start;
/* Initialize controlling macro state. */
pfile-mi_valid = true;
@@ -1418,7 +1419,8 @@ cpp_push_default_include (cpp_reader *pf
/* Do appropriate cleanup when a file INC's buffer is popped off the
input stack. */
void
-_cpp_pop_file_buffer (cpp_reader *pfile, _cpp_file *file)
+_cpp_pop_file_buffer (cpp_reader *pfile, _cpp_file *file,
+ const unsigned char *to_free)
{
/* Record the inclusion-preventing macro, which could be NULL
meaning no controlling macro. */
@@ -1428,12 +1430,15 @@ _cpp_pop_file_buffer (cpp_reader *pfile,
/* Invalidate control macros in the #including file. */
pfile-mi_valid = false;
- if (file-buffer_start)
+ if (to_free)
{
- free ((void *) file-buffer_start);
- file-buffer_start = NULL;
- file-buffer = NULL;
- file-buffer_valid = false;
+ if (to_free == file-buffer_start)
+ {
+ file-buffer_start = NULL;
+ file-buffer = NULL;
+ file-buffer_valid = false;
+ }
+ free ((void *) to_free);
}
}
--- libcpp/directives.c.jj 2013-01-15 09:04:55.0 +0100
+++ libcpp/directives.c 2013-02-28 17:09:53.239097488 +0100
@@ -2558,6 +2558,7 @@ _cpp_pop_buffer (cpp_reader *pfile)
cpp_buffer *buffer = pfile-buffer;
struct _cpp_file *inc = buffer-file;
struct if_stack *ifs;
+ const unsigned char *to_free;
/* Walk back up the conditional stack till we reach its level at
entry to this file, issuing error messages. */
@@ -2571,6 +2572,7 @@ _cpp_pop_buffer (cpp_reader *pfile)
/* _cpp_do_file_change expects pfile-buffer to be the new one. */
pfile-buffer = buffer-prev;
+ to_free = buffer-to_free;
free (buffer-notes);
/* Free the buffer object now; we may want to push a new buffer
@@ -2579,7 +2581,7 @@ _cpp_pop_buffer (cpp_reader *pfile)
if (inc)
{
- _cpp_pop_file_buffer (pfile, inc);
+ _cpp_pop_file_buffer (pfile, inc,
[PATCH] Add no_sanitize_address attribute (PR sanitizer/56454)
Hi!
I'm not very happy about the renaming of the attribute, but it happened
in clang already, so here is a patch to do the same in gcc too.
The old name of the attribute is recognized too for compatibility e.g.
with code written for clang 3.[12] sanitizer, and during attribute parsing
changed into no_sanitize_address attribute which asan.c later tests.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-02-28 Konstantin Serebryany konstantin.s.serebry...@gmail.com
Jakub Jelinek ja...@redhat.com
PR sanitizer/56454
* asan.c (gate_asan): Lookup no_sanitize_address instead of
no_address_safety_analysis attribute.
* doc/extend.texi (no_address_safety_attribute): Rename to
no_sanitize_address attribute, mention no_address_safety_analysis
attribute as deprecated alias.
* c-common.c (handle_no_sanitize_address_attribute): New function.
(c_common_attribute_table): Add no_sanitize_address attribute.
(handle_no_address_safety_analysis_attribute): Add
no_sanitize_address attribute, not no_address_safety_analysis
attribute.
* g++.dg/asan/default-options-1.C (__asan_default_options): Use
no_sanitize_address attribute rather than no_address_safety_analysis.
* g++.dg/asan/sanitizer_test_utils.h
(ATTRIBUTE_NO_ADDRESS_SAFETY_ANALYSIS): Likewise.
* c-c++-common/asan/attrib-1.c: Test no_sanitize_address attribute
in addition to no_address_safety_analysis.
--- gcc/asan.c.jj 2013-02-18 16:39:55.600894178 +0100
+++ gcc/asan.c 2013-02-28 17:29:07.520363403 +0100
@@ -2278,6 +2278,6 @@ gate_asan (void)
{
return flag_asan != 0
- !lookup_attribute (no_address_safety_analysis,
+ !lookup_attribute (no_sanitize_address,
DECL_ATTRIBUTES (current_function_decl));
}
--- gcc/c-family/c-common.c.jj 2013-02-19 07:40:00.348377798 +0100
+++ gcc/c-family/c-common.c 2013-02-28 18:01:59.549869867 +0100
@@ -307,8 +307,10 @@ static tree handle_common_attribute (tre
static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
static tree handle_hot_attribute (tree *, tree, tree, int, bool *);
static tree handle_cold_attribute (tree *, tree, tree, int, bool *);
+static tree handle_no_sanitize_address_attribute (tree *, tree, tree,
+ int, bool *);
static tree handle_no_address_safety_analysis_attribute (tree *, tree, tree,
int, bool *);
static tree handle_noinline_attribute (tree *, tree, tree, int, bool *);
static tree handle_noclone_attribute (tree *, tree, tree, int, bool *);
static tree handle_leaf_attribute (tree *, tree, tree, int, bool *);
@@ -715,6 +717,9 @@ const struct attribute_spec c_common_att
0, 0, true, false, false,
handle_no_address_safety_analysis_attribute,
false },
+ { no_sanitize_address,0, 0, true, false, false,
+ handle_no_sanitize_address_attribute,
+ false },
{ warning, 1, 1, true, false, false,
handle_error_attribute, false },
{ error, 1, 1, true, false, false,
@@ -6505,12 +6510,12 @@ handle_cold_attribute (tree *node, tree
return NULL_TREE;
}
-/* Handle a no_address_safety_analysis attribute; arguments as in
+/* Handle a no_sanitize_address attribute; arguments as in
struct attribute_spec.handler. */
static tree
-handle_no_address_safety_analysis_attribute (tree *node, tree name, tree, int,
-bool *no_add_attrs)
+handle_no_sanitize_address_attribute (tree *node, tree name, tree, int,
+ bool *no_add_attrs)
{
if (TREE_CODE (*node) != FUNCTION_DECL)
{
@@ -6521,6 +6526,23 @@ handle_no_address_safety_analysis_attrib
return NULL_TREE;
}
+/* Handle a no_address_safety_analysis attribute; arguments as in
+ struct attribute_spec.handler. */
+
+static tree
+handle_no_address_safety_analysis_attribute (tree *node, tree name, tree, int,
+bool *no_add_attrs)
+{
+ if (TREE_CODE (*node) != FUNCTION_DECL)
+warning (OPT_Wattributes, %qE attribute ignored, name);
+ else if (!lookup_attribute (no_sanitize_address, DECL_ATTRIBUTES (*node)))
+DECL_ATTRIBUTES (*node)
+ = tree_cons (get_identifier (no_sanitize_address),
+ NULL_TREE, DECL_ATTRIBUTES (*node));
+ *no_add_attrs = true;
+ return NULL_TREE;
+}
+
/* Handle a noinline attribute; arguments as in
struct attribute_spec.handler. */
--- gcc/doc/extend.texi.jj 2013-02-25 15:25:43.897463673 +0100
+++ gcc/doc/extend.texi 2013-02-28 17:31:40.789468660 +0100
@@ -2133,7 +2133,8 @@ attributes are currently defined for fun
C++ PATCH for c++/56481 (time hog with repeated )
The problem with this testcase was that for a repeated , each call of
potential_constant_expression_1 led to two calls for the LHS, giving it
O(N^2) complexity. Fixed by avoiding the redundant call in
maybe_constant_value by calling cxx_eval_outermost_constant_expr directly.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 001c03d979ea1aaa9bc9565f2b9c82371cc481f1
Author: Jason Merrill ja...@redhat.com
Date: Thu Feb 28 12:30:40 2013 -0500
PR c++/56481
* semantics.c (potential_constant_expression_1): Use
cxx_eval_outermost_constant_expr rather than maybe_constant_value.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 9446f83..8038aa2 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -8683,10 +8683,12 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
case ROUND_MOD_EXPR:
{
tree denom = TREE_OPERAND (t, 1);
- /* We can't call maybe_constant_value on an expression
+ if (!potential_constant_expression_1 (denom, rval, flags))
+ return false;
+ /* We can't call cxx_eval_outermost_constant_expr on an expression
that hasn't been through fold_non_dependent_expr yet. */
if (!processing_template_decl)
- denom = maybe_constant_value (denom);
+ denom = cxx_eval_outermost_constant_expr (denom, true);
if (integer_zerop (denom))
{
if (flags tf_error)
@@ -8696,7 +8698,8 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
else
{
want_rval = true;
- goto binary;
+ return potential_constant_expression_1 (TREE_OPERAND (t, 0),
+ want_rval, flags);
}
}
@@ -8731,7 +8734,7 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
if (!potential_constant_expression_1 (op, rval, flags))
return false;
if (!processing_template_decl)
- op = maybe_constant_value (op);
+ op = cxx_eval_outermost_constant_expr (op, true);
if (tree_int_cst_equal (op, tmp))
return potential_constant_expression_1 (TREE_OPERAND (t, 1), rval, flags);
else
@@ -8793,7 +8796,7 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
if (!potential_constant_expression_1 (tmp, rval, flags))
return false;
if (!processing_template_decl)
- tmp = maybe_constant_value (tmp);
+ tmp = cxx_eval_outermost_constant_expr (tmp, true);
if (integer_zerop (tmp))
return potential_constant_expression_1 (TREE_OPERAND (t, 2),
want_rval, flags);
Re: [PATCH] Fix a slp leak caused by vec.h conversion (PR middle-end/56461)
On Thu, Feb 28, 2013 at 3:06 PM, Jakub Jelinek ja...@redhat.com wrote: Hi! This is small, but quite common memory leak in slp vectorization. vec_alloc (vec_defs, number_of_vects); on vl_ptr-ish vectree *vec_defs; first calls new on the vectree (i.e. allocates sizeof (void *) bytes), and then actually creates vector pointed to by that. Later on we copy the content of what it points to, but don't actually free the void * sized allocation. Fixed by changing the vector to be actually vecvectree *, which also simplifies the callers. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2013-02-28 Jakub Jelinek ja...@redhat.com PR middle-end/56461 * tree-vectorizer.h (vect_get_slp_defs): Change 3rd argument type to vecvectree *. * tree-vect-slp.c (vect_get_slp_defs): Likewise. Change vec_defs to be vectree instead of vectree *, set vec_defs to vNULL and call vec_defs.create (number_of_vects), adjust other uses of vec_defs. * tree-vect-stmts.c (vect_get_vec_defs, vectorizable_call, vectorizable_condition): Adjust vect_get_slp_defs callers. OK. Diego.
Re: [PATCH] Add no_sanitize_address attribute (PR sanitizer/56454)
Jakub Jelinek ja...@redhat.com writes: Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2013-02-28 Konstantin Serebryany konstantin.s.serebry...@gmail.com Jakub Jelinek ja...@redhat.com PR sanitizer/56454 * asan.c (gate_asan): Lookup no_sanitize_address instead of no_address_safety_analysis attribute. * doc/extend.texi (no_address_safety_attribute): Rename to no_sanitize_address attribute, mention no_address_safety_analysis attribute as deprecated alias. * c-common.c (handle_no_sanitize_address_attribute): New function. (c_common_attribute_table): Add no_sanitize_address attribute. (handle_no_address_safety_analysis_attribute): Add no_sanitize_address attribute, not no_address_safety_analysis attribute. * g++.dg/asan/default-options-1.C (__asan_default_options): Use no_sanitize_address attribute rather than no_address_safety_analysis. * g++.dg/asan/sanitizer_test_utils.h (ATTRIBUTE_NO_ADDRESS_SAFETY_ANALYSIS): Likewise. * c-c++-common/asan/attrib-1.c: Test no_sanitize_address attribute in addition to no_address_safety_analysis. This OK, thanks. -- Dodji
Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
On Thu, Feb 28, 2013 at 9:07 AM, Xinliang David Li davi...@google.com wrote: Any insight about the relative performance of the two implementations? We have a benchmark for the speed of unwinder. Here are results. The number /1, /2, etc. is the number of levels in the stack trace. Using frame-based unwinder: Benchmark Time(ns)CPU(ns) Iterations BM_GetStackTrace/1 29 29 24137931 BM_GetStackTrace/2 38 38 17948718 BM_GetStackTrace/3 43 44 16279070 BM_GetStackTrace/4 57 57 1000 BM_GetStackTrace/5 62 62 1000 BM_GetStackTrace/6 65 65 1000 BM_GetStackTrace/7 65 64 1000 BM_GetStackTrace/8 65 65 1000 BM_GetStackTrace/9 65 65 1000 BM_GetStackTrace/10 65 65 1000 Using libgcc: Benchmark Time(ns)CPU(ns) Iterations BM_GetStackTrace/11543 1543 47 BM_GetStackTrace/22042 2057 35 BM_GetStackTrace/32378 2366 291667 BM_GetStackTrace/42754 2720 25 BM_GetStackTrace/53212 3200 218750 BM_GetStackTrace/63655 3651 19 BM_GetStackTrace/74039 4000 175000 BM_GetStackTrace/84009 4000 175000 BM_GetStackTrace/94002 4000 175000 BM_GetStackTrace/10 4017 4000 175000 Using libunwind: Benchmark Time(ns)CPU(ns) Iterations BM_GetStackTrace/1 1091086363636 BM_GetStackTrace/2 121122583 BM_GetStackTrace/3 130130500 BM_GetStackTrace/4 133132500 BM_GetStackTrace/5 148148467 BM_GetStackTrace/6 1621624375000 BM_GetStackTrace/7 1741754117647 BM_GetStackTrace/8 185185389 BM_GetStackTrace/9 1881873684211 BM_GetStackTrace/101881873684211 Conclusions: - frame based unwinder is hard to beat (re-confirmed :-) - libunwind is getting really close at 3x the overhead - libgcc is nowhere close at 50x. -- Paul Pluzhnikov
Re: Recent sigprocmask changes in libgo/runtime/proc.c killed thread debugging on alpha.
On Thu, Feb 28, 2013 at 1:21 PM, Uros Bizjak ubiz...@gmail.com wrote: On Thu, Feb 28, 2013 at 9:55 PM, Ian Lance Taylor i...@google.com wrote: On Thu, Feb 28, 2013 at 12:44 PM, Uros Bizjak ubiz...@gmail.com wrote: I'm fine with not blocking a signal that the debugger needs, but I have no idea what that signal might be. Can you please advise me how to avoid blocking certain signal? I have a small testcase using pthreads that dies in the same way, so in fact the problem is not go specific. Anyway, I would like to investigate this issue some more. To avoid blocking a certain signal, after this line in proc.c sigfillset(clear); add sigdelset(clear, SIGINT); That will block all the signals other than SIGINT. Pick whatever signals you don't want to block, and call sigdelset as often as you like. It may or may not help to know that there are two signals that are special to the NPTL library: __SIGRTMIN and __SIGRTMIN + 1. I don't see why that would be an issue here, but who knows. Thanks for your instructions, I was able to find that SIGTRAP does all the difference! Thanks. I committed this patch. Ian foo.patch Description: Binary data
Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
On Thu, Feb 28, 2013 at 11:59 AM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Feb 28, 2013 at 11:57:48AM -0800, Cary Coutant wrote: Similarly, couldn't dlopen drop the loader lock while calling malloc? It can't, but perhaps it could call some alternative malloc instead (the simpler malloc version in ld.so or similar). ld-linux starts calling the simpler malloc in dl-minimal.c, then switches to real libc.so.6 malloc later on. This behavior causes a lot of pain to anyone who tries to interpose malloc and use dlsym(RTLD_NEXT,...) or similar from the interposer. Roland explained to me ~15 years ago why it is that way (it had something to do with Hurd); an explanation I can't find at the moment. -- Paul Pluzhnikov
[C++ Patch] Tiny grokdeclarator clean up
Hi,
for 4.9 I'd like to clean-up a bit grokdeclarator: today I noticed this
low hanging fruit which seems straightforward enough for 4.8.0 too
(unless it hints to a bug?!?)
Thanks,
Paolo.
//
2013-03-01 Paolo Carlini paolo.carl...@oracle.com
* decl.c (grokdeclarator): Remove dead code.
Index: decl.c
===
--- decl.c (revision 196362)
+++ decl.c (working copy)
@@ -8599,7 +8599,6 @@ grokdeclarator (const cp_declarator *declarator,
int explicit_int = 0;
int explicit_char = 0;
int defaulted_int = 0;
- tree dependent_name = NULL_TREE;
tree typedef_decl = NULL_TREE;
const char *name = NULL;
@@ -9196,12 +9195,6 @@ grokdeclarator (const cp_declarator *declarator,
}
friendp = decl_spec_seq_has_spec_p (declspecs, ds_friend);
- if (dependent_name !friendp)
-{
- error (%%T::%D% is not a valid declarator, ctype, dependent_name);
- return error_mark_node;
-}
-
/* Issue errors about use of storage classes for parameters. */
if (decl_context == PARM)
{
Re: [C++ Patch] Tiny grokdeclarator clean up
On 02/28/2013 07:31 PM, Paolo Carlini wrote: for 4.9 I'd like to clean-up a bit grokdeclarator: today I noticed this low hanging fruit which seems straightforward enough for 4.8.0 too (unless it hints to a bug?!?) OK, looks like the code that set that variable was removed in 2004, by the cdk_* rewrite. Guess we would have noticed any issues by now. :) Jason
Re: [PATCH] C++ math constants
On Thu, Feb 21, 2013 at 12:38 PM, Benjamin De Kosnik b...@redhat.com wrote:
Not seeing it.
Say for:
#include iostream
// A class for math constants.
templatetypename _RealType
struct __math_constants
{
// Constant @f$ \pi @f$.
static constexpr _RealType __pie =
3.1415926535897932384626433832795029L; };
templateclass T
void print(const T t) { std::cout t; }
int main()
{
print(__math_constantsdouble::__pie);
return 0;
}
I'm not getting any definition, even at -O0.
Even more so: how would an explicit instantiation even work?
Try this simplified code:
templatetypename T
struct a {
static constexpr T m = T(1);
};
If you try
template constexpr int a::mint;
nothing gets emitted into the object file (this is even with the trunk
gcc). If I use
template constexpr int a::mint = 1;
I get a definition but I have to remove the initialization in the
class definition itself. If I use
struct template aint;
there is no output in the file as well.
All this makes perfect sense with gcc. Since the constant will never
be referenced as a variable there is no need for the compiler to emit
a definition. If the argument is that there has to be one, how would
it be done?
[PATCH ARM-Embedded-4_7-branch] fixing incoorect instruction length in checkin r193980
Hi, On ARM-Embedded-4_7 branch, check-in(r193980) causes a branch out of range bug. Root cause is the incorrect instruction length set by that check-in. Since the length of instruction should strictly reflect the pattern it matches, this patch fixes it by correcting the length. Patch applied to ARM-Embedded-4_7-branch as r196368. Thanks. 2013-03-01 Bin Cheng bin.ch...@arm.com * config/arm/arm.md (*arm_addsi3, *arm_subsi3_insn, *arm_mulsi3_v6) (*arm_andsi3_insn, andsi_notsi_si, *iorsi3_insn, *arm_xorsi3) (*arm_shiftsi3): Change attribute length from 2 to 4 for all alternatives.
