[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |10.2 Last reconfirmed||2020-06-05 --- Comment #2 from Iain Sandoe --- There was a long discussion amongst the implementors at WG21 meeting in Prague about what should be done for the closure object. The standard is really silent about coroutines and lambdas except by inference (and different implementors had made different inferences). The end result of the discussion is that we should treat it the same way as a class object (passing a reference to it to the traits, allocator lookup and promise parameter preview). current MSVC is the only implementation to have this complete, clang passes the reference to the traits but not to the allocator / promise. GCC (current code) passes the closure pointer to all three. I posted a patch here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546299.html to bring GCC up to date with the agreed interpretation. After that, diagnostics will (as ever) be a QoI issue - as far as coroutines go, the implementation makes use of the same lookup facilities as the rest of the C++ FE (so we should expect a consistent behaviour in terms of diagnostics). (libraries like cppcoro etc. make heavy use of coroutine lambdas, so they are certainly found to be viable).
[Bug fortran/93624] Memory leak with allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93624 Juan Javier Dominguez Moreno changed: What|Removed |Added CC||juan.dominguez@eveutilities ||.com --- Comment #1 from Juan Javier Dominguez Moreno --- Created attachment 48682 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48682&action=edit Memory leak when returning an allocatable derived type deallocate_test.f08
[Bug fortran/93624] Memory leak with allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93624 --- Comment #2 from Juan Javier Dominguez Moreno --- Hello, I ran into the same problem using: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.1.0 (GCC) The example is in the attached file "deallocate_test.f08". The address sanitizer output is: = ==17194==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x7f6c75f26459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x5591e02303fe in create_container_leak /home/juan/temp/deallocate_test.f08:57 #2 0x5591e0231136 in do_leak /home/juan/temp/deallocate_test.f08:42 #3 0x5591e0230277 in deallocate_test /home/juan/temp/deallocate_test.f08:34 #4 0x5591e0231667 in main /home/juan/temp/deallocate_test.f08:30 #5 0x7f6c75863001 in __libc_start_main (/usr/lib/libc.so.6+0x27001) Direct leak of 8 byte(s) in 1 object(s) allocated from: #0 0x7f6c75f26459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x5591e022faf0 in __deallocate_test_mod_MOD_make_object /home/juan/temp/deallocate_test.f08:21 #2 0x5591e02304da in create_container_leak /home/juan/temp/deallocate_test.f08:59 #3 0x5591e0231136 in do_leak /home/juan/temp/deallocate_test.f08:42 #4 0x5591e0230277 in deallocate_test /home/juan/temp/deallocate_test.f08:34 #5 0x5591e0231667 in main /home/juan/temp/deallocate_test.f08:30 #6 0x7f6c75863001 in __libc_start_main (/usr/lib/libc.so.6+0x27001) Direct leak of 8 byte(s) in 1 object(s) allocated from: #0 0x7f6c75f26459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x5591e022faf0 in __deallocate_test_mod_MOD_make_object /home/juan/temp/deallocate_test.f08:21 #2 0x5591e022fea9 in create_container_no_leak /home/juan/temp/deallocate_test.f08:66 #3 0x5591e0230b55 in do_no_leak /home/juan/temp/deallocate_test.f08:50 #4 0x5591e0230283 in deallocate_test /home/juan/temp/deallocate_test.f08:35 #5 0x5591e0231667 in main /home/juan/temp/deallocate_test.f08:30 #6 0x7f6c75863001 in __libc_start_main (/usr/lib/libc.so.6+0x27001) Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x7f6c75f26459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x5591e02305a9 in create_container_leak /home/juan/temp/deallocate_test.f08:59 #2 0x5591e0231136 in do_leak /home/juan/temp/deallocate_test.f08:42 #3 0x5591e0230277 in deallocate_test /home/juan/temp/deallocate_test.f08:34 #4 0x5591e0231667 in main /home/juan/temp/deallocate_test.f08:30 #5 0x7f6c75863001 in __libc_start_main (/usr/lib/libc.so.6+0x27001) SUMMARY: AddressSanitizer: 40 byte(s) leaked in 4 allocation(s).
[Bug tree-optimization/95539] Vectorizer ICE in dr_misalignment, at tree-vectorizer.h:1433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95539 Richard Biener changed: What|Removed |Added Keywords|needs-bisection |needs-reduction --- Comment #2 from Richard Biener --- I have a patch. Indeed caused by SLP_NODE_REPRESENTATIVE changes.
[Bug tree-optimization/95539] Vectorizer ICE in dr_misalignment, at tree-vectorizer.h:1433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95539 Richard Biener changed: What|Removed |Added Keywords|needs-reduction | --- Comment #3 from Richard Biener --- I have it reduced.
[Bug tree-optimization/95539] Vectorizer ICE in dr_misalignment, at tree-vectorizer.h:1433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95539
--- Comment #4 from Richard Biener ---
ypedef unsigned short uint16_t;
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__))
_mm_set_epi16 (short __q7, short __q6, short __q5, short __q4,
short __q3, short __q2, short __q1, short __q0)
{
return __extension__ (__m128i)(__v8hi){
__q0, __q1, __q2, __q3, __q4, __q5, __q6, __q7 };
}
void gcm_HashMult_hw(__m128i *x, const unsigned char *buf, unsigned int count)
{
unsigned i;
__m128i bin __attribute__((aligned(16)));
for (i = 0; i < count; i++, buf += 16)
{
bin = _mm_set_epi16(((uint16_t)buf[0] << 8) | buf[1],
((uint16_t)buf[2] << 8) | buf[3],
((uint16_t)buf[4] << 8) | buf[5],
((uint16_t)buf[6] << 8) | buf[7],
((uint16_t)buf[8] << 8) | buf[9],
((uint16_t)buf[10] << 8) | buf[11],
((uint16_t)buf[12] << 8) | buf[13],
((uint16_t)buf[14] << 8) | buf[15]);
*(x++) = bin;
}
}
[Bug c++/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548
--- Comment #1 from David Binderman ---
Reduced C++ code is
enum a { b = (unsigned long)-1 } c;
[Bug libgomp/92854] [OpenACC] Always-true conditional in 'libgomp/oacc-mem.c:acc_unmap_data'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92854 Thomas Schwinge changed: What|Removed |Added Resolution|--- |FIXED Assignee|jules at gcc dot gnu.org |tschwinge at gcc dot gnu.org Status|ASSIGNED|RESOLVED --- Comment #13 from Thomas Schwinge --- The dead code has been removed (master and releases/gcc-10 branches), and the (unrelated) 'libgomp.oacc-c-c++-common/acc_map_data-device_already-3.c' problem is tracked in PR92888.
[Bug libstdc++/95547] gdb pretty-printing of std::unique_ptr less helpful than it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95547
--- Comment #1 from Jonathan Wakely ---
(In reply to M Welinder from comment #0)
> This is with a fairly old compiler, but same behaviour observed with gcc10.
Old and unsupported, bugs should really be reported for current versions.
As you say, YMMV, other people want more information. And what gets printed in
the backtrace is decided by GDB anyway, not GCC. The pretty printers can't
control eliding the contents of the {...}. When printing the variables
explicitly you get the values you want:
(gdb) p p
$1 = std::optional = {[contained value] = 14}
(gdb) up
(gdb) p p
$2 = std::shared_ptr (use count 1, weak count 0) = {get() = 0x418ee0}
(gdb) up
(gdb) p p
$3 = std::unique_ptr = {get() = 0x418eb0}
Changing those to just print a pointer value would not be an improvement. The
point of the pretty printers is to provide extra information, not be as brief
as the raw format for scalar values.
If you want less verbose output from the printers I suggest you modify
libstdc++-v3/python/libstdcxx/v6/printers.py to add a boolean flag that
switches between different output modes (verbose/concise) so that you can set
that within GDB (maybe in a gdbinit file). You would need to format the
contents as a string, not use the 'children' method to return a child value in
curly braces. Users who don't want the extra info can then disable it.
Or extend GDB itself to support two forms of output, the full one and an
abbreviated one for use in backtraces. Then change the libstdc++ printers to
add an extra method to each printer that returns the abbreviated form.
[Bug libstdc++/95547] gdb pretty-printing of std::unique_ptr less helpful than it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95547 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement
[Bug ada/95549] [9/10/11 regression] gnat1 doesn't link on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95549 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug ada/95549] New: [9/10/11 regression] gnat1 doesn't link on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95549 Bug ID: 95549 Summary: [9/10/11 regression] gnat1 doesn't link on AIX Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: powerpc-ibm-aix7.2.0.0, powerpc-ibm-aix7.1.3.0 I've been trying to get a working GNAT on AIX 7. Starting with old GNAT binaries from GCC .1.0 for AIX 5.2, I went via GCC 4.7.4 and GCC 8.4.0, where the builds succeeded with minor issues. However, in all of GCC 9.3.0, 10.1.0, and current master, gnat1 fails to link in stage 1: $ g++ -std=gnu++98 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o gnat1 ada/adadecode.o ada/adaint.o ada/argv.o ada/cio.o ada/cstreams.o ada/env.o ada/init.o ada/initialize.o ada/raise.o ada/raise-gcc.o ada/seh_init.o ada/targext.o ada/cuintp.o ada/decl.o ada/rtfinal.o ada/rtinit.o ada/misc.o ada/utils.o ada/utils2.o ada/trans.o ada/targtyps.o ada/libgnat/a-charac.o ada/libgnat/a-chlat1.o ada/libgnat/a-elchha.o ada/libgnat/a-except.o ada/libgnat/a-exctra.o ada/libgnat/a-ioexce.o ada/libgnat/ada.o ada/spark_xrefs.o ada/ali.o ada/alloc.o ada/aspects.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o ada/contracts.o ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o ada/elists.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/eval_fat.o ada/exp_aggr.o ada/exp_spark.o ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o ada/exp_ch11.o ada/exp_ch12.o ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o ada/exp_ch5.o ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o ada/exp_code.o ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o ada/exp_imgv.o ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o ada/exp_smem.o ada/exp_strm.o ada/exp_tss.o ada/exp_unst.o ada/exp_util.o ada/expander.o ada/fmap.o ada/fname-uf.o ada/fname.o ada/freeze.o ada/frontend.o ada/libgnat/g-byorma.o ada/libgnat/g-dynhta.o ada/libgnat/g-hesora.o ada/libgnat/g-htable.o ada/libgnat/g-lists.o ada/libgnat/g-sets.o ada/libgnat/g-spchge.o ada/libgnat/g-speche.o ada/libgnat/g-u3spch.o ada/get_targ.o ada/ghost.o ada/libgnat/gnat.o ada/gnatvsn.o ada/hostparm.o ada/impunit.o ada/inline.o ada/libgnat/interfac.o ada/itypes.o ada/krunch.o ada/layout.o ada/lib-load.o ada/lib-util.o ada/lib-writ.o ada/lib-xref.o ada/lib.o ada/live.o ada/namet-sp.o ada/namet.o ada/nlists.o ada/nmake.o ada/opt.o ada/osint-c.o ada/osint.o ada/output.o ada/par.o ada/par_sco.o ada/prep.o ada/prepcomp.o ada/put_scos.o ada/repinfo.o ada/restrict.o ada/rident.o ada/rtsfind.o ada/libgnat/s-addope.o ada/libgnat/s-addima.o ada/libgnat/s-assert.o ada/libgnat/s-bitops.o ada/libgnat/s-carun8.o ada/libgnat/s-casuti.o ada/libgnat/s-conca2.o ada/libgnat/s-conca3.o ada/libgnat/s-conca4.o ada/libgnat/s-conca5.o ada/libgnat/s-conca6.o ada/libgnat/s-conca7.o ada/libgnat/s-conca8.o ada/libgnat/s-conca9.o ada/libgnat/s-crc32.o ada/libgnat/s-crtl.o ada/libgnat/s-excdeb.o ada/libgnat/s-except.o ada/libgnat/s-exctab.o ada/libgnat/s-excmac.o ada/libgnat/s-htable.o ada/libgnat/s-imenne.o ada/libgnat/s-imgenu.o ada/libgnat/s-imgint.o ada/libgnat/s-mastop.o ada/libgnat/s-memory.o ada/libgnat/s-os_lib.o ada/libgnat/s-parame.o ada/libgnat/s-purexc.o ada/libgnat/s-restri.o ada/libgnat/s-secsta.o ada/libgnat/s-soflin.o ada/libgnat/s-soliin.o ada/libgnat/s-sopco3.o ada/libgnat/s-sopco4.o ada/libgnat/s-sopco5.o ada/libgnat/s-stache.o ada/libgnat/s-stalib.o ada/libgnat/s-stoele.o ada/libgnat/s-strcom.o ada/libgnat/s-strhas.o ada/libgnat/s-string.o ada/libgnat/s-strops.o ada/libgnat/s-traceb.o ada/libgnat/s-traent.o ada/libgnat/s-trasym.o ada/libgnat/s-unstyp.o ada/libgnat/s-utf_32.o ada/libgnat/s-valint.o ada/libgnat/s-valuns.o ada/libgnat/s-valuti.o ada/libgnat/s-wchcnv.o ada/libgnat/s-wchcon.o ada/libgnat/s-wchjis.o ada/libgnat/s-wchstw.o ada/scans.o ada/scil_ll.o ada/scn.o ada/scng.o ada/scos.o ada/sdefault.o ada/sem.o ada/sem_aggr.o ada/sem_attr.o ada/sem_aux.o ada/sem_case.o ada/sem_cat.o ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o ada/sem_ch13.o ada/sem_ch2.o ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o ada/sem_ch6.o ada/sem_ch7.o ada/sem_ch8.o ada/sem_ch9.o ada/sem_dim.o ada/sem_disp.o ada/sem_dist.o ada/sem_elab.o ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o ada/sem_mech.o ada/sem_prag.o ada/sem_res.o ada/sem_scil.o ada/sem_smem.o ada/sem_spark.o ada/sem_type.o ada/sem_util.o ada/sem_warn.o ada/set_targ.o ada/sinfo-cn.o ada/sinfo.o ada/sinput-d.o ada/sinput-l.o ada/sinput.o ada/snames.o ada/sprint.o ada/s
[Bug target/95535] Failure to optimize out cdqe after __bultin_ctz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95535 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:892b51cb73f24157391cd18c2215e8d703af97e7 commit r11-965-g892b51cb73f24157391cd18c2215e8d703af97e7 Author: Jakub Jelinek Date: Fri Jun 5 10:44:23 2020 +0200 ix86: Improve __builtin_c[lt]z followed by extension [PR95535] In January I've added patterns to optimize SImode -> DImode sign or zero extension of __builtin_popcount, this patch does the same for __builtin_c[lt]z. Like most other instructions, the [tl]zcntl instructions clear the upper 32 bits of the destination register and as the instructions only result in values 0 to 32 inclusive, both sign and zero extensions behave the same. 2020-06-05 Jakub Jelinek PR target/95535 * config/i386/i386.md (*ctzsi2_zext, *clzsi2_lzcnt_zext): New define_insn_and_split patterns. (*ctzsi2_zext_falsedep, *clzsi2_lzcnt_zext_falsedep): New define_insn patterns. * gcc.target/i386/pr95535-1.c: New test. * gcc.target/i386/pr95535-2.c: New test.
[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) > I'd say the vectorizer/simplify_vector_constructor just shouldn't attempt to > use these (e.g. vec_pack*, vec_unpack* optabs) for !VEC_MODE_P unless it is > VECTOR_BOOLEAN_TYPE_P type. > For i386 it would be the right thing as the patterns really assume that it > is vector booleans and have their properties. > Though, aarch64 seems to have vec_pack_trunc_di and vec_pack_trunc_df > expanders, it is unclear to me what they are for and if they are really used. > Other targets seem to only define these for vector modes. Yeah, I agree those look odd. The covering note for the patch that added them was: https://gcc.gnu.org/pipermail/gcc-patches/2013-April/361636.html which talks about fixing gcc.dg/vect failures. But as James says, only the 128-bit patterns should be needed for that. Maybe the the 64-bit patterns were just added for completeness. Perhaps one justification for _di is that there is no V1DI mode. Instead a vector of 1 DImode would itself have mode DImode. So in principle, vec_pack_trunc_di is probably the right name for a (V1)DI->V2SI truncate. The same doesn't apply to _df since we don't use scalar float modes for V1 vectors. And (unlike at the time of the patch) we now have V1DF. So I agree that the _df one looks dead. That said, for AArch64 we'd now try to mix 128-bit and 64-bit vectors instead of vectorising with 2 64-bit vectors. So the _di pattern probably isn't useful in practice either. In summary: from an AArch64 perspective, it's probably fine to check !VECTOR_MODE_P || VECTOR_BOOLEAN_TYPE_P. But given the V1 thing, maybe it would be better to add || m == GET_MODE_INNER (m) as well (unless that defeats the fix).
[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 --- Comment #7 from rsandifo at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #6) > In summary: from an AArch64 perspective, it's probably fine to > check !VECTOR_MODE_P || VECTOR_BOOLEAN_TYPE_P. But given the V1 > thing, maybe it would be better to add || m == GET_MODE_INNER (m) > as well (unless that defeats the fix). Er, I mean: m == TYPE_MODE (TREE_TYPE (vectype)) or whatever. m == GET_MODE_INNER (m) is of course always true for scalars :-)
[Bug target/95254] aarch64: gcc generate inefficient code with fixed sve vector length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95254 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:9a182ef9ee011935d827ab5c6c9a7cd8e22257d8 commit r11-966-g9a182ef9ee011935d827ab5c6c9a7cd8e22257d8 Author: Fei Yang Date: Fri Jun 5 10:34:59 2020 +0100 expand: Simplify removing subregs when expanding a copy [PR95254] In rtl expand, if we have a copy that matches one of the following patterns: (set (subreg:M1 (reg:M2 ...)) (subreg:M1 (reg:M2 ...))) (set (subreg:M1 (reg:M2 ...)) (mem:M1 ADDR)) (set (mem:M1 ADDR) (subreg:M1 (reg:M2 ...))) (set (subreg:M1 (reg:M2 ...)) (constant C)) where mode M1 is equal in size to M2, try to detect whether the mode change involves an implicit round trip through memory. If so, see if we can avoid that by removing the subregs and doing the move in mode M2 instead. 2020-06-05 Felix Yang gcc/ PR target/95254 * expr.c (emit_move_insn): Check src and dest of the copy to see if one or both of them are subregs, try to remove the subregs when innermode and outermode are equal in size and the mode change involves an implicit round trip through memory. gcc/testsuite/ PR target/95254 * gcc.target/aarch64/pr95254.c: New test. * gcc.target/i386/pr67609.c: Check "movq\t%xmm0" instead of "movdqa".
[Bug target/95254] aarch64: gcc generate inefficient code with fixed sve vector length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95254 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/95539] Vectorizer ICE in dr_misalignment, at tree-vectorizer.h:1433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95539 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9758d196f57950ea89baa5cdf6ebd7125b5056e0 commit r11-967-g9758d196f57950ea89baa5cdf6ebd7125b5056e0 Author: Richard Biener Date: Fri Jun 5 10:13:27 2020 +0200 tree-optimization/95539 - fix SLP_TREE_REPRESENTATIVE vs. dr_info This fixes a disconnect between the stmt_info used for dr_info analysis and the one in SLP_TREE_REPRESENTATIVE with a temporary workaround. 2020-06-05 Richard Biener PR tree-optimization/95539 * tree-vect-data-refs.c (vect_slp_analyze_and_verify_instance_alignment): Use SLP_TREE_REPRESENTATIVE for the data-ref check. * tree-vect-stmts.c (vectorizable_load): Reset stmt_info back to the first scalar stmt rather than the SLP_TREE_REPRESENTATIVE to match previous behavior. * gcc.dg/vect/pr95539.c: New testcase.
[Bug tree-optimization/95539] Vectorizer ICE in dr_misalignment, at tree-vectorizer.h:1433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95539 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug ada/95549] [9/10/11 regression] gnat1 doesn't link on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95549 Richard Biener changed: What|Removed |Added Keywords||build Target Milestone|11.0|9.4
[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Version|unknown |11.0 Component|c++ |lto --- Comment #2 from Richard Biener --- I think Honza ran into this himself.
[Bug middle-end/95550] New: [OpenACC] ICE in expand_oacc_for, at omp-expand.c:6075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95550 Bug ID: 95550 Summary: [OpenACC] ICE in expand_oacc_for, at omp-expand.c:6075 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The following program gives an ICE with -fopenacc: 12 | !$acc loop private(A) | internal compiler error: in expand_oacc_for, at omp-expand.c:6075 0x6b9638 expand_oacc_for ../../repos/gcc-cs-og10-pre/gcc/omp-expand.c:6075 0xd6eadf expand_omp_for ../../repos/gcc-cs-og10-pre/gcc/omp-expand.c:6583 0xd6f5ea expand_omp ../../repos/gcc-cs-og10-pre/gcc/omp-expand.c:8912 program main implicit none (type, external) integer :: j, i integer, allocatable :: A(:) A = [(3*j, j=1, 10)] !$acc parallel create(A) A(:) = [(-2*i, i = 1, size(A))] !$acc loop private(A) do i = 1, 10 A(i) = 9*i end do !if (any (A /= [(-2*i, i = 1, 10)])) error stop 2 !$acc end parallel end
[Bug middle-end/95551] New: [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551 Bug ID: 95551 Summary: [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2' Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc, openmp, wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Loosely related to PR 95550 (for a variant of this test case, which fails with an ICE). The following test case fails to compile with -fopenmp or -fopenacc with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2' at least when offloading to AMDGCN (for nvidia, one runs into PR 65181) and also with "-foffload=disable -O3". Note: In order to reproduce this issue, an offloading compiler has to be configured (configure-time set ENABLE_OFFLOADING has to evaluate to true) as otherwise no .gnu.offload_vars is generated. program main implicit none (type, external) integer :: j integer, allocatable :: A(:) A = [(3*j, j=1, 10)] call bar (A) deallocate (A) contains subroutine bar (array) integer :: i integer :: array(:) !$omp target map(from:array) !$acc parallel copyout(array) array = [(-2*i, i = 1, size(array))] !$omp do private(array) !$acc loop gang private(array) do i = 1, 10 array(i) = 9*i end do if (any (array /= [(-2*i, i = 1, 10)])) error stop 2 !$omp end target !$acc end parallel end subroutine bar end
[Bug middle-end/95551] [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551 Tobias Burnus changed: What|Removed |Added Depends on||94848 --- Comment #1 from Tobias Burnus --- See also PR 94848 – the error is slightly different but similar enough that it might have the same cause. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848 [Bug 94848] [Offloading][LTO] error due to only partially eliminated var / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures
[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 --- Comment #3 from Jan Hubicka --- > I think Honza ran into this himself. Yep, i converted code to use wide-ints. But it is nice to have short testcase. Honza
Re: [Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
> I think Honza ran into this himself. Yep, i converted code to use wide-ints. But it is nice to have short testcase. Honza
[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 --- Comment #4 from Jakub Jelinek --- On Fri, Jun 05, 2020 at 12:46:15PM +0200, Jan Hubicka wrote: > > I think Honza ran into this himself. > Yep, i converted code to use wide-ints. But it is nice to have short > testcase. For the testsuite perhaps also add another one with __int128_t and/or __uint128_t enumerators (guarded with #ifdef __SIZEOF_INT128__). Jakub
Re: [Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
On Fri, Jun 05, 2020 at 12:46:15PM +0200, Jan Hubicka wrote: > > I think Honza ran into this himself. > Yep, i converted code to use wide-ints. But it is nice to have short > testcase. For the testsuite perhaps also add another one with __int128_t and/or __uint128_t enumerators (guarded with #ifdef __SIZEOF_INT128__). Jakub
[Bug middle-end/4210] should not warn in dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 --- Comment #43 from Marc Glisse --- (In reply to Niels Möller from comment #42) > And what's the easiest way to run the the right compiler process (I guess > that's cc1) under gdb? gcc -c t.c -wrapper gdb,--args
[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 48683 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48683&action=edit gcc11-pr95528.patch Untested fix.
[Bug libstdc++/91486] future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486 --- Comment #8 from Mike Crowe --- I think that https://gcc.gnu.org/pipermail/libstdc++/2020-May/050437.html fixes this for std::future::wait_for including the __chrono_detail part mentioned in comment 5.
[Bug libstdc++/93542] std::future::wait_for should use monotonic clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93542 --- Comment #2 from Mike Crowe --- An updated version of the fix is available in https://gcc.gnu.org/pipermail/libstdc++/2020-May/050433.html which relies on https://gcc.gnu.org/pipermail/libstdc++/2020-May/050439.html .
[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 --- Comment #9 from rsandifo at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #8) > Created attachment 48683 [details] > gcc11-pr95528.patch > > Untested fix. The VECTOR_TYPE_P condition should be redundant. Looks good to me otherwise FWIW.
[Bug fortran/95509] [11 regression] gfortran.dg/spellcheck-operator.f90 fails after r11-875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509 --- Comment #3 from Tom Tromey --- https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547388.html
[Bug middle-end/95552] New: VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 Bug ID: 95552 Summary: VLA ICE Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- Target: powerpc-ibm-aix* g++.dg/ext/vla3.C and g++.dg/cpp1y/vla8.C both now elicit during RTL pass: expand /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/cpp1y/vla8.C:24:12: internal compiler error: in expand_expr_real_1, at expr.c:10160 ranges offset out of range
[Bug middle-end/95552] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-06-05 Ever confirmed|0 |1 --- Comment #2 from David Edelsohn --- Confirmed.
[Bug middle-end/95552] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 David Edelsohn changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from David Edelsohn --- Confirmed.
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Summary|VLA ICE |[11 Regression] VLA ICE
[Bug target/95055] [11 Regression] gcc.dg/compat/scalar-by-value-3 fails on aarch64 after r11-165-geb72dc663e9070b281be83a80f6f838a3a878822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95055 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||acoplan at gcc dot gnu.org --- Comment #1 from Alex Coplan --- Hi Christophe, see PR95526: this should be fixed by ab56390384cd5168b548ff07e6f0c9c4d41420fb.
[Bug target/95526] [11 Regression] aarch64: Wrong code accessing complex number from varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95526 Alex Coplan changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #8 from Alex Coplan --- *** Bug 95055 has been marked as a duplicate of this bug. ***
[Bug target/95055] [11 Regression] gcc.dg/compat/scalar-by-value-3 fails on aarch64 after r11-165-geb72dc663e9070b281be83a80f6f838a3a878822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95055 Alex Coplan changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #2 from Alex Coplan --- *** This bug has been marked as a duplicate of bug 95526 ***
[Bug c++/95328] structured binding of template type inside template function is reported as "incomplete class type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95328 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-06-05 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/95551] [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
--- Comment #2 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #0)
> if (any (array /= [(-2*i, i = 1, 10)])) error stop 2
The A.10.2 is the array {-2,-4,...,-20} in static memory, which has been
removed with -O3 but there is still:
.offload_var_table:
.quad A.10.2
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 --- Comment #35 from Andrew Downing --- I agree that the new implicit object creation rules sound very difficult to implement correctly especially because the behavior in C is different. I'm curious to see how that will all play out. In this situation though, if we use the C rules for what memcpy does C17 6.5/6 https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf#section.6.5, the effective type shouldn't be changed. The declared type of both objects is known to the compiler. In the first memcpy the declared type of the object is unsigned char[8], in the second memcpy the declared type of the object is double. Placement new changes the effective type to std::uint64_t, but that doesn't change the behavior of memcpy. Footnote 88 says "Allocated objects have no declared type.". I believe calling a function defined in another TU that returns a pointer also has to be considered to return a pointer to an object with no declared type, because the object's declaration isn't visible. In this situation though, the declared types are visible, and so a modifying access, or memcpy, or memmove shouldn't change the effective type. If gcc is changing the effective type with every memcpy no matter what, that would be the wrong thing to do right? Especially since you're saying that it's the reason that this example isn't being compiled correctly.
[Bug middle-end/95551] [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Before IPA, we should be able to optimize away variables even if they are marked declare target to, as long as we optimize them away completely (i.e. neither the offloaded code nor host code will refer to them in any way), which suggests that perhaps we should be populating the variable and function tables for offloading later than we do now (basically immediately before IPA), but also once we enter something into the tables, we should mark those as being used such that e.g. IPA passes or anything later will not really optimize them away.
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 Victor Khimenko changed: What|Removed |Added CC||khim at google dot com --- Comment #2 from Victor Khimenko --- Note that gcc looks bad even on the example from Microsoft's blog post: https://godbolt.org/z/Jc7TcN The fact that MSVC also looks bad on example from Microsoft is not really relevant, it's MSVC, after all. Blogpost itself is here: https://devblogs.microsoft.com/cppblog/simplify-your-code-with-rocket-science-c20s-spaceship-operator/
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #19 from David Malcolm --- (In reply to bouanto from comment #18) > (In reply to David Malcolm from comment #16) > > Created attachment 48677 [details] > This API looks good. Thanks. [...snip...] > > "Basic" asm > > > > Do we actually need "basic" asm (as opposed to extended asm)? > > In particular I'm wary about asm code that's outside of any given function. > > Is that needed? > > That's something I use in my compiler, so that would be very appreciated if > you could add this. Can you give concrete example(s) please? I'm having trouble thinking through how this would work. [...snip...]
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #20 from bouanto at zoho dot com --- Well, there's syntax for assembly at the top-level so the user can enter anything he wants, like in C. I can craft you an example if you need to, though. (In reply to David Malcolm from comment #19) > (In reply to bouanto from comment #18) > > (In reply to David Malcolm from comment #16) > > > Created attachment 48677 [details] > > This API looks good. > > Thanks. > > [...snip...] > > > > "Basic" asm > > > > > > Do we actually need "basic" asm (as opposed to extended asm)? > > > In particular I'm wary about asm code that's outside of any given > > > function. > > > Is that needed? > > > > That's something I use in my compiler, so that would be very appreciated if > > you could add this. > > Can you give concrete example(s) please? I'm having trouble thinking > through how this would work. > > [...snip...]
[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540
--- Comment #3 from Michael Bruck ---
I think you misread, I was complaining about it passing the closure to the
traits/constructor/allocator. But if that is what was agreed upon...
Can the closure object that is being passed to the constructor and allocator be
used for anything? I am asking because I got it to pass nullptr with the code
below. But if there is no legitimate use it might as well always pass a
nullptr.
template
struct foo_t
{
static auto test()
{
return F();
}
};
using moo = foo_t<[]() -> pt::handle_t{ co_return; }>;
...
int main { moo::test(); }
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 --- Comment #3 from David Edelsohn --- Started between r11-878 and r11-896
[Bug testsuite/95546] Random Fortran test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #4 from jvdelisle at charter dot net --- I am curious, did this just start happening or is it a long time issue just reported. Locking mecahnisms were adjusted recently I believe.
[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540 --- Comment #4 from Iain Sandoe --- (In reply to Michael Bruck from comment #3) > I think you misread, I was complaining about it passing the closure to the > traits/constructor/allocator. But if that is what was agreed upon... > > Can the closure object that is being passed to the constructor and allocator > be used for anything? I am asking because I got it to pass nullptr with the > code below. But if there is no legitimate use it might as well always pass a > nullptr. OK.. I think I did misread (I was under the impression you wanted better diagnostics for the case where the user had intentionally specialised the traits - but made an error). [FTR, I am not sure if that's feasible - but someone with more specialisation-fu can comment on that]. --- I think we need the closure object type in the traits lookup because: Since the coroutine traits are global, and the closure type is unique, that provides a way to disambiguate instantiations of the traits for lambdas with otherwise identical signatures. The callable is usable in the other positions - I don't think that was particularly in debate. The issue was about whether we should pass a reference to the closure or the pointer (and it was decided that symmetry with the class object that a reference was the intention). The fix is not yet in master (to make it a reference) - it's pending review (but you could apply it to test things out).
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 David Edelsohn changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from David Edelsohn --- Jason, this seems to be a regression introduced by your patch for C++ VLA PR 95232.
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 Jason Merrill changed: What|Removed |Added Version|10.0|11.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-06-05
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Priority|P3 |P4
--- Comment #1 from kargl at gcc dot gnu.org ---
This allows the code to compile and print 1.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 280157)
+++ gcc/fortran/expr.c (working copy)
@@ -1684,7 +1684,13 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
}
cons = gfc_constructor_lookup (base, limit);
- gcc_assert (cons);
+
+ if (!cons)
+ {
+ t = false;
+ goto cleanup;
+ }
+
gfc_constructor_append_expr (&expr->value.constructor,
gfc_copy_expr (cons->expr), NULL);
}
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #21 from David Malcolm --- (In reply to bouanto from comment #20) > Well, there's syntax for assembly at the top-level so the user can enter > anything he wants, like in C. > I can craft you an example if you need to, though. I could use a concrete example of what you might use in C. An issue is ordering: in C, these top-level statements presumably are ordered relative to each other and the function bodies, based on the order they're seen by the parser (though I'm guessing here). Would something similar happen based on the order of calls to gcc_jit_context_new_function?
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 David Malcolm changed: What|Removed |Added Attachment #48677|0 |1 is obsolete|| --- Comment #22 from David Malcolm --- Created attachment 48684 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48684&action=edit Updated work-in-progress patch which adds "asm goto" support Here's an updated version of the patch which adds "asm goto" support. grep for test_i386_basic_asm_3a to see an example. Also uploaded to: https://dmalcolm.fedorapeople.org/gcc/2020-06-05/0001-FIXME-WIP-on-extended-asm-support-v2.patch Does this API make sense?
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #11 from anlauf at gcc dot gnu.org --- Patch submitted for review: https://gcc.gnu.org/pipermail/fortran/2020-June/054473.html
[Bug c++/95553] New: Incorrect/misspelled designators not triggering compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95553
Bug ID: 95553
Summary: Incorrect/misspelled designators not triggering
compilation error
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alex at weej dot com
Target Milestone: ---
The following code, I believe, should not compile in C++20 or otherwise (we use
it in gnu++17 mode).
#include
auto take_a_string(std::string const& wat) -> void;
auto test() {
take_a_string({.anything_goes_here = "banana"});
}
Tested this on GCC 7 and GCC trunk today on https://godbolt.org/z/ANNyL6
Note that Clang does treat this as an error.
Thanks
[Bug c++/95553] Incorrect/misspelled designators not triggering compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95553 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- We warn with -Wpedantic and error with -pedantic-errors.
[Bug testsuite/95546] Random Fortran test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546 --- Comment #5 from Steve Kargl --- On Fri, Jun 05, 2020 at 03:46:18PM +, jvdelisle at charter dot net wrote: > > I am curious, did this just start happening or is it a long time issue just > reported. Locking mecahnisms were adjusted recently I believe. > What locking are you referring to? If it some recent changes to libgfortran's pthread locking, then I think that has nothing to do with the problem reported here. The code eof_4.f90 runs multiple tests. The looks like open(unit=99, file='test.dat', status='new') ! ! Test 1 ! close(99, status='delete') open(unit=99, file='test.dat', status='new') ! ! Test 2 ! close(99, status='delete') open(unit=99, file='test.dat', status='new') ! ! Test 3 ! close(99, status='delete') The above is actually testing Fortran feature. HJ Lu reported problems with 'make -jN', which suggests that eof_4.f90 is being compiled and executed in parallel. That is subject to races. Dejagnu needs to be told that eof_4.f90 cannot be run in parallel. If it is not possible to defeat dejagnu, then the test will need to changed to use a unique file name character(len=20) name write(name, '(A,I0,A)') 'tmp', getpid(), '.dat' open(unit=99, file=name, status='new') ! ! Test 1 ! close(99, status='delete') The test could also be adjusted to use inquire() and sleep() (need to check syntax) 1 inquire(file='test.dat', exists=stat) if (stat == 1) then call sleep(2) goto 1 end if
[Bug c++/65969] typename allowed in using declaration of non-types names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65969
Haoxin Tu changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment #3 from Haoxin Tu ---
This case also reproduces the issue
namespace g_namespace {
int var = 1;
}
int main() {
using typename g_namespace::var; //should be compiled failed but succeeded
return 0;
}
[Bug c/95554] New: spurious -Wnonnull on a conditional call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95554
Bug ID: 95554
Summary: spurious -Wnonnull on a conditional call
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The C test case below was reduced from gcc/var-tracking.c which triggers the
-Wnonnull (in C++) when the this pointer in member functions is considered
implicitly declared nonnull (or, alternatively, when vec::is_empty() is
declared with attribute nonnull):
In file included from /ssd/test/src/gcc/86568/gcc/var-tracking.c:89:
/ssd/test/src/gcc/86568/gcc/var-tracking.c: In function ‘void
loc_exp_dep_alloc(variable*, int)’:
/ssd/test/src/gcc/86568/gcc/var-tracking.c:8109:46: error: ‘this’ pointer null
[-Werror=nonnull]
8109 | || VAR_LOC_DEP_VEC (var)->is_empty ());
| ^
/ssd/test/src/gcc/86568/gcc/system.h:748:14: note: in definition of macro
‘gcc_assert’
748 |((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0
: 0))
| ^~~~
/ssd/test/src/gcc/86568/gcc/var-tracking.c:8107:3: note: in expansion of macro
‘gcc_checking_assert’
8107 | gcc_checking_assert (!count
| ^~~
In the test case the P macro corresponds to the VAR_LOC_DEP_VEC() macro defined
in the file, function g() to loc_exp_dep_alloc (), and the return statement to
the gcc_checking_assert.
$ cat q.c && gcc -O2 -S -Wall -fdump-tree-original=/dev/stdout q.c
__attribute__ ((nonnull)) int f (void*);
struct A
{
int i;
};
struct B
{
struct A *p;
};
#define P(p) (p->p ? &p->p : 0)
int g (struct B *p)
{
return P (p) == 0 || f (P (p));
}
q.c: In function ‘g’:
q.c:17:24: warning: null argument where non-null required (argument 1)
[-Wnonnull]
17 | return P (p) == 0 || f (P (p));
|^
;; Function g (null)
;; enabled by -tree-original
{
return (p->p == 0B || &p->p == 0B) || f (p->p != 0B ? (void *) &p->p : 0B) !=
0;
}
[Bug fortran/95509] [11 regression] gfortran.dg/spellcheck-operator.f90 fails after r11-875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509 --- Comment #4 from CVS Commits --- The master branch has been updated by Tom Tromey : https://gcc.gnu.org/g:640e05e02b567fa5ccf4c207e6fc6c3e9a93b17c commit r11-1004-g640e05e02b567fa5ccf4c207e6fc6c3e9a93b17c Author: Tom Tromey Date: Fri Jun 5 06:40:14 2020 -0600 fortran/95509 - fix spellcheck-operator.f90 regression My earlier patch to add case handling to the spell checker caused a Fortran regression. I believe I must have misread the test results. This patch fixes the problem by changing the cutoff. I chose this value because the previous patch effectively multiplied the result of get_edit_distance by 2 (unless a case change is involved). gcc/fortran/ChangeLog: PR fortran/95509 * misc.c (gfc_closest_fuzzy_match): Update cutoff value computation.
[Bug fortran/95509] [11 regression] gfortran.dg/spellcheck-operator.f90 fails after r11-875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509 Tom Tromey changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Tom Tromey --- Fixed.
[Bug bootstrap/95555] New: [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Bug ID: 9 Summary: [11 regression] bootstrap build failure starting with r11-959 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- g:b825a22890740f341eae566af27e18e528cd29a7, r11-959 /home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/xg++ -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/ -B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/libsupc++ -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/. -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcpp/include -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gmp -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gmp -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./mpfr/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpfr/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpc/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libbacktrace -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./isl/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/isl/include -o postreload.o -MT postreload.o -MMD -MP -MF ./.deps/postreload.TPo /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/postreload.c /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/postreload.c: In function 'int reload_cse_simplify_operands(rtx_insn*, rtx)': /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/postreload.c:629:5: error: '*alternative_order' may be used uninitialized [-Werror=maybe-uninitialized] 629 | j = alternative_order[0]; | ~~^~ cc1plus: all warnings being treated as errors make[3]: *** [postreload.o] Error 1
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 --- Comment #12 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bcd96c9cce962ca5b2c6f8459597fb759f945ccf commit r11-1009-gbcd96c9cce962ca5b2c6f8459597fb759f945ccf Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow.
[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95537 --- Comment #9 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bcd96c9cce962ca5b2c6f8459597fb759f945ccf commit r11-1009-gbcd96c9cce962ca5b2c6f8459597fb759f945ccf Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow.
[Bug fortran/95500] Segfault compiling extra interface on intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95500 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4b3ea558da6479dabe5841bcb0f6bad3f7fea858 commit r10-8250-g4b3ea558da6479dabe5841bcb0f6bad3f7fea858 Author: Harald Anlauf Date: Thu Jun 4 21:00:33 2020 +0200 PR fortran/95500 - Segfault compiling extra interface on intrinsic Converting an expression so that it can be passed by reference could result in a NULL pointer dereference. 2020-06-04 Steven G. Kargl Harald Anlauf gcc/fortran/ PR fortran/95500 * trans-expr.c (gfc_conv_expr_reference): Do not dereference NULL pointer. gcc/testsuite/ PR fortran/95500 * gfortran.dg/pr95500.f90: New test. (cherry picked from commit 8c727bdf4acf28c8315b119a1c8f6d6af745c2af)
[Bug fortran/95500] Segfault compiling extra interface on intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95500 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:fa0d6c132c8fd7deb118f8309aa9dfe41a88e840 commit r9-8653-gfa0d6c132c8fd7deb118f8309aa9dfe41a88e840 Author: Harald Anlauf Date: Thu Jun 4 21:00:33 2020 +0200 PR fortran/95500 - Segfault compiling extra interface on intrinsic Converting an expression so that it can be passed by reference could result in a NULL pointer dereference. 2020-06-04 Steven G. Kargl Harald Anlauf gcc/fortran/ PR fortran/95500 * trans-expr.c (gfc_conv_expr_reference): Do not dereference NULL pointer. gcc/testsuite/ PR fortran/95500 * gfortran.dg/pr95500.f90: New test. (cherry picked from commit 8c727bdf4acf28c8315b119a1c8f6d6af745c2af)
[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540 --- Comment #5 from Michael Bruck --- > Since the coroutine traits are global, and the closure type is unique, > that provides a way to disambiguate instantiations of the traits for > lambdas with otherwise identical signatures. But the closure type is generated in the same lambda expression where the coroutine generator looks up the coroutine_traits<>. How do I specialize on that?
[Bug fortran/95500] Segfault compiling extra interface on intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95500 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11, and backported to 10-branch and 9-branch. Closing. Thanks for the report!
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #1 from Martin Sebor --- The reload_cse_simplify_operands() function allocates three arrays but resets only two: alternative_reject = XALLOCAVEC (int, recog_data.n_alternatives); alternative_nregs = XALLOCAVEC (int, recog_data.n_alternatives); alternative_order = XALLOCAVEC (int, recog_data.n_alternatives); memset (alternative_reject, 0, recog_data.n_alternatives * sizeof (int)); memset (alternative_nregs, 0, recog_data.n_alternatives * sizeof (int)); It then assigns to the alternative_order array in the loop below, but only conditionally: /* Record all alternatives which are better or equal to the currently matching one in the alternative_order array. */ for (i = j = 0; i < recog_data.n_alternatives; i++) if (alternative_reject[i] <= alternative_reject[which_alternative]) alternative_order[j++] = i; recog_data.n_alternatives = j; Finally, it unconditionally reads the first element: /* Substitute the operands as determined by op_alt_regno for the best alternative. */ j = alternative_order[0]; I don't know this part of the compiler to tell if the first element is guaranteed to be stored into by the loop, and it seems that GCC can't figure it out either, so it issues the warning. That's expected. If the element is guaranteed to be set by the loop then storing a zero into it before the loop should be safe and avoid the warning. If it isn't, someone familiar with the code should look into what the right initial value should be. The affected code hasn't changed since 2003 but Jakub and Richard Sandiford have made changes to the function since then so they might be able to help. In the meantime, I would suggest zeroing out the first element to see if that helps. Bill, can you give it a try?
[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540
--- Comment #6 from Iain Sandoe ---
(In reply to Michael Bruck from comment #5)
> > Since the coroutine traits are global, and the closure type is unique,
> > that provides a way to disambiguate instantiations of the traits for
> > lambdas with otherwise identical signatures.
>
> But the closure type is generated in the same lambda expression where the
> coroutine generator looks up the coroutine_traits<>. How do I specialize on
> that?
I wasn't meaning to suggest you can specialise per lambda (but I was saying
that the traits instantiated will be unique per lambda) - perhaps the latter is
an implementation detail.
Providing the class/callable object type to the traits look does allow
specialisations like ...
template
struct std::coroutine_traits {
struct promise_type {
promise_type (CallOp op, T ...args) {}
Fake get_return_object() { return {}; }
std::suspend_always initial_suspend() { return {}; }
to be possible.
( I might be getting out of my depth with the long history of the design
evolution here - but this is my understanding of the rationale for the status
quo ).
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #15 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:78c4b06ac3df51c460de835917549c8555ee4eaf commit r10-8252-g78c4b06ac3df51c460de835917549c8555ee4eaf Author: Harald Anlauf Date: Fri May 29 21:19:31 2020 +0200 PR fortran/95090 - ICE: identifier overflow The initial fix for this PR uncovered several latent issues with further too small string buffers which showed up only when testing on i686. Provide sufficiently large temporaries. 2020-05-29 Harald Anlauf gcc/fortran/ PR fortran/95090 * class.c (get_unique_type_string): Enlarge temporary for name-mangling. Use strncpy to prevent buffer overrun. (get_unique_hashed_string): Enlarge temporary. (gfc_hash_value): Enlarge temporary for name-mangling. (cherry picked from commit 7deca8c0b3765787627b11387b56b97b01a8bf33)
[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95537 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:36442ee216acbe9a345ae625be53efbde8626477 commit r10-8254-g36442ee216acbe9a345ae625be53efbde8626477 Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow. (cherry picked from commit bcd96c9cce962ca5b2c6f8459597fb759f945ccf)
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2ee89130c278169b18b0123316ea4745120f commit r10-8251-g2ee89130c278169b18b0123316ea4745120f Author: Harald Anlauf Date: Wed May 27 21:20:24 2020 +0200 PR fortran/95090 - ICE: identifier overflow For long module name, derive type and component name, the generated name-mangled symbol did not fit into a buffer when coarrays were enabled. Provide sufficiently large temporary. 2020-05-27 Harald Anlauf gcc/fortran/ PR fortran/95090 * iresolve.c (gfc_get_string): Enlarge temporary for name-mangling. gcc/testsuite/ PR fortran/95090 * gfortran.dg/pr95090.f90: New test. (cherry picked from commit c949ec9c4e88d2ff6dbd5b179abddf3703129577)
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #16 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b3c17dfef86311a8b27b8e19854fd44cf8da29ee commit r10-8253-gb3c17dfef86311a8b27b8e19854fd44cf8da29ee Author: Harald Anlauf Date: Sat May 30 20:50:59 2020 +0200 PR fortran/95090 - ICE: identifier overflow Implement buffer overrun check for temporary that holds mangled names. 2020-05-30 Harald Anlauf gcc/fortran/ PR fortran/95090 * class.c (get_unique_type_string): Use buffer overrun check. (cherry picked from commit bf5fbbbd8c9a3385c1083cc80683bdb0195b1ffc)
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:36442ee216acbe9a345ae625be53efbde8626477 commit r10-8254-g36442ee216acbe9a345ae625be53efbde8626477 Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow. (cherry picked from commit bcd96c9cce962ca5b2c6f8459597fb759f945ccf)
[Bug c++/86568] -Wnonnull warnings should highlight the relevant argument not the closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||patch --- Comment #2 from Martin Sebor --- Full patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547415.html
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #2 from Andreas Schwab --- alternative_order[0] is guaranteed to be set, because alternative_reject[i] <= alternative_reject[which_alternative] for i == which_alternative at least. We know that which_alternative < recog_data.n_alternatives, otherwise alternative_reject[which_alternative] would be undefined.
[Bug c++/95369] braced-init-list with designated initializers as template-argument rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95369 --- Comment #5 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:cecc73af4980004502f4c327b6c639125defb379 commit r11-1010-gcecc73af4980004502f4c327b6c639125defb379 Author: Marek Polacek Date: Fri Jun 5 14:22:35 2020 -0400 c++: Make braced-init-list as template arg work with aggr init [PR95369] Barry pointed out to me that our braced-init-list as a template-argument extension doesn't work as expected when we aggregate-initialize. Since aggregate list-initialization is a user-defined conversion sequence, we allow it as part of a converted constant expression. Co-authored-by: Jason Merrill gcc/cp/ChangeLog: PR c++/95369 * call.c (build_converted_constant_expr_internal): Allow list-initialization. gcc/testsuite/ChangeLog: PR c++/95369 * g++.dg/cpp2a/nontype-class38.C: New test.
[Bug testsuite/95546] Random Fortran test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546 --- Comment #6 from Dominique d'Humieres --- > I am curious, did this just start happening or is it a long time issue just > reported. The test is quite old: Feb 18 2018. I did not see any failure for it until now (one instance).
[Bug fortran/95106] Bogus warning from module with long name and an equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1e20cd1b583347cb2ea8591a45d99df143f7c41a commit r10-8255-g1e20cd1b583347cb2ea8591a45d99df143f7c41a Author: Harald Anlauf Date: Sun May 24 21:35:04 2020 +0200 PR fortran/95106 - truncation of long symbol names with EQUIVALENCE For long module names, the generated name-mangled symbol was truncated, leading to bogus warnings about COMMON block mismatches. Provide sufficiently large temporaries. gcc/fortran/ 2020-05-24 Harald Anlauf PR fortran/95106 * trans-common.c (gfc_sym_mangled_common_id): Enlarge temporaries for name-mangling. gcc/testsuite/ 2020-05-24 Harald Anlauf PR fortran/95106 * gfortran.dg/equiv_11.f90: New test.
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428 --- Comment #7 from Nathan Sidwell --- Richard Smith thinks the ABI is clear and compilers should always emit the as-base ctor. Even though that wording was written before final was a thing. Depends if Jason wants to argue the case?
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:075bec57a1c63a1b1de9d95909866a6548380390 commit r9-8654-g075bec57a1c63a1b1de9d95909866a6548380390 Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow. (cherry picked from commit bcd96c9cce962ca5b2c6f8459597fb759f945ccf)
[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95537 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:075bec57a1c63a1b1de9d95909866a6548380390 commit r9-8654-g075bec57a1c63a1b1de9d95909866a6548380390 Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow. (cherry picked from commit bcd96c9cce962ca5b2c6f8459597fb759f945ccf)
[Bug fortran/95106] Bogus warning from module with long name and an equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:371739d01d00ae4c55902e0937b73ddee7d66391 commit r9-8655-g371739d01d00ae4c55902e0937b73ddee7d66391 Author: Harald Anlauf Date: Sun May 24 21:35:04 2020 +0200 PR fortran/95106 - truncation of long symbol names with EQUIVALENCE For long module names, the generated name-mangled symbol was truncated, leading to bogus warnings about COMMON block mismatches. Provide sufficiently large temporaries. gcc/fortran/ 2020-05-24 Harald Anlauf PR fortran/95106 * trans-common.c (gfc_sym_mangled_common_id): Enlarge temporaries for name-mangling. gcc/testsuite/ 2020-05-24 Harald Anlauf PR fortran/95106 * gfortran.dg/equiv_11.f90: New test. (cherry picked from commit d176184d98a00ab379ae5959aed1908a79995e6b)
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11, and backported to 10-branch and 9-branch. Thanks for the report and assistance in pinpointing the origin of the problem!
[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95537 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11, and backported to 10-branch and 9-branch. Thanks for the report and assistance in pinpointing the origin of the problem!
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552
--- Comment #5 from Jason Merrill ---
This simplified testcase has been broken a lot longer (back to GCC 8, at
least); my patch just extended the breakage to templates that already affected
non-templates. The issue is that cloning the constructor doesn't handle the
VLA typedef properly, so the version in the clone ends up still referring to
the cloned function, which blows up.
struct ViewDom
{
ViewDom(int i) { char (*a)[i]; }
};
void element( )
{
ViewDom a(2);
}
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11 and 10-branch. A backport to 9-branch would need some manual work. As this is not a regression, not done. Thanks for the report!
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d7760318305a0eab43d59d9884486569409c2d52 commit r10-8256-gd7760318305a0eab43d59d9884486569409c2d52 Author: Harald Anlauf Date: Thu May 28 22:28:08 2020 +0200 PR fortran/95373 - ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic types is valid only for suffienctly new Fortran standards. Add appropriate check. 2020-05-28 Harald Anlauf gcc/fortran/ PR fortran/95373 * primary.c (is_inquiry_ref): Check validity of inquiry references against selected Fortran standard. gcc/testsuite/ PR fortran/95373 * gfortran.dg/pr95373_1.f90: New test. * gfortran.dg/pr95373_2.f90: New test. (cherry picked from commit 5c715e6a2990cfb6c15acc1ee14219523534ec69)
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2927ec5bc1276188efae82301d8fcffe4a245d1e commit r10-8257-g2927ec5bc1276188efae82301d8fcffe4a245d1e Author: Harald Anlauf Date: Sat May 30 20:59:41 2020 +0200 PR fortran/95373 - ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic types is valid only for suffienctly new Fortran standards. Add appropriate checks in the appropriate place. 2020-05-30 Harald Anlauf gcc/fortran/ PR fortran/95373 * primary.c (is_inquiry_ref): Move validity check of inquiry references against selected Fortran standard from here... (gfc_match_varspec) ...to here. gcc/testsuite/ PR fortran/95373 * gfortran.dg/pr95373_1.f90: Adjust error messages. * gfortran.dg/pr95373_2.f90: Adjust error message. (cherry picked from commit dd38c765a04d06c775134a135f68b18c3b7c9c78)
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #3 from Martin Sebor --- (In reply to Andreas Schwab from comment #2) > alternative_order[0] is guaranteed to be set, because alternative_reject[i] > <= alternative_reject[which_alternative] for i == which_alternative at > least. We know that which_alternative < recog_data.n_alternatives, > otherwise alternative_reject[which_alternative] would be undefined. That's another way of saying that the code must be correct because otherwise it would be undefined. (There is no obvious constraint that which_alternative is less than recog_data.n_alternatives.) But if clearing alternative_order[0] is safe and if avoids the warning it's fine with me. Bill, can you please confirm that the patch below suppresses it (I can't reproduce it on my end)? diff --git a/gcc/postreload.c b/gcc/postreload.c index f6258285022..9b4e2bd9efb 100644 --- a/gcc/postreload.c +++ b/gcc/postreload.c @@ -592,6 +592,10 @@ reload_cse_simplify_operands (rtx_insn *insn, rtx testreg) } } + /* The loop below sets alternative_order[0] but -Wmaybe-uninitialized + can't know that. Clear it here to avoid the warning. */ + alternative_order[0] = 0; + /* Record all alternatives which are better or equal to the currently matching one in the alternative_order array. */ for (i = j = 0; i < recog_data.n_alternatives; i++)
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2039ad0eb5261a2e7eb1d3c9da7576a5c370c073 commit r9-8656-g2039ad0eb5261a2e7eb1d3c9da7576a5c370c073 Author: Harald Anlauf Date: Thu May 28 22:28:08 2020 +0200 PR fortran/95373 - ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic types is valid only for suffienctly new Fortran standards. Add appropriate check. 2020-05-28 Harald Anlauf gcc/fortran/ PR fortran/95373 * primary.c (is_inquiry_ref): Check validity of inquiry references against selected Fortran standard. gcc/testsuite/ PR fortran/95373 * gfortran.dg/pr95373_1.f90: New test. * gfortran.dg/pr95373_2.f90: New test. (cherry picked from commit 5c715e6a2990cfb6c15acc1ee14219523534ec69)
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d82e9d37d843539127df59d7b8894e5e3baec9b9 commit r9-8657-gd82e9d37d843539127df59d7b8894e5e3baec9b9 Author: Harald Anlauf Date: Sat May 30 20:59:41 2020 +0200 PR fortran/95373 - ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic types is valid only for suffienctly new Fortran standards. Add appropriate checks in the appropriate place. 2020-05-30 Harald Anlauf gcc/fortran/ PR fortran/95373 * primary.c (is_inquiry_ref): Move validity check of inquiry references against selected Fortran standard from here... (gfc_match_varspec) ...to here. gcc/testsuite/ PR fortran/95373 * gfortran.dg/pr95373_1.f90: Adjust error messages. * gfortran.dg/pr95373_2.f90: Adjust error message. (cherry picked from commit dd38c765a04d06c775134a135f68b18c3b7c9c78)
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11, and backported to 10-branch and 9-branch. Thanks for the report!
[Bug fortran/95512] gcc/fortran/trans-decl.c:1066: array sanity check after use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95512 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-06-05 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from anlauf at gcc dot gnu.org --- This looks like a false positive: dim is the index of the enclosing for loop. It is also funny that it warns about this statement and not the if preceeding this one.
[Bug fortran/95374] ICE: gfc_array_size failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95374 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |accepts-invalid, ||ice-on-invalid-code Priority|P3 |P4 Ever confirmed|0 |1 Last reconfirmed||2020-06-05 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Example z2.f90 is actually invalid code that is not rejected, since the rhs takes element a(0) which is out-of-bounds, has size 1, whereas the lhs has size 0. For the same reason, z1.f90 is invalid code since it accesses a(0).
