Re: [patch, fortran] PR55117 Programs fails to read namelist (contains derived types objects)
Jerry DeLisle wrote: Regression tested on x86-64. Test case attached with patch. OK for trunk? Looks good to me. Thanks for the patch. Tobias 2014-05-24 Tobias Burnus bur...@net-b.de PR fortran/55117 * trans-io.c (nml_full_name, transfer_namelist_element): Insert a '+' rather then '%' to differentiate namelist variable names that are based on extended derived types. 2014-05-24 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/55117 * io/list_read.c (extended_look_ahead): New helper function to scan the namelist name and look for matches with the new '+' extended type parent indicator. (str_comp_extended): New helper function to compare the namelist name with the varname namelist. (find_nml_name): Use the new helper functions to match the extended type varnames.
Re: atomic update of profile counters (issue7000044)
2013-11-19 Rong Xu x...@google.com
* gcc/gcov-io.h: Add atomic function macros for compiler use.
* gcc/common.opt (fprofile-generate-atomic): New option.
* gcc/tree-profile.c (gimple_init_edge_profiler): Support for
atomic counter update.
(gimple_gen_edge_profiler): Ditto.
* libgcc/libgcov-profiler.c
(__gcov_interval_profiler_atomic): Ditto.
(__gcov_pow2_profiler_atomic): Ditto.
(__gcov_one_value_profiler_body_atomic): Ditto.
(__gcov_one_value_profiler_atomic): Ditto.
(__gcov_indirect_call_profiler_atomic): Ditto.
(__gcov_indirect_call_profiler_v2_atomic): Ditto.
(__gcov_time_profiler_atomic): Ditto.
(__gcov_average_profiler_atomic): Ditto.
* gcc/gcc.c: Link libatomic when -fprofile-generate-atomic used.
* libgcc/Makefile.in: Add atomic objects.
Index: gcc/common.opt
===
--- gcc/common.opt(revision 205053)
+++ gcc/common.opt(working copy)
@@ -1684,6 +1684,15 @@ fprofile-correction
Common Report Var(flag_profile_correction)
Enable correction of flow inconsistent profile data input
+; fprofile-generate-atomic=0: default and disable atomical update.
+; fprofile-generate-atomic=1: atomically update edge profile counters.
+; fprofile-generate-atomic=2: atomically update value profile counters.
+; fprofile-generate-atomic=3: atomically update edge and value profile
counters.
+; other values will be ignored (fall back to the default of 0).
+fprofile-generate-atomic=
+Common Joined UInteger Report Var(flag_profile_generate_atomic) Init(3)
Optimization
+fprofile-generate-atomic=[0..3] Atomical increments of profile counters.
Instead magic numbers I would preffer flags, like edge and value
and permiting combinations like -ffprofile-generate-atomic=edge,value
I wonder about the option name, I suppose this option also combine with
-ftest-coverage
(and no longer too useful -fprofile-arcs), so the profile-generate prefix may
be bit
misleading here (giving an impression that it is not useful in this case).
But I can't think of something really better.
Other thing I wonder about is that we may want to implement alternative
solution with
TLS or smaller per-thread buffers and locked updates. It would be bit
difficult to
extend -fprofile-generate-atomic to this...
@@ -155,6 +155,9 @@ gimple_init_edge_profiler (void)
tree ic_profiler_fn_type;
tree average_profiler_fn_type;
tree time_profiler_fn_type;
+ const char *fn_name;
+ bool profile_gen_value_atomic = (flag_profile_generate_atomic == 2 ||
+ flag_profile_generate_atomic == 3);
if (!gcov_type_node)
{
Will this work with optimization attributes?
The rest of patch looks OK, lets settle option name and get it in.
Sorry for dropping the ball for 4.8.
Re: libsanitizer merge from upstream r208536
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, May 26, 2014 at 08:57:11AM +0400, Konstantin Serebryany wrote: Last time I tried, asan did not work on ppc32 for a large number of different reasons. ??? Comparing my 4.9.0 ppc/ppc64 testresults, for 32-bit I see: FAIL: c-c++-common/asan/null-deref-1.c -O0 output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O1 output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O2 output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O3 -fomit-frame-pointer output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O3 -g output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -Os output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/pr59063-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) UNRESOLVED: c-c++-common/asan/pr59063-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects compilation failed to produce executable and for 64-bit: FAIL: c-c++-common/asan/null-deref-1.c -O2 output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O3 -fomit-frame-pointer output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O3 -g output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/null-deref-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test, is ASAN:SIGSEGV FAIL: c-c++-common/asan/pr59063-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) UNRESOLVED: c-c++-common/asan/pr59063-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects compilation failed to produce executable FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -g execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -Os execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test Doesn't look like the ppc32 port would be in any worse shape than the 64-bit one. Peter has brought a real problem, in particular the allocator now newly relying on 2 x word size atomics which is definitely non-portable, I don't see why the answer to that should be disable your port or build a buildbot. Because this is my default reply to any such case. :) Jakub
Re: [PATCH] Fix PR rtl-optimization/61278
On 23 May 2014 19:56, Richard Biener richard.guent...@gmail.com wrote:
On Fri, May 23, 2014 at 12:33 PM, Zhenqiang Chen
zhenqiang.c...@linaro.org wrote:
On 23 May 2014 17:05, Richard Biener richard.guent...@gmail.com wrote:
On Fri, May 23, 2014 at 9:23 AM, Zhenqiang Chen
zhenqiang.c...@linaro.org wrote:
Hi,
The patch fixes PR rtl-optimization/61278. Root cause for issue is
that df_live does not exist at -O1.
Bootstrap and no make check regression on X86-64.
OK for trunk?
Why do you need to give up? It seems you can simply avoid
marking the block as dirty (though df_get_live_in/out also hands you
back DF_LR_IN/OUT if !df_live). So isn't the df_grow_bb_info the
real fix?
The df_get_live_in of the new basic block will be used to analyse
later INSNs. If it is not set or incorrect, it will impact on later
analysis.
df_grow_bb_info is to make sure the live_in data structure is
allocated for the new basic block (although I have not found any case
fail without it). After bitmap_copy(...), we can use it for later
INSNs.
Note that df_get_live_in/out are functions tailored to IRA that
knows that they handle both df_live and df_lr dependent on
optimization level. Is shrink-wrapping supposed to work with
both problems as well?
Yes. But it seams not perfect to handle df_lr problem. When I fixed PR
57637 (https://gcc.gnu.org/ml/gcc-patches/2013-07/msg00897.html), we
selected if DF_LIVE doesn't exist, i.e. at -O1, just give up
searching NEXT_BLOCK.
Ok, I see. Maybe it would be better to completely disable
shrink-wrapping when LIVE is not available.
Agree. There are potential bugs since DF_REF_PARTIAL and
DF_REF_CONDITIONAL defs are not correctly handled in DF_LR.
I will send out a patch to disable prepare_shrink_wrap when DF_LIVE is
not available.
Patch is ok.
Thanks! Committed @210922.
-Zhenqiang
Thanks,
Richard.
Thanks!
-Zhenqiang
ChangeLog:
2014-05-23 Zhenqiang Chen zhenqiang.c...@linaro.org
PR rtl-optimization/61278
* shrink-wrap.c (move_insn_for_shrink_wrap): Check df_live.
testsuite/ChangeLog:
2014-05-23 Zhenqiang Chen zhenqiang.c...@linaro.org
* gcc.dg/lto/pr61278_0.c: New test.
* gcc.dg/lto/pr61278_1.c: New test.
diff --git a/gcc/shrink-wrap.c b/gcc/shrink-wrap.c
index f09cfe7..be17829 100644
--- a/gcc/shrink-wrap.c
+++ b/gcc/shrink-wrap.c
@@ -204,8 +204,15 @@ move_insn_for_shrink_wrap (basic_block bb, rtx insn,
/* Create a new basic block on the edge. */
if (EDGE_COUNT (next_block-preds) == 2)
{
+ /* If DF_LIVE doesn't exist, i.e. at -O1, just give up. */
+ if (!df_live)
+ return false;
+
next_block = split_edge (live_edge);
+ /* We create a new basic block. Call df_grow_bb_info to make sure
+all data structures are allocated. */
+ df_grow_bb_info (df_live);
bitmap_copy (df_get_live_in (next_block), df_get_live_out (bb));
df_set_bb_dirty (next_block);
diff --git a/gcc/testsuite/gcc.dg/lto/pr61278_0.c
b/gcc/testsuite/gcc.dg/lto/pr61278_0.c
new file mode 100644
index 000..03a24ae
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lto/pr61278_0.c
@@ -0,0 +1,30 @@
+/* { dg-lto-do link } */
+/* { dg-lto-options { { -flto -O0 } } } */
+/* { dg-extra-ld-options -flto -O1 } */
+
+static unsigned int
+fn1 (int p1, int p2)
+{
+ return 0;
+}
+
+char a, b, c;
+
+char
+foo (char *p)
+{
+ int i;
+ for (b = 1 ; b 0; b++)
+{
+ for (i = 0; i 2; i++)
+ ;
+ for (a = 1; a 0; a++)
+ {
+ char d[1] = { 0 };
+ if (*p)
+ break;
+ c ^= fn1 (fn1 (fn1 (0, 0), 0), 0);
+ }
+}
+ return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/lto/pr61278_1.c
b/gcc/testsuite/gcc.dg/lto/pr61278_1.c
new file mode 100644
index 000..b02c8ac
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lto/pr61278_1.c
@@ -0,0 +1,13 @@
+/* { dg-lto-do link } */
+/* { dg-lto-options { { -flto -O1 } } } */
+
+extern char foo (char *);
+
+char d;
+
+int
+main ()
+{
+ foo (d);
+ return 0;
+}
Re: libsanitizer merge from upstream r208536
On Fri, May 23, 2014 at 8:45 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, May 23, 2014 at 04:11:48PM +0400, Konstantin Serebryany wrote:
2) it doesn't still deal with unaligned power of two accesses properly,
but neither does llvm (at least not 3.4). Am not talking about
undefined behavior cases where the compiler isn't told the access
is misaligned, but e.g. when accessing struct S { int x; }
__attribute__((packed)) and similar (or aligned(1)). Supposedly
we could force __asan_report_*_n for that case too, because
normal wider check assumes it is aligned
Yep, we don't do it.
Now we do: http://llvm.org/viewvc/llvm-project?rev=209508view=rev
Here is the GCC side of the thing, ok for trunk if it bootstraps/regtests?
(on top of the earlier posted two patches).
Note, I think some work is needed on the library side,
ERROR: AddressSanitizer: unknown-crash on address 0xffc439cf at pc 0x804898e
bp 0xffc438d8 sp 0xffc438cc
With clang I get this nice report:
==20989==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffdf02 at pc 0x4b20db bp 0x7fffdd70 sp 0x7fffdd68
READ of size 4 at 0x7fffdf02 thread T0
#0 0x4b20da in foo(S*) /home/kcc/tmp/jakub-unaligned.c:6
#1 0x4b2744 in main /home/kcc/tmp/jakub-unaligned.c:30
#2 0x76bfd76c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
#3 0x4b1e6c in _start (/usr/local/google/kcc/llvm_cmake/a.out+0x4b1e6c)
Address 0x7fffdf02 is located in stack of thread T0 at offset 66 in frame
#0 0x4b24ef in main /home/kcc/tmp/jakub-unaligned.c:23
This frame has 5 object(s):
[32, 36) 'retval'
[48, 64) 't' == Memory access at offset 66 overflows this variable
[80, 84) 'v'
[96, 104) 'p'
[128, 132) 'w'
HINT: this may be a false positive if your program uses some custom
stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/home/kcc/tmp/jakub-unaligned.c:6 foo(S*)
Shadow bytes around the buggy address:
0x10007fff7b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7bb0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x10007fff7bc0: 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7bd0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 00 00
=0x10007fff7be0:[f2]f2 04 f2 00 f2 f2 f2 04 f3 f3 f3 00 00 00 00
0x10007fff7bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7c10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
READ of size 4 at 0xffc439cf thread T0
#0 0x804898d in foo
/usr/src/gcc/gcc/testsuite/c-c++-common/asan/misalign-1.c:10
#1 0x8048746 in main
/usr/src/gcc/gcc/testsuite/c-c++-common/asan/misalign-1.c:34
#2 0x49e39b72 in __libc_start_main (/lib/libc.so.6+0x49e39b72)
#3 0x8048848
(/usr/src/gcc/obj2/gcc/testsuite/gcc/misalign-1.exe+0x8048848)
Address 0xffc439cf is located in stack of thread T0 at offset 175 in frame
#0 0x804868f in main
/usr/src/gcc/gcc/testsuite/c-c++-common/asan/misalign-1.c:27
This frame has 3 object(s):
[32, 36) 'v'
[96, 100) 'w'
[160, 176) 't' == Memory access at offset 175 partially overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: unknown-crash
/usr/src/gcc/gcc/testsuite/c-c++-common/asan/misalign-1.c:10 foo
Shadow bytes around the buggy address:
0x3ff886e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3ff886f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3ff88700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3ff88710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3ff88720: 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2
=0x3ff88730: 04 f4 f4 f4 f2 f2 f2 f2 00[00]f4 f4 f3 f3 f3 f3
0x3ff88740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3ff88750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3ff88760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3ff88770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3ff88780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
ASan
[RFC] Add patch for debugging compiler ICEs
Hi,
A years ago there was a discussion (
https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about
debugging compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for some reasons this patch
wasn't applied to trunk.
Is this still considered a useful feature for 4.10? If yes, we can
resurrect and submit this patch.
-Maxim
# DP: Retry the build on an ice, save the calling options and preprocessed
# DP: source when the ice is reproducible.
2004-01-23 Jakub Jelinek ja...@redhat.com
* gcc.c (execute): Don't free first string early, but at the end
of the function. Call retry_ice if compiler exited with
ICE_EXIT_CODE.
(retry_ice): New function.
* diagnostic.c (diagnostic_count_diagnostic,
diagnostic_action_after_output, error_recursion): Exit with
ICE_EXIT_CODE instead of FATAL_EXIT_CODE.
#--- a/src/gcc/Makefile.in
#+++ b/src/gcc/Makefile.in
#@@ -181,6 +181,8 @@ SYSCALLS.c.X-warn = -Wno-strict-prototypes -Wno-error
# dfp.o-warn = -Wno-error
# # mips-tfile.c contains -Wcast-qual warnings.
# mips-tfile.o-warn = -Wno-error
#+# gcc-ice-hack
#+gcc.o-warn = -Wno-error
#
# # All warnings have to be shut off in stage1 if the compiler used then
# # isn't gcc; configure determines that. WARN_CFLAGS will be either
--- a/src/gcc/gcc.c
+++ b/src/gcc/gcc.c
@@ -250,6 +250,9 @@
#if defined(HAVE_TARGET_OBJECT_SUFFIX) || defined(HAVE_TARGET_EXECUTABLE_SUFFIX)
static const char *convert_filename (const char *, int, int);
#endif
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+static void retry_ice (const char *prog, const char **argv);
+#endif
static const char *getenv_spec_function (int, const char **);
static const char *if_exists_spec_function (int, const char **);
@@ -2638,7 +2643,7 @@
}
}
- if (string != commands[i].prog)
+ if (i string != commands[i].prog)
free (CONST_CAST (char *, string));
}
@@ -2691,6 +2696,16 @@
else if (WIFEXITED (status)
WEXITSTATUS (status) = MIN_FATAL_STATUS)
{
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+ /* For ICEs in cc1, cc1obj, cc1plus see if it is
+ reproducible or not. */
+ const char *p;
+ if (WEXITSTATUS (status) == ICE_EXIT_CODE
+ i == 0
+ (p = strrchr (commands[0].argv[0], DIR_SEPARATOR))
+ ! strncmp (p + 1, cc1, 3))
+ retry_ice (commands[0].prog, commands[0].argv);
+#endif
if (WEXITSTATUS (status) greatest_status)
greatest_status = WEXITSTATUS (status);
ret_code = -1;
@@ -2748,6 +2763,9 @@
}
}
+if (commands[0].argv[0] != commands[0].prog)
+ free (CONST_CAST (char *, commands[0].argv[0]));
+
return ret_code;
}
}
@@ -5874,6 +5892,227 @@
switches[switchnum].validated = 1;
}
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+#define RETRY_ICE_ATTEMPTS 2
+
+static void
+retry_ice (const char *prog, const char **argv)
+{
+ int nargs, out_arg = -1, quiet = 0, attempt;
+ int pid, retries, sleep_interval;
+ const char **new_argv;
+ char *temp_filenames[RETRY_ICE_ATTEMPTS * 2 + 2];
+
+ if (gcc_input_filename == NULL || ! strcmp (gcc_input_filename, -))
+return;
+
+ for (nargs = 0; argv[nargs] != NULL; ++nargs)
+/* Only retry compiler ICEs, not preprocessor ones. */
+if (! strcmp (argv[nargs], -E))
+ return;
+else if (argv[nargs][0] == '-' argv[nargs][1] == 'o')
+ {
+ if (out_arg == -1)
+ out_arg = nargs;
+ else
+ return;
+ }
+/* If the compiler is going to output any time information,
+ it might varry between invocations. */
+else if (! strcmp (argv[nargs], -quiet))
+ quiet = 1;
+else if (! strcmp (argv[nargs], -ftime-report))
+ return;
+
+ if (out_arg == -1 || !quiet)
+return;
+
+ memset (temp_filenames, '\0', sizeof (temp_filenames));
+ new_argv = XALLOCAVEC (const char *, nargs + 3);
+ memcpy (new_argv, argv, (nargs + 1) * sizeof (const char *));
+ new_argv[nargs++] = -frandom-seed=0;
+ new_argv[nargs] = NULL;
+ if (new_argv[out_arg][2] == '\0')
+new_argv[out_arg + 1] = -;
+ else
+new_argv[out_arg] = -o-;
+
+ for (attempt = 0; attempt RETRY_ICE_ATTEMPTS + 1; ++attempt)
+{
+ int fd = -1;
+ int status;
+
+ temp_filenames[attempt * 2] = make_temp_file (.out);
+ temp_filenames[attempt * 2 + 1] = make_temp_file (.err);
+
+ if (attempt == RETRY_ICE_ATTEMPTS)
+{
+ int i;
+ int fd1, fd2;
+ struct stat st1, st2;
+ size_t n, len;
+ char *buf;
+
+ buf = XNEWVEC (char, 8192);
+
+ for (i = 0; i 2; ++i)
+ {
+ fd1 = open (temp_filenames[i], O_RDONLY);
+ fd2 = open (temp_filenames[2 + i], O_RDONLY);
+
+ if (fd1 0 || fd2 0)
+ {
+ i = -1;
+ close (fd1);
+ close (fd2);
+ break;
+ }
+
+ if (fstat (fd1, st1) 0 || fstat (fd2, st2) 0)
+ {
+ i = -1;
+ close (fd1);
+ close (fd2);
+ break;
+ }
+
+ if (st1.st_size != st2.st_size)
+ {
+ close
Re: [RFC][ARM] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook
Ping^2 ? Thanks, Kugan On 12/05/14 09:47, Kugan wrote: Ping ? Thanks, Kugan On 02/05/14 19:04, Kugan wrote: On 02/05/14 10:15, Joseph S. Myers wrote: It doesn't seem a good idea to me for a host-side GCC file to use the FE_* names for the target's FE_* values; you'd run into problems if that file ever ends up including the host's fenv.h, directly or indirectly, on any host. The same comment applies to the AArch64 patch as well. Instead I suggest names such as ARM_FE_* that won't conflict with the host's system headers. Thanks for spotting it. Here is the updated patch that changes it to ARM_FE_*. Thanks, Kugan gcc/ +2014-05-02 Kugan Vivekanandarajah kug...@linaro.org + +* config/arm/arm.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New define. +(arm_builtins) : Add ARM_BUILTIN_GET_FPSCR and ARM_BUILTIN_SET_FPSCR. +(bdesc_2arg) : Add description for builtins __builtins_arm_set_fpscr +and __builtins_arm_get_fpscr. +(arm_init_builtins) : Initialize builtins __builtins_arm_set_fpscr and +__builtins_arm_get_fpscr. +(arm_expand_builtin) : Expand builtins __builtins_arm_set_fpscr and +__builtins_arm_ldfpscr. +(arm_atomic_assign_expand_fenv): New function. +* config/arm/vfp.md (set_fpscr): New pattern. +(get_fpscr) : Likewise. +* config/arm/unspecs.md (unspecv): Add VUNSPEC_GET_FPSCR and +VUNSPEC_SET_FPSCR. +* doc/extend.texi (AARCH64 Built-in Functions) : Document +__builtins_arm_set_fpscr, __builtins_arm_get_fpscr. +
Re: [PATCH] PR 61249: fix documentation of __builtin_ia32_{vfrczss,vfrczsd,mpsadbw256}
Hello! 2014-05-26 Michael Tautschnig m...@debian.org PR target/61249 * doc/extend.texi: Fix parameter lists of __builtin_ia32_vfrczs[sd], __builtin_ia32_mpsadbw256. Thanks, I have committed the patch with slightly changed ChangeLog to all branches. Uros.
Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
.././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ()); ~~~^ This is PR 61146. You can get around it by adding -fheinous-gnu-extensions to BOOT_CFLAGS. This causes GCC bootstrap to fail on Darwin systems (whose system compiler is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s the right call, see below), I’ve filed a separate report for the bootstrap issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315). Regarding PR 61146, I agree with Marc Glisse (comment #3) that the casts in question look weird and should probably be removed, as was done in GMP. This code should be cleaned up, and it will fix bootstrap on clang-based target coincidentally, without adding another kludge. FX
Re: libsanitizer merge from upstream r208536
On Mon, May 26, 2014 at 11:29:28AM +0400, Konstantin Serebryany wrote: Note, I think some work is needed on the library side, ERROR: AddressSanitizer: unknown-crash on address 0xffc439cf at pc 0x804898e bp 0xffc438d8 sp 0xffc438cc With clang I get this nice report: ==20989==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffdf02 at pc 0x4b20db bp 0x7fffdd70 sp 0x7fffdd68 READ of size 4 at 0x7fffdf02 thread T0 #0 0x4b20da in foo(S*) /home/kcc/tmp/jakub-unaligned.c:6 #1 0x4b2744 in main /home/kcc/tmp/jakub-unaligned.c:30 #2 0x76bfd76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226 #3 0x4b1e6c in _start (/usr/local/google/kcc/llvm_cmake/a.out+0x4b1e6c) Address 0x7fffdf02 is located in stack of thread T0 at offset 66 in frame #0 0x4b24ef in main /home/kcc/tmp/jakub-unaligned.c:23 So you are passing two different base-addr values to the __asan_report_load_n ? If yes, that doesn't sound like a good idea to me, because it will almost always generate larger code, plus the diagnostic is incorrect, there is no 4 byte read at address 0x7fffdf02, there is a 4 byte read at address 0x7fffdeff, where 1 byte read at at 0x7fffdeff has been checked and found valid, and one byte read at 0x7fffdf02 has been checked and found invalid. So in that case IMNSHO you need to fix both asan library and llvm. Jakub
Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags
r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10. ../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope libgfortran/configure defines HAVE_STRNLEN on targets supporting it. The same revision also breaks the test g++.dg/tls/diag-1.C /opt/gcc/work/gcc/testsuite/g++.dg/tls/diag-1.C:31:1: internal compiler error: in symtab_get_node, at cgraph.h:1021 TIA, Dominique
Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr wrote: r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10. ../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope strnlen should be declared in include/libiberty.h if there is no declaration as libiberty support is already there. That should be a simple fix. Thanks, Andrew Pinski libgfortran/configure defines HAVE_STRNLEN on targets supporting it. The same revision also breaks the test g++.dg/tls/diag-1.C /opt/gcc/work/gcc/testsuite/g++.dg/tls/diag-1.C:31:1: internal compiler error: in symtab_get_node, at cgraph.h:1021 TIA, Dominique
Re: libsanitizer merge from upstream r208536
Agree. I was going to change instrumentation of unaligned and unusual-sized accesses to simple callbacks. 004b1f30 _Z3fooP1S: 4b1f30: 53 push %rbx 4b1f31: 48 89 fbmov%rdi,%rbx 4b1f34: be 04 00 00 00 mov$0x4,%esi 4b1f39: e8 62 9d fe ff callq 49bca0 __asan_loadN 4b1f3e: 8b 03 mov(%rbx),%eax 4b1f40: 5b pop%rbx 4b1f41: c3 retq This is implemented in llvm, just need a flag flip. It also needs a performance improvement in the run-time. This is in my TODO, just didn't have time. clang++ -g -O2 -fsanitize=address ~/tmp/jakub-unaligned.c -mllvm -asan-instrumentation-with-call-threshold=0 ./a.out ==6925==ERROR: AddressSanitizer: unknown-crash on address 0x7fff9968a1af at pc 0x4b1f3e bp 0x7fff9968a160 sp 0x7fff9968a148 READ of size 4 at 0x7fff9968a1af thread T0 #0 0x4b1f3d in foo(S*) /home/kcc/tmp/jakub-unaligned.c:6 #1 0x4b205a in main /home/kcc/tmp/jakub-unaligned.c:30 #2 0x7fec5540f76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226 #3 0x4b1e6c in _start (/usr/local/google/kcc/llvm_cmake/a.out+0x4b1e6c) Address 0x7fff9968a1af is located in stack of thread T0 at offset 47 in frame #0 0x4b1f8f in main /home/kcc/tmp/jakub-unaligned.c:23 This frame has 4 object(s): [32, 48) 't' == Memory access at offset 47 partially overflows this variable [64, 68) 'v' [80, 88) 'p' [112, 116) 'w' Apparently, this unknown-crash needs to be fixed. Give me some time (may not have it this week though). --kcc On Mon, May 26, 2014 at 12:57 PM, Jakub Jelinek ja...@redhat.com wrote: On Mon, May 26, 2014 at 11:29:28AM +0400, Konstantin Serebryany wrote: Note, I think some work is needed on the library side, ERROR: AddressSanitizer: unknown-crash on address 0xffc439cf at pc 0x804898e bp 0xffc438d8 sp 0xffc438cc With clang I get this nice report: ==20989==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffdf02 at pc 0x4b20db bp 0x7fffdd70 sp 0x7fffdd68 READ of size 4 at 0x7fffdf02 thread T0 #0 0x4b20da in foo(S*) /home/kcc/tmp/jakub-unaligned.c:6 #1 0x4b2744 in main /home/kcc/tmp/jakub-unaligned.c:30 #2 0x76bfd76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226 #3 0x4b1e6c in _start (/usr/local/google/kcc/llvm_cmake/a.out+0x4b1e6c) Address 0x7fffdf02 is located in stack of thread T0 at offset 66 in frame #0 0x4b24ef in main /home/kcc/tmp/jakub-unaligned.c:23 So you are passing two different base-addr values to the __asan_report_load_n ? If yes, that doesn't sound like a good idea to me, because it will almost always generate larger code, plus the diagnostic is incorrect, there is no 4 byte read at address 0x7fffdf02, there is a 4 byte read at address 0x7fffdeff, where 1 byte read at at 0x7fffdeff has been checked and found valid, and one byte read at 0x7fffdf02 has been checked and found invalid. So in that case IMNSHO you need to fix both asan library and llvm. Jakub
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
This causes GCC bootstrap to fail on Darwin systems (whose system compiler is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s the right call, see below), I’ve filed a separate report for the bootstrap issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315). Since my PR has been closed twice by Andrew Pinski (“it’s clang’s fault, bouh ouh”), I’d ask the maintainers to step in. Can we please provide a GCC that works for the default darwin setup? Or at least drop darwin as secondary target and document the failure? FX
Re: Fix broken graph dump
On Sat, May 24, 2014 at 6:44 AM, Xinliang David Li davi...@google.com wrote: graph dump is broken in trunk (and gcc-49) -- the subgraph of the last function gets dumped. The patch fixed the problem. Also fixed the function header dump -- the cgraph uid is still used in many places such as -fdisable|enable-xxx options. Ok for trunk? Ok if tested ok. Thanks, Richard. David
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
On Mon, May 26, 2014 at 2:22 AM, FX fxcoud...@gmail.com wrote: This causes GCC bootstrap to fail on Darwin systems (whose system compiler is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s the right call, see below), I’ve filed a separate report for the bootstrap issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315). Since my PR has been closed twice by Andrew Pinski (“it’s clang’s fault, bouh ouh”), I’d ask the maintainers to step in. Can we please provide a GCC that works for the default darwin setup? Or at least drop darwin as secondary target and document the failure? The failure is again a bug in clang compiler of defining __GNUC__ when they don't fully support GNU C if they want to say it is not a bug to define __GNUC__ I give up. This is just like the bug a while back where ICC did the same thing. We need to shame compiler developers to stop saying they support GNU C without really supporting it. Work arounds for broken commercial compilers is something which we tried back in the 90s; We really should not still be keeping around any work around for them either. Thanks, Andrew PInski FX
Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags
On my side, I can see that r210901 breaks AArch64 compiler build: gcc/config/aarch64/aarch64.c: In function ‘void aarch64_elf_asm_named_section(const char*, unsigned int, tree_node*)’: gcc/config/aarch64/aarch64.c:8136: error: ‘decl_comdat_group’ was not declared in this scope Christophe. On 26 May 2014 11:16, Andrew Pinski pins...@gmail.com wrote: On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr wrote: r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10. ../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope strnlen should be declared in include/libiberty.h if there is no declaration as libiberty support is already there. That should be a simple fix. Thanks, Andrew Pinski libgfortran/configure defines HAVE_STRNLEN on targets supporting it. The same revision also breaks the test g++.dg/tls/diag-1.C /opt/gcc/work/gcc/testsuite/g++.dg/tls/diag-1.C:31:1: internal compiler error: in symtab_get_node, at cgraph.h:1021 TIA, Dominique
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
On Mon, May 26, 2014 at 10:14 AM, FX fxcoud...@gmail.com wrote: .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ()); ~~~^ This is PR 61146. You can get around it by adding -fheinous-gnu-extensions to BOOT_CFLAGS. This causes GCC bootstrap to fail on Darwin systems (whose system compiler is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s the right call, see below), I’ve filed a separate report for the bootstrap issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315). Regarding PR 61146, I agree with Marc Glisse (comment #3) that the casts in question look weird and should probably be removed, as was done in GMP. This code should be cleaned up, and it will fix bootstrap on clang-based target coincidentally, without adding another kludge. Please post a patch. Thanks, Richard. FX
Re: libsanitizer merge from upstream r208536
On 05/26/2014 01:19 PM, Konstantin Serebryany wrote: This is implemented in llvm, just need a flag flip. It also needs a performance improvement in the run-time. This is in my TODO, just didn't have time. FYI I have a patch that adds -asan-instrumentation-with-call-threshold for GCC (will send in couple of days). -Y
Re: [PATCH, libgfortran] PR 61310 CTIME intrinsic output incorrect on MinGW
On Mon, May 26, 2014 at 1:25 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 26, 2014 at 12:21:21AM +0300, Janne Blomqvist wrote: Hi, GFortran currently uses strftime(...,%c,...) to produce the result for the CTIME and FDATE intrinsics. Unfortunately, it seems that on MinGW this does not produce identical output to the C stdlib ctime(), even in the default locale. The attached patch implements an alternative approach, originally suggested by Jakub in PR 47802, to produce a thread-safe ctime-like function by using snprintf manually. Regtested on x86_64-unknown-linux-gnu, Ok for trunk/4.9/4.8/4.7? Patch looks ok to me. +/* Maximum space a ctime-like string might need. A normal ctime + string is 26 bytes, but the maximum possible year number is + 2,147,485,547 (2,147,483,647 + 1900, since tm_year is a 32-bit + signed integer) so an extra 6 bytes are needed. */ +#define CSZ 32 Is there a better name than CSZ, which is not exactly too descriptive? Hmm, what about CTIME_BUFSZ? Ok with that change? -- Janne Blomqvist
Re: Breakage with [PATCH, libgfortran] PR60324 Handle arbitrarily long path names
On Fri, May 23, 2014 at 5:23 AM, Hans-Peter Nilsson h...@bitrange.com wrote: I'm not defending the existing solution, I was observing your patch breaking it. The obvious fix is adjustments by means of this existing machinery; done. I suggest breakages be fixed without shooting messengers or requiring jumping through even stupider hoops in order to fix an obvious immediate breakage. If you take issue with that machinery, that's a separate issue which shouldn't be holding up fixing a breakage. Sorry, I didn't mean to imply that any of this is your fault, on the contrary I'm happy to have prompt reports from targets I don't use myself. Thanks for fixing it! -- Janne Blomqvist
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
On Mon, May 26, 2014 at 1:14 AM, FX fxcoud...@gmail.com wrote: .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ()); ~~~^ This is PR 61146. You can get around it by adding -fheinous-gnu-extensions to BOOT_CFLAGS. This causes GCC bootstrap to fail on Darwin systems (whose system compiler is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s the right call, see below), I’ve filed a separate report for the bootstrap issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315). Regarding PR 61146, I agree with Marc Glisse (comment #3) that the casts in question look weird and should probably be removed, as was done in GMP. This code should be cleaned up, and it will fix bootstrap on clang-based target coincidentally, without adding another kludge. I think that posting a patch is probably the best bet. Then the various merits of the patch to clean up the code can be argued. As far as some sort of workaround, I'd suggest seeing if there's something else that can be done first. Thanks. -eric
[RFC] optimize x - y cmp 0 with undefined overflow
Hi,
the motivation of this work is to get rid of the range check on Z in:
function F (X : Integer; Y : Integer ) return Positive is
Z : Integer;
begin
if X = Y then
return 1;
end if;
Z := Y - X;
return Z;
end;
An equivalent C testcase is:
extern void abort (void);
int foo (int x, int y)
{
int z;
if (x = y)
return 1;
z = y - x;
if (z = 0)
abort ();
return z;
}
for which the call to abort is not optimized at -O2.
fold_comparison knows how to optimize X +- C1 CMP C2 to X CMP C2 -+ C1 with
undefined overflow so optimizing X - Y CMP 0 to X CMP Y is a generalization.
Once this is done, forwprop will immediately optimize:
extern void abort (void);
int foo (int x, int y)
{
int z;
if (x = y)
return 1;
z = y - x;
if (z = 0)
abort ();
return 0;
}
because 'z' has a single use, but the original testcase won't be optimized.
The attached patch implements the missing bits in vrp_evaluate_conditional by
manual propagating the operands of a defining PLUS_EXPR or MINUS_EXPR for an
SSA name in a condition; an other possibility could be DOM instead of VRP.
This comes with 4 testcases: the original Ada testcase, the C equivalent, a
testcase for the folding and another one for the -Wstrict-overflow warning.
Tested on x86_64-suse-linux with no regressions.
2014-05-26 Eric Botcazou ebotca...@adacore.com
* fold-const.c (fold_comparison): Clean up and simplify X +- C1 CMP C2
to X CMP C2 -+ C1 transformation, add X - Y CMP 0 to X CMP Y.
* tree-vrp.c (vrp_evaluate_conditional_warnv_with_fold): New function.
(vrp_evaluate_conditional): Call it on SSA names with defining PLUS_EXPR
or MINUS_EXPR if the evaluation of the condition yielded nothing.
2014-05-26 Eric Botcazou ebotca...@adacore.com
* gcc.dg/fold-compare-8.c: New test.
* gcc.dg/Wstrict-overflow-25.c: Likewise.
* gcc.dg/tree-ssa/vrp92.c: Likewise.
* gnat.dg/opt38.adb: Likewise.
--
Eric BotcazouIndex: fold-const.c
===
--- fold-const.c (revision 210911)
+++ fold-const.c (working copy)
@@ -8920,28 +8920,25 @@ fold_comparison (location_t loc, enum tr
if (tree_swap_operands_p (arg0, arg1, true))
return fold_build2_loc (loc, swap_tree_comparison (code), type, op1, op0);
- /* Transform comparisons of the form X +- C1 CMP C2 to X CMP C2 +- C1. */
+ /* Transform comparisons of the form X +- C1 CMP C2 to X CMP C2 -+ C1. */
if ((TREE_CODE (arg0) == PLUS_EXPR || TREE_CODE (arg0) == MINUS_EXPR)
- (TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST
- !TREE_OVERFLOW (TREE_OPERAND (arg0, 1))
- TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg1)))
- (TREE_CODE (arg1) == INTEGER_CST
- !TREE_OVERFLOW (arg1)))
+ TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg1))
+ TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST
+ !TREE_OVERFLOW (TREE_OPERAND (arg0, 1))
+ TREE_CODE (arg1) == INTEGER_CST
+ !TREE_OVERFLOW (arg1))
{
+ const enum tree_code
+ reverse_op = TREE_CODE (arg0) == PLUS_EXPR ? MINUS_EXPR : PLUS_EXPR;
tree const1 = TREE_OPERAND (arg0, 1);
tree const2 = arg1;
tree variable = TREE_OPERAND (arg0, 0);
- tree lhs;
- int lhs_add;
- lhs_add = TREE_CODE (arg0) != PLUS_EXPR;
-
- lhs = fold_build2_loc (loc, lhs_add ? PLUS_EXPR : MINUS_EXPR,
- TREE_TYPE (arg1), const2, const1);
+ tree new_const
+ = fold_build2_loc (loc, reverse_op, TREE_TYPE (arg1), const2, const1);
/* If the constant operation overflowed this can be
simplified as a comparison against INT_MAX/INT_MIN. */
- if (TREE_CODE (lhs) == INTEGER_CST
- TREE_OVERFLOW (lhs))
+ if (TREE_OVERFLOW (new_const))
{
int const1_sgn = tree_int_cst_sgn (const1);
enum tree_code code2 = code;
@@ -8961,29 +8958,48 @@ fold_comparison (location_t loc, enum tr
/* We now can look at the canonicalized case
VARIABLE + 1 CODE2 INT_MIN
and decide on the result. */
- if (code2 == LT_EXPR
- || code2 == LE_EXPR
- || code2 == EQ_EXPR)
- return omit_one_operand_loc (loc, type, boolean_false_node, variable);
- else if (code2 == NE_EXPR
- || code2 == GE_EXPR
- || code2 == GT_EXPR)
- return omit_one_operand_loc (loc, type, boolean_true_node, variable);
+ switch (code2)
+ {
+ case EQ_EXPR:
+ case LT_EXPR:
+ case LE_EXPR:
+ return
+ omit_one_operand_loc (loc, type, boolean_false_node, variable);
+
+ case NE_EXPR:
+ case GE_EXPR:
+ case GT_EXPR:
+ return
+ omit_one_operand_loc (loc, type, boolean_true_node, variable);
+
+ default:
+ gcc_unreachable ();
+ }
}
-
- if (TREE_CODE (lhs) == TREE_CODE (arg1)
- (TREE_CODE (lhs) != INTEGER_CST
- || !TREE_OVERFLOW (lhs)))
+ else
{
if (code != EQ_EXPR code != NE_EXPR)
fold_overflow_warning (assuming signed overflow does not
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
Please post a patch. How about that? I’m not doing a full clean-up of the longlong.h code outside the area affected. This restores bootstrap on darwin, confirming that both the system compiler and later-stage-gcc accepts it. FX longlong.diff Description: Binary data longlong.ChangeLog Description: Binary data
Re: libsanitizer merge from upstream r208536
On 23 May 2014 17:01, Evgeniy Stepanov eugeni.stepa...@gmail.com wrote:
Hi Christophe,
is there anything special about your setup? We've seen it build on
arm/linux and arm/android correctly.
Hi,
As Kugan said, I needed to add --enable-obsolete-rpc when configuring glibc.
Thanks,
Christophe.
On Fri, May 23, 2014 at 6:06 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
Hi,
Since merge from upstream r209283 (210743 in GCC), my build fails on
ARM, because rpc/xdr.h is not found.
Is this expected?
Thanks,
Christophe.
On 23 May 2014 15:45, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Fri, May 23, 2014 at 5:41 PM, Marek Polacek pola...@redhat.com wrote:
On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote:
5 months' worth of changes may break any platform we are not testing
ourselves
(that includes Ubuntu 12.04, 13.10, 14.04, Mac 10.9, Windows 7, Android
ARM),
please help us test this patch on your favorite platform.
On powerpc64 I hit
/home/polacek/gcc/libsanitizer/asan/asan_linux.cc:209:3: error: #error
Unsupported arch
# error Unsupported arch
because the merge (aka clang's r196802) removed ppc64 hunk of code:
-# elif defined(__powerpc__) || defined(__powerpc64__)
- ucontext_t *ucontext = (ucontext_t*)context;
- *pc = ucontext-uc_mcontext.regs-nip;
- *sp = ucontext-uc_mcontext.regs-gpr[PT_R1];
- // The powerpc{,64}-linux ABIs do not specify r31 as the frame
- // pointer, but GCC always uses r31 when we need a frame pointer.
- *bp = ucontext-uc_mcontext.regs-gpr[PT_R31];
-# elif defined(__sparc__)
Someone will have to send this patch via llvm-commits :(
(I've pinged Peter Bergner once with no luck).
Marek
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
On Mon, May 26, 2014 at 12:32:15PM +0200, FX wrote: Please post a patch. How about that? I’m not doing a full clean-up of the longlong.h code outside the area affected. This restores bootstrap on darwin, confirming that both the system compiler and later-stage-gcc accepts it. grep '=.*\(U[SD]Itype\|unsigned int\)' longlong.h | wc -l 98 So changing just 2 of them doesn't feel right to me... Jakub
[PATCH][4/4] Always 64bit-HWI cleanups
This is the last cleanup bit. Remaining is getting rid of HOST_WIDE_INT in favor of [u]int64_t and adjusting interfaces and interface names. That's too disruptive at the moment (thus appropriate for a delay until 4.9.1 is out) and I'm not sure if we want to split that work or if such splitting is even possible sensibly. For example wide-int should get its own abstraction of its storage type (which could be simply [u]int64_t - the actual compute routines can happily split a [u]int64_t into two pieces again if that is desirable on some architectures - I suspect GCC is good enough in optimizing the two element case inline for them). This moves the relatively new HALF_WIDE_INT stuff to its only user, wide-int.cc, and uses the PRI*64 stuff in the HOST_WIDE_INT_PRINT macros. Bootstrap / testing in progress on x86_64-unknown-linux-gnu. Richard. 2014-05-26 Richard Biener rguent...@suse.de * hwint.h (*_HALF_WIDE_INT*): Move to ... * wide-int.cc (HOST_BITS_PER_HALF_WIDE_INT, HOST_HALF_WIDE_INT): ... here and remove the rest. * hwint.h (HOST_WIDE_INT_PRINT_*): Define in terms of PRI*64. Index: gcc/hwint.h === *** gcc/hwint.h.orig2014-05-26 10:49:23.009339524 +0200 --- gcc/hwint.h 2014-05-26 11:09:43.597255488 +0200 *** extern char sizeof_long_long_must_be_8[s *** 64,103 # endif #endif - /* Print support for half a host wide int. */ - #define HOST_BITS_PER_HALF_WIDE_INT 32 - #if HOST_BITS_PER_HALF_WIDE_INT == HOST_BITS_PER_LONG - # define HOST_HALF_WIDE_INT long - # define HOST_HALF_WIDE_INT_PRINT HOST_LONG_FORMAT - # define HOST_HALF_WIDE_INT_PRINT_C L - # define HOST_HALF_WIDE_INT_PRINT_DEC % HOST_HALF_WIDE_INT_PRINT d - # define HOST_HALF_WIDE_INT_PRINT_DEC_C HOST_HALF_WIDE_INT_PRINT_DEC HOST_HALF_WIDE_INT_PRINT_C - # define HOST_HALF_WIDE_INT_PRINT_UNSIGNED % HOST_HALF_WIDE_INT_PRINT u - # define HOST_HALF_WIDE_INT_PRINT_HEX %# HOST_HALF_WIDE_INT_PRINT x - # define HOST_HALF_WIDE_INT_PRINT_HEX_PURE % HOST_HALF_WIDE_INT_PRINT x - #elif HOST_BITS_PER_HALF_WIDE_INT == HOST_BITS_PER_INT - # define HOST_HALF_WIDE_INT int - # define HOST_HALF_WIDE_INT_PRINT - # define HOST_HALF_WIDE_INT_PRINT_C - # define HOST_HALF_WIDE_INT_PRINT_DEC % HOST_HALF_WIDE_INT_PRINT d - # define HOST_HALF_WIDE_INT_PRINT_DEC_C HOST_HALF_WIDE_INT_PRINT_DEC HOST_HALF_WIDE_INT_PRINT_C - # define HOST_HALF_WIDE_INT_PRINT_UNSIGNED % HOST_HALF_WIDE_INT_PRINT u - # define HOST_HALF_WIDE_INT_PRINT_HEX %# HOST_HALF_WIDE_INT_PRINT x - # define HOST_HALF_WIDE_INT_PRINT_HEX_PURE % HOST_HALF_WIDE_INT_PRINT x - #elif HOST_BITS_PER_HALF_WIDE_INT == HOST_BITS_PER_SHORT - # define HOST_HALF_WIDE_INT short - # define HOST_HALF_WIDE_INT_PRINT - # define HOST_HALF_WIDE_INT_PRINT_C - # define HOST_HALF_WIDE_INT_PRINT_DEC % HOST_HALF_WIDE_INT_PRINT d - # define HOST_HALF_WIDE_INT_PRINT_DEC_C HOST_HALF_WIDE_INT_PRINT_DEC HOST_HALF_WIDE_INT_PRINT_C - # define HOST_HALF_WIDE_INT_PRINT_UNSIGNED % HOST_HALF_WIDE_INT_PRINT u - # define HOST_HALF_WIDE_INT_PRINT_HEX %# HOST_HALF_WIDE_INT_PRINT x - # define HOST_HALF_WIDE_INT_PRINT_HEX_PURE % HOST_HALF_WIDE_INT_PRINT x - #else - #error Please add support for HOST_HALF_WIDE_INT - #endif - - #define HOST_WIDE_INT_UC(X) HOST_WIDE_INT_C (X ## U) #define HOST_WIDE_INT_1 HOST_WIDE_INT_C (1) #define HOST_WIDE_INT_1U HOST_WIDE_INT_UC (1) --- 64,69 *** extern char sizeof_long_long_must_be_8[s *** 109,156 typedef before using the __asm_fprintf__ format attribute. */ typedef HOST_WIDE_INT __gcc_host_wide_int__; - /* Various printf format strings for HOST_WIDE_INT. */ - - #if HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONG - # define HOST_WIDE_INT_PRINT HOST_LONG_FORMAT - # define HOST_WIDE_INT_PRINT_C L - /* HOST_BITS_PER_WIDE_INT is 64 bits. */ - # define HOST_WIDE_INT_PRINT_DOUBLE_HEX \ - 0x% HOST_LONG_FORMAT x%016 HOST_LONG_FORMAT x - # define HOST_WIDE_INT_PRINT_PADDED_HEX \ - %016 HOST_LONG_FORMAT x - #else - # define HOST_WIDE_INT_PRINT HOST_LONG_LONG_FORMAT - # define HOST_WIDE_INT_PRINT_C LL - /* HOST_BITS_PER_WIDE_INT is 64 bits. */ - # define HOST_WIDE_INT_PRINT_DOUBLE_HEX \ - 0x% HOST_LONG_LONG_FORMAT x%016 HOST_LONG_LONG_FORMAT x - # define HOST_WIDE_INT_PRINT_PADDED_HEX \ - %016 HOST_LONG_LONG_FORMAT x - #endif /* HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONG */ - - #define HOST_WIDE_INT_PRINT_DEC % HOST_WIDE_INT_PRINT d - #define HOST_WIDE_INT_PRINT_DEC_C HOST_WIDE_INT_PRINT_DEC HOST_WIDE_INT_PRINT_C - #define HOST_WIDE_INT_PRINT_UNSIGNED % HOST_WIDE_INT_PRINT u - #define HOST_WIDE_INT_PRINT_HEX %# HOST_WIDE_INT_PRINT x - #define HOST_WIDE_INT_PRINT_HEX_PURE % HOST_WIDE_INT_PRINT x - /* Provide C99 inttypes.h style format definitions for 64bits. */ #ifndef HAVE_INTTYPES_H #undef PRId64 ! #define PRId64 HOST_WIDE_INT_PRINT d #undef PRIi64 ! #define PRIi64 HOST_WIDE_INT_PRINT i #undef PRIo64 ! #define
RE: [PATCH, PR58942, Cilk+] Fix ICE when pointer is used in array notation
BTW, similar testcase seems to segfault too:
int foo (int*p, int *i)
{
return __sec_reduce_max_ind(p[1:i]);
}
This one should be fixed by r210930
Thanks,
Igor
[PATCH] Do not build libsanitizer also for powerpc*-*-linux*
Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. The proposed patch disables building libsanitizer for powerpc*-*-linux* in addition to already disabled powerpc*le-*-linux* until the smarter solution will emerge. The actual issue preventing ASAN from porting to PPC seems to be inability to retrieve values of PC and BP on this architecture. --- gcc-4.10-20140525/libsanitizer/configure.tgt~ 2014-05-26 17:59:21.224116974 +0800 +++ gcc-4.10-20140525/libsanitizer/configure.tgt 2014-05-26 18:00:03.048478781 +0800 @@ -26,11 +26,9 @@ LSAN_SUPPORTED=yes fi ;; - powerpc*le-*-linux*) + powerpc*-*-linux* | powerpc*le-*-linux*) UNSUPPORTED=1 ;; - powerpc*-*-linux*) - ;; sparc*-*-linux*) ;; arm*-*-linux*)
Re: [PATCH] Fix PR54733 Optimize endian independent load/store
On 23 May 2014 05:36, Thomas Preud'homme thomas.preudho...@arm.com wrote: From: Richard Biener [mailto:richard.guent...@gmail.com] On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme thomas.preudho...@arm.com wrote: Updated ChangeLogs: *** gcc/ChangeLog *** 2014-05-20 Thomas Preud'homme thomas.preudho...@arm.com PR tree-optimization/54733 * tree-ssa-math-opts.c (nop_stats): New bswap_stats structure. (CMPNOP): Define. (find_bswap_or_nop_load): New. (find_bswap_1): Renamed to ... (find_bswap_or_nop_1): This. Also add support for memory source. (find_bswap): Renamed to ... (find_bswap_or_nop): This. Also add support for memory source and detection of bitwise operations equivalent to load in host endianness. (execute_optimize_bswap): Likewise. Also move its leading comment back in place and split statement transformation into ... (bswap_replace): This. *** gcc/testsuite/ChangeLog *** 2014-05-20 Thomas Preud'homme thomas.preudho...@arm.com PR tree-optimization/54733 * gcc.dg/optimize-bswapdi-3.c: New test to check extension of bswap optimization to support memory sources and bitwise operations equivalent to load in host endianness. * gcc.dg/optimize-bswaphi-1.c: Likewise. * gcc.dg/optimize-bswapsi-2.c: Likewise. * gcc.c-torture/execute/bswap-2.c: Likewise. Best regards, This is ok. Great. Commited. Thanks a lot for your patience in mentoring me to improve this patch. Best regards, Thomas I have noticed that the new bswap-2.c test fails at execution on armeb targets. See: http://cbuild.validation.linaro.org/build/cross-validation/gcc/210843/report-build-info.html Could you have a look? Thanks, Christophe.
RE: [PATCH] Fix PR54733 Optimize endian independent load/store
From: Christophe Lyon [mailto:christophe.l...@linaro.org] I have noticed that the new bswap-2.c test fails at execution on armeb targets. See: http://cbuild.validation.linaro.org/build/cross-validation/gcc/210843/report- build-info.html Could you have a look? Sure. I suspect it's the same kind of problem m68k run into. I already wrote a patch to reduce the impact of different bitfield layout and it's in review right now. I'll send you tomorrow for testing. Thanks for the feedback. Best regards, Thomas
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
So changing just 2 of them doesn't feel right to me… Here’s a patch that removes all the casts on output operands in x86/x86_64 code in longlong.h. Again bootstrapped on x86_64-apple-darwin13, passing both stage1 (system compiler) and stages 2-3 (gcc). OK to commit? Other archs which have such code are arc, arm, hppa, m32r, mc68000, mc68020, ns32000, ibm032, sparc, and vax. Since I don’t have any of those to test on, I can’t test it there. If you or another global reviewer indicate that a patch extending the work attached to these other archs is suitable, I’m willing to do the tedious work of proposing a full patch, but I won’t be able to test it (and I didn’t want to do it if it had no chance of being accepted). Thanks, FX longlong.ChangeLog Description: Binary data longlong.ChangeLog Description: Binary data
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
So changing just 2 of them doesn't feel right to me… [Again, with the patch actually attached… sorry] Here’s a patch that removes all the casts on output operands in x86/x86_64 code in longlong.h. Again bootstrapped on x86_64-apple-darwin13, passing both stage1 (system compiler) and stages 2-3 (gcc). OK to commit? Other archs which have such code are arc, arm, hppa, m32r, mc68000, mc68020, ns32000, ibm032, sparc, and vax. Since I don’t have any of those to test on, I can’t test it there. If you or another global reviewer indicate that a patch extending the work attached to these other archs is suitable, I’m willing to do the tedious work of proposing a full patch, but I won’t be able to test it (and I didn’t want to do it if it had no chance of being accepted). Thanks, FX longlong.diff Description: Binary data longlong.ChangeLog Description: Binary data
Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux*
On Mon, May 26, 2014 at 2:53 PM, Arseny Solokha asolo...@gmx.com wrote: Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. The proposed patch disables building libsanitizer for powerpc*-*-linux* in addition to already disabled powerpc*le-*-linux* until the smarter solution will emerge. The actual issue preventing ASAN from porting to PPC seems to be inability to retrieve values of PC and BP on this architecture. I agree with disabling asan on any platform that is not supported upstream. You still may need someone else's (Jakub's?) approval for this.
Ping #1: [patch,arm] Add GCC runtime library exceptions to files that go into libgcc
This is Ping #1 for https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00747.html an addendum that adds runtime library exception to two more files in the ARM backend (arm-opts.h, arm-cores.def) that are included in libgcc. Ok to apply? Johann Am 05/10/2014 02:51 AM, schrieb Ian Lance Taylor: Georg-Johann Lay a...@jlay.de writes: This patch adds GCC Runtime Library Exception to files that go into libgcc because libgcc2.c includes tm.h and libgcc_tm.h. Most of these files contain much code, some used by libgcc, some not. Some potential users of (lib)gcc have objections that missing RLE might infect their target code. Even though I know that this is actually not the case and the FSF is fine with target code linked against libgcc, it's pointless to argue in that direction. At least this is my personal experience with advocates. I am aware that there was effort for better separation of libgcc and GCC, but obviously this separation has not yet been achieved. This this ok for trunk? And is there anything special about license changes w.r.t FSF that I have to take into account? CCed Ian so that someone from the GCC steering committee can have a look. I think this is unnecessary but fine. Thanks. Yes, I know it's not needed... yet it can increase acceptance of GCC. I opened a PR61152 for this so that it's clearer for why the Runtime Exceptions will be added: http://gcc.gnu.org/PR61152 Added two files included by arm.h I missed; is it in order to apply this, too? And is it in order to apply/backport this to the 4.9 branch? From source perspective the changes are trivial enough. Johann PR libgcc/61152 * config/arm/arm-opts.h (License): Add GCC Runtime Library Exception. * config/arm/arm-cores.def (License): Same. Index: gcc/config/arm/arm-cores.def === --- gcc/config/arm/arm-cores.def(revision 210321) +++ gcc/config/arm/arm-cores.def(working copy) @@ -14,6 +14,10 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + Under Section 7 of GPL version 3, you are granted additional + permissions described in the GCC Runtime Library Exception, version + 3.1, as published by the Free Software Foundation. + You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/. */ Index: gcc/config/arm/arm-opts.h === --- gcc/config/arm/arm-opts.h (revision 210321) +++ gcc/config/arm/arm-opts.h (working copy) @@ -13,6 +13,10 @@ or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + Under Section 7 of GPL version 3, you are granted additional + permissions described in the GCC Runtime Library Exception, version + 3.1, as published by the Free Software Foundation. + You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/. */
Re: [PATCH, libgfortran] PR 61310 CTIME intrinsic output incorrect on MinGW
On Mon, May 26, 2014 at 01:00:56PM +0300, Janne Blomqvist wrote: On Mon, May 26, 2014 at 1:25 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 26, 2014 at 12:21:21AM +0300, Janne Blomqvist wrote: Hi, GFortran currently uses strftime(...,%c,...) to produce the result for the CTIME and FDATE intrinsics. Unfortunately, it seems that on MinGW this does not produce identical output to the C stdlib ctime(), even in the default locale. The attached patch implements an alternative approach, originally suggested by Jakub in PR 47802, to produce a thread-safe ctime-like function by using snprintf manually. Regtested on x86_64-unknown-linux-gnu, Ok for trunk/4.9/4.8/4.7? Patch looks ok to me. +/* Maximum space a ctime-like string might need. A normal ctime + string is 26 bytes, but the maximum possible year number is + 2,147,485,547 (2,147,483,647 + 1900, since tm_year is a 32-bit + signed integer) so an extra 6 bytes are needed. */ +#define CSZ 32 Is there a better name than CSZ, which is not exactly too descriptive? Hmm, what about CTIME_BUFSZ? Ok with that change? Yes, the name is much better. Yes, patch is ok. -- Steve
strengthen protection against REG_EQUIV/EQUAL on !REG set
Hello, This is a follow up on a thread started long ago there: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00967.html With a first followup and a patch proposal there: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00731.html Then a refinement suggested by Richard Sandiford here: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01515.html We have been running with the proposed patch for years now, it still applies on mainline and bootstraps + regtests fine on x86_64-linux for languages=all,ada. Ok to commit ? Thanks in advance, With Kind Regards, Olivier 2014-05-26 Richard Sandiford rdsandif...@googlemail.com * rtl.h (set_for_reg_notes): Declare. * emit-rtl.c (set_for_reg_notes): New function. (set_unique_reg_note): Use it. * optabs.c (add_equal_note): Likewise. ehregnote.diff Description: Binary data
Re: [RFC] optimize x - y cmp 0 with undefined overflow
On Mon, May 26, 2014 at 12:22 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
the motivation of this work is to get rid of the range check on Z in:
function F (X : Integer; Y : Integer ) return Positive is
Z : Integer;
begin
if X = Y then
return 1;
end if;
Z := Y - X;
return Z;
end;
An equivalent C testcase is:
extern void abort (void);
int foo (int x, int y)
{
int z;
if (x = y)
return 1;
z = y - x;
if (z = 0)
abort ();
return z;
}
for which the call to abort is not optimized at -O2.
fold_comparison knows how to optimize X +- C1 CMP C2 to X CMP C2 -+ C1 with
undefined overflow so optimizing X - Y CMP 0 to X CMP Y is a generalization.
Once this is done, forwprop will immediately optimize:
extern void abort (void);
int foo (int x, int y)
{
int z;
if (x = y)
return 1;
z = y - x;
if (z = 0)
abort ();
return 0;
}
because 'z' has a single use, but the original testcase won't be optimized.
The attached patch implements the missing bits in vrp_evaluate_conditional by
manual propagating the operands of a defining PLUS_EXPR or MINUS_EXPR for an
SSA name in a condition; an other possibility could be DOM instead of VRP.
This comes with 4 testcases: the original Ada testcase, the C equivalent, a
testcase for the folding and another one for the -Wstrict-overflow warning.
Tested on x86_64-suse-linux with no regressions.
+ tree new_const
+ = fold_build2_loc (loc, reverse_op, TREE_TYPE (arg1), const2, const1);
/* If the constant operation overflowed this can be
simplified as a comparison against INT_MAX/INT_MIN. */
- if (TREE_CODE (lhs) == INTEGER_CST
- TREE_OVERFLOW (lhs))
+ if (TREE_OVERFLOW (new_const))
well, either use int_const_binop above or retain the check (or use
TREE_OVERFLOW_P). Bonus points for using wide-ints here
and not relying on TREE_OVERFLOW.
+ /* Transform comparisons of the form X - Y CMP 0 to X CMP Y. */
+ if (TREE_CODE (arg0) == MINUS_EXPR
+ TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg1))
any good reason for using TYPE_OVERFLOW_UNDEFINED on the
type of arg1 instead on the type of the MINUS (yes, they should
match, but it really looks odd ... the overflow of the minus has to be
undefined). Also for EQ_EXPR and NE_EXPR the transform is
fine even when !TYPE_OVERFLOW_UNDEFINED (and we seem
to perform it already somewhere). Please look where and try to
add the undefined overflow case to it.
As for the VRP pieces I don't understand what is missing here
(well, compare_range_with_value and/or compare_values might
not handle this case? then better fix that to improve symbolic
range handling in general?). Also I have a longstanding patch
in my tree that does
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 210931)
+++ gcc/tree-vrp.c (working copy)
@@ -6919,14 +6919,15 @@ vrp_evaluate_conditional_warnv_with_ops_
vr0 = (TREE_CODE (op0) == SSA_NAME) ? get_value_range (op0) : NULL;
vr1 = (TREE_CODE (op1) == SSA_NAME) ? get_value_range (op1) : NULL;
+ tree res = NULL_TREE;
if (vr0 vr1)
-return compare_ranges (code, vr0, vr1, strict_overflow_p);
- else if (vr0 vr1 == NULL)
-return compare_range_with_value (code, vr0, op1, strict_overflow_p);
- else if (vr0 == NULL vr1)
-return (compare_range_with_value
+res = compare_ranges (code, vr0, vr1, strict_overflow_p);
+ if (!res vr0)
+res = compare_range_with_value (code, vr0, op1, strict_overflow_p);
+ if (!res vr1)
+res = (compare_range_with_value
(swap_tree_comparison (code), vr1, op0, strict_overflow_p));
- return NULL;
+ return res;
}
/* Helper function for vrp_evaluate_conditional_warnv. */
maybe that helps as well.
Thanks,
Richard.
2014-05-26 Eric Botcazou ebotca...@adacore.com
* fold-const.c (fold_comparison): Clean up and simplify X +- C1 CMP C2
to X CMP C2 -+ C1 transformation, add X - Y CMP 0 to X CMP Y.
* tree-vrp.c (vrp_evaluate_conditional_warnv_with_fold): New function.
(vrp_evaluate_conditional): Call it on SSA names with defining
PLUS_EXPR
or MINUS_EXPR if the evaluation of the condition yielded nothing.
2014-05-26 Eric Botcazou ebotca...@adacore.com
* gcc.dg/fold-compare-8.c: New test.
* gcc.dg/Wstrict-overflow-25.c: Likewise.
* gcc.dg/tree-ssa/vrp92.c: Likewise.
* gnat.dg/opt38.adb: Likewise.
--
Eric Botcazou
Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags
Jan Hubicka hubi...@ucw.cz writes: I'm fine with enlarging tree_function_decl for now - ideally we'd push stuff from it elsewhere (like target and optimization option tree nodes, or most of the visibility and symbol related stuff). Not sure why tree_type_decl inherits from tree_decl_non_common (and thus tree_decl_with_vis). Probably because of the non-common parts being (ab-)used by FEs. Otherwise I'd say simply put a symtab node pointer into tree_decl_with_vis ... (can we move section_name and comdat_group more easily than assembler_name?) Hi, this patch removes comdat_group pointer and adds direct symtab pointer. As expected, the change is not completely easy. The main uglyness in C++'s version of duplicate_decl that creates a duplicated decl with duplicated symtab node now and needs to remove it. Other problem is copy_node and c's duplicate_decl that does memcpy on a node and thus also copie the symtab pointer that is not the right thing to do. On the other hand on middle-end side several things simplify, so I think overall the approach works relatively well. I have bootstrapped/regtested x86_64-linux and I plan to give it more testing tomorrow and commit if there are no complains. Incrementally I would like then to cleanup way the decl_with_vis.symtab_node pointer is maintained. I do not want to allow users to tamper with it, so I did not make accessor macro for it, however there are more direct uses than I would like: I will need to figure out how to reduce those. This patch broke Solaris bootstrap: /vol/gcc/src/hg/trunk/local/gcc/config/sol2.c: In function 'void solaris_elf_asm_comdat_section(const char*, unsigned int, tree)': /vol/gcc/src/hg/trunk/local/gcc/config/sol2.c:213:17: error: 'decl_comdat_group' was not declared in this scope /vol/gcc/src/hg/trunk/local/gcc/config/sol2.c: In function 'int solaris_define_comdat_signature(comdat_entry**, void*)': /vol/gcc/src/hg/trunk/local/gcc/config/sol2.c:267:12: error: 'decl_comdat_group' was not declared in this scope The following snippet allows a sparc-sun-solaris2.11 bootstrap to go along further, only to break again later in libjava for what seems to be unrelated reasons. 2014-05-26 Rainer Orth r...@cebitec.uni-bielefeld.de * config/sol2.c: Include cgraph.h. diff --git a/gcc/config/sol2.c b/gcc/config/sol2.c --- a/gcc/config/sol2.c +++ b/gcc/config/sol2.c @@ -32,6 +32,7 @@ along with GCC; see the file COPYING3. #include diagnostic-core.h #include ggc.h #include hash-table.h +#include cgraph.h tree solaris_pending_aligns, solaris_pending_inits, solaris_pending_finis; I'm not sure if this is the right approach, though, using get_comdat_group seems to be preferred!? ISTM that other ports might have similar problems: darwin.c, mep/mep.c, and mips/mips.c all use DECL_COMDAT_GROUP without including cgraph.h. * mips.c (mips_start_unique_function): Likewise. (ix86_code_end): Likewise. (rs6000_code_end): Likweise. The last two entries lack the file names. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Fix primitive wi::int_traits
The following patch fixes completes the primitive int_traints
with long and long long variants and drops the HWI case. This
fixes darwin builds where HOST_WIDE_INT is 'long' but
int64_t is 'long long'.
Bootstrapped on x86_64-unknown-linux-gnu (and on darwin by Ian),
soon to be committed.
Richard.
2014-05-26 Richard Biener rguent...@suse.de
* wide-int.h (wi::int_traits long, wi::int_traits unsigned long,
wi::int_traits long long, wi::int_traits unsigned long long):
Provide specializations.
(wi::int_traits HOST_WIDE_INT,
wi::int_traits unsigned HOST_WIDE_INT): Remove specializations.
Index: gcc/wide-int.h
===
--- gcc/wide-int.h (revision 210931)
+++ gcc/wide-int.h (working copy)
@@ -1446,12 +1446,22 @@ namespace wi
: public primitive_int_traits unsigned int, false {};
template
- struct int_traits HOST_WIDE_INT
-: public primitive_int_traits HOST_WIDE_INT, true {};
+ struct int_traits long
+: public primitive_int_traits long, true {};
template
- struct int_traits unsigned HOST_WIDE_INT
-: public primitive_int_traits unsigned HOST_WIDE_INT, false {};
+ struct int_traits unsigned long
+: public primitive_int_traits unsigned long, false {};
+
+#if defined HAVE_LONG_LONG
+ template
+ struct int_traits long long
+: public primitive_int_traits long long, true {};
+
+ template
+ struct int_traits unsigned long long
+: public primitive_int_traits unsigned long long, false {};
+#endif
}
namespace wi
detecting container overflow bugs in std::vector
Hello, Some of std::vector misuses are very hard to find with internal STL checks or using external tools (such as Valgrind or AddressSanitizer [1]). Example: std::vectorint v(4); v.reserve(8); int *p = v.data(); p[6] = 0; // BOOM We call these bugs container overflow [2,6] and we've developed a method for finding them using a combination of AddressSanitizer [1] and code annotations in the STL code. We've implemented these annotations in libc++ trunk [3] and in our branch of libstdc++ [4]. These annotations have found over 30 bugs for us, and are still finding more. Would you consider a patch similar to [4] for libstdc++ trunk? If yes, any comments on the patch? The current patch has a (minor) problem that affects only code with exceptions [5]. If the libstdc++ team is generally ok with the idea I will work on the updated patch and send it for review. [1] http://code.google.com/p/address-sanitizer/ [2] https://code.google.com/p/address-sanitizer/wiki/ContainerOverflow [3] http://llvm.org/viewvc/llvm-project?view=revisionrevision=208319 [4] https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=207517 [5] https://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg96615.html [6] http://llvm.org/devmtg/2014-04/PDFs/LightningTalks/EuroLLVM%202014%20--%20container%20overflow.pdf Thanks, --kcc
[C PATCH] Better location info for function parameters (PR c/56724)
This patch introduces $subject, so if the warning says passing
argument N of X, the caret points to actual argument and not
to function decl. So e.g.:
pr56724-2.c:23:17: warning: passing argument 3 of ‘foo_sc’ from incompatible
pointer type
foo_sc (1, 2, f);
^
pr56724-2.c:9:13: note: expected ‘signed char *’ but argument is of type ‘float
*’
extern void foo_sc (int, int, signed char *);
^
Note that the column info for note: is still not optimal :( (and fixing this
will
be probably a little bit harder).
Furthermore, the patch adds missing OPT_Wtraditional_conversion to warning_at
calls, alongside with some whitespace fixes.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
[Joseph is away this week, so it would be appreciated if someone else could
approve this.]
2014-05-26 Marek Polacek pola...@redhat.com
PR c/56724
* c-typeck.c (convert_arguments): Get location of a parameter. Change
error and warning calls to error_at and warning_at. Pass location of
a parameter to it. Call warning_at with OPT_Wtraditional_conversion.
(convert_for_assignment): Add parameter to WARN_FOR_ASSIGNMENT and
WARN_FOR_QUALIFIERS. Pass expr_loc to those.
* gcc.dg/pr56724-1.c: New test.
* gcc.dg/pr56724-2.c: New test.
* gcc.dg/wtr-conversion-1.c: Use -Wtraditional-conversion instead of
-Wtraditional.
* gcc.dg/dfp/wtr-conversion-1.c: Likewise.
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 74a5ebd..0e31d39 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -3072,6 +3072,12 @@ convert_arguments (location_t loc, veclocation_t
arg_loc, tree typelist,
bool excess_precision = false;
bool npc;
tree parmval;
+ /* Some __atomic_* builtins have additional hidden argument at
+position 0. */
+ location_t ploc
+ = !arg_loc.is_empty () values-length () == arg_loc.length ()
+ ? expansion_point_location_if_in_system_header (arg_loc[parmnum])
+ : input_location;
if (type == void_type_node)
{
@@ -3114,7 +3120,8 @@ convert_arguments (location_t loc, veclocation_t
arg_loc, tree typelist,
if (type == error_mark_node || !COMPLETE_TYPE_P (type))
{
- error (type of formal parameter %d is incomplete, parmnum + 1);
+ error_at (ploc, type of formal parameter %d is incomplete,
+ argnum);
parmval = val;
}
else
@@ -3129,34 +3136,40 @@ convert_arguments (location_t loc, veclocation_t
arg_loc, tree typelist,
if (INTEGRAL_TYPE_P (type)
TREE_CODE (valtype) == REAL_TYPE)
- warning (0, passing argument %d of %qE as integer
-rather than floating due to prototype,
-argnum, rname);
+ warning_at (ploc, OPT_Wtraditional_conversion,
+ passing argument %d of %qE as integer rather
+ than floating due to prototype,
+ argnum, rname);
if (INTEGRAL_TYPE_P (type)
TREE_CODE (valtype) == COMPLEX_TYPE)
- warning (0, passing argument %d of %qE as integer
-rather than complex due to prototype,
-argnum, rname);
+ warning_at (ploc, OPT_Wtraditional_conversion,
+ passing argument %d of %qE as integer rather
+ than complex due to prototype,
+ argnum, rname);
else if (TREE_CODE (type) == COMPLEX_TYPE
TREE_CODE (valtype) == REAL_TYPE)
- warning (0, passing argument %d of %qE as complex
-rather than floating due to prototype,
-argnum, rname);
+ warning_at (ploc, OPT_Wtraditional_conversion,
+ passing argument %d of %qE as complex rather
+ than floating due to prototype,
+ argnum, rname);
else if (TREE_CODE (type) == REAL_TYPE
INTEGRAL_TYPE_P (valtype))
- warning (0, passing argument %d of %qE as floating
-rather than integer due to prototype,
-argnum, rname);
+ warning_at (ploc, OPT_Wtraditional_conversion,
+ passing argument %d of %qE as floating rather
+ than integer due to prototype,
+ argnum, rname);
else if (TREE_CODE (type) == COMPLEX_TYPE
INTEGRAL_TYPE_P (valtype))
- warning (0, passing argument
Re: detecting container overflow bugs in std::vector
On 26/05/14 17:40 +0400, Konstantin Serebryany wrote: Would you consider a patch similar to [4] for libstdc++ trunk? If yes, any comments on the patch? + // When sanitizer annotataions are off, avoid bazillion of no-op I'd rather see the member functions use our consistent naming conventions. The function parameters in the __is_same_allocatorT,U case should be unnamed, to avoid warnings with -Wsystem-headers. The __old_size variable should be marked __attribute((unused)) too, or just get rid of it and pass size() - 1 to the annotate function. The current patch has a (minor) problem that affects only code with exceptions [5]. So only most C++ code then. That's not minor. Not everyone turns off exceptions like Google. If the libstdc++ team is generally ok with the idea I will work on the updated patch and send it for review. It does look useful but I'm concerned about a proliferation of container checks, we already have the libstdc++ Debug Mode, and I'd like to see some of the lightweight checks from the Google branch added to trunk too. The exception problem is a showstopper, but should be fixable with some RAII.
[C++ Patch] PR 43453
Hi,
according to the analysis, we should not reject these initializations.
Thus I added some code following closely 8.5/17. I also enlarged the
testcase a bit to make sure that, for example, we still reject too long
initializer-strings (a preliminary draft didn't call digest_init)
Tested x86_64-linux.
///
/cp
2014-05-26 Paolo Carlini paolo.carl...@oracle.com
PR c++/43453
* typeck.c (cp_build_modify_expr): Handle array of characters
initialized by a string literal.
* typeck2.c (store_init_value): Likewise.
/testsuite
2014-05-26 Paolo Carlini paolo.carl...@oracle.com
PR c++/43453
* g++.dg/init/pr43453.C: New.
Index: cp/typeck.c
===
--- cp/typeck.c (revision 210928)
+++ cp/typeck.c (working copy)
@@ -7502,6 +7502,18 @@ cp_build_modify_expr (tree lhs, enum tree_code mod
return error_mark_node;
}
+ /* C++11 8.5/17: If the destination type is an array of characters,
+an array of char16_t, an array of char32_t, or an array of wchar_t,
+and the initializer is a string literal */
+ else if (TREE_CODE (newrhs) == STRING_CST
+ char_type_p (TREE_TYPE (lhstype))
+ modifycode == INIT_EXPR)
+ {
+ newrhs = digest_init (lhstype, newrhs, complain);
+ if (newrhs == error_mark_node)
+ return error_mark_node;
+ }
+
else if (!same_or_base_type_p (TYPE_MAIN_VARIANT (lhstype),
TYPE_MAIN_VARIANT (TREE_TYPE (newrhs
{
Index: cp/typeck2.c
===
--- cp/typeck2.c(revision 210928)
+++ cp/typeck2.c(working copy)
@@ -786,7 +786,12 @@ store_init_value (tree decl, tree init, vectree,
gcc_assert (TREE_CODE (decl) != RESULT_DECL);
if (TREE_CODE (init) == TREE_LIST
- TREE_CODE (TREE_TYPE (decl)) == ARRAY_TYPE)
+ TREE_CODE (type) == ARRAY_TYPE
+ /* C++11 8.5/17: If the destination type is an array of characters,
+an array of char16_t, an array of char32_t, or an array of wchar_t,
+and the initializer is a string literal */
+ !(char_type_p (TREE_TYPE (type))
+ TREE_CODE (TREE_VALUE (init)) == STRING_CST))
{
error (cannot initialize arrays using this syntax);
return NULL_TREE;
Index: testsuite/g++.dg/init/pr43453.C
===
--- testsuite/g++.dg/init/pr43453.C (revision 0)
+++ testsuite/g++.dg/init/pr43453.C (working copy)
@@ -0,0 +1,22 @@
+// PR c++/43453
+
+struct A {
+ char x[4];
+ A() : x(bug) { };
+};
+
+char x [4] (bug);
+
+struct B {
+ char y[4];
+ B() : y(bu) { };
+};
+
+char y [4] (bu);
+
+struct C {
+ char z[4];
+ C() : z(bugs) { }; // { dg-error too long }
+};
+
+char z [4] (bugs);// { dg-error too long }
Re: detecting container overflow bugs in std::vector
On 26/05/14 15:12 +0100, Jonathan Wakely wrote: It does look useful but I'm concerned about a proliferation of container checks, we already have the libstdc++ Debug Mode, and I'd like to see some of the lightweight checks from the Google branch added to trunk too. I see that the patch on the Google branch removes some of the __google_stl_debug_vector checks -- are they considered no longer necessary/useful with asan? Aren't they still much cheaper than asan instrumentation?
Re: [PATCH] Fix primitive wi::int_traits
On May 26, 2014, at 6:39 AM, Richard Biener rguent...@suse.de wrote: The following patch fixes completes the primitive int_traints with long and long long variants and drops the HWI case. Bootstrapped on x86_64-unknown-linux-gnu (and on darwin by Ian), soon to be committed. Looks good, thanks.
Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
On 04/28/2014 10:08 AM, Christian Bruel wrote:
Hello,
I'd like to ping the following patches
[Hookize mode-switching]
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01003.html
[Add new hooks to support toggle and SH4A fpchg instruction]
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01005.html
Sorry, I only saw the first part and thought I' d need to wait till I
see the second part - and I somehow missed that.
I think the previous known mode should be passed to the
TARGET_MODE_EMIT hook - no need to have extra hooks
for toggling, and, as I mentioned earlier, fixating on the toggle is
actually an SH artifact - other ports have multi-way
modes settings that can benefit from knowing the previous mode.
OK I'll change the bool toggle parameter by the previous mode in
TARGET_MODE_EMIT and remove the bool XOR hooks in the SH description.
Hello,
This is the interface for targets that could use the previous mode for
switching. TARGET_MODE_EMIT now takes a new prev_mode parameter. If the
previous mode cannot be determined, MODE_NONE (value depends on the
entity) is used.
The implementation is less trivial than just supporting a boolean toggle
bit, as the previous modes information have to be carried along the
edges. For this I recycle the auxiliary edge field that is made
unnecessary by the removal of make_pred_opaque and a change in the
implementation to call LCM for every modes from every identity
simultaneously. This idea was suggested by Joern in PR29349. Another
speed improvement is that we process the modes to no_mode instead of
max_num_modes for each entity.
Thanks to all this, the only additional data to support prev_mode is
that for each BB, the avin/avout lcm computation are cached inside the
bb_info mode_in/mode_out fields, the xor toggle bit handling could
have been removed.
bootstrapped/regtested for x86 and sh4, sh4a, sh4a-single,
epiphany build is OK. testsuite not ran.
Joern, is this new target macro interface OK with you ? Jeff, (or other
RTL maintainer) since this is a new implementation for
optimize_mode_switching I suppose your previous approval doesn't held
anymore... is this new one OK for trunk as well ?
No change for x86/sh4/2a interfaces.
Many thanks
Christian
2014-05-23 Christian Bruel christian.br...@st.com
* mode-switching.c (struct bb_info): Add mode_out, mode_in caches.
(make_preds_opaque): Delete function.
(clear_mode_bit, mode_bit_p, set_mode_bit): New macros.
(add_mode_set, get_mode_set, alloc_mode_aux, free_modes_edges): New functions.
(commit_mode_sets): New function.
(optimize_mode_switching): Handle current_mode to mode_switching_emit.
Process all modes at once.
* basic-block.h (pre_edge_lcm_avs): Declare.
* lcm.c (pre_edge_lcm_avs): Renamed from pre_edge_lcm.
Call clear_aux_for_edges. Fix comments.
(pre_edge_lcm): New wrapper function to call pre_edge_lcm_avs.
(pre_edge_rev_lcm): Idem.
* config/epiphany/epiphany.c (emit_set_fp_mode): Add prev_mode parameter.
* config/epiphany/epiphany-protos.h (emit_set_fp_mode): Idem.
* config/epiphany/resolve-sw-modes.c (pass_resolve_sw_modes::execute): Idem.
* config/i386/i386.c (x96_emit_mode_set): Idem.
* config/sh/sh.c (sh_emit_mode_set): Likewise. Handle PR toggle.
* config/sh/sh.md (toggle_pr): Defined if TARGET_FPU_SINGLE.
(fpscr_toggle) Disallow from delay slot.
* target.def (emit_mode_set): Add prev_mode parameter.
* doc/tm.texi: Regenerate.
2014-05-19 Christian Bruel christian.br...@st.com
* gcc.target/sh/fpchg.c: New test.
Index: gcc/basic-block.h
===
--- gcc/basic-block.h (revision 210845)
+++ gcc/basic-block.h (working copy)
@@ -711,6 +711,9 @@ extern void bitmap_union_of_preds (sbitmap, sbitma
extern struct edge_list *pre_edge_lcm (int, sbitmap *, sbitmap *,
sbitmap *, sbitmap *, sbitmap **,
sbitmap **);
+extern struct edge_list *pre_edge_lcm_avs (int, sbitmap *, sbitmap *,
+ sbitmap *, sbitmap *, sbitmap *,
+ sbitmap *, sbitmap **, sbitmap **);
extern struct edge_list *pre_edge_rev_lcm (int, sbitmap *,
sbitmap *, sbitmap *,
sbitmap *, sbitmap **,
Index: gcc/config/epiphany/epiphany-protos.h
===
--- gcc/config/epiphany/epiphany-protos.h (revision 210845)
+++ gcc/config/epiphany/epiphany-protos.h (working copy)
@@ -40,7 +40,8 @@ extern int epiphany_initial_elimination_offset (in
extern void epiphany_init_expanders (void);
extern int hard_regno_mode_ok (int regno, enum machine_mode mode);
#ifdef HARD_CONST
-extern void emit_set_fp_mode (int entity, int mode, HARD_REG_SET regs_live);
+extern void emit_set_fp_mode (int entity, int mode, int prev_mode,
+ HARD_REG_SET regs_live);
#endif
extern void epiphany_insert_mode_switch_use (rtx insn, int, int);
extern void epiphany_expand_set_fp_mode (rtx *operands);
Index: gcc/config/epiphany/epiphany.c
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
On May 26, 2014, at 2:22 AM, FX fxcoud...@gmail.com wrote: This causes GCC bootstrap to fail on Darwin systems (whose system compiler is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s the right call, see below), I’ve filed a separate report for the bootstrap issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315). Since my PR has been closed twice by Andrew Pinski (“it’s clang’s fault, bouh ouh”), I’d ask the maintainers to step in. Can we please provide a GCC that works for the default darwin setup? Or at least drop darwin as secondary target and document the failure? The best coarse of action, post a patch, have it reviewed and put in. Current action, a patch has been posted, the review is outstanding, I’d like to see it put in; though, I am curious why the casts were there in the first place. Another way out, #ifndef clang the entire thing and disappear the contents for clang. I’d be fine with that as well, ultimately the longlong.h people will have to choose how they want to solve the issue. The state of the PR system isn’t as concerning to me as the state of the software tree. The bug _will_ get fixed, one way, or, another. The current patch posted that removes the casts seems like the best possible solution to me.
[PATCH] Fix regexp in gfortran.dg/bind_c_array_params_2.f90
The following patch adjust the regexp in gfortran.dg/bind_c_array_params_2.f90.
Tested on powerpc-apple-darwin9* and x86_64-apple-darwin*, and by
Andreas Schwab on unspecified targets (see
https://gcc.gnu.org/ml/fortran/2014-05/msg00137.html).
OK for trunk?
Dominique
2014-05-26 Dominique d'Humieres domi...@lps.ens.fr
* gfortran.dg/gfortran.dg/bind_c_array_params_2.f90:
Adjust regexp for more targets.
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
2014-05-24 16:17:53.0 +0200
+++ gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 2014-05-25
20:38:18.0 +0200
@@ -16,7 +16,7 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final { scan-assembler-times call\[^\n\r\]*myBindC 1 { target { ! {
hppa*-*-hpux* } } } } }
-! { dg-final { scan-assembler-times call\[^\n\r\]*myBindC,%r2 1 { target {
hppa*-*-hpux* } } } }
+! { dg-final { scan-assembler-times \[ \t\]_*myBindC 1 { target { ! {
hppa*-*-hpux* } } } } }
+! { dg-final { scan-assembler-times \[ \t\]_*myBindC,%r2 1 { target {
hppa*-*-hpux* } } } }
! { dg-final { scan-tree-dump-times test \\\(parm\\. 1 original } }
! { dg-final { cleanup-tree-dump original } }
Re: ipa-visibility TLC 2/n
On 05/25/2014 07:54 AM, Jan Hubicka wrote:
Hi,
this patch adds code to rerite references in vtable initializers to local
aliases
when doing so is a win.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-visibility.c (can_replace_by_local_alias_in_vtable): New function.
(update_vtable_references): New function.
(function_and_variable_visibility): Rewrite also vtable initializers.
* varpool.c (cgraph_variable_initializer_availability): Remove assert.
Index: varpool.c
===
--- varpool.c (revision 210908)
+++ varpool.c (working copy)
@@ -355,7 +355,6 @@ varpool_add_new_variable (tree decl)
enum availability
cgraph_variable_initializer_availability (varpool_node *node)
{
- gcc_assert (cgraph_function_flags_ready);
if (!node-definition)
return AVAIL_NOT_AVAILABLE;
if (!TREE_PUBLIC (node-decl))
Index: ipa-visibility.c
===
--- ipa-visibility.c(revision 210908)
+++ ipa-visibility.c(working copy)
@@ -343,6 +343,36 @@ can_replace_by_local_alias (symtab_node
!symtab_can_be_discarded (node));
}
+/* Return true if we can replace refernece to NODE by local alias
Hello Jan,
s/refernece/reference
+ within a virtual table. Generally we can replace function pointers
+ and virtual table pointers. */
+
+bool
+can_replace_by_local_alias_in_vtable (symtab_node *node)
+{
+ if (is_a varpool_node * (node)
+ !DECL_VIRTUAL_P (node-decl))
+return false;
+ return can_replace_by_local_alias (node);
+}
+
+/* walk_tree callback that rewrites initializer references. */
+
+static tree
+update_vtable_references (tree *tp, int *walk_subtrees, void *data
ATTRIBUTE_UNUSED)
+{
+ if (TREE_CODE (*tp) == VAR_DECL
+ || TREE_CODE (*tp) == FUNCTION_DECL)
+{
+ if (can_replace_by_local_alias_in_vtable (symtab_get_node (*tp)))
+ *tp = symtab_nonoverwritable_alias (symtab_get_node (*tp))-decl;
+ *walk_subtrees = 0;
+}
+ else if (IS_TYPE_OR_DECL_P (*tp))
+*walk_subtrees = 0;
+ return NULL;
+}
+
/* In LTO we can remove COMDAT groups and weak symbols.
Either turn them into normal symbols or external symbol depending on
resolution info. */
@@ -625,6 +655,34 @@ function_and_variable_visibility (bool w
vnode-resolution = LDPR_PREVAILING_DEF_IRONLY;
}
update_visibility_by_resolution_info (vnode);
+
+ /* Update virutal tables to point to local aliases where possible. */
s/virutal/virtual
Martin
+ if (DECL_VIRTUAL_P (vnode-decl)
+ !DECL_EXTERNAL (vnode-decl))
+ {
+ int i;
+ struct ipa_ref *ref;
+ bool found = false;
+
+ /* See if there is something to update. */
+ for (i = 0; ipa_ref_list_referring_iterate (vnode-ref_list,
+ i, ref); i++)
+ if (ref-use == IPA_REF_ADDR
+can_replace_by_local_alias_in_vtable (ref-referred))
+ {
+ found = true;
+ break;
+ }
+ if (found)
+ {
+ struct pointer_set_t *visited_nodes = pointer_set_create ();
+ walk_tree (DECL_INITIAL (vnode-decl),
+update_vtable_references, NULL, visited_nodes);
+ pointer_set_destroy (visited_nodes);
+ ipa_remove_all_references (vnode-ref_list);
+ record_references_in_initializer (vnode-decl, false);
+ }
+ }
}
if (dump_file)
Re: [C++ Patch] PR 43453
... the below should be better, handles correctly cv-qualifiers.
Thanks,
Paolo.
Index: cp/typeck.c
===
--- cp/typeck.c (revision 210928)
+++ cp/typeck.c (working copy)
@@ -7502,6 +7502,18 @@ cp_build_modify_expr (tree lhs, enum tree_code mod
return error_mark_node;
}
+ /* C++11 8.5/17: If the destination type is an array of characters,
+an array of char16_t, an array of char32_t, or an array of wchar_t,
+and the initializer is a string literal */
+ else if (TREE_CODE (newrhs) == STRING_CST
+ char_type_p (TREE_TYPE (TYPE_MAIN_VARIANT (lhstype)))
+ modifycode == INIT_EXPR)
+ {
+ newrhs = digest_init (lhstype, newrhs, complain);
+ if (newrhs == error_mark_node)
+ return error_mark_node;
+ }
+
else if (!same_or_base_type_p (TYPE_MAIN_VARIANT (lhstype),
TYPE_MAIN_VARIANT (TREE_TYPE (newrhs
{
Index: cp/typeck2.c
===
--- cp/typeck2.c(revision 210928)
+++ cp/typeck2.c(working copy)
@@ -786,7 +786,12 @@ store_init_value (tree decl, tree init, vectree,
gcc_assert (TREE_CODE (decl) != RESULT_DECL);
if (TREE_CODE (init) == TREE_LIST
- TREE_CODE (TREE_TYPE (decl)) == ARRAY_TYPE)
+ TREE_CODE (type) == ARRAY_TYPE
+ /* C++11 8.5/17: If the destination type is an array of characters,
+an array of char16_t, an array of char32_t, or an array of wchar_t,
+and the initializer is a string literal */
+ !(char_type_p (TREE_TYPE (TYPE_MAIN_VARIANT (type)))
+ TREE_CODE (TREE_VALUE (init)) == STRING_CST))
{
error (cannot initialize arrays using this syntax);
return NULL_TREE;
Index: testsuite/g++.dg/init/pr43453.C
===
--- testsuite/g++.dg/init/pr43453.C (revision 0)
+++ testsuite/g++.dg/init/pr43453.C (working copy)
@@ -0,0 +1,29 @@
+// PR c++/43453
+
+struct A {
+ char x[4];
+ A() : x(bug) { };
+};
+
+char x [4] (bug);
+
+struct CA {
+ const char cx[4];
+ CA() : cx(bug) { };
+};
+
+const char cx [4] (bug);
+
+struct B {
+ char y[4];
+ B() : y(bu) { };
+};
+
+char y [4] (bu);
+
+struct C {
+ char z[4];
+ C() : z(bugs) { }; // { dg-error too long }
+};
+
+char z [4] (bugs);// { dg-error too long }
[PATCH] Support asan-instrumentation-with-call-threshold in GCC
Hi all,
This patch adds support for outline Asan instrumentation (i.e. function
calls instead of inline checks). This has been recently added to LLVM to
* reduce long compiler runtimes on large functions with huge (over 10K)
number of memory accesses (http://llvm.org/bugs/show_bug.cgi?id=12653)
* a step to full Kasan support in GCC
* reduce code size overhead
Implementation is a bit different from LLVM: GCC starts generating
function calls after overflowing the threshold whereas LLVM replaces all
instrumentations once total number is estimated to be larger than
treshold. Making implementations more similar would require bigger
rewrite of Asan which I would prefer to avoid.
The patch consists of two parts:
* asan_negative_params_1.diff - support for negative parameters
* asan_calls_1.diff - the proper
Bootstrapped/regtested on x64.
-Y
2014-04-26 Yury Gribov y.gri...@samsung.com
gcc/
* config/s390/s390.c (s390_option_override): Rename function.
* config/sh/sh.c: Likewise.
* opts-common.c (unsigned_integral_argument): New function.
(integral_argument): Add support for signed values.
(decode_cmdline_option): Rename function.
* opts.c (default_options_optimization): Rename function.
(handle_param): Allow signed --param values.
(set_debug_level): Rename function.
* opts.h: Update prototypes.
* params.c (set_param_value): Remove check for unsigned.
* params.h (INVALID_PARAM_VAL): Remove macro.
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 417e2a8..4e184d5 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -11853,7 +11853,7 @@ s390_option_override (void)
{
int val;
- val = integral_argument (opt-arg);
+ val = unsigned_integral_argument (opt-arg);
if (val == -1)
{
/* argument is not a plain number */
diff --git a/gcc/config/sh/sh.c b/gcc/config/sh/sh.c
index a0c4628..7565953 100644
--- a/gcc/config/sh/sh.c
+++ b/gcc/config/sh/sh.c
@@ -710,7 +710,7 @@ got_mode_name:;
else if (tokens[i].find (gbr-offset=) == 0)
{
std::string offset_str = tokens[i].substr (strlen (gbr-offset=));
- ret.tcb_gbr_offset = integral_argument (offset_str.c_str ());
+ ret.tcb_gbr_offset = unsigned_integral_argument (offset_str.c_str ());
if (offset_str.empty () || ret.tcb_gbr_offset == -1)
err_ret (could not parse gbr-offset value \%s\ in atomic model
option, offset_str.c_str ());
diff --git a/gcc/opts-common.c b/gcc/opts-common.c
index 007a546..737c66b 100644
--- a/gcc/opts-common.c
+++ b/gcc/opts-common.c
@@ -151,10 +151,27 @@ find_opt (const char *input, unsigned int lang_mask)
value, otherwise return -1. */
int
-integral_argument (const char *arg)
+unsigned_integral_argument (const char *arg)
+{
+ int error;
+ int val = integral_argument(arg, error);
+ return error || val 0 ? -1 : val;
+}
+
+/* If ARG is a decimal or hexadecimal integer, return its
+ value, otherwise return -1 and set ERROR. */
+
+int
+integral_argument (const char *arg, int *error)
{
const char *p = arg;
+ if (error)
+*error = 0;
+
+ if (*p == '-')
+p++;
+
while (*p ISDIGIT (*p))
p++;
@@ -162,16 +179,29 @@ integral_argument (const char *arg)
return atoi (arg);
/* It wasn't a decimal number - try hexadecimal. */
- if (arg[0] == '0' (arg[1] == 'x' || arg[1] == 'X'))
+
+ p = arg;
+
+ if (*p == '-')
+p++;
+
+ if (p[0] == '0' (p[1] == 'x' || p[1] == 'X'))
{
- p = arg + 2;
- while (*p ISXDIGIT (*p))
- p++;
+ int has_digits = 0;
+
+ p += 2;
+
+ while (*p ISXDIGIT (*p)) {
+ has_digits = 1;
+ p++;
+ }
- if (p != arg + 2 *p == '\0')
+ if (has_digits *p == '\0')
return strtol (arg, NULL, 16);
}
+ if (error)
+*error = 1;
return -1;
}
@@ -610,7 +640,7 @@ decode_cmdline_option (const char **argv, unsigned int lang_mask,
/* If the switch takes an integer, convert it. */
if (arg option-cl_uinteger)
{
- value = integral_argument (arg);
+ value = unsigned_integral_argument (arg);
if (value == -1)
errors |= CL_ERR_UINT_ARG;
}
diff --git a/gcc/opts.c b/gcc/opts.c
index 2f4f913..7687271 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -551,7 +551,7 @@ default_options_optimization (struct gcc_options *opts,
}
else
{
- const int optimize_val = integral_argument (opt-arg);
+ const int optimize_val = unsigned_integral_argument (opt-arg);
if (optimize_val == -1)
error_at (loc, argument to %-O% should be a non-negative
integer, %g%, %s% or %fast%);
@@ -1932,8 +1932,9 @@ handle_param (struct gcc_options *opts, struct gcc_options *opts_set,
arg);
else
{
- value = integral_argument (equal + 1);
- if (value == -1)
+ int error;
+ value = integral_argument (equal + 1, error);
+ if (error)
error_at (loc, invalid --param value %qs, equal + 1);
else
{
@@ -2077,7 +2078,7 @@ set_debug_level
Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC
Making implementations more similar would require bigger rewrite of Asan of GCC Asan
Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC
On Mon, May 26, 2014 at 07:58:17PM +0400, Yury Gribov wrote:
This patch adds support for outline Asan instrumentation (i.e.
function calls instead of inline checks). This has been recently
added to LLVM to
* reduce long compiler runtimes on large functions with huge (over
10K) number of memory accesses
(http://llvm.org/bugs/show_bug.cgi?id=12653)
* a step to full Kasan support in GCC
* reduce code size overhead
Implementation is a bit different from LLVM: GCC starts generating
function calls after overflowing the threshold whereas LLVM replaces
all instrumentations once total number is estimated to be larger
than treshold. Making implementations more similar would require
bigger rewrite of Asan which I would prefer to avoid.
The patch consists of two parts:
* asan_negative_params_1.diff - support for negative parameters
I don't like this. Why do you need it?
Negative params look like a bad idea to me. If you want to
have different values for none, all and some, then you can use
e.g. 0 as a special value and number of accesses = param
for the other one, or one can be 0, another INT_MAX, etc.,
-1, 0 and positive doesn't make things any clearer.
* asan_calls_1.diff - the proper
Note, the patch conflicts with the recently posted asan patches,
please wait until those are reviewed.
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -257,6 +257,8 @@ struct asan_mem_ref
static alloc_pool asan_mem_ref_alloc_pool;
+static int asan_num_accesses;
I don't see this variable ever changed, so don't see how the patch can
actually work.
@@ -1476,17 +1506,30 @@ build_check_stmt (location_t location, tree base,
gimple_stmt_iterator *iter,
tree shadow_type = TREE_TYPE (shadow_ptr_type);
tree uintptr_type
= build_nonstandard_integer_type (TYPE_PRECISION (TREE_TYPE (base)), 1);
- tree base_ssa = base;
+ tree base_ssa;
+ bool use_calls = asan_num_accesses
ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD;
Too long line.
@@ -1687,6 +1798,8 @@ instrument_mem_region_access (tree base, tree len,
gimple_stmt_iterator *iter,
location_t location, bool is_store)
{
+ bool use_calls = asan_num_accesses
ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD;
Likewise.
@@ -2265,6 +2386,9 @@ initialize_sanitizer_builtins (void)
tree BT_FN_VOID_PTR_PTR
= build_function_type_list (void_type_node, ptr_type_node,
ptr_type_node, NULL_TREE);
+ tree BT_FN_VOID_PTR_SIZE
+= build_function_type_list (void_type_node, ptr_type_node,
+ size_type_node, NULL_TREE);
I thought the functions use uptr arguments, aka BT_FN_VOID_PTR_PTRMODE.
Jakub
Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC
* asan_negative_params_1.diff - support for negative parameters I don't like this. Why do you need it? That's only for compatibility with LLVM. I know that's not usually considered an argument in gcc-patches but things like this would surely make developer's life harder. * asan_calls_1.diff - the proper Note, the patch conflicts with the recently posted asan patches, please wait until those are reviewed. Right, thanks for heads up. +static int asan_num_accesses; I don't see this variable ever changed, so don't see how the patch can actually work. True, I haven't run into this because test runs with -1 threshold (and this does work). Other points noted. -Y
Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags
On my side, I can see that r210901 breaks AArch64 compiler build: gcc/config/aarch64/aarch64.c: In function ‘void aarch64_elf_asm_named_section(const char*, unsigned int, tree_node*)’: gcc/config/aarch64/aarch64.c:8136: error: ‘decl_comdat_group’ was not declared in this scope This sould be fixed by adding #include cgraph.h into aarch64.c I will look into the strnlen issue. Honza
[patch,doc,avr] PR61044: Note that label defferences are not supported
This adds a note to the user manual that code with label differences is not
supported. This is because adding an offset to a stub address as generated
with gs() will in general not yield the address of the label+offset.
This actually occurs only if gs() has something to do, e.g. on devices with
more than 128KiB of flash; but I don't see any benefit from supporting the
feature on small devices -- left out all the problems caused by relaxing and
when gas resolves the label difference.
Thus, add a note that it's not available on any AVR and mark the PR as invalid.
Ok for trunk?
Johann
PR target/61044
* doc/extend.texi (Local Labels): Note that label differences are
not supported for AVR.
Index: doc/extend.texi
===
--- doc/extend.texi (revision 210936)
+++ doc/extend.texi (working copy)
@@ -373,6 +373,8 @@ goto *(foo + array[i]);
This is more friendly to code living in shared libraries, as it reduces
the number of dynamic relocations that are needed, and by consequence,
allows the data to be read-only.
+This alternative with label differences is not supported for the AVR target,
+please use the first approach for AVR programs.
The @code{foo} expressions for the same label might have different
values if the containing function is inlined or cloned. If a program
Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC
On Mon, May 26, 2014 at 08:31:39PM +0400, Yury Gribov wrote: * asan_negative_params_1.diff - support for negative parameters I don't like this. Why do you need it? That's only for compatibility with LLVM. I know that's not usually considered an argument in gcc-patches but things like this would surely make developer's life harder. llvm doesn't support --param, does it? So it is a different option anyway, if you want to tweak it in Makefiles (usually you don't), you need different cases for the two compilers, so I don't see how it would make developer's life harder. Negative values are special for all the params machinery for bounds checking of the values. Jakub
[PATCH, libbid]: Fix variable ‘Ql’ set but not used warnings
Hello!
Attached patch fixes several variable ‘Ql’ set but not used warnings
in bid128_div.c and bid64_div.c libbid sources. We can simply use
__mul_128x128_high functions when lowpart is not needed.
2014-05-26 Uros Bizjak ubiz...@gmail.com
* bid128_div.c (BID128_FUNCTION_ARG2): Remove unused variable 'Ql'.
Call __mul_128x128_high instead of __mul_128x128_full.
(TYPE0_FUNCTION_ARGTYPE1_ARGTYPE2): Ditto.
(BID128_FUNCTION_ARGTYPE1_ARG128): Ditto.
(BID128_FUNCTION_ARG128_ARGTYPE2): Ditto.
* bid64_div.c (TYPE0_FUNCTION_ARGTYPE1_ARG128): Ditto.
(TYPE0_FUNCTION_ARG128_ARGTYPE2): Ditto.
(TYPE0_FUNCTION_ARG128_ARG128): Ditto.
Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32}.
HJ, should this be fixed upstream first?
Uros.
Index: bid128_div.c
===
--- bid128_div.c(revision 210927)
+++ bid128_div.c(working copy)
@@ -36,7 +36,7 @@ extern UINT8 packed_1_zeros[];
BID128_FUNCTION_ARG2 (bid128_div, x, y)
UINT256 CA4, CA4r, P256;
- UINT128 CX, CY, T128, CQ, CR, CA, TP128, Qh, Ql, res;
+ UINT128 CX, CY, T128, CQ, CR, CA, TP128, Qh, res;
UINT64 sign_x, sign_y, T, carry64, D, Q_high, Q_low, QX, PD,
valid_y;
int_float fx, fy, f64;
@@ -239,7 +239,7 @@ if (!CA4.w[0] !CA4.w[1])
if (d5 nzeros)
nzeros = d5;
// get P*(2^M[extra_digits])/10^extra_digits
-__mul_128x128_full (Qh, Ql, CQ, reciprocals10_128[nzeros]);
+__mul_128x128_high (Qh, CQ, reciprocals10_128[nzeros]);
// now get P/10^extra_digits: shift Q_high right by M[extra_digits]-128
amount = recip_scale[nzeros];
@@ -365,7 +365,7 @@ if (!CA4.w[0] !CA4.w[1])
if (nzeros) {
// get P*(2^M[extra_digits])/10^extra_digits
- __mul_128x128_full (Qh, Ql, CQ, reciprocals10_128[nzeros]);
+ __mul_128x128_high (Qh, CQ, reciprocals10_128[nzeros]);
//now get P/10^extra_digits: shift Q_high right by M[extra_digits]-128
amount = recip_scale[nzeros];
@@ -487,7 +487,7 @@ TYPE0_FUNCTION_ARGTYPE1_ARGTYPE2 (UINT128, bid128d
UINT64, y)
UINT256 CA4, CA4r, P256;
- UINT128 CX, CY, T128, CQ, CR, CA, TP128, Qh, Ql, res;
+ UINT128 CX, CY, T128, CQ, CR, CA, TP128, Qh, res;
UINT64 sign_x, sign_y, T, carry64, D, Q_high, Q_low, QX, PD,
valid_y;
int_float fx, fy, f64;
@@ -701,7 +701,7 @@ __div_256_by_128 (CQ, CA4, CY);
if (d5 nzeros)
nzeros = d5;
// get P*(2^M[extra_digits])/10^extra_digits
- __mul_128x128_full (Qh, Ql, CQ, reciprocals10_128[nzeros]);
+ __mul_128x128_high (Qh, CQ, reciprocals10_128[nzeros]);
//__mul_128x128_to_256(P256, CQ,
reciprocals10_128[nzeros]);Qh.w[1]=P256.w[3];Qh.w[0]=P256.w[2];
// now get P/10^extra_digits: shift Q_high right by M[extra_digits]-128
@@ -829,7 +829,7 @@ __div_256_by_128 (CQ, CA4, CY);
if (nzeros) {
// get P*(2^M[extra_digits])/10^extra_digits
- __mul_128x128_full (Qh, Ql, CQ, reciprocals10_128[nzeros]);
+ __mul_128x128_high (Qh, CQ, reciprocals10_128[nzeros]);
// now get P/10^extra_digits: shift Q_high right by
M[extra_digits]-128
amount = recip_scale[nzeros];
@@ -946,7 +946,7 @@ BID_RETURN (res);
BID128_FUNCTION_ARGTYPE1_ARG128 (bid128dq_div, UINT64, x, y)
UINT256 CA4, CA4r, P256;
- UINT128 CX, CY, T128, CQ, CR, CA, TP128, Qh, Ql, res;
+ UINT128 CX, CY, T128, CQ, CR, CA, TP128, Qh, res;
UINT64 sign_x, sign_y, T, carry64, D, Q_high, Q_low, QX, valid_y,
PD;
int_float fx, fy, f64;
@@ -1155,7 +1155,7 @@ __div_256_by_128 (CQ, CA4, CY);
if (d5 nzeros)
nzeros = d5;
// get P*(2^M[extra_digits])/10^extra_digits
- __mul_128x128_full (Qh, Ql, CQ, reciprocals10_128[nzeros]);
+ __mul_128x128_high (Qh, CQ, reciprocals10_128[nzeros]);
//__mul_128x128_to_256(P256, CQ,
reciprocals10_128[nzeros]);Qh.w[1]=P256.w[3];Qh.w[0]=P256.w[2];
// now get P/10^extra_digits: shift Q_high right by M[extra_digits]-128
@@ -1285,7 +1285,7 @@ __div_256_by_128 (CQ, CA4, CY);
if (nzeros) {
// get P*(2^M[extra_digits])/10^extra_digits
- __mul_128x128_full (Qh, Ql, CQ, reciprocals10_128[nzeros]);
+ __mul_128x128_high (Qh, CQ, reciprocals10_128[nzeros]);
// now get P/10^extra_digits: shift Q_high right by
M[extra_digits]-128
amount = recip_scale[nzeros];
@@ -1403,7 +1403,7 @@ BID_RETURN (res);
BID128_FUNCTION_ARG128_ARGTYPE2 (bid128qd_div, x, UINT64, y)
UINT256 CA4, CA4r, P256;
- UINT128 CX, CY, T128, CQ, CR, CA, TP128, Qh, Ql, res;
+ UINT128 CX, CY, T128, CQ, CR, CA, TP128, Qh, res;
UINT64 sign_x, sign_y, T, carry64, D, Q_high, Q_low, QX, PD,
valid_y;
int_float fx, fy, f64;
@@ -1607,7 +1607,7 @@ __div_256_by_128 (CQ, CA4, CY);
if (d5 nzeros)
nzeros = d5;
// get
[PATCH, i386]: Fix logical 'not' error in x86_rtx_costs (PR 61271)
Hello!
There is a stray ! in ix86_rtx_costs which results in an invalid
bypass for LABEL_REFs. After some simplifications, the fixed condition
should read:
else if (flag_pic SYMBOLIC_CONST (x)
!(TARGET_64BIT
(GET_CODE (x) == LABEL_REF
|| (GET_CODE (x) == SYMBOL_REF
SYMBOL_REF_LOCAL_P (x)
*total = 1;
The patch fixes the condition, but I don't think that handling of
LABEL_REFs and SYMBOL_REFs is correct in the cost function at all.
E.g. in x86_64_immediate_operand predicate, LABEL_REFs (and non-TLS
SYMBOL_REFs) are rejected for all PIC code models, so they get cost of
3 and don't even reach this part of the function.
Honza, can you perhaps check if x86_64{,_zext}_immediate operand
handles PIC code models in a correct way?
The trivial patch is bootstrapped and regression tested on
x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: i386.c
===
--- i386.c (revision 210937)
+++ i386.c (working copy)
@@ -37903,10 +37903,10 @@ ix86_rtx_costs (rtx x, int code_i, int outer_code_
else if (TARGET_64BIT !x86_64_zext_immediate_operand (x, VOIDmode))
*total = 2;
else if (flag_pic SYMBOLIC_CONST (x)
- !(TARGET_64BIT
-(GET_CODE (x) == LABEL_REF
- || (GET_CODE (x) == SYMBOL_REF
-SYMBOL_REF_LOCAL_P (x)
+ (!TARGET_64BIT
+ || (!GET_CODE (x) != LABEL_REF
+ (GET_CODE (x) != SYMBOL_REF
+ || !SYMBOL_REF_LOCAL_P (x)
*total = 1;
else
*total = 0;
Re: [PATCH, i386]: Fix logical 'not' error in x86_rtx_costs (PR 61271)
On Mon, May 26, 2014 at 7:48 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
There is a stray ! in ix86_rtx_costs which results in an invalid
bypass for LABEL_REFs. After some simplifications, the fixed condition
should read:
else if (flag_pic SYMBOLIC_CONST (x)
!(TARGET_64BIT
(GET_CODE (x) == LABEL_REF
|| (GET_CODE (x) == SYMBOL_REF
SYMBOL_REF_LOCAL_P (x)
*total = 1;
The patch fixes the condition, but I don't think that handling of
LABEL_REFs and SYMBOL_REFs is correct in the cost function at all.
E.g. in x86_64_immediate_operand predicate, LABEL_REFs (and non-TLS
SYMBOL_REFs) are rejected for all PIC code models, so they get cost of
3 and don't even reach this part of the function.
Honza, can you perhaps check if x86_64{,_zext}_immediate operand
handles PIC code models in a correct way?
The trivial patch is bootstrapped and regression tested on
x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Eh, wrong patch was attached. And ChangeLog was missing, too.
2014-05-26 Uros Bizjak ubiz...@gmail.com
PR target/61271
* config/i386/i386.c (ix86_rtx_costs)
case CONST_INT, case CONST, case LABEL_REF, case SYMBOL_REF:
Fix condition.
Uros.
Index: i386.c
===
--- i386.c (revision 210889)
+++ i386.c (working copy)
@@ -37903,10 +37903,10 @@
else if (TARGET_64BIT !x86_64_zext_immediate_operand (x, VOIDmode))
*total = 2;
else if (flag_pic SYMBOLIC_CONST (x)
- (!TARGET_64BIT
- || (!GET_CODE (x) != LABEL_REF
- (GET_CODE (x) != SYMBOL_REF
- || !SYMBOL_REF_LOCAL_P (x)
+ !(TARGET_64BIT
+(GET_CODE (x) == LABEL_REF
+ || (GET_CODE (x) == SYMBOL_REF
+SYMBOL_REF_LOCAL_P (x)
*total = 1;
else
*total = 0;
Re: [patch i386]: Expand sibling-tail-calls via accumulator register
Hi,
adjusted patch to make it more bullet-proved and tested it.
2014-05-26 Kai Tietz kti...@redhat.com
* config/i386/i386.c (ix86_expand_call): Enforce for sibcalls
on memory the use of accumulator-register.
(ix86_function_ok_for_sibcall): Reject for x86_64 ABI sibling
calls for varardic-functions.
Regression tested for x86_64-unknown-linux-gnu, x86_64-w64-mingw32, and
i686-pc-cygwin.
Ok for apply?
Regards,
Kai
Index: i386.c
===
--- i386.c (revision 210936)
+++ i386.c (working copy)
@@ -5298,6 +5298,12 @@ ix86_function_ok_for_sibcall (tree decl, tree exp)
decl_or_type = type;
}
+ /* We need to reject stdarg-function for x86_64 ABI as accumulator
+ is used as argument. */
+ if (TARGET_64BIT stdarg_p (type)
+ ix86_function_type_abi (type) == SYSV_ABI)
+return false;
+
/* Check that the return value locations are the same. Like
if we are returning floats on the 80387 register stack, we cannot
make a sibcall from a function that doesn't return a float to a
@@ -24916,8 +24922,19 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx call
? !sibcall_insn_operand (XEXP (fnaddr, 0), word_mode)
: !call_insn_operand (XEXP (fnaddr, 0), word_mode))
{
+ rtx r;
fnaddr = convert_to_mode (word_mode, XEXP (fnaddr, 0), 1);
- fnaddr = gen_rtx_MEM (QImode, copy_to_mode_reg (word_mode, fnaddr));
+ if (!sibcall)
+ r = copy_to_mode_reg (word_mode, fnaddr);
+ else
+ {
+ r = gen_rtx_REG (word_mode, AX_REG);
+ if (! general_operand (fnaddr, VOIDmode))
+ fnaddr = force_operand (fnaddr, r);
+ if (fnaddr != r)
+ emit_move_insn (r, fnaddr);
+ }
+ fnaddr = gen_rtx_MEM (QImode, r);
}
call = gen_rtx_CALL (VOIDmode, fnaddr, callarg1);
[PATCH, testsuite]: Fix lto.exp does not support ... in secondary source files warnings
Hello!
2014-05-26 Uros Bizjak ubiz...@gmail.com
* gcc.dg/lto/pr61278_1.c: Remove dg directives.
Tested on x86_64-pc-linux-gnu and committed.
Uros.
Index: ChangeLog
===
--- ChangeLog (revision 210936)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2014-05-26 Uros Bizjak ubiz...@gmail.com
+
+ * gcc.dg/lto/pr61278_1.c: Remove dg directives.
+
2014-05-26 Jerry DeLisle jvdeli...@gcc.gnu.org
PR libgfortran/55117
Index: gcc.dg/lto/pr61278_1.c
===
--- gcc.dg/lto/pr61278_1.c (revision 210936)
+++ gcc.dg/lto/pr61278_1.c (working copy)
@@ -1,6 +1,3 @@
-/* { dg-lto-do link } */
-/* { dg-lto-options { { -flto -O1 } } } */
-
extern char foo (char *);
char d;
Re: [patch i386]: Expand sibling-tail-calls via accumulator register
On Mon, May 26, 2014 at 02:20:36PM -0400, Kai Tietz wrote:
--- i386.c(revision 210936)
+++ i386.c(working copy)
@@ -5298,6 +5298,12 @@ ix86_function_ok_for_sibcall (tree decl, tree exp)
decl_or_type = type;
}
+ /* We need to reject stdarg-function for x86_64 ABI as accumulator
+ is used as argument. */
+ if (TARGET_64BIT stdarg_p (type)
+ ix86_function_type_abi (type) == SYSV_ABI)
+return false;
+
/* Check that the return value locations are the same. Like
if we are returning floats on the 80387 register stack, we cannot
make a sibcall from a function that doesn't return a float to a
@@ -24916,8 +24922,19 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx call
? !sibcall_insn_operand (XEXP (fnaddr, 0), word_mode)
: !call_insn_operand (XEXP (fnaddr, 0), word_mode))
{
+ rtx r;
fnaddr = convert_to_mode (word_mode, XEXP (fnaddr, 0), 1);
- fnaddr = gen_rtx_MEM (QImode, copy_to_mode_reg (word_mode, fnaddr));
+ if (!sibcall)
+ r = copy_to_mode_reg (word_mode, fnaddr);
+ else
+ {
+ r = gen_rtx_REG (word_mode, AX_REG);
+ if (! general_operand (fnaddr, VOIDmode))
+ fnaddr = force_operand (fnaddr, r);
Wrong formatting.
+ if (fnaddr != r)
+ emit_move_insn (r, fnaddr);
+ }
+ fnaddr = gen_rtx_MEM (QImode, r);
}
call = gen_rtx_CALL (VOIDmode, fnaddr, callarg1);
In any case, I still can't understand how limiting the choices of the
register allocator can improve code rather than making it worse.
If the accumulator is available there, why doesn't the RA choose it
if it is beneficial? And why aren't other registers similarly suitable for
that? Say r10, r11...
Jakub
[PATCH, testsuite]: Fix c-c++-common/cilk-plus/AN/pr61191.c dg-error directives.
Hello!
2014-05-26 Uros Bizjak ubiz...@gmail.com
* c-c++-common/cilk-plus/AN/pr61191.c: Fix dg-error directives.
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: c-c++-common/cilk-plus/AN/pr61191.c
===
--- c-c++-common/cilk-plus/AN/pr61191.c (revision 210936)
+++ c-c++-common/cilk-plus/AN/pr61191.c (working copy)
@@ -4,7 +4,7 @@
double f(double * A, double * B)
{
- return __sec_reduce_add((B[0:500])(;
-/* { dg-error expected expression before ';' token {target *-*-*} 7 } */
-/* { dg-error called object {target *-*-*} 7 } */
-} /* { dg-error expected } */
+ return __sec_reduce_add((B[0:500])(; /* { dg-error called object {
target c } } */
+/* { dg-error expected expression before ';' token { target c } 7 } */
+/* { dg-error expected primary-expression before ';' token { target c++ }
7 } */
+} /* { dg-error expected { target c } } */
Make sure that all insn codes are in (0, LAST_INSN_CODE)
The patches I posted to cache recog_op_alt and the set of enabled
alternatives both relied on having an array of LAST_INSN_CODE elements.
It turns out that LAST_INSN_CODE is only 1+ the last _named_ insn,
rather than 1+ the last used insn code.
The only users of LAST_INSN_CODE I can see are LRA, which also uses it
for a per-insn-code cache, and tree-vect-stmts.c, which uses it as a
code that no insn can have. In both cases I think we want LAST_INSN_CODE
to account for unnamed insns too.
Tested on x86_64-linux-gnu. OK to install?
Richard
gcc/
* gencodes.c (main): Make LAST_INSN_CODE higher than any insn code,
rather than any named insn's code.
Index: gcc/gencodes.c
===
--- gcc/gencodes.c 2014-05-25 14:07:53.024841792 +0100
+++ gcc/gencodes.c 2014-05-25 14:17:28.905958781 +0100
@@ -50,6 +50,7 @@ gen_insn (rtx insn, int code)
main (int argc, char **argv)
{
rtx desc;
+ int last = 1;
progname = gencodes;
@@ -82,13 +83,16 @@ enum insn_code {\n\
break;
if (GET_CODE (desc) == DEFINE_INSN || GET_CODE (desc) == DEFINE_EXPAND)
- gen_insn (desc, insn_code_number);
+ {
+ gen_insn (desc, insn_code_number);
+ last = insn_code_number + 1;
+ }
}
- puts ( LAST_INSN_CODE\n\
+ printf ( LAST_INSN_CODE = %d\n\
};\n\
\n\
-#endif /* GCC_INSN_CODES_H */);
+#endif /* GCC_INSN_CODES_H */, last);
if (ferror (stdout) || fflush (stdout) || fclose (stdout))
return FATAL_EXIT_CODE;
[PATCH] Warn on and fold NULL checks against inline functions
Hi,
This patch teaches the C++ frontend to warn on NULL checks against
inline functions and it teaches the middle-end to fold NULL checks
against inline functions. These two things are currently done for
non-inline C++ functions, but inline functions are exceptional in that
the C++ frontend marks them as weak, and NULL checks against weak
symbols cannot be folded in general because the symbol may be mapped to
NULL at link-time.
But in the case of an inline function, the fact that it's a weak symbol
is an implementation detail. And because it is not permitted to
explicitly give an inline function the weak attribute (see
handle_weak_attribute), in order to acheive $SUBJECT it suffices to
assume that all inline functions are non-null, which is what this patch
does.
Bootstrap and regtest against x86_64-unknown-linux-gnu in progress. Is
this patch OK assuming no regressions?
2014-05-26 Patrick Palka patr...@parcs.ath.cx
* c-family/c-common.c (decl_with_nonnull_addr_p): Assume inline
functions are non-null.
* fold-const.c (tree_single_nonzero_warnv_p): Likewise.
---
gcc/c-family/c-common.c | 4 +++-
gcc/fold-const.c| 5 -
gcc/testsuite/g++.dg/inline-1.C | 14 ++
3 files changed, 21 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/inline-1.C
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 6ec14fc..d4747a0 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -4508,7 +4508,9 @@ decl_with_nonnull_addr_p (const_tree expr)
return (DECL_P (expr)
(TREE_CODE (expr) == PARM_DECL
|| TREE_CODE (expr) == LABEL_DECL
- || !DECL_WEAK (expr)));
+ || !DECL_WEAK (expr)
+ || (TREE_CODE (expr) == FUNCTION_DECL
+ DECL_DECLARED_INLINE_P (expr;
}
/* Prepare expr to be an argument of a TRUTH_NOT_EXPR,
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 188b179..2796079 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -16052,7 +16052,10 @@ tree_single_nonzero_warnv_p (tree t, bool
*strict_overflow_p)
|| (DECL_CONTEXT (base)
TREE_CODE (DECL_CONTEXT (base)) == FUNCTION_DECL
auto_var_in_fn_p (base, DECL_CONTEXT (base)
- return !VAR_OR_FUNCTION_DECL_P (base) || !DECL_WEAK (base);
+ return !VAR_OR_FUNCTION_DECL_P (base)
+|| !DECL_WEAK (base)
+|| (TREE_CODE (base) == FUNCTION_DECL
+ DECL_DECLARED_INLINE_P (base));
/* Constants are never weak. */
if (CONSTANT_CLASS_P (base))
diff --git a/gcc/testsuite/g++.dg/inline-1.C b/gcc/testsuite/g++.dg/inline-1.C
new file mode 100644
index 000..65beff1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/inline-1.C
@@ -0,0 +1,14 @@
+// { dg-options -Waddress }
+
+inline void
+foo (void)
+{
+}
+
+int
+bar (void)
+{
+ return foo == 0; // { dg-warning never be NULL }
+}
+
+// { dg-final { scan-assembler-not foo } }
--
2.0.0.rc2
[Patch, Fortran, committed] Fix broken link in gfortran.texi
Committed as Rev. 210946.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 210945)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2014-05-26 Tobias Burnus bur...@net-b.de
+
+ * gfortran.texi (Project Status): Fix broken link.
+
2014-05-26 Janne Blomqvist j...@gcc.gnu.org
PR libfortran/61310
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi (Revision 210945)
+++ gcc/fortran/gfortran.texi (Arbeitskopie)
@@ -488,8 +488,7 @@
@uref{http://www.netlib.org/benchmark/livermore,
Livermore Fortran Kernels test}. It has been used to compile a number of
large real-world programs, including
-@uref{http://mysite.verizon.net/serveall/moene.pdf, the HIRLAM
-weather-forecasting code} and
+@uref{http://hirlam.org/, the HARMONIE and HIRLAM weather forecasting code} and
@uref{http://physical-chemistry.scb.uwa.edu.au/tonto/wiki/index.php/Main_Page,
the Tonto quantum chemistry package}; see
@url{https://gcc.gnu.org/@/wiki/@/GfortranApps} for an extended list.
Re: aarch64 build broken
Hi Jan,
r210901 | hubicka | 2014-05-25 00:00:14 +0200 (So, 25. Mai 2014)
this checkin broke the aarch64 build:
./../gcc-trunk/gcc/config/aarch64/aarch64.c: In function ‘void
aarch64_elf_asm_named_section(const char*, unsigned int, tree)’:
../../gcc-trunk/gcc/tree.h:2326:26: error: ‘decl_comdat_group’ was not
declared in this scope
decl_comdat_group (NODE)
^
../../gcc-trunk/gcc/tree.h:226:15: note: in definition of macro ‘TREE_CHECK’
(tree_check ((T), __FILE__, __LINE__, __FUNCTION__, (CODE)))
^
../../gcc-trunk/gcc/tree.h:925:19: note: in expansion of macro
‘IDENTIFIER_NODE_CHECK’
((const char *) IDENTIFIER_NODE_CHECK (NODE)-identifier.id.str)
^
../../gcc-trunk/gcc/config/aarch64/aarch64.c:8136:8: note: in expansion of
macro ‘IDENTIFIER_POINTER’
IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
^
../../gcc-trunk/gcc/config/aarch64/aarch64.c:8136:28: note: in expansion of
macro ‘DECL_COMDAT_GROUP’
IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
Hi,
the problem is that decl_comdat_group used by DECL_COMDAT_GROUP macro is
defined in cgraph.h that is not inlined. This patch moves is offline making
tree.h self contained.
Does it solve the pbootstrap problem?
Honza
Index: cgraph.h
===
--- cgraph.h(revision 210908)
+++ cgraph.h(working copy)
@@ -1621,14 +1621,4 @@ symtab_in_same_comdat_p (symtab_node *on
return one-get_comdat_group () == two-get_comdat_group ();
}
-
-/* Return comdat group of DECL. */
-static inline tree
-decl_comdat_group (tree node)
-{
- struct symtab_node *snode = symtab_get_node (node);
- if (!snode)
-return NULL;
- return snode-get_comdat_group ();
-}
#endif /* GCC_CGRAPH_H */
Index: tree.h
===
--- tree.h (revision 210908)
+++ tree.h (working copy)
@@ -3431,6 +3434,7 @@ tree_operand_check_code (const_tree __t,
|| ((NODE) TREE_TYPE ((NODE)) == error_mark_node))
extern tree decl_assembler_name (tree);
+extern tree decl_comdat_group (tree);
/* Compute the number of bytes occupied by 'node'. This routine only
looks at TREE_CODE and, if the code is TREE_VEC, TREE_VEC_LENGTH. */
Index: tree.c
===
--- tree.c (revision 210908)
+++ tree.c (working copy)
@@ -603,6 +603,16 @@ decl_assembler_name (tree decl)
return DECL_WITH_VIS_CHECK (decl)-decl_with_vis.assembler_name;
}
+/* Return comdat group of DECL. */
+tree
+decl_comdat_group (tree node)
+{
+ struct symtab_node *snode = symtab_get_node (node);
+ if (!snode)
+return NULL;
+ return snode-get_comdat_group ();
+}
+
/* Compute the number of bytes occupied by a tree with code CODE.
This function cannot be used for nodes that have variable sizes,
including TREE_VEC, INTEGER_CST, STRING_CST, and CALL_EXPR. */
Require '%' to be at the beginning of a constraint string
Jeff Law l...@redhat.com writes:
On 05/20/14 02:19, Richard Sandiford wrote:
On the subject of commutativity, we have:
static bool
commutative_constraint_p (const char *str)
{
int curr_alt, c;
bool ignore_p;
for (ignore_p = false, curr_alt = 0;;)
{
c = *str;
if (c == '\0')
break;
str += CONSTRAINT_LEN (c, str);
if (c == '#' || !recog_data.alternative_enabled_p[curr_alt])
ignore_p = true;
else if (c == ',')
{
curr_alt++;
ignore_p = false;
}
else if (! ignore_p)
{
/* Usually `%' is the first constraint character but the
documentation does not require this. */
if (c == '%')
return true;
}
}
return false;
}
Any objections to requiring `%' to be the first constraint character?
Seems wasteful to be searching the constraint string just to support
an odd case.
If we're going to change it, then clearly the docs need to change and
ideally we'd statically check the port's constraints during the build
process to ensure they meet the tighter definition.
OK, how does this look? I built a cc1 for one target per config/
directory to (try to) check that there were no remaining cases.
This means that we will silently ignore '%'s that are embedded in the
middle of an asm constraint string, but in a way that's already true for
most places that check for commutativity. An error seems a bit extreme
when '%' is only a hint. If we want a warning, what should the option
be called? And should it be under -Wall, -Wextra, or on by default?
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
* doc/md.texi: Document that the % constraint character must
be at the beginning of the string.
* genoutput.c (validate_insn_alternatives): Check that '=',
'+' and '%' only appear at the beginning of a constraint.
* ira.c (commutative_constraint_p): Delete.
(ira_get_dup_out_num): Expect the '%' commutativity marker to be
at the start of the string.
* config/alpha/alpha.md (*movmemdi_1, *clrmemdi_1): Remove
duplicate '='s.
* config/arm/neon.md (bicdi3_neon): Likewise.
* config/vax/vax.md (sbcdi3): Likewise.
* config/h8300/h8300.md (*cmpstz): Remove duplicate '+'.
* config/arc/arc.md (mulsi_600, mulsidi_600, umulsidi_600)
(mul64): Move '%' to beginning of constraint.
* config/arm/arm.md (*xordi3_insn): Likewise.
* config/nds32/nds32.md (addmode3, mulsi3, andsi3, iorsi3)
(xorsi3): Likewise.
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi 2014-05-26 19:47:27.560682653 +0100
+++ gcc/doc/md.texi 2014-05-26 20:08:23.808948838 +0100
@@ -1589,7 +1589,9 @@ See, for example, the @samp{mulsi3} insn
Declares the instruction to be commutative for this operand and the
following operand. This means that the compiler may interchange the
two operands if that is the cheapest way to make all operands fit the
-constraints.
+constraints. @samp{%} applies to all alternatives and must appear as
+the first character in the constraint.
+
@ifset INTERNALS
This is often used in patterns for addition instructions
that really have only two operands: the result must go in one of the
Index: gcc/genoutput.c
===
--- gcc/genoutput.c 2014-05-26 19:47:27.560682653 +0100
+++ gcc/genoutput.c 2014-05-26 20:08:23.675947636 +0100
@@ -781,6 +781,11 @@ validate_insn_alternatives (struct data
for (p = d-operand[start].constraint; (c = *p); p += len)
{
+ if ((c == '%' || c == '=' || c == '+')
+p != d-operand[start].constraint)
+ error_with_line (d-lineno,
+ character '%c' can only be used at the
+ beginning of a constraint string);
#ifdef USE_MD_CONSTRAINTS
if (ISSPACE (c) || strchr (indep_constraints, c))
len = 1;
Index: gcc/ira.c
===
--- gcc/ira.c 2014-05-26 20:10:28.988080881 +0100
+++ gcc/ira.c 2014-05-26 20:10:32.773115124 +0100
@@ -1769,38 +1769,6 @@ setup_prohibited_mode_move_regs (void)
}
-
-/* Return TRUE if the operand constraint STR is commutative. */
-static bool
-commutative_constraint_p (const char *str)
-{
- int curr_alt, c;
- bool ignore_p;
-
- for (ignore_p = false, curr_alt = 0;;)
-{
- c = *str;
- if (c == '\0')
- break;
- str += CONSTRAINT_LEN (c, str);
- if (c == '#' || !recog_data.alternative_enabled_p[curr_alt])
- ignore_p = true;
- else if (c == ',')
- {
-
Re: [patch i386]: Expand sibling-tail-calls via accumulator register
- Original Message -
On Mon, May 26, 2014 at 02:20:36PM -0400, Kai Tietz wrote:
--- i386.c (revision 210936)
+++ i386.c (working copy)
@@ -5298,6 +5298,12 @@ ix86_function_ok_for_sibcall (tree decl, tree exp)
decl_or_type = type;
}
+ /* We need to reject stdarg-function for x86_64 ABI as accumulator
+ is used as argument. */
+ if (TARGET_64BIT stdarg_p (type)
+ ix86_function_type_abi (type) == SYSV_ABI)
+return false;
+
/* Check that the return value locations are the same. Like
if we are returning floats on the 80387 register stack, we cannot
make a sibcall from a function that doesn't return a float to a
@@ -24916,8 +24922,19 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx call
? !sibcall_insn_operand (XEXP (fnaddr, 0), word_mode)
: !call_insn_operand (XEXP (fnaddr, 0), word_mode))
{
+ rtx r;
fnaddr = convert_to_mode (word_mode, XEXP (fnaddr, 0), 1);
- fnaddr = gen_rtx_MEM (QImode, copy_to_mode_reg (word_mode, fnaddr));
+ if (!sibcall)
+ r = copy_to_mode_reg (word_mode, fnaddr);
+ else
+ {
+ r = gen_rtx_REG (word_mode, AX_REG);
+ if (! general_operand (fnaddr, VOIDmode))
+ fnaddr = force_operand (fnaddr, r);
Wrong formatting.
Thanks for the heads up. Fix the superflous tab.
+ if (fnaddr != r)
+ emit_move_insn (r, fnaddr);
+ }
+ fnaddr = gen_rtx_MEM (QImode, r);
}
call = gen_rtx_CALL (VOIDmode, fnaddr, callarg1);
In any case, I still can't understand how limiting the choices of the
register allocator can improve code rather than making it worse.
If the accumulator is available there, why doesn't the RA choose it
if it is beneficial? And why aren't other registers similarly suitable for
that? Say r10, r11...
I don't see it as limiting. The intend of this is more to have fixed patterns
on epilogue. And in fact is accumulator that register which can be used as
scratch-register for all i386-targets. Beside for varardic-functions, which
anyway aren't any good candidates for sibling-call-optimization (on x86_64 due
ABI).
Well, for x86_64 ABI we might could consider to use R11_REG instead of AX_REG.
Is there any advantage in special-case for x86_64 ABI?
The R10-register isn't a good choice due it might be used as drap-register and
therefore can't be loaded before epilogue gets destroyed.
Jakub
Kai
RE: aarch64 build broken
Hi Jan,
looks good. Thanks!
Bernd
On Mon, 26 May 2014 21:07:28 +0200, Jan Hubicka wrote:
From: hubi...@ucw.cz
To: bernd.edlin...@hotmail.de
CC: hubi...@ucw.cz; gcc-patches@gcc.gnu.org
Subject: Re: aarch64 build broken
Hi Jan,
r210901 | hubicka | 2014-05-25 00:00:14 +0200 (So, 25. Mai 2014)
this checkin broke the aarch64 build:
./../gcc-trunk/gcc/config/aarch64/aarch64.c: In function ‘void
aarch64_elf_asm_named_section(const char*, unsigned int, tree)’:
../../gcc-trunk/gcc/tree.h:2326:26: error: ‘decl_comdat_group’ was not
declared in this scope
decl_comdat_group (NODE)
^
../../gcc-trunk/gcc/tree.h:226:15: note: in definition of macro ‘TREE_CHECK’
(tree_check ((T), __FILE__, __LINE__, __FUNCTION__, (CODE)))
^
../../gcc-trunk/gcc/tree.h:925:19: note: in expansion of macro
‘IDENTIFIER_NODE_CHECK’
((const char *) IDENTIFIER_NODE_CHECK (NODE)-identifier.id.str)
^
../../gcc-trunk/gcc/config/aarch64/aarch64.c:8136:8: note: in expansion of
macro ‘IDENTIFIER_POINTER’
IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
^
../../gcc-trunk/gcc/config/aarch64/aarch64.c:8136:28: note: in expansion of
macro ‘DECL_COMDAT_GROUP’
IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
Hi,
the problem is that decl_comdat_group used by DECL_COMDAT_GROUP macro is
defined in cgraph.h that is not inlined. This patch moves is offline making
tree.h self contained.
Does it solve the pbootstrap problem?
Honza
Index: cgraph.h
===
--- cgraph.h (revision 210908)
+++ cgraph.h (working copy)
@@ -1621,14 +1621,4 @@ symtab_in_same_comdat_p (symtab_node *on
return one-get_comdat_group () == two-get_comdat_group ();
}
-
-/* Return comdat group of DECL. */
-static inline tree
-decl_comdat_group (tree node)
-{
- struct symtab_node *snode = symtab_get_node (node);
- if (!snode)
- return NULL;
- return snode-get_comdat_group ();
-}
#endif /* GCC_CGRAPH_H */
Index: tree.h
===
--- tree.h (revision 210908)
+++ tree.h (working copy)
@@ -3431,6 +3434,7 @@ tree_operand_check_code (const_tree __t,
|| ((NODE) TREE_TYPE ((NODE)) == error_mark_node))
extern tree decl_assembler_name (tree);
+extern tree decl_comdat_group (tree);
/* Compute the number of bytes occupied by 'node'. This routine only
looks at TREE_CODE and, if the code is TREE_VEC, TREE_VEC_LENGTH. */
Index: tree.c
===
--- tree.c (revision 210908)
+++ tree.c (working copy)
@@ -603,6 +603,16 @@ decl_assembler_name (tree decl)
return DECL_WITH_VIS_CHECK (decl)-decl_with_vis.assembler_name;
}
+/* Return comdat group of DECL. */
+tree
+decl_comdat_group (tree node)
+{
+ struct symtab_node *snode = symtab_get_node (node);
+ if (!snode)
+ return NULL;
+ return snode-get_comdat_group ();
+}
+
/* Compute the number of bytes occupied by a tree with code CODE.
This function cannot be used for nodes that have variable sizes,
including TREE_VEC, INTEGER_CST, STRING_CST, and CALL_EXPR. */
Re: [patch i386]: Expand sibling-tail-calls via accumulator register
On Mon, May 26, 2014 at 03:22:50PM -0400, Kai Tietz wrote: In any case, I still can't understand how limiting the choices of the register allocator can improve code rather than making it worse. If the accumulator is available there, why doesn't the RA choose it if it is beneficial? And why aren't other registers similarly suitable for that? Say r10, r11... I don't see it as limiting. The intend of this is more to have fixed patterns on epilogue. And in fact is accumulator that register which can be used as scratch-register for all i386-targets. Beside for varardic-functions, which anyway aren't any good candidates for sibling-call-optimization (on x86_64 due ABI). Well, for x86_64 ABI we might could consider to use R11_REG instead of AX_REG. Is there any advantage in special-case for x86_64 ABI? The R10-register isn't a good choice due it might be used as drap-register and therefore can't be loaded before epilogue gets destroyed. It is limiting. If r11/rax and often also r10 can be chosen, telling the RA it can only choose rax is a limitation. Can you show some testcase where your patch is actually beneficial? We should analyze why the RA made that choice. Jakub
Re: [PATCH] Warn on and fold NULL checks against inline functions
On Mon, 26 May 2014, Patrick Palka wrote: This patch teaches the C++ frontend to warn on NULL checks against inline functions and it teaches the middle-end to fold NULL checks against inline functions. These two things are currently done for non-inline C++ functions, but inline functions are exceptional in that the C++ frontend marks them as weak, and NULL checks against weak symbols cannot be folded in general because the symbol may be mapped to NULL at link-time. But in the case of an inline function, the fact that it's a weak symbol is an implementation detail. And because it is not permitted to explicitly give an inline function the weak attribute (see handle_weak_attribute), in order to acheive $SUBJECT it suffices to assume that all inline functions are non-null, which is what this patch does. Thanks for working on this. You may want to mention PR 59948 in the ChangeLog. In the comments of that PR, Honza seems to have a different idea of what the fold-const test should look like. -- Marc Glisse
Re: [patch i386]: Expand sibling-tail-calls via accumulator register
- Original Message - On Mon, May 26, 2014 at 03:22:50PM -0400, Kai Tietz wrote: In any case, I still can't understand how limiting the choices of the register allocator can improve code rather than making it worse. If the accumulator is available there, why doesn't the RA choose it if it is beneficial? And why aren't other registers similarly suitable for that? Say r10, r11... I don't see it as limiting. The intend of this is more to have fixed patterns on epilogue. And in fact is accumulator that register which can be used as scratch-register for all i386-targets. Beside for varardic-functions, which anyway aren't any good candidates for sibling-call-optimization (on x86_64 due ABI). Well, for x86_64 ABI we might could consider to use R11_REG instead of AX_REG. Is there any advantage in special-case for x86_64 ABI? The R10-register isn't a good choice due it might be used as drap-register and therefore can't be loaded before epilogue gets destroyed. It is limiting. If r11/rax and often also r10 can be chosen, telling the RA it can only choose rax is a limitation. No, it isn't. For sure. The code-branch choosing the accu to call after epilogue isn't used as memories for sibling-calls aren't allowed. This code-branch will get active with my other sibling-tail-call patch. Can you show some testcase where your patch is actually beneficial? We should analyze why the RA made that choice. So it is obvious I can't provide you samples you asked for. Nevertheless I am pretty interested to see a sample by you (with activated sibling-tail-call memories) which chooses for tail-call-register for memory something else then accu. Jakub Kai
Re: [PATCH] Warn on and fold NULL checks against inline functions
On Mon, May 26, 2014 at 4:26 PM, Marc Glisse marc.gli...@inria.fr wrote: On Mon, 26 May 2014, Patrick Palka wrote: This patch teaches the C++ frontend to warn on NULL checks against inline functions and it teaches the middle-end to fold NULL checks against inline functions. These two things are currently done for non-inline C++ functions, but inline functions are exceptional in that the C++ frontend marks them as weak, and NULL checks against weak symbols cannot be folded in general because the symbol may be mapped to NULL at link-time. But in the case of an inline function, the fact that it's a weak symbol is an implementation detail. And because it is not permitted to explicitly give an inline function the weak attribute (see handle_weak_attribute), in order to acheive $SUBJECT it suffices to assume that all inline functions are non-null, which is what this patch does. Thanks for working on this. You may want to mention PR 59948 in the ChangeLog. In the comments of that PR, Honza seems to have a different idea of what the fold-const test should look like. I wonder, then, if the test in c-common.c is also broken... Thanks for the heads up about the PR.
[PATCH, libgfortran, committed] Introduce xrealloc, use it
Hi,
libgfortran has malloc and calloc wrappers, but so far the equivalent
realloc wrapper has been missing. The attached patch corrects this,
and converts existing realloc users. Committed r210948 to trunk as
obvious after regtesting on x86_64-unknown-linux-gnu.
2014-05-26 Janne Blomqvist j...@gcc.gnu.org
* libgfortran.h (xrealloc): New prototype.
* runtime/memory.c (xrealloc): New function.
* io/fbuf.c (fbuf_alloc): Use xrealloc.
* io/list_read.c (push_char_default): Likewise.
(push_char4): Likewise.
--
Janne Blomqvist
diff --git a/libgfortran/io/fbuf.c b/libgfortran/io/fbuf.c
index 170ce97..e24da62 100644
--- a/libgfortran/io/fbuf.c
+++ b/libgfortran/io/fbuf.c
@@ -121,10 +121,7 @@ fbuf_alloc (gfc_unit * u, int len)
{
/* Round up to nearest multiple of the current buffer length. */
newlen = ((u-fbuf-pos + len) / u-fbuf-len + 1) * u-fbuf-len;
- dest = realloc (u-fbuf-buf, newlen);
- if (dest == NULL)
- return NULL;
- u-fbuf-buf = dest;
+ u-fbuf-buf = xrealloc (u-fbuf-buf, newlen);
u-fbuf-len = newlen;
}
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 13e38f4..a7e4f88 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -79,7 +79,7 @@ typedef unsigned char uchar;
static void
push_char_default (st_parameter_dt *dtp, int c)
{
- char *new;
+
if (dtp-u.p.saved_string == NULL)
{
@@ -92,13 +92,11 @@ push_char_default (st_parameter_dt *dtp, int c)
if (dtp-u.p.saved_used = dtp-u.p.saved_length)
{
dtp-u.p.saved_length = 2 * dtp-u.p.saved_length;
- new = realloc (dtp-u.p.saved_string, dtp-u.p.saved_length);
- if (new == NULL)
- generate_error (dtp-common, LIBERROR_OS, NULL);
- dtp-u.p.saved_string = new;
+ dtp-u.p.saved_string =
+ xrealloc (dtp-u.p.saved_string, dtp-u.p.saved_length);
// Also this should not be necessary.
- memset (new + dtp-u.p.saved_used, 0,
+ memset (dtp-u.p.saved_string + dtp-u.p.saved_used, 0,
dtp-u.p.saved_length - dtp-u.p.saved_used);
}
@@ -126,10 +124,7 @@ push_char4 (st_parameter_dt *dtp, int c)
if (dtp-u.p.saved_used = dtp-u.p.saved_length)
{
dtp-u.p.saved_length = 2 * dtp-u.p.saved_length;
- new = realloc (p, dtp-u.p.saved_length * sizeof (gfc_char4_t));
- if (new == NULL)
- generate_error (dtp-common, LIBERROR_OS, NULL);
- p = new;
+ p = xrealloc (p, dtp-u.p.saved_length * sizeof (gfc_char4_t));
memset4 (new + dtp-u.p.saved_used, 0,
dtp-u.p.saved_length - dtp-u.p.saved_used);
diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h
index ba6c1e9..b3e8a2e 100644
--- a/libgfortran/libgfortran.h
+++ b/libgfortran/libgfortran.h
@@ -771,6 +771,8 @@ internal_proto(xmalloc);
extern void *xcalloc (size_t, size_t) __attribute__ ((malloc));
internal_proto(xcalloc);
+extern void *xrealloc (void *, size_t);
+internal_proto(xrealloc);
/* environ.c */
diff --git a/libgfortran/runtime/memory.c b/libgfortran/runtime/memory.c
index efeea86..b18b505 100644
--- a/libgfortran/runtime/memory.c
+++ b/libgfortran/runtime/memory.c
@@ -58,3 +58,17 @@ xcalloc (size_t nmemb, size_t size)
return p;
}
+
+
+void *
+xrealloc (void *ptr, size_t size)
+{
+ if (size == 0)
+size = 1;
+
+ void *newp = realloc (ptr, size);
+ if (!newp)
+os_error (Memory allocation failure in xrealloc);
+
+ return newp;
+}
Re: Make sure that all insn codes are in (0, LAST_INSN_CODE)
- puts ( LAST_INSN_CODE\n\ + printf ( LAST_INSN_CODE = %d\n\ };\n\ \n\ -#endif /* GCC_INSN_CODES_H */); +#endif /* GCC_INSN_CODES_H */, last); You probably didn't intend to delete the newline at the end of the generated file? Segher
Re: [PATCH] Warn on and fold NULL checks against inline functions
On Mon, 26 May 2014, Patrick Palka wrote: On Mon, May 26, 2014 at 4:26 PM, Marc Glisse marc.gli...@inria.fr wrote: On Mon, 26 May 2014, Patrick Palka wrote: This patch teaches the C++ frontend to warn on NULL checks against inline functions and it teaches the middle-end to fold NULL checks against inline functions. These two things are currently done for non-inline C++ functions, but inline functions are exceptional in that the C++ frontend marks them as weak, and NULL checks against weak symbols cannot be folded in general because the symbol may be mapped to NULL at link-time. But in the case of an inline function, the fact that it's a weak symbol is an implementation detail. And because it is not permitted to explicitly give an inline function the weak attribute (see handle_weak_attribute), in order to acheive $SUBJECT it suffices to assume that all inline functions are non-null, which is what this patch does. Thanks for working on this. You may want to mention PR 59948 in the ChangeLog. In the comments of that PR, Honza seems to have a different idea of what the fold-const test should look like. I wonder, then, if the test in c-common.c is also broken... Thanks for the heads up about the PR. I think I should also mention PR 61144 which says the test can be wrong in the other direction (I didn't look at it closely). But even if the tests are broken, your patch may still be an improvement while waiting for the rewrite... -- Marc Glisse
Re: another patch for PR60969
On 2014-05-25, 12:58 PM, Christophe Lyon wrote: Hi, Since this patch was committed, I can see aarch64_be-none-elf build fail in newlib with this error message: 0x8ba1fb check_rtl /tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/lra.c:2083 0x8bd5b2 lra(_IO_FILE*) /tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/lra.c:2462 0x880688 do_reload /tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/ira.c:5457 0x880978 execute /tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/ira.c:5618 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [lib_a-wcstombs.o] Error 1 Could you fill the bug and attach a preprocessed file (sorry, I have no available amr64 machine). Thanks.
Re: another patch for PR60969
On 26 May 2014 23:24, Vladimir Makarov vmaka...@redhat.com wrote: On 2014-05-25, 12:58 PM, Christophe Lyon wrote: Hi, Since this patch was committed, I can see aarch64_be-none-elf build fail in newlib with this error message: 0x8ba1fb check_rtl /tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/lra.c:2083 0x8bd5b2 lra(_IO_FILE*) /tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/lra.c:2462 0x880688 do_reload /tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/ira.c:5457 0x880978 execute /tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/ira.c:5618 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [lib_a-wcstombs.o] Error 1 Could you fill the bug and attach a preprocessed file (sorry, I have no available amr64 machine). Neither do I :-) I have filed PR61325. Christophe.
Re: [wwwdocs] Buildstat update for 4.9
On Sun, 18 May 2014, Tom G. Christensen wrote: Latest results for 4.9.x -tgc Testresults for 4.9.0: arm-unknown-linux-gnueabi hppa-unknown-linux-gnu i386-pc-solaris2.9 (2) i386-pc-solaris2.10 i386-pc-solaris2.11 i686-unknown-linux-gnu mips-unknown-linux-gnu mipsel-unknown-linux-gnu powerpc-apple-darwin8.11.0 powerpc-unknown-linux-gnu powerpc64-unknown-linux-gnu sparc-sun-solaris2.9 (2) sparc-sun-solaris2.11 sparc64-sun-solaris2.9 sparc-unknown-linux-gnu x86_64-unknown-linux-gnu (3) Thanks, Tom. I just applied this. Gerald
AIX build broken by IPA changes
Jan, The IPA patch broke bootstrap on AIX with multiple failures. The tail of the build log is attached. - David make AR_FLAGS= CC_FOR_BUILD= CC_FOR_TARGET= CFLAGS=-g -O2 CXXFLAGS=-g -O2 CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET= INSTALL=/nasfarm/edelsohn/src/src/install-sh -c INSTALL_DATA=/nasfarm/edelsohn/src/src/install-sh -c -m 644 INSTALL_PROGRAM=/nasfarm/edelsohn/src/src/install-sh -c INSTALL_SCRIPT=/nasfarm/edelsohn/src/src/install-sh -c LDFLAGS= LIBCFLAGS= LIBCFLAGS_FOR_TARGET= MAKE=make MAKEINFO=/usr/gnu/bin/bash /nasfarm/edelsohn/src/src/libstdc++-v3/../missing makeinfo SHELL=/usr/gnu/bin/bash RUNTESTFLAGS= exec_prefix=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525 infodir=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/share/info libdir=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/lib includedir=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/include prefix=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525 tooldir= gxx_include_dir=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/include/c++/4.10.0 AR=ar -X32_64 AS=/tmp/20140525/./gcc/as LD=/tmp/20140525/./gcc/collect-ld RANLIB=ranlib NM=/tmp/20140525/./gcc/nm -B -X32_64 NM_FOR_BUILD= NM_FOR_TARGET= DESTDIR= WERROR= all-recursive make[1]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3' Making all in include make[2]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include' Making all in libsupc++ make[2]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++' Making all in src make[2]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src' Making all in c++98 make[3]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/c++98' /usr/gnu/bin/bash ../../libtool --tag CXX --tag disable-shared --mode=compile /tmp/20140525/./gcc/xgcc -shared-libgcc -B/tmp/20140525/./gcc -nostdinc++ -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++/.libs -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/bin/ -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/lib/ -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/include -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/sys-include -I/nasfarm/edelsohn/src/src/libstdc++-v3/../libgcc -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0 -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include -I/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++ -I/gsa/yktgsa/home/e/d/edelsohn/install/include -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=strstream.lo -g -O2 -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/backward -Wno-deprecated -c /nasfarm/edelsohn/src/src/libstdc++-v3/src/c++98/strstream.cc libtool: compile: /tmp/20140525/./gcc/xgcc -shared-libgcc -B/tmp/20140525/./gcc -nostdinc++ -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++/.libs -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/bin/ -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/lib/ -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/include -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/sys-include -I/nasfarm/edelsohn/src/src/libstdc++-v3/../libgcc -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0 -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include -I/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++ -I/gsa/yktgsa/home/e/d/edelsohn/install/include -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=strstream.lo -g -O2 -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/backward -Wno-deprecated -c /nasfarm/edelsohn/src/src/libstdc++-v3/src/c++98/strstream.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o strstream.o In file
Re: detecting container overflow bugs in std::vector
On Mon, May 26, 2014 at 8:19 AM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: On Mon, May 26, 2014 at 6:12 PM, Jonathan Wakely jwak...@redhat.com wrote: I see that the patch on the Google branch removes some of the __google_stl_debug_vector checks -- are they considered no longer necessary/useful with asan? This was some unrelated change. Paul? That appears to have been a merge mistake on my part. I'll add them back. Thanks for noticing. -- Paul Pluzhnikov
Re: [PATCH][4/4] Always 64bit-HWI cleanups
This patch (further) broke bootstrap on AIX. AIX defaults to 32 bit,
although it supports 64 bit HWI.
/nasfarm/edelsohn/src/src/gcc/bitmap.c: In function 'int
print_statistics(bitmap_descriptor_d**, output_info*)':
/nasfarm/edelsohn/src/src/gcc/bitmap.c:2168:24: error: expected ')'
before 'PRId64'
/nasfarm/edelsohn/src/src/gcc/bitmap.c: In function 'void
dump_bitmap_statistics()':
/nasfarm/edelsohn/src/src/gcc/bitmap.c:2202:15: error: expected ')'
before 'PRId64'
/nasfarm/edelsohn/src/src/gcc/bt-load.c: In function 'void
migrate_btr_defs(reg_class, int)':
/nasfarm/edelsohn/src/src/gcc/bt-load.c:1414:34: error: expected ')'
before 'PRId64'
/nasfarm/edelsohn/src/src/gcc/cfg.c: In function 'void
dump_edge_info(FILE*, edge, int, int)':
/nasfarm/edelsohn/src/src/gcc/cfg.c:489:25: error: expected ')' before 'PRId64'
/nasfarm/edelsohn/src/src/gcc/cfg.c: In function 'void
dump_bb_info(FILE*, basic_block, int, int, bool, bool)':
/nasfarm/edelsohn/src/src/gcc/cfg.c:737:33: error: expected ')' before 'PRId64'
bitmap.i looks like:
int
print_statistics (bitmap_descriptor_d **slot, output_info *i)
{
bitmap_descriptor d = *slot;
char s[4096];
if (d-allocated)
{
const char *s1 = d-file;
const char *s2;
while ((s2 = strstr (s1, gcc/)))
s1 = s2 + 4;
sprintf (s, %s:%i (%s), s1, d-line, d-function);
s[41] = 0;
fprintf ((_iob[2]),
%-41s %9u %15PRId64 %15PRId64 %15PRId64
%10PRId64 %10PRId64\n,
s, d-created,
d-allocated, d-peak, d-current,
d-nsearches, d-search_iter);
i-size += d-allocated;
i-count += d-created;
}
return 1;
}
- David
Re: [PATCH][4/4] Always 64bit-HWI cleanups
Sorry, I meant to refer to the 3/n patch.
Thanks, David
On Mon, May 26, 2014 at 9:58 PM, David Edelsohn dje@gmail.com wrote:
This patch (further) broke bootstrap on AIX. AIX defaults to 32 bit,
although it supports 64 bit HWI.
/nasfarm/edelsohn/src/src/gcc/bitmap.c: In function 'int
print_statistics(bitmap_descriptor_d**, output_info*)':
/nasfarm/edelsohn/src/src/gcc/bitmap.c:2168:24: error: expected ')'
before 'PRId64'
/nasfarm/edelsohn/src/src/gcc/bitmap.c: In function 'void
dump_bitmap_statistics()':
/nasfarm/edelsohn/src/src/gcc/bitmap.c:2202:15: error: expected ')'
before 'PRId64'
/nasfarm/edelsohn/src/src/gcc/bt-load.c: In function 'void
migrate_btr_defs(reg_class, int)':
/nasfarm/edelsohn/src/src/gcc/bt-load.c:1414:34: error: expected ')'
before 'PRId64'
/nasfarm/edelsohn/src/src/gcc/cfg.c: In function 'void
dump_edge_info(FILE*, edge, int, int)':
/nasfarm/edelsohn/src/src/gcc/cfg.c:489:25: error: expected ')' before
'PRId64'
/nasfarm/edelsohn/src/src/gcc/cfg.c: In function 'void
dump_bb_info(FILE*, basic_block, int, int, bool, bool)':
/nasfarm/edelsohn/src/src/gcc/cfg.c:737:33: error: expected ')' before
'PRId64'
bitmap.i looks like:
int
print_statistics (bitmap_descriptor_d **slot, output_info *i)
{
bitmap_descriptor d = *slot;
char s[4096];
if (d-allocated)
{
const char *s1 = d-file;
const char *s2;
while ((s2 = strstr (s1, gcc/)))
s1 = s2 + 4;
sprintf (s, %s:%i (%s), s1, d-line, d-function);
s[41] = 0;
fprintf ((_iob[2]),
%-41s %9u %15PRId64 %15PRId64 %15PRId64
%10PRId64 %10PRId64\n,
s, d-created,
d-allocated, d-peak, d-current,
d-nsearches, d-search_iter);
i-size += d-allocated;
i-count += d-created;
}
return 1;
}
- David
Re: libsanitizer merge from upstream r208536
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek ja...@redhat.com wrote: Doesn't look like the ppc32 port would be in any worse shape than the 64-bit one. Peter has brought a real problem, in particular the allocator now newly relying on 2 x word size atomics which is definitely non-portable, I don't see why the answer to that should be disable your port or build a buildbot. Right, the ppc32 results definitely show it's on par with the ppc64 results. On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote: Because this is my default reply to any such case. :) I hope that is a humorous reply and not a serious one. In one of my other posts, I asked should 32-bit ports even attempt to use the 2 * word_size atomics. What is the code doing such that it wants to use a 2 * word_size atomic? Is it as simple as commenting that code out for 32-bit builds of the library or do we really have to support that? Peter
Re: AIX build broken by IPA changes
Jan, The IPA patch broke bootstrap on AIX with multiple failures. The tail of the build log is attached. Thanks, I will give it a try at gcc111, good to have reproducible testcase. Honza - David make AR_FLAGS= CC_FOR_BUILD= CC_FOR_TARGET= CFLAGS=-g -O2 CXXFLAGS=-g -O2 CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET= INSTALL=/nasfarm/edelsohn/src/src/install-sh -c INSTALL_DATA=/nasfarm/edelsohn/src/src/install-sh -c -m 644 INSTALL_PROGRAM=/nasfarm/edelsohn/src/src/install-sh -c INSTALL_SCRIPT=/nasfarm/edelsohn/src/src/install-sh -c LDFLAGS= LIBCFLAGS= LIBCFLAGS_FOR_TARGET= MAKE=make MAKEINFO=/usr/gnu/bin/bash /nasfarm/edelsohn/src/src/libstdc++-v3/../missing makeinfo SHELL=/usr/gnu/bin/bash RUNTESTFLAGS= exec_prefix=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525 infodir=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/share/info libdir=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/lib includedir=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/include prefix=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525 tooldir= gxx_include_dir=/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/include/c++/4.10.0 AR=ar -X32_64 AS=/tmp/20140525/./gcc/as LD=/tmp/20140525/./gcc/collect-ld RANLIB=ranlib NM=/tmp/20140525/./gcc/nm -B -X32_64 NM_FOR_BUILD= NM_FOR_TARGET= DESTDIR= WERROR= all-recursive make[1]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3' Making all in include make[2]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include' Making all in libsupc++ make[2]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++' Making all in src make[2]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src' Making all in c++98 make[3]: Entering directory `/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/c++98' /usr/gnu/bin/bash ../../libtool --tag CXX --tag disable-shared --mode=compile /tmp/20140525/./gcc/xgcc -shared-libgcc -B/tmp/20140525/./gcc -nostdinc++ -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++/.libs -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/bin/ -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/lib/ -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/include -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/sys-include -I/nasfarm/edelsohn/src/src/libstdc++-v3/../libgcc -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0 -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include -I/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++ -I/gsa/yktgsa/home/e/d/edelsohn/install/include -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=strstream.lo -g -O2 -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/backward -Wno-deprecated -c /nasfarm/edelsohn/src/src/libstdc++-v3/src/c++98/strstream.cc libtool: compile: /tmp/20140525/./gcc/xgcc -shared-libgcc -B/tmp/20140525/./gcc -nostdinc++ -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs -L/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++/.libs -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/bin/ -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/lib/ -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/include -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20140525/powerpc-ibm-aix7.1.0.0/sys-include -I/nasfarm/edelsohn/src/src/libstdc++-v3/../libgcc -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0 -I/tmp/20140525/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include -I/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++ -I/gsa/yktgsa/home/e/d/edelsohn/install/include -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=strstream.lo -g -O2
Re: aarch64 build broken
Hi Jan, looks good. Thanks! Thanks, I have commited the change. Honza
Re: Ping #1: [patch,arm] Add GCC runtime library exceptions to files that go into libgcc
Georg-Johann Lay a...@gjlay.de writes: This is Ping #1 for https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00747.html an addendum that adds runtime library exception to two more files in the ARM backend (arm-opts.h, arm-cores.def) that are included in libgcc. Ok to apply? This is OK. Sorry, I didn't think you were waiting for another approval, it's basically the same as the last patch. Ian Am 05/10/2014 02:51 AM, schrieb Ian Lance Taylor: Georg-Johann Lay a...@jlay.de writes: This patch adds GCC Runtime Library Exception to files that go into libgcc because libgcc2.c includes tm.h and libgcc_tm.h. Most of these files contain much code, some used by libgcc, some not. Some potential users of (lib)gcc have objections that missing RLE might infect their target code. Even though I know that this is actually not the case and the FSF is fine with target code linked against libgcc, it's pointless to argue in that direction. At least this is my personal experience with advocates. I am aware that there was effort for better separation of libgcc and GCC, but obviously this separation has not yet been achieved. This this ok for trunk? And is there anything special about license changes w.r.t FSF that I have to take into account? CCed Ian so that someone from the GCC steering committee can have a look. I think this is unnecessary but fine. Thanks. Yes, I know it's not needed... yet it can increase acceptance of GCC. I opened a PR61152 for this so that it's clearer for why the Runtime Exceptions will be added: http://gcc.gnu.org/PR61152 Added two files included by arm.h I missed; is it in order to apply this, too? And is it in order to apply/backport this to the 4.9 branch? From source perspective the changes are trivial enough. Johann PR libgcc/61152 * config/arm/arm-opts.h (License): Add GCC Runtime Library Exception. * config/arm/arm-cores.def (License): Same. Index: gcc/config/arm/arm-cores.def === --- gcc/config/arm/arm-cores.def(revision 210321) +++ gcc/config/arm/arm-cores.def(working copy) @@ -14,6 +14,10 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + Under Section 7 of GPL version 3, you are granted additional + permissions described in the GCC Runtime Library Exception, version + 3.1, as published by the Free Software Foundation. + You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/. */ Index: gcc/config/arm/arm-opts.h === --- gcc/config/arm/arm-opts.h (revision 210321) +++ gcc/config/arm/arm-opts.h (working copy) @@ -13,6 +13,10 @@ or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + Under Section 7 of GPL version 3, you are granted additional + permissions described in the GCC Runtime Library Exception, version + 3.1, as published by the Free Software Foundation. + You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/. */
Re: lto-plugin: mismatch between ld's architecture and GCC's configure --host
On 05/22/2014 06:56 AM, Thomas Schwinge wrote: Hi! Now that GCC again is in development stage, and with fresh hope to have someone review this patch submission, after having let the issue rest for several months: I just re-tested the current versions. Still there are no changes for a regular build (not using the new configure options). On the other hand, configuring GCC as described in the documentation update, it is possible to use the 32-bit x86 linker for/with a x86_64 build, and get the very same GCC test results as when using a x86_64 linker. See http://news.gmane.org/find-root.php?message_id=%3C87k3hioknw.fsf%40kepler.schwinge.homeip.net%3E for the whole story. The patches looked fine to Cary, but he says they need approval by a global maintainer or build machinery maintainer. The module_srcdir patch is fine (assuming you've tested it on a Canadian cross). The Non-host system configuration for linker plugins patch is OK if you test it on a Canadian cross (unexpected bugs can pop up with Canadian crosses, so you need to test it with build != host != target, preferably with all three incompatible). I don't feel that I understand the lto-plugin code well enough to approve that patch.
Re: libsanitizer merge from upstream r208536
On Tue, May 27, 2014 at 6:25 AM, Peter Bergner berg...@vnet.ibm.com wrote: On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek ja...@redhat.com wrote: Doesn't look like the ppc32 port would be in any worse shape than the 64-bit one. Peter has brought a real problem, in particular the allocator now newly relying on 2 x word size atomics which is definitely non-portable, I don't see why the answer to that should be disable your port or build a buildbot. Right, the ppc32 results definitely show it's on par with the ppc64 results. On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote: Because this is my default reply to any such case. :) I hope that is a humorous reply and not a serious one. Not really humorous. Our position is and always was: If you are adding support for a new architecture/platform, we encourage you to set up a public build bot, otherwise we can not guarantee that we will keep your code in working conditions. https://code.google.com/p/address-sanitizer/wiki/HowToContribute In one of my other posts, I asked should 32-bit ports even attempt to use the 2 * word_size atomics. What is the code doing such that it wants to use a 2 * word_size atomic? Is it as simple as commenting that code out for 32-bit builds of the library or do we really have to support that? Frankly, I don't remember where asan can use 2 * word_size atomic. This might be some mistake in new code indeed. Do you see what function calls these atomics? --kcc Peter
Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC
my 2c
- using instrumentation via calls adds extra 1.5x-2.x slowdown
- it indeed saves code size
- in LLVM this was done mostly to overcome the compile time problem on
huge functions
- in GCC we will indeed need this for kasan
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel)
- even for kasan this is not a long term solution -- once we finalize
the kasan memory layout we'll want to inline the instrumentation. But
that may take long time to come there.
- it would be nice to have the name prefix configurable from command
line (${PREFIX}_load1 instead of __asan_load1) because kasan uses
different names already.
On Mon, May 26, 2014 at 7:58 PM, Yury Gribov y.gri...@samsung.com wrote:
Hi all,
This patch adds support for outline Asan instrumentation (i.e. function
calls instead of inline checks). This has been recently added to LLVM to
* reduce long compiler runtimes on large functions with huge (over 10K)
number of memory accesses (http://llvm.org/bugs/show_bug.cgi?id=12653)
* a step to full Kasan support in GCC
* reduce code size overhead
Implementation is a bit different from LLVM: GCC starts generating function
calls after overflowing the threshold whereas LLVM replaces all
instrumentations once total number is estimated to be larger than treshold.
Making implementations more similar would require bigger rewrite of Asan
which I would prefer to avoid.
The patch consists of two parts:
* asan_negative_params_1.diff - support for negative parameters
* asan_calls_1.diff - the proper
Bootstrapped/regtested on x64.
-Y
Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC
- using instrumentation via calls adds extra 1.5x-2.x slowdown
On x64.
- it would be nice to have the name prefix configurable from command
line (${PREFIX}_load1 instead of __asan_load1) because kasan uses
different names already.
Yeah, I noticed corresponding option in LLVM. AFAIK standard GCC
parameters infrastructure (--param) only supports integral values so
we'll need a separate flag for this feature. I'm curious, why do you
need separate names for Kasan?
-Y
Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC
On Tue, May 27, 2014 at 9:40 AM, Yury Gribov y.gri...@samsung.com wrote:
- using instrumentation via calls adds extra 1.5x-2.x slowdown
On x64.
Interesting. can you share your ARM numbers?
- it would be nice to have the name prefix configurable from command
line (${PREFIX}_load1 instead of __asan_load1) because kasan uses
different names already.
Yeah, I noticed corresponding option in LLVM. AFAIK standard GCC parameters
infrastructure (--param) only supports integral values so we'll need a
separate flag for this feature. I'm curious, why do you need separate names
for Kasan?
Well, maybe we don't. It'll just cause us a minor headache to change the names.
Dmitry?
-Y
Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC
On 05/27/2014 09:43 AM, Konstantin Serebryany wrote: - using instrumentation via calls adds extra 1.5x-2.x slowdown On x64. Interesting. can you share your ARM numbers? That wasn't an objection - I just made sure to specify the platform (x64 ABI is somewhat special).
