[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 --- Comment #13 from rguenther at suse dot de --- On Tue, 28 Jan 2020, ch3root at openwall dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 > > --- Comment #12 from Alexander Cherepanov --- > (In reply to rguent...@suse.de from comment #9) > > This example simply shows that we're propagating the equivalence > > y == x - 1 in the way that the controlled x - 1 becomes y (that's > > possibly a QOI issue in this particular case where we _do_ see > > that y is not initialized - but as said in general we cannot know) > > and that we then optimize condition ? uninit : 5 as 5 (we're > > optimistically treating uninit equal to 5 here which is OK). > > Right, nothing new here, just a simpler example. (Building something upon my > first example was not fun. This one proved to be much nicer.) > > > Note the (void)&y doesn't do anything but it really looks like > > it is required to make the testcase conforming (otherwise you > > wouldn't use it?). > > This is just a ritual dance dedicated to Itanium. C11, 6.3.2.1p2, has the > following text added for DR 338[1]: > > "If the lvalue designates an object of automatic storage duration that could > have been declared with the register storage class (never had its address > taken), and that object is uninitialized (not declared with an initializer and > no assignment to it has been performed prior to use), the behavior is > undefined." OK, so the (void)&y doesn't prevent GCC from allocating y to a register. Of course the wording above requires declaration with "register" which would make writing &y invalid. > OTOH maybe it's worth to spent a minute on this DR given we are discussing > speculative execution. [2] has a nice explanation of the topic. IIUC you can > try to hoist a dereference of a pointer from a loop -- you will just get a NaT > (Not-a-Thing) value in a register instead of a crash if the pointer is bad. > But > if your speculatively executed hoisted code have to write to memory a value > from a register that corresponds to an uninitialized variable and this > register > contains a NaT, you get your crash back:-) > > According to [3] the whole thing is to be EOLed the next year, so not sure how > relevant this is. Trap representations are still relevant (sNaN exists on most IEEE conforming architectures), and most of your testcases would also translate to floating-point entities (with more careful handling of "equality").
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 rockeet changed: What|Removed |Added CC||rockeet at gmail dot com --- Comment #19 from rockeet --- Is there a way(command line option or -DSOME_MACRO ...) to make gcc issue cmpxchg16b for std::atomic.compare_exchange_* ?
[Bug c/88660] [8/9/10 Regression] Invalid report of "set but used variable" with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88660 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #2 from Jeffrey A. Law --- I think we've just got the wrong value for the last argument to the convert_lvalue_to_ravlue call within c_parser_switch_statement. That argument controls whether or not we mark the expression with DECL_READ_P.
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #16 from Alan Modra --- It is possible to fix this in the assembler too, but I'm reluctant to do so. If we make some sort of promise that .set x,y .set x,y gives the same results as when only the first .set is present, then gas needs to correctly calculate "no change in y". That is complicated in the general case of an arbitrary expression for y. It's even surprisingly complicated if y is just a single symbol.
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #15 from Peter Bergner --- So using the configure setup (minus the -specs=... options) in Comment 13, I was able to recreate the issue using unpatched Python-3.9.0a3 and GCC10. The failing command is: /home/bergner/gcc/install/gcc-fsf-mainline-base/libexec/gcc/powerpc64le-linux/10.0.1/lto1 -quiet -dumpdir ./ -dumpbase libpython3.9.a -mcpu=power8 -mtune=power8 -m64 -auxbase-strip libpython3.9.so.lto.o -g -O2 -version -fno-openmp -fno-openacc -fPIC -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -fno-semantic-interposition -flinker-output=dyn @/tmp/ccikqTcI -o getbuildinfo.s I notice if I drop the -fno-semantic-interposition option, I only get 1: .set_PyObject_AssertFailed.localalias,_PyObject_AssertFailed instead of 2.
[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 --- Comment #2 from Richard Smith --- Still crashes GCC trunk from today: https://godbolt.org/z/zWvT4w
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 --- Comment #7 from Bill Schmidt --- The ELFv2 ABI Appendix B calls for a bcd data type defined as: typedef bcd vector unsigned char; and then defines a bunch of potential functions that can be built around it. The BCD functions (such as __builtin_bcdadd), earlier in the appendix, are defined in terms of vector unsigned char. GCC has just never gotten around to implementing these, due to a combination of user disinterest and resource constraints. We'll have to step up to these, hopefully in GCC 11 (though our plate is really full there already).
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #14 from Victor Stinner --- Fedora downstream issue: https://bugzilla.redhat.com/show_bug.cgi?id=1795575
[Bug libgomp/93471] GCC-9.2.0 libgomp configuration passes bogus mingw32 library search paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471
--- Comment #4 from Keith Marshall ---
(In reply to Keith Marshall from comment #3)
> Although this initially manifests for libgomp, the actual source of the
> failure may lie elsewhere within the GCC build system. After placing
> libpthread.a into the ${top_builddir}/mingw32/winsup hierarchy, other
> components -- initially ada -- fail in identical circumstances, with
> identical -L path specs, except that it is -lws2_32 which cannot be found,
> unless it too is copied to the ${top_builddir}/mingw32/winsup hierarchy.
Interestingly, I can no longer reproduce this failure, w.r.t. -lws2_32. I
believe this to be the result of a local patch, which I've applied to Ada's
gsocket.h, to remove gratuitously introduced dependencies on getaddrinfo(),
getnameinfo(), and freeaddrinfo() functions, (which are unsupported in Windows
versions predating WinXP), replacing them with a MinGW emulation of Microsoft's
wspiapi.h fallback API, based on Microsoft's equivalent of a dlopen()/dlsym()
lookup, and so eliminating all direct link-time dependencies on -lws2_32, (even
though it remains specified in the linking command).
OTOH, the failure w.r.t. -lpthread remains consistently reproducible.
[Bug c++/91318] [C++][PATCH] warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-28 CC||law at redhat dot com Ever confirmed|0 |1 --- Comment #6 from Jeffrey A. Law --- Pings need to go to the gcc-patches mailing list. At this point we're well into stage4 (regression bugfixing) and ISTM this needs to defer to the next stage1 development cycle which typically starts in the spring.
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #13 from Victor Stinner --- I used 3.9.0a3 release of Python to reproduce the issue: https://www.python.org/ftp/python/3.9.0/Python-3.9.0a3.tar.xz Here are the full commands to configure Python on ppc64le for Fedora Rawhide with PGO+LTO optimizations. --- export CFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -fPIC -fwrapv' export CFLAGS_NODIST='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -fPIC -fwrapv -fno-semantic-interposition' export CPPFLAGS='' export CXXFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -fPIC -fwrapv' export FCFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -I/usr/lib64/gfortran/modules' export FFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -I/usr/lib64/gfortran/modules' export LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g' export LDFLAGS_NODIST='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fno-semantic-interposition -g' export LINKCC=gcc export LT_SYS_LIBRARY_PATH=/usr/lib64: export OPT='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -fPIC -fwrapv' ./configure --build=ppc64le-redhat-linux-gnu --host=ppc64le-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-ipv6 --enable-shared --with-computed-gotos=yes --with-dbmliborder=gdbm:ndbm:bdb --with-system-expat --with-system-ffi --enable-loadable-sqlite-extensions --with-dtrace --with-lto --with-ssl-default-suites=openssl --with-valgrind --without-ensurepip --enable-optimizations --- Then run "make". Note: I prefer to "mkdir build; cd build" and run "../configure (...)" to not pollute sources with generated files (and be able to retry from scratch if neeed).
[Bug c++/92948] internal compiler error: in tsubst_copy, at cp/pt.c:15788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92948 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code, patch, ||rejects-valid --- Comment #6 from Marek Polacek --- Now posted https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01896.html
[Bug fortran/93486] ICE on valid with nested submodules and long submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93486 --- Comment #2 from Andrew Benson --- The problem is caused when loading (generic or operator) interfaces from a module file. The module name can include the submodule name, so a size of 2*GFC_MAX_SYMBOL_LEN+2 is required to read this in. The attached patch fixes this problem.
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384
--- Comment #12 from Victor Stinner ---
Created attachment 47726
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47726&action=edit
preprocessed object.c (gcc -E), bzip2 compressed
Here is the gcc -E output of Objects/object.c.
Truncated extract (function body replaced with "..."):
# 446 "../Include/cpython/object.h"
__attribute__ ((visibility ("default"))) void _PyObject_AssertFailed(
PyObject *obj,
const char *expr,
const char *msg,
const char *file,
int line,
const char *function);
void
_PyObject_AssertFailed(PyObject *obj, const char *expr, const char *msg,
const char *file, int line, const char *function)
{
...
Py_FatalError("_PyObject_AssertFailed");
}
I modified the command which creates Objects/object.o to get the preprocessor
output, but it's not directly related to the libpython3.9.so linking command
(which uses object.o and not object.c).
[Bug fortran/93486] ICE on valid with nested submodules and long submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93486 --- Comment #1 from Andrew Benson --- Created attachment 47725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47725&action=edit Proposed patch
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 --- Comment #6 from Segher Boessenkool --- [ Whoops, hit enter. ] We need to have a C type for decimal integer before we can use that at all.
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 --- Comment #5 from Segher Boessenkool --- bcdadd works with decimal *integers*; _Decimal128 is decimal *float*.
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #11 from Jakub Jelinek --- Seems node->call_for_symbol_and_aliases (symtab_node::noninterposable_alias, (void *)&new_node, true); if (new_node) return new_node; should catch that, so the question is why it hasn't been found. Will try to reproduce tomorrow.
[Bug lto/93384] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- *.localalias aliases are created by symtab_node::noninterposable_alias () method. So, the question is what are the guards that should prevent creating it multiple times (or whether it shouldn't append some number at the end if more than one alias is needed, though I don't really say what would be an advantage to create more than one.
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |10.0 Summary|Python 3.9.0a3 fails to |[10 Regression] Python |build on ppc64le with GCC |3.9.0a3 fails to build on |10.0.1: redefined symbol|ppc64le with GCC 10.0.1: |cannot be used on reloc |redefined symbol cannot be ||used on reloc
[Bug fortran/93486] New: ICE on valid with nested submodules and long submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93486 Bug ID: 93486 Summary: ICE on valid with nested submodules and long 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 causes an ICE with revision ad690d79cfbb905c5546c9333c5fd089d906505b: module ivs interface l module procedure l_ end interface l contains function l_() end function l_ end module ivs module aModeratleyLongModuleName use ivs interface module subroutine cmo() end subroutine cmo end interface end module aModeratleyLongModuleName submodule (aModeratleyLongModuleName) aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill contains module procedure cmo end procedure cmo end submodule aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill submodule (aModeratleyLongModuleName:aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill) sb end submodule sb submodule (aModeratleyLongModuleName:sb) sc end submodule sc $ 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 20200128 (experimental) (GCC) $ gfortran -c test.F90 -o test.o f951: internal compiler error: Segmentation fault 0xe1bc9f crash_signal ../../gcc-git/gcc/toplev.c:328 0x7f98119c71ef ??? /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x84b3f0 gfc_use_modules() ../../gcc-git/gcc/fortran/module.c:7315 0x85acc8 use_modules ../../gcc-git/gcc/fortran/parse.c:114 0x866daa parse_module ../../gcc-git/gcc/fortran/parse.c:6111 0x86733c gfc_parse_file() ../../gcc-git/gcc/fortran/parse.c:6428 0x8b780f 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 ICE goes away if the module and/or submodule names are made shorter.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419
Martin Sebor changed:
What|Removed |Added
Keywords||rejects-valid
Target|hurd freebsd|*-aix7.1 hurd freebsd
Status|ASSIGNED|NEW
--- Comment #7 from Martin Sebor ---
I can reproduce the error with an rs6000-aix7.1 cross:
$ cat pr93419.c && /build/rs6000-aix7.1/gcc-trunk/gcc/xgcc -B
/build/rs6000-aix7.1/gcc-trunk/gcc pr93419.c
#if __has_attribute (ifunc)
typedef void (fntype)(void);
fntype* fn_select (void) { return 0; }
void fn(void) __attribute__((ifunc ("fn_select")));
#endif
pr93419.c:5:6: error: 'ifunc' is not supported on this target
5 | void fn(void) __attribute__((ifunc ("fn_select")));
| ^~
It is issued in varasm.c under one of two conditions:
if (TREE_CODE (decl) == FUNCTION_DECL
&& cgraph_node::get (decl)->ifunc_resolver)
{
#if defined (ASM_OUTPUT_TYPE_DIRECTIVE)
if (targetm.has_ifunc_p ())
ASM_OUTPUT_TYPE_DIRECTIVE
(asm_out_file, IDENTIFIER_POINTER (id),
IFUNC_ASM_TYPE);
else
#endif
error_at (DECL_SOURCE_LOCATION (decl),
"%qs is not supported on this target", "ifunc");
}
Neither of these seems to be considered by the operator (in fact, it looks like
the only thing the handler does consider is the whether the attribute is
defined for the target), so confirmed as a bug. It seems that the conditions
in varasm.c (and anywhere else in the compiler) that determine whether or not
an attribute is supported should be abstracted into an API and tested by the
builtin handler during preprocessing as well as by later stages.
[Bug libstdc++/93479] compare_three_way allows comparing arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93479
--- Comment #2 from Jonathan Wakely ---
i.e.
--- a/libstdc++-v3/libsupc++/compare
+++ b/libstdc++-v3/libsupc++/compare
@@ -525,7 +525,9 @@ namespace std
// BUILTIN-PTR-THREE-WAY(T, U)
template
concept __3way_builtin_ptr_cmp
- = convertible_to<_Tp, const volatile void*>
+ = requires(_Tp&& __t, _Up&& __u)
+ { static_cast<_Tp&&>(__t) <=> static_cast<_Up&&>(__u); }
+ && convertible_to<_Tp, const volatile void*>
&& convertible_to<_Up, const volatile void*>
&& ! requires(_Tp&& __t, _Up&& __u)
{ operator<=>(static_cast<_Tp&&>(__t), static_cast<_Up&&>(__u)); }
[Bug libstdc++/93479] compare_three_way allows comparing arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93479 --- Comment #1 from Jonathan Wakely --- (In reply to Barry Revzin from comment #0) > The check for __3way_builtin_ptr_cmp needs to reject arrays, since the > expression declval() <=> declval() does not resolve to a built-in > operator comparing pointers (it doesn't resolve to any operator). I think it should require declval() <=> declval() to be valid. I forgot to actually check that.
[Bug c++/90333] [9/10 Regression] Can't apply attributes to lambdas with trailing returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/93479] compare_three_way allows comparing arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93479 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-28 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug c++/93480] Defaulted <=> doesn't expand array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-28 Ever confirmed|0 |1
[Bug fortran/93473] ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 --- Comment #8 from Andrew Benson --- I think this is PR87103 causing this problem. There's a patch in that PR (simply removing the check for the overlong symbol name also works as the symbol name length is already checked elsewhere). The patch has not been approved though as there's a better fix in the works -see https://gcc.gnu.org/ml/fortran/2018-09/msg00016.html
[Bug fortran/93473] ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #7 from Rainer Orth --- The new testcase ICEs on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (both 32 and 64-bit) as well as powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu: +FAIL: gfortran.dg/pr93473.f90 -O (internal compiler error) +FAIL: gfortran.dg/pr93473.f90 -O (test for excess errors) Excess errors: f951: internal compiler error: new_symbol(): Symbol name too long 0x8b450a2 gfc_report_diagnostic /vol/gcc/src/hg/master/local/gcc/fortran/error.c:782 0x8b450a2 gfc_internal_error(char const*, ...) /vol/gcc/src/hg/master/local/gcc/fortran/error.c:1402 0x8bebb58 gfc_new_symbol(char const*, gfc_namespace*) /vol/gcc/src/hg/master/local/gcc/fortran/symbol.c:3139 0x8b8bb5b read_module /vol/gcc/src/hg/master/local/gcc/fortran/module.c:5398 0x8b8bb5b gfc_use_module /vol/gcc/src/hg/master/local/gcc/fortran/module.c:7192 0x8b8e216 gfc_use_modules() /vol/gcc/src/hg/master/local/gcc/fortran/module.c:7316 0x8b9e6bc use_modules /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:114 0x8baa73a parse_module /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6111 0x8baab4c gfc_parse_file() /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6428 0x8bfbffd gfc_be_parse_file /vol/gcc/src/hg/master/local/gcc/fortran/f95-lang.c:210
[Bug c++/91008] error redeclaring the same type involving a non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91008 --- Comment #2 from Martin Sebor --- Clang rejects it because it doesn't yet support non-type template parameters of user-defined types (as the first error on line 9 implies).
[Bug c++/90609] [9/10 Regression] Compilation error in std::function default member initialization inside template class with defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90609 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #4 from Jason Merrill --- This seems to be fixed for 9.3/10.
[Bug middle-end/93437] [9/10 Regression] on protobuf generated code, -Warray-bounds is brittle and not very helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93437 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:4dd27b527c503aa50909fe1eb7d308266b1e103a commit r10-6309-g4dd27b527c503aa50909fe1eb7d308266b1e103a Author: Martin Sebor Date: Tue Jan 28 14:48:52 2020 -0700 PR middle-end/93437 - bogus -Warray-bounds on protobuf generated code gcc/testsuite/ChangeLog: PR middle-end/93437 * g++.dg/warn/Wstringop-overflow-5.C: New test.
[Bug c++/93477] [10 Regression] __atribute__((weak)) variables sharing the same name in two named namespaces cause a multiple definition error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93477 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/90750] [9/10 Regression] ICE in cp_default_conversion, at cp/typeck.c:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90750 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
[Bug c++/93442] [8/9/10 Regression] lambda in if constexpr fails to compile since r8-5529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93442 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a4b4b1e3ac9a2c97f7550024c3cc5aff52e0614c commit r10-6308-ga4b4b1e3ac9a2c97f7550024c3cc5aff52e0614c Author: Jason Merrill Date: Tue Jan 28 16:06:33 2020 -0500 c++: Fix return deduction of lambda in discarded stmt. A return statement in a discarded statement is not used for return type deduction, but we still want to do deduction for a return statement in a lambda in a discarded statement. PR c++/93442 * parser.c (cp_parser_lambda_expression): Clear in_discarded_stmt.
[Bug c++/93477] [10 Regression] __atribute__((weak)) variables sharing the same name in two named namespaces cause a multiple definition error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93477 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:25d62480c89d6db90a66ba69f6dbaa820a1ac90b commit r10-6307-g25d62480c89d6db90a66ba69f6dbaa820a1ac90b Author: Jason Merrill Date: Tue Jan 28 15:15:20 2020 -0500 c++: Fix guard variable and attribute weak. My patch for PR 91476 worked for decls that are implicitly comdat/weak due to C++ linkage rules, but broke variables explicitly marked weak. PR c++/93477 PR c++/91476 * decl2.c (copy_linkage): Do copy DECL_ONE_ONLY and DECL_WEAK.
[Bug c++/91476] [9/10 Regression] const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91476 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:25d62480c89d6db90a66ba69f6dbaa820a1ac90b commit r10-6307-g25d62480c89d6db90a66ba69f6dbaa820a1ac90b Author: Jason Merrill Date: Tue Jan 28 15:15:20 2020 -0500 c++: Fix guard variable and attribute weak. My patch for PR 91476 worked for decls that are implicitly comdat/weak due to C++ linkage rules, but broke variables explicitly marked weak. PR c++/93477 PR c++/91476 * decl2.c (copy_linkage): Do copy DECL_ONE_ONLY and DECL_WEAK.
[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- Should be fixed on the trunk.
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 --- Comment #4 from Jens Seifert --- Power8 has bcdadd which can be only combined with _Decimal128 if you have some kind of conversion in between BCDs stored in vector register and _Decimal128. On Power9 vec_load_len/vec_store_len can be used to load variable length BCDs. On Power7/8 I can load variable length BCDs as well (with more instructions), but overall it is desirable to have the possibility to convert vector to _Decimal128 and vice versa. I suppose I can survive with inline assembly like below. The assembly works for p7-p9 with optimal speed. The memcpy inline between vector and _Decimal128 is not optimal for -mcpu=power7-9. Always a store/load (lacking XNOP) ending up in load-hit-store issue.
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 --- Comment #12 from Alexander Cherepanov --- (In reply to rguent...@suse.de from comment #9) > This example simply shows that we're propagating the equivalence > y == x - 1 in the way that the controlled x - 1 becomes y (that's > possibly a QOI issue in this particular case where we _do_ see > that y is not initialized - but as said in general we cannot know) > and that we then optimize condition ? uninit : 5 as 5 (we're > optimistically treating uninit equal to 5 here which is OK). Right, nothing new here, just a simpler example. (Building something upon my first example was not fun. This one proved to be much nicer.) > Note the (void)&y doesn't do anything but it really looks like > it is required to make the testcase conforming (otherwise you > wouldn't use it?). This is just a ritual dance dedicated to Itanium. C11, 6.3.2.1p2, has the following text added for DR 338[1]: "If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined." OTOH maybe it's worth to spent a minute on this DR given we are discussing speculative execution. [2] has a nice explanation of the topic. IIUC you can try to hoist a dereference of a pointer from a loop -- you will just get a NaT (Not-a-Thing) value in a register instead of a crash if the pointer is bad. But if your speculatively executed hoisted code have to write to memory a value from a register that corresponds to an uninitialized variable and this register contains a NaT, you get your crash back:-) According to [3] the whole thing is to be EOLed the next year, so not sure how relevant this is. [1] http://open-std.org/jtc1/sc22/wg14/www/docs/dr_338.htm [2] https://devblogs.microsoft.com/oldnewthing/?p=41003 [3] https://en.wikipedia.org/wiki/IA-64#End_of_life:_2021
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #18 from David Malcolm --- The setjmp ICE seen by David and Iain should be fixed by r10-6305-g5aebfb71763c7c8d0bb96adcd0a5f94de96a2a13 As noted in https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01889.html, I reproduced the bug and verified the fix via a stage 1 build on powerpc-ibm-aix7.2.0.0 (gcc111), where there were no remaining FAILs in analyzer.exp after the patch.
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #17 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5aebfb71763c7c8d0bb96adcd0a5f94de96a2a13 commit r10-6305-g5aebfb71763c7c8d0bb96adcd0a5f94de96a2a13 Author: David Malcolm Date: Tue Jan 28 10:06:24 2020 -0800 analyzer: fix ICE when longjmp isn't marked 'noreturn' (PR 93316) Comments 11-16 within PR analyzer/93316 discuss an ICE in some setjmp tests seen on AIX and powerpc-darwin9. The issue turned out to be an implicit assumption that longjmp is marked "noreturn". There are two places in engine.cc where the code attempted to locate the longjmp GIMPLE_CALL by finding the final stmt within its supernode, in one place casting it via "as_a ", in the other using it as the location_t of the "rewinding from longjmp..." event. When longjmp isn't marked noreturn, its basic block and hence supernode can have additional stmts after the longjmp; in the setjmp-3.c case this was a GIMPLE_RETURN, leading to a ICE when casting this to a GIMPLE_CALL. This patch fixes the two places in question to use the rewind_info_t::get_longjmp_call member function introduced by 342e14ffa30e9163a1a75e0a4fb21b6883d58dbe, fixing the ICE (and ensuring the correct location_t is used for events). gcc/analyzer/ChangeLog: PR analyzer/93316 * engine.cc (rewind_info_t::update_model): Get the longjmp call stmt via get_longjmp_call () rather than assuming it is the last stmt in the longjmp's supernode. (rewind_info_t::add_events_to_path): Get the location_t for the rewind_from_longjmp_event via get_longjmp_call () rather than from the supernode's get_end_location ().
[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272 --- Comment #6 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:5c8a1211b9873a1b69ef7b2fddae181535bc3b0a commit r10-6304-g5c8a1211b9873a1b69ef7b2fddae181535bc3b0a Author: Vladimir N. Makarov Date: Tue Jan 28 15:43:44 2020 -0500 Fix for PR93272 - LRA: EH reg allocated to hold local variable 2020-01-28 Vladimir Makarov PR rtl-optimization/93272 * ira-lives.c (process_out_of_region_eh_regs): New function. (process_bb_node_lives): Call it.
[Bug c++/93475] With 100k+ mangled names, g++ appears to incorrectly mangle about 15% causing demangle failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93475 --- Comment #2 from Simon Hardy-Francis --- The other two links posted link to this gist [1] which contains a list of the presumably incorrectly mangled names which fail to demangle. The mangled names were harvested from g++ assembly files after compiling this open source project called Zeek [2]. Link [1] contains the list of mangled names which fail to demangle and which the LLVM guys suggest were incorrectly mangled in the first place. If you'd like to recreate the list then recompile Zeek [2] via assembly files and then harvest the mangled names from the assembly files. Friendly warning: Many of the mangled names are many KB long, and many of the demangled names are many 100 KB long due to gratuitous C++ templating! Good luck! [1] https://gist.github.com/simonhf/0d60bb94f2d90c1b32e4786b2d1062ad [2] https://github.com/zeek/zeek
[Bug c++/93442] [8/9/10 Regression] lambda in if constexpr fails to compile since r8-5529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93442 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
[Bug target/93448] PPC: missing builtin for DFP quantize(dqua,dquai,dquaq,dquaiq)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448 --- Comment #5 from Segher Boessenkool --- Great :-) We still should have builtins for this, of course.
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-28 Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- It is fine with -mcpu=power9, using the mfvsrld and mtvsrdd instructions. Not completely optimal probably, but much closer. What do you want this to use on power8 (and power7)?
[Bug ipa/93318] [10 regression] Firefox LTO+FDO ICEs in speculative_call_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93318 --- Comment #8 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:40d240315a6e5ff2010769bfa1c19264217b5f1c commit r10-6301-g40d240315a6e5ff2010769bfa1c19264217b5f1c Author: Jan Hubicka Date: Tue Jan 28 21:30:14 2020 +0100 ipa: fix handling of multiple speculations (PR93318) This patch started as work to resole Richard's comment on quadratic lookups in resolve_speculation. While doing it I however noticed multiple problems in the new speuclative call code which made the patch quite big. In particular: 1) Before applying speculation we consider only targets with at lest probability 1/2. If profile is sane at most two targets can have probability greater or equal to 1/2. So the new multi-target speculation code got enabled only in very special scenario when there ae precisely two target with precise probability 1/2 (which is tested by the single testcase). As a conseuqence the multiple target logic got minimal test coverage and this made us to miss several ICEs. 2) Profile updating in profile merging, tree-inline and indirect call expansion was wrong which led to inconsistent profiles (as already seen on the testcase). 3) Code responsible to turn speculative call to direct call was broken for anything with more than one target. 4) There were multiple cases where call_site_hash went out of sync which eventually leads to an ICE.. 5) Some code expects that all speculative call targets forms a sequence in the callee linked list but there is no code to maintain that invariant nor a verifier. Fixing this it became obvious that the current API of speculative_call_info is not useful because it really builds on fact tht there are precisely three components (direct call, ref and indirect call) in every speculative call sequence. I ended up replacing it with iterator API for direct call (first_speculative_call_target, next_speculative_call_target) and accessors for the other coponents updating comment in cgraph.h. Finally I made the work with call site hash more effetive by updating edge manipulation to keep them in sequence. So first one can be looked up from the hash and then they can be iterated by callee. There are other things that can be improved (for example the speculation should start with most common target first), but I will try to keep that for next stage1. This patch is mostly about getting rid of ICE and profile corruption which is a regression from GCC 9. Honza gcc/ChangeLog: 2020-01-28 Jan Hubicka PR lto/93318 * cgraph.c (cgraph_add_edge_to_call_site_hash): Update call site hash only when edge is first within the sequence. (cgraph_edge::set_call_stmt): Update handling of speculative calls. (symbol_table::create_edge): Do not set target_prob. (cgraph_edge::remove_caller): Watch for speculative calls when updating the call site hash. (cgraph_edge::make_speculative): Drop target_prob parameter. (cgraph_edge::speculative_call_info): Remove. (cgraph_edge::first_speculative_call_target): New member function. (update_call_stmt_hash_for_removing_direct_edge): New function. (cgraph_edge::resolve_speculation): Rewrite to new API. (cgraph_edge::speculative_call_for_target): New member function. (cgraph_edge::make_direct): Rewrite to new API; fix handling of multiple speculation targets. (cgraph_edge::redirect_call_stmt_to_callee): Likewise; fix updating of profile. (verify_speculative_call): Verify that targets form an interval. * cgraph.h (cgraph_edge::speculative_call_info): Remove. (cgraph_edge::first_speculative_call_target): New member function. (cgraph_edge::next_speculative_call_target): New member function. (cgraph_edge::speculative_call_target_ref): New member function. (cgraph_edge;:speculative_call_indirect_edge): New member funtion. (cgraph_edge): Remove target_prob. * cgraphclones.c (cgraph_node::set_call_stmt_including_clones): Fix handling of speculative calls. * ipa-devirt.c (ipa_devirt): Fix handling of speculative cals. * ipa-fnsummary.c (analyze_function_body): Likewise. * ipa-inline.c (speculation_useful_p): Use new speculative call API. * ipa-profile.c (dump_histogram): Fix formating. (ipa_profile_generate_summary): Watch for overflows. (ipa_profile): Do not require probablity to be 1/2; update to new API. * ipa-prop.c (ipa_make_edge_direct_to_target): Update to new API. (update_indirect_edges_after_inlining): Update to new API. * ipa-utils.c (ipa_merge_profiles): Rewrite merging of speculative cal
[Bug c++/93477] [10 Regression] __atribute__((weak)) variables sharing the same name in two named namespaces cause a multiple definition error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93477 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/90546] [9/10 Regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- Fixed for 9.3/10.
[Bug c++/90546] [9/10 Regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1c7061c7c352e086b64a60b91e5204f9757bfa97 commit r9-8186-g1c7061c7c352e086b64a60b91e5204f9757bfa97 Author: Jason Merrill Date: Tue Jan 28 12:26:10 2020 -0500 c++: Allow template rvalue-ref conv to bind to lvalue ref. When I implemented the [over.match.ref] rule that a reference conversion function needs to match l/rvalue of the target reference type it changed our handling of this testcase. It seems to me that our current behavior is what the standard says, but it doesn't seem desirable, and all the other compilers have our old behavior. So let's limit the change to non-templates until there's some clarification from the committee. PR c++/90546 * call.c (build_user_type_conversion_1): Allow a template conversion returning an rvalue reference to bind directly to an lvalue.
[Bug c++/90546] [9/10 Regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:14e320dbc10cc796fd7ca0b6c44e0c9ac0901da9 commit r10-6300-g14e320dbc10cc796fd7ca0b6c44e0c9ac0901da9 Author: Jason Merrill Date: Tue Jan 28 12:26:10 2020 -0500 c++: Allow template rvalue-ref conv to bind to lvalue ref. When I implemented the [over.match.ref] rule that a reference conversion function needs to match l/rvalue of the target reference type it changed our handling of this testcase. It seems to me that our current behavior is what the standard says, but it doesn't seem desirable, and all the other compilers have our old behavior. So let's limit the change to non-templates until there's some clarification from the committee. PR c++/90546 * call.c (build_user_type_conversion_1): Allow a template conversion returning an rvalue reference to bind directly to an lvalue.
[Bug tree-optimization/89689] [8/9/10 regression] false warning -Wstringop-overflow=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89689 --- Comment #4 from Jeffrey A. Law --- So it occurs to me that in this specific case if DSE did a better job we would eliminate the first conditional branch which in turn would eliminate the need for jump threading and the const/copy propagation that is causing headaches. And just to be clear that won't fix the more general case where a conditional const/copy propagation changes the destination object of checked routine like memcpy. Even so, improving DSE is generally a good thing. So with that in mind, this is what the key parts of the IL looks like in DSE1: ;; basic block 2, loop depth 0, maybe hot ;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED) ;;pred: ENTRY (FALLTHRU,EXECUTABLE) h$data_33 = l.data; if (h$data_33 != &__sb_slop) goto ; [70.00%] else goto ; [30.00%] ;;succ: 3 [70.0% (guessed)] (TRUE_VALUE,EXECUTABLE) ;;4 [30.0% (guessed)] (FALSE_VALUE,EXECUTABLE) ;; basic block 3, loop depth 0, maybe hot ;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED) ;;pred: 2 [70.0% (guessed)] (TRUE_VALUE,EXECUTABLE) *h$data_33 = 0; ;;succ: 4 [always] (FALLTHRU,EXECUTABLE) ;; basic block 4, loop depth 0, maybe hot ;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED) ;;pred: 3 [always] (FALLTHRU,EXECUTABLE) ;;2 [30.0% (guessed)] (FALSE_VALUE,EXECUTABLE) _23 = __builtin_object_size (h$data_33, 0); _25 = __builtin___memcpy_chk (h$data_33, "abcd", 4, _23); We can see that the store in BB3 will always be overwritten by the memcpy. I'm actually a bit surprised that DSE didn't catch this and remove the *h$data_33 = 0 statement. [ Imagine a pause here while I throw things under the debugger... ] Ah, b_o_s is considered as potentially reading h$data_33. If we fix that, then we end up removing the store as dead and we get exactly the cascading events we want and the bogus warning is avoided. For reasons unknown we consider _b_o_s pure, not const. Jakub thinks were just being very cautious given the security implications around mucking up _b_o_s. ANyway, I'm going to dig into that history and see if we ever had it or discussed the constness of _b_o_s.
[Bug target/91461] Don't turn on X86_TUNE_SSE_TYPELESS_STORES for AVX/AVX512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91461 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from H.J. Lu --- Fixed.
[Bug ipa/93318] [10 regression] Firefox LTO+FDO ICEs in speculative_call_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93318 --- Comment #7 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:845bb366adcf702331de3d8022fd0e1c1c918607 commit r10-6299-g845bb366adcf702331de3d8022fd0e1c1c918607 Author: Jan Hubicka Date: Tue Jan 28 20:34:56 2020 +0100 ipa: fix handling of multiple speculations (PR93318) This patch started as work to resole Richard's comment on quadratic lookups in resolve_speculation. While doing it I however noticed multiple problems in the new speuclative call code which made the patch quite big. In particular: 1) Before applying speculation we consider only targets with at lest probability 1/2. If profile is sane at most two targets can have probability greater or equal to 1/2. So the new multi-target speculation code got enabled only in very special scenario when there ae precisely two target with precise probability 1/2 (which is tested by the single testcase). As a conseuqence the multiple target logic got minimal test coverage and this made us to miss several ICEs. 2) Profile updating in profile merging, tree-inline and indirect call expansion was wrong which led to inconsistent profiles (as already seen on the testcase). 3) Code responsible to turn speculative call to direct call was broken for anything with more than one target. 4) There were multiple cases where call_site_hash went out of sync which eventually leads to an ICE.. 5) Some code expects that all speculative call targets forms a sequence in the callee linked list but there is no code to maintain that invariant nor a verifier. Fixing this it became obvious that the current API of speculative_call_info is not useful because it really builds on fact tht there are precisely three components (direct call, ref and indirect call) in every speculative call sequence. I ended up replacing it with iterator API for direct call (first_speculative_call_target, next_speculative_call_target) and accessors for the other coponents updating comment in cgraph.h. Finally I made the work with call site hash more effetive by updating edge manipulation to keep them in sequence. So first one can be looked up from the hash and then they can be iterated by callee. There are other things that can be improved (for example the speculation should start with most common target first), but I will try to keep that for next stage1. This patch is mostly about getting rid of ICE and profile corruption which is a regression from GCC 9. gcc/ChangeLog: PR lto/93318 * cgraph.c (cgraph_add_edge_to_call_site_hash): Update call site hash only when edge is first within the sequence. (cgraph_edge::set_call_stmt): Update handling of speculative calls. (symbol_table::create_edge): Do not set target_prob. (cgraph_edge::remove_caller): Watch for speculative calls when updating the call site hash. (cgraph_edge::make_speculative): Drop target_prob parameter. (cgraph_edge::speculative_call_info): Remove. (cgraph_edge::first_speculative_call_target): New member function. (update_call_stmt_hash_for_removing_direct_edge): New function. (cgraph_edge::resolve_speculation): Rewrite to new API. (cgraph_edge::speculative_call_for_target): New member function. (cgraph_edge::make_direct): Rewrite to new API; fix handling of multiple speculation targets. (cgraph_edge::redirect_call_stmt_to_callee): Likewise; fix updating of profile. (verify_speculative_call): Verify that targets form an interval. * cgraph.h (cgraph_edge::speculative_call_info): Remove. (cgraph_edge::first_speculative_call_target): New member function. (cgraph_edge::next_speculative_call_target): New member function. (cgraph_edge::speculative_call_target_ref): New member function. (cgraph_edge;:speculative_call_indirect_edge): New member funtion. (cgraph_edge): Remove target_prob. * cgraphclones.c (cgraph_node::set_call_stmt_including_clones): Fix handling of speculative calls. * ipa-devirt.c (ipa_devirt): Fix handling of speculative cals. * ipa-fnsummary.c (analyze_function_body): Likewise. * ipa-inline.c (speculation_useful_p): Use new speculative call API. * ipa-profile.c (dump_histogram): Fix formating. (ipa_profile_generate_summary): Watch for overflows. (ipa_profile): Do not require probablity to be 1/2; update to new API. * ipa-prop.c (ipa_make_edge_direct_to_target): Update to new API. (update_indirect_edges_after_inlining): Update to new API. * ipa-utils.c (ipa_merge_profiles): Rewrite merging of speculative call profiles. * profile-coun
[Bug target/91461] Don't turn on X86_TUNE_SSE_TYPELESS_STORES for AVX/AVX512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91461 --- Comment #4 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:dd9b529f08c3c6064c37234922d298336d78caf7 commit r10-6298-gdd9b529f08c3c6064c37234922d298336d78caf7 Author: H.J. Lu Date: Tue Jan 28 11:32:56 2020 -0800 i386: Prefer TARGET_AVX over TARGET_SSE_TYPELESS_STORES movaps/movups is one byte shorter than movdqa/movdqu. But it isn't the case for AVX nor AVX512. This patch prefers TARGET_AVX over TARGET_SSE_TYPELESS_STORES and adjust vmovups checks in assembly ouputs. gcc/ PR target/91461 * config/i386/i386.md (*movoi_internal_avx): Remove TARGET_SSE_TYPELESS_STORES check. (*movti_internal): Prefer TARGET_AVX over TARGET_SSE_TYPELESS_STORES. (*movtf_internal): Likewise. * config/i386/sse.md (mov_internal): Prefer TARGET_AVX over TARGET_SSE_TYPELESS_STORES. Remove " == 16" check from TARGET_SSE_TYPELESS_STORES. gcc/testsuite/ PR target/91461 * gcc.target/i386/avx256-unaligned-store-2.c: Don't check vmovups. * gcc.target/i386/avx256-unaligned-store-3.c: Likewise. * 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.
[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 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- Fixed 3d056cbfb3484f4037b34c908b26e1c6776c86b5
[Bug lto/93384] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384
--- Comment #9 from Peter Bergner ---
(In reply to Victor Stinner from comment #7)
>
> And it's implemented as:
>
> void
> _PyObject_AssertFailed(PyObject *obj, const char *expr, const char *msg,
>const char *file, int line, const char *function)
> {
>...
> }
Can you also attach the preprocessed source file that -save-temps also created?
[Bug lto/93384] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #8 from Peter Bergner --- The two error locations are the same, namely: bl _PyObject_AssertFailed.localalias Earlier in the asm file, we have: .type _PyObject_AssertFailed, @function _PyObject_AssertFailed: ... .cfi_endproc .LFE6858: .size _PyObject_AssertFailed,.-_PyObject_AssertFailed .set_PyObject_AssertFailed.localalias,_PyObject_AssertFailed .set_PyObject_AssertFailed.localalias,_PyObject_AssertFailed So we're creating that alias twice. If I remove one of them, it assembles fine. Does the source have some typo where it creates the same alias twice?
[Bug lto/93384] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384
--- Comment #7 from Victor Stinner ---
sh-5.0# as -a64 -mpower8 -many -mlittle -o test.o getbuildinfo.s
getbuildinfo.s: Assembler messages:
getbuildinfo.s:87427: Error: redefined symbol cannot be used on reloc
getbuildinfo.s:261948: Error: redefined symbol cannot be used on reloc
...
addi 5,5,.LC715@toc@l
li 4,0
bl _PyObject_AssertFailed.localalias <= LINE 87427
.LVL7500:
.loc 31 2180 9 is_stmt 0 view .LVU23717
...
...
addi 5,5,.LC715@toc@l
li 4,0
bl _PyObject_AssertFailed.localalias <= LINE 261948
.LVL25059:
...
---
I found "_PyObject_AssertFailed.localalias" somewhere else:
...
.LFE6858:
.size _PyObject_AssertFailed,.-_PyObject_AssertFailed
.set_PyObject_AssertFailed.localalias,_PyObject_AssertFailed
.set_PyObject_AssertFailed.localalias,_PyObject_AssertFailed
.align 2
.globl PyInit_xxsubtype
.type PyInit_xxsubtype, @function
PyInit_xxsubtype:
...
---
In Python, _PyObject_AssertFailed() is declared in Include/cpython/object.h by:
PyAPI_FUNC(void) _PyObject_AssertFailed(
PyObject *obj,
const char *expr,
const char *msg,
const char *file,
int line,
const char *function);
Using gcc -E, I got:
# 446 "../Include/cpython/object.h"
__attribute__ ((visibility ("default"))) void _PyObject_AssertFailed(
PyObject *obj,
const char *expr,
const char *msg,
const char *file,
int line,
const char *function);
And it's implemented as:
void
_PyObject_AssertFailed(PyObject *obj, const char *expr, const char *msg,
const char *file, int line, const char *function)
{
...
}
[Bug lto/93384] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #6 from Victor Stinner --- Even when compressed with bzip2 -9, the assembly file is still 6.9 MB. Bugzilla doesn't allow files larger than 1 MB. Here is the file: http://haypo.alwaysdata.net/tmp/getbuildinfo.s.bz2
[Bug lto/93384] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #5 from Victor Stinner --- $ gcc -save-temps -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fno-semantic-interposition -g -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fno-semantic-interposition -g -o libpython3.9.so Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/token.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/capsule.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/interpreteridobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/picklebufobject.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/ast_unparse.o Python/bltinmodule.o Python/ceval.o Python/codecs.o Python/compile.o Python/context.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/hamt.o Python/import.o Python/importdl.o Python/initconfig.o Python/marshal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/peephole.o Python/preconfig.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o Python/pydtrace.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o Modules/_functoolsmodule.o Modules/_operator.o Modules/_collectionsmodule.o Modules/_abc.o Modules/itertoolsmodule.o Modules/atexitmodule.o Modules/signalmodule.o Modules/_stat.o Modules/timemodule.o Modules/_threadmodule.o Modules/_localemodule.o Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o Modules/faulthandler.o Modules/_tracemalloc.o Modules/hashtable.o Modules/symtablemodule.o Modules/xxsubtype.o Python/frozen.o -lcrypt -lpthread -ldl -lutil -lm -lm getbuildinfo.s: Assembler messages: getbuildinfo.s:87427: Error: redefined symbol cannot be used on reloc getbuildinfo.s:261948: Error: redefined symbol cannot be used on reloc lto-wrapper: fatal error: gcc returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status Oh wait, it created a file called getbuildinfo.s (3,965,403 lines): I attach it to the issue.
[Bug lto/93384] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #4 from Victor Stinner --- > Can you use -save-temps and look at the generated assembler file in around > those two lines? This could be some inline-asm that causes the error too. The error occurs on linking .o files into libpython3.9.so when at the second step of the profile guided optimization (PGO); Python is rebuilt using the collected profiles. I added -save-temps and gcc created a libpython3.9.so.lto_wrapper_args file: --- -fresolution=-lm.res -flinker-output=dyn Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/token.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/capsule.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/interpreteridobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/picklebufobject.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/ast_unparse.o Python/bltinmodule.o Python/ceval.o Python/codecs.o Python/compile.o Python/context.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/hamt.o Python/import.o Python/importdl.o Python/initconfig.o Python/marshal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/peephole.o Python/preconfig.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o Modules/_functoolsmodule.o Modules/_operator.o Modules/_collectionsmodule.o Modules/_abc.o Modules/itertoolsmodule.o Modules/atexitmodule.o Modules/signalmodule.o Modules/_stat.o Modules/timemodule.o Modules/_threadmodule.o Modules/_localemodule.o Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o Modules/faulthandler.o Modules/_tracemalloc.o Modules/hashtable.o Modules/symtablemodule.o Modules/xxsubtype.o Python/frozen.o --- Processes running when the bug occurs: PID TTY STAT TIME COMMAND 19877 pts/0T 0:00 gcc -save-temps -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--a 19878 pts/0T 0:00 /usr/libexec/gcc/ppc64le-redhat-linux/10/collect2 -plugin /usr/libexec/gcc/ppc64le-redhat-linux/10/liblto_plugin.so -plugin-opt=/usr/libexe 19879 pts/0T 0:00 /usr/bin/ld -plugin /usr/libexec/gcc/ppc64le-redhat-linux/10/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/ppc64le-redhat-linux/10/lto-wrap 19880 pts/0T 0:00 /usr/libexec/gcc/ppc64le-redhat-linux/10/lto-wrapper @libpython3.9.so.lto_wrapper_args 19881 pts/0T 0:00 gcc @/tmp/ccRJQGYo 19882 pts/0T 0:55 /usr/libexec/gcc/ppc64le-redhat-linux/10/lto1 -quiet -dumpdir ./ -dumpbase libpython3.9.so -msecure-plt -mcpu=power8 -mtune=power8 -mcpu=po
[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461 Andrew Benson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Andrew Benson --- Fixed by https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commit;h=ad690d79cfbb905c5546c9333c5fd089d906505b
[Bug target/91116] bad register choices for rs6000 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91116 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Segher Boessenkool --- This seems to be fixed now. We now get foo: lwz 6,0(4) lwz 7,4(4) lwz 8,8(4) lwz 10,12(4) stw 6,0(3) stw 7,4(3) stw 8,8(3) stw 10,12(3) blr which of course still is worse than using lfd/stfd, but this is not a regression at all, it goes back to at least 4.6.
[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 #7 from CVS Commits --- The master branch has been updated by Andrew Benson : https://gcc.gnu.org/g:ad690d79cfbb905c5546c9333c5fd089d906505b commit r10-6296-gad690d79cfbb905c5546c9333c5fd089d906505b Author: Andrew Benson Date: Tue Jan 28 18:12:23 2020 + Increase GFC_MAX_MANGLED_SYMBOL_LEN to handle submodule names. PR fortran/93461 * 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. * gfortran.dg/pr93461.f90: New test.
[Bug bootstrap/93409] [10 Regression] gcn libgomp plugin fails to build for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409 Matthias Klose changed: What|Removed |Added CC||doko at debian dot org --- Comment #4 from Matthias Klose --- your proposed patch fails with: checking for suffix of object files... configure: error: in `/home/packages/gcc/10/gcc-10-10-202 00128/build-gcn/amdgcn-amdhsa/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details mv -f .deps/findcomp.Tpo .deps/findcomp.Plo
[Bug fortran/93473] ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 Andrew Benson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Benson --- Fixed by https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commit;h=a83b5cc5828ee34471de415e8893242dd3b0a91b
[Bug target/93448] PPC: missing builtin for DFP quantize(dqua,dquai,dquaq,dquaiq)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448 --- Comment #4 from Jens Seifert --- The inline asm constraint "d" works. Thank you.
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
--- Comment #2 from Jens Seifert ---
#include
typedef float _Decimal128 __attribute__((mode(TD)));
_Decimal128 bcdtodpd(vector double v)
{
_Decimal128 res;
memcpy(&res, &v, sizeof(res));
res = __builtin_denbcdq(0, res);
return res;
}
_Decimal128 bcdtodpd_opt(vector double bcd)
{
_Decimal128 res;
__asm__ volatile("xxlor 4,%x1,%x1;\n"
"xxpermdi 5,%x1,%x1,3;\n"
"denbcdq 0,%0,4":"=d"(res):"v"(bcd):"vs36","vs37");
return res;
}
vector double dpdtobcd(_Decimal128 dpd)
{
_Decimal128 bcd = __builtin_ddedpdq(0, dpd);
vector double res;
memcpy(&res, &bcd, sizeof(res));
return res;
}
vector double dpdtobcd_opt(_Decimal128 dpd)
{
vector double res;
__asm__ volatile("ddedpdq 0,4,%1;\n"
"xxpermdi %x0,4,5,0":"=v"(res):"d"(dpd):"vs36","vs37");
return res;
}
The non-inline assembly show store/load (very slow).
The assembly version does the conversion from vector to _Decimal128 with
optimal sequence for Power7 and above.
[Bug fortran/93473] ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Benson : https://gcc.gnu.org/g:a83b5cc5828ee34471de415e8893242dd3b0a91b commit r10-6295-ga83b5cc5828ee34471de415e8893242dd3b0a91b Author: Andrew Benson Date: Tue Jan 28 17:58:40 2020 + Allow concatenated module+submodule names. Increase length of char variables "parent1" and "parent2" in set_syms_host_assoc() to allow them to hold concatenated module + submodule names. 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.
[Bug fortran/93485] ICE in gfc_trans_array_ctor_element, at fortran/trans-array.c:1682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93485 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- This (no ac) seems to be accepted : $ cat z3.f90 program p integer :: n = 2 associate (i => n) print *, (i, i=1,n) end associate end $ gfortran-10-20200126 z3.f90 && ./a.out 1 2 $
[Bug fortran/93485] New: ICE in gfc_trans_array_ctor_element, at fortran/trans-array.c:1682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93485 Bug ID: 93485 Summary: ICE in gfc_trans_array_ctor_element, at fortran/trans-array.c:1682 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- ICEs with an array constructor, down to at least gfortran-4.9 : $ cat z1.f90 program p integer :: n = 2 associate (i => n) print *, sum([(i, i=1,n)]) end associate end $ cat z2.f90 program p integer :: n = 2 associate (i => n) print *, [(i, i=1,n)] end associate end $ gfortran-10-20200126 -c z1.f90 z1.f90:4:0: 4 | print *, sum([(i, i=1,n)]) | internal compiler error: Segmentation fault 0xd38ebf crash_signal ../../gcc/toplev.c:328 0x738238 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) ../../gcc/tree.h:3400 0x738238 gfc_trans_array_ctor_element ../../gcc/fortran/trans-array.c:1682 0x746ffc gfc_trans_array_constructor_value ../../gcc/fortran/trans-array.c:1879 0x747502 gfc_trans_array_constructor_value ../../gcc/fortran/trans-array.c:1852 0x747ffa trans_array_constructor ../../gcc/fortran/trans-array.c:2644 0x747ffa gfc_add_loop_ss_code ../../gcc/fortran/trans-array.c:2924 0x748755 gfc_conv_loop_setup(gfc_loopinfo*, locus*) ../../gcc/fortran/trans-array.c:5216 0x79f440 gfc_conv_intrinsic_arith ../../gcc/fortran/trans-intrinsic.c:4592 0x7a6fe6 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.c:10313 0x77916a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8661 0x782e15 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool) ../../gcc/fortran/trans-expr.c:8806 0x7adda7 gfc_trans_transfer(gfc_code*) ../../gcc/fortran/trans-io.c:2582 0x7314e7 trans_code ../../gcc/fortran/trans.c:2084 0x7aa8d2 build_dt ../../gcc/fortran/trans-io.c:2026 0x731507 trans_code ../../gcc/fortran/trans.c:2056 0x7cf6cf gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2276 0x731607 trans_code ../../gcc/fortran/trans.c:1960 0x76899d gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6823 0x6e2796 translate_all_program_units ../../gcc/fortran/parse.c:6305
[Bug fortran/93484] New: [8/9/10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93484 Bug ID: 93484 Summary: [8/9/10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With a missing declaration, starts to ICE with r7 : $ cat z1.f90 program p implicit none integer :: x(4) = [1,2,3,4] print *, [real(x(k))] end $ cat z2.f90 program p implicit none integer, parameter :: x(4) = [1,2,3,4] print *, [real(x(k))] end $ gfortran-6 -c z1.f90 z1.f90:4:21: print *, [real(x(k))] 1 Error: Symbol 'k' at (1) has no IMPLICIT type $ gfortran-10-20200126 -c z1.f90 z1.f90:1:0: 1 | program p | internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1120 0x776230 gfc_typenode_for_spec(gfc_typespec*, int) ../../gcc/fortran/trans-types.c:1120 0x77642e gfc_sym_type(gfc_symbol*) ../../gcc/fortran/trans-types.c:2247 0x71b346 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1764 0x71dfaf generate_local_decl ../../gcc/fortran/trans-decl.c:5894 0x6ddb82 do_traverse_symtree ../../gcc/fortran/symbol.c:4162 0x71ef54 generate_local_vars ../../gcc/fortran/trans-decl.c:6100 0x71ef54 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6758 0x6a8056 translate_all_program_units ../../gcc/fortran/parse.c:6305 0x6a8056 gfc_parse_file() ../../gcc/fortran/parse.c:6544 0x6f265f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug fortran/93483] New: ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483 Bug ID: 93483 Summary: ICE in gfc_constructor_copy, at fortran/constructor.c:103 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- While z0 works, special case z1 does not; down to at least r5 : $ cat z0.f90 program p integer, parameter :: a(2) = [1, 2] print *, [real :: a] print *, [real :: -a] print *, -[real :: a] print *, -[real :: -a] print * print *, [real :: [1, 2]] print *, [real :: -[1, 2]] print *, -[real :: [1, 2]] end $ cat z1.f90 program p print *, -[real :: -[1, 2]] print *, +[real :: +[1, 2]] end $ gfortran-10-20200126 z0.f90 && ./a.out 1. 2. -1. -2. -1. -2. 1. 2. 1. 2. -1. -2. -1. -2. $ gfortran-10-20200126 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbac5cf crash_signal ../../gcc/toplev.c:328 0x151181c splay_tree_foreach ../../libiberty/splay-tree.c:577 0x62d574 gfc_constructor_copy(splay_tree_s*) ../../gcc/fortran/constructor.c:103 0x61431b reduce_unary ../../gcc/fortran/arith.c:1269 0x61433f reduce_unary ../../gcc/fortran/arith.c:1272 0x614b8f eval_intrinsic ../../gcc/fortran/arith.c:1611 0x6836c4 match_level_2 ../../gcc/fortran/matchexp.c:490 0x6836e2 match_level_3 ../../gcc/fortran/matchexp.c:551 0x6837d4 match_level_4 ../../gcc/fortran/matchexp.c:599 0x6837d4 match_and_operand ../../gcc/fortran/matchexp.c:693 0x6839c2 match_or_operand ../../gcc/fortran/matchexp.c:722 0x683a92 match_equiv_operand ../../gcc/fortran/matchexp.c:765 0x683b64 match_level_5 ../../gcc/fortran/matchexp.c:811 0x682f41 gfc_match_expr(gfc_expr**) ../../gcc/fortran/matchexp.c:870 0x66a809 match_io_element ../../gcc/fortran/io.c:3729 0x66d195 match_io_list ../../gcc/fortran/io.c:3777 0x66d5a4 match_io ../../gcc/fortran/io.c:4476 0x6712ca gfc_match_print() ../../gcc/fortran/io.c:4533 0x69d0c1 match_word ../../gcc/fortran/parse.c:65 0x6a1a53 decode_statement ../../gcc/fortran/parse.c:537
[Bug fortran/93482] New: ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93482
Bug ID: 93482
Summary: ICE in gfc_resolve_character_array_constructor, at
fortran/array.c:2096
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Similar to pr65428, and down to at least r5 :
$ cat z1.f90
program p
print *, [[character::]]
end
$ cat z2.f90
program p
integer :: i
character, parameter :: c(0) = 'a'
print *, [[c]]
print *, [[('b',i=1,0)]]
end
$ gfortran-10-20200126 -c z1.f90
f951: internal compiler error: in gfc_resolve_character_array_constructor, at
fortran/array.c:2096
0x61b706 gfc_resolve_character_array_constructor(gfc_expr*)
../../gcc/fortran/array.c:2096
0x6bf014 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7049
0x6b803c gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6967
0x6b803c gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11688
0x6c6f2f gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10715
0x6b6d68 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11678
0x6b95e7 resolve_codes
../../gcc/fortran/resolve.c:17205
0x6b96ae gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17240
0x6a7a0c resolve_all_program_units
../../gcc/fortran/parse.c:6244
0x6a7a0c gfc_parse_file()
../../gcc/fortran/parse.c:6491
0x6f265f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210
[Bug target/93453] PPC: rldimi not taken into account to avoid shift+or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-28 Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- The first case is because the splitter does emit_insn (gen_ashldi3 (op3, op3, GEN_INT (32))); emit_insn (gen_iordi3 (dest, dest, op3)); but this splitter runs late, so it has to do all wanted simple optimisations manually. The second is Trying 7 -> 8: 7: r124:DI=r125:DI<<0x20 REG_DEAD r125:DI 8: r123:DI=r124:DI|r126:DI REG_DEAD r126:DI REG_DEAD r124:DI Failed to match this instruction: (set (reg:DI 123) (ior:DI (ashift:DI (reg:DI 125) (const_int 32 [0x20])) (reg:DI 126))) We need a separate pattern to also recognise this (instead of just a version with the AND) if we already know the high half bits (of r126 here) are zero. Confirmed.
[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #6 from Tobias Burnus --- (In reply to Richard Biener from comment #4) > Fixing this will be an ABI change and may cause old and new objects no > longer to link? By itself, the pattern for constructing the identifier is unchanged – except that there is now more space for longer names. — Before the change, it only accepted identifiers of the following length: __amodulewithanallowedname.asubmodulewithaveryveryverylongbutentirelylegalname_MOD_asubroutinewithaverylongnamethatwillcauseaprobl If you save letters in the module name (amodulewithanallowedname) and/or submodule name (asubmodulewithaveryveryverylongbutentirelylegalname) you have more letters for the procedure name – which is already not that short even after trimming: "asubroutinewithaverylongnamethatwillcauseaprobl". Thus, the problem only occurs if all parts use very long names – and only if one uses submodules which are also a relatively new feature (of GCC 6). Hence, technically, it is an ABI change – but I don't think that any real-world program will have hit this limit!
[Bug libgomp/93481] New: Do not fail with nowait clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93481 Bug ID: 93481 Summary: Do not fail with nowait clause Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: josem at udel dot edu CC: jakub at gcc dot gnu.org Target Milestone: --- Hi from the SOLLVE team We have notice that the nowait clause used with target generates the following error message: libgomp: GOMP_OFFLOAD_async_run unimplemented I believe you should not fail execution, instead nowait can be safely ignored and still be compliant with the specifications. A warning could be fine as well. In fact there are many other compilers that still do not implement async offloading, but just ignore the nowait clause. Thank you very much. Jose Monsalve
[Bug middle-end/93437] [9/10 Regression] on protobuf generated code, -Warray-bounds is brittle and not very helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93437 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-28 Component|c++ |middle-end Known to work||10.0 Summary|On protobuf generated code, |[9/10 Regression] on |-Warray-bounds is brittle |protobuf generated code, |and not very helpful|-Warray-bounds is brittle ||and not very helpful Ever confirmed|0 |1 Known to fail||9.2.0 --- Comment #3 from Martin Sebor --- Confirmed for GCC 9. It does look like it disappeared in GCC 10.0 after g:6889a3acfeed47265886676c6d43b04ef799fb82 AKA r275981. Thanks for the heads up! Let me add the test case and resolve the 10 regression as fixed (r275981 was checked in to fix a false negative, not specifically suppress a false positive, but it fixed a bug that apparently worked ways). Since the fix adds new warnings I don't think the policy allows it to be backported to GCC 9.
[Bug c++/90546] [9/10 Regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 --- Comment #6 from Jason Merrill --- This changed from the fix for PR 86521. As you say, deduction is first done with P = T&&, A = const Foo&, and deduces 'const Foo' for T. This produces operator const Foo&&. But according to [over.match.ref], we don't consider a conversion function yielding an rvalue reference (const Foo&&) for direct reference binding to an lvalue reference (const Foo&), so we fall back on creating a temporary Foo and binding the reference to that. On the other hand, the rules in [dcl.init.ref] are more forgiving; this case seems to hit the bullet Otherwise, if the initializer expression...has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be converted to an rvalue or function lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (see 12.4.1.6), then the value of the initializer expression in the first case and the result of the conversion in the second case is called the converted initializer In any case, the reference is bound to the resulting glvalue (or to an appropriate base class subobject). So if we ignored the [over.match.ref] rule we would happily bind directly to the xvalue from operator const Foo&&. The standard is definitely unclear here, but no other implementation agrees with us on this testcase. I suppose for now I'll limit the [over.match.ref] limitation to only apply to non-template conversions.
[Bug target/90000] Compile-time hog w/ impossible asm constraints on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #1 from Segher Boessenkool --- *** Bug 90968 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/90968] [10 Regression] ICE in eliminate_regs_in_insn, at lra-eliminations.c:1027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90968 Segher Boessenkool changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Segher Boessenkool --- Duplicate of PR9 is a better resolution. *** This bug has been marked as a duplicate of bug 9 ***
[Bug c++/90915] [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90915 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Mine.
[Bug rtl-optimization/90968] [10 Regression] ICE in eliminate_regs_in_insn, at lra-eliminations.c:1027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90968 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Segher Boessenkool --- This is normal. You get that for any other -mcpu if you say -msoft-float, for example. Maybe the message for this case should not say "internal compiler error". I thought we didn't, for inline asm, did anything change there?
[Bug c/92326] wrong bound in zero-length array diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92326 --- Comment #4 from Martin Sebor --- No progress yet. This bug is only cosmetic, in the format of the flexible array member in the warning, so it shouldn't cause any failures (as in false positives or negatives). Can you clarify how the builds of grub2 and qemu are affected by it?
[Bug middle-end/86912] Function pointer imposes an optimization barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86912 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80603, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93411 --- Comment #4 from Martin Sebor --- See also pr80603 and its duplicate pr93411 that I raised for the missing optimization in comment #3.
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 Segher Boessenkool changed: What|Removed |Added Target|powerpc-*-*-* |powerpc*-*-* --- Comment #1 from Segher Boessenkool --- Could you show what you want the source code to look like, and what the resulting machine code should be? And/or what you can get today?
$$_Magento Mobile App Development
Hi, I am Komal Singh, India's No. 1 Magento Certified Developer and Solution Specialist. I lead a team of 30+ Certified Magento Developers who have immense expertise in basic to advanced level Magento 1 as well as Magento 2 related tasks. Be it store designing from scratch or advanced features integration in existing Magento stores such as Automated Integration of Magento Store with Google shopping, Ajax based Pagination, Review, Q and A module and much more. As of today, our team has successfully delivered 650+ Magento Store Design, Development, and Advanced features integration related projects. As a team, we are appreciated all across the globe for generating sales through Magento stores as we have also employ advanced SEO skills while designing the Magento Store. We are not only a Magento store designer & developer but are also engaged in rendering an elite range of services including the web and graphic designing, mobile application development, WordPress, SEO (search engine optimization) and much more. Services We Offer: . Magento Mobile App Development. . PSD to Magento Conversion. . Custom Magento Store Designing from Scratch. . Custom Magento Store Development. . Magento Integration and Maintenance. . Magento Extension/Plugins Development. . Magento Store/e-commerce Development. . Migration of Existing eCommerce Store to Magento. . Magento 1.X to Magento 2.X Migration. May I know if you are interested in any of our offered Magento related services. As per your response, I will reply from my official email ID for further communication and consultation on your needs. No matter how big or small are your requirements, we are always there to assist you. Looking forward to your positive response. Warm Regards, Komal Singh Senior Magento Developer
[Bug libgcc/90918] -Wreturn-local-addr in __splitstack_find in libgcc/generic-morestack.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90918
--- Comment #4 from Martin Sebor ---
A pointer to a local variable is indeterminate when returned from the function
and using it undefined. GCC substitutes null for such pointers to avoid
accidentally clobbering the stack (this was disabled in r273261 by adding
#pragma GCC optimize ("no-isolate-erroneous-paths-dereference" near line 26 in
the file; I raised this bug for the record). Rather than disabling the GCC
transformation (which also avoids the warning) I would recommend considering an
alternate solution.
[Bug c++/93480] New: Defaulted <=> doesn't expand array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480
Bug ID: 93480
Summary: Defaulted <=> doesn't expand array elements
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This example should be valid:
#include
struct C {
int x[4];
auto operator<=>(C const&) const = default;
};
bool check(C const& a, C const& b) {
return (a <=> b) == 0;
}
a <=> b should check each array element in turn. But gcc defines C's
operator<=> as deleted.
[Bug libstdc++/93479] New: compare_three_way allows comparing arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93479
Bug ID: 93479
Summary: compare_three_way allows comparing arrays
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This program:
#include
bool check(int(&x)[4], int(&y)[4]) {
return std::compare_three_way{}(x, y) == 0;
}
Successfully compiles, with check() doing an address comparison on x and y. But
compare_three_way is just the function object for <=> and x <=> y is ill-formed
(gcc correctly rejects that).
The check for __3way_builtin_ptr_cmp needs to reject arrays, since the
expression declval() <=> declval() does not resolve to a built-in
operator comparing pointers (it doesn't resolve to any operator).
[Bug target/93448] PPC: missing builtin for DFP quantize(dqua,dquai,dquaq,dquaiq)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448
--- Comment #3 from Segher Boessenkool ---
So you just use "d", like in
void g(_Decimal128 x) { asm("# %0" :: "d"(x)); }
[Bug target/93448] PPC: missing builtin for DFP quantize(dqua,dquai,dquaq,dquaiq)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-28 Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Even/odd pairs Just Works(tm), for TDmode (which _Decimal128 is).
[Bug fortran/93025] [OpenACC] ICE with copy(y(1)%cc(:)%i) type of strided access – permitted since commit of OpenACC 2.6 deep copy patch series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93025 --- Comment #4 from Tobias Burnus --- (In reply to Tobias Burnus from comment #0) > It is not clear to me whether it is valid or not. To answer myself and record the result: As mentioned by me in https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01814.html , it is invalid via the following in OpenACC 3.0 (OpenACC 2.6 is same): “Any array or subarray in a data clause, including Fortran array pointers, must be a contiguous block of memory, except for dynamic multidimensional C arrays.” (2.7.1 under Restrictions.) (In reply to jules from comment #3) > I believe this is fixed on trunk now. So do I. Thanks for the fix!
[Bug fortran/93473] ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 --- Comment #4 from Andrew Benson --- @Martin - yes, thanks for the reminder, I'll send the updated patch to the GCC mailing list.
[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 #5 from Andrew Benson --- Yes, I think this would be an ABI change. Is there anything else I need to include in a patch as a result of this?
[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91187
--- Comment #9 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Albert Astals Cid from comment #0)
> > #define Z_NULL 0
>
> N.B. this is actually a bug. Using Z_NULL where a null pointer is expected
> might cause bugs e.g. execl("foo", "foo", Z_NULL) can pass a 32-bit int
> where a 64-bit pointer is expected, leading to undefined behaviour.
Whether this is a bug in the definition of Z_NULL depends on how Z_NULL is
meant to be used. If it is not supported as a variadic function argument, the
fact that it does not work as a variadic function argument is not a bug.
zlib.h's definition contains a comment:
#define Z_NULL 0 /* for initializing zalloc, zfree, opaque */
This does not include calling variadic functions.
> So maybe the warning should be taken as an opportunity to fix the code (or
> report a bug to the library) to use something safer:
>
> #if __cplusplus
> #define Z_NULL nullptr
> #else
> #define Z_NULL 0L
> #endif
If Z_NULL is meant to be usable as a variadic function argument, this is wrong
too. There is no guarantee that 0L is the same size as a pointer (think W64).
There is not even a guarantee that NULL is the same size as a pointer.
[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
--- Comment #3 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:3d056cbfb3484f4037b34c908b26e1c6776c86b5
commit r10-6294-g3d056cbfb3484f4037b34c908b26e1c6776c86b5
Author: Nathan Sidwell
Date: Tue Jan 28 07:58:29 2020 -0800
preprocessor: Make __has_include a builtin macro [PR93452]
The clever hack of '#define __has_include __has_include' breaks -dD
and -fdirectives-only, because that emits definitions. This turns
__has_include into a proper builtin macro. Thus it's never emitted
via -dD, and because use outside of directive processing is undefined,
we can just expand it anywhere.
PR preprocessor/93452
* internal.h (struct spec_nodes): Drop n__has_include{,_next}.
* directives.c (lex_macro_node): Don't check __has_include redef.
* expr.c (eval_token): Drop __has_include eval.
(parse_has_include): Move to ...
* macro.c (builtin_has_include): ... here.
(_cpp_builtin_macro_text): Eval __has_include{,_next}.
* include/cpplib.h (enum cpp_builtin_type): Add BT_HAS_INCLUDE{,_NEXT}.
* init.c (builtin_array): Add them.
(cpp_init_builtins): Drop __has_include{,_next} init here ...
* pch.c (cpp_read_state): ... and here.
* traditional.c (enum ls): Drop has_include states ...
(_cpp_scan_out_logical_line): ... and here.
[Bug libstdc++/91243] is_invocable mishandles functions returning indestructible types by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91243 --- Comment #4 from Jonathan Wakely --- Oh that's not the problem here though. Hmm, maybe the specification of is_invocable is bad then :-)
