New Spanish PO file for 'gcc' (version 7.2.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-7.2.0.es.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] Misc sse.md formatting fixes
On Thu, Dec 28, 2017 at 10:06 AM, Jakub Jelinek wrote:
> Hi!
>
> I've noticed various formatting issues in the recently added ISA support
> patterns. No functional changes, bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk?
>
> OT, wonder why we have any of the maskz and maskz_1 patterns, can't it be
> done in the intrinsic header by using the mask intrinsic with a _mm*zero*
> operand? I understand the need to have separate builtins for masked and
> non-masked at least in some cases (as we need AVX512BW for the masked cases
> but not for unmasked).
>
> 2017-12-28 Jakub Jelinek
>
> * config/i386/sse.md (vgf2p8affineinvqb_,
> vgf2p8affineqb_, vgf2p8mulb_,
> vpshrd_, vpshld_,
> vpshrdv_, vpshrdv__mask, vpshrdv__maskz,
> vpshrdv__maskz_1, vpshldv_, vpshldv__mask,
> vpshldv__maskz, vpshldv__maskz_1, vpdpbusd_,
> vpdpbusd__mask, vpdpbusd__maskz, vpdpbusd__maskz_1,
> vpdpbusds_, vpdpbusds__mask, vpdpbusds__maskz,
> vpdpbusds__maskz_1, vpdpwssd_, vpdpwssd__mask,
> vpdpwssd__maskz, vpdpwssd__maskz_1, vpdpwssds_,
> vpdpwssds__mask, vpdpwssds__maskz,
> vpdpwssds__maskz_1, vaesdec_, vaesdeclast_,
> vaesenc_, vpclmulqdq_,
> avx512vl_vpshufbitqmb): Formatting
> fixes.
OK as a trivial patch.
Thanks,
Uros.
> --- gcc/config/i386/sse.md.jj 2017-12-22 14:00:04.768613671 +0100
> +++ gcc/config/i386/sse.md 2017-12-27 19:19:58.081660733 +0100
> @@ -20082,10 +20082,11 @@ (define_insn "vpopcount
>
> (define_insn "vgf2p8affineinvqb_"
>[(set (match_operand:VI1_AVX512F 0 "register_operand" "=x,x,v")
> - (unspec:VI1_AVX512F [(match_operand:VI1_AVX512F 1 "register_operand"
> "%0,x,v")
> - (match_operand:VI1_AVX512F 2
> "nonimmediate_operand" "xBm,xm,vm")
> - (match_operand:QI 3 "const_0_to_255_operand"
> "n,n,n")]
> - UNSPEC_GF2P8AFFINEINV))]
> + (unspec:VI1_AVX512F
> + [(match_operand:VI1_AVX512F 1 "register_operand" "%0,x,v")
> + (match_operand:VI1_AVX512F 2 "nonimmediate_operand" "xBm,xm,vm")
> + (match_operand:QI 3 "const_0_to_255_operand" "n,n,n")]
> + UNSPEC_GF2P8AFFINEINV))]
>"TARGET_GFNI"
>"@
> gf2p8affineinvqb\t{%3, %2, %0| %0, %2, %3}
> @@ -20099,10 +20100,11 @@ (define_insn "vgf2p8affineinvqb_
> (define_insn "vgf2p8affineqb_"
>[(set (match_operand:VI1_AVX512F 0 "register_operand" "=x,x,v")
> - (unspec:VI1_AVX512F [(match_operand:VI1_AVX512F 1 "register_operand"
> "%0,x,v")
> - (match_operand:VI1_AVX512F 2
> "nonimmediate_operand" "xBm,xm,vm")
> - (match_operand:QI 3 "const_0_to_255_operand"
> "n,n,n")]
> - UNSPEC_GF2P8AFFINE))]
> + (unspec:VI1_AVX512F
> + [(match_operand:VI1_AVX512F 1 "register_operand" "%0,x,v")
> + (match_operand:VI1_AVX512F 2 "nonimmediate_operand" "xBm,xm,vm")
> + (match_operand:QI 3 "const_0_to_255_operand" "n,n,n")]
> + UNSPEC_GF2P8AFFINE))]
>"TARGET_GFNI"
>"@
> gf2p8affineqb\t{%3, %2, %0| %0, %2, %3}
> @@ -20116,9 +20118,10 @@ (define_insn "vgf2p8affineqb_
> (define_insn "vgf2p8mulb_"
>[(set (match_operand:VI1_AVX512F 0 "register_operand" "=x,x,v")
> - (unspec:VI1_AVX512F [(match_operand:VI1_AVX512F 1 "register_operand"
> "%0,x,v")
> - (match_operand:VI1_AVX512F 2
> "nonimmediate_operand" "xBm,xm,vm")]
> - UNSPEC_GF2P8MUL))]
> + (unspec:VI1_AVX512F
> + [(match_operand:VI1_AVX512F 1 "register_operand" "%0,x,v")
> + (match_operand:VI1_AVX512F 2 "nonimmediate_operand" "xBm,xm,vm")]
> + UNSPEC_GF2P8MUL))]
>"TARGET_GFNI"
>"@
> gf2p8mulb\t{%2, %0| %0, %2}
> @@ -20134,9 +20137,9 @@ (define_insn "vpshrd_"
>[(set (match_operand:VI248_VLBW 0 "register_operand" "=v")
> (unspec:VI248_VLBW
> [(match_operand:VI248_VLBW 1 "register_operand" "v")
> - (match_operand:VI248_VLBW 2 "nonimmediate_operand" "vm")
> - (match_operand:SI 3 "const_0_to_255_operand" "n")
> -] UNSPEC_VPSHRD))]
> + (match_operand:VI248_VLBW 2 "nonimmediate_operand" "vm")
> + (match_operand:SI 3 "const_0_to_255_operand" "n")]
> + UNSPEC_VPSHRD))]
>"TARGET_AVX512VBMI2"
>"vpshrd\t{%3, %2, %1, %0|%0,
> %1, %2, %3 }"
> [(set_attr ("prefix") ("evex"))])
> @@ -20145,9 +20148,9 @@ (define_insn "vpshld_"
>[(set (match_operand:VI248_VLBW 0 "register_operand" "=v")
> (unspec:VI248_VLBW
> [(match_operand:VI248_VLBW 1 "register_operand" "v")
> - (match_operand:VI248_VLBW 2 "nonimmediate_operand" "vm")
> - (match_operand:SI 3 "const_0_to_255_operand" "n")
> -] UNSPEC_VPSHLD))]
> + (match_operand:VI248_VLBW 2 "nonimmediate_operand" "vm")
> + (match_operand:SI 3 "const_0_to_255_operan
Re: [PATCH] Fix gcc.target/i386/avx512vpopcntdqvl-vpopcnt*-1.c FAILs
On Thu, Dec 28, 2017 at 4:18 PM, Jakub Jelinek wrote:
> Hi!
>
> Binutils had vpopcnt[dq] support since ~ January, but only for the 512-bit
> instructions, only in ~ October further support for the AVX512VPOPCNTDQ |
> AVX512VL instructions has been added. So, if one is using gas in between
> those two, these two tests FAIL to assemble.
>
> Fixed thusly (tests will be UNSUPPORTED not just with as that doesn't
> support vpopcnt[dq] at all, but also one that only supports
> vpopcnt[dq] %zmmN, ..., but should work with more recent binutils), regtested
> on x86_64-linux, ok for trunk?
>
> 2017-12-28 Jakub Jelinek
>
> * gcc.target/i386/i386.exp
> (check_effective_target_avx512vpopcntdqvl): New proc.
> * gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c: Use
> avx512vpopcntdqvl effective target rather than avx512vpopcntdq.
> * gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c: Likewise.
OK.
Thanks,
Uros.
> --- gcc/testsuite/gcc.target/i386/i386.exp.jj 2017-12-22 14:00:02.809638667
> +0100
> +++ gcc/testsuite/gcc.target/i386/i386.exp 2017-12-28 16:09:25.702051624
> +0100
> @@ -410,6 +410,19 @@ proc check_effective_target_avx512vpopcn
> } "-mavx512vpopcntdq" ]
> }
>
> +# Return 1 if avx512_vpopcntdq & avx512vl instructions can be compiled.
> +proc check_effective_target_avx512vpopcntdqvl { } {
> +return [check_no_compiler_messages avx512vpopcntdqvl object {
> +typedef int __v8si __attribute__ ((__vector_size__ (32)));
> +
> +__v8si
> +_mm256_popcnt_epi32 (__v8si __A)
> +{
> +return (__v8si) __builtin_ia32_vpopcountd_v8si ((__v8si) __A);
> +}
> +} "-mavx512vpopcntdq -mavx512vl" ]
> +}
> +
> # Return 1 if gfni instructions can be compiled.
> proc check_effective_target_gfni { } {
> return [check_no_compiler_messages gfni object {
> --- gcc/testsuite/gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c.jj
> 2017-12-22 14:00:02.785638973 +0100
> +++ gcc/testsuite/gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c
> 2017-12-28 16:12:20.427156937 +0100
> @@ -1,7 +1,7 @@
> /* { dg-do run } */
> /* { dg-options "-O2 -mavx512vpopcntdq -mavx512bw -mavx512vl" } */
> /* { dg-require-effective-target avx512vl } */
> -/* { dg-require-effective-target avx512vpopcntdq } */
> +/* { dg-require-effective-target avx512vpopcntdqvl } */
> /* { dg-require-effective-target avx512bw } */
>
> #define AVX512VL
> --- gcc/testsuite/gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c.jj
> 2017-12-22 14:00:02.784638986 +0100
> +++ gcc/testsuite/gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c
> 2017-12-28 16:12:28.269161404 +0100
> @@ -1,7 +1,7 @@
> /* { dg-do run } */
> /* { dg-options "-O2 -mavx512vl -mavx512vpopcntdq" } */
> /* { dg-require-effective-target avx512vl } */
> -/* { dg-require-effective-target avx512vpopcntdq } */
> +/* { dg-require-effective-target avx512vpopcntdqvl } */
>
> #define AVX512VL
> #define AVX512F_LEN 256
>
> Jakub
Re: [PATCH] Fix gcc.target/i386/avx512vpopcntdqvl-vpopcnt*-1.c FAILs
On Thu, Dec 28, 2017 at 4:18 PM, Jakub Jelinek wrote:
> Hi!
>
> Binutils had vpopcnt[dq] support since ~ January, but only for the 512-bit
> instructions, only in ~ October further support for the AVX512VPOPCNTDQ |
> AVX512VL instructions has been added. So, if one is using gas in between
> those two, these two tests FAIL to assemble.
>
> Fixed thusly (tests will be UNSUPPORTED not just with as that doesn't
> support vpopcnt[dq] at all, but also one that only supports
> vpopcnt[dq] %zmmN, ..., but should work with more recent binutils), regtested
> on x86_64-linux, ok for trunk?
>
> 2017-12-28 Jakub Jelinek
>
> * gcc.target/i386/i386.exp
> (check_effective_target_avx512vpopcntdqvl): New proc.
> * gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c: Use
> avx512vpopcntdqvl effective target rather than avx512vpopcntdq.
> * gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c: Likewise.
>
> --- gcc/testsuite/gcc.target/i386/i386.exp.jj 2017-12-22 14:00:02.809638667
> +0100
> +++ gcc/testsuite/gcc.target/i386/i386.exp 2017-12-28 16:09:25.702051624
> +0100
> @@ -410,6 +410,19 @@ proc check_effective_target_avx512vpopcn
> } "-mavx512vpopcntdq" ]
> }
>
> +# Return 1 if avx512_vpopcntdq & avx512vl instructions can be compiled.
Perhaps we should say:
# Return 1 if variable-length avx512_vpopcntdq instructions can be compiled.
Uros.
> +proc check_effective_target_avx512vpopcntdqvl { } {
> +return [check_no_compiler_messages avx512vpopcntdqvl object {
> +typedef int __v8si __attribute__ ((__vector_size__ (32)));
> +
> +__v8si
> +_mm256_popcnt_epi32 (__v8si __A)
> +{
> +return (__v8si) __builtin_ia32_vpopcountd_v8si ((__v8si) __A);
> +}
> +} "-mavx512vpopcntdq -mavx512vl" ]
> +}
> +
> # Return 1 if gfni instructions can be compiled.
> proc check_effective_target_gfni { } {
> return [check_no_compiler_messages gfni object {
> --- gcc/testsuite/gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c.jj
> 2017-12-22 14:00:02.785638973 +0100
> +++ gcc/testsuite/gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c
> 2017-12-28 16:12:20.427156937 +0100
> @@ -1,7 +1,7 @@
> /* { dg-do run } */
> /* { dg-options "-O2 -mavx512vpopcntdq -mavx512bw -mavx512vl" } */
> /* { dg-require-effective-target avx512vl } */
> -/* { dg-require-effective-target avx512vpopcntdq } */
> +/* { dg-require-effective-target avx512vpopcntdqvl } */
> /* { dg-require-effective-target avx512bw } */
>
> #define AVX512VL
> --- gcc/testsuite/gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c.jj
> 2017-12-22 14:00:02.784638986 +0100
> +++ gcc/testsuite/gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c
> 2017-12-28 16:12:28.269161404 +0100
> @@ -1,7 +1,7 @@
> /* { dg-do run } */
> /* { dg-options "-O2 -mavx512vl -mavx512vpopcntdq" } */
> /* { dg-require-effective-target avx512vl } */
> -/* { dg-require-effective-target avx512vpopcntdq } */
> +/* { dg-require-effective-target avx512vpopcntdqvl } */
>
> #define AVX512VL
> #define AVX512F_LEN 256
>
> Jakub
Re: [libgomp, openacc, openmp, PR83046] Prune removed funcs from offload table
On Fri, Dec 29, 2017 at 02:07:49PM +0100, Tom de Vries wrote:
> --- a/gcc/lto-streamer-out.c
> +++ b/gcc/lto-streamer-out.c
> @@ -41,6 +41,7 @@ along with GCC; see the file COPYING3. If not see
> #include "builtins.h"
> #include "gomp-constants.h"
> #include "debug.h"
> +#include "omp-offload.h"
>
>
> static void lto_write_tree (struct output_block*, tree, bool);
> @@ -2355,6 +2356,31 @@ lto_output (void)
>int i, n_nodes;
>lto_symtab_encoder_t encoder = lto_get_out_decl_state
> ()->symtab_node_encoder;
>
> + bool truncated_p = false;
I don't think you need this var.
> + unsigned int write_index = 0;
> + for (unsigned read_index = 0; read_index < vec_safe_length (offload_funcs);
> + read_index++)
> +{
> + tree fn_decl = (*offload_funcs)[read_index];
> + bool remove_p = cgraph_node::get (fn_decl) == NULL;
> + if (remove_p)
> + {
> + truncated_p = true;
> + continue;
> + }
> +
> + if (write_index != read_index)
> + (*offload_funcs)[write_index] = (*offload_funcs)[read_index];
> +
> + write_index++;
> +}
> + if (truncated_p)
> +offload_funcs->truncate (write_index);
Either you truncate unconditionally, truncate is extremely cheap operation,
or if you really wanted to guard it, you could just do
if (read_index != write_index)
> +
> + if (!flag_lto)
> +for (unsigned i = 0; i < vec_safe_length (offload_funcs); i++)
> + DECL_PRESERVE_P ((*offload_funcs)[i]) = 1;
Can you please do this inside of the above loop, you have fn_decl already
there, just do it after the
if (remove_p)
continue;
And, I think you can do it unconditionally at that point, or, can you use
in_lto_p instead of flag_lto? flag_lto is set even during the -flto
compilation of the sources before LTO is streamed, there is no need to
pessimize that code, we can still remove it, we just can't remove anything
after we've streamed LTO bytecode (for either the host or offloading
targets).
> @@ -7058,7 +7058,11 @@ expand_omp_target (struct omp_region *region)
>
>/* Add the new function to the offload table. */
>if (ENABLE_OFFLOADING)
> - vec_safe_push (offload_funcs, child_fn);
> + {
> + if (flag_lto)
> + DECL_PRESERVE_P (child_fn) = 1;
And use if (in_lto_p) here too.
Ok for trunk with those changes.
Jakub
[testsuite, PR83612] Fix 'memory cannot be printed' in gcc.dg/ubsan/object-size-9.c
Hi,
I ran into the following failure:
...
FAIL: gcc.dg/ubsan/object-size-9.c -O2 output pattern test, is
gcc.dg/ubsan/object-size-9.c:11:13: runtime error: load of address
0x00600ff2 with insufficient space for an object of type 'char'
0x00600ff2: note: pointer points here
...
The failure is because the test-case expects the sanitizer to access the
memory and print its contents, but the memory happens not to be not
accessible.
I've applied the same fix as was applied in
c-c++-common/ubsan/object-size-9.c for PR sanitizer/64078: add an
alignment attribute to the variable to ensure that the memory after the
variable is accessible.
Tested on x86_64.
Committed as obvious.
Thanks,
- Tom
Fix 'memory cannot be printed' in gcc.dg/ubsan/object-size-9.c
2017-12-30 Tom de Vries
PR testsuite/83612
* gcc.dg/ubsan/object-size-9 (t): Add alignment attribute.
---
gcc/testsuite/gcc.dg/ubsan/object-size-9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/ubsan/object-size-9.c b/gcc/testsuite/gcc.dg/ubsan/object-size-9.c
index e0a2980..41c4a94 100644
--- a/gcc/testsuite/gcc.dg/ubsan/object-size-9.c
+++ b/gcc/testsuite/gcc.dg/ubsan/object-size-9.c
@@ -3,7 +3,7 @@
/* { dg-options "-fsanitize=undefined" } */
struct T { int c; char d[]; };
-struct T t = { 1, "a" };
+struct T t __attribute__ ((aligned(4096))) = { 1, "a" };
int
baz (int i)
Re: [libgomp, openacc, openmp, PR83046] Prune removed funcs from offload table
On 12/30/2017 10:54 AM, Jakub Jelinek wrote:
On Fri, Dec 29, 2017 at 02:07:49PM +0100, Tom de Vries wrote:
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3. If not see
#include "builtins.h"
#include "gomp-constants.h"
#include "debug.h"
+#include "omp-offload.h"
static void lto_write_tree (struct output_block*, tree, bool);
@@ -2355,6 +2356,31 @@ lto_output (void)
int i, n_nodes;
lto_symtab_encoder_t encoder = lto_get_out_decl_state
()->symtab_node_encoder;
+ bool truncated_p = false;
I don't think you need this var.
Removed.
+ unsigned int write_index = 0;
+ for (unsigned read_index = 0; read_index < vec_safe_length (offload_funcs);
+ read_index++)
+{
+ tree fn_decl = (*offload_funcs)[read_index];
+ bool remove_p = cgraph_node::get (fn_decl) == NULL;
+ if (remove_p)
+ {
+ truncated_p = true;
+ continue;
+ }
+
+ if (write_index != read_index)
+ (*offload_funcs)[write_index] = (*offload_funcs)[read_index];
+
+ write_index++;
+}
+ if (truncated_p)
+offload_funcs->truncate (write_index);
Either you truncate unconditionally, truncate is extremely cheap operation,
or if you really wanted to guard it, you could just do
if (read_index != write_index)
My concern was not the cost, but offload_funcs == NULL.
I've fixed this now by moving the code into a separate function and
using the offload_funcs == NULL as early exit test.
+
+ if (!flag_lto)
+for (unsigned i = 0; i < vec_safe_length (offload_funcs); i++)
+ DECL_PRESERVE_P ((*offload_funcs)[i]) = 1;
Can you please do this inside of the above loop, you have fn_decl already
there, just do it after the
if (remove_p)
continue;
Done.
And, I think you can do it unconditionally at that point,
Done. [ I wonder though if we can use in_lto_p as early exit test as well. ]
or, can you use
in_lto_p instead of flag_lto? flag_lto is set even during the -flto
compilation of the sources before LTO is streamed, there is no need to
pessimize that code, we can still remove it, we just can't remove anything
after we've streamed LTO bytecode (for either the host or offloading
targets).
@@ -7058,7 +7058,11 @@ expand_omp_target (struct omp_region *region)
/* Add the new function to the offload table. */
if (ENABLE_OFFLOADING)
- vec_safe_push (offload_funcs, child_fn);
+ {
+ if (flag_lto)
+ DECL_PRESERVE_P (child_fn) = 1;
And use if (in_lto_p) here too.
Done.
Ok for trunk with those changes.
Will commit after another round of testing.
Thanks,
- Tom
Prune removed funcs from offload table
2017-12-27 Tom de Vries
PR libgomp/83046
* omp-expand.c (expand_omp_target): If in_lto_p, mark offload_funcs with
DECL_PRESERVE_P.
* lto-streamer-out.c (prune_offload_funcs): New function. Remove
offload_funcs entries that no longer have a corresponding cgraph_node.
Mark the remaining ones as DECL_PRESERVE_P.
(output_lto): Call prune_offload_funcs.
* testsuite/libgomp.oacc-c-c++-common/pr83046.c: New test.
* testsuite/libgomp.c-c++-common/pr83046.c: New test.
---
gcc/lto-streamer-out.c | 32 ++
gcc/omp-expand.c | 6 +++-
libgomp/testsuite/libgomp.c-c++-common/pr83046.c | 25 +
.../testsuite/libgomp.oacc-c-c++-common/pr83046.c | 25 +
4 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index ba29bd088e6..ef170838fc0 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3. If not see
#include "builtins.h"
#include "gomp-constants.h"
#include "debug.h"
+#include "omp-offload.h"
static void lto_write_tree (struct output_block*, tree, bool);
@@ -2345,6 +2346,35 @@ wrap_refs (tree *tp, int *ws, void *)
return NULL_TREE;
}
+/* Remove functions that are no longer used from offload_funcs, and mark the
+ remaining ones with DECL_PRESERVE_P. */
+
+static void
+prune_offload_funcs (void)
+{
+ if (!offload_funcs)
+return;
+
+ unsigned int write_index = 0;
+ for (unsigned read_index = 0; read_index < vec_safe_length (offload_funcs);
+ read_index++)
+{
+ tree fn_decl = (*offload_funcs)[read_index];
+ bool remove_p = cgraph_node::get (fn_decl) == NULL;
+ if (remove_p)
+ continue;
+
+ DECL_PRESERVE_P (fn_decl) = 1;
+
+ if (write_index != read_index)
+ (*offload_funcs)[write_index] = (*offload_funcs)[read_index];
+
+ write_index++;
+}
+
+ offload_funcs->truncate (write_index);
+}
+
/* Main entry point from the pass manager. */
void
@@ -2355,6 +2385,8 @@ lto_output (void)
int i, n_nodes;
lto_symtab_encoder_t encoder = lto_get_out_decl_state ()->symtab_node_encoder;
+ prune_offload_funcs ();
+
i
Re: [PATCH] PR 78534 Change character length from int to size_t
Hi Janne,
In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.
Just running some tests on gcc110 (the big-endian PPC machine from
the compile farm).
Something does not seem to work with I/O with long strings.
With
program main
character(len=2_8**33), parameter :: a = ""
character(len=2_8**33) :: b
print '(A),a
b = ""
print '(A)',b
end program main
I get
$ strace ./a.out > /dev/null
...
write(1, "\n", 1) = 1
write(1, "\n", 1) = 1
so I suspect there still is a 32-bit quantity for string lengths
lurking somewhere in the I/O library.
The following program causes a segfault on compilation:
program main
integer(8), parameter :: n=2_8**32
character(len=*), parameter :: a1 = repeat('x',n)
end program main
The program
program main
integer(8), parameter :: n=2_8**32
character(len=n), parameter :: a1 = repeat('x',n), a2 = repeat('y',n)
character(len=*), parameter :: a3 = a1 // a2
end program main
is rejected with
tkoenig@gcc1-power7 String]$ gfortran concat.f90
concat.f90:4:37:
character(len=*), parameter :: a3 = a1 // a2
1
Error: Function ‘a1’ in initialization expression at (1) must be an
intrinsic function
That's all I could find for the moment. I will continue looking.
Thanks for tackling this!
Regards
Thomas
Re: [PATCH] PR 78534 Change character length from int to size_t
On Sat, Dec 30, 2017 at 4:59 PM, Thomas Koenig wrote: > That's all I could find for the moment. I will continue looking. > Thanks for tackling this! Thanks for testing! To be honest, I haven't really done much testing with big strings, so far my focus has been on getting the existing testsuite to pass and getting the ABI right. As the library ABI has been broken for GCC 8 already by other changes, I'd like to piggyback this ABI change in for the GCC 8 release as well. As the patch is already pretty big as is, I'd prefer that other fixes to enable big strings would be done as separate patches rather than trying to make everything perfect on the first try. Slightly related to your testcases, I think it would make sense to create some separate "GFortran huge" testsuite, where we could collect testcases that need lots of memory, or cpu time, or disk space and can thus not be part of the default testsuite. -- Janne Blomqvist
[PATCH] expandargv: fix memory leak
When the responsefile's contents are interpolated into the argument vector,
the pointer to original option string ("@filename") became lost. This
caused a small leak for every responsefile on the commandline.
---
libiberty/argv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libiberty/argv.c b/libiberty/argv.c
index c544dad73ee..bdd4ace4cb6 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -455,6 +455,8 @@ expandargv (int *argcp, char ***argvp)
file_argc = 0;
while (file_argv[file_argc])
++file_argc;
+ /* Free the original option's memory. */
+ free((*argvp)[i]);
/* Now, insert FILE_ARGV into ARGV. The "+1" below handles the
NULL terminator at the end of ARGV. */
*argvp = ((char **)
--
2.11.0
Re: [patch, committed] Bug 83613 - [8 Regression] Executing gfortran.dg/inquire_internal.f90 hangs on darwin
On 12/29/2017 02:40 PM, Jerry DeLisle wrote: > Committed as obvious after regression testing on x86_64-pc-linux-gnu. > > Dominiq: Please confirm is fixed. > > Regards, > > Jerry > The actual patch, Dominiq confirmed the issue was fixed: diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c index 2ca8525fbec..a655665aa8a 100644 --- a/libgfortran/io/unit.c +++ b/libgfortran/io/unit.c @@ -707,7 +707,9 @@ init_units (void) } /* The default internal units. */ u = insert_unit (GFC_INTERNAL_UNIT); + __gthread_mutex_unlock (&u->lock); u = insert_unit (GFC_INTERNAL_UNIT4); + __gthread_mutex_unlock (&u->lock); } Cheers, Jerry
Re: [PATCH] PR 78534 Change character length from int to size_t
Hi Janne, To be honest, I haven't really done much testing with big strings, so far my focus has been on getting the existing testsuite to pass and getting the ABI right. I agree that some of the test cases can be fixed later. However, I would really prefer if the I/O worked, because that is very basic functionality, but also because this is (likely to be) an ABI issue. If this bug remains unfixed for any reason at all, then we are left with no choice but to break the ABI when we fix that bug. I would like to avoid that, if possible. By the way, we also should forsee a few more ABI-breaking things while we're at it. We should - Put a "reserved" field in the array descriptor for things like "did this come from an ALLOCATE statement or not", there is a PR for this - Put a pointer to void into the I/O structures, which we are certain to need for async I/O - Increase the maximum number of array dimensions to 15, as per f2008 - Insert a "BACK" argument in minloc, maxloc, minval, maxval, even if we do not use it at the moment As the library ABI has been broken for GCC 8 already by other changes, I'd like to piggyback this ABI change in for the GCC 8 release as well. As the patch is already pretty big as is, I'd prefer that other fixes to enable big strings would be done as separate patches rather than trying to make everything perfect on the first try. I tend to concur for the other bugs, but not for the I/O issue. Regards Thomas
Re: [PATCH] expandargv: fix memory leak
On Dez 30 2017, Daniel van Gerpen wrote:
> When the responsefile's contents are interpolated into the argument vector,
> the pointer to original option string ("@filename") became lost. This
> caused a small leak for every responsefile on the commandline.
argv elements generally don't point to the heap.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
[PATCH] Fix ICE with vector 16-bit rotate (PR middle-end/83623)
Hi!
Ths chunk of code wants to expand 16-bit rotate by 8 as bswaphi, but
if mode is a vector mode (or complex mode), trying to use bswaphi pattern to
swap say V16HImode vector is just wrong.
This patch arranges to use bswapv16hi etc. instead in those cases, which
isn't 100% clear to me from the docs if they only swap bytes of each of the
vector element, but from looking at a few backends it seems like that is the
case and if it wasn't, e.g. simplify-rtx.c would missimplify stuff.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-12-30 Jakub Jelinek
PR middle-end/83623
* expmed.c (expand_shift_1): For 2-byte rotates by BITS_PER_UNIT,
check for bswap in mode rather than HImode and use that in expand_unop
too.
* gcc.dg/pr83623.c: New test.
--- gcc/expmed.c.jj 2017-12-20 20:40:18.0 +0100
+++ gcc/expmed.c2017-12-30 11:44:47.045433528 +0100
@@ -2490,9 +2490,8 @@ expand_shift_1 (enum tree_code code, mac
&& CONST_INT_P (op1)
&& INTVAL (op1) == BITS_PER_UNIT
&& GET_MODE_SIZE (scalar_mode) == 2
- && optab_handler (bswap_optab, HImode) != CODE_FOR_nothing)
-return expand_unop (HImode, bswap_optab, shifted, NULL_RTX,
- unsignedp);
+ && optab_handler (bswap_optab, mode) != CODE_FOR_nothing)
+return expand_unop (mode, bswap_optab, shifted, NULL_RTX, unsignedp);
if (op1 == const0_rtx)
return shifted;
--- gcc/testsuite/gcc.dg/pr83623.c.jj 2017-12-30 11:49:23.259470538 +0100
+++ gcc/testsuite/gcc.dg/pr83623.c 2017-12-30 11:49:01.309467592 +0100
@@ -0,0 +1,12 @@
+/* PR middle-end/83623 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-additional-options "-mmovbe" { target i?86-*-* x86_64-*-* } } */
+
+unsigned short __attribute__ ((__vector_size__ (16))) x;
+
+void
+foo (void)
+{
+ x = x << 8 | x >> 8;
+}
Jakub
[PATCH] Fix expand_assignment stores to CONCAT (PR middle-end/83609)
Hi!
The first hunk before the if (!from...) part shows a typo I've made in a
recent change, the last argument of simplify_gen_subreg is byte offset, and
the subreg has same bitsize outer and inner modes, so using byte offset 1
makes no sense at all.
Another issue that the testcase suffers from is that the simplify_gen_rtx
(preexisting issue) can fail, and in that case trying to read_complex_part
from that NULL will ICE. The patch tries harder by trying to simplify the
2 halves separately, and for all cases when simplify_gen_subreg fails which
can happen because of various reasons, there is the fallback to go through
memory.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/7.3?
2017-12-30 Jakub Jelinek
PR middle-end/83609
* expr.c (expand_assignment): Fix up a typo in simplify_gen_subreg
last argument when extracting from CONCAT. If either from_real or
from_imag is NULL, use expansion through memory. If result is not
a CONCAT and simplify_gen_subreg fails, try to simplify_gen_subreg
the parts directly to inner mode, if even that fails, use expansion
through memory.
* gcc.dg/pr83609.c: New test.
* g++.dg/opt/pr83609.C: New test.
--- gcc/expr.c.jj 2017-12-21 09:43:19.797042465 +0100
+++ gcc/expr.c 2017-12-30 13:49:19.634057445 +0100
@@ -5158,7 +5158,9 @@ expand_assignment (tree to, tree from, b
from_mode, 0);
rtx from_imag
= simplify_gen_subreg (to_mode, XEXP (result, 1),
- from_mode, 1);
+ from_mode, 0);
+ if (!from_real || !from_imag)
+ goto concat_store_slow;
emit_move_insn (XEXP (to_rtx, 0), from_real);
emit_move_insn (XEXP (to_rtx, 1), from_imag);
}
@@ -5167,14 +5169,35 @@ expand_assignment (tree to, tree from, b
rtx from_rtx
= simplify_gen_subreg (GET_MODE (to_rtx), result,
TYPE_MODE (TREE_TYPE (from)), 0);
- emit_move_insn (XEXP (to_rtx, 0),
- read_complex_part (from_rtx, false));
- emit_move_insn (XEXP (to_rtx, 1),
- read_complex_part (from_rtx, true));
+ if (from_rtx)
+ {
+ emit_move_insn (XEXP (to_rtx, 0),
+ read_complex_part (from_rtx, false));
+ emit_move_insn (XEXP (to_rtx, 1),
+ read_complex_part (from_rtx, true));
+ }
+ else
+ {
+ machine_mode to_mode
+ = GET_MODE_INNER (GET_MODE (to_rtx));
+ rtx from_real
+ = simplify_gen_subreg (to_mode, result,
+ TYPE_MODE (TREE_TYPE (from)),
+ 0);
+ rtx from_imag
+ = simplify_gen_subreg (to_mode, result,
+ TYPE_MODE (TREE_TYPE (from)),
+ GET_MODE_SIZE (to_mode));
+ if (!from_real || !from_imag)
+ goto concat_store_slow;
+ emit_move_insn (XEXP (to_rtx, 0), from_real);
+ emit_move_insn (XEXP (to_rtx, 1), from_imag);
+ }
}
}
else
{
+ concat_store_slow:;
rtx temp = assign_stack_temp (GET_MODE (to_rtx),
GET_MODE_SIZE (GET_MODE (to_rtx)));
write_complex_part (temp, XEXP (to_rtx, 0), false);
--- gcc/testsuite/gcc.dg/pr83609.c.jj 2017-12-30 13:47:49.350044674 +0100
+++ gcc/testsuite/gcc.dg/pr83609.c 2017-12-30 13:42:52.227002619 +0100
@@ -0,0 +1,29 @@
+/* PR middle-end/83609 */
+/* { dg-do run } */
+/* { dg-options "-O2 -fno-tree-forwprop -fno-tree-ccp -fno-tree-fre
-fno-tree-pre -fno-code-hoisting" } */
+
+#if __SIZEOF_LONG_LONG__ == 2 * __SIZEOF_FLOAT__
+_Complex float
+foo (void)
+{
+ _Complex float c;
+ *((unsigned long long *)&c) = 0x123456789abcdef0ULL;
+ return c;
+}
+
+int
+main ()
+{
+ union { _Complex float c; unsigned long long l; } u;
+ u.c = foo ();
+ if (u.l != 0x123456789abcdef0ULL)
+__builtin_abort ();
+ return 0;
+}
+#else
+int
+main ()
+{
+ return 0;
+}
+#endif
--- gcc/testsuite/g++.dg/opt/pr83609.C.jj 2017-12-30 13:48:18.937048860
+0100
+++ gcc/testsuite/g++.dg/opt/pr83609.C 2017-12-30 13:46:25.968032868 +0100
@@ -0,0 +1,28 @@
+// PR middle-end/83609
+// { dg-do compile }
+// { dg-options "-O2 -fno-tree-forwprop" }
+
+template class B;
+template <> struct B
+{
+ float f
[PATCH] Fix another ICE with complex assignment (PR middle-end/83608)
Hi!
The comment on convert_modes says:
Both modes may be floating, or both integer.
but as the testcase shows, with a MEM_REF with a different mode class
than a VAR_DECL as its operand we can end up with e.g. floating point vs.
integral mode etc. and convert_modes doesn't handle those cases.
This patch uses simplify_gen_subreg in those case first.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/7.3?
2017-12-30 Jakub Jelinek
PR middle-end/83608
* expr.c (store_expr_with_bounds): Use simplify_gen_subreg instead of
convert_modes if target mode has the right side, but different mode
class.
* g++.dg/opt/pr83608.C: New test.
--- gcc/expr.c.jj 2017-12-30 14:35:52.095877981 +0100
+++ gcc/expr.c 2017-12-30 14:36:06.268882813 +0100
@@ -5638,8 +5638,21 @@ store_expr_with_bounds (tree exp, rtx ta
if (CONSTANT_P (temp) && GET_MODE (temp) == VOIDmode
&& TREE_CODE (exp) != ERROR_MARK
&& GET_MODE (target) != TYPE_MODE (TREE_TYPE (exp)))
-temp = convert_modes (GET_MODE (target), TYPE_MODE (TREE_TYPE (exp)),
- temp, TYPE_UNSIGNED (TREE_TYPE (exp)));
+{
+ if (GET_MODE_CLASS (GET_MODE (target))
+ != GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (exp)))
+ && GET_MODE_BITSIZE (GET_MODE (target))
+== GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (exp
+ {
+ rtx t = simplify_gen_subreg (GET_MODE (target), temp,
+ TYPE_MODE (TREE_TYPE (exp)), 0);
+ if (t)
+ temp = t;
+ }
+ if (GET_MODE (temp) == VOIDmode)
+ temp = convert_modes (GET_MODE (target), TYPE_MODE (TREE_TYPE (exp)),
+ temp, TYPE_UNSIGNED (TREE_TYPE (exp)));
+}
/* If value was not generated in the target, store it there.
Convert the value to TARGET's type first if necessary and emit the
--- gcc/testsuite/g++.dg/opt/pr83608.C.jj 2017-12-30 14:36:52.323898522
+0100
+++ gcc/testsuite/g++.dg/opt/pr83608.C 2017-12-30 14:00:12.811195532 +0100
@@ -0,0 +1,28 @@
+// PR middle-end/83608
+// { dg-do compile }
+// { dg-options "-O2" }
+
+template class B;
+template <> struct B
+{
+ float foo () { return __real__ b; }
+ _Complex double b;
+};
+
+void bar (int);
+
+template
+void
+baz ()
+{
+ B h;
+ T *a = (T *) &h;
+ a[0] = a[1] = 6;
+ h.foo () ? void () : bar (7);
+}
+
+int
+main ()
+{
+ baz ();
+}
Jakub
[C PATCH] Fix error recovery ICEs (PR c/83595)
Hi!
As the patch shows, in lots of spots the C FE can return a c_expr
with error_mark_node value, but uninitialized locations, so if something
calls expr.get_location (), it can ICE.
Other spots are already using the set_error method which sets the value
to error_mark_node and in addition to that clears the locations.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-12-30 Jakub Jelinek
PR c/83595
* c-parser.c (c_parser_braced_init, c_parser_initelt,
c_parser_conditional_expression, c_parser_cast_expression,
c_parser_sizeof_expression, c_parser_alignof_expression,
c_parser_postfix_expression, c_parser_omp_declare_reduction,
c_parser_transaction_expression): Use set_error () method instead
of setting value member to error_mark_node.
* gcc.dg/pr83595.c: New test.
--- gcc/c/c-parser.c.jj 2017-12-22 11:38:07.781178925 +0100
+++ gcc/c/c-parser.c2017-12-30 15:22:25.638774453 +0100
@@ -4582,7 +4582,7 @@ c_parser_braced_init (c_parser *parser,
c_token *next_tok = c_parser_peek_token (parser);
if (next_tok->type != CPP_CLOSE_BRACE)
{
- ret.value = error_mark_node;
+ ret.set_error ();
ret.original_code = ERROR_MARK;
ret.original_type = NULL;
braces.skip_until_found_close (parser);
@@ -4649,7 +4649,7 @@ c_parser_initelt (c_parser *parser, stru
else
{
struct c_expr init;
- init.value = error_mark_node;
+ init.set_error ();
init.original_code = ERROR_MARK;
init.original_type = NULL;
c_parser_error (parser, "expected identifier");
@@ -4785,7 +4785,7 @@ c_parser_initelt (c_parser *parser, stru
else
{
struct c_expr init;
- init.value = error_mark_node;
+ init.set_error ();
init.original_code = ERROR_MARK;
init.original_type = NULL;
c_parser_error (parser, "expected %<=%>");
@@ -6693,7 +6693,7 @@ c_parser_conditional_expression (c_parse
if (!c_parser_require (parser, CPP_COLON, "expected %<:%>"))
{
c_inhibit_evaluation_warnings -= cond.value == truthvalue_true_node;
- ret.value = error_mark_node;
+ ret.set_error ();
ret.original_code = ERROR_MARK;
ret.original_type = NULL;
return ret;
@@ -7071,7 +7071,7 @@ c_parser_cast_expression (c_parser *pars
parens.skip_until_found_close (parser);
if (type_name == NULL)
{
- ret.value = error_mark_node;
+ ret.set_error ();
ret.original_code = ERROR_MARK;
ret.original_type = NULL;
return ret;
@@ -7297,7 +7297,7 @@ c_parser_sizeof_expression (c_parser *pa
struct c_expr ret;
c_inhibit_evaluation_warnings--;
in_sizeof--;
- ret.value = error_mark_node;
+ ret.set_error ();
ret.original_code = ERROR_MARK;
ret.original_type = NULL;
return ret;
@@ -7383,7 +7383,7 @@ c_parser_alignof_expression (c_parser *p
struct c_expr ret;
c_inhibit_evaluation_warnings--;
in_alignof--;
- ret.value = error_mark_node;
+ ret.set_error ();
ret.original_code = ERROR_MARK;
ret.original_type = NULL;
return ret;
@@ -7838,7 +7838,7 @@ c_parser_postfix_expression (c_parser *p
&& !targetm.fixed_point_supported_p ())
{
error_at (loc, "fixed-point types not supported for this target");
- expr.value = error_mark_node;
+ expr.set_error ();
}
break;
case CPP_CHAR:
@@ -17748,7 +17748,7 @@ c_parser_omp_declare_reduction (c_parser
struct c_expr initializer;
tree omp_priv = NULL_TREE, omp_orig = NULL_TREE;
bool bad = false;
- initializer.value = error_mark_node;
+ initializer.set_error ();
if (!c_parser_require (parser, CPP_CLOSE_PAREN, "expected %<)%>"))
bad = true;
else if (c_parser_next_token_is (parser, CPP_NAME)
@@ -18305,7 +18305,7 @@ c_parser_transaction_expression (c_parse
else
{
error:
- ret.value = error_mark_node;
+ ret.set_error ();
ret.original_code = ERROR_MARK;
ret.original_type = NULL;
}
--- gcc/testsuite/gcc.dg/pr83595.c.jj 2017-12-30 15:23:43.864797406 +0100
+++ gcc/testsuite/gcc.dg/pr83595.c 2017-12-30 15:23:24.898791837 +0100
@@ -0,0 +1,9 @@
+/* PR c/83595 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void
+foo ()
+{
+ (())((int){0); /* { dg-error "expected expression before" } */
+}
Jakub
[PATCH] Fix ICE with LOOP_VECTORIZED ifn (PR tree-optimization/83581)
Hi!
The problem on this testcase is that ldist pass changes some GIMPLE_CONDs
into 0 != 0 or similar, but the pass doesn't perform any cleanups, then
ifcvt is run and does completely useless work of duplicating dead loops
and guarding them with LOOP_VECTORIZED ifns, and then during the ifcvt
cfg cleanup the dead loops are optimized away, but nothing removes the
corresponding LOOP_VECTORIZED ifns. While perhaps we'll need to hook into
the loop removal and remove the dead ifns or remove the dead ifns during
vectorizer pass using a more expensive way at some point (e.g. by scanning
all bb's last insn for GIMPLE_COND checking LOOP_VECTORIZED) at some point,
in this case it seems to me clearly preferrable to let the ldist pass clean
up after itself, so that we don't do useless work in ifcvt from the
beginning.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-12-30 Jakub Jelinek
PR tree-optimization/83581
* tree-loop-distribution.c (pass_loop_distribution::execute): Return
TODO_cleanup_cfg if any changes have been made.
* gcc.dg/pr83581.c: New test.
--- gcc/tree-loop-distribution.c.jj 2017-12-21 09:43:17.486071696 +0100
+++ gcc/tree-loop-distribution.c2017-12-30 16:54:08.106143319 +0100
@@ -3103,7 +3103,7 @@ pass_loop_distribution::execute (functio
checking_verify_loop_structure ();
- return 0;
+ return changed ? TODO_cleanup_cfg : 0;
}
} // anon namespace
--- gcc/testsuite/gcc.dg/pr83581.c.jj 2017-12-30 16:55:35.950164947 +0100
+++ gcc/testsuite/gcc.dg/pr83581.c 2017-12-30 16:55:17.520160406 +0100
@@ -0,0 +1,21 @@
+/* PR tree-optimization/83581 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -fno-tree-copy-prop -fno-tree-loop-im" } */
+
+int a, b, c;
+
+int
+foo (int x)
+{
+ int *d = &x;
+ while (a < 1)
+{
+ for (b = 0; b < 2; ++b)
+{
+ *d += !!x + 1;
+ d = &c;
+}
+ ++a;
+}
+ return *d;
+}
Jakub
Re: [PATCH] expandargv: fix memory leak
On Sat, 30 Dec 2017 18:27:30 +0100
Andreas Schwab wrote:
> On Dez 30 2017, Daniel van Gerpen wrote:
>
> > When the responsefile's contents are interpolated into the argument
> > vector, the pointer to original option string ("@filename") became
> > lost. This caused a small leak for every responsefile on the
> > commandline.
>
> argv elements generally don't point to the heap.
No, but expandargv() copies argv to the heap and then inserts the contents of
the responsefile.
The libiberty testsuite uses "@test-expandargv-0.lst" as an argument:
valgrind --leak-check=full testsuite/test-expandargv
==15851== Memcheck, a memory error detector
==15851== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==15851== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==15851== Command: testsuite/test-expandargv
==15851==
PASS: test-expandargv-0.
PASS: test-expandargv-1.
PASS: test-expandargv-2.
PASS: test-expandargv-3.
PASS: test-expandargv-4.
PASS: test-expandargv-5.
PASS: test-expandargv-6.
==15851==
==15851== HEAP SUMMARY:
==15851== in use at exit: 602 bytes in 28 blocks
==15851== total heap usage: 145 allocs, 117 frees, 931,880 bytes allocated
==15851==
==15851== 23 bytes in 1 blocks are definitely lost in loss record 1 of 4
==15851==at 0x4C2DB2F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15851==by 0x10A037: xmalloc (xmalloc.c:147)
==15851==by 0x10A0F9: xstrdup (xstrdup.c:34)
==15851==by 0x1097C4: dupargv (argv.c:86)
==15851==by 0x109DBA: expandargv (argv.c:453)
==15851==by 0x109630: run_tests (test-expandargv.c:275)
==15851==by 0x10916F: main (test-expandargv.c:328)
[...]
Daniel
[PATCH] expandargv: fix check for dynamic allocation of argument vector
When the code interpolates the contents of response files, the
argument vector is reallocated to the new size. This only works
if it was dynamically allocated once before -- we do not want to
mess with the argv memory given to us by the init code.
The code tried to detect this with a flag, but that was never
written to, leading to multiple dynamic allocations -- one
for each response file.
---
libiberty/argv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libiberty/argv.c b/libiberty/argv.c
index bdd4ace4cb6..fa88e50e894 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -367,8 +367,8 @@ expandargv (int *argcp, char ***argvp)
{
/* The argument we are currently processing. */
int i = 0;
- /* Non-zero if ***argvp has been dynamically allocated. */
- int argv_dynamic = 0;
+ /* To check if ***argvp has been dynamically allocated. */
+ char ** const original_argv = *argvp;
/* Limit the number of response files that we parse in order
to prevent infinite recursion. */
unsigned int iteration_limit = 2000;
@@ -449,7 +449,7 @@ expandargv (int *argcp, char ***argvp)
/* Parse the string. */
file_argv = buildargv (buffer);
/* If *ARGVP is not already dynamically allocated, copy it. */
- if (!argv_dynamic)
+ if (*argvp == original_argv)
*argvp = dupargv (*argvp);
/* Count the number of arguments. */
file_argc = 0;
--
2.11.0
Re: [PATCH] PR 78534 Change character length from int to size_t
On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig wrote: > Hi Janne, > >> To be honest, I haven't really done much testing with big strings, so >> far my focus has been on getting the existing testsuite to pass and >> getting the ABI right. > > > I agree that some of the test cases can be fixed later. However, I > would really prefer if the I/O worked, because that is very basic > functionality, but also because this is (likely to be) an ABI issue. > If this bug remains unfixed for any reason at all, then we are left with > no choice but to break the ABI when we fix that bug. I would like to > avoid that, if possible. Fair enough. I took a look at the I/O example you provided, and at least that particular case is not due to an ABI issue, but rather that the formatted I/O stuff inside libgfortran extensively uses int for lengths. I managed to hack around it quickly to make your testcase work, but a proper fix, while straightforward, implies fixing up the types a bit more. But still only in the internals, the external ABI visible interface is ok. I can provide that stuff as a separate patch, or merge it into the original megapatch and resubmit that, whichever way you prefer. FWIW, by changing your example to use unformatted I/O, it works correctly. And as unformatted uses the same library entry points for transferring the data, this is thus further evidence that the problem is in the internals of the formatted I/O rather than in the ABI. -- Janne Blomqvist
Re: [PATCH] PR 78534 Change character length from int to size_t
On 12/30/2017 12:35 PM, Janne Blomqvist wrote: > On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig wrote: ---snip--- > > I can provide that stuff as a separate patch, or merge it into the > original megapatch and resubmit that, whichever way you prefer. I would prefer we split into two patches. This will make review of the library I/O changes easier. The int len is used in a lot of places also where it really happens to also be the kind (which is a length in our implementation). Janne I trust your judgment about where it makes sense to change to size_t. On Thomas earlier comment about adding a pointer to void to hold space for async. I am OK with this too, though I am not convinced we have really defined our async objective here. More later on that topic. Regards, Jerry
Re: [PATCH] Fix ICE with vector 16-bit rotate (PR middle-end/83623)
On December 30, 2017 8:27:44 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>Ths chunk of code wants to expand 16-bit rotate by 8 as bswaphi, but
>if mode is a vector mode (or complex mode), trying to use bswaphi
>pattern to
>swap say V16HImode vector is just wrong.
>
>This patch arranges to use bswapv16hi etc. instead in those cases,
>which
>isn't 100% clear to me from the docs if they only swap bytes of each of
>the
>vector element, but from looking at a few backends it seems like that
>is the
>case and if it wasn't, e.g. simplify-rtx.c would missimplify stuff.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
>2017-12-30 Jakub Jelinek
>
> PR middle-end/83623
> * expmed.c (expand_shift_1): For 2-byte rotates by BITS_PER_UNIT,
> check for bswap in mode rather than HImode and use that in expand_unop
> too.
>
> * gcc.dg/pr83623.c: New test.
>
>--- gcc/expmed.c.jj2017-12-20 20:40:18.0 +0100
>+++ gcc/expmed.c 2017-12-30 11:44:47.045433528 +0100
>@@ -2490,9 +2490,8 @@ expand_shift_1 (enum tree_code code, mac
> && CONST_INT_P (op1)
> && INTVAL (op1) == BITS_PER_UNIT
> && GET_MODE_SIZE (scalar_mode) == 2
>- && optab_handler (bswap_optab, HImode) != CODE_FOR_nothing)
>-return expand_unop (HImode, bswap_optab, shifted, NULL_RTX,
>-unsignedp);
>+ && optab_handler (bswap_optab, mode) != CODE_FOR_nothing)
>+return expand_unop (mode, bswap_optab, shifted, NULL_RTX,
>unsignedp);
>
> if (op1 == const0_rtx)
> return shifted;
>--- gcc/testsuite/gcc.dg/pr83623.c.jj 2017-12-30 11:49:23.259470538
>+0100
>+++ gcc/testsuite/gcc.dg/pr83623.c 2017-12-30 11:49:01.309467592 +0100
>@@ -0,0 +1,12 @@
>+/* PR middle-end/83623 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2" } */
>+/* { dg-additional-options "-mmovbe" { target i?86-*-* x86_64-*-* } }
>*/
>+
>+unsigned short __attribute__ ((__vector_size__ (16))) x;
>+
>+void
>+foo (void)
>+{
>+ x = x << 8 | x >> 8;
>+}
>
> Jakub
Re: [PATCH] Fix expand_assignment stores to CONCAT (PR middle-end/83609)
On December 30, 2017 8:31:59 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The first hunk before the if (!from...) part shows a typo I've made in
>a
>recent change, the last argument of simplify_gen_subreg is byte offset,
>and
>the subreg has same bitsize outer and inner modes, so using byte offset
>1
>makes no sense at all.
>Another issue that the testcase suffers from is that the
>simplify_gen_rtx
>(preexisting issue) can fail, and in that case trying to
>read_complex_part
>from that NULL will ICE. The patch tries harder by trying to simplify
>the
>2 halves separately, and for all cases when simplify_gen_subreg fails
>which
>can happen because of various reasons, there is the fallback to go
>through
>memory.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>trunk/7.3?
OK.
Richard.
>2017-12-30 Jakub Jelinek
>
> PR middle-end/83609
> * expr.c (expand_assignment): Fix up a typo in simplify_gen_subreg
> last argument when extracting from CONCAT. If either from_real or
> from_imag is NULL, use expansion through memory. If result is not
> a CONCAT and simplify_gen_subreg fails, try to simplify_gen_subreg
> the parts directly to inner mode, if even that fails, use expansion
> through memory.
>
> * gcc.dg/pr83609.c: New test.
> * g++.dg/opt/pr83609.C: New test.
>
>--- gcc/expr.c.jj 2017-12-21 09:43:19.797042465 +0100
>+++ gcc/expr.c 2017-12-30 13:49:19.634057445 +0100
>@@ -5158,7 +5158,9 @@ expand_assignment (tree to, tree from, b
> from_mode, 0);
> rtx from_imag
> = simplify_gen_subreg (to_mode, XEXP (result, 1),
>- from_mode, 1);
>+ from_mode, 0);
>+if (!from_real || !from_imag)
>+ goto concat_store_slow;
> emit_move_insn (XEXP (to_rtx, 0), from_real);
> emit_move_insn (XEXP (to_rtx, 1), from_imag);
> }
>@@ -5167,14 +5169,35 @@ expand_assignment (tree to, tree from, b
> rtx from_rtx
> = simplify_gen_subreg (GET_MODE (to_rtx), result,
> TYPE_MODE (TREE_TYPE (from)), 0);
>-emit_move_insn (XEXP (to_rtx, 0),
>-read_complex_part (from_rtx, false));
>-emit_move_insn (XEXP (to_rtx, 1),
>-read_complex_part (from_rtx, true));
>+if (from_rtx)
>+ {
>+emit_move_insn (XEXP (to_rtx, 0),
>+read_complex_part (from_rtx, false));
>+emit_move_insn (XEXP (to_rtx, 1),
>+read_complex_part (from_rtx, true));
>+ }
>+else
>+ {
>+machine_mode to_mode
>+ = GET_MODE_INNER (GET_MODE (to_rtx));
>+rtx from_real
>+ = simplify_gen_subreg (to_mode, result,
>+ TYPE_MODE (TREE_TYPE (from)),
>+ 0);
>+rtx from_imag
>+ = simplify_gen_subreg (to_mode, result,
>+ TYPE_MODE (TREE_TYPE (from)),
>+ GET_MODE_SIZE (to_mode));
>+if (!from_real || !from_imag)
>+ goto concat_store_slow;
>+emit_move_insn (XEXP (to_rtx, 0), from_real);
>+emit_move_insn (XEXP (to_rtx, 1), from_imag);
>+ }
> }
> }
> else
> {
>+ concat_store_slow:;
> rtx temp = assign_stack_temp (GET_MODE (to_rtx),
> GET_MODE_SIZE (GET_MODE (to_rtx)));
> write_complex_part (temp, XEXP (to_rtx, 0), false);
>--- gcc/testsuite/gcc.dg/pr83609.c.jj 2017-12-30 13:47:49.350044674
>+0100
>+++ gcc/testsuite/gcc.dg/pr83609.c 2017-12-30 13:42:52.227002619 +0100
>@@ -0,0 +1,29 @@
>+/* PR middle-end/83609 */
>+/* { dg-do run } */
>+/* { dg-options "-O2 -fno-tree-forwprop -fno-tree-ccp -fno-tree-fre
>-fno-tree-pre -fno-code-hoisting" } */
>+
>+#if __SIZEOF_LONG_LONG__ == 2 * __SIZEOF_FLOAT__
>+_Complex float
>+foo (void)
>+{
>+ _Complex float c;
>+ *((unsigned long long *)&c) = 0x123456789abcdef0ULL;
>+ return c;
>+}
>+
>+int
>+main ()
>+{
>+ union { _Complex float c; unsigned long long l; } u;
>+ u.c = foo ();
>+ if (u.l != 0x123456789abcdef0ULL)
>+__builtin_abort ();
>+ return 0;
>+}
>+#else
>+int
>+main ()
>+{
>+ return 0;
>+}
>+#endif
>--- gcc/testsuite/g++.dg/opt/pr83609.C.jj 2017-12-30 13:48:18.937048860
>+0100
>+++ gcc/testsuite/g++.dg/opt/pr83609.C 2017-12-30 13:46:25.968032868
>+0100
>@@ -0,0 +1,28 @@
>+
Re: [PATCH] Fix another ICE with complex assignment (PR middle-end/83608)
On December 30, 2017 8:35:09 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The comment on convert_modes says:
> Both modes may be floating, or both integer.
>but as the testcase shows, with a MEM_REF with a different mode class
>than a VAR_DECL as its operand we can end up with e.g. floating point
>vs.
>integral mode etc. and convert_modes doesn't handle those cases.
>
>This patch uses simplify_gen_subreg in those case first.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>trunk/7.3?
OK.
Richard.
>2017-12-30 Jakub Jelinek
>
> PR middle-end/83608
> * expr.c (store_expr_with_bounds): Use simplify_gen_subreg instead of
> convert_modes if target mode has the right side, but different mode
> class.
>
> * g++.dg/opt/pr83608.C: New test.
>
>--- gcc/expr.c.jj 2017-12-30 14:35:52.095877981 +0100
>+++ gcc/expr.c 2017-12-30 14:36:06.268882813 +0100
>@@ -5638,8 +5638,21 @@ store_expr_with_bounds (tree exp, rtx ta
> if (CONSTANT_P (temp) && GET_MODE (temp) == VOIDmode
> && TREE_CODE (exp) != ERROR_MARK
> && GET_MODE (target) != TYPE_MODE (TREE_TYPE (exp)))
>-temp = convert_modes (GET_MODE (target), TYPE_MODE (TREE_TYPE
>(exp)),
>-temp, TYPE_UNSIGNED (TREE_TYPE (exp)));
>+{
>+ if (GET_MODE_CLASS (GET_MODE (target))
>+!= GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (exp)))
>+&& GET_MODE_BITSIZE (GET_MODE (target))
>+ == GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (exp
>+ {
>+rtx t = simplify_gen_subreg (GET_MODE (target), temp,
>+ TYPE_MODE (TREE_TYPE (exp)), 0);
>+if (t)
>+ temp = t;
>+ }
>+ if (GET_MODE (temp) == VOIDmode)
>+ temp = convert_modes (GET_MODE (target), TYPE_MODE (TREE_TYPE (exp)),
>+temp, TYPE_UNSIGNED (TREE_TYPE (exp)));
>+}
>
> /* If value was not generated in the target, store it there.
> Convert the value to TARGET's type first if necessary and emit the
>--- gcc/testsuite/g++.dg/opt/pr83608.C.jj 2017-12-30 14:36:52.323898522
>+0100
>+++ gcc/testsuite/g++.dg/opt/pr83608.C 2017-12-30 14:00:12.811195532
>+0100
>@@ -0,0 +1,28 @@
>+// PR middle-end/83608
>+// { dg-do compile }
>+// { dg-options "-O2" }
>+
>+template class B;
>+template <> struct B
>+{
>+ float foo () { return __real__ b; }
>+ _Complex double b;
>+};
>+
>+void bar (int);
>+
>+template
>+void
>+baz ()
>+{
>+ B h;
>+ T *a = (T *) &h;
>+ a[0] = a[1] = 6;
>+ h.foo () ? void () : bar (7);
>+}
>+
>+int
>+main ()
>+{
>+ baz ();
>+}
>
> Jakub
Re: [PATCH] Fix ICE with LOOP_VECTORIZED ifn (PR tree-optimization/83581)
On December 30, 2017 8:42:06 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The problem on this testcase is that ldist pass changes some
>GIMPLE_CONDs
>into 0 != 0 or similar, but the pass doesn't perform any cleanups, then
>ifcvt is run and does completely useless work of duplicating dead loops
>and guarding them with LOOP_VECTORIZED ifns, and then during the ifcvt
>cfg cleanup the dead loops are optimized away, but nothing removes the
>corresponding LOOP_VECTORIZED ifns. While perhaps we'll need to hook
>into
>the loop removal and remove the dead ifns or remove the dead ifns
>during
>vectorizer pass using a more expensive way at some point (e.g. by
>scanning
>all bb's last insn for GIMPLE_COND checking LOOP_VECTORIZED) at some
>point,
>in this case it seems to me clearly preferrable to let the ldist pass
>clean
>up after itself, so that we don't do useless work in ifcvt from the
>beginning.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
>2017-12-30 Jakub Jelinek
>
> PR tree-optimization/83581
> * tree-loop-distribution.c (pass_loop_distribution::execute): Return
> TODO_cleanup_cfg if any changes have been made.
>
> * gcc.dg/pr83581.c: New test.
>
>--- gcc/tree-loop-distribution.c.jj2017-12-21 09:43:17.486071696 +0100
>+++ gcc/tree-loop-distribution.c 2017-12-30 16:54:08.106143319 +0100
>@@ -3103,7 +3103,7 @@ pass_loop_distribution::execute (functio
>
> checking_verify_loop_structure ();
>
>- return 0;
>+ return changed ? TODO_cleanup_cfg : 0;
> }
>
> } // anon namespace
>--- gcc/testsuite/gcc.dg/pr83581.c.jj 2017-12-30 16:55:35.950164947
>+0100
>+++ gcc/testsuite/gcc.dg/pr83581.c 2017-12-30 16:55:17.520160406 +0100
>@@ -0,0 +1,21 @@
>+/* PR tree-optimization/83581 */
>+/* { dg-do compile } */
>+/* { dg-options "-O3 -fno-tree-copy-prop -fno-tree-loop-im" } */
>+
>+int a, b, c;
>+
>+int
>+foo (int x)
>+{
>+ int *d = &x;
>+ while (a < 1)
>+{
>+ for (b = 0; b < 2; ++b)
>+{
>+ *d += !!x + 1;
>+ d = &c;
>+}
>+ ++a;
>+}
>+ return *d;
>+}
>
> Jakub
