Re: [PATCH] Fix vector rsqrt discovery (PR tree-optimization/68501)
On Sat, Nov 28, 2015 at 08:47:18AM +0100, Richard Biener wrote: > On November 27, 2015 8:40:56 PM GMT+01:00, Jakub Jelinek > wrote: > >The recent changes where vector sqrt is represented in the IL using > >IFN_SQRT instead of target specific builtins broke the discovery > >of vector rsqrt, as targetm.builtin_reciprocal is called only > >on builtin functions (not internal functions). Furthermore, > >for internal fns, not only the IFN_* is significant, but also the > >types (modes actually) of the lhs and/or arguments. > > > >This patch adjusts the target hook, so that the backends can just > >inspect > >the call (builtin or internal function), whatever it is. > > > >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > OK. Though the other option would be to add an optab with corresponding IFN. Yeah, I've been thinking about IFN_RSQRT and rsqrt optab, perhaps that is cleaner and the target hook could go away completely. Jakub
Re: [RFC] Getting LTO incremental linking work
On 26/11/15 00:07, Jan Hubicka wrote:
(flinker_output): New flag.
Hi,
this seems to have cause a regression when using a compiler configured
for offloading (giving ~1000 fails in libgomp testing).
For test-case libgomp.c/examples-4/array_sections-3.c, we enter run_gcc
in lto-wrapper with args:
...
Breakpoint 1, run_gcc (argc=4, argv=0x7fffde68) at
src/gcc-gomp-4_0-branch/gcc/lto-wrapper.c:897
897 char *list_option_full = NULL;
(gdb) p argv[0]
$8 = 0x7fffe104 "lto-wrapper"
(gdb) p argv[1]
$9 = 0x7fffe1af "-fresolution=array_sections-3.res"
(gdb) p argv[2]
$10 = 0x7fffe1d1 "-flinker-output=exec"
(gdb) p argv[3]
$11 = 0x7fffe1e6 "array_sections-3.o"
...
And here (cc-ing author of this bit) we decide that -flinker-output=exec
is a file:
...
/* If object files contain offload sections, but do not contain LTO
sections,
then there is no need to perform a link-time recompilation, i.e.
lto-wrapper is used only for a compilation of offload images. */
if (have_offload && !have_lto)
{
for (i = 1; i < argc; ++i)
if (strncmp (argv[i], "-fresolution=",
sizeof ("-fresolution=") - 1))
{
char *out_file;
/* Can be ".o" or ".so". */
char *ext = strrchr (argv[i], '.');
if (ext == NULL)
out_file = make_temp_file ("");
else
out_file = make_temp_file (ext);
/* The linker will delete the files we give it, so make
copies. */
copy_file (out_file, argv[i]);
printf ("%s\n", out_file);
}
goto finish;
}
...
And try to copy it:
...
Program received signal SIGSEGV, Segmentation fault.
0x7783d7e0 in feof () from /lib/libc.so.6
(gdb) bt
#0 0x7783d7e0 in feof () from /lib/libc.so.6
#1 0x00406ff5 in copy_file (dest=0x71cdd0 "/tmp/ccL6HCCe",
src=0x7fffe1d1 "-flinker-output=exec")
at lto-wrapper.c:769
#2 0x004080b7 in run_gcc (argc=4, argv=0x7fffde68) at
gcc/lto-wrapper.c:1109
#3 0x00409873 in main (argc=4, argv=0x7fffde68) at
gcc/lto-wrapper.c:1396
...
Thanks,
- Tom
[Patch, fortran] PR68534 - No error on mismatch in number of arguments between submodule and module interface
Dear All,
The check that the number of formal arguments in the submodule
procedure declaration is the same as that in the module interface was
not working when there were none in either of them. This rather
trivial patch remedies the problem.
Bootstrapped and regtested on FC21/x86_64 - OK for trunk?
Paul
2015-11-28 Paul Thomas
PR fortran/68534
* decl.c (gfc_match_formal_arglist): Cope with zero formal args
either in interface declaration or in procedure declaration in
submodule.
2015-11-28 Paul Thomas
PR fortran/68534
* gfortran.dg/submodule_13.f08: New test.
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (revision 230783)
--- gcc/fortran/decl.c (working copy)
*** ok:
*** 4817,4830
goto cleanup;
}
! if (formal)
{
for (p = formal, q = head; p && q; p = p->next, q = q->next)
{
if ((p->next != NULL && q->next == NULL)
|| (p->next == NULL && q->next != NULL))
! gfc_error_now ("Mismatch in number of MODULE PROCEDURE "
! "formal arguments at %C");
else if ((p->sym == NULL && q->sym == NULL)
|| strcmp (p->sym->name, q->sym->name) == 0)
continue;
--- 4817,4839
goto cleanup;
}
! if (progname->attr.module_procedure && progname->attr.host_assoc)
{
+ bool arg_count_mismatch = false;
+
+ if (!formal && head)
+ arg_count_mismatch = true;
+
+ /* Abreviated module procedure declaration is not meant to have any
+formal arguments! */
+ if (!sym->abr_modproc_decl && formal && !head)
+ arg_count_mismatch = true;
+
for (p = formal, q = head; p && q; p = p->next, q = q->next)
{
if ((p->next != NULL && q->next == NULL)
|| (p->next == NULL && q->next != NULL))
! arg_count_mismatch = true;
else if ((p->sym == NULL && q->sym == NULL)
|| strcmp (p->sym->name, q->sym->name) == 0)
continue;
*** ok:
*** 4833,4838
--- 4842,4851
"argument names (%s/%s) at %C",
p->sym->name, q->sym->name);
}
+
+ if (arg_count_mismatch)
+ gfc_error_now ("Mismatch in number of MODULE PROCEDURE "
+ "formal arguments at %C");
}
return MATCH_YES;
Index: gcc/testsuite/gfortran.dg/submodule_13.f08
===
*** gcc/testsuite/gfortran.dg/submodule_13.f08 (revision 0)
--- gcc/testsuite/gfortran.dg/submodule_13.f08 (working copy)
***
*** 0
--- 1,32
+ ! { dg-do compile }
+ !
+ ! Checks the fix for PR68534 in which checks for the number
+ ! failed if either the interface or the module procedure had
+ ! no dummies.
+ !
+ ! Reported on clf at:
+ ! https://groups.google.com/forum/#!topic/comp.lang.fortran/-ZgbM5qkFmc
+ !
+ module m
+ implicit none
+ interface
+ module subroutine foo()
+ end subroutine foo
+
+ module subroutine bar(i)
+ integer, intent(inout) :: i
+ end subroutine bar
+end interface
+ end module m
+
+ submodule(m) sm
+ contains
+ module subroutine foo(i) ! { dg-error "Mismatch in number of MODULE
PROCEDURE formal" }
+ integer, intent(inout) :: i
+ i = 42
+ end subroutine foo
+
+ module subroutine bar ! { dg-error "Mismatch in number of MODULE PROCEDURE
formal" }
+ print *, "bar"
+ end subroutine bar
+ end submodule sm
Re: [PATCH] Fix vector rsqrt discovery (PR tree-optimization/68501)
On November 28, 2015 9:38:40 AM GMT+01:00, Jakub Jelinek wrote: >On Sat, Nov 28, 2015 at 08:47:18AM +0100, Richard Biener wrote: >> On November 27, 2015 8:40:56 PM GMT+01:00, Jakub Jelinek > wrote: >> >The recent changes where vector sqrt is represented in the IL using >> >IFN_SQRT instead of target specific builtins broke the discovery >> >of vector rsqrt, as targetm.builtin_reciprocal is called only >> >on builtin functions (not internal functions). Furthermore, >> >for internal fns, not only the IFN_* is significant, but also the >> >types (modes actually) of the lhs and/or arguments. >> > >> >This patch adjusts the target hook, so that the backends can just >> >inspect >> >the call (builtin or internal function), whatever it is. >> > >> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >> >> OK. Though the other option would be to add an optab with >corresponding IFN. > >Yeah, I've been thinking about IFN_RSQRT and rsqrt optab, perhaps that >is >cleaner and the target hook could go away completely. That was the idea for this kind of stuff. Not sure if appropriate at this stage. Richard. > Jakub
Re: [RFC] Getting LTO incremental linking work
On 28/11/15 10:35, Tom de Vries wrote:
On 26/11/15 00:07, Jan Hubicka wrote:
(flinker_output): New flag.
Hi,
this seems to have cause a regression when using a compiler configured
for offloading (giving ~1000 fails in libgomp testing).
For test-case libgomp.c/examples-4/array_sections-3.c, we enter run_gcc
in lto-wrapper with args:
...
Breakpoint 1, run_gcc (argc=4, argv=0x7fffde68) at
src/gcc-gomp-4_0-branch/gcc/lto-wrapper.c:897
897 char *list_option_full = NULL;
(gdb) p argv[0]
$8 = 0x7fffe104 "lto-wrapper"
(gdb) p argv[1]
$9 = 0x7fffe1af "-fresolution=array_sections-3.res"
(gdb) p argv[2]
$10 = 0x7fffe1d1 "-flinker-output=exec"
(gdb) p argv[3]
$11 = 0x7fffe1e6 "array_sections-3.o"
...
And here (cc-ing author of this bit) we decide that -flinker-output=exec
is a file:
...
/* If object files contain offload sections, but do not contain LTO
sections,
then there is no need to perform a link-time recompilation, i.e.
lto-wrapper is used only for a compilation of offload images. */
if (have_offload && !have_lto)
{
for (i = 1; i < argc; ++i)
if (strncmp (argv[i], "-fresolution=",
sizeof ("-fresolution=") - 1))
{
char *out_file;
/* Can be ".o" or ".so". */
char *ext = strrchr (argv[i], '.');
if (ext == NULL)
out_file = make_temp_file ("");
else
out_file = make_temp_file (ext);
/* The linker will delete the files we give it, so make
copies. */
copy_file (out_file, argv[i]);
printf ("%s\n", out_file);
}
goto finish;
}
...
And try to copy it:
...
Program received signal SIGSEGV, Segmentation fault.
0x7783d7e0 in feof () from /lib/libc.so.6
(gdb) bt
#0 0x7783d7e0 in feof () from /lib/libc.so.6
#1 0x00406ff5 in copy_file (dest=0x71cdd0 "/tmp/ccL6HCCe",
src=0x7fffe1d1 "-flinker-output=exec")
at lto-wrapper.c:769
#2 0x004080b7 in run_gcc (argc=4, argv=0x7fffde68) at
gcc/lto-wrapper.c:1109
#3 0x00409873 in main (argc=4, argv=0x7fffde68) at
gcc/lto-wrapper.c:1396
...
This patch fixes the failures. I'm not sure if this is the right or
complete fix though.
Thanks,
- Tom
diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index b9ac535..e4772d1 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1096,7 +1096,10 @@ run_gcc (unsigned argc, char *argv[])
if (have_offload && !have_lto)
{
for (i = 1; i < argc; ++i)
- if (strncmp (argv[i], "-fresolution=", sizeof ("-fresolution=") - 1))
+ if (strncmp (argv[i], "-fresolution=",
+ sizeof ("-fresolution=") - 1) != 0
+ && strncmp (argv[i], "-flinker-output=",
+ sizeof ("-flinker-output=") - 1) != 0)
{
char *out_file;
/* Can be ".o" or ".so". */
Re: [RFC] Getting LTO incremental linking work
2015-11-28 14:01 GMT+03:00 Tom de Vries : > This patch fixes the failures. I'm not sure if this is the right or complete > fix though. I think it's ok, at least until we decide how to rework the offloading stuff in lto-wrapper (see PR68463). Thanks, -- Ilya
Re: [PATCH] Add save_expr langhook (PR c/68513)
On Sat, 28 Nov 2015, Richard Biener wrote: > Different approach: after the FE folds (unexpectedly?), scan the result > for SAVE_EXPRs and if found, drop the folding. Or, if conversions are going to fold from language-independent code (which is the underlying problem here - a conversion without folding would be preferred once the fallout from that can be resolved), make the front end fold with c_fully_fold before doing the conversion, and wrap the result of the conversion in a C_MAYBE_CONST_EXPR with c_wrap_maybe_const in the same way as done in other places that fold early (if either c_fully_fold indicates it can't occur in a constant expression, or the result of folding / conversion is not an INTEGER_CST). -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch, fortran] PR68534 - No error on mismatch in number of arguments between submodule and module interface
On Sat, Nov 28, 2015 at 11:35:54AM +0100, Paul Richard Thomas wrote: > + > + /* Abreviated module procedure declaration is not meant to have any s/Abreviated/Abbreviated > + formal arguments! */ > + if (!sym->abr_modproc_decl && formal && !head) > + arg_count_mismatch = true; > + OK to commit. -- Steve
Re: [RFC] Getting LTO incremental linking work
On 28/11/15 13:02, Ilya Verbin wrote:
2015-11-28 14:01 GMT+03:00 Tom de Vries :
This patch fixes the failures. I'm not sure if this is the right or complete
fix though.
I think it's ok, at least until we decide how to rework the offloading
stuff in lto-wrapper (see PR68463).
Bootstrapped and reg-tested on x86_64.
Committed to trunk as attached.
Thanks,
- Tom
Handle flinker-output in lto-wrapper
2015-11-28 Tom de Vries
* lto-wrapper.c (run_gcc): Handle -flinker-output argument.
---
gcc/lto-wrapper.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index b9ac535..e4772d1 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1096,7 +1096,10 @@ run_gcc (unsigned argc, char *argv[])
if (have_offload && !have_lto)
{
for (i = 1; i < argc; ++i)
- if (strncmp (argv[i], "-fresolution=", sizeof ("-fresolution=") - 1))
+ if (strncmp (argv[i], "-fresolution=",
+ sizeof ("-fresolution=") - 1) != 0
+ && strncmp (argv[i], "-flinker-output=",
+ sizeof ("-flinker-output=") - 1) != 0)
{
char *out_file;
/* Can be ".o" or ".so". */
Re: [PATCH committed] PR other/61321 - demangler crash on casts in template parameters
On 11/27/2015 02:53 PM, Markus Trippelsdorf wrote: > I've committed the patch from Pedro Alves for PR61321. It was approved > by Jason over a year ago and the dups kept piling up. Thanks Markus. I've merged libiberty/ to sourceware.org git in order to pick the fix for gdb: https://sourceware.org/ml/binutils/2015-11/msg00261.html and pushed the corresponding GDB demangler-api adjustment: https://sourceware.org/ml/gdb-patches/2015-11/msg00599.html This and a few other demangler fixes are included in the (soon to be released) gdb 7.10.1: https://sourceware.org/ml/gdb-patches/2015-11/msg00600.html Thanks, Pedro Alves
Re: [PATCH] fix PR65726
On Thu, 26 Nov 2015, Andreas Tobler wrote:
the attached patch fixes the build issue from this ticket if bootstrap is
disabled.
Tested on x86_64-*-linux* and on x86_64-*-freebsd* with gcc and clang.
Ok for trunk?
And 5.3?
Thanks,
Andreas
2015-11-26 Andreas Tobler
PR libffi/65726
* Makefile.def (lang_env_dependencies): Make libffi depend
on cxx.
* Makefile.in: Regenerate.
This one fixes the issue in all my tests (and I am the original
reporter).
Since we do not have a libffi maintainer and it is a regression
and really straightforward, I'd go ahead and apply it, Andreas.
GeraldIndex: Makefile.def
===
--- Makefile.def(revision 230942)
+++ Makefile.def(working copy)
@@ -534,6 +534,7 @@
// on libgcc and newlib/libgloss.
lang_env_dependencies = { module=libjava; cxx=true; };
lang_env_dependencies = { module=libitm; cxx=true; };
+lang_env_dependencies = { module=libffi; cxx=true; };
lang_env_dependencies = { module=libcilkrts; cxx=true; };
lang_env_dependencies = { module=liboffloadmic; cxx=true; };
lang_env_dependencies = { module=newlib; no_c=true; };
Index: Makefile.in
===
--- Makefile.in (revision 230942)
+++ Makefile.in (working copy)
@@ -51034,6 +51034,7 @@
configure-target-libffi: maybe-all-target-newlib maybe-all-target-libgloss
+configure-target-libffi: maybe-all-target-libstdc++-v3
configure-target-libjava: maybe-all-target-newlib maybe-all-target-libgloss
configure-target-libjava: maybe-all-target-libstdc++-v3
[PTX] Fix CFA breakage
The recent patch to tree-nested.c:
2015-11-26 Pierre-Marie de Rodat
PR debug/53927
* tree-nested.c (finalize_nesting_tree_1): Append a field to
hold the frame base address.
* dwarf2out.c (gen_subprogram_die): Generate for
DW_AT_static_link a location description that computes the value
of this field.
broke PTX, as it tried to use argp for the CFA. Fixed thusly. Also tidied up a
few bits of nvptx.h while I was there.
nathan
2015-11-28 Nathan Sidwell
* config/nvptx/nvptx.h (FIRST_PARM_OFFSET): Add void cast.
(FRAME_POINTER_CFA_OFFSET): Define.
(struct nvptx_args): Use 'tree' type.
(INIT_CUMULATIVE_ARGS): Remove unnecessary do...while.
Index: gcc/config/nvptx/nvptx.h
===
--- gcc/config/nvptx/nvptx.h (revision 231037)
+++ gcc/config/nvptx/nvptx.h (working copy)
@@ -166,14 +166,16 @@ enum reg_class
#define OUTGOING_ARG_POINTER_REGNUM 11
#define OUTGOING_STATIC_CHAIN_REGNUM 10
-#define FIRST_PARM_OFFSET(FNDECL) 0
+#define FIRST_PARM_OFFSET(FNDECL) ((void)(FNDECL), 0)
#define PUSH_ARGS_REVERSED 1
-
#define ACCUMULATE_OUTGOING_ARGS 1
+/* Avoid using the argument pointer for frame-related things. */
+#define FRAME_POINTER_CFA_OFFSET(FNDECL) ((void)(FNDECL), 0)
+
#ifdef HOST_WIDE_INT
struct nvptx_args {
- union tree_node *fntype;
+ tree fntype;
/* Number of arguments passed in registers so far. */
int count;
/* Offset into the stdarg area so far. */
@@ -184,7 +186,7 @@ struct nvptx_args {
#define CUMULATIVE_ARGS struct nvptx_args
#define INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, FNDECL, N_NAMED_ARGS) \
- do { (CUM).fntype = (FNTYPE); (CUM).count = 0; (CUM).off = 0; } while (0)
+ ((CUM).fntype = (FNTYPE), (CUM).count = 0, (CUM).off = 0, (void)0)
#define FUNCTION_ARG_REGNO_P(r) 0
