Re: [Patch] Add OPT_Wattributes to ignored attributes on template args
Ping: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02256.html Regards, Ryan Mansfield On 15-09-29 04:21 PM, Ryan Mansfield wrote: Hi, In canonicalize_type_argument attributes are being discarded with a warning. Should it be added to OPT_Wattributes? 2015-09-29 Ryan Mansfield <rmansfi...@qnx.com> * pt.c (canonicalize_type_argument): Use OPT_Wattributes in warning.
[Patch] Add OPT_Wattributes to ignored attributes on template args
Hi, In canonicalize_type_argument attributes are being discarded with a warning. Should it be added to OPT_Wattributes? 2015-09-29 Ryan Mansfield <rmansfi...@qnx.com> * pt.c (canonicalize_type_argument): Use OPT_Wattributes in warning. Index: cp/pt.c === --- cp/pt.c (revision 228265) +++ cp/pt.c (working copy) @@ -6888,7 +6888,7 @@ tree canon = strip_typedefs (arg, _attributes); if (removed_attributes && (complain & tf_warning)) -warning (0, "ignoring attributes on template argument %qT", arg); +warning (OPT_Wattributes, "ignoring attributes on template argument %qT", arg); return canon; } Regards, Ryan Mansfield
[Patch][testsuite,i386]: Remove include of values.h from avx512
Hi, Some of the avx512 tests include values.h which is an obsolete header on Linux which provides compatibility macros based on limits.h and float.h definitions. On QNX we have no values.h ;), so these tests fail to build. The include doesn't appear to be needed on Linux, as x86_64-linux-gnu has no regressions with the include removed. I wasn't able to determine which target, if any, required values.h. 2015-04-15 Ryan Mansfield rmansfi...@qnx.com * gcc.target/i386/avx512bw-vpermi2w-2.c: Remove values.h include. * gcc.target/i386/avx512bw-vpermt2w-2.c: Ditto. * gcc.target/i386/avx512bw-vpmaddubsw-2.c: Ditto. * gcc.target/i386/avx512bw-vpmaddwd-2.c: Ditto. * gcc.target/i386/avx512dq-vfpclasspd-2.c: Ditto. * gcc.target/i386/avx512dq-vfpclassps-2.c: Dttto. * gcc.target/i386/avx512vbmi-vpermi2b-2.c: Ditto. * gcc.target/i386/avx512vbmi-vpermt2b-2.c: Ditto. OK for trunk and gcc-5-branch? Regards, Ryan Mansfield - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Index: gcc/testsuite/gcc.target/i386/avx512bw-vpermi2w-2.c === --- gcc/testsuite/gcc.target/i386/avx512bw-vpermi2w-2.c (revision 222125) +++ gcc/testsuite/gcc.target/i386/avx512bw-vpermi2w-2.c (working copy) @@ -7,7 +7,6 @@ #define SIZE (AVX512F_LEN / 16) #include math.h -#include values.h #include avx512f-mask-type.h #define NUM 32 Index: gcc/testsuite/gcc.target/i386/avx512bw-vpermt2w-2.c === --- gcc/testsuite/gcc.target/i386/avx512bw-vpermt2w-2.c (revision 222125) +++ gcc/testsuite/gcc.target/i386/avx512bw-vpermt2w-2.c (working copy) @@ -7,7 +7,6 @@ #define SIZE (AVX512F_LEN / 16) #include math.h -#include values.h #include avx512f-mask-type.h #define NUM 32 Index: gcc/testsuite/gcc.target/i386/avx512bw-vpmaddubsw-2.c === --- gcc/testsuite/gcc.target/i386/avx512bw-vpmaddubsw-2.c (revision 222125) +++ gcc/testsuite/gcc.target/i386/avx512bw-vpmaddubsw-2.c (working copy) @@ -6,7 +6,6 @@ #include avx512f-helper.h #include math.h -#include values.h #define SIZE (AVX512F_LEN / 16) #include avx512f-mask-type.h Index: gcc/testsuite/gcc.target/i386/avx512bw-vpmaddwd-2.c === --- gcc/testsuite/gcc.target/i386/avx512bw-vpmaddwd-2.c (revision 222125) +++ gcc/testsuite/gcc.target/i386/avx512bw-vpmaddwd-2.c (working copy) @@ -6,7 +6,6 @@ #include avx512f-helper.h #include math.h -#include values.h #define SIZE (AVX512F_LEN / 32) #include avx512f-mask-type.h Index: gcc/testsuite/gcc.target/i386/avx512dq-vfpclasspd-2.c === --- gcc/testsuite/gcc.target/i386/avx512dq-vfpclasspd-2.c (revision 222125) +++ gcc/testsuite/gcc.target/i386/avx512dq-vfpclasspd-2.c (working copy) @@ -6,7 +6,6 @@ #include avx512f-helper.h #include math.h -#include values.h #define SIZE (AVX512F_LEN / 64) #include avx512f-mask-type.h Index: gcc/testsuite/gcc.target/i386/avx512dq-vfpclassps-2.c === --- gcc/testsuite/gcc.target/i386/avx512dq-vfpclassps-2.c (revision 222125) +++ gcc/testsuite/gcc.target/i386/avx512dq-vfpclassps-2.c (working copy) @@ -6,7 +6,6 @@ #include avx512f-helper.h #include math.h -#include values.h #include avx512f-mask-type.h #define SIZE (AVX512F_LEN / 32) Index: gcc/testsuite/gcc.target/i386/avx512vbmi-vpermi2b-2.c === --- gcc/testsuite/gcc.target/i386/avx512vbmi-vpermi2b-2.c (revision 222125) +++ gcc/testsuite/gcc.target/i386/avx512vbmi-vpermi2b-2.c (working copy) @@ -8,7 +8,6 @@ #define SIZE (AVX512F_LEN / 8) #include math.h -#include values.h #include avx512f-mask-type.h #define NUM 32 Index: gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-2.c === --- gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-2.c (revision 222125) +++ gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-2.c (working copy) @@ -8,7 +8,6 @@ #define SIZE (AVX512F_LEN / 8) #include math.h -#include values.h #include avx512f-mask-type.h #define NUM 32
[Patch][testsuite] Fix a few test cases
Hi,
Here are a few test tweaks. In 921202-1.c, if STACK_SIZE is used then
VLEN will blow the stack with 64bit longs. e.g. if STACK_SIZE == 512K
then 3 arrays of 32767 longs means at a minimum 767K of stack will be
used at -O0. In pr51447.c, the rbx global register is clobbering the rbx
of main's caller, which can cause test case crashes on return.
2014-12-12 Ryan Mansfield rmansfi...@qnx.com
* gcc.c-torture/execute/921202-1.c: Adjust VLEN.
* gcc.c-torture/execute/pr51447.c: Restore rbx for x86-64.
* gcc.dg/cpp/trad/include.c: Exclude QNX targets.
OK?
Regards,
Ryan Mansfield
Index: gcc/testsuite/gcc.c-torture/execute/921202-1.c
===
--- gcc/testsuite/gcc.c-torture/execute/921202-1.c (revision 218685)
+++ gcc/testsuite/gcc.c-torture/execute/921202-1.c (working copy)
@@ -2,7 +2,7 @@
#ifndef STACK_SIZE
#define VLEN 2055
#else
-#define VLEN ((STACK_SIZE/16) - 1)
+#define VLEN ((STACK_SIZE/32) - 1)
#endif
main ()
{
Index: gcc/testsuite/gcc.c-torture/execute/pr51447.c
===
--- gcc/testsuite/gcc.c-torture/execute/pr51447.c (revision 218685)
+++ gcc/testsuite/gcc.c-torture/execute/pr51447.c (working copy)
@@ -14,6 +14,10 @@
main (void)
{
__label__ nonlocal_lab;
+#ifdef __x86_64__
+ void *rbx __asm (rbx);
+ void *saved_rbx = rbx;
+#endif
__attribute__((noinline, noclone)) void
bar (void *func)
{
@@ -21,9 +25,15 @@
goto nonlocal_lab;
}
bar (nonlocal_lab);
+#ifdef __x86_64__
+ rbx = saved_rbx;
+#endif
return 1;
nonlocal_lab:
if (ptr != nonlocal_lab)
abort ();
+#ifdef __x86_64__
+ rbx = saved_rbx;
+#endif
return 0;
}
Index: gcc/testsuite/gcc.dg/cpp/trad/include.c
===
--- gcc/testsuite/gcc.dg/cpp/trad/include.c (revision 218685)
+++ gcc/testsuite/gcc.dg/cpp/trad/include.c (working copy)
@@ -1,11 +1,11 @@
/* Copyright (c) 2002 Free Software Foundation Inc. */
-/* Test that macros are not expanded in the quotes of #inlcude. */
+/* Test that macros are not expanded in the quotes of #include. */
/* vxWorksCommon.h uses the # operator to construct the name of an
include file, thus making the file incompatible with -traditional-cpp.
Newlib uses ## when including stdlib.h as of 2007-09-07. */
-/* { dg-do preprocess { target { { ! vxworks_kernel } { ! newlib } } } } */
+/* { dg-do preprocess { target { { ! vxworks_kernel } { ! newlib } { ! *-*-qnx* }} } } */
#define __STDC__ 1 /* Stop complaints about non-ISO compilers. */
#define stdlib 1
Re: [Patch]: Check __gthread_setspecific return
On 14-12-05 05:53 PM, Jeff Law wrote: On 12/02/14 10:53, Ryan Mansfield wrote: Hi, Underlying pthread_setspecific can return non-zero with ENOMEM or EINVAL. 2014-12-02 Ryan Mansfield rmansfi...@qnx.com * emutls.c (__emutls_get_address): Check __gthread_setspecific returns. OK? OK. Thanks Jeff. Could someone please apply on my behalf? Regards, Ryan Mansfield
Re: [Patch][testsuite] Fix a few test cases
On 14-12-12 04:29 PM, Mike Stump wrote:
On Dec 12, 2014, at 11:38 AM, Ryan Mansfield rmansfi...@qnx.com wrote:
Here are a few test tweaks. In 921202-1.c, if STACK_SIZE is used then VLEN will
blow the stack with 64bit longs. e.g. if STACK_SIZE == 512K then 3 arrays of
32767 longs means at a minimum 767K of stack will be used at -O0. In pr51447.c,
the rbx global register is clobbering the rbx of main's caller, which can cause
test case crashes on return.
2014-12-12 Ryan Mansfield rmansfi...@qnx.com
* gcc.c-torture/execute/921202-1.c: Adjust VLEN.
* gcc.c-torture/execute/pr51447.c: Restore rbx for x86-64.
* gcc.dg/cpp/trad/include.c: Exclude QNX targets.
OK?
Ok for first and third part. The second one, I would like an rbx/x86_64 person
to review.
Thanks. rbx is callee saved, and it's being clobbered.
e.g. on Linux x86-64
Breakpoint 1, main ()
at
/home/ryan/gnu/gcc/trunk/gcc/testsuite/gcc.c-torture/execute/pr51447.c:13
13 {
1: x/i $pc
= 0x40054e main:push %rbp
(gdb) info reg rbx
rbx0x0 0
(gdb) s
26return 0;
1: x/i $pc
= 0x400596 main+72: mov$0x0,%eax
(gdb) info reg rbx
rbx0x400586 4195718r
The global register var docs say:
A function that can alter the value of a global register variable
cannot safely be called from a function compiled without this variable,
because it could clobber the value the caller expects to find there on
return. Therefore, the function that is the entry point into the part of
the program that uses the global register variable must explicitly save
and restore the value that belongs to its caller.
The updated diff switches the test to use inline asm to save/restore rbx
instead of the local reg vars, but maybe there's a better way.
Regards,
Ryan Mansfield
Index: gcc/testsuite/gcc.c-torture/execute/921202-1.c
===
--- gcc/testsuite/gcc.c-torture/execute/921202-1.c (revision 218685)
+++ gcc/testsuite/gcc.c-torture/execute/921202-1.c (working copy)
@@ -2,7 +2,7 @@
#ifndef STACK_SIZE
#define VLEN 2055
#else
-#define VLEN ((STACK_SIZE/16) - 1)
+#define VLEN ((STACK_SIZE/32) - 1)
#endif
main ()
{
Index: gcc/testsuite/gcc.c-torture/execute/pr51447.c
===
--- gcc/testsuite/gcc.c-torture/execute/pr51447.c (revision 218685)
+++ gcc/testsuite/gcc.c-torture/execute/pr51447.c (working copy)
@@ -14,6 +14,10 @@
main (void)
{
__label__ nonlocal_lab;
+#ifdef __x86_64__
+ void *saved_rbx;
+ asm volatile (movq %%rbx, %0 : =r (saved_rbx) : : );
+#endif
__attribute__((noinline, noclone)) void
bar (void *func)
{
@@ -21,9 +25,15 @@
goto nonlocal_lab;
}
bar (nonlocal_lab);
+#ifdef __x86_64__
+ asm volatile (movq %0, %%rbx : : r (saved_rbx) : rbx );
+#endif
return 1;
nonlocal_lab:
if (ptr != nonlocal_lab)
abort ();
+#ifdef __x86_64__
+ asm volatile (movq %0, %%rbx : : r (saved_rbx) : rbx );
+#endif
return 0;
}
Index: gcc/testsuite/gcc.dg/cpp/trad/include.c
===
--- gcc/testsuite/gcc.dg/cpp/trad/include.c (revision 218685)
+++ gcc/testsuite/gcc.dg/cpp/trad/include.c (working copy)
@@ -1,11 +1,11 @@
/* Copyright (c) 2002 Free Software Foundation Inc. */
-/* Test that macros are not expanded in the quotes of #inlcude. */
+/* Test that macros are not expanded in the quotes of #include. */
/* vxWorksCommon.h uses the # operator to construct the name of an
include file, thus making the file incompatible with -traditional-cpp.
Newlib uses ## when including stdlib.h as of 2007-09-07. */
-/* { dg-do preprocess { target { { ! vxworks_kernel } { ! newlib } } } } */
+/* { dg-do preprocess { target { { ! vxworks_kernel } { ! newlib } { ! *-*-qnx* } } } } */
#define __STDC__ 1 /* Stop complaints about non-ISO compilers. */
#define stdlib 1
[Patch]: Check __gthread_setspecific return
Hi,
Underlying pthread_setspecific can return non-zero with ENOMEM or EINVAL.
2014-12-02 Ryan Mansfield rmansfi...@qnx.com
* emutls.c (__emutls_get_address): Check __gthread_setspecific
returns.
OK?
Regards,
Ryan Mansfield
Index: libgcc/emutls.c
===
--- libgcc/emutls.c (revision 218278)
+++ libgcc/emutls.c (working copy)
@@ -160,7 +160,8 @@
if (arr == NULL)
abort ();
arr-size = size;
- __gthread_setspecific (emutls_key, (void *) arr);
+ if (__gthread_setspecific (emutls_key, (void *) arr) != 0)
+ abort ();
}
else if (__builtin_expect (offset arr-size, 0))
{
@@ -174,7 +175,8 @@
arr-size = size;
memset (arr-data + orig_size, 0,
(size - orig_size) * sizeof (void *));
- __gthread_setspecific (emutls_key, (void *) arr);
+ if (__gthread_setspecific (emutls_key, (void *) arr) != 0)
+ abort ();
}
void *ret = arr-data[offset - 1];
[aarch64] Remove aarch64_function_profiler prototype
aarch64_function_profiler was removed in rev203028 but the prototype was left behind. If OK, can someone apply? Thanks. Regards, Ryan Mansfield 2014-04-30 Ryan Mansfield rmansfi...@qnx.com * config/aarch64/aarch64-protos.h (aarch64_function_profiler): Remove. Index: config/aarch64/aarch64-protos.h === --- config/aarch64/aarch64-protos.h (revision 209944) +++ config/aarch64/aarch64-protos.h (working copy) @@ -223,7 +223,6 @@ void aarch64_expand_mov_immediate (rtx, rtx); void aarch64_expand_prologue (void); void aarch64_expand_vector_init (rtx, rtx); -void aarch64_function_profiler (FILE *, int); void aarch64_init_cumulative_args (CUMULATIVE_ARGS *, const_tree, rtx, const_tree, unsigned); void aarch64_init_expanders (void);
Re: [Committed][ARM][AArch64] Patches previously ok'd for stage1
On 14-04-23 11:38 AM, Kyrill Tkachov wrote: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00934.html (http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01634.html) This patch breaks building arm-eabi with a 32bit host gcc. e.g ../../gcc/config/arm/aarch-common.c ../../gcc/config/arm/aarch-common.c:198: error: integer constant is too large for 'long' type ../../gcc/config/arm/aarch-common.c:205: error: integer constant is too large for 'long' type ../../gcc/config/arm/t-arm:83: recipe for target 'aarch-common.o' failed make[2]: *** [aarch-common.o] Error 1 Regards, Ryan Mansfield
Re: [Committed][ARM][AArch64] Patches previously ok'd for stage1
On 14-04-24 12:12 PM, Kyrill Tkachov wrote: On 24/04/14 14:44, Ryan Mansfield wrote: On 14-04-23 11:38 AM, Kyrill Tkachov wrote: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00934.html (http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01634.html) This patch breaks building arm-eabi with a 32bit host gcc. Hi Ryan, Does this patch fix it for you? I'll test and bootstrap it on arm. Kyrill 2014-04-24 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/aarch-common.c (aarch_rev16_shright_mask_imm_p): Use HOST_WIDE_INT_C for mask literal. (aarch_rev16_shleft_mask_imm_p): Likewise. Yes, your patch resolves the build issues. Thanks. Regards, Ryan Mansfield
gcc 4.8.2 online docs broken
A number of the links in 4.8.2 docs are broken (trunk seem to be OK). http://gcc.gnu.org/onlinedocs/4.8.2/gcc/ has 404s for the following: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/IA-64-Options.html#IA-64-Options http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/PDP-11-Options.html#PDP-11-Options http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/TILE-Gx-Options.html#TILE-Gx-Options http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Conditionally-supported-behavior.html#Conditionally-supported-behavior The w3c validator page says there's 54 broken links. It looks like anything with a - in the URL is affected. Regards, Ryan Mansfield
Re: [PATCH, preprocessor] Fix 56896
On 13-12-10 01:47 PM, Ryan Mansfield wrote: Fixes missing DIR_SEPARATOR if --with-gxx-include-dir configured as subdir of sysroot. 2013-12-10 Ryan Mansfield rmansfi...@qnx.com PR preprocessor/56896 * incpath.c (add_standard_paths): Strip trailing sysroot DIR_SEPARATOR only if appended path begins with DIR_SEPARATOR. Ping? Regards, Ryan Mansfield
Re: Fix bootstrap with -mno-accumulate-outgoing-args
On 14-01-01 09:23 AM, Jan Hubicka wrote: Here insn 765 gets adjusted for insn766 wihtout updating REG_ARGS_SIZE. This is IMO not bug in scheduler but bug in fact that insn 775 should not have the note on it when it is not adjusting stack pointer. This is because originally it was push instruction, but combine-stack-adjustments turned it into move. I think it should remove the ARG_SIZE note when doing so, since argument block size should be corrently annotated by preceeding stack adjustment insn. Bootstrapped/regtested x86_64-linux. Did not double check it is solves the ARM issue reported in PR, too. FWIW, I tested your patch and it doesn't address the ICE on ARM. Regards, Ryan Mansfield
Re: [PATCH, testsuite] Fix alignment in movapd tests
On 13-12-10 01:13 PM, Uros Bizjak wrote: Hello! 2013-12-10 Ryan Mansfield rmansfi...@qnx.com PR testsuite/59442 * gcc.target/i386/sse2-movapd-1.c: Fix alignment attributes. * gcc.target/i386/sse2-movapd-2.c: Likewise. * gcc.target/i386/avx-vmovapd-256-1.c: Likewise. * gcc.target/i386/avx-vmovapd-256-2.c: Likewise. OK for mainline and release branches. Thanks. Could someone please apply it for me? Regards, Ryan Mansfield
[PATCH, testsuite] Fix alignment in movapd tests
The movapd tests in the i386 testsuite fail if built with
-fstack-protector-strong or -fstack-protector-all, due to 8byte
alignment instead of 16, or 32byte alignment.
2013-12-10 Ryan Mansfield rmansfi...@qnx.com
PR testsuite/59442
* gcc.target/i386/sse2-movapd-1.c: Fix alignment attributes.
* gcc.target/i386/sse2-movapd-2.c: Likewise.
* gcc.target/i386/avx-vmovapd-256-1.c: Likewise.
* gcc.target/i386/avx-vmovapd-256-2.c: Likewise.
Regards,
Ryan Mansfield
Index: gcc/testsuite/gcc.target/i386/avx-vmovapd-256-1.c
===
--- gcc/testsuite/gcc.target/i386/avx-vmovapd-256-1.c (revision 205857)
+++ gcc/testsuite/gcc.target/i386/avx-vmovapd-256-1.c (working copy)
@@ -15,7 +15,7 @@
avx_test (void)
{
union256d u;
- double e [4] __attribute__ ((aligned (8))) = {41124.234,2344.2354,8653.65635,856.43576};
+ double e [4] __attribute__ ((aligned (32))) = {41124.234,2344.2354,8653.65635,856.43576};
u.x = test (e);
Index: gcc/testsuite/gcc.target/i386/avx-vmovapd-256-2.c
===
--- gcc/testsuite/gcc.target/i386/avx-vmovapd-256-2.c (revision 205857)
+++ gcc/testsuite/gcc.target/i386/avx-vmovapd-256-2.c (working copy)
@@ -15,7 +15,7 @@
avx_test (void)
{
union256d u;
- double e [4] __attribute__ ((aligned (8))) = {0.0};
+ double e [4] __attribute__ ((aligned (32))) = {0.0};
u.x = _mm256_set_pd (39578.467285, 7856.342941, 85632.783567, 47563.234215);
Index: gcc/testsuite/gcc.target/i386/sse2-movapd-1.c
===
--- gcc/testsuite/gcc.target/i386/sse2-movapd-1.c (revision 205857)
+++ gcc/testsuite/gcc.target/i386/sse2-movapd-1.c (working copy)
@@ -25,7 +25,7 @@
TEST (void)
{
union128d u;
- double e[2] __attribute__ ((aligned (8))) = {2134.3343,1234.635654};
+ double e[2] __attribute__ ((aligned (16))) = {2134.3343,1234.635654};
u.x = test (e);
Index: gcc/testsuite/gcc.target/i386/sse2-movapd-2.c
===
--- gcc/testsuite/gcc.target/i386/sse2-movapd-2.c (revision 205857)
+++ gcc/testsuite/gcc.target/i386/sse2-movapd-2.c (working copy)
@@ -25,7 +25,7 @@
TEST (void)
{
union128d u;
- double e[2] __attribute__ ((aligned (8))) = {0.0};
+ double e[2] __attribute__ ((aligned (16))) = {0.0};
u.x = _mm_set_pd (2134.3343,1234.635654);
[PATCH, preprocessor] Fix 56896
Fixes missing DIR_SEPARATOR if --with-gxx-include-dir configured as subdir of sysroot. 2013-12-10 Ryan Mansfield rmansfi...@qnx.com PR preprocessor/56896 * incpath.c (add_standard_paths): Strip trailing sysroot DIR_SEPARATOR only if appended path begins with DIR_SEPARATOR. Regards, Ryan Mansfield Index: incpath.c === --- incpath.c (revision 205857) +++ incpath.c (working copy) @@ -179,7 +179,8 @@ char *sysroot_no_trailing_dir_separator = xstrdup (sysroot); size_t sysroot_len = strlen (sysroot); - if (sysroot_len 0 sysroot[sysroot_len - 1] == DIR_SEPARATOR) + if (sysroot_len 0 sysroot[sysroot_len - 1] == DIR_SEPARATOR + p-fname[0] == DIR_SEPARATOR) sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0'; str = concat (sysroot_no_trailing_dir_separator, p-fname, NULL); free (sysroot_no_trailing_dir_separator);
doc: Add -fuse-ld to option index
I noticed there wasn't an entry in the option index for -fuse-ld. If
OK, can someone apply? Thanks.
Regards,
Ryan Mansfield
2013-12-01 Ryan Mansfield rmansfi...@qnx.com
* doc/invoke.texi (-fuse-ld): Add index entry.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 205573)
+++ gcc/doc/invoke.texi (working copy)
@@ -8691,6 +8691,7 @@
Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, @option{-Os}.
@item -fuse-ld=bfd
+@opindex fuse-ld
Use the @command{bfd} linker instead of the default linker.
@item -fuse-ld=gold
Re: C++ PATCH for c++/54277 (wrong cv-quals in lambda)
On 13-03-16 10:40 PM, Jason Merrill wrote:
On 03/16/2013 03:28 PM, Jason Merrill wrote:
I have no idea why the existing code tried to deduce the desired quals
from current_class_ref rather than just look at the object it has.
Well, maybe now I do; when I tested all my changes again before checking
in, this one caused a crash because I had left out another change that
it depends on. Previously we gave the 'this' capture in a lambda a
DECLTYPE_TYPE type since the enclosing class is a dependent type, but
that means that *this has no type at all and so we can't look at its
quals. But that isn't necessary; we know enough about the type of
'this' that it's a pointer to some instantiation of this class template,
so we can give the capture field and proxy that type rather than mess
with DECLTYPE_TYPE. We could limit this change to only POINTER_TYPE,
but we might as well save a bit of memory and only use the DECLTYPE_TYPE
when we really don't know anything about the type being captured;
specifically, when we don't know whether or not it's a reference.
Tested x86_64-pc-linux-gnu, applying to trunk.
Hi Jason,
It seems this change introduced the following segfault building
compatibility-thread-c++0x.cc for an arm eabi target.
ice.ii:48:20: internal compiler error: Segmentation fault
(__args) ...);
^
0xa7b67f crash_signal
../../gcc/toplev.c:332
0x4e98e2 resolve_args
../../gcc/cp/call.c:3739
0x5022d7 build_new_function_call(tree_node*, vectree_node*, va_gc,
vl_embed**, bool, int)
../../gcc/cp/call.c:3849
0x66dc42 finish_call_expr(tree_node*, vectree_node*, va_gc,
vl_embed**, bool, bool, int)
../../gcc/cp/semantics.c:2214
Attached is a reduced testcase. Sorry, for reporting it on gcc-patches
but bugzilla is currently offline.
Regards,
Ryan Mansfield
namespace std __attribute__ ((__visibility__ (default)))
{
template typename _Tp struct remove_reference
{
typedef _Tp type;
};
template typename _Tp constexpr _Tp
forward (typename std::remove_reference _Tp ::type __t) noexcept
{
return static_cast _Tp (__t);
}
template typename _Res, typename _T1,
typename _T2
struct _Reference_wrapper_base _Res (_T1::*) (_T2) const volatile
:binary_function const volatile _T1 *, _T2, _Res
{
};
template typename _Tp class reference_wrapper:public
_Reference_wrapper_base typename remove_cv
_Tp ::type
{
};
template typename _Tp inline reference_wrapper _Tp
ref (_Tp __t) noexcept
{
}
template typename _Signature struct _Bind_simple;
template typename _Func, typename ... _BoundArgs struct
_Bind_simple_helper
{
typedef _Bind_simple __func_type (typename decay
_BoundArgs ::type ...) __type;
};
template typename _Callable,
typename ... _Args typename _Bind_simple_helper _Callable,
_Args ... ::__type __bind_simple (_Callable __callable, _Args
... __args)
{
}
template typename _Signature class function;
struct once_flag
{
};
template typename _Callable,
typename ... _Args void call_once (once_flag __once, _Callable
__f, _Args ... __args)
{
auto __callable = std::__bind_simple (std::forward _Callable (__f),
std::forward _Args
(__args) ...);
__once_functor =[]()
{
__callable ();
};
}
class _State_base
{
once_flag _M_once;
void _M_set_result (function _Ptr_type () __res,
bool __ignore_failure = false)
{
bool __set = __ignore_failure;
call_once (_M_once, _State_base::_M_do_set, this, ref (__res),
ref (__set));
}
private:void _M_do_set (function _Ptr_type () __f, bool __set)
{
}
}
}
Re: Backtrace library [1/3]
On 12-09-17 12:39 PM, Ian Lance Taylor wrote: On Thu, Sep 13, 2012 at 1:00 PM, Diego Novillo dnovi...@google.com wrote: On 2012-09-11 18:53 , Ian Lance Taylor wrote: 2012-09-11 Ian Lance Taylor i...@google.com * Initial implementation. OK. Thanks for all the reviews. I have committed the libbacktrace library to trunk. I will follow up with a patch to actually use it. Please let me know about any build problems. I'm hitting the following build issue /bin/sh ./libtool --tag=CC --mode=compile i686-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c -o backtrace.lo ../../libbacktrace/backtrace.c libtool: compile: i686-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c ../../libbacktrace/backtrace.c -o backtrace.o cc1: warnings being treated as errors ../../libbacktrace/backtrace.c: In function 'unwind': ../../libbacktrace/backtrace.c:69: warning: implicit declaration of function '_Unwind_GetIPInfo' make[3]: *** [backtrace.lo] Error 1 Regards, Ryan Mansfield
Re: Backtrace library [1/3]
On 12-09-19 06:17 PM, Ian Lance Taylor wrote: On Wed, Sep 19, 2012 at 1:56 PM, Ryan Mansfield rmansfi...@qnx.com wrote: I'm hitting the following build issue /bin/sh ./libtool --tag=CC --mode=compile i686-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c -o backtrace.lo ../../libbacktrace/backtrace.c libtool: compile: i686-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c ../../libbacktrace/backtrace.c -o backtrace.o cc1: warnings being treated as errors ../../libbacktrace/backtrace.c: In function 'unwind': ../../libbacktrace/backtrace.c:69: warning: implicit declaration of function '_Unwind_GetIPInfo' make[3]: *** [backtrace.lo] Error 1 Don't omit the details: How precisely did you run configure? In what directory is this error occurring? $ head config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ ../configure --disable-bootstrap --enable-languages=c++ ## - ## ## Platform. ## Please check HAVE_GETIPINFO in libbacktrace/config.h. I assume it is 1. Yep, it's 1. $ grep HAVE_GETIPINFO config.h #define HAVE_GETIPINFO 1 It looks like you may be doing some sort of Canadian Cross build. What version of GCC is i686-unknown-linux-gnu-gcc? Does that version of gcc declare _Unwind_GetIPInfo in its unwind.h? Does it provide _Unwind_GetIPInfo in its libgcc? I'm using gcc 4.1 on this machine. No, it doesn't have it in the unwind.h or libgcc. Regards, Ryan Mansfield
Re: Backtrace library [1/3]
On 12-09-19 06:58 PM, Ian Lance Taylor wrote: Thanks for the additional info. I have committed this patch, which should fix the problem. Bootstrapped and ran libbacktrace tests on x86_64-unknown-linux-gnu. Thanks Ian. This patch fixes the issue. Regards, Ryan Mansfield 2012-09-19 Ian Lance Taylor i...@google.com * configure.ac: Only use GCC_CHECK_UNWIND_GETIPINFO when compiled as a target library. * configure: Rebuild.
Re: Diagnostics from GCC_DRIVER_HOST_INITIALIZATION
On 12-07-27 03:41 AM, Dodji Seketeli wrote: 2012-07-20 Ryan Mansfield rmansfi...@qnx.com * gcc.c (main): Move GCC_DRIVER_HOST_INITIALIZATION after diagnostic_initialize. Could someone please apply the change? The change seems small and obvious enough to not require copyright assignment on file, but, just to be sure, Ryan, do you have copyright assignment to the FSF on file (sorry if my question is stupid)? Yes, I do. Regards, Ryan Mansfield
Re: Commit: ARM: Document -munaligned-access
On 12-07-19 05:33 PM, Hans-Peter Nilsson wrote: Maybe something like: Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.113 diff -p -u -r1.113 changes.html --- changes.html5 Jun 2012 11:03:53 - 1.113 +++ changes.html15 Jun 2012 02:04:46 - @@ -43,6 +43,19 @@ /li +liOn ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, +ARMv7-R, or ARMv7-M, the new option +code-munaligned-access/code is active by default, which for +some source codes generates code that accesses memory on unaligned +adresses. This will require the kernel of those systems to enable adresses - addresses. Regards, Ryan Mansfield
Re: Diagnostics from GCC_DRIVER_HOST_INITIALIZATION
On 12-07-19 06:06 PM, Gabriel Dos Reis wrote:
On Thu, Jul 19, 2012 at 4:13 PM, Ryan Mansfield rmansfi...@qnx.com wrote:
GCC_DRIVER_HOST_INITIALIZATION happens before diagnostic_initialize, this
can cause crashes if it call diagnostics such as warning, or fatal_error are
used in the macro. One example would be in darwin-driver.c where
darwin_find_version_from_kernel can call warning(). Another example is in
xm-djgpp.h where it calls fatal (this appears to have bit-rotted with the
fatal - fatal_error switch)
Would moving the GCC_DRIVER_HOST_INITIALIZATION after diagnostic_initialize
be OK?
yes, I think so.
OK, then here's a changelog entry for the diff.
2012-07-20 Ryan Mansfield rmansfi...@qnx.com
* gcc.c (main): Move GCC_DRIVER_HOST_INITIALIZATION after
diagnostic_initialize.
Could someone please apply the change?
Regards,
Ryan Mansfield
Index: gcc.c
===
--- gcc.c (revision 189716)
+++ gcc.c (working copy)
@@ -6189,17 +6189,18 @@
CL_DRIVER,
decoded_options, decoded_options_count);
-#ifdef GCC_DRIVER_HOST_INITIALIZATION
- /* Perform host dependent initialization when needed. */
- GCC_DRIVER_HOST_INITIALIZATION;
-#endif
-
/* Unlock the stdio streams. */
unlock_std_streams ();
gcc_init_libintl ();
diagnostic_initialize (global_dc, 0);
+
+#ifdef GCC_DRIVER_HOST_INITIALIZATION
+ /* Perform host dependent initialization when needed. */
+ GCC_DRIVER_HOST_INITIALIZATION;
+#endif
+
if (atexit (delete_temp_files) != 0)
fatal_error (atexit failed);
Diagnostics from GCC_DRIVER_HOST_INITIALIZATION
GCC_DRIVER_HOST_INITIALIZATION happens before diagnostic_initialize, this can cause crashes if it call diagnostics such as warning, or fatal_error are used in the macro. One example would be in darwin-driver.c where darwin_find_version_from_kernel can call warning(). Another example is in xm-djgpp.h where it calls fatal (this appears to have bit-rotted with the fatal - fatal_error switch) Would moving the GCC_DRIVER_HOST_INITIALIZATION after diagnostic_initialize be OK? Index: gcc.c === --- gcc.c (revision 189681) +++ gcc.c (working copy) @@ -6189,17 +6189,18 @@ CL_DRIVER, decoded_options, decoded_options_count); -#ifdef GCC_DRIVER_HOST_INITIALIZATION - /* Perform host dependent initialization when needed. */ - GCC_DRIVER_HOST_INITIALIZATION; -#endif - /* Unlock the stdio streams. */ unlock_std_streams (); gcc_init_libintl (); diagnostic_initialize (global_dc, 0); + +#ifdef GCC_DRIVER_HOST_INITIALIZATION + /* Perform host dependent initialization when needed. */ + GCC_DRIVER_HOST_INITIALIZATION; +#endif + if (atexit (delete_temp_files) != 0) fatal_error (atexit failed); Regards, Ryan Mansfield
Fix crash in vect_is_slp_reduction
There is a crash in vect_is_slp_reduction where use_stmt doesn't get initialized in the FOR_EACH_IMM_USE_FAST loop. 1718 FOR_EACH_IMM_USE_FAST (use_p, imm_iter, lhs) (gdb) call debug_tree(lhs) ssa_name 0x76e3a5a0 type integer_type 0x77f8c7e0 int32_t sizes-gimplified public SI size integer_cst 0x77ec47e0 constant 32 unit size integer_cst 0x77ec4580 constant 4 align 32 symtab 0 alias set -1 canonical type 0x77ecb498 precision 32 min integer_cst 0x77ec4780 -2147483648 max integer_cst 0x77ec47a0 2147483647 context translation_unit_decl 0x77f98508 D.1314 pointer_to_this pointer_type 0x77f9f930 var var_decl 0x76e1ce60 g_29_lsm.18def_stmt g_29_lsm.18_137 = PHI g_29_lsm.18_87(15), D.2113_96(18) version 137 (gdb) n 1742 if (found) (gdb) 1746 if (gimple_code (use_stmt) == GIMPLE_PHI) (gdb) Program received signal SIGSEGV, Segmentation fault. 0x00980f22 in gimple_code (g=0x0) at ../../gcc/gimple.h:1098 1098 return g-gsbase.code; Is the following sufficient? Index: tree-vect-loop.c === --- tree-vect-loop.c(revision 173945) +++ tree-vect-loop.c(working copy) @@ -1743,7 +1743,7 @@ break; /* This is a loop exit phi, and we haven't reached the reduction phi. */ - if (gimple_code (use_stmt) == GIMPLE_PHI) + if (!use_stmt || gimple_code (use_stmt) == GIMPLE_PHI) return false; if (!is_gimple_assign (use_stmt) Regards, Ryan Mansfield
Re: Fix crash in vect_is_slp_reduction
On 11-05-20 10:17 AM, Richard Guenther wrote: On Fri, May 20, 2011 at 4:06 PM, Ryan Mansfieldrmansfi...@qnx.com wrote: There is a crash in vect_is_slp_reduction where use_stmt doesn't get initialized in the FOR_EACH_IMM_USE_FAST loop. 1718 FOR_EACH_IMM_USE_FAST (use_p, imm_iter, lhs) (gdb) call debug_tree(lhs) ssa_name 0x76e3a5a0 typeinteger_type 0x77f8c7e0 int32_t sizes-gimplified public SI sizeinteger_cst 0x77ec47e0 constant 32 unit sizeinteger_cst 0x77ec4580 constant 4 align 32 symtab 0 alias set -1 canonical type 0x77ecb498 precision 32 mininteger_cst 0x77ec4780 -2147483648 maxinteger_cst 0x77ec47a0 2147483647 contexttranslation_unit_decl 0x77f98508 D.1314 pointer_to_thispointer_type 0x77f9f930 varvar_decl 0x76e1ce60 g_29_lsm.18def_stmt g_29_lsm.18_137 = PHI g_29_lsm.18_87(15), D.2113_96(18) version 137 (gdb) n 1742 if (found) (gdb) 1746 if (gimple_code (use_stmt) == GIMPLE_PHI) (gdb) Program received signal SIGSEGV, Segmentation fault. 0x00980f22 in gimple_code (g=0x0) at ../../gcc/gimple.h:1098 1098 return g-gsbase.code; Is the following sufficient? No, we shouldn't arrive with a NULL use_stmt here. OK, thanks. I've filed PR49087 with a testcase. Regards, Ryan Mansfield
Re: GCC 4.4.2 Status Report (2009-10-15)
Jakub Jelinek wrote: Status == GCC 4.4.2 release tarballs have been uploaded, the 4.4 branch is again open for commits under the usual release branch rules. I'll announce the release once mirrors had some time to download it. The onlinedocs already point to 4.4.2 but there is a permission issue accessing onlinedocs/gcc-4.4.2/gcc/ (i.e. 403) Regards, Ryan Mansfield
Re: Add my name to Write-after-Approval List
Paolo Bonzini wrote: 4) some might fall under 2 or 3. Actually just one; he used to be at QNX, couldn't find any data after 2005 on qnx.com but I'm CCing him: gp (Graeme Peterson )2003-08-063 Graeme left QNX back in 2006. He removed himself from the MAINTAINERS file: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00513.html Regards, Ryan Mansfield
[lto] Reader-writer compatibility?
Is it required that the same compiler that generated lto objects be used to read them? I've come across a couple ICEs with the current revision reading lto objects created by a slightly older version but same configuration. Is this simply invalid usage of my part? Regards, Ryan Mansfield
Re: [lto] Reader-writer compatibility?
Diego Novillo wrote: On Tue, Sep 1, 2009 at 11:42, Ryan Mansfieldrmansfi...@qnx.com wrote: Is it required that the same compiler that generated lto objects be used to read them? I've come across a couple ICEs with the current revision reading lto objects created by a slightly older version but same configuration. Is this simply invalid usage of my part? It's likely. How much drift between the two revisions? Can you recreate the ICE if you write and read with the exact same revision? If so, please file a bug. The objects were created with rev 15 and being read using 151271. No, I can't reproduce the ICE using the same version. Thanks for confirming this is not expected to work. Regards, Ryan Mansfield
Re: GCC 4.3 target deprecation proposals
Joseph S. Myers wrote: Following my proposal for target architecture deprecations in 4.3 http://gcc.gnu.org/ml/gcc/2008-01/msg00335.html, I now propose the following list of individual targets to deprecate, based on the same methodology previously described. The patch to remove c4x and deprecate the previously discussed target architectures crx, iq2000, mt, stormy16 will be submitted shortly; the patch for the remaining deprecations (only touching config.gcc and the release notes) will be submitted later after any discussion. * i[34567]86-*-nto-qnx* Please do not deprecated this target. We intend to update this target and post test results in the very near future. Regards, Ryan Mansfield
RE: C++, export for templates (was: C++ standard)
Couldn't find anything on it in bugzilla, and I don't think it's worth the effort. IIRC, Herb Sutter and another guy spent 6 months to get it right in the EDG front end (and Herb originally wanted to throw export for templates out of the standard alltogether). -- Tarjei The implementation of export was done by Steve Adamczyk, John Spicer, and Daveed Vandevoorde - also known as Edison Design Group (EDG). Herb Sutter and Tom Plum wrote a committee paper entitled Why We Can't Afford Export [1]. The paper points out that it took EDG 1.5 years of planning and 3 person years to implement export. EDG estimates elapsed time for other implementers approximately 2.5 to 3 years, start to finish. [1] http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf Regards, Ryan Mansfield
RE: C++, export for templates (was: C++ standard)
and that paper was debunked when it was presented at the ISO C++ committee in April 2003 at Oxford, UK. EDG is very willing to give advice (based on their experience) to anyone interested in implementing export in, say GCC. (They want to see the best implementation of export for C++.) -- Gaby Well, my point was that Herb Sutter had just written a paper on it, and it was the EDG guys who had done the implementation. Even though Sutter's paper was debunked, do EDG no longer stand behind their 2.5-3yr estimate? Regards, Ryan Mansfield
RE: What are the differences between 2.95.3 and 3.2.3?
http://gcc.gnu.org/gcc-3.0/features.html http://gcc.gnu.org/gcc-3.0/caveats.html http://gcc.gnu.org/gcc-3.1/changes.html http://gcc.gnu.org/gcc-3.2/changes.html Regards, Ryan Mansfield -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pascal Aschwanden Sent: Wednesday, November 02, 2005 3:44 PM To: [EMAIL PROTECTED] Subject: What are the differences between 2.95.3 and 3.2.3? thanks, Pascal
RE: Complier not giving warning/error in this scenario.. Please h elp..
No, it's not a problem with the compiler. When you remove the function name,
the code is still valid.
For example:
int main() {
int a;
a = (1,2,3,4);
printf(%d\n, a);
}
[EMAIL PROTECTED]:~$ gcc t.c
[EMAIL PROTECTED]:~$ ./a.out
4
See 6.5.17 Comma operator of the C Standard for more information
Regards,
Ryan Mansfield
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Soujanya Gundlapalli
Sent: Wednesday, September 28, 2005 11:06 PM
To: [EMAIL PROTECTED]
Cc: gcc-bugs@gcc.gnu.org
Subject: FW: Complier not giving warning/error in this scenario.. Please
help..
Hello All,
I am trying to compile the file with the following code.
Originally it was:
if ((erc = pk_val(pline, pkt, mp, PKT_CLEAR, PK_LOCAL))
By accident I saved the file with the following code.
if ((erc = (pline, pkt, mp, PKT_CLEAR, PK_LOCAL))
By accident pk_val_call got deleted and when I complied the above code
using the options
cc -c -g, it got compiled successfully. I tried removing -g also. Even
then it gave success. Is this a problem with the compiler? Is there a
fix for this that I can use.
Appreciate your help.
Regards
Soujanya
