[Bug target/93418] [9 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] GCC |[9 Regression] GCC |incorrectly constant|incorrectly constant |propagates |propagates |_mm_sllv/srlv/srav |_mm_sllv/srlv/srav --- Comment #10 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bff948aa337807260344c83ac9079d6386410094
commit r10-6273-gbff948aa337807260344c83ac9079d6386410094
Author: Jakub Jelinek
Date: Tue Jan 28 08:46:23 2020 +0100
i386: Fix ix86_fold_builtin shift folding [PR93418]
The following testcase is miscompiled, because the variable shift left
operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
we call builder.new_unary_operation, builder.encoded_nelts () will be just
1
and thus we encode the resulting vector as if all the elements were the
same.
For non-masked is_vshift, we could perhaps call
builder.new_binary_operation
(TREE_TYPE (args[0]), args[0], args[1], false), but then there are masked
shifts, for non-is_vshift we could perhaps call it too but with args[2]
instead of args[1], but there is no builder.new_ternary_operation.
All this stuff is primarily for aarch64 anyway, on x86 we don't have any
variable length vectors, and it is not a big deal to compute all elements
and just let builder.finalize () find the most efficient VECTOR_CST
representation of the vector. So, instead of doing too much, this just
keeps using new_unary_operation only if only one VECTOR_CST is involved
(i.e. non-masked shift by constant) and for the rest just compute all elts.
2020-01-28 Jakub Jelinek
PR target/93418
* config/i386/i386.c (ix86_fold_builtin) : If mask is not
-1 or is_vshift is true, use new_vector with number of elts npatterns
rather than new_unary_operation.
* gcc.target/i386/avx2-pr93418.c: New test.
[Bug tree-optimization/93454] [10 Regression] buffer overflow in fold_array_ctor_reference since r10-1882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93454 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/93454] [10 Regression] buffer overflow in fold_array_ctor_reference since r10-1882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93454 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3c076c9642fd8877def0a0597ec7e4adfb5aa3b3 commit r10-6272-g3c076c9642fd8877def0a0597ec7e4adfb5aa3b3 Author: Jakub Jelinek Date: Tue Jan 28 08:44:07 2020 +0100 gimple-fold: Fix buffer overflow in fold_array_ctor_reference [PR93454] libgcrypt FAILs to build on aarch64-linux with *** stack smashing detected ***: terminated when gcc is compiled with -D_FORTIFY_SOURCE=2. The problem is if fold_array_ctor_reference is called with size equal to or very close to MAX_BITSIZE_MODE_ANY_MODE bits and non-zero inner_offset. The first native_encode_expr is called with that inner_offset and bufoff 0, the subsequent ones with offset of 0, and bufoff elt_size - inner_offset, 2 * elt_size - inner_offset etc. So, e.g. on the testcase where we start with inner_offset 1 and size is e.g. 256 bytes and elt_size 4 bytes we then call native_encode_expr at bufoff 251 and then 255, but that one overwrites 3 bytes beyond the buf array. The following patch fixes that. In addition, it avoids calling elt_size.to_uhwi () all the time, and punts if elt_sz would be too large. 2020-01-28 Jakub Jelinek PR tree-optimization/93454 * gimple-fold.c (fold_array_ctor_reference): Perform elt_size.to_uhwi () just once, instead of calling it in every iteration. Punt if that value is above size of the temporary buffer. Decrease third native_encode_expr argument when bufoff + elt_sz is above size of buf. * gcc.dg/pr93454.c: New test.
[Bug middle-end/93399] [8/9/10 Regression] Annotate assembler option failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93399 --- Comment #5 from Alexandre Oliva --- I suppose it would make sense for str_pattern_slim to quote line breaks and other active characters when printing out string literals. And perhaps to eliminate one more use of str_pattern_slim while at that...
Re: [PATCH] calls.c: refactor special_function_p for use by analyzer
On Mon, Jan 27, 2020 at 09:09:37PM -0500, David Malcolm wrote: > > Please see calls.c (special_function_p), you should treat certainly > > also sigsetjmp as a setjmp call, and similarly to special_function_p, > > skip over _ or __ prefixes before the setjmp or sigsetjmp name. > > Similarly for longjmp/siglongjmp. > > This patch refactors some code in special_function_p that checks for > the function being sane to match by name, splitting it out into a new > maybe_special_function_p, and using it it two places in the analyzer. > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; > OK for master? Not sure it is worth it to factor out the DECL_NAME (fndecl) && (DECL_CONTEXT (fndecl) == NULL_TREE || TREE_CODE (DECL_CONTEXT (fndecl)) == TRANSLATION_UNIT_DECL) && TREE_PUBLIC (fndecl) check, that seems like simple enough that it could be duplicated. And, even if there is a strong reason not to, at least it ought to be defined inline in the header, not everyone will use LTO and without LTO it will need to be an out of line call. Ack on removing the fndecl && check from special_function_p, the callers ensure it is non-NULL already, and even if they didn't, after the if (fndecl && ...) guarded if there is unconditional dereferencing of fndecl. Jakub
Re: [PATCH] doc: clarify the situation with pointer arithmetic
On Tue, 28 Jan 2020, Uecker, Martin wrote: > > (*) this also shows the level of "obfuscation" needed to fool compilers > > to lose provenance knowledge is hard to predict. > > Well, this is exactly the problem we want to address by defining > a clear way to do this. Casting to an integer would be the way > to state: "consider the pointer as escaped and forget the > provenance" and casting an integer to a pointer would > mean "this pointer may point to all objects whose pointer has > escaped". This would give the programmer explicit control about > this aspect and make most existing code using pointer-to-integer > casts well-defined. At the same time, this should be simple > to add to existing points-to analysis. Can you explain why you make it required for the compiler to treat the points-to set unnecessarily broader than it could prove? In the Matlab example, there's a simple chain of computations that the compiler is following to prove that the pointer resulting from the final cast is derived from exactly one other pointer (no other pointers have participated in the computations). Or, in other words: is there an example where a programmer can distinguish between the requirement you explain above vs. the fine-grained interpretation that GIMPLE aims to implement (at least as I understand it), which is: when the program creates a pointer by means of non-pointer computations (casts, representation access, etc), the resulting pointer may point to: * any object which address could have participated in the computation (which is at worst the entire set of "exposed" objects up to that program point, but can be much narrower if the compiler can see the entire chain of computations) * any objects which is not "exposed" but could have known address, e.g. because it is placed at a specific address during linking Thanks. Alexander
[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272 --- Comment #5 from Andreas Krebbel --- (In reply to Vladimir Makarov from comment #4) > (In reply to Andreas Krebbel from comment #3) > > Created attachment 47714 [details] > > IRA EH fix - only when added at start of BB > > > > A probably better version of the fix. This version only reverts the > > allocation decision if the move is about to be added at the start of an EH > > basic block. > > Andreas, thank you for explaining the problem. Your patch should solve the > problem but my worry is that the final assignment can be worse (especially > if the pseudo in a loop goes into an EH bb). > > I think that such pseudo should have the right conflicting hard regnos > **before** the assignment. In this case the pseudo did not get a hard > register living into EH but still can get another hard register. > If you don't mind, I will take it from here and try to create such patch. > If you want to continue this work by yourself, please let me know. Please do. Thanks!
Re: [PATCH] i386: Don't use ix86_tune_ctrl_string in parse_mtune_ctrl_str
On Mon, Jan 27, 2020 at 3:13 PM H.J. Lu wrote:
>
> There are
>
> static void
> parse_mtune_ctrl_str (bool dump)
> {
> if (!ix86_tune_ctrl_string)
> return;
>
> parse_mtune_ctrl_str is only called from set_ix86_tune_features, which
> is only called from ix86_function_specific_restore and
> ix86_option_override_internal. parse_mtune_ctrl_str shouldn't use
> ix86_tune_ctrl_string which is defined with global_options. Instead,
> opts should be passed to parse_mtune_ctrl_str.
>
> PR target/91399
> * config/i386/i386-options.c (set_ix86_tune_features): Add an
> argument of a pointer to struct gcc_options and pass it to
> parse_mtune_ctrl_str.
> (ix86_function_specific_restore): Pass opts to
> set_ix86_tune_features.
> (ix86_option_override_internal): Likewise.
> (parse_mtune_ctrl_str): Add an argument of a pointer to struct
> gcc_options and use it for x_ix86_tune_ctrl_string.
Rubberstamp OK. I don't know this part well, but looks somehow obvious.
Thanks,
Uros.
> ---
> gcc/config/i386/i386-options.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> index 2acc9fb0cfe..e0be4932534 100644
> --- a/gcc/config/i386/i386-options.c
> +++ b/gcc/config/i386/i386-options.c
> @@ -741,7 +741,8 @@ ix86_option_override_internal (bool main_args_p,
>struct gcc_options *opts,
>struct gcc_options *opts_set);
> static void
> -set_ix86_tune_features (enum processor_type ix86_tune, bool dump);
> +set_ix86_tune_features (struct gcc_options *opts,
> + enum processor_type ix86_tune, bool dump);
>
> /* Restore the current options */
>
> @@ -810,7 +811,7 @@ ix86_function_specific_restore (struct gcc_options *opts,
>
>/* Recreate the tune optimization tests */
>if (old_tune != ix86_tune)
> -set_ix86_tune_features (ix86_tune, false);
> +set_ix86_tune_features (opts, ix86_tune, false);
> }
>
> /* Adjust target options after streaming them in. This is mainly about
> @@ -1538,13 +1539,13 @@ ix86_parse_stringop_strategy_string (char
> *strategy_str, bool is_memset)
> print the features that are explicitly set. */
>
> static void
> -parse_mtune_ctrl_str (bool dump)
> +parse_mtune_ctrl_str (struct gcc_options *opts, bool dump)
> {
> - if (!ix86_tune_ctrl_string)
> + if (!opts->x_ix86_tune_ctrl_string)
> return;
>
>char *next_feature_string = NULL;
> - char *curr_feature_string = xstrdup (ix86_tune_ctrl_string);
> + char *curr_feature_string = xstrdup (opts->x_ix86_tune_ctrl_string);
>char *orig = curr_feature_string;
>int i;
>do
> @@ -1583,7 +1584,8 @@ parse_mtune_ctrl_str (bool dump)
> processor type. */
>
> static void
> -set_ix86_tune_features (enum processor_type ix86_tune, bool dump)
> +set_ix86_tune_features (struct gcc_options *opts,
> + enum processor_type ix86_tune, bool dump)
> {
>unsigned HOST_WIDE_INT ix86_tune_mask = HOST_WIDE_INT_1U << ix86_tune;
>int i;
> @@ -1605,7 +1607,7 @@ set_ix86_tune_features (enum processor_type ix86_tune,
> bool dump)
> ix86_tune_features[i] ? "on" : "off");
> }
>
> - parse_mtune_ctrl_str (dump);
> + parse_mtune_ctrl_str (opts, dump);
> }
>
>
> @@ -2364,7 +2366,7 @@ ix86_option_override_internal (bool main_args_p,
>XDELETEVEC (s);
> }
>
> - set_ix86_tune_features (ix86_tune, opts->x_ix86_dump_tunes);
> + set_ix86_tune_features (opts, ix86_tune, opts->x_ix86_dump_tunes);
>
>ix86_recompute_optlev_based_flags (opts, opts_set);
>
> --
> 2.24.1
>
Re: [PATCH] i386: Disable TARGET_SSE_TYPELESS_STORES for TARGET_AVX
On Mon, Jan 27, 2020 at 11:17 PM H.J. Lu wrote:
>
> On Mon, Jan 27, 2020 at 12:26 PM Uros Bizjak wrote:
> >
> > On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote:
> > >
> > > movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the
> > > case for AVX nor AVX512. We should disable TARGET_SSE_TYPELESS_STORES
> > > for TARGET_AVX.
> > >
> > > gcc/
> > >
> > > PR target/91461
> > > * config/i386/i386.h (TARGET_SSE_TYPELESS_STORES): Disable for
> > > TARGET_AVX.
> > > * config/i386/i386.md (*movoi_internal_avx): Remove
> > > TARGET_SSE_TYPELESS_STORES check.
> > >
> > > gcc/testsuite/
> > >
> > > PR target/91461
> > > * gcc.target/i386/pr91461-1.c: New test.
> > > * gcc.target/i386/pr91461-2.c: Likewise.
> > > * gcc.target/i386/pr91461-3.c: Likewise.
> > > * gcc.target/i386/pr91461-4.c: Likewise.
> > > * gcc.target/i386/pr91461-5.c: Likewise.
> > > ---
> > > gcc/config/i386/i386.h| 4 +-
> > > gcc/config/i386/i386.md | 4 +-
> > > gcc/testsuite/gcc.target/i386/pr91461-1.c | 66
> > > gcc/testsuite/gcc.target/i386/pr91461-2.c | 19 ++
> > > gcc/testsuite/gcc.target/i386/pr91461-3.c | 76 +++
> > > gcc/testsuite/gcc.target/i386/pr91461-4.c | 21 +++
> > > gcc/testsuite/gcc.target/i386/pr91461-5.c | 17 +
> > > 7 files changed, 203 insertions(+), 4 deletions(-)
> > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-1.c
> > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-2.c
> > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-3.c
> > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-4.c
> > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-5.c
> > >
> > > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> > > index 943e9a5c783..c134b04c5c4 100644
> > > --- a/gcc/config/i386/i386.h
> > > +++ b/gcc/config/i386/i386.h
> > > @@ -516,8 +516,10 @@ extern unsigned char
> > > ix86_tune_features[X86_TUNE_LAST];
> > > #define TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL \
> > > ix86_tune_features[X86_TUNE_SSE_PACKED_SINGLE_INSN_OPTIMAL]
> > > #define TARGET_SSE_SPLIT_REGS
> > > ix86_tune_features[X86_TUNE_SSE_SPLIT_REGS]
> > > +/* NB: movaps/movups is one byte shorter than movdaq/movdqu. But it
> > > + isn't the case for AVX nor AVX512. */
> > > #define TARGET_SSE_TYPELESS_STORES \
> > > - ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES]
> > > + (!TARGET_AVX && ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES])
> >
> > This is wrong place to disable the feature.
>
> Like this?
No.
There is a mode attribute in i386.md/sse.md for relevant patterns.
Please adapt calculation of mode attributes instead.
Uros.
> diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> index 2acc9fb0cfe..639969d736d 100644
> --- a/gcc/config/i386/i386-options.c
> +++ b/gcc/config/i386/i386-options.c
> @@ -1597,6 +1597,11 @@ set_ix86_tune_features (enum processor_type
> ix86_tune, bool dump)
> = !!(initial_ix86_tune_features[i] & ix86_tune_mask);
> }
>
> + /* NB: movaps/movups is one byte shorter than movdaq/movdqu. But it
> + isn't the case for AVX nor AVX512. */
> + if (TARGET_AVX)
> +ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES] = 0;
> +
>if (dump)
> {
>fprintf (stderr, "List of x86 specific tuning parameter names:\n");
>
>
> --
> H.J.
[Bug c++/92169] crash on referring to a local class member by unqualified name from outside the enclosing function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92169
Dmitry G. Dyachenko changed:
What|Removed |Added
CC||dimhen at gmail dot com
--- Comment #1 from Dmitry G. Dyachenko ---
r257061 PASS for me
r10-6221-g53d172975f269138ba227f6d4560950265c36df8 PASS too
g++ -std=c++{14,17,2a} -fchecking=2 -Ofast -c x.cc
[Bug target/92137] [ia32] Missing documentation for ia32 builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92137 --- Comment #7 from Eric Gallager --- (In reply to Ariel Torti from comment #6) > (In reply to Eric Gallager from comment #5) > > (In reply to Jakub Jelinek from comment #3) > > > Those are intrinsics and most of them are documented in the Intel > > > architecture manuals, or various web sites. Not sure it is a good idea to > > > duplicate that documentation. > > > > Might be worthwhile to at least provide a link to the manuals or websites > > then, if we're not going to duplicate the info contained in them... > > Could you provide an example on how you would add them ? I'm pretty sure the file to edit would be gcc/doc/extend.texi; it's written in texinfo, so standard texinfo URL syntax would probably be the way to go. There are already some other URLs in the file, so you can just grep for "https://; and then copy the markup around them to add your own links.
[PATCH, libphobos] Fix compilation dependencies on s390x-linux-musl
Hi,
This patch fixes GDC on s390x-linux-musl targets. It was specifically
tested under Alpine Linux (see
https://gitlab.alpinelinux.org/alpine/aports/commit/c123e0f14ab73976a36c651d47d134f249413f29
).
The patch fixes two issues: First, Musl always provide
`__tls_get_addr`, so we can always use it to get the TLS range instead
of the internal function (which is glibc-specific).
Second, druntime provide an ASM implementation for
`fiber_switchContext` for most platform under
libphobos/libdruntime/config/$ARCH/switchcontext.S, and default to
`swapcontext` when not available, which is the case on s390x.
However, the configure script did not depend on `swapcontext` being
present, as it's part of glibc, but not Musl (there is a libucontext
available on Alpine for this), which is added here.
@Iain: Any chance those could be backported to v9 ?
---
Mathias Lang
---
libphobos/ChangeLog:
* libdruntime/gcc/sections/elf_shared.d Always use
__tls_get_addr on Musl.
* configure.ac: Search librairies for swapcontext when
LIBDRUNTIME_NEEDS_UCONTEXT is yes.
* configure.tgt: Set LIBDRUNTIME_NEEDS_UCONTEXT on s390*-linux*.
* configure: Regenerate.
---
diff -Nurp a/libphobos/libdruntime/gcc/sections/elf_shared.d
b/libphobos/libdruntime/gcc/sections/elf_shared.d
--- a/libphobos/libdruntime/gcc/sections/elf_shared.d
+++ b/libphobos/libdruntime/gcc/sections/elf_shared.d
@@ -1084,7 +1084,9 @@ void[] getTLSRange(size_t mod, size_t sz) nothrow @nogc
// base offset
auto ti = tls_index(mod, 0);
-version (IBMZ_Any)
+version (CRuntime_Musl)
+return (__tls_get_addr()-TLS_DTV_OFFSET)[0 .. sz];
+else version (IBMZ_Any)
{
auto idx = cast(void *)__tls_get_addr_internal()
+ cast(ulong)__builtin_thread_pointer();
diff -Nurp a/libphobos/configure.ac b/libphobos/configure.ac
--- a/libphobos/configure.ac
+++ b/libphobos/configure.ac
@@ -140,6 +140,14 @@ case ${host} in
esac
AC_MSG_RESULT($LIBPHOBOS_SUPPORTED)
+AC_MSG_CHECKING([if target needs to link in swapcontext])
+AC_MSG_RESULT($LIBDRUNTIME_NEEDS_UCONTEXT)
+AS_IF([test "x$LIBDRUNTIME_NEEDS_UCONTEXT" = xyes], [
+ AC_SEARCH_LIBS([swapcontext], [c ucontext], [], [
+ AC_MSG_ERROR([[can't find library providing swapcontext]])
+ ])
+])
+
# Decide if it's usable.
case $LIBPHOBOS_SUPPORTED:$enable_libphobos in
*:no) use_libphobos=no ;;
diff -Nurp a/libphobos/configure.tgt b/libphobos/configure.tgt
--- a/libphobos/configure.tgt
+++ b/libphobos/configure.tgt
@@ -22,6 +22,13 @@
# Disable the libphobos or libdruntime components on untested or known
# broken systems. More targets shall be added after testing.
LIBPHOBOS_SUPPORTED=no
+
+# Check if we require 'ucontext' or if we have a custom solution.
+# Most platform uses a custom assembly solution for context switches,
+# see `core.thread` and grep for `AsmExternal`.
+# Definitions are in config/ARCH/
+LIBDRUNTIME_NEEDS_UCONTEXT=no
+
case "${target}" in
aarch64*-*-linux*)
LIBPHOBOS_SUPPORTED=yes
@@ -37,6 +44,7 @@ case "${target}" in
;;
s390*-linux*)
LIBPHOBOS_SUPPORTED=yes
+ LIBDRUNTIME_NEEDS_UCONTEXT=yes
;;
x86_64-*-kfreebsd*-gnu | i?86-*-kfreebsd*-gnu)
LIBPHOBOS_SUPPORTED=yes
[Bug c/93476] int bit fields waste space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93476 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This is the ABI that specifies the size/alignment of the structs. GCC is just following that. The alignment of the struct with an int field is 4 bytes on most if not all targets where the sizeof(int) == 4.
[Bug c/93476] New: int bit fields waste space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93476
Bug ID: 93476
Summary: int bit fields waste space
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: doug at cs dot dartmouth.edu
Target Milestone: ---
sizeof(struct{ unsigned int a:2; }) is 4. 3 out of the 4
bytes are gratuitously wasted.
A workaround is struct{ unsigned char a:2; }, whose size is 1,
but this is implementation-defined syntax and not portable.
[Bug c++/93475] New: With 100k+ mangled names, appears to incorrectly mangle about 15% causing demangle failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93475 Bug ID: 93475 Summary: With 100k+ mangled names, appears to incorrectly mangle about 15% causing demangle failure Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: simonhf at gmail dot com Target Milestone: --- When looking at over 100k mangled C++ names, many of them fail to demangle using common command line tools. Initially I thought this was the fault of the demangler and opened a bug here [1]. However, after opening a similar bug here [2] for the LLVM demangler, a detailed response from LLVM developers appears to suggest that g++ itself is mangling incorrect, so I opened this bug! [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93035 [2] https://bugs.llvm.org/show_bug.cgi?id=44428
[PATCH] calls.c: refactor special_function_p for use by analyzer
On Wed, 2020-01-22 at 20:40 +0100, Jakub Jelinek wrote:
> On Wed, Jan 22, 2020 at 02:35:13PM -0500, David Malcolm wrote:
> > PR analyzer/93316 reports various testsuite failures where I
> > accidentally relied on properties of x86_64-pc-linux-gnu.
> >
> > The following patch fixes them on sparc-sun-solaris2.11 (gcc211 in
> > the
> > GCC compile farm), and, I hope, the other configurations showing
> > failures.
> >
> > There may still be other failures for pattern-test-2.c, which I'm
> > tracking separately as PR analyzer/93291.
> >
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
> > tested on stage 1 on sparc-sun-solaris2.11.
> >
> > gcc/analyzer/ChangeLog:
> > PR analyzer/93316
> > * analyzer.cc (is_setjmp_call_p): Check for "setjmp" as well as
> > "_setjmp".
>
> Please see calls.c (special_function_p), you should treat certainly
> also sigsetjmp as a setjmp call, and similarly to special_function_p,
> skip over _ or __ prefixes before the setjmp or sigsetjmp name.
> Similarly for longjmp/siglongjmp.
>
> Jakub
This patch refactors some code in special_function_p that checks for
the function being sane to match by name, splitting it out into a new
maybe_special_function_p, and using it it two places in the analyzer.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
OK for master?
Thanks
Dave
gcc/analyzer/ChangeLog:
* analyzer.cc (is_named_call_p): Replace tests for fndecl being
extern at file scope and having a non-NULL DECL_NAME with a call
to maybe_special_function_p.
* function-set.cc (function_set::contains_decl_p): Add call to
maybe_special_function_p.
gcc/ChangeLog:
* calls.c (maybe_special_function_p): New function, splitting out
the check for DECL_NAME being non-NULL and fndecl being extern at
file scope from...
(special_function_p): ...here. Drop check for fndecl being
non-NULL that was after a usage of DECL_NAME (fndecl).
* tree.h (maybe_special_function_p): New decl.
---
gcc/analyzer/analyzer.cc | 10 +
gcc/analyzer/function-set.cc | 2 ++
gcc/calls.c | 40 +---
gcc/tree.h | 2 ++
4 files changed, 33 insertions(+), 21 deletions(-)
diff --git a/gcc/analyzer/analyzer.cc b/gcc/analyzer/analyzer.cc
index 1b5e4c9ecf8..5cf745ea632 100644
--- a/gcc/analyzer/analyzer.cc
+++ b/gcc/analyzer/analyzer.cc
@@ -65,18 +65,10 @@ is_named_call_p (tree fndecl, const char *funcname)
gcc_assert (fndecl);
gcc_assert (funcname);
- /* Exclude functions not at the file scope, or not `extern',
- since they are not the magic functions we would otherwise
- think they are. */
- if (!((DECL_CONTEXT (fndecl) == NULL_TREE
-|| TREE_CODE (DECL_CONTEXT (fndecl)) == TRANSLATION_UNIT_DECL)
- && TREE_PUBLIC (fndecl)))
+ if (!maybe_special_function_p (fndecl))
return false;
tree identifier = DECL_NAME (fndecl);
- if (identifier == NULL)
-return false;
-
const char *name = IDENTIFIER_POINTER (identifier);
const char *tname = name;
diff --git a/gcc/analyzer/function-set.cc b/gcc/analyzer/function-set.cc
index 6ed15ae95ad..1b6b5d9f9c1 100644
--- a/gcc/analyzer/function-set.cc
+++ b/gcc/analyzer/function-set.cc
@@ -59,6 +59,8 @@ bool
function_set::contains_decl_p (tree fndecl) const
{
gcc_assert (fndecl && DECL_P (fndecl));
+ if (!maybe_special_function_p (fndecl))
+return false;
return contains_name_p (IDENTIFIER_POINTER (DECL_NAME (fndecl)));
}
diff --git a/gcc/calls.c b/gcc/calls.c
index 1336f49ea5e..447a36c3707 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -572,22 +572,18 @@ emit_call_1 (rtx funexp, tree fntree ATTRIBUTE_UNUSED,
tree fndecl ATTRIBUTE_UNU
anti_adjust_stack (gen_int_mode (n_popped, Pmode));
}
-/* Determine if the function identified by FNDECL is one with
- special properties we wish to know about. Modify FLAGS accordingly.
-
- For example, if the function might return more than one time (setjmp), then
- set ECF_RETURNS_TWICE.
+/* Determine if the function identified by FNDECL is one that
+ makes sense to match by name, for those places where we detect
+ "magic" functions by name.
- Set ECF_MAY_BE_ALLOCA for any memory allocation function that might allocate
- space from the stack such as alloca. */
+ Return true if FNDECL has a name and is an extern fndecl at file scope.
+ FNDECL must be a non-NULL decl. */
-static int
-special_function_p (const_tree fndecl, int flags)
+bool
+maybe_special_function_p (const_tree fndecl)
{
tree name_decl = DECL_NAME (fndecl);
-
- if (fndecl && name_decl
- && IDENTIFIER_LENGTH (name_decl) <= 11
+ if (name_decl
/* Exclude functions not at the file scope, or not `extern',
since they are not the magic functions we would otherwise
think they are.
@@ -598,6 +594,26 @@ special_function_p (const_tree fndecl, int flags)
[Bug middle-end/82407] [meta-bug] qsort_chk fallout tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407 Bug 82407 depends on bug 93451, which changed state. Bug 93451 Summary: ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93451 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/93451] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93451 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug preprocessor/93452] [10 Regression] __has_include changes broke compilation of -fdirectives-only preprocessed sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93452 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-28 CC||nathan at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |blocker --- Comment #2 from Andrew Pinski --- .
[committed] analyzer: fix ICE when canonicalizing NaN (PR 93451)
PR analyzer/93451 reports an ICE when canonicalizing the constants
in a region_model, with a failed qsort_chk when attempting to sort
the constants within the region_model.
The svalues in the model were:
sv0: {poisoned: uninit}
sv1: {type: ‘double’, ‘0.0’}
sv2: {type: ‘double’, ‘1.0e+0’}
sv3: {type: ‘double’, ‘ Nan’}
The qsort_chk of the 3 constants fails due to tree_cmp using the
LT_EXPR ordering of the REAL_CSTs, which doesn't work for NaN.
This patch adjusts tree_cmp to impose an arbitrary ordering during
canonicalization for UNORDERED_EXPR cases w/o relying on the LT_EXPR
ordering, fixing the ICE.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
committed to master as r10-6271-g8c08c983015e675f555d57a30e15d918abef2b93.
gcc/analyzer/ChangeLog:
PR analyzer/93451
* region-model.cc (tree_cmp): For the REAL_CST case, impose an
arbitrary order on NaNs relative to other NaNs and to non-NaNs;
const-correctness tweak.
(ana::selftests::build_real_cst_from_string): New function.
(ana::selftests::append_interesting_constants): New function.
(ana::selftests::test_tree_cmp_on_constants): New test.
(ana::selftests::test_canonicalization_4): New test.
(ana::selftests::analyzer_region_model_cc_tests): Call the new
tests.
gcc/testsuite/ChangeLog:
PR analyzer/93451
* gcc.dg/analyzer/torture/pr93451.c: New test.
---
gcc/analyzer/region-model.cc | 90 ++-
.../gcc.dg/analyzer/torture/pr93451.c | 14 +++
2 files changed, 101 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/torture/pr93451.c
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index a986549b597..62c96a6ceea 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -1811,11 +1811,22 @@ tree_cmp (const_tree t1, const_tree t2)
case REAL_CST:
{
- real_value *rv1 = TREE_REAL_CST_PTR (t1);
- real_value *rv2 = TREE_REAL_CST_PTR (t2);
+ const real_value *rv1 = TREE_REAL_CST_PTR (t1);
+ const real_value *rv2 = TREE_REAL_CST_PTR (t2);
+ if (real_compare (UNORDERED_EXPR, rv1, rv2))
+ {
+ /* Impose an arbitrary order on NaNs relative to other NaNs
+ and to non-NaNs. */
+ if (int cmp_isnan = real_isnan (rv1) - real_isnan (rv2))
+ return cmp_isnan;
+ if (int cmp_issignaling_nan
+ = real_issignaling_nan (rv1) - real_issignaling_nan (rv2))
+ return cmp_issignaling_nan;
+ return real_isneg (rv1) - real_isneg (rv2);
+ }
if (real_compare (LT_EXPR, rv1, rv2))
return -1;
- if (real_compare (LT_EXPR, rv2, rv1))
+ if (real_compare (GT_EXPR, rv1, rv2))
return 1;
return 0;
}
@@ -6927,6 +6938,58 @@ namespace ana {
namespace selftest {
+/* Build a constant tree of the given type from STR. */
+
+static tree
+build_real_cst_from_string (tree type, const char *str)
+{
+ REAL_VALUE_TYPE real;
+ real_from_string (, str);
+ return build_real (type, real);
+}
+
+/* Append various "interesting" constants to OUT (e.g. NaN). */
+
+static void
+append_interesting_constants (auto_vec *out)
+{
+ out->safe_push (build_int_cst (integer_type_node, 0));
+ out->safe_push (build_int_cst (integer_type_node, 42));
+ out->safe_push (build_int_cst (unsigned_type_node, 0));
+ out->safe_push (build_int_cst (unsigned_type_node, 42));
+ out->safe_push (build_real_cst_from_string (float_type_node, "QNaN"));
+ out->safe_push (build_real_cst_from_string (float_type_node, "-QNaN"));
+ out->safe_push (build_real_cst_from_string (float_type_node, "SNaN"));
+ out->safe_push (build_real_cst_from_string (float_type_node, "-SNaN"));
+ out->safe_push (build_real_cst_from_string (float_type_node, "0.0"));
+ out->safe_push (build_real_cst_from_string (float_type_node, "-0.0"));
+ out->safe_push (build_real_cst_from_string (float_type_node, "Inf"));
+ out->safe_push (build_real_cst_from_string (float_type_node, "-Inf"));
+}
+
+/* Verify that tree_cmp is a well-behaved comparator for qsort, even
+ if the underlying constants aren't comparable. */
+
+static void
+test_tree_cmp_on_constants ()
+{
+ auto_vec csts;
+ append_interesting_constants ();
+
+ /* Try sorting every triple. */
+ const unsigned num = csts.length ();
+ for (unsigned i = 0; i < num; i++)
+for (unsigned j = 0; j < num; j++)
+ for (unsigned k = 0; k < num; k++)
+ {
+ auto_vec v (3);
+ v.quick_push (csts[i]);
+ v.quick_push (csts[j]);
+ v.quick_push (csts[k]);
+ v.qsort (tree_cmp);
+ }
+}
+
/* Implementation detail of the ASSERT_CONDITION_* macros. */
void
@@ -7577,6 +7640,25 @@ test_canonicalization_3 ()
ASSERT_EQ (model0, model1);
}
+/* Verify that we can canonicalize a model containing NaN and other real
+
[Bug analyzer/93451] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93451
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:8c08c983015e675f555d57a30e15d918abef2b93
commit r10-6271-g8c08c983015e675f555d57a30e15d918abef2b93
Author: David Malcolm
Date: Mon Jan 27 16:23:43 2020 -0500
analyzer: fix ICE when canonicalizing NaN (PR 93451)
PR analyzer/93451 reports an ICE when canonicalizing the constants
in a region_model, with a failed qsort_chk when attempting to sort
the constants within the region_model.
The svalues in the model were:
sv0: {poisoned: uninit}
sv1: {type: ‘double’, ‘0.0’}
sv2: {type: ‘double’, ‘1.0e+0’}
sv3: {type: ‘double’, ‘ Nan’}
The qsort_chk of the 3 constants fails due to tree_cmp using the
LT_EXPR ordering of the REAL_CSTs, which doesn't work for NaN.
This patch adjusts tree_cmp to impose an arbitrary ordering during
canonicalization for UNORDERED_EXPR cases w/o relying on the LT_EXPR
ordering, fixing the ICE.
gcc/analyzer/ChangeLog:
PR analyzer/93451
* region-model.cc (tree_cmp): For the REAL_CST case, impose an
arbitrary order on NaNs relative to other NaNs and to non-NaNs;
const-correctness tweak.
(ana::selftests::build_real_cst_from_string): New function.
(ana::selftests::append_interesting_constants): New function.
(ana::selftests::test_tree_cmp_on_constants): New test.
(ana::selftests::test_canonicalization_4): New test.
(ana::selftests::analyzer_region_model_cc_tests): Call the new
tests.
gcc/testsuite/ChangeLog:
PR analyzer/93451
* gcc.dg/analyzer/torture/pr93451.c: New test.
Re: [PATCH] doc: clarify the situation with pointer arithmetic
Hi Richard, thank you for your response. Am Montag, den 27.01.2020, 15:42 +0100 schrieb Richard Biener: > On Fri, Jan 24, 2020 at 12:46 AM Uecker, Martin > wrote: > > > > Am Donnerstag, den 23.01.2020, 14:18 +0100 schrieb Richard Biener: > > > On Wed, Jan 22, 2020 at 12:40 PM Martin Sebor wrote: > > > > > > > > On 1/22/20 8:32 AM, Richard Biener wrote: > > > > > On Tue, 21 Jan 2020, Alexander Monakov wrote: > > > > > > > > > > > On Tue, 21 Jan 2020, Richard Biener wrote: > > > > > > > > > > > > > Fourth. That PNVI (I assume it's the whole pointer-provenance > > > > > > > stuff) > > > > > > > wants to get the "best" of both which can never be done since a > > > > > > > compiler > > > > > > > needs to have a way to be conservative - in this area it's > > > > > > > conflicting > > > > > > > conservative treatment which is impossible. > > > > > > > > > > > > This paragraph is unclear, I don't immediately see what the > > > > > > conflicting goals > > > > > > are. The rest is clear enough given the previous discussions I saw. > > > > > > > > > > > > Did you mean the restriction that you cannot do arithmetic > > > > > > involving two > > > > > > integers based on pointers, get a value corresponding to one of > > > > > > them, > > > > > > cast it back and get a pointer suitable for accessing either of two > > > > > > originally pointed-to objects? I don't see that as a conflict > > > > > > because > > > > > > it places a restriction on users, not the compiler. > > > > > > > > > > As far as I remember the discussions PNVI requires to track > > > > > provenance for correctness, you may not miss or attach wrong > > > > > provenance > > > > > to a pointer and there's only "single" provenance, not "many" > > > > > (aka, may point to A and B). I don't see how you can ever implement > > > > > that. > > > > I have not idea how you came to that conclusion. PNVI is perfectly > > compatible with a naive compiler who does not track provenance at > > all as well as an abstract machine that actually carries run-time > > provenance around with each pointer and checks every operation. > > It was designed specifically to allow both cases and everything > > in between (especially compilers who track provenance during > > compile time but the programs then do not track provenance at > > run-time). > > > > You may be confused by the abstract formulation that indeed > > assigns a single provenance to each pointer. A compiler would > > track its *knowledge about provenance*, which would be a set > > of possible targets. > > Well, the question is whether PVNI allows the compiler to put any > additional restriction on what the provenance of an interger is. It > appears not, so any attempt to track provenance through integers > is doomed until the cases are very simple. I'm not sure that's desirable (*). PVNI makes something which is now implementation defined have well defined semantics. This is not possible to do without putting additional restrictions on the compiler and this will make some optimizations non-compliant. In both committees (C and C++) there is a consensus that the rules about provenance should be made clear and explicit. So far, this is the only well-developed proposal. > > > Well, PNVI limits optimization opportunities of GCC which currently > > > _does_ track provenance through integers and thus only allows > > > a very limited set(*) of "unrelated" pointers to appear here (documented > > > is that none are, implementation details differ from version to version). > > > > > > There are no optimization "opportunities" by making pointer <-> integer > > > conversions lose information. > > > > You are right: It is meant to constrain optimizations. > > > > The reasoning behind this that currently all compilers behave > > inconsistently and this is not terrible useful to anybody. > > > > At the same time, there does not appear to > > be any reasonable way how integers can have provenance. > > Any rules we came up with really got complicated and are > > also fundamentally at odds with the usual mathematical > > properties of integers one would naively expect. > > So the original point where GCC started to track provenance through > non-pointers (PVNI should really be PVNNP since I guess tracking > provenance through floats isn't to be done either ;)) was a testcase > showing that Matlab (IIRC) generated C code funneled pointers through > a pair of floats (obviously a single float isn't enough for 64bit pointers > ...) > and that prevents a good deal of optimization due to missed alias analysis. > I fixed that and now GCC happily tracks provenance through a pair of > floats ... Yes, this is impressive. And yes, the proposal would forbid this (i.e. doing aliasing analysis based on the provenance tracked through integers). PVNI would make the Matlab code well-defined (under some conditions), but break the optimization based on tracking provenance through floats. But as the
Re: [PATCH] i386: Disable TARGET_SSE_TYPELESS_STORES for TARGET_AVX
On Mon, Jan 27, 2020 at 2:17 PM H.J. Lu wrote: > > On Mon, Jan 27, 2020 at 12:26 PM Uros Bizjak wrote: > > > > On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote: > > > > > > movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the > > > case for AVX nor AVX512. We should disable TARGET_SSE_TYPELESS_STORES > > > for TARGET_AVX. > > > > > > gcc/ > > > > > > PR target/91461 > > > * config/i386/i386.h (TARGET_SSE_TYPELESS_STORES): Disable for > > > TARGET_AVX. > > > * config/i386/i386.md (*movoi_internal_avx): Remove > > > TARGET_SSE_TYPELESS_STORES check. > > > > > > gcc/testsuite/ > > > > > > PR target/91461 > > > * gcc.target/i386/pr91461-1.c: New test. > > > * gcc.target/i386/pr91461-2.c: Likewise. > > > * gcc.target/i386/pr91461-3.c: Likewise. > > > * gcc.target/i386/pr91461-4.c: Likewise. > > > * gcc.target/i386/pr91461-5.c: Likewise. > > > --- > > > gcc/config/i386/i386.h| 4 +- > > > gcc/config/i386/i386.md | 4 +- > > > gcc/testsuite/gcc.target/i386/pr91461-1.c | 66 > > > gcc/testsuite/gcc.target/i386/pr91461-2.c | 19 ++ > > > gcc/testsuite/gcc.target/i386/pr91461-3.c | 76 +++ > > > gcc/testsuite/gcc.target/i386/pr91461-4.c | 21 +++ > > > gcc/testsuite/gcc.target/i386/pr91461-5.c | 17 + > > > 7 files changed, 203 insertions(+), 4 deletions(-) > > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-1.c > > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-2.c > > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-3.c > > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-4.c > > > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-5.c > > > > > > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h > > > index 943e9a5c783..c134b04c5c4 100644 > > > --- a/gcc/config/i386/i386.h > > > +++ b/gcc/config/i386/i386.h > > > @@ -516,8 +516,10 @@ extern unsigned char > > > ix86_tune_features[X86_TUNE_LAST]; > > > #define TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL \ > > > ix86_tune_features[X86_TUNE_SSE_PACKED_SINGLE_INSN_OPTIMAL] > > > #define TARGET_SSE_SPLIT_REGS > > > ix86_tune_features[X86_TUNE_SSE_SPLIT_REGS] > > > +/* NB: movaps/movups is one byte shorter than movdaq/movdqu. But it > > > + isn't the case for AVX nor AVX512. */ > > > #define TARGET_SSE_TYPELESS_STORES \ > > > - ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES] > > > + (!TARGET_AVX && ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES]) > > > > This is wrong place to disable the feature. > Here is the updated patch on top of https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01742.html so that set_ix86_tune_features can access per function setting. OK for master branch? Thanks. -- H.J. From 61482a7d4dff07075f2534840040bafa420e9f36 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Mon, 27 Jan 2020 09:35:11 -0800 Subject: [PATCH] i386: Disable TARGET_SSE_TYPELESS_STORES for TARGET_AVX movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the case for AVX nor AVX512. We should disable TARGET_SSE_TYPELESS_STORES for TARGET_AVX and adjust vmovups checks in assembly ouputs. gcc/ PR target/91461 * config/i386/i386-options.c (set_ix86_tune_features): Disable TARGET_SSE_TYPELESS_STORES for TARGET_AVX. * config/i386/i386.md (*movoi_internal_avx): Remove TARGET_SSE_TYPELESS_STORES check. gcc/testsuite/ PR target/91461 * gcc.target/i386/avx256-unaligned-store-3.c: Don't check vmovups. * gcc.target/i386/pieces-memcpy-4.c: Likewise. * gcc.target/i386/pieces-memcpy-5.c: Likewise. * gcc.target/i386/pieces-memcpy-6.c: Likewise. * gcc.target/i386/pieces-strcpy-2.c: Likewise. * gcc.target/i386/pr90980-1.c: Likewise. * gcc.target/i386/pr87317-4.c: Check "\tvmovd\t" instead of "vmovd" to avoid matching "vmovdqu". * gcc.target/i386/pr87317-5.c: Likewise. * gcc.target/i386/pr87317-7.c: Likewise. * gcc.target/i386/pr91461-1.c: New test. * gcc.target/i386/pr91461-2.c: Likewise. * gcc.target/i386/pr91461-3.c: Likewise. * gcc.target/i386/pr91461-4.c: Likewise. * gcc.target/i386/pr91461-5.c: Likewise. * gcc.target/i386/pr91461-6.c: Likewise. --- gcc/config/i386/i386-options.c| 5 ++ gcc/config/i386/i386.md | 4 +- .../i386/avx256-unaligned-store-3.c | 4 +- .../gcc.target/i386/pieces-memcpy-4.c | 3 +- .../gcc.target/i386/pieces-memcpy-5.c | 3 +- .../gcc.target/i386/pieces-memcpy-6.c | 3 +- .../gcc.target/i386/pieces-strcpy-2.c | 2 +- gcc/testsuite/gcc.target/i386/pr87317-4.c | 2 +- gcc/testsuite/gcc.target/i386/pr87317-5.c | 2 +- gcc/testsuite/gcc.target/i386/pr87317-7.c | 2 +- gcc/testsuite/gcc.target/i386/pr90980-1.c | 2 +- gcc/testsuite/gcc.target/i386/pr91461-1.c | 66 gcc/testsuite/gcc.target/i386/pr91461-2.c | 19
[PATCH 4/4] SRA: Do not ignore padding when totally scalarizing [PR92486]
Hi, PR 92486 shows that DSE, when seeing a "normal" gimple aggregate assignment coming from a C struct assignment and one a representing a folded memcpy, can kill the latter and keep in place only the former, which does not copy padding - at least when SRA decides to totally scalarize a least one of the aggregates (when not doing total scalarization, SRA cares about padding) SRA would not totally scalarize an aggregate if it saw that it takes part in a gimple assignment which is a folded memcpy (see how type_changing_p is set in contains_vce_or_bfcref_p) but it doesn't because of the DSE decisions. I was asked to modify SRA to take padding into account - and to copy it around - when totally scalarizing, which is what the patch below does. I am not very happy about this, I am afraid it will lead to performance regressions, but this has all been discussed (see https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01185.html and https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00218.html). I tried to alleviate the problem by not only inserting accesses for padding but also by enlarging existing accesses whenever possible to extend over padding - the extended access would get copied when in the original IL an aggregate copy is replaced with SRA copies and a BIT_FIELD_REF would be generated to replace a scalar access to a part of the aggregate in the original IL. I have made it work in the sense that the patch passed bootstrap and testing (see the git branch refs/users/jamborm/heads/sra-later_total-bfr-20200127 or look at https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/users/jamborm/heads/sra-later_total-bfr-20200127 if you are interested), but this approach meant that each such extended replacement which was written to (so all of them) could potentially become only partially assigned to and so had to be marked as addressable and could not become gimple register, meaning that total scalarizatio would be creating addressable variables. Detecting such cases is not easy, it would mean introducing yet another type of write flag (written to exactly this access) and propagate that flag across assignment sub-accesses. So I decided that was not the way to go and instead only extended integer accesses, and that is what the atcg below does. Like in the previous attempt, whatever padding could not be covered by extending an access would be covered by extra artificial accesses. As you can see, it adds a little complexity to various places of the pass which are already not trivial, but hopefully it is manageable. Bootstrapped and tested on x86_64-linux, I'll curious about the feedback. Thanks, Martin 2020-01-27 Martin Jambor PR tree-optimization/92486 * tree-sra.c: Include langhooks.h (struct access): New fields reg_size and reg_acc_type. (dump_access): Print new fields. (acc_size): New function. (find_access_in_subtree): Use it, new parameter reg. (get_var_base_offset_size_access): Pass true to find_access_in_subtree. (create_access_1): Initialize reg_size. (create_artificial_child_access): Likewise. (create_total_scalarization_access): Likewise. (build_ref_for_model): Do not use model expr if reg_acc_size is non-NULL. (get_reg_access_replacement): New function. (verify_sra_access_forest): Adjust verification for presence of extended accesses covering padding. (analyze_access_subtree): Undo extension over padding if total scalarization failed, set grp_partial_lhs if we are going to introduce a partial store to the new replacement, do not ignore holes when totally scalarizing. (sra_type_for_size): New function. (total_scalarization_fill_padding): Likewise. (total_should_skip_creating_access): Use it. (totally_scalarize_subtree): Likewise. (sra_modify_expr): Use get_reg_access_replacement instead of get_access_replacement, adjust for reg_acc_type. (sra_modify_assign): Likewise. (load_assign_lhs_subreplacements): Pass false to find_access_in_subtree. testsuite/ * gcc.dg/tree-ssa/pr92486.c: New test. --- gcc/ChangeLog | 32 +++ gcc/testsuite/ChangeLog | 5 + gcc/testsuite/gcc.dg/tree-ssa/pr92486.c | 38 +++ gcc/tree-sra.c | 368 +--- 4 files changed, 396 insertions(+), 47 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr92486.c diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 3541c6638f9..34c60e6f2a3 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,35 @@ +2020-01-26 Martin Jambor + + PR tree-optimization/92486 + * tree-sra.c: Include langhooks.h + (struct access): New fields reg_size and reg_acc_type. + (dump_access): Print new fields. + (acc_size): New function. + (find_access_in_subtree): U
[PATCH 2/4] SRA: Total scalarization after access propagation [PR92706]
Hi,
this patch fixes the second testcase in PR 92706 by performing total
scalarization only quite a bit later, when we already have access
trees constructed and even done propagation of accesses from RHSs of
assignment to LHSs.
The new code simultaneously traverses the existing access tree and the
declared variable type and adds artificial accesses whenever they can
fit in between the existing ones. This prevents us from creating
accesses based on the type which then clash with those which have
propagated here from another access tree describing an aggregate on a
RHS of an assignment, which means that both sides of the assignment
will be scalarized differently, leading to bad code and the aggregate
most likely not going away.
This new version is hopefully slightly easier to read and review and
also fixed one potential bug, but otherwise does pretty much the same
thing as the first one.
Bootstrapped and LTO-bootstrapped and tested on an x86_64-linux, where
it causes two new guality XPASSes. I expect that review will lead to
requests to change things but provided we want to fix PR 92706 now, I
believe this is the way to go. The fix for PR 92486 which I am
sending as a follow-up also depends on this patch.
Thanks,
Martin
2019-12-20 Martin Jambor
PR tree-optimization/92706
* tree-sra.c (struct access): Adjust comment of
grp_total_scalarization.
(find_access_in_subtree): Look for single children spanning an entire
access.
(scalarizable_type_p): Allow register accesses, adjust callers.
(completely_scalarize): Remove function.
(scalarize_elem): Likewise.
(create_total_scalarization_access): Likewise.
(sort_and_splice_var_accesses): Do not track total scalarization
flags.
(analyze_access_subtree): New parameter totally, adjust to new meaning
of grp_total_scalarization.
(analyze_access_trees): Pass new parameter to analyze_access_subtree.
(can_totally_scalarize_forest_p): New function.
(create_total_scalarization_access): Likewise.
(create_total_access_and_reshape): Likewise.
(total_should_skip_creating_access): Likewise.
(totally_scalarize_subtree): Likewise.
(analyze_all_variable_accesses): Perform total scalarization after
subaccess propagation using the new functions above.
(initialize_constant_pool_replacements): Output initializers by
traversing the access tree.
testsuite/
* gcc.dg/tree-ssa/pr92706-2.c: New test.
* gcc.dg/guality/pr59776.c: Xfail tests for s2.g.
---
gcc/testsuite/gcc.dg/guality/pr59776.c| 4 +-
gcc/testsuite/gcc.dg/tree-ssa/pr92706-2.c | 19 +
gcc/tree-sra.c| 666 --
3 files changed, 505 insertions(+), 184 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr92706-2.c
diff --git a/gcc/testsuite/gcc.dg/guality/pr59776.c
b/gcc/testsuite/gcc.dg/guality/pr59776.c
index 382abb622bb..6c1c8165b70 100644
--- a/gcc/testsuite/gcc.dg/guality/pr59776.c
+++ b/gcc/testsuite/gcc.dg/guality/pr59776.c
@@ -12,11 +12,11 @@ foo (struct S *p)
struct S s1, s2; /* { dg-final { gdb-test pr59776.c:17
"s1.f" "5.0" } } */
s1 = *p; /* { dg-final { gdb-test pr59776.c:17
"s1.g" "6.0" } } */
s2 = s1; /* { dg-final { gdb-test pr59776.c:17
"s2.f" "0.0" } } */
- *(int *) = 0; /* { dg-final { gdb-test pr59776.c:17
"s2.g" "6.0" } } */
+ *(int *) = 0; /* { dg-final { gdb-test pr59776.c:17
"s2.g" "6.0" { xfail *-*-* } } } */
asm volatile (NOP : : : "memory"); /* { dg-final { gdb-test pr59776.c:20
"s1.f" "5.0" } } */
asm volatile (NOP : : : "memory"); /* { dg-final { gdb-test pr59776.c:20
"s1.g" "6.0" } } */
s2 = s1; /* { dg-final { gdb-test pr59776.c:20
"s2.f" "5.0" } } */
- asm volatile (NOP : : : "memory"); /* { dg-final { gdb-test pr59776.c:20
"s2.g" "6.0" } } */
+ asm volatile (NOP : : : "memory"); /* { dg-final { gdb-test pr59776.c:20
"s2.g" "6.0" { xfail *-*-* } } } */
asm volatile (NOP : : : "memory");
}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr92706-2.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr92706-2.c
new file mode 100644
index 000..37ab9765db0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr92706-2.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-esra" } */
+
+typedef __UINT64_TYPE__ uint64_t;
+typedef __UINT32_TYPE__ uint32_t;
+struct S { uint32_t i[2]; } __attribute__((aligned(__alignof__(uint64_t;
+typedef uint64_t my_int64 __attribute__((may_alias));
+uint64_t load (void *p)
+{
+ struct S u, v, w;
+ uint64_t tem;
+ tem = *(my_int64 *)p;
+ *(my_int64 *) = tem;
+ u = v;
+ w = u;
+ return *(my_int64 *)
+}
+
+/* { dg-final { scan-tree-dump "Created a replacement for v" "esra" } } */
diff --git
[PATCH 3/4] SRA: Also propagate accesses from LHS to RHS [PR92706]
Hi,
the previous patch unfortunately does not fix the first testcase in PR
92706 and since I am afraid it might be the important one, I also
focused on that. The issue here is again total scalarization accesses
clashing with those representing accesses in the IL - on another
aggregate but here the sides are switched. Whereas in the previous
case the total scalarization accesses prevented propagation along
assignments, here we have the user accesses on the LHS, so even though
we do not create anything there, we totally scalarize the RHS and
again end up with assignments with different scalarizations leading to
bad code.
So we clearly need to propagate information about accesses from RHSs
to LHSs too, which the patch below does. Because the intent is only
preventing bad total scalarization - which the last patch now performs
late enough - and do not care about grp_write flag and so forth, the
propagation is a bit simpler and so I did not try to unify all of the
code for both directions.
More information and some discussion is in the thread from the initial
submission, the code has not changed in any (substantial) way. See
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01184.html and
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00698.html.
Bootstrapped and tested on x86_64-linux.
Thanks,
Martin
2019-12-11 Martin Jambor
PR tree-optimization/92706
* tree-sra.c (struct access): Fields first_link, last_link,
next_queued and grp_queued renamed to first_rhs_link, last_rhs_link,
next_rhs_queued and grp_rhs_queued respectively, new fields
first_lhs_link, last_lhs_link, next_lhs_queued and grp_lhs_queued.
(struct assign_link): Field next renamed to next_rhs, new field
next_lhs. Updated comment.
(work_queue_head): Renamed to rhs_work_queue_head.
(lhs_work_queue_head): New variable.
(add_link_to_lhs): New function.
(relink_to_new_repr): Also relink LHS lists.
(add_access_to_work_queue): Renamed to add_access_to_rhs_work_queue.
(add_access_to_lhs_work_queue): New function.
(pop_access_from_work_queue): Renamed to
pop_access_from_rhs_work_queue.
(pop_access_from_lhs_work_queue): New function.
(build_accesses_from_assign): Also add links to LHS lists and to LHS
work_queue.
(child_would_conflict_in_lacc): Renamed to
child_would_conflict_in_acc. Adjusted parameter names.
(create_artificial_child_access): New parameter set_grp_read, use it.
(subtree_mark_written_and_enqueue): Renamed to
subtree_mark_written_and_rhs_enqueue.
(propagate_subaccesses_across_link): Renamed to
propagate_subaccesses_from_rhs.
(propagate_subaccesses_from_lhs): New function.
(propagate_all_subaccesses): Also propagate subaccesses from LHSs to
RHSs.
testsuite/
* gcc.dg/tree-ssa/pr92706-1.c: New test.
---
gcc/testsuite/gcc.dg/tree-ssa/pr92706-1.c | 17 ++
gcc/tree-sra.c| 306 --
2 files changed, 248 insertions(+), 75 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr92706-1.c
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr92706-1.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr92706-1.c
new file mode 100644
index 000..c36d103798e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr92706-1.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-esra-details" } */
+
+struct S { int i[4]; } __attribute__((aligned(128)));
+typedef __int128_t my_int128 __attribute__((may_alias));
+__int128_t load (void *p)
+{
+ struct S v;
+ __builtin_memcpy (, p, sizeof (struct S));
+ struct S u;
+ u = v;
+ struct S w;
+ w = u;
+ return *(my_int128 *)
+}
+
+/* { dg-final { scan-tree-dump-not "Created a replacement for u offset:
\[^0\]" "esra" } } */
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 2b0849858de..ea8594db193 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -167,11 +167,15 @@ struct access
struct access *next_sibling;
/* Pointers to the first and last element in the linked list of assign
- links. */
- struct assign_link *first_link, *last_link;
+ links for propagation from LHS to RHS. */
+ struct assign_link *first_rhs_link, *last_rhs_link;
- /* Pointer to the next access in the work queue. */
- struct access *next_queued;
+ /* Pointers to the first and last element in the linked list of assign
+ links for propagation from LHS to RHS. */
+ struct assign_link *first_lhs_link, *last_lhs_link;
+
+ /* Pointer to the next access in the work queues. */
+ struct access *next_rhs_queued, *next_lhs_queued;
/* Replacement variable for this access "region." Never to be accessed
directly, always only by the means of get_access_replacement() and only
@@ -184,8 +188,11 @@ struct access
/* Is this particular access write access? */
unsigned write : 1;
- /* Is this access
[PATCH 1/4] SRA: Add verification of accesses
Hi,
this patch has not changed since the last submission at all, in fact
it got approved but without the follow-up fix of the reverse flag, it
would introduce regression, so it should not be committed on its own.
Because the follow-up patches perform some non-trivial operations on
SRA patches, I wrote myself a verifier. And sure enough, it has
spotted two issues, one of which is fixed in this patch too - we did
not correctly set the parent link when creating artificial accesses
for propagation across assignments. The second one is the (not)
setting of reverse flag when creating accesses for total scalarization
but since the following patch removes the offending function, this
patch does not fix it.
Bootstrapped and tested on x86_64, I consider this a pre-requisite for
the followup patches (and the parent link fix really is).
Thanks,
Martin
2019-12-10 Martin Jambor
* tree-sra.c (verify_sra_access_forest): New function.
(verify_all_sra_access_forests): Likewise.
(create_artificial_child_access): Set parent.
(analyze_all_variable_accesses): Call the verifier.
---
gcc/tree-sra.c | 86 ++
1 file changed, 86 insertions(+)
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 875d5b21763..36106fecaf1 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2321,6 +2321,88 @@ build_access_trees (struct access *access)
return true;
}
+/* Traverse the access forest where ROOT is the first root and verify that
+ various important invariants hold true. */
+
+DEBUG_FUNCTION void
+verify_sra_access_forest (struct access *root)
+{
+ struct access *access = root;
+ tree first_base = root->base;
+ gcc_assert (DECL_P (first_base));
+ do
+{
+ gcc_assert (access->base == first_base);
+ if (access->parent)
+ gcc_assert (access->offset >= access->parent->offset
+ && access->size <= access->parent->size);
+ if (access->next_sibling)
+ gcc_assert (access->next_sibling->offset
+ >= access->offset + access->size);
+
+ poly_int64 poffset, psize, pmax_size;
+ bool reverse;
+ tree base = get_ref_base_and_extent (access->expr, , ,
+ _size, );
+ HOST_WIDE_INT offset, size, max_size;
+ if (!poffset.is_constant ()
+ || !psize.is_constant ()
+ || !pmax_size.is_constant (_size))
+ gcc_unreachable ();
+ gcc_assert (base == first_base);
+ gcc_assert (offset == access->offset);
+ gcc_assert (access->grp_unscalarizable_region
+ || size == max_size);
+ gcc_assert (max_size == access->size);
+ gcc_assert (reverse == access->reverse);
+
+ if (access->first_child)
+ {
+ gcc_assert (access->first_child->parent == access);
+ access = access->first_child;
+ }
+ else if (access->next_sibling)
+ {
+ gcc_assert (access->next_sibling->parent == access->parent);
+ access = access->next_sibling;
+ }
+ else
+ {
+ while (access->parent && !access->next_sibling)
+ access = access->parent;
+ if (access->next_sibling)
+ access = access->next_sibling;
+ else
+ {
+ gcc_assert (access == root);
+ root = root->next_grp;
+ access = root;
+ }
+ }
+}
+ while (access);
+}
+
+/* Verify access forests of all candidates with accesses by calling
+ verify_access_forest on each on them. */
+
+DEBUG_FUNCTION void
+verify_all_sra_access_forests (void)
+{
+ bitmap_iterator bi;
+ unsigned i;
+ EXECUTE_IF_SET_IN_BITMAP (candidate_bitmap, 0, i, bi)
+{
+ tree var = candidate (i);
+ struct access *access = get_first_repr_for_decl (var);
+ if (access)
+ {
+ gcc_assert (access->base == var);
+ verify_sra_access_forest (access);
+ }
+}
+}
+
/* Return true if expr contains some ARRAY_REFs into a variable bounded
array. */
@@ -2566,6 +2648,7 @@ create_artificial_child_access (struct access *parent,
struct access *model,
access->offset = new_offset;
access->size = model->size;
access->type = model->type;
+ access->parent = parent;
access->grp_write = set_grp_write;
access->grp_read = false;
access->reverse = model->reverse;
@@ -2850,6 +2933,9 @@ analyze_all_variable_accesses (void)
propagate_all_subaccesses ();
+ if (flag_checking)
+verify_all_sra_access_forests ();
+
bitmap_copy (tmp, candidate_bitmap);
EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, bi)
{
--
2.24.1
[Bug rtl-optimization/90688] [8/9/10 Regression] ICE in calc_dfs_tree, at dominance.c:458 since r235297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90688 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #3 from Jeffrey A. Law --- This was fixed some time ago by Jakub. *** This bug has been marked as a duplicate of bug 92610 ***
[Bug rtl-optimization/92610] [10 Regression] ICE in calc_dfs_tree, at dominance.c:458 since r270940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92610 --- Comment #5 from Jeffrey A. Law --- *** Bug 90688 has been marked as a duplicate of this bug. ***
[Bug c/93474] no warning for nonstandard bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93474 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- GCC documents this: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html#Structures-unions-enumerations-and-bit-fields-implementation Allowable bit-field types other than _Bool, signed int, and unsigned int (C99 and C11 6.7.2.1). Other integer types, such as long int, and enumerated types are permitted even in strictly conforming mode. --- CUT It is up to each other compiler to document the implementation defined behavior. GCC does document what happens.
[Bug c++/91075] Wrong code generated for static variable with local redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91075 --- Comment #1 from joseph at codesourcery dot com --- This would definitely be invalid C (the prior declaration visible in the inner scope has no linkage, so the inner declaration has external linkage and "If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined." applies). For C++, it appears the example in 3.5 paragraph 6 in the (old) document you linked to is the relevant one, explicitly saying the inner declaration refers to an entity with external linkage which is different from the static variable with internal linkage. In C++17, [basic.link] paragraph 6 says this example is ill-formed; no doubt one of our C++ experts can give details of when and why this changed and whether it was a defect fix.
[Bug c/93474] New: no warning for nonstandard bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93474
Bug ID: 93474
Summary: no warning for nonstandard bit field
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: doug at cs dot dartmouth.edu
Target Milestone: ---
struct { char x:1; } is implementation-defined syntax
per www.open-std.org/jtc1/sc22/wg14/www/docs/n2433.pdf,
Section 6.7.2.1, Constraint 5, which requires support
of only _Bool, signed int and unsigned int declarators.
gcc -Wall -Wpedantic -Wextra does not report this
nonstandard usage.
Re: [PATCH] i386: Fix ix86_fold_builtin shift folding [PR93418]
On Tue, 2020-01-28 at 00:41 +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because the variable shift left
> operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
> VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
> we call builder.new_unary_operation, builder.encoded_nelts () will be just 1
> and thus we encode the resulting vector as if all the elements were the
> same.
> For non-masked is_vshift, we could perhaps call builder.new_binary_operation
> (TREE_TYPE (args[0]), args[0], args[1], false), but then there are masked
> shifts, for non-is_vshift we could perhaps call it too but with args[2]
> instead of args[1], but there is no builder.new_ternary_operation.
> All this stuff is primarily for aarch64 anyway, on x86 we don't have any
> variable length vectors, and it is not a big deal to compute all elements
> and just let builder.finalize () find the most efficient VECTOR_CST
> representation of the vector. So, instead of doing too much, this just
> keeps using new_unary_operation only if only one VECTOR_CST is involved
> (i.e. non-masked shift by constant) and for the rest just compute all elts.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-01-28 Jakub Jelinek
>
> PR target/93418
> * config/i386/i386.c (ix86_fold_builtin) : If mask is not
> -1 or is_vshift is true, use new_vector with number of elts npatterns
> rather than new_unary_operation.
>
> * gcc.target/i386/avx2-pr93418.c: New test.
OK.
Jeff
>
Re: [PATCH] gimple-fold: Fix buffer overflow in fold_array_ctor_reference [PR93454]
On Tue, 2020-01-28 at 00:33 +0100, Jakub Jelinek wrote: > Hi! > > libgcrypt FAILs to build on aarch64-linux with > *** stack smashing detected ***: terminated > when gcc is compiled with -D_FORTIFY_SOURCE=2. The problem is if > fold_array_ctor_reference is called with size equal to or very close to > MAX_BITSIZE_MODE_ANY_MODE bits and non-zero inner_offset. > The first native_encode_expr is called with that inner_offset and bufoff 0, > the subsequent ones with offset of 0, and bufoff elt_size - inner_offset, > 2 * elt_size - inner_offset etc. So, e.g. on the testcase where we start > with inner_offset 1 and size is e.g. 256 bytes and elt_size 4 bytes > we then call native_encode_expr at bufoff 251 and then 255, but that one > overwrites 3 bytes beyond the buf array. > The following patch fixes that. In addition, it avoids calling > elt_size.to_uhwi () all the time, and punts if elt_sz would be too large. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2020-01-28 Jakub Jelinek > > PR tree-optimization/93454 > * gimple-fold.c (fold_array_ctor_reference): Perform > elt_size.to_uhwi () just once, instead of calling it in every > iteration. Punt if that value is above size of the temporary > buffer. Decrease third native_encode_expr argument when > bufoff + elt_sz is above size of buf. > > * gcc.dg/pr93454.c: New test. OK jeff >
Re: [PATCH] libiberty/hashtab: More const parameters
On Mon, 2020-01-27 at 22:32 +, Andrew Burgess wrote: > I know that the tree's currently closed to non-bugfix changes, but I > was hoping this might be accpeted anyway so it can be backported to > binutils-gdb. > > --- > > Makes some parameters const in libiberty's hashtab library. > > include/ChangeLog: > > * hashtab.h (htab_remove_elt): Make a parameter const. > (htab_remove_elt_with_hash): Likewise. > > libiberty/ChangeLog: > > * hashtab.c (htab_remove_elt): Make a parameter const. > (htab_remove_elt_with_hash): Likewise. OK jeff >
[Bug rtl-optimization/93455] aarch64: Q constraint address is recomputed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93455 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|target |rtl-optimization Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- This is most likely just a weird interaction between predicates and constraints.
[Bug debug/93380] Variable Length Array Evaluation will be wrong or cause GDB to crash due to GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93380 --- Comment #3 from Andrew Pinski --- (In reply to Robert Dumitru from comment #2) > Hi Andrew, > > Thank you for your pointing out that. I will report the issue to ARM as well. > However, regarding 1 and 2: > > 1. I understand this looks like a gdb bug, but my investigation pointed me > to consider that what gdb does is correct- at least partially. It tries to > read the memory to find the size of the array. If the memory is not > initialised with the correct value, the size can be huge - hence - virtual > memory exhausted bug. > I will try and check with a newer gdb. Maybe gdb should know the expression > can not be evaluated before right instructions are executed? But there should be a limit inside GDB to know the size is most likely bogus.
[Bug target/86793] mips port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86793 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 Ever confirmed|0 |1
[patch, fortran] PR93473 - ICE on valid with long module + submodule names
I created PR93473 for this problem: The following code causes a bogus "symbol
is already defined" error (using git commit
472dc648ce3e7661762931d584d239611ddca964):
module aModestlyLongModuleName
type :: aTypeWithASignificantlyLongNameButStillAllowedOK
end type aTypeWithASignificantlyLongNameButStillAllowedOK
interface
module function aFunctionWithALongButStillAllowedName(parameters)
result(self)
type(aTypeWithASignificantlyLongNameButStillAllowedOK) :: self
end function aFunctionWithALongButStillAllowedName
end interface
end module aModestlyLongModuleName
submodule (aModestlyLongModuleName)
aTypeWithASignificantlyLongNameButStillAllowedOK_
contains
module procedure aFunctionWithALongButStillAllowedName
class(*), pointer :: genericObject
end procedure aFunctionWithALongButStillAllowedName
end submodule aTypeWithASignificantlyLongNameButStillAllowedOK_
submodule
(aModestlyLongModuleName:aTypeWithASignificantlyLongNameButStillAllowedOK_)
aSubmoduleWithASignificantlyLongButStillAllowedName__
end submodule aSubmoduleWithASignificantlyLongButStillAllowedName__
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../
libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/
Tools_Devel --enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200127 (experimental) (GCC)
$ gfortran -c 1057.F90 -o test.o -ffree-line-length-none
f951: internal compiler error: Segmentation fault
0xe1021f crash_signal
../../gcc-git/gcc/toplev.c:328
0x7fd1480c91ef ???
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/
sysv/linux/x86_64/sigaction.c:0
0x891106 do_traverse_symtree
../../gcc-git/gcc/fortran/symbol.c:4173
0x85739b parse_module
../../gcc-git/gcc/fortran/parse.c:6111
0x85782d gfc_parse_file()
../../gcc-git/gcc/fortran/parse.c:6427
0x8a7f2f gfc_be_parse_file
../../gcc-git/gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
The problem occurs in set_syms_host_assoc() where the "parent1" and "parent2"
variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This is insufficient
when the parent names are a module+submodule name concatenated with a ".". The
patch above fixes this by increasing their length to 2*GFC_MAX_SYMBOL_LEN+2.
A patch to fix this is attached. The patch regression tests cleanly - ok to
commit?
-Andrew
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 4bff0c8..cbace25 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -6045,8 +6045,8 @@ set_syms_host_assoc (gfc_symbol *sym)
{
gfc_component *c;
const char dot[2] = ".";
- char parent1[GFC_MAX_SYMBOL_LEN + 1];
- char parent2[GFC_MAX_SYMBOL_LEN + 1];
+ char parent1[2 * GFC_MAX_SYMBOL_LEN + 2];
+ char parent2[2 * GFC_MAX_SYMBOL_LEN + 2];
if (sym == NULL)
return;
diff --git a/gcc/testsuite/gfortran.dg/pr93473.f90 b/gcc/testsuite/gfortran.dg/pr93473.f90
new file mode 100644
index 000..dda8525
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93473.f90
@@ -0,0 +1,28 @@
+! { dg-do compile }
+! { dg-options "-ffree-line-length-none" }
+! PR fortran/93473
+module aModestlyLongModuleName
+
+ type :: aTypeWithASignificantlyLongNameButStillAllowedOK
+ end type aTypeWithASignificantlyLongNameButStillAllowedOK
+
+ interface
+ module function aFunctionWithALongButStillAllowedName(parameters) result(self)
+ type(aTypeWithASignificantlyLongNameButStillAllowedOK) :: self
+ end function aFunctionWithALongButStillAllowedName
+ end interface
+
+end module aModestlyLongModuleName
+
+submodule (aModestlyLongModuleName) aTypeWithASignificantlyLongNameButStillAllowedOK_
+
+contains
+
+ module procedure aFunctionWithALongButStillAllowedName
+ class(*), pointer :: genericObject
+ end procedure aFunctionWithALongButStillAllowedName
+
+end submodule aTypeWithASignificantlyLongNameButStillAllowedOK_
+
+submodule (aModestlyLongModuleName:aTypeWithASignificantlyLongNameButStillAllowedOK_) aSubmoduleWithASignificantlyLongButStillAllowedName__
+end submodule aSubmoduleWithASignificantlyLongButStillAllowedName__
2020-01-27 Andrew Benson
PR fortran/93473
* parse.c: Increase length of char variables to allow them to hold
a concatenated module + submodule name.
* gfortran.dg/pr93473.f90: New test.
[PATCH] i386: Fix ix86_fold_builtin shift folding [PR93418]
Hi!
The following testcase is miscompiled, because the variable shift left
operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
we call builder.new_unary_operation, builder.encoded_nelts () will be just 1
and thus we encode the resulting vector as if all the elements were the
same.
For non-masked is_vshift, we could perhaps call builder.new_binary_operation
(TREE_TYPE (args[0]), args[0], args[1], false), but then there are masked
shifts, for non-is_vshift we could perhaps call it too but with args[2]
instead of args[1], but there is no builder.new_ternary_operation.
All this stuff is primarily for aarch64 anyway, on x86 we don't have any
variable length vectors, and it is not a big deal to compute all elements
and just let builder.finalize () find the most efficient VECTOR_CST
representation of the vector. So, instead of doing too much, this just
keeps using new_unary_operation only if only one VECTOR_CST is involved
(i.e. non-masked shift by constant) and for the rest just compute all elts.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-01-28 Jakub Jelinek
PR target/93418
* config/i386/i386.c (ix86_fold_builtin) : If mask is not
-1 or is_vshift is true, use new_vector with number of elts npatterns
rather than new_unary_operation.
* gcc.target/i386/avx2-pr93418.c: New test.
--- gcc/config/i386/i386.c.jj 2020-01-22 09:49:27.375413362 +0100
+++ gcc/config/i386/i386.c 2020-01-27 18:22:34.986577375 +0100
@@ -17278,8 +17278,13 @@ ix86_fold_builtin (tree fndecl, int n_ar
countt = build_int_cst (integer_type_node, count);
}
tree_vector_builder builder;
- builder.new_unary_operation (TREE_TYPE (args[0]), args[0],
- false);
+ if (mask != HOST_WIDE_INT_M1U || is_vshift)
+ builder.new_vector (TREE_TYPE (args[0]),
+ TYPE_VECTOR_SUBPARTS (TREE_TYPE (args[0])),
+ 1);
+ else
+ builder.new_unary_operation (TREE_TYPE (args[0]), args[0],
+false);
unsigned int cnt = builder.encoded_nelts ();
for (unsigned int i = 0; i < cnt; ++i)
{
--- gcc/testsuite/gcc.target/i386/avx2-pr93418.c.jj 2020-01-27
18:27:53.461799372 +0100
+++ gcc/testsuite/gcc.target/i386/avx2-pr93418.c2020-01-27
18:26:11.592327685 +0100
@@ -0,0 +1,20 @@
+/* PR target/93418 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-not "link_error" "optimized" } } */
+
+#include
+
+void link_error (void);
+
+void
+foo (void)
+{
+ __m128i a = _mm_set1_epi32 (0xU);
+ __m128i b = _mm_setr_epi32 (16, 31, -34, 3);
+ __m128i c = _mm_sllv_epi32 (a, b);
+ __v4su d = (__v4su) c;
+ if (d[0] != 0xU || d[1] != 0x8000U
+ || d[2] != 0 || d[3] != 0xfff8U)
+link_error ();
+}
Jakub
[Bug rtl-optimization/61926] const-anchor optimisation is sensitive to ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61926 --- Comment #4 from Andrew Pinski --- (In reply to Martin Liška from comment #3) > Can the bug be marked as resolved? No, the testcases are just xfailed.
[Bug libfortran/91543] [10 Regression] nf failure ( Handling stack overflow more sensibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- For the case where you want some kind of recovery, -fstack-check is a better approach than -fstack-clash-protection as -fstack-check ensures there's always a page available to the segfault handler.
[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91474 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.3 --- Comment #12 from Andrew Pinski --- Fixed.
[Bug target/80306] ICE in cfgexpand.c during cross-compilation for mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80306 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #3 from Andrew Pinski --- Fixed so closing as GCC 7.x and before are no longer supported.
[Bug target/80306] ICE in cfgexpand.c during cross-compilation for mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80306 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- .
[Bug libgcc/63882] internal compiler error: in int_mode_for_mode, at stor-layout.c:395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63882 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Andrew Pinski --- mips64-linux-gnu builds have been working for me for a long time now including a native builds. So closing as works for me. Also no comments in over 3 years.
[PATCH] gimple-fold: Fix buffer overflow in fold_array_ctor_reference [PR93454]
Hi!
libgcrypt FAILs to build on aarch64-linux with
*** stack smashing detected ***: terminated
when gcc is compiled with -D_FORTIFY_SOURCE=2. The problem is if
fold_array_ctor_reference is called with size equal to or very close to
MAX_BITSIZE_MODE_ANY_MODE bits and non-zero inner_offset.
The first native_encode_expr is called with that inner_offset and bufoff 0,
the subsequent ones with offset of 0, and bufoff elt_size - inner_offset,
2 * elt_size - inner_offset etc. So, e.g. on the testcase where we start
with inner_offset 1 and size is e.g. 256 bytes and elt_size 4 bytes
we then call native_encode_expr at bufoff 251 and then 255, but that one
overwrites 3 bytes beyond the buf array.
The following patch fixes that. In addition, it avoids calling
elt_size.to_uhwi () all the time, and punts if elt_sz would be too large.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-01-28 Jakub Jelinek
PR tree-optimization/93454
* gimple-fold.c (fold_array_ctor_reference): Perform
elt_size.to_uhwi () just once, instead of calling it in every
iteration. Punt if that value is above size of the temporary
buffer. Decrease third native_encode_expr argument when
bufoff + elt_sz is above size of buf.
* gcc.dg/pr93454.c: New test.
--- gcc/gimple-fold.c.jj2020-01-12 11:54:36.0 +0100
+++ gcc/gimple-fold.c 2020-01-27 15:54:51.188830178 +0100
@@ -6665,12 +6665,14 @@ fold_array_ctor_reference (tree type, tr
/* And offset within the access. */
inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
- if (size > elt_size.to_uhwi () * BITS_PER_UNIT)
+ unsigned HOST_WIDE_INT elt_sz = elt_size.to_uhwi ();
+ if (size > elt_sz * BITS_PER_UNIT)
{
/* native_encode_expr constraints. */
if (size > MAX_BITSIZE_MODE_ANY_MODE
|| size % BITS_PER_UNIT != 0
- || inner_offset % BITS_PER_UNIT != 0)
+ || inner_offset % BITS_PER_UNIT != 0
+ || elt_sz > MAX_BITSIZE_MODE_ANY_MODE / BITS_PER_UNIT)
return NULL_TREE;
unsigned ctor_idx;
@@ -6701,10 +6703,11 @@ fold_array_ctor_reference (tree type, tr
index = wi::umax (index, access_index);
do
{
- int len = native_encode_expr (val, buf + bufoff,
- elt_size.to_uhwi (),
+ if (bufoff + elt_sz > sizeof (buf))
+ elt_sz = sizeof (buf) - bufoff;
+ int len = native_encode_expr (val, buf + bufoff, elt_sz,
inner_offset / BITS_PER_UNIT);
- if (len != elt_size - inner_offset / BITS_PER_UNIT)
+ if (len != (int) elt_sz - inner_offset / BITS_PER_UNIT)
return NULL_TREE;
inner_offset = 0;
bufoff += len;
--- gcc/testsuite/gcc.dg/pr93454.c.jj 2020-01-27 16:04:22.420430555 +0100
+++ gcc/testsuite/gcc.dg/pr93454.c 2020-01-27 16:03:24.734278795 +0100
@@ -0,0 +1,25 @@
+/* PR tree-optimization/93454 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -g" } */
+
+#if __SIZEOF_INT__ == 4 && __CHAR_BIT__ == 8
+#define A(n) n, n + 0x01010101, n + 0x02020202, n + 0x03030303
+#define B(n) A (n), A (n + 0x04040404), A (n + 0x08080808), A (n + 0x0c0c0c0c)
+#define C(n) B (n), B (n + 0x10101010), B (n + 0x20202020), B (n + 0x30303030)
+#define D(n) C (n), C (n + 0x40404040), C (n + 0x80808080U), C (n +
0xc0c0c0c0U)
+const unsigned int a[64] = { C (0) };
+const unsigned int b[256] = { D (0) };
+const unsigned int c[32] = { B (0), B (0x10101010) };
+const unsigned int d[16] = { B (0) };
+const unsigned int e[8] = { A (0), A (0x04040404) };
+
+void
+foo (void)
+{
+ const unsigned char *s = ((const unsigned char *) a) + 1;
+ const unsigned char *t = ((const unsigned char *) b) + 1;
+ const unsigned char *u = ((const unsigned char *) c) + 1;
+ const unsigned char *v = ((const unsigned char *) d) + 1;
+ const unsigned char *w = ((const unsigned char *) e) + 1;
+}
+#endif
Jakub
[Bug ipa/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug lto/92588] [10 Regression] ICE nodes with unreleased memory found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92588 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |WORKSFORME --- Comment #4 from Jeffrey A. Law --- I scanned all my build logs for Fedora 32 and couldn't find any instance of this either. I think we should just CLOSED/WORKSFORME.
[Bug target/86793] mips port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86793 --- Comment #1 from Andrew Pinski --- So I can fix this for the Marvell/Cavium produced cores; Spectre workaround is not needed though. Someone inside WaveComputing/MIPS would have to implement this for those ones.
[Bug libgcc/86290] Go cross build fails, "with libgcc_s.so.1 [...] not found"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86290 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Andrew Pinski --- Works for me in GCC 7.3 and the trunk so closing as worksforme.
[Bug bootstrap/80656] mips64-linux cross build fails: Link tests are not allowed after GCC_NO_EXECUTABLES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80656 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Andrew Pinski --- This works for me; I am able to build a full toolchain with GCC 7.3 and the trunk for MIPS64.
[Bug target/28126] gcc moves an expensive (tls) instruction outside of a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126 --- Comment #13 from Andrew Pinski --- > For now it is always emulated by kernel Not on MIPS64r3/MIPS32r3 and above cores. Octeon2/3 implements this register. There might be other cores which implement this register too.
[Bug fortran/93473] ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 --- Comment #2 from Andrew Benson --- Problem occurs in set_syms_host_assoc() where the "parent1" and "parent2" variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This is insufficient when the parent names are a module+submodule name concatenated with a ".". The patch above fixes this by increasing their length to 2*GFC_MAX_SYMBOL_LEN+2.
[Bug fortran/93473] ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 --- Comment #1 from Andrew Benson --- Created attachment 47722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47722=edit Proposed patch
[Bug fortran/93473] New: ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 Bug ID: 93473 Summary: ICE on valid with long module + submodule names Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following code causes a bogus "symbol is already defined" error (using git commit 472dc648ce3e7661762931d584d239611ddca964): module aModestlyLongModuleName type :: aTypeWithASignificantlyLongNameButStillAllowedOK end type aTypeWithASignificantlyLongNameButStillAllowedOK interface module function aFunctionWithALongButStillAllowedName(parameters) result(self) type(aTypeWithASignificantlyLongNameButStillAllowedOK) :: self end function aFunctionWithALongButStillAllowedName end interface end module aModestlyLongModuleName submodule (aModestlyLongModuleName) aTypeWithASignificantlyLongNameButStillAllowedOK_ contains module procedure aFunctionWithALongButStillAllowedName class(*), pointer :: genericObject end procedure aFunctionWithALongButStillAllowedName end submodule aTypeWithASignificantlyLongNameButStillAllowedOK_ submodule (aModestlyLongModuleName:aTypeWithASignificantlyLongNameButStillAllowedOK_) aSubmoduleWithASignificantlyLongButStillAllowedName__ end submodule aSubmoduleWithASignificantlyLongButStillAllowedName__ $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools_Devel --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200127 (experimental) (GCC) $ gfortran -c 1057.F90 -o test.o -ffree-line-length-none f951: internal compiler error: Segmentation fault 0xe1021f crash_signal ../../gcc-git/gcc/toplev.c:328 0x7fd1480c91ef ??? /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x891106 do_traverse_symtree ../../gcc-git/gcc/fortran/symbol.c:4173 0x85739b parse_module ../../gcc-git/gcc/fortran/parse.c:6111 0x85782d gfc_parse_file() ../../gcc-git/gcc/fortran/parse.c:6427 0x8a7f2f gfc_be_parse_file ../../gcc-git/gcc/fortran/f95-lang.c:210 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
Re: [cris-decc0 8/9] cris: Move trivially from cc0 to reg:CC model, removing most optimizations.
Hi! On Wed, Jan 22, 2020 at 07:11:27AM +0100, Hans-Peter Nilsson wrote: > I intend to put back as many as I find use for, of those > anonymous patterns in a controlled manner, with self-contained > test-cases proving their usability, rather than symmetry with > other instructions and similar addressing modes, which guided > the original introduction. I've entered prX to track code > performance regressions related to this transition, with focus > on target-side causes and fixes; besides the function prologue > special-case, there were some checking presence of the bit-test > (btstq) instruction. That's PR93372 (not X :-) ). Do you have any estimate how much removing cc0 this way costs in performance (or code size, or any other metric)? Segher
[Bug c++/90731] [9/10 Regression] noexcept broken for forward declarations with decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90731 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[PATCH] libiberty/hashtab: More const parameters
I know that the tree's currently closed to non-bugfix changes, but I
was hoping this might be accpeted anyway so it can be backported to
binutils-gdb.
---
Makes some parameters const in libiberty's hashtab library.
include/ChangeLog:
* hashtab.h (htab_remove_elt): Make a parameter const.
(htab_remove_elt_with_hash): Likewise.
libiberty/ChangeLog:
* hashtab.c (htab_remove_elt): Make a parameter const.
(htab_remove_elt_with_hash): Likewise.
---
include/ChangeLog | 5 +
include/hashtab.h | 4 ++--
libiberty/ChangeLog | 5 +
libiberty/hashtab.c | 4 ++--
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/hashtab.h b/include/hashtab.h
index d94b54c3c41..6cca342b989 100644
--- a/include/hashtab.h
+++ b/include/hashtab.h
@@ -173,8 +173,8 @@ extern void * htab_find_with_hash (htab_t, const void
*, hashval_t);
extern void ** htab_find_slot_with_hash (htab_t, const void *,
hashval_t, enum insert_option);
extern voidhtab_clear_slot (htab_t, void **);
-extern voidhtab_remove_elt (htab_t, void *);
-extern voidhtab_remove_elt_with_hash (htab_t, void *, hashval_t);
+extern voidhtab_remove_elt (htab_t, const void *);
+extern voidhtab_remove_elt_with_hash (htab_t, const void *, hashval_t);
extern voidhtab_traverse (htab_t, htab_trav, void *);
extern voidhtab_traverse_noresize (htab_t, htab_trav, void *);
diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c
index 26c98ce2d68..225e9e540a7 100644
--- a/libiberty/hashtab.c
+++ b/libiberty/hashtab.c
@@ -709,7 +709,7 @@ htab_find_slot (htab_t htab, const PTR element, enum
insert_option insert)
element in the hash table, this function does nothing. */
void
-htab_remove_elt (htab_t htab, PTR element)
+htab_remove_elt (htab_t htab, const PTR element)
{
htab_remove_elt_with_hash (htab, element, (*htab->hash_f) (element));
}
@@ -720,7 +720,7 @@ htab_remove_elt (htab_t htab, PTR element)
function does nothing. */
void
-htab_remove_elt_with_hash (htab_t htab, PTR element, hashval_t hash)
+htab_remove_elt_with_hash (htab_t htab, const PTR element, hashval_t hash)
{
PTR *slot;
--
2.14.5
[Bug c++/93437] On protobuf generated code, -Warray-bounds is brittle and not very helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93437 --- Comment #2 from Andrew Pinski --- (In reply to Rafael Avila de Espindola from comment #1) > The warning is no longer issued after > 6889a3acfeed47265886676c6d43b04ef799fb82. g:6889a3acfeed47265886676c6d43b04ef799fb82 > > Martin, is this a duplicate of middle-end/91631?
Re: [PATCH] i386: Disable TARGET_SSE_TYPELESS_STORES for TARGET_AVX
On Mon, Jan 27, 2020 at 12:26 PM Uros Bizjak wrote:
>
> On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote:
> >
> > movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the
> > case for AVX nor AVX512. We should disable TARGET_SSE_TYPELESS_STORES
> > for TARGET_AVX.
> >
> > gcc/
> >
> > PR target/91461
> > * config/i386/i386.h (TARGET_SSE_TYPELESS_STORES): Disable for
> > TARGET_AVX.
> > * config/i386/i386.md (*movoi_internal_avx): Remove
> > TARGET_SSE_TYPELESS_STORES check.
> >
> > gcc/testsuite/
> >
> > PR target/91461
> > * gcc.target/i386/pr91461-1.c: New test.
> > * gcc.target/i386/pr91461-2.c: Likewise.
> > * gcc.target/i386/pr91461-3.c: Likewise.
> > * gcc.target/i386/pr91461-4.c: Likewise.
> > * gcc.target/i386/pr91461-5.c: Likewise.
> > ---
> > gcc/config/i386/i386.h| 4 +-
> > gcc/config/i386/i386.md | 4 +-
> > gcc/testsuite/gcc.target/i386/pr91461-1.c | 66
> > gcc/testsuite/gcc.target/i386/pr91461-2.c | 19 ++
> > gcc/testsuite/gcc.target/i386/pr91461-3.c | 76 +++
> > gcc/testsuite/gcc.target/i386/pr91461-4.c | 21 +++
> > gcc/testsuite/gcc.target/i386/pr91461-5.c | 17 +
> > 7 files changed, 203 insertions(+), 4 deletions(-)
> > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-1.c
> > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-2.c
> > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-3.c
> > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-4.c
> > create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-5.c
> >
> > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> > index 943e9a5c783..c134b04c5c4 100644
> > --- a/gcc/config/i386/i386.h
> > +++ b/gcc/config/i386/i386.h
> > @@ -516,8 +516,10 @@ extern unsigned char ix86_tune_features[X86_TUNE_LAST];
> > #define TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL \
> > ix86_tune_features[X86_TUNE_SSE_PACKED_SINGLE_INSN_OPTIMAL]
> > #define TARGET_SSE_SPLIT_REGS ix86_tune_features[X86_TUNE_SSE_SPLIT_REGS]
> > +/* NB: movaps/movups is one byte shorter than movdaq/movdqu. But it
> > + isn't the case for AVX nor AVX512. */
> > #define TARGET_SSE_TYPELESS_STORES \
> > - ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES]
> > + (!TARGET_AVX && ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES])
>
> This is wrong place to disable the feature.
Like this?
diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index 2acc9fb0cfe..639969d736d 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -1597,6 +1597,11 @@ set_ix86_tune_features (enum processor_type
ix86_tune, bool dump)
= !!(initial_ix86_tune_features[i] & ix86_tune_mask);
}
+ /* NB: movaps/movups is one byte shorter than movdaq/movdqu. But it
+ isn't the case for AVX nor AVX512. */
+ if (TARGET_AVX)
+ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES] = 0;
+
if (dump)
{
fprintf (stderr, "List of x86 specific tuning parameter names:\n");
--
H.J.
Re: GCC Multi-Threading Ideas
On 1/24/20, Richard Earnshaw (lists) wrote: > On 24/01/2020 10:27, Jonathan Wakely wrote: >> On Fri, 24 Jan 2020 at 03:39, Nicholas Krause >> wrote: >>> Sorry for the second message Allan but make -j does not scale well >>> beyond 4 or >>> 8 threads and that's considering a 4 core or 8 machine. The problem has >>> to >>> do with large build machines with CPUs with more cores than this or as >>> is becoming >>> more common on mainstream systems. >> >> And make scales well beyond 8 processes (not threads) on such machines. >> > > The problem isn't make, per se, or even gcc. It's the build system as a > whole. > > On a highly multi-core machine, gcc itself hits the bottle-neck called > configure. That's serial, run *many* times (especially when there are > many multilibs) and dominates build time. > > On high multi-core machines, gcc's 15-minute system load gets no-where > near to the number of threads on the machine because of this. > > R. > It would be great if we could get some new autotools releases some time to help with this; autoconf in particular hasn't had an update in several years now AFAIK. While automake has had updates more recently than autoconf, they've mostly just been to the automake part itself and not to the aclocal program that comes with it, and aclocal in particular is another bottleneck for people who regenerate the build system files (although it could just be that way in my case because I have so many m4 macro files installed on my system for it to search thru for macros every time...)
[Bug c++/93437] On protobuf generated code, -Warray-bounds is brittle and not very helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93437 Rafael Avila de Espindola changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Rafael Avila de Espindola --- The warning is no longer issued after 6889a3acfeed47265886676c6d43b04ef799fb82. Martin, is this a duplicate of middle-end/91631?
Re: [PATCH] gcc: Add new configure options to allow static libraries to be selected
* Jeff Law [2020-01-22 13:52:27 -0700]: > On Wed, 2020-01-22 at 15:39 +, Andrew Burgess wrote: > > The motivation behind this change is to make it easier for a user to > > link against static libraries on a target where dynamic libraries are > > the default library type (for example GNU/Linux). > > > > Further, my motivation is really for linking libraries into GDB, > > however, the binutils-gdb/config/ directory is a copy of gcc/config/ > > so changes for GDB need to be approved by the GCC project first. > > > > After making this change in the gcc/config/ directory I've run > > autoreconf on all of the configure scripts in the GCC tree and a > > couple have been updated, so I'll use one of these to describe what my > > change does. > > > > Consider libcpp, this library links against libiconv. Currently if > > the user builds on a system with both static and dynamic libiconv > > installed then autotools will pick up the dynamic libiconv by > > default. This is almost certainly the right thing to do. > > > > However, if the user wants to link against static libiconv then things > > are a little harder, they could remove the dynamic libiconv from their > > system, but this is probably a bad idea (other things might depend on > > that library), or the user can build their own version of libiconv, > > install it into a unique prefix, and then configure gcc using the > > --with-libiconv-prefix=DIR flag. This works fine, but is somewhat > > annoying, the static library available, I just can't get autotools to > > use it. > > > > My change then adds a new flag --with-libiconv-type=TYPE, where type > > is either auto, static, or shared. The default auto, ensures we keep > > the existing behaviour unchanged. > > > > If the user configures with --with-libiconv-type=static then the > > configure script will ignore any dynamic libiconv it finds, and will > > only look for a static libiconv, if no static libiconv is found then > > the configure will continue as though there is no libiconv at all > > available. > > > > Similarly a user can specify --with-libiconv-type=shared and force the > > use of shared libiconv, any static libiconv will be ignored. > > > > As I've implemented this change within the AC_LIB_LINKFLAGS_BODY macro > > then only libraries configured using the AC_LIB_LINKFLAGS or > > AC_LIB_HAVE_LINKFLAGS macros will gain the new configure flag. > > > > If this is accepted into GCC then there will be follow on patches for > > binutils and GDB to regenerate some configure scripts in those > > projects. > > > > For GCC only two configure scripts needed updated after this commit, > > libcpp and libstdc++-v3, both of which link against libiconv. > > > > config/ChangeLog: > > > > * lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Add new > > --with-libXXX-type=... option. Use this to guide the selection of > > either a shared library or a static library. > > > > libcpp/ChangeLog: > > > > * configure: Regnerate. > > > > libstdc++-v3/ChangeLog: > > > > * configure: Regnerate. > s/Regnerate/Regenerate/ > > This isn't strictly a regression bugfix. But given the nature of these > files I think we probably need to be a bit more lax and allow safe > changes so that downstream uses can move forward independent of the gcc > development and release schedule. > > So, OK. Thanks for the flexibility. Now pushed. Thanks, Andrew
Re: Support gnu_unique_object symbols on MIPS
On Mon, 2020-01-27 at 18:23 +, Joseph Myers wrote: > mips_declare_object_name is missing the support for declaring symbols > as gnu_unique_object that is present in the generic > ASM_DECLARE_OBJECT_NAME in elfos.h. I'm not aware of any > MIPS-specific reason for that support to be absent; > mips_declare_object_name predates the addition of gnu_unique_object > support and as far as I can tell this was simply an oversight when > that support was added. This patch adds the missing support, > following the code in elfos.h. > > Tested with no regressions with cross to mips-linux-gnu. In > particular, this fixes the failure of the recently-added glibc test > elf/tst-dlopen-nodelete-reloc, which relies on the compiler generating > such symbols, for MIPS. > > 2020-01-27 Joseph Myers > > * config/mips/mips.c (mips_declare_object_name) > [USE_GNU_UNIQUE_OBJECT]: Support use of gnu_unique_object. LGTM. jeff >
Re: [PATCH v2][ARM] Disable code hoisting with -O3 (PR80155)
Hi! On Tue, Jan 21, 2020 at 02:10:21PM +, Wilco Dijkstra wrote: > While code hoisting generally improves codesize, it can affect performance > negatively. Benchmarking shows it doesn't help SPEC and negatively affects > embedded benchmarks. Since the impact is relatively small with -O2 and mainly > affects -O3, the simplest option is to disable code hoisting for -O3 and > higher. Should this be a generic thing, not target-specific? Segher
[Bug c/93472] New: Document extended forms of constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93472 Bug ID: 93472 Summary: Document extended forms of constant expression Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- GCC accepts extended forms of constant expression. An example that came up recently was: const int a = 5; const int b = a; IIUC the standard permits the compiler to accept other forms of constant expression. However, I couldn't find this in the documentation, and I think it would be good if GCC documented the extensions it supports. Perhaps a new node in the "C Implementation-Defined Behavior" section would be appropriate.
Re: [PATCH 0/2] Make C front end share the C++ tree representation of loops and switches
On Thu, 2019-12-12 at 15:44 -0500, Jason Merrill wrote: > Here are the dumps from ssa-dom-thread-7.c made to compile as C++; cx-current > is the dumps with current trunk; cx-old is changed to use the old goto-based > lowering like C. Sorry this has taken so long to get back to. For ssa-dom-thread-7.c it looks like the differences we're encountering start at the thread1 pass. While both cc1 and cc1plus optimized 16 jump threading paths, the final targets differ in some cases. I guess somewhat ironically cc1plus actually does a better job threading deeper through the CFG. I suspect, but have not actually confirmed that by threading deeper through the CFG, there's just fewer things for subsequent passes to detect and optimize. I'm pretty sure cc1 doesn't thread as deeply simply due to the ordering of the jump thread paths that have been recorded. Essentially we only optimize *one* path starting at any given edge even though we may have multiple potential jump threading paths that start at that edge. This clearly argues that we should sort the vector of jump threading paths so that we find the longest paths first. While I think we've missed the boat for gcc-10, I think these patches should go forward in gcc-11. I'll own getting the paths sorted so that this problem is avoided. Jeff
[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461 --- Comment #2 from Andrew Benson --- The problem occurs because GFC_MAX_MANGLED_SYMBOL_LEN is set to GFC_MAX_SYMBOL_LEN*2+4, which is sufficient for a module name plus function name (plus the additional "_"'s that get prepended), but insufficient if a submodule name is included. The name then gets truncated and can lead to two different functions having the same (truncated) symbol name. The fix is to increase this length to GFC_MAX_SYMBOL_LEN*3+5 - which allows for the submodule name plus the "." added between module and submodule names. Patch attached.
[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461 --- Comment #1 from Andrew Benson --- Created attachment 47721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47721=edit Patch for PR93461
[patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule
I created PR93461 for this issue: The following code causes a bogus "symbol is
already defined" error (using git commit
73380abd6b2783215c7950a2ade5e3f4b271e2bc):
module aModuleWithAnAllowedName
interface
module subroutine aShortName()
end subroutine aShortName
end interface
end module aModuleWithAnAllowedName
submodule (aModuleWithAnAllowedName)
aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName
contains
subroutine aShortName()
call aSubroutineWithAVeryLongNameThatWillCauseAProblem()
call aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso()
end subroutine aShortName
subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem()
end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem
subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso()
end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso
end submodule aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../
libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/
Tools_Devel --enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200124 (experimental) (GCC)
$ gfortran -c symlength.F90 -o symlength.o -ffree-line-length-none -
frecursive -pthread -Wall -fbacktrace -ffpe-trap=invalid,zero,overflow -fdump-
core -O3 -ffinite-math-only -fno-math-errno -fopenmp -g
/tmp/cc8B4Hmp.s: Assembler messages:
/tmp/cc8B4Hmp.s:20: Error: symbol
`__amodulewithanallowedname.asubmodulewithaveryveryverylongbutentirelylegalname_MOD_asubroutinewithaverylongnamethatwillcauseaprobl'
is already defined
The problem occurs because GFC_MAX_MANGLED_SYMBOL_LEN is set to
GFC_MAX_SYMBOL_LEN*2+4, which is sufficient for a module name plus function
name
(plus the additional "_"'s that get prepended), but insufficient if a submodule
name is included. The name then gets truncated and can lead to two different
functions having the same (truncated) symbol name.
The fix is to increase this length to GFC_MAX_SYMBOL_LEN*3+5 - which allows for
the submodule name plus the "." added between module and submodule names.
I've attached a patch for this which includes a new test case for this PR. The
patch regression tests cleanly.
OK to commit?
-Andrew
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://github.com/galacticusorg/galacticus
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index 52bc045..5942320 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -24,7 +24,7 @@ along with GCC; see the file COPYING3. If not see
#include "predict.h" /* For enum br_predictor and PRED_*. */
/* Mangled symbols take the form __module__name. */
-#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*2+4)
+#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*3+5)
/* Struct for holding a block of statements. It should be treated as an
opaque entity and not modified directly. This allows us to change the
diff --git a/gcc/testsuite/gfortran.dg/pr93461.f90 b/gcc/testsuite/gfortran.dg/pr93461.f90
new file mode 100644
index 000..3bef326
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93461.f90
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! PR fortran/93461
+module aModuleWithAnAllowedName
+ interface
+ module subroutine aShortName()
+ end subroutine aShortName
+ end interface
+end module aModuleWithAnAllowedName
+
+submodule (aModuleWithAnAllowedName) aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName
+contains
+ subroutine aShortName()
+call aSubroutineWithAVeryLongNameThatWillCauseAProblem()
+call aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso()
+ end subroutine aShortName
+
+ subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem()
+ end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem
+
+ subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso()
+ end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso
+end submodule aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName
2020-01-27 Andrew Benson
* trans.h: Increase GFC_MAX_MANGLED_SYMBOL_LEN to
GFC_MAX_SYMBOL_LEN*3+5 to allow for inclusion of submodule name,
plus the "." between module and submodule names.
[Bug libstdc++/93470] [9/10 Regression] [C++2a] std::reference_wrapper to function type is broken with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470 --- Comment #4 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #3) > (In reply to frankhb1989 from comment #2) > > Sorry, I missed to mention it only failed with `clang++ -std=c++2a` > > If you're going to claim something is broken please don't forget the most > critical piece of information. > True, I should have been mention this in the title of the bug. My mistake to leave "C++2a" but not "Clang++" and forget to rephrase it in the comment with a proper case. > GCC accepts it as an extension, which is also correct. > > You get a diagnostic with -Wsystem-headers, but not by default. Fair point. Glad to see this not depending on the compiler.
[Bug libstdc++/93470] [9/10 Regression] [C++2a] std::reference_wrapper to function type is broken with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470 Jonathan Wakely changed: What|Removed |Added Status|WAITING |ASSIGNED Target Milestone|--- |9.3 Summary|[C++2a] |[9/10 Regression] [C++2a] |std::reference_wrapper to |std::reference_wrapper to |function type is broken |function type is broken ||with Clang --- Comment #3 from Jonathan Wakely --- (In reply to frankhb1989 from comment #2) > Sorry, I missed to mention it only failed with `clang++ -std=c++2a` If you're going to claim something is broken please don't forget the most critical piece of information. Bugzilla reminds you to read https://gcc.gnu.org/bugs/ before creating every bug, please be sure to do that, and provide the requested information. > Clang++ 9.0.1). G++ with `-std=c++2a` still accepts the code. However, it > seems that Clang++ is correct here. GCC accepts it as an extension, which is also correct. You get a diagnostic with -Wsystem-headers, but not by default.
[Bug go/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Ian Lance Taylor --- Go frontend is fixed.
[Bug target/89627] Miscompiled constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89627 Jim Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot gnu.org --- Comment #5 from Jim Wilson --- Was fixed in gcc 9 last year.
[Bug go/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 --- Comment #8 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:2f195832a12ff4fb54d723f32019d4175db1b5da commit r10-6267-g2f195832a12ff4fb54d723f32019d4175db1b5da Author: Ian Lance Taylor Date: Fri Jan 24 12:39:23 2020 -0800 compiler: cleanups permitted by GCC requirement of MPFR 3.1.0 For MPFR functions, change from GMP_RND* to MPFR_RND*. Also change mp_exp_t to mpfr_expt_t. Fixes PR go/92463 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/216417
Go patch committed: Cleanups for MPFR 3.1.0
This patch to the Go frontend adds cleanups now that MPFR 3.1.0 is
required. For MPFR functions, change from GMP_RND* to MPFR_RND*.
Also change mp_exp_t to mpfr_expt_t. This fixes GCC PR 92463.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu (with MPFR
4.0.2). Committed to mainline.
Ian
b1321526a1de86d4feadef1bc9b1a64f45ceebb8
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 38872c44eab..49312fa10f7 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-197381c6364431a7a05e32df683874b7cadcc4b4
+132e0e61d59aaa52f8fdb03a925300c1ced2a0f2
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/expressions.cc b/gcc/go/gofrontend/expressions.cc
index 14bec9a427f..42ad93b9830 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -2580,11 +2580,11 @@ Integer_expression::do_import(Import_expression* imp,
Location loc)
return Expression::make_error(loc);
}
if (pos == std::string::npos)
- mpfr_set_ui(real, 0, GMP_RNDN);
+ mpfr_set_ui(real, 0, MPFR_RNDN);
else
{
std::string real_str = num.substr(0, pos);
- if (mpfr_init_set_str(real, real_str.c_str(), 10, GMP_RNDN) != 0)
+ if (mpfr_init_set_str(real, real_str.c_str(), 10, MPFR_RNDN) != 0)
{
go_error_at(imp->location(), "bad number in import data: %qs",
real_str.c_str());
@@ -2599,7 +2599,7 @@ Integer_expression::do_import(Import_expression* imp,
Location loc)
imag_str = num.substr(pos);
imag_str = imag_str.substr(0, imag_str.size() - 1);
mpfr_t imag;
- if (mpfr_init_set_str(imag, imag_str.c_str(), 10, GMP_RNDN) != 0)
+ if (mpfr_init_set_str(imag, imag_str.c_str(), 10, MPFR_RNDN) != 0)
{
go_error_at(imp->location(), "bad number in import data: %qs",
imag_str.c_str());
@@ -2639,7 +2639,7 @@ Integer_expression::do_import(Import_expression* imp,
Location loc)
else
{
mpfr_t val;
- if (mpfr_init_set_str(val, num.c_str(), 10, GMP_RNDN) != 0)
+ if (mpfr_init_set_str(val, num.c_str(), 10, MPFR_RNDN) != 0)
{
go_error_at(imp->location(), "bad number in import data: %qs",
num.c_str());
@@ -2753,7 +2753,7 @@ class Float_expression : public Expression
: Expression(EXPRESSION_FLOAT, location),
type_(type)
{
-mpfr_init_set(this->val_, *val, GMP_RNDN);
+mpfr_init_set(this->val_, *val, MPFR_RNDN);
}
// Write VAL to export data.
@@ -2923,8 +2923,8 @@ Float_expression::do_get_backend(Translate_context*
context)
void
Float_expression::export_float(String_dump *exp, const mpfr_t val)
{
- mp_exp_t exponent;
- char* s = mpfr_get_str(NULL, , 10, 0, val, GMP_RNDN);
+ mpfr_exp_t exponent;
+ char* s = mpfr_get_str(NULL, , 10, 0, val, MPFR_RNDN);
if (*s == '-')
exp->write_c_string("-");
exp->write_c_string("0.");
@@ -4781,7 +4781,7 @@ Unary_expression::eval_constant(Operator op, const
Numeric_constant* unc,
unc->get_float();
mpfr_t val;
mpfr_init(val);
- mpfr_neg(val, uval, GMP_RNDN);
+ mpfr_neg(val, uval, MPFR_RNDN);
nc->set_float(unc->type(), val);
mpfr_clear(uval);
mpfr_clear(val);
@@ -5613,8 +5613,8 @@ Binary_expression::compare_float(const Numeric_constant*
left_nc,
if (!type->is_abstract() && type->float_type() != NULL)
{
int bits = type->float_type()->bits();
- mpfr_prec_round(left_val, bits, GMP_RNDN);
- mpfr_prec_round(right_val, bits, GMP_RNDN);
+ mpfr_prec_round(left_val, bits, MPFR_RNDN);
+ mpfr_prec_round(right_val, bits, MPFR_RNDN);
}
*cmp = mpfr_cmp(left_val, right_val);
@@ -5649,10 +5649,10 @@ Binary_expression::compare_complex(const
Numeric_constant* left_nc,
if (!type->is_abstract() && type->complex_type() != NULL)
{
int bits = type->complex_type()->bits();
- mpfr_prec_round(mpc_realref(left_val), bits / 2, GMP_RNDN);
- mpfr_prec_round(mpc_imagref(left_val), bits / 2, GMP_RNDN);
- mpfr_prec_round(mpc_realref(right_val), bits / 2, GMP_RNDN);
- mpfr_prec_round(mpc_imagref(right_val), bits / 2, GMP_RNDN);
+ mpfr_prec_round(mpc_realref(left_val), bits / 2, MPFR_RNDN);
+ mpfr_prec_round(mpc_imagref(left_val), bits / 2, MPFR_RNDN);
+ mpfr_prec_round(mpc_realref(right_val), bits / 2, MPFR_RNDN);
+ mpfr_prec_round(mpc_imagref(right_val), bits / 2, MPFR_RNDN);
}
*cmp = mpc_cmp(left_val, right_val) != 0;
@@ -5899,10 +5899,10 @@ Binary_expression::eval_float(Operator op, const
Numeric_constant* left_nc,
switch (op)
{
case OPERATOR_PLUS:
- mpfr_add(val, left_val, right_val, GMP_RNDN);
+ mpfr_add(val, left_val, right_val, MPFR_RNDN);
break;
case OPERATOR_MINUS:
-
[Bug target/93459] ix86_fold_builtin should handle __builtin_ia32_pcmpeqd128_mask and similar builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93459 --- Comment #2 from Marc Glisse --- For __builtin_ia32_vec_ext_v4si, shouldn't we lower it to an array access in gimple, when the second argument is constant? I assume we don't want to do it directly in smmintrin.h for diagnostic purposes.
Re: [PATCH] i386: Disable TARGET_SSE_TYPELESS_STORES for TARGET_AVX
On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote:
>
> movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the
> case for AVX nor AVX512. We should disable TARGET_SSE_TYPELESS_STORES
> for TARGET_AVX.
>
> gcc/
>
> PR target/91461
> * config/i386/i386.h (TARGET_SSE_TYPELESS_STORES): Disable for
> TARGET_AVX.
> * config/i386/i386.md (*movoi_internal_avx): Remove
> TARGET_SSE_TYPELESS_STORES check.
>
> gcc/testsuite/
>
> PR target/91461
> * gcc.target/i386/pr91461-1.c: New test.
> * gcc.target/i386/pr91461-2.c: Likewise.
> * gcc.target/i386/pr91461-3.c: Likewise.
> * gcc.target/i386/pr91461-4.c: Likewise.
> * gcc.target/i386/pr91461-5.c: Likewise.
> ---
> gcc/config/i386/i386.h| 4 +-
> gcc/config/i386/i386.md | 4 +-
> gcc/testsuite/gcc.target/i386/pr91461-1.c | 66
> gcc/testsuite/gcc.target/i386/pr91461-2.c | 19 ++
> gcc/testsuite/gcc.target/i386/pr91461-3.c | 76 +++
> gcc/testsuite/gcc.target/i386/pr91461-4.c | 21 +++
> gcc/testsuite/gcc.target/i386/pr91461-5.c | 17 +
> 7 files changed, 203 insertions(+), 4 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-1.c
> create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-2.c
> create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-3.c
> create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-4.c
> create mode 100644 gcc/testsuite/gcc.target/i386/pr91461-5.c
>
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index 943e9a5c783..c134b04c5c4 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -516,8 +516,10 @@ extern unsigned char ix86_tune_features[X86_TUNE_LAST];
> #define TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL \
> ix86_tune_features[X86_TUNE_SSE_PACKED_SINGLE_INSN_OPTIMAL]
> #define TARGET_SSE_SPLIT_REGS ix86_tune_features[X86_TUNE_SSE_SPLIT_REGS]
> +/* NB: movaps/movups is one byte shorter than movdaq/movdqu. But it
> + isn't the case for AVX nor AVX512. */
> #define TARGET_SSE_TYPELESS_STORES \
> - ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES]
> + (!TARGET_AVX && ix86_tune_features[X86_TUNE_SSE_TYPELESS_STORES])
This is wrong place to disable the feature.
Uros.
> #define TARGET_SSE_LOAD0_BY_PXOR
> ix86_tune_features[X86_TUNE_SSE_LOAD0_BY_PXOR]
> #define TARGET_MEMORY_MISMATCH_STALL \
> ix86_tune_features[X86_TUNE_MEMORY_MISMATCH_STALL]
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 6e9c9bd2fb6..bb096133880 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -1980,9 +1980,7 @@
>(and (eq_attr "alternative" "1")
> (match_test "TARGET_AVX512VL"))
> (const_string "XI")
> - (ior (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL")
> - (and (eq_attr "alternative" "3")
> -(match_test "TARGET_SSE_TYPELESS_STORES")))
> + (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL")
> (const_string "V8SF")
> ]
> (const_string "OI")))])
> diff --git a/gcc/testsuite/gcc.target/i386/pr91461-1.c
> b/gcc/testsuite/gcc.target/i386/pr91461-1.c
> new file mode 100644
> index 000..0c94b8e2b76
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr91461-1.c
> @@ -0,0 +1,66 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mavx" } */
> +/* { dg-final { scan-assembler "\tvmovdqa\t" } } */
> +/* { dg-final { scan-assembler "\tvmovdqu\t" } } */
> +/* { dg-final { scan-assembler "\tvmovapd\t" } } */
> +/* { dg-final { scan-assembler "\tvmovupd\t" } } */
> +/* { dg-final { scan-assembler-not "\tvmovaps\t" } } */
> +/* { dg-final { scan-assembler-not "\tvmovups\t" } } */
> +
> +#include
> +
> +void
> +foo1 (__m128i *p, __m128i x)
> +{
> + *p = x;
> +}
> +
> +void
> +foo2 (__m128d *p, __m128d x)
> +{
> + *p = x;
> +}
> +
> +void
> +foo3 (__float128 *p, __float128 x)
> +{
> + *p = x;
> +}
> +
> +void
> +foo4 (__m128i_u *p, __m128i x)
> +{
> + *p = x;
> +}
> +
> +void
> +foo5 (__m128d_u *p, __m128d x)
> +{
> + *p = x;
> +}
> +
> +typedef __float128 __float128_u __attribute__ ((__aligned__ (1)));
> +
> +void
> +foo6 (__float128_u *p, __float128 x)
> +{
> + *p = x;
> +}
> +
> +#ifdef __x86_64__
> +typedef __int128 __int128_u __attribute__ ((__aligned__ (1)));
> +
> +extern __int128 int128;
> +
> +void
> +foo7 (__int128 *p)
> +{
> + *p = int128;
> +}
> +
> +void
> +foo8 (__int128_u *p)
> +{
> + *p = int128;
> +}
> +#endif
> diff --git a/gcc/testsuite/gcc.target/i386/pr91461-2.c
> b/gcc/testsuite/gcc.target/i386/pr91461-2.c
> new file mode 100644
> index 000..921cfaf9780
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr91461-2.c
> @@ -0,0 +1,19 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mavx" } */
> +/* { dg-final { scan-assembler
[Bug libstdc++/93470] [C++2a] std::reference_wrapper to function type is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470
--- Comment #2 from frankhb1989 at gmail dot com ---
Case:
#include
void foo() {}
int main()
{
std::ref(foo)();
}
Sorry, I missed to mention it only failed with `clang++ -std=c++2a` (using
Clang++ 9.0.1). G++ with `-std=c++2a` still accepts the code. However, it seems
that Clang++ is correct here.
Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?
On Mon, 27 Jan 2020, Ulrich Weigand wrote: > I see. I guess that makes me wonder what -fno-fast-math *ever* does > (except canceling a -ffast-math earlier on the command line). Looking > at the current code, -fno-fast-math (just like -ffast-math) only ever > sets flags whose default is not overridden on the command line, but > then it always sets them to their default value! As a general principle, more specific flags take precedence over less specific ones, regardless of the command-line order. So it's correct for -ffast-math and -fno-fast-math not to do anything with a flag that was explicitly overridden by the user (modulo any issues where a particular combination of flags is unsupported by GCC, as with the "%<-fassociative-math%> disabled; other options take precedence" case in toplev.c). -- Joseph S. Myers jos...@codesourcery.com
RE: Home care Centers
Hi, Did you had a chance to review my previous mail which I sent across? If you are interested please revert me with your target requirement, so that I can get back to you with more information on the counts and pricing. Thank you and looking forward for your response. Regards, Olivia Martin | Manager Demand Generation| If you do not wish to receive further emails, please respond with "Unsubscribe" in the subject line. From: Olivia Martin [mailto:olivia.mar...@solutiontradeinfra.com] Sent: 21 January 2020 16:35 To: 'gcc-patches@gcc.gnu.org' Subject: Home care Centers Hi, Just wanted to check your interest in acquiring the records of Home care Centers/Agencies. If you are interested please let me know your target Geography, so that I can revert with further information on counts and pricing. Thank you and I look forward for your response. Regards, Olivia Martin | Manager Demand Generation| To opt out, please reply with Opt Out in the Subject Line.
[Bug libgomp/93471] New: GCC-9.2.0 libgomp configuration passes bogus mingw32 library search paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471
Bug ID: 93471
Summary: GCC-9.2.0 libgomp configuration passes bogus mingw32
library search paths
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: keith.marshall at mailinator dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Building GCC-9.2.0 for mingw32 target, initially as GNU/Linux hosted
cross-compiler, and subsequently using that cross-compiler to build
cross-native for Win32 deployment, both builds fail at libgomp configuration
step, because libpthread.a cannot be found ... in spite of it being available
at its correctly installed location, relative to the associated pthreads header
files, which are found.
Specifically, failure to find the library is because the GCC-9.2.0 build
system, which does pass valid -I search paths, passes two entirely bogus -L
search paths, and no valid -L path, to the linker; both -L paths which are
passed lie within the non-existent, and never created,
${top_builddir}/mingw32/winsup hierarchy.
I can kludge around this, by manually creating the
${top_builddir}/mingw32/winsup/mingw directory, and creating libpthread.a
within it, as a hard link to the properly installed library, (which in my build
case is /home/keith/mingw32/lib/pthread.a), but that's a hideous kludge, to
work around a failing of the build system itself. Furthermore, it does have to
be a hard link, or a physical copy ... logically I had hoped that creating
${top_builddir}/mingw32/winsup as a physical directory hierarchy, with mingw as
a symbolic link within that, as a reference to /home/keith/mingw32/lib, would
have been sufficient, but apparently it is not.
I've never encountered any such issue, building previous GCC versions back as
far as GCC-4.8.2, and through to GCC-8.2.0, so it appears that this is a newly
introduced build system defect, with GCC-9.x
[Bug tree-optimization/71625] missing strlen optimization on different array initialization style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625 --- Comment #25 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8f25c39c454d7d3d323edf014a653649946352bd commit r10-6266-g8f25c39c454d7d3d323edf014a653649946352bd Author: Jason Merrill Date: Sun Jan 26 22:19:47 2020 -0500 c++: Fix array of char typedef in template (PR90966). Since Martin Sebor's patch for PR 71625 to change braced array initializers to STRING_CST in some cases, we need to be ready for STRING_CST with types that are changed by tsubst. fold_convert doesn't know how to deal with STRING_CST, which is reasonable; we really shouldn't expect it to here. So let's handle STRING_CST separately. PR c++/90966 * pt.c (tsubst_copy) [STRING_CST]: Don't use fold_convert.
[Bug c++/90966] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:16155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90966 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8f25c39c454d7d3d323edf014a653649946352bd commit r10-6266-g8f25c39c454d7d3d323edf014a653649946352bd Author: Jason Merrill Date: Sun Jan 26 22:19:47 2020 -0500 c++: Fix array of char typedef in template (PR90966). Since Martin Sebor's patch for PR 71625 to change braced array initializers to STRING_CST in some cases, we need to be ready for STRING_CST with types that are changed by tsubst. fold_convert doesn't know how to deal with STRING_CST, which is reasonable; we really shouldn't expect it to here. So let's handle STRING_CST separately. PR c++/90966 * pt.c (tsubst_copy) [STRING_CST]: Don't use fold_convert.
[COMMITTED] c++: Fix array of char typedef in template (PR90966).
Since Martin Sebor's patch for PR 71625 to change braced array initializers
to STRING_CST in some cases, we need to be ready for STRING_CST with types
that are changed by tsubst. fold_convert doesn't know how to deal with
STRING_CST, which is reasonable; we really shouldn't expect it to here. So
let's handle STRING_CST separately.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/90966
* pt.c (tsubst_copy) [STRING_CST]: Don't use fold_convert.
---
gcc/cp/pt.c | 13 -
gcc/testsuite/g++.dg/cpp0x/initlist-array10.C | 14 ++
2 files changed, 26 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array10.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 45c204e4269..6e614d5a058 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -16772,7 +16772,6 @@ tsubst_copy (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
case INTEGER_CST:
case REAL_CST:
-case STRING_CST:
case COMPLEX_CST:
{
/* Instantiate any typedefs in the type. */
@@ -16782,6 +16781,18 @@ tsubst_copy (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
return r;
}
+case STRING_CST:
+ {
+ tree type = tsubst (TREE_TYPE (t), args, complain, in_decl);
+ r = t;
+ if (type != TREE_TYPE (t))
+ {
+ r = copy_node (t);
+ TREE_TYPE (r) = type;
+ }
+ return r;
+ }
+
case PTRMEM_CST:
/* These can sometimes show up in a partial instantiation, but never
involve template parms. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array10.C
b/gcc/testsuite/g++.dg/cpp0x/initlist-array10.C
new file mode 100644
index 000..fb9e136b56e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array10.C
@@ -0,0 +1,14 @@
+// PR c++/90966
+// { dg-do compile { target c++11 } }
+
+template
+void f()
+{
+ using S = signed char;
+ constexpr const S v[]{0};
+}
+
+int main()
+{
+ f();
+}
base-commit: 1f2e84238c9f079747804026b6225ec8c1d0e4b7
--
2.18.1
[Bug libstdc++/93470] [C++2a] std::reference_wrapper to function type is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Testcase please, as requested by https://gcc.gnu.org/bugs/
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #2 from Jonathan Wakely --- This is a bug in your libc headers (and I'm guessing you're on OS X). The aligned_alloc function should be declared for C++17 and later, irrespective of the _XOPEN_SOURCE value.
[Bug middle-end/93194] -fpatchable-function-entries : __patchable_function_entries has wrong sh_addralign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Should be fixed by the commit referenced in c#2.
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Please provide the rest of the info requested by https://gcc.gnu.org/bugs (especially the output of gcc -v)
Re: [PATCH] get source line for diagnostic from preprocessed file / PR preprocessor/79106
On Mon, 2019-12-16 at 11:18 +, Bader, Lucas wrote: > Hello, > > within a compile cluster, only the preprocessed output of GCC is transferred > to remote nodes for compilation. > When GCC produces advanced diagnostics (with -fdiagnostics-show-caret), e.g. > prints out the affected source > line and fixit hints, it attempts to read the source file again, even when > compiling a preprocessed file (-fpreprocessed). > This leads to wrong diagnostics when building with a compile cluster, or, > more generally, when changing or deleting the original source file. > > This patch attempts to alter the behavior by implementing a > location_get_source_line_preprocessed > function that can be used in diagnostic-show-locus.c in case a preprocessed > file is compiled. > There was some previous discussion on this behavior on PR preprocessor/79106. > > This is my first patch to GCC, so in case something is wrong with the format, > please let me know. > > Best regards > Lucas > > 2019-12-16 Lucas Bader > > PR preprocessor/79106 > * c-opts.c (c_common_handle_option): pass -fpreprocessed > option value to global diagnostic configuration > > * diagnostic-show-locus.c (layout::layout): read line from source or > preprocessed > file based on -fpreprocessed value > (source_line::source_line): read line from source or preprocessed > file based on -fpreprocessed value > (layout::print_line): read line from source or preprocessed > file based on -fpreprocessed value > > * diagnostic.h (diagnostic_context): new members for reading > source lines from preprocessed files > * diagnostic.c (diagnostic_initialize): initialize new members > > * input.c (location_get_source_line_preprocessed): new function > to read source lines from preprocessed files > (test_reading_source_line_preprocessed): new test case > (input_c_tests): execute new test case > > * opts-global.c (read_cmdline_options): pass input filename to global > diagnostic context Note this is not forgotten. But it seems more appropriate for gcc-11 rather than gcc-10. Jeff >
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #8 from Devin Hussey --- Seems to work. ~ $ ~/gcc-test/bin/x86_64-pc-cygwin-gcc.exe -mavx2 -O3 _mm_sllv_bug.c ~ $ ./a.exe Without optimizations (correct result): 8000 fff8 With optimizations (incorrect result): 8000 fff8 ~ $ And checking the assembly, the shifts are constant propagated. The provided test file also passes.
[Bug libstdc++/93470] New: [C++2a] std::reference_wrapper to function type is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470 Bug ID: 93470 Summary: [C++2a] std::reference_wrapper to function type is broken Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: frankhb1989 at gmail dot com Target Milestone: --- In `std::reference_wrapper::operator()` in : #if __cplusplus > 201703L static_assert(sizeof(type), "type must be complete"); #endif The static assertion is ill-formed when `type` is a function type, required by instantiation of function template specialization `std::reference_wrapper::operator()` when `T` is a function type.
[Bug c++/93443] gcc/cp/coroutines.cc:3555:23: runtime error: load of value 255, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93443 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:1f2e84238c9f079747804026b6225ec8c1d0e4b7 commit r10-6265-g1f2e84238c9f079747804026b6225ec8c1d0e4b7 Author: Iain Sandoe Date: Mon Jan 27 10:13:09 2020 + coroutines: Ensure the ramp return object is checked (PR93443). As the PR shows, there is a pathway through the code where the no_warning value is not set, which corresponds to a missing check of the ramp return when it was constructed from the 'get return object' Fixed by ensuring that the check of the return value is carried out for both return cases. gcc/cp/ChangeLog: 2020-01-27 Iain Sandoe PR c++/93443 * coroutines.cc (morph_fn_to_coro): Check the ramp return value when it is constructed from the 'get return object'.
[Bug libstdc++/93469] New: memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 Bug ID: 93469 Summary: memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: karen.arutyunov at gmail dot com Target Milestone: --- While packaging ICU 65.1 for build2 toolchain I end up with the following error on macOS 10.15.2 with g++ 9.2.0 (Homebrew GCC 9.2.0_2): In file included from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/bits/stl_algo.h:59, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/string:52, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/stdexcept:39, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/array:39, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/tuple:39, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/bits/unique_ptr.h:37, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/memory:80, from /Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/unicode/localpointer.h:45, from /Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/unicode/udata.h:23, from /Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/udatamem.h:24, from /Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/umapfile.cpp:26: /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/cstdlib:132:11: error: '::aligned_alloc' has not been declared 132 | using ::aligned_alloc; | ^ The issue seems to relate to libstdc++ headers and pops up if the C++20 standard is specified on the command line and a program defines the _XOPEN_SOURCE macro and includes the memory header. It can be reproduced with the following commands: % cat
[Bug go/93468] New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 --- Comment #2 from Svante Signell --- Created attachment 47720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47720=edit Add hurd to // +build
[Bug go/93468] New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 --- Comment #1 from Svante Signell --- Created attachment 47719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47719=edit Add hurd to // +build
Re: [PATCH] Clean up references to Subversion in documentation sources.
On Mon, Jan 13, 2020 at 01:12:15PM -0500, Eric S. Raymond wrote: > Jonathan Wakely : > > Email the patches to gcc-patches@gcc.gnu.org, that's how things get > > merged. > > > > We're not looking to change any workflows now. > > Roger that. > > Once the dust from the conversion has settled, though, there is a > related issue I intend to bring up on the main list. > > You've only collected about 60% of the potential benefits from git > by adopting git itself. The other 40% would come from moving > to to one of the modern git-centric forges like GitHub or GitLab. NAK. Our development model fits our needs well, even with all its warts. A "pull request" model would not fit well *at all*. The "everything passes through email" model is *good*, not in the least because it puts everyone on a level playing field. Everyone can see everything, and comment on everything. And if it slows you down, well, that is a good thing as well probably! Thought and carefulness and looking at things from multiple angles is what we need, not raw speed: we need good changes, we do not need making it easier to get your changes included at the cost of basic quality. Anyway, 90% of the advantages of using Git come from using it *locally*, which many of us have been doing since forever and a day already. Segher
[Bug go/93468] New: New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 Bug ID: 93468 Summary: New patches to build gcc-10 on GNU/Hurd Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: svante.signell at gmail dot com CC: cmang at google dot com Target Milestone: --- Created attachment 47718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47718=edit netpoll_hurd.go update Fixes FTBFS for gcc-snapshot-20200124 on GNU/Hurd Hello, Test-compiling Debian Version gcc-10-10-20200124-1 reveals that three small fixes are needed for a successful build, one in runtime/netpoll_hurd.go, one in syscall/sockcmsg_unix_other.go and one in runtime/nbpipe_pipe2.go. The attached patches fixes the build and tests of libgo. There are still two tests failing due to linkage problems. When time permits I'll investigate these problems. Thanks!
