[committed] Rename vect_no_int_max to vect_no_int_min_max
[ was: Re: [RFC] Add check_effective_target_vect_min_max ]
On 12-08-15 12:06, Richard Biener wrote:
On Wed, 12 Aug 2015, Rainer Orth wrote:
Tom de Vries writes:
On 12/08/15 10:51, Rainer Orth wrote:
Tom de Vries writes:
This follow-up patch introduces a new effective target vect_min_max,
similar to how effective target vect_bswap is implemented.
Any comments?
Thanks,
- Tom
Add check_effective_target_vect_min_max
2015-08-12 Tom de Vries
* lib/target-supports.exp (check_effective_target_vect_min_max): New
proc.
* gcc.dg/vect/trapv-vect-reduc-4.c: Use vect_min_max effective target.
Looks good to me, but the new effective-target keyword needs documenting
in sourcebuild.texi.
Hmm, in sourcebuild.texi I found:
...
@item vect_no_int_max
Target does not support a vector max instruction on @code{int}.
...
That looks related. [ I also found a patch introducing vect_no_uint_max
here: https://gcc.gnu.org/ml/gcc-patches/2010-01/msg00152.html. ]
I'm not sure where to take it from here. Should I introduce
vect_no_int_min, and use that in combination with vect_no_int_max?
I'd say this is something for the vectorizer maintainers to decide. Richi?
I expect the above is already effectively
vect_no_int_min as well (which target would support min but not max...?).
So after double-checking that you could rename it to vect_no_int_min_max.
I found test-case vect-double-reduc-3.c, which uses vect_no_int_max for both min
and max.
Committed patch to trunk.
Thanks,
- Tom
Rename vect_no_int_max to vect_no_int_min_max
2015-08-23 Tom de Vries
* gcc.dg/vect/trapv-vect-reduc-4.c: Use vect_no_int_min_max.
* gcc.dg/vect/costmodel/i386/costmodel-vect-reduc-1char.c: Rename
vect_no_int_max to vect_no_int_min_max.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-reduc-1char.c: Same.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-reduc-1char.c: Same.
* gcc.dg/vect/no-scevccp-noreassoc-slp-reduc-7.c: Same.
* gcc.dg/vect/slp-reduc-4.c: Same.
* gcc.dg/vect/slp-reduc-5.c: Same.
* gcc.dg/vect/vect-125.c: Same.
* gcc.dg/vect/vect-13.c: Same.
* gcc.dg/vect/vect-double-reduc-3.c: Same.
* gcc.dg/vect/vect-reduc-1.c: Same.
* gcc.dg/vect/vect-reduc-1char-big-array.c: Same.
* gcc.dg/vect/vect-reduc-1char.c:Same.
* gcc.dg/vect/vect-reduc-1short.c: Same.
* gcc.dg/vect/vect-reduc-2.c: Same.
* gcc.dg/vect/wrapv-vect-reduc-2char.c: Same.
* gcc.dg/vect/wrapv-vect-reduc-2short.c: Same.
* lib/target-supports.exp: Same.
* doc/sourcebuild.texi: Rename vect_no_int_max with
vect_no_int_min_max. Update description.
---
gcc/doc/sourcebuild.texi | 4 ++--
.../vect/costmodel/i386/costmodel-vect-reduc-1char.c | 2 +-
.../vect/costmodel/ppc/costmodel-vect-reduc-1char.c | 2 +-
.../vect/costmodel/x86_64/costmodel-vect-reduc-1char.c | 2 +-
.../gcc.dg/vect/no-scevccp-noreassoc-slp-reduc-7.c | 4 ++--
gcc/testsuite/gcc.dg/vect/slp-reduc-4.c | 4 ++--
gcc/testsuite/gcc.dg/vect/slp-reduc-5.c | 4 ++--
gcc/testsuite/gcc.dg/vect/trapv-vect-reduc-4.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-125.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-13.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-double-reduc-3.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-reduc-1.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-reduc-1char-big-array.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-reduc-1char.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-reduc-1short.c| 2 +-
gcc/testsuite/gcc.dg/vect/vect-reduc-2.c | 2 +-
gcc/testsuite/gcc.dg/vect/wrapv-vect-reduc-2char.c | 2 +-
gcc/testsuite/gcc.dg/vect/wrapv-vect-reduc-2short.c | 2 +-
gcc/testsuite/lib/target-supports.exp| 16
19 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index d339d1e..7aa9c9d 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1366,8 +1366,8 @@ Target supports a vector misalign access.
@item vect_no_align
Target does not support a vector alignment mechanism.
-@item vect_no_int_max
-Target does not support a vector max instruction on @code{int}.
+@item vect_no_int_min_max
+Target does not support a vector min and max instruction on @code{int}.
@item vect_no_int_add
Target does not support a vector add instruction on @code{int}.
diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-reduc-1char.c b/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-reduc-1char.c
index 29bb6c7..ff955af 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-reduc-1char.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-reduc-1char.c
@@ -47,5 +47,5 @@ int main (void)
return 0;
}
-/* { dg-final { scan-tree-dump-times "vectorized 3 loops" 1 "vect" { xfail vect_no_int_max } } } */
+/* { dg-final {
Re: [patch,libgfortran] Handle invalid command line in EXECUTE_COMMAND_LINE
10-day *ping* for my 3 Fortran patches: - Handle invalid command line in EXECUTE_COMMAND_LINE (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00758.html) - Use libbacktrace in libgfortran (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00762.html) - Fix configure test for weakref support (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00796.html)
Re: [PATCH] Missing Skylake -march=/-mtune= option
On 2015.08.20 at 17:49 +0200, Markus Trippelsdorf wrote: > On 2015.08.13 at 12:31 +0300, Yuri Rumyantsev wrote: > > Hi All, > > > > Here is patch for adding march/mtune options for Skylake. > > http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf > > > states that BMI1 and BMI2 are not supported. Is this true for all > Skylake CPUs? According to https://software.intel.com/en-us/forums/topic/584240 this only affects Skylake Pentium/Celeron processors, that incorrectly report that BMI is present. So this is not an issue in general. -- Markus
[nvptx] fix complex args
I've committed this patch, which fixes gcc.dg/compat/struct-by-value-11
That test passes 'complex char', which is split into two char arguments. We
fail to promote the type in one place, leading to a PTX type mismatch where we
claim an 8 bit type is a 32 bit type.
nathan
2015-08-23 Nathan Sidwell
* config/nvptx/nvptx.c (walk_args_for_param): Promote arg reg
decls.
(nvptx_declare_function_name): Insert formatting tabs for
consistency.
Index: config/nvptx/nvptx.c
===
--- config/nvptx/nvptx.c (revision 227101)
+++ config/nvptx/nvptx.c (working copy)
@@ -1,4 +1,3 @@
-
/* Target code for NVPTX.
Copyright (C) 2014-2015 Free Software Foundation, Inc.
Contributed by Bernd Schmidt
@@ -413,10 +412,10 @@ walk_args_for_param (FILE *file, tree ar
i++;
if (write_copy)
fprintf (file, "\tld.param%s %%ar%d, [%%in_ar%d];\n",
- nvptx_ptx_type_from_mode (mode, false), i, i);
+ nvptx_ptx_type_from_mode (mode, true), i, i);
else
fprintf (file, "\t.reg%s %%ar%d;\n",
- nvptx_ptx_type_from_mode (mode, false), i);
+ nvptx_ptx_type_from_mode (mode, true), i);
}
}
}
@@ -546,7 +545,7 @@ nvptx_declare_function_name (FILE *file,
else if (TYPE_MODE (result_type) != VOIDmode)
{
machine_mode mode = arg_promotion (TYPE_MODE (result_type));
- fprintf (file, ".reg%s %%retval;\n",
+ fprintf (file, "\t.reg%s %%retval;\n",
nvptx_ptx_type_from_mode (mode, false));
}
@@ -618,10 +617,10 @@ nvptx_declare_function_name (FILE *file,
walk_args_for_param (file, TYPE_ARG_TYPES (fntype), DECL_ARGUMENTS (decl),
true, return_in_mem);
if (return_in_mem)
-fprintf (file, "ld.param.u%d %%ar1, [%%in_ar1];\n",
+fprintf (file, "\tld.param.u%d %%ar1, [%%in_ar1];\n",
GET_MODE_BITSIZE (Pmode));
if (stdarg_p (fntype))
-fprintf (file, "ld.param.u%d %%argp, [%%in_argp];\n",
+fprintf (file, "\tld.param.u%d %%argp, [%%in_argp];\n",
GET_MODE_BITSIZE (Pmode));
}
[libcpp/C PATCH] Handle lines encoded into several maps in linemap_position_for_loc_and_offset
linemap_position_for_loc_and_offset() tries to generate a location_t
encoding a column offset from the current location, for example, point
to a certain character inside a string. This is trivial to do when the
new location "fits within" the map of the original location. However,
it may happen that the (long) line corresponding to the original
location is encoded in several maps, thus the new location should
actually be encoded in a subsequent map from the original location.
This patch detects this case and adjusts the map correspondingly.
(This shows that the line-map representation is quite wasteful in this
case, because line-maps always start at column 0. That is, map[0]
highest location may encode up to line 8 column 80, then
map[1]->start_location starts encoding at line 8 column 0. Thus, there
are two location_t values that point to the same source location.)
No new testcase since Marek found out this when tackling PR c/66415
(https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00411.html). This
change just fixes the column number.
Bootstrapped & regtested on x86-64-linux-gnu.
OK?
libcpp/ChangeLog:
2015-08-23 Manuel López-Ibáñez
* line-map.c (linemap_position_for_loc_and_offset): Handle the
case of long lines encoded in multiple maps.
gcc/testsuite/ChangeLog:
2015-08-23 Manuel López-Ibáñez
* gcc.dg/cpp/pr66415-1.c: Test column number.
Index: gcc/testsuite/gcc.dg/cpp/pr66415-1.c
===
--- gcc/testsuite/gcc.dg/cpp/pr66415-1.c(revision 226953)
+++ gcc/testsuite/gcc.dg/cpp/pr66415-1.c(working copy)
@@ -3,7 +3,7 @@
/* { dg-options "-Wformat" } */
void
fn1 (void)
{
- __builtin_printf
("x%dxxx");
/* { dg-warning "format" } */
+ __builtin_printf
("x%dxxx");
/* { dg-warning "71:format" } */
}
Index: libcpp/line-map.c
===
--- libcpp/line-map.c (revision 226953)
+++ libcpp/line-map.c (working copy)
@@ -686,32 +686,38 @@ linemap_position_for_loc_and_offset (str
return loc;
/* We find the real location and shift it. */
loc = linemap_resolve_location (set, loc, LRK_SPELLING_LOCATION, &map);
/* The new location (loc + offset) should be higher than the first
- location encoded by MAP.
- FIXME: We used to linemap_assert_fails here and in the if below,
- but that led to PR66415. So give up for now. */
- if ((MAP_START_LOCATION (map) >= loc + offset))
+ location encoded by MAP. This can fail if the line information
+ is messed up because of line directives (see PR66415). */
+ if (MAP_START_LOCATION (map) >= loc + offset)
return loc;
+ linenum_type line = SOURCE_LINE (map, loc);
+ unsigned int column = SOURCE_COLUMN (map, loc);
+
/* If MAP is not the last line map of its set, then the new location
(loc + offset) should be less than the first location encoded by
- the next line map of the set. */
- if (map != LINEMAPS_LAST_ORDINARY_MAP (set))
-if ((loc + offset >= MAP_START_LOCATION (&map[1])))
- return loc;
+ the next line map of the set. Otherwise, we try to encode the
+ location in the next map. */
+ while (map != LINEMAPS_LAST_ORDINARY_MAP (set)
+&& loc + offset >= MAP_START_LOCATION (&map[1]))
+{
+ map = &map[1];
+ /* If the next map starts in a higher line, we cannot encode the
+location there. */
+ if (line < ORDINARY_MAP_STARTING_LINE_NUMBER (map))
+ return loc;
+}
- offset += SOURCE_COLUMN (map, loc);
- if (linemap_assert_fails
-(offset < (1u << map->column_bits)))
+ offset += column;
+ if (linemap_assert_fails (offset < (1u << map->column_bits)))
return loc;
source_location r =
-linemap_position_for_line_and_column (map,
- SOURCE_LINE (map, loc),
- offset);
+linemap_position_for_line_and_column (map, line, offset);
if (linemap_assert_fails (r <= set->highest_location)
|| linemap_assert_fails (map == linemap_lookup (set, r)))
return loc;
return r;
Re: [PATCH] config: fix AM_ICONV for in-tree libiconv
On Sat, 2015-08-22 at 18:04 +0100, Pedro Alves wrote:
> I noticed that regenerating binutils/configure or gdb/configure
> undoes the libiconv changes done here:
[snip]
> However, that commit does not include any config/iconv.m4/AM_ICONV
> change. Looks like you forgot to attach the config/iconv.m4 patch, and
> then only the regeneration bits were pushed (both binutils-gdb git
> and gcc svn)?
Looks like I forgot to repost that part of the patchset; attached.
--
Yaakov Selkowitz
Associate Software Engineer, ARM
Red Hat, Inc.
2015-07-01 Yaakov Selkowitz
config/
* iconv.m4 (AM_ICONV_LINK): Use in-tree libiconv when present.
Index: config/iconv.m4
===
--- config/iconv.m4 (revision 223875)
+++ config/iconv.m4 (working copy)
@@ -7,6 +7,7 @@
dnl the same distribution terms as the rest of that program.
dnl From Bruno Haible.
+dnl with modifications to support building with in-tree libiconv
AC_DEFUN([AM_ICONV_LINKFLAGS_BODY],
[
@@ -28,16 +29,15 @@
dnl accordingly.
AC_REQUIRE([AM_ICONV_LINKFLAGS_BODY])
- dnl Add $INCICONV to CPPFLAGS before performing the following checks,
- dnl because if the user has installed libiconv and not disabled its use
- dnl via --without-libiconv-prefix, he wants to use it. The first
- dnl AC_TRY_LINK will then fail, the second AC_TRY_LINK will succeed.
- am_save_CPPFLAGS="$CPPFLAGS"
- AC_LIB_APPENDTOVAR([CPPFLAGS], [$INCICONV])
-
AC_CACHE_CHECK(for iconv, am_cv_func_iconv, [
am_cv_func_iconv="no, consider installing GNU libiconv"
am_cv_lib_iconv=no
+dnl Add $INCICONV to CPPFLAGS before performing the first check,
+dnl because if the user has installed libiconv and not disabled its use
+dnl via --without-libiconv-prefix, he wants to use it. This first
+dnl AC_TRY_LINK will then fail, the second AC_TRY_LINK will succeed.
+am_save_CPPFLAGS="$CPPFLAGS"
+CPPFLAGS="$CPPFLAGS $INCICONV"
AC_TRY_LINK([#include
#include ],
[iconv_t cd = iconv_open("","");
@@ -44,8 +44,36 @@
iconv(cd,NULL,NULL,NULL,NULL);
iconv_close(cd);],
am_cv_func_iconv=yes)
+CPPFLAGS="$am_save_CPPFLAGS"
+
+if test "$am_cv_func_iconv" != yes && test -d ../libiconv; then
+ for _libs in .libs _libs; do
+am_save_CPPFLAGS="$CPPFLAGS"
+am_save_LIBS="$LIBS"
+CPPFLAGS="$CPPFLAGS -I../libiconv/include"
+LIBS="$LIBS ../libiconv/lib/$_libs/libiconv.a"
+AC_TRY_LINK([#include
+#include ],
+ [iconv_t cd = iconv_open("","");
+ iconv(cd,NULL,NULL,NULL,NULL);
+ iconv_close(cd);],
+ INCICONV="-I../libiconv/include"
+ LIBICONV='${top_builddir}'/../libiconv/lib/$_libs/libiconv.a
+ LTLIBICONV='${top_builddir}'/../libiconv/lib/libiconv.la
+ am_cv_lib_iconv=yes
+ am_cv_func_iconv=yes)
+CPPFLAGS="$am_save_CPPFLAGS"
+LIBS="$am_save_LIBS"
+if test "$am_cv_func_iconv" = "yes"; then
+ break
+fi
+ done
+fi
+
if test "$am_cv_func_iconv" != yes; then
+ am_save_CPPFLAGS="$CPPFLAGS"
am_save_LIBS="$LIBS"
+ CPPFLAGS="$LIBS $INCICONV"
LIBS="$LIBS $LIBICONV"
AC_TRY_LINK([#include
#include ],
@@ -54,6 +82,7 @@
iconv_close(cd);],
am_cv_lib_iconv=yes
am_cv_func_iconv=yes)
+ CPPFLAGS="$am_save_CPPFLAGS"
LIBS="$am_save_LIBS"
fi
])
@@ -61,12 +90,10 @@
AC_DEFINE(HAVE_ICONV, 1, [Define if you have the iconv() function.])
fi
if test "$am_cv_lib_iconv" = yes; then
+AC_LIB_APPENDTOVAR([CPPFLAGS], [$INCICONV])
AC_MSG_CHECKING([how to link with libiconv])
AC_MSG_RESULT([$LIBICONV])
else
-dnl If $LIBICONV didn't lead to a usable library, we don't need $INCICONV
-dnl either.
-CPPFLAGS="$am_save_CPPFLAGS"
LIBICONV=
LTLIBICONV=
fi
Re: [patch,libgfortran] Handle invalid command line in EXECUTE_COMMAND_LINE
On Fri, Aug 14, 2015 at 10:54 AM, FX wrote: > The attached patch fixes PR 62296 > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62296). The Fortran > interpretation there was a bit confused (see links to comp.lang.fortran > thread from the PR), but the consensus is that the standard makes a > difference between the command-line returning with nonzero status (which sets > EXITSTAT) and the command-line not being able to execute at all (which sets > CMDSTAT and CMDMSG). > > The attached patch recognizes this by checking the return value of system() > for magic values 126 and 127, which are used by various combinations of > shells and libc to indicate that the shell could not be executed. The > attached testcase checks that. > > Bootstrapped and regtested on x86_64-apple-darwin14. > OK to commit to trunk? > > FX > > > > PS: I’ve also taken the opportunity to rework a bit the runtime error message > issued when CMDSTAT is not present, to actually include the actual error > condition message (that which would be CMDMSG if it were present) rather than > a generic error message. > > Otherwise looks good, but strncat is C99, and we support targets which don't have a C99 libc (been there, done that..). Since in this case you're dealing with string literals rather than user input, it ought to be safe to just use plain strcat (or strlen+memcpy, if you prefer). Ok with that change. -- Janne Blomqvist
Re: [patch,libgfortran,toplevel] Use libbacktrace in libgfortran
On Fri, Aug 14, 2015 at 5:18 PM, FX wrote: >>> Use libbacktrace (instead of our own unwind-based code) to display >>> backtraces from libgfortran >>> upon error or user request. >>> >>> 1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs >>> global reviewer >>> approval) >>> 2. In gcc/fortran/config-lang.in, add libbacktrace to target_libs >>> 3. In libgfortran, we remove our own code and substitute calls to >>> libbacktrace >>> >>> Bootstrapped and regtested on x86_64-pc-linux-gnu (which has full >>> libbacktrace support) and >>> x86_64-apple-darwin14 (which has minimal libbacktrace support). OK to >>> commit to trunk? >> >> backtrace.ChangeLog is unreadable for me … > > Sending again, this time with .txt extension, hoping this makes it go through > OK. Awesome! Looks good. I only have one small bikeshed request: Can you make the output format match the existing code? (As there seems to be no GNU (or otherwise) standard how backtraces should look, in order to minimize user confusion I made the current code produce output matching gdb backtraces as close as seemed reasonable.) Ok with that change. -- Janne Blomqvist
Re: [patch,libgfortran,toplevel] Use libbacktrace in libgfortran
> Awesome! Looks good. I only have one small bikeshed request: Can you > make the output format match the existing code? Problem with that is that ad the new backtrace uses full path for file names, the one-line format easily wraps in 80 column and make the output harder to read (in my opinion). In realize this is mostly taste an very subjective, so with this nugget of extra input, I leave the final decision to you: let me know what you think best, between readability and "conformance" to GDB format. Cheers, FX
Re: [patch,libgfortran,toplevel] Use libbacktrace in libgfortran
On Sun, Aug 23, 2015 at 11:14 PM, FX wrote: > >> Awesome! Looks good. I only have one small bikeshed request: Can you >> make the output format match the existing code? > > Problem with that is that ad the new backtrace uses full path for file names, > the one-line format easily wraps in 80 column and make the output harder to > read (in my opinion). > > In realize this is mostly taste an very subjective, so with this nugget of > extra input, I leave the final decision to you: let me know what you think > best, between readability and "conformance" to GDB format. Ah, I didn't realize that. I guess you're right, it's better to split the filename:linenumber to a separate line. But still, I think it's clearer if you keep the "in" and "at" like the current code & gdb does. Thus, something like #framenumber 0xADDRESS in funcname at filename:linenumber And another thing which I previously missed: You have removed the store_exe_path function as it's no longer used for anything. However, that function is part of the libgfortran ABI and is found in gfortran.map, so we have to keep it until we bump the so version. :( Please also add a note to the libgfortran ABI cleanup wiki page so we don't forget about it. With these changes, Ok for trunk. Thanks a lot for working on this! -- Janne Blomqvist
Re: [patch,libgfortran] Handle invalid command line in EXECUTE_COMMAND_LINE
> Otherwise looks good, but strncat is C99, and we support targets which > don't have a C99 libc (been there, done that..). Since in this case > you're dealing with string literals rather than user input, it ought > to be safe to just use plain strcat (or strlen+memcpy, if you prefer). Nope, strncat() is C90: http://clc-wiki.net/wiki/strncat Thus, safe to use, I think. I committed as submitted, as revision 227105. Thanks for the review. FX
Re: [patch,libgfortran,toplevel] Use libbacktrace in libgfortran
> Ah, I didn't realize that. I guess you're right, it's better to split
> the filename:linenumber to a separate line. But still, I think it's
> clearer if you keep the "in" and "at" like the current code & gdb
> does. Thus, something like
>
> #framenumber 0xADDRESS in funcname
>at filename:linenumber
Done.
> And another thing which I previously missed: You have removed the
> store_exe_path function as it's no longer used for anything. However,
> that function is part of the libgfortran ABI and is found in
> gfortran.map, so we have to keep it until we bump the so version. :(
Which is what I did, though it’s not very clear from the .diff itself. The
function is emptied but remains in libgfortran/runtime/main.c:
void
store_exe_path (const char * argv0 __attribute__ ((unused)))
{
/* This function is now useless, but is retained due to ABI compatibility.
Remove when bumping the library ABI. */
;
}
> Please also add a note to the libgfortran ABI cleanup wiki page so we
> don't forget about it.
Done.
> With these changes, Ok for trunk. Thanks a lot for working on this!
Committed as revision 227106 with the changes above.
Thanks for reviewing the patch.
FX
