[Bug target/57477] gcc generates suboptimal code for a simple and-shift-zeroextend combination on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57477 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Severity|normal |enhancement Status|UNCONFIRMED |NEW Last reconfirmed||2023-12-17 --- Comment #1 from Andrew Pinski --- Confirmed. There is Canonicalization going on which just happens to be worse for x86_64.
[Bug target/57672] va_list fixinclude needed for AIX 5.3 sys/types.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57672 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Target Milestone|--- |9.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- AIX 5.3 support was removed in GCC 9 by r9-2371-g116c7f320e45d6 .
[Bug testsuite/54697] testsuite in gcc 4.7.x leaves zombie processes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54697 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Target Milestone|--- |4.8.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- OSF support was removed from GCC 4.8.0.
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:da70c5b17123b7c81155ef03fb4591b71a681344 commit r14-6640-gda70c5b17123b7c81155ef03fb4591b71a681344 Author: Gerald Pfeifer Date: Sun Dec 17 15:13:39 2023 +0800 install: Streamline the hppa*-hp-hpux* section gcc: PR target/69374 * doc/install.texi (Specific) : Remove a note on GCC 4.3. Remove details on how the HP assembler, which we document as not working, breaks. : Note that only the HP linker is supported.
[Bug target/52670] -mabi=ms generates bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52670 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.7.0 Resolution|--- |FIXED Keywords||wrong-code Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed for GCC 4.7.0 by r0-107474-g6510e8bbf0b551 .
[Bug target/113048] New: [13/14 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1862 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
Bug ID: 113048
Summary: [13/14 Regression] ICE: in lra_split_hard_reg_for, at
lra-assigns.cc:1862 (unable to find a register to
spill) {*andndi3_doubleword_bmi} with
-march=cascadelake
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu
Created attachment 56893
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56893=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O1 -march=cascadelake -m32 -fwrapv testcase.c
testcase.c: In function 'foo0':
testcase.c:13:49: warning: division by zero [-Wdiv-by-zero]
13 | (~s64_0 & (0xfb5856dd8a4d4702 & foo0_s16_0) / 0) * u8_1;
| ^
testcase.c:22:1: error: unable to find a register to spill
22 | }
| ^
testcase.c:22:1: error: this is the insn:
(insn 34 99 109 2 (parallel [
(set (reg:DI 209 [159])
(and:DI (not:DI (reg/v:DI 187 [orig:144 s64_0 ] [144]))
(reg:DI 199 [182])))
(clobber (reg:CC 17 flags))
]) "testcase.c":13:13 703 {*andndi3_doubleword_bmi}
(expr_list:REG_DEAD (reg:DI 199 [182])
(expr_list:REG_DEAD (reg/v:DI 187 [orig:144 s64_0 ] [144])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
during RTL pass: reload
testcase.c:22:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1862
0x8035ef _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x12f42dd lra_split_hard_reg_for()
/repo/gcc-trunk/gcc/lra-assigns.cc:1862
0x12ed9f8 lra(_IO_FILE*, int)
/repo/gcc-trunk/gcc/lra.cc:2518
0x129badf do_reload
/repo/gcc-trunk/gcc/ira.cc:5973
0x129badf execute
/repo/gcc-trunk/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6619-20231216150950-g39f9c426f58-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-6619-20231216150950-g39f9c426f58-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231216 (experimental) (GCC)
[Bug tree-optimization/86975] wrong peephole optimization applied on nios2 and mips targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86975
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2023-12-17
--- Comment #2 from Andrew Pinski ---
I wonder if we should always use (a|casebit[32]) == 'e' for this case ...
Though I see LLVM Canonicals into the `(x&~32) == 'E'` even for the `(x|32) ==
'E'`.
int isE(int x) { return (x=='e') || (x=='E') ; }
int isE0(int x) { return (x&~32)=='E' ; }
int isE1(int x) { return (x|32)=='e' ; }
[Bug tree-optimization/109290] warning: array subscript -50 is outside array bounds of ‘struct kobject[36028797018963967]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109290 lavr at ncbi dot nlm.nih.gov changed: What|Removed |Added CC||lavr at ncbi dot nlm.nih.gov --- Comment #4 from lavr at ncbi dot nlm.nih.gov --- GCC 11.4 produces the same warning on code as simple as this: char buf[128]; char* c, q; // buf is filled with some contents from a read() if (!*(c = buf + strcspn(buf, kDigits))) return 0; q = c > buf ? c[-1] : '\0'; // THIS LINE GETS A WARNING array subscript -1 is outside array bounds of 'char[128]' [-Warray-bounds] Note that there's an explicit check that c > buf before accessing the index backwards.
[Bug middle-end/104069] Wuse-after-free=2 -O0 false positive "may be used"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
lavr at ncbi dot nlm.nih.gov changed:
What|Removed |Added
CC||lavr at ncbi dot nlm.nih.gov
--- Comment #35 from lavr at ncbi dot nlm.nih.gov ---
I'm still seeing this bogus warning for code as simple as this:
if (!(buf = (char*) realloc(var, newsize)) {
free(var); // THIS LINE GETS A WARNING HERE
return 0;
}
with GCC 13.2:
warning: pointer 'var' may be used after 'realloc' [-Wuse-after-free]
[Bug preprocessor/38987] Including a precompiled header from another header causes invalid assembly to be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38987 Andrew Pinski changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #14 from Andrew Pinski --- *** Bug 31872 has been marked as a duplicate of this bug. ***
[Bug debug/31872] Duplicate file numbers for .file directive with -g3 -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31872 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- This is a dup in the end. *** This bug has been marked as a duplicate of bug 38987 ***
[Bug libstdc++/84688] Use pdqsort instead of introsort for std::sort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84688 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug sanitizer/64354] no preprocessor symbol __SANITIZE_THREAD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354 Andrew Pinski changed: What|Removed |Added CC||rogero at howzatt dot co.uk --- Comment #5 from Andrew Pinski --- *** Bug 63559 has been marked as a duplicate of this bug. ***
[Bug sanitizer/63559] -fsanitize=thread sets no preprocessor flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Fixed for GCC 7 by r7-886-gf3510625cf2035 so this is a dup of PR 64354. *** This bug has been marked as a duplicate of bug 64354 ***
[Bug sanitizer/64354] no preprocessor symbol __SANITIZE_THREAD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354 Andrew Pinski changed: What|Removed |Added Target Milestone|5.0 |7.0
[Bug target/90798] Improve the diagnostic for the mismatched target attributes and the intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90798 Andrew Pinski changed: What|Removed |Added CC||jean-charles.papin@ens-cach ||an.fr --- Comment #4 from Andrew Pinski --- *** Bug 60985 has been marked as a duplicate of this bug. ***
[Bug target/60985] _mm_blendv_pd requires the '-msse4.1' option to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60985 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Yes PR 90798 is for that. So closing as a dup. *** This bug has been marked as a duplicate of bug 90798 ***
[Bug target/60985] _mm_blendv_pd requires the '-msse4.1' option to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60985 --- Comment #2 from Andrew Pinski --- Note the `-m32` part of _mm_blend_pd is fixed in GCC 9+ as we get: ``` In file included from :2: : In function 'main': :11:14: error: '__builtin_ia32_blendpd' needs isa option -msse4.1 11 | __m128d r = _mm_blend_pd (a, b, 1); | ^~~~ ``` Note the error message for _mm_blendv should be improved. I thought there was another bug about that ...
[Bug bootstrap/58657] bootstrapping cross compiler for sh4eb-*.* target wrongly creates a compiler with emulated TLS support instead of native TLS support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58657 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed for GCC 6 by r6-3299-g311adabec523e8 .
[Bug target/52889] incorrect sign of _mm_nmsub_XX intrinsics in fma4intrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52889
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Andrew Pinski ---
I tested:
```
#include
extern __m128 a,b,c;
void foo(){
a = _mm_nmsub_ps(a,b,c);
}
```
GCC produces correctly:
foo:
vmovaps a(%rip), %xmm1
vmovaps b(%rip), %xmm2
vfnmsubps c(%rip), %xmm2, %xmm1, %xmm0
vmovaps %xmm0, a(%rip)
ret
> However the fma4intrin.h mapping has changed from 4.5 -> 4.6,
> which might likely have introduced the error.
No r0-103863-g89509419968e2b (which was included in GCC 4.6.0) fixed the
defintion.
[Bug target/52889] incorrect sign of _mm_nmsub_XX intrinsics in fma4intrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52889 Andrew Pinski changed: What|Removed |Added Severity|critical|normal --- Comment #1 from Andrew Pinski --- I am not sure how important this is since FMA4 was only supported on a few AMD chips FMA4 and is no longer implemented on newer AMD chips (since Zen 1). I will double check to see if the definition was fixed though ...
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:f73a00b735f1c78b8eb09cffae8f5102b99f363f commit r14-6639-gf73a00b735f1c78b8eb09cffae8f5102b99f363f Author: Gerald Pfeifer Date: Sun Dec 17 09:18:28 2023 +0800 doc: Remove references to buildstat.html gcc: PR other/69374 * doc/install.texi (Installing GCC): Remove reference to buildstat.html. (Testing): Ditto. (Final install): Remove section on submitting information for buildstat.html. Adjust the request for feedback.
[Bug c++/106363] [13/14 Regression] [modules] ICE using-declaration of imported name in the same namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106363 --- Comment #6 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:cb76f46c97e9f4e4869acceb77a000b6cc2cda0e commit r14-6636-gcb76f46c97e9f4e4869acceb77a000b6cc2cda0e Author: Nathaniel Shead Date: Sun Nov 12 11:54:43 2023 +1100 c++: Seed namespaces for bindings [PR106363] Currently the first depset for an EK_BINDING is not seeded. This breaks the attached testcase as then the namespace is not considered referenced yet during streaming, but we've already finished importing. There doesn't seem to be any particular reason I could find for skipping the first depset for bindings, and removing the condition doesn't appear to cause any test failures, so this patch removes that check. PR c++/106363 gcc/cp/ChangeLog: * module.cc (module_state::write_cluster): Don't skip first depset for bindings. gcc/testsuite/ChangeLog: * g++.dg/modules/pr106363_a.C: New test. * g++.dg/modules/pr106363_b.C: New test. Signed-off-by: Nathaniel Shead
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > https://wg21.link/P2419R2 localized chrono formatting (also p2372r3) I think this this requires using nl_langinfo_l(CODESET, loc) to find out if the locale uses UTF-8, and then use iconv to convert to UTF-8 if it doesn't. But I'm not sure how we do that for an arbitrary std::locale which doesn't have an associated C locale, and we can't get its locale_t identifier anyway.
[Bug other/58974] document bug: texi2pod.pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58974 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-12-16 --- Comment #1 from Andrew Pinski --- Confirmed, still an issue today
[Bug fortran/55978] class_optional_2.f90 -Os fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 --- Comment #30 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #29) > + if (a->expr->expr_type == EXPR_NULL || a->expr->ts.type == BT_UNKNOWN) > + goto skip_size_check; Oops, that should read && instead of ||.
[Bug fortran/55978] class_optional_2.f90 -Os fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #29 from anlauf at gcc dot gnu.org --- (In reply to janus from comment #24) > * the NULL case in comment 16 is rejected This is fixed by: diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc index fc4fe662eab..ad99285d513 100644 --- a/gcc/fortran/interface.cc +++ b/gcc/fortran/interface.cc @@ -3409,6 +3425,9 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal, if (f->sym->ts.type == BT_CLASS) goto skip_size_check; + if (a->expr->expr_type == EXPR_NULL || a->expr->ts.type == BT_UNKNOWN) + goto skip_size_check; + actual_size = get_expr_storage_size (a->expr); formal_size = get_sym_storage_size (f->sym); if (actual_size != 0 && actual_size < formal_size
[Bug middle-end/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113033 Xi Ruoyao changed: What|Removed |Added Keywords||missed-optimization --- Comment #6 from Xi Ruoyao --- There is also a missed-optimization on LoongArch. vrotlM3 should be expanded to (rotatert X, (neg Y)) instead of two shifts and an ior.
[Bug target/113040] [14 Regression] libmvec test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |14.0
[Bug c++/113041] misleading diagnostic for variable of non-literal type in constexpr function in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113041 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-12-16 --- Comment #1 from Andrew Pinski --- Confirmed. there might be others like this too.
[Bug analyzer/112792] -Wanalyzer-out-of-bounds false positives seen on Linux kernel with certain unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112792 --- Comment #3 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:7abc7aae564e63173fbaa14805e3dddea7f6a160 commit r14-6635-g7abc7aae564e63173fbaa14805e3dddea7f6a160 Author: David Malcolm Date: Sat Dec 16 16:19:36 2023 -0500 analyzer: add sarif properties for bounds checking diagnostics As a followup to r14-6057-g12b67d1e13b3cf, add SARIF property bags for -Wanalyzer-out-of-bounds, to help with debugging these warnings. This was very helpful with PR analyzer/112792. gcc/analyzer/ChangeLog: * analyzer.cc: Include "tree-pretty-print.h" and "diagnostic-event-id.h". (tree_to_json): New. (diagnostic_event_id_to_json): New. (bit_offset_to_json): New. (byte_offset_to_json): New. * analyzer.h (tree_to_json): New decl. (diagnostic_event_id_to_json): New decl. (bit_offset_to_json): New decl. (byte_offset_to_json): New decl. * bounds-checking.cc: Include "diagnostic-format-sarif.h". (out_of_bounds::maybe_add_sarif_properties): New. (concrete_out_of_bounds::maybe_add_sarif_properties): New. (concrete_past_the_end::maybe_add_sarif_properties): New. (symbolic_past_the_end::maybe_add_sarif_properties): New. * region-model.cc (region_to_value_map::to_json): New. (region_model::to_json): New. * region-model.h (region_to_value_map::to_json): New decl. (region_model::to_json): New decl. * store.cc (bit_range::to_json): New. (byte_range::to_json): New. * store.h (bit_range::to_json): New decl. (byte_range::to_json): New decl. Signed-off-by: David Malcolm
[Bug target/113044] [14 Regression] wrong code with vector shift at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113044 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-12-16 Status|UNCONFIRMED |NEW Keywords||needs-bisection --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/113044] [14 Regression] wrong code with vector shift at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113044 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|target Target Milestone|--- |14.0
[Bug c++/113047] dereferencing a null pointer in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113047 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102420 --- Comment #2 from Andrew Pinski --- I suspect this is a dup of bug 102420 .
[Bug c++/113047] dereferencing a null pointer in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113047 --- Comment #1 from gcc_bz at brnz dot org --- I have submitted this same question for clang: https://github.com/llvm/llvm-project/issues/75716
[Bug c++/113047] New: dereferencing a null pointer in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113047
Bug ID: 113047
Summary: dereferencing a null pointer in a constant expression
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc_bz at brnz dot org
Target Milestone: ---
Should it be possible to dereference a null pointer in a C++20 constant
expression?
Consider this c++20 code:
struct T {
constexpr bool isNull() {
return !this;
}
};
static_assert(((T*)nullptr)->isNull());
constexpr T* t = nullptr;
static_assert((*t).isNull());
I would expect this to not compile due to the dereferencing of a null pointer
in a constant expression.
With reference to https://godbolt.org/z/q53rz5d69
By default, gcc-13.2 compiles without warning. -Wall yields a -Wnonnull
warning.
clang-17.0.1 produces errors and warning, by default.
msvc 19.38 compiles without warning.
Potentially relevant context:
2748. Accessing static data members via null pointer
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2748
2823. Implicit undefined behavior when dereferencing pointers
https://cplusplus.github.io/CWG/issues/2823.html
[Bug middle-end/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113033
Xi Ruoyao changed:
What|Removed |Added
Component|target |middle-end
CC||jakub at gcc dot gnu.org
--- Comment #5 from Xi Ruoyao ---
It looks like we should do:
diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index b294eabb08d..b87e09a8a65 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -2628,9 +2628,7 @@ expand_shift_1 (enum tree_code code, machine_mode mode,
rtx shifted,
(mode, GET_MODE_BITSIZE (scalar_mode) - INTVAL (op1));
else
{
- other_amount
- = simplify_gen_unary (NEG, GET_MODE (op1),
- op1, GET_MODE (op1));
+ other_amount = negate_rtx (GET_MODE (op1), op1);
HOST_WIDE_INT mask = GET_MODE_PRECISION (scalar_mode) - 1;
other_amount
= simplify_gen_binary (AND, GET_MODE (op1), other_amount,
??
[Bug libstdc++/113046] Standard algorithms should do de-iterator optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113046 --- Comment #1 from cqwrteur --- -Os optimization could observe the issue more clearly. The number of instructions reduced 51.94%, which is huge. https://godbolt.org/z/Eh1P1vvo5 I guarantee you this will improve the overall performance of C++ for a lot.
[Bug target/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113033 --- Comment #4 from Xi Ruoyao --- Strange... Most backends do not have predicate for op2 of vec_init but how do they evade this issue?
[Bug libstdc++/113046] New: Standard algorithms should do de-iterator optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113046 Bug ID: 113046 Summary: Standard algorithms should do de-iterator optimizations Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- I presented an example on Godbolt indicating that the combined use of std::vector::iterator with int* result in duplicated code when compared to using int*, which is not ideal. Additionally, it was observed that GCC and Clang do not optimize std::vector::iterator as effectively as a straightforward int*. You can view the example here: https://godbolt.org/z/x3q18fG3T To address this issue, I recommend implementing a de-iterator optimization. This optimization aims to eliminate the abstraction of the contiguous iterator, treating it as a simple pointer. By doing so, the compiler can merge duplicated code with a pointer, leading to simplified code and better overall optimization.
[Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758 --- Comment #14 from Greg McGary --- I bisected to here for the commit that broke the non-Zbs case: https://github.com/gcc-mirror/gcc/commit/2e886eef7f2b5aadb00171af868f0895b647c3a4 ... and here for Zbs case: https://github.com/gcc-mirror/gcc/commit/4e1e0d79ecbe8727cb69d4cd97b20c71caaefafc Note that the Zbs break happens with the commit that introduces Zbs handling, i.e., it never worked with Zbs from the beginning. In the non-Zbs case, it was the introduction of the insn_and_split pattern for single-insn materialization of negative constants that allows the combiner to create the problematic insn.
[Bug libstdc++/107367] All standard library algorithms should optimize to pointers internally when they are contiguous iterators after C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107367 cqwrteur changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #3 from cqwrteur --- moved and restart
[Bug target/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113033
--- Comment #3 from Xi Ruoyao ---
(define_expand "vec_init"
[(match_operand:LSX 0 "register_operand")
(match_operand:LSX 1 "")]
"ISA_HAS_LSX"
{
loongarch_expand_vector_init (operands[0], operands[1]);
DONE;
})
We need to add a predicate for operand 1...
[Bug fortran/97592] [11/12/13/14 Regression] Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-December/060042.html
[Bug target/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113033 --- Comment #2 from Xi Ruoyao --- It looks like we are missing a force_reg () somewhere.
[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94342 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #13 from Patrick Palka --- The attribute propagation issue which caused us to effectively ignore the section attribute on templated entities is fixed (naively, see PR88061#c11) for GCC 14 by r14-6595
[Bug c++/88061] section attributes of variable templates are ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061 --- Comment #11 from Patrick Palka --- N.B. that commit just naively fixes the attribute propagation issue which seems to make at least simple examples work as expected. The question of section + comdat handling could IIUC be demonstrated using non-template inline functions/variables as well and so is really an orthogonal issue I think?
[Bug target/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113033 Xi Ruoyao changed: What|Removed |Added CC||chenglulu at loongson dot cn, ||xen0n at gentoo dot org Ever confirmed|0 |1 Last reconfirmed||2023-12-16 Status|UNCONFIRMED |NEW --- Comment #1 from Xi Ruoyao --- Confirmed.
[Bug c++/88061] section attributes of variable templates are ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #10 from Patrick Palka --- Fixed for GCC 14
[Bug c++/70435] section attribute of a function template is not honored.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70435 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #10 from Patrick Palka --- Fixed for GCC 14
[Bug c++/109715] abi_tag attribute is not applied to variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109715 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |RESOLVED Target Milestone|--- |14.0 --- Comment #2 from Patrick Palka --- Fixed for GCC 14
[Bug c++/104867] Base class matching ignores type of `auto` template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104867 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed for GCC 14
[Bug c++/99186] std::tuple compilation error when elements are specializations of template class declared with template < auto E > syntax with E being a enumerator of a enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99186 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #8 from Patrick Palka --- Fixed for GCC 14
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #1 from Andrew Pinski --- This could also be a valgrind issue ...
[Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 Bug ID: 113045 Summary: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just tried a valgrind build of gcc trunk on my Raspberry PI 3B+. It said: echo | /home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/ -nostdinc -E -dM - | \ sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \ -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ sort -u > tmp-macro_list ==9933== Invalid read of size 8 ==9933==at 0x151D554: vld1q_u8 (arm_neon.h:10455) ==9933==by 0x151D554: search_line_fast (lex.cc:872) ==9933==by 0x151D554: _cpp_clean_line (lex.cc:960) ==9933==by 0x151DA0F: bool get_fresh_line_impl(cpp_reader*) (lex.cc:3747) $ grep -E "^Config|^==[0-9]" mk.out Configuring in ./libiberty Configuring in ./fixincludes Configuring in ./lto-plugin Configuring in build-armv7l-unknown-linux-gnueabihf/libiberty Configuring in build-armv7l-unknown-linux-gnueabihf/fixincludes Configuring in build-armv7l-unknown-linux-gnueabihf/libcpp Configuring in ./zlib Configuring in ./libbacktrace Configuring in ./libcody Configuring in ./libdecnumber Configuring in ./c++tools Configuring in ./libcpp Configuring in ./gcc Configuring in ./libcc1 ==9933== Invalid read of size 8 ==9933==at 0x151D554: vld1q_u8 (arm_neon.h:10455) ==9933==by 0x151D554: search_line_fast (lex.cc:872) ==9933==by 0x151D554: _cpp_clean_line (lex.cc:960) ==9933==by 0x151DA0F: bool get_fresh_line_impl(cpp_reader*) (lex.cc:3 747) Configure line is ../trunk/configure --disable-multilib \ --disable-bootstrap \ --enable-checking=valgrind \ --enable-languages=c,c++ And there is some tweeking of the top level Makefile: sed 's;-O2;-O2 -march=native;' < Makefile > Makefile.tmp diff Makefile Makefile.tmp mv Makefile.tmp Makefile
[Bug c/44179] warn about sizeof(char) and sizeof('x')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #5 from Alexander Monakov --- Warning when sizeof 'x' appears as a term in an addition/subtraction would catch the misuses while leaving instances like assert(sizeof 'x' == 4) be.
[Bug c/44179] warn about sizeof(char) and sizeof('x')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #4 from Harald van Dijk ---
(In reply to Zack Weinberg from comment #3)
> See
> http://codesearch.debian.net/
> search?q=filetype%3Ac+%5Cbsizeof%5Cs*%5C%28%5Cs*%27=0 for many
> examples.
There is a lot in there where a warning would be useful, but also a lot in
there where a warning would not be useful because the only reason the code is
doing sizeof('x') is because it's making sure that it actually is sizeof(int),
to check that it's not being compiled with a C++ compiler, or a C compiler that
picked up some C++isms by mistake. If GCC decides to warn about that, it is not
obvious how the code should be rewritten to silence the warning, but still have
the desired effect. In other places, redundant parentheses can be added to
indicate that a use is intentional ("if (a = b)" warns, "if ((a = b))" shuts up
the compiler), but sizeof('x') already has redundant parentheses. Would users
then be suggested to write sizeof(('x'))?
[Bug analyzer/112792] -Wanalyzer-out-of-bounds false positives seen on Linux kernel with certain unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112792
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:5f1bed2a7af828103ca23a3546466a23e8dd2f30
commit r14-6622-g5f1bed2a7af828103ca23a3546466a23e8dd2f30
Author: David Malcolm
Date: Sat Dec 16 09:03:16 2023 -0500
analyzer: use bit-level granularity for concrete bounds-checking [PR112792]
PR analyzer/112792 reports false positives from -fanalyzer's
bounds-checking on certain packed structs containing bitfields e.g.
in the Linux kernel's drivers/dma/idxd/device.c:
union msix_perm {
struct {
u32 rsvd2 : 8;
u32 pasid : 20;
};
u32 bits;
} __attribute__((__packed__));
The root cause is that the bounds-checking is done using byte offsets
and ranges; in the above, an access of "pasid" is treated as a 32-bit
access starting one byte inside the union, thus accessing byte offsets
1-4 when only offsets 0-3 are valid.
This patch updates the bounds-checking to use bit offsets and ranges
wherever possible - for concrete offsets and capacities. In the above
accessing "pasid" is treated as bits 8-27 of a 32-bit region, fixing the
false positive.
Symbolic offsets and ranges are still handled at byte granularity.
gcc/analyzer/ChangeLog:
PR analyzer/112792
* bounds-checking.cc
(out_of_bounds::oob_region_creation_event_capacity): Rename
"capacity" to "byte_capacity". Layout fix.
(out_of_boundsadd_region_creation_events): Rename
"capacity" to "byte_capacity".
(class concrete_out_of_bounds): Rename m_out_of_bounds_range to
m_out_of_bounds_bits and convert from a byte_range to a bit_range.
(concrete_out_of_bounds::get_out_of_bounds_bytes): New.
(concrete_past_the_end::concrete_past_the_end): Rename param
"byte_bound" to "bit_bound". Initialize m_byte_bound.
(concrete_past_the_end::subclass_equal_p): Update for renaming
of m_byte_bound to m_bit_bound.
(concrete_past_the_end::m_bit_bound): New field.
(concrete_buffer_overflow::concrete_buffer_overflow): Convert
param "range" from byte_range to bit_range. Rename param
"byte_bound" to "bit_bound".
(concrete_buffer_overflow::emit): Update for bits vs bytes.
(concrete_buffer_overflow::describe_final_event): Split
into...
(concrete_buffer_overflow::describe_final_event_as_bytes): ...this
(concrete_buffer_overflow::describe_final_event_as_bits): ...and
this.
(concrete_buffer_over_read::concrete_buffer_over_read): Convert
param "range" from byte_range to bit_range. Rename param
"byte_bound" to "bit_bound".
(concrete_buffer_over_read::emit): Update for bits vs bytes.
(concrete_buffer_over_read::describe_final_event): Split into...
(concrete_buffer_over_read::describe_final_event_as_bytes):
...this
(concrete_buffer_over_read::describe_final_event_as_bits): ...and
this.
(concrete_buffer_underwrite::concrete_buffer_underwrite): Convert
param "range" from byte_range to bit_range.
(concrete_buffer_underwrite::describe_final_event): Split into...
(concrete_buffer_underwrite::describe_final_event_as_bytes):
...this
(concrete_buffer_underwrite::describe_final_event_as_bits): ...and
this.
(concrete_buffer_under_read::concrete_buffer_under_read): Convert
param "range" from byte_range to bit_range.
(concrete_buffer_under_read::describe_final_event): Split into...
(concrete_buffer_under_read::describe_final_event_as_bytes):
...this
(concrete_buffer_under_read::describe_final_event_as_bits): ...and
this.
(region_model::check_region_bounds): Use bits for concrete values,
and rename locals to indicate whether we're dealing with bits or
bytes. Specifically, replace "num_bytes_sval" with
"num_bits_sval", and get it from reg's "get_bit_size_sval".
Replace "num_bytes_tree" with "num_bits_tree". Rename "capacity"
to "byte_capacity". Rename "cst_capacity_tree" to
"cst_byte_capacity_tree". Replace "offset" and
"num_bytes_unsigned" with "bit_offset" and "num_bits_unsigned"
respectively, converting from byte_offset_t to bit_offset_t.
Replace "out" and "read_bytes" with "bits_outside" and "read_bits"
respectively, converting from byte_range to bit_range. Convert
"buffer" from byte_range to bit_range. Replace "byte_bound" with
"bit_bound".
* region.cc
[Bug fortran/112459] gfortran -w option causes derived-type finalization at creation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459 --- Comment #4 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:9a1105b770df9a9b485705398abbb74b5c487a25 commit r14-6621-g9a1105b770df9a9b485705398abbb74b5c487a25 Author: Paul Thomas Date: Sat Dec 16 13:59:45 2023 + Fortran: Prevent unwanted finalization with -w option [PR112459] 2023-12-16 Paul Thomas gcc/fortran PR fortran/112459 * trans-array.cc (gfc_trans_array_constructor_value): Replace gfc_notification_std with explicit logical expression that selects F2003/2008 and excludes -std=default/gnu. * trans-expr.cc (gfc_conv_expr): Ditto. gcc/testsuite/ PR fortran/112459 * gfortran.dg/pr112459.f90: New test.
[Bug fortran/112834] Class array function selector causes chain of syntax and other spurious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112834 --- Comment #3 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:5ae6f524f5d4ee2ab79ba797fa4901daf90afb25 commit r14-6620-g5ae6f524f5d4ee2ab79ba797fa4901daf90afb25 Author: Paul Thomas Date: Sat Dec 16 13:26:47 2023 + Fortran: Fix problems with class array function selectors [PR112834] 2023-12-16 Paul Thomas gcc/fortran PR fortran/112834 * match.cc (build_associate_name): Fix whitespace issues. (select_type_set_tmp): If the selector is of unknown type, go the SELECT TYPE selector to see if this is a function and, if the result is available, use its typespec. * parse.cc (parse_associate): Again, use the function result if the type of the selector result is unknown. * trans-stmt.cc (trans_associate_var): The expression has to be of type class, for class_target to be true. Convert and fix class functions. Pass the fixed expression. PR fortran/111853 * resolve.cc (gfc_expression_rank): Avoid null dereference. gcc/testsuite/ PR fortran/112834 * gfortran.dg/associate_63.f90 : New test. PR fortran/111853 * gfortran.dg/pr111853.f90 : New test.
[Bug fortran/111853] f951: Segmentation fault at gfc_expression_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111853 --- Comment #2 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:5ae6f524f5d4ee2ab79ba797fa4901daf90afb25 commit r14-6620-g5ae6f524f5d4ee2ab79ba797fa4901daf90afb25 Author: Paul Thomas Date: Sat Dec 16 13:26:47 2023 + Fortran: Fix problems with class array function selectors [PR112834] 2023-12-16 Paul Thomas gcc/fortran PR fortran/112834 * match.cc (build_associate_name): Fix whitespace issues. (select_type_set_tmp): If the selector is of unknown type, go the SELECT TYPE selector to see if this is a function and, if the result is available, use its typespec. * parse.cc (parse_associate): Again, use the function result if the type of the selector result is unknown. * trans-stmt.cc (trans_associate_var): The expression has to be of type class, for class_target to be true. Convert and fix class functions. Pass the fixed expression. PR fortran/111853 * resolve.cc (gfc_expression_rank): Avoid null dereference. gcc/testsuite/ PR fortran/112834 * gfortran.dg/associate_63.f90 : New test. PR fortran/111853 * gfortran.dg/pr111853.f90 : New test.
[Bug fortran/89645] No IMPLICIT type error with: ASSOCIATE( X => function() )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89645
--- Comment #5 from Paul Thomas ---
Created attachment 56892
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56892=edit
An experimental patch for two pass compilation of contained procedures with
failures
I am giving up on this. Failures as follows:
FAIL: gfortran.dg/binding_label_tests_13_main.f03 -O (test for errors, line
5)
FAIL: gfortran.dg/binding_label_tests_13_main.f03 -O (test for errors, line
10)
Compiles without errors
FAIL: gfortran.dg/deferred_character_8.f90 -O0 (internal compiler error:
Segmentation fault)
FAIL: gfortran.dg/deferred_character_8.f90 -O0 (test for excess errors)
Compiles and runs OK outside dejagnu
...repeats...
FAIL: gfortran.dg/entry_16.f90 -O0 (internal compiler error: Segmentation
fault)
FAIL: gfortran.dg/entry_16.f90 -O0 (test for excess errors)
...repeats...
FAIL: gfortran.dg/entry_1.f90 -O1 (test for excess errors)
FAIL: gfortran.dg/entry_1.f90 -O2 (test for excess errors)
...repeats...
FAIL: gfortran.dg/entry_13.f90 -O0 (internal compiler error: Segmentation
fault)
FAIL: gfortran.dg/entry_13.f90 -O0 (test for excess errors)
...repeats...
All three entry failures are due to:
internal compiler error: Segmentation fault
0x10941df crash_signal
../../gcc/gcc/toplev.cc:316
0x10cf582 main_block_label
../../gcc/gcc/tree-cfg.cc:1533
0x10cf582 cleanup_dead_labels()
../../gcc/gcc/tree-cfg.cc:1718
0x10dd8d1 build_gimple_cfg
../../gcc/gcc/tree-cfg.cc:241
0x10dd8d1 execute_build_cfg
../../gcc/gcc/tree-cfg.cc:371
FAIL: gfortran.dg/host_assoc_call_3.f90 -O (test for excess errors)
Not finding the specific, doubly contained 'putaline'
gfortran.dg/namelist_4.f90 -O (test for errors, line 34)
FAIL: gfortran.dg/namelist_4.f90 -O (test for excess errors)
Error: ‘f2’ at (1) is not a variable instead of { dg-error "is not a VALUE" }
FAIL: gfortran.dg/pointer_assign_12.f90 -O (internal compiler error:
gimplification failed)
FAIL: gfortran.dg/pointer_assign_12.f90 -O (test for errors, line 10)
FAIL: gfortran.dg/pointer_assign_12.f90 -O (test for excess errors)
10 | g => 1 ! { dg-error "Pointer assignment target cannot be a
constant" }
|
^
internal compiler error: gimplification failed
0xd6cd97 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:17749
FAIL: gfortran.dg/pr87907.f90 -O (internal compiler error: Segmentation
fault)
FAIL: gfortran.dg/pr87907.f90 -O (test for errors, line 15)
FAIL: gfortran.dg/pr87907.f90 -O (test for errors, line 20)
FAIL: gfortran.dg/pr87907.f90 -O (test for errors, line 22)
FAIL: gfortran.dg/pr87907.f90 -O (test for excess errors)
f951: internal compiler error: Segmentation fault
0x10941df crash_signal
../../gcc/gcc/toplev.cc:316
0x97fd53 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/gcc/fortran/decl.cc:4281
0x9816bc gfc_match_data_decl()
../../gcc/gcc/fortran/decl.cc:6286
0x9f7a9f match_word
../../gcc/gcc/fortran/parse.cc:92
0x9f7a9f decode_statement
../../gcc/gcc/fortran/parse.cc:476
FAIL: gfortran.dg/pr95690.f90 -O (test for errors, line 5)
FAIL: gfortran.dg/pr95690.f90 -O (test for excess errors)
Error: Function ‘erfc’ requires an argument list at (1)
FAIL: gfortran.dg/pr96102.f90 -O (test for errors, line 13)
FAIL: gfortran.dg/pr96102.f90 -O (test for errors, line 14)
FAIL: gfortran.dg/pr96102.f90 -O (test for errors, line 17)
FAIL: gfortran.dg/pr96102.f90 -O (test for errors, line 18)
FAIL: gfortran.dg/pr96102.f90 -O (test for excess errors)
17 | if ( n /= 0 ) stop 1! { dg-error "internal procedure of the
same name" }
| 1
Error: Function ‘n’ requires an argument list at (1)
FAIL: gfortran.dg/pr96102b.f90 -O (test for errors, line 10)
FAIL: gfortran.dg/pr96102b.f90 -O (test for errors, line 11)
FAIL: gfortran.dg/pr96102b.f90 -O (test for errors, line 14)
FAIL: gfortran.dg/pr96102b.f90 -O (test for errors, line 15)
FAIL: gfortran.dg/pr96102b.f90 -O (test for excess errors)
Error: Unexpected use of subroutine name ‘n’ at (1)
FAIL: gfortran.dg/proc_ptr_result_2.f90 -O (test for excess errors)
35 | call set_fun(aux)
| 1
Error: Type mismatch in argument ‘y’ at (1); passed REAL(4) to UNKNOWN
XPASS: gfortran.dg/goacc/coarray.f95 -O TODO (test for errors, line 27)
XPASS: gfortran.dg/goacc/cray-2.f95 -O TODO (test for errors, line 49)
FAIL: gfortran.dg/goacc/cray-2.f95 -O (test for excess errors)
XPASS: gfortran.dg/goacc/cray.f95 -O TODO (test for errors, line 48)
FAIL: gfortran.dg/goacc/cray.f95 -O (test for excess errors)
FAIL: gfortran.dg/goacc/declare-1.f95 -O (test for errors, line 13)
FAIL: gfortran.dg/goacc/declare-1.f95 -O (test for excess errors)
FAIL:
[Bug rtl-optimization/113044] New: [14 Regression] wrong code with vector shift at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113044 Bug ID: 113044 Summary: [14 Regression] wrong code with vector shift at -O1 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56891=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O testcase.c $ ./a.out Aborted In the assembly: ... foo: ... mov al, dl # tmp110, v shr al, cl # tmp110, _1 movzx ecx, ch # tmp117, _1 mov ah, dl # tmp110, v shr ah, cl # tmp110, tmp117 ... 'dl' contains the low byte of the vector; dh should be used for the second shift: $ diff -u a-testcase.s.BAD a-testcase.s --- a-testcase.s.BAD2023-12-16 10:52:17.108156425 +0100 +++ a-testcase.s2023-12-16 10:52:22.871458132 +0100 @@ -23,7 +23,7 @@ mov al, dl # tmp110, v shr al, cl # tmp110, _1 movzx ecx, ch # tmp117, _1 - mov ah, dl # tmp110, v + mov ah, dh # tmp110, v shr ah, cl # tmp110, tmp117 # testcase.c:7: volatile char d = c; mov BYTE PTR [rsp+31], dil # d, c fixes the assembly $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6619-20231216150950-g39f9c426f58-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-6619-20231216150950-g39f9c426f58-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231216 (experimental) (GCC)
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-2526-g8911879415d6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Roger Sayle --- This should now be fixed on mainline, but similar issues may still be latent in combine (see the longer alternative in comment #12).
[Bug target/113034] Miscompilation of __m128 ne comparison on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113034 Xi Ruoyao changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |xry111 at gcc dot gnu.org --- Comment #4 from Xi Ruoyao --- I'm working on it.
[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 --- Comment #2 from Jonathan Wakely --- jason: seems like a simple matter of forcing the builtin declaration into the global module ppalka: fwiw it also works if we get rid of the implicit declaration of __class_type_info when declaring the builtin and just use const void* throughout the parameter list
[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-12-16
Target|powerpc64le-linux-gnu |
Status|UNCONFIRMED |NEW
Host|powerpc64le-linux-gnu |
Ever confirmed|0 |1
Build|powerpc64le-linux-gnu |
--- Comment #1 from Jonathan Wakely ---
It's seen on other targets too. Patrick came up with this reduced reproducer
for it:
--- a/gcc/testsuite/g++.dg/modules/pr106304_b.C
+++ b/gcc/testsuite/g++.dg/modules/pr106304_b.C
@@ -5,4 +5,5 @@ module pr106304;
void f(A& a) {
as_b(a);
+ dynamic_cast();
}
Just another latent front-end modules bug, that gets triggered by my new
library code.
[Bug tree-optimization/111967] [12 Regression] during GIMPLE pass: evrp ICE: in operator[], at vec.h:910 with -O2 -fno-tree-forwprop -fdump-tree-evrp-all since r12-4694
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111967 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug c/112339] ICE with clang::no_sanitize and -fsanitize=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112339 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug target/113034] Miscompilation of __m128 ne comparison on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113034 --- Comment #3 from Xi Ruoyao --- (define_code_iterator vfcond [unordered ordered eq ne le lt uneq unle unlt]) (define_code_attr fcc [(unordered "cun") (ordered "cor") (eq"ceq") (ne"cne") (uneq "cueq") (unle "cule") (unlt "cult") (le"cle") (lt"clt")]) This just looks wrong: not only "cne" should be "cune", but also "clt"/"cle" should be "slt"/"sle" instead (per C23 Annex F). It seems we should use the same thing as fcond in loongarch.md.
[Bug target/113034] Miscompilation of __m128 ne comparison on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113034 Xi Ruoyao changed: What|Removed |Added CC||chenglulu at loongson dot cn, ||xen0n at gentoo dot org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-12-16 Keywords||wrong-code --- Comment #2 from Xi Ruoyao --- Confirmed.
