[Bug c++/106493] trailing requires clauses is not used for partial ordering when the ellipsis parameter is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106493 --- Comment #2 from Yuanfang Chen --- I'm actually fixing it on the Clang side. It would be great to make GCC/Clang match each other.
[Bug c++/106493] trailing requires clauses is not used for partial ordering when the ellipsis parameter is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106493 --- Comment #1 from Andrew Pinski --- clang rejects this for the same reason ...
[Bug c++/106493] New: trailing requires clauses is not used for partial ordering when the ellipsis parameter is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106493
Bug ID: 106493
Summary: trailing requires clauses is not used for partial
ordering when the ellipsis parameter is present
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tabloid.adroit at gmail dot com
Target Milestone: ---
test case:
```
template
concept AtLeast2 = sizeof(T) >= 2;
template
constexpr int doo(int a, ...) requires AtLeast2 && true {
return 1;
}
template
constexpr int doo(int b) requires AtLeast2 {
return 2;
}
static_assert(doo(2) == 1);
```
The assertion fails due to ambiguity. However, I'd expect the trailing requires
clauses kicks in by https://eel.is/c++draft/temp.fct#temp.func.order-6.4
Removing the ellipsis parameter fixes the assertion failure.
[Bug bootstrap/43301] top-level configure script ignores ---with-build-time-tools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301 Eric Gallager changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-July/59 ||9118.html Keywords||patch --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > (In reply to Eric Gallager from comment #3) > > Patches go to the gcc-patches mailing list if you still want to see this > > fixed > > Actually I guess I can try taking it myself OK, submitted: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599118.html
[Bug target/106450] [13 Regression] ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106450 --- Comment #5 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:493f4e6cf081ea2d016547629b29d130c1533ccb commit r13-1906-g493f4e6cf081ea2d016547629b29d130c1533ccb Author: Roger Sayle Date: Sun Jul 31 21:44:51 2022 +0100 PR target/106450: Tweak timode_remove_non_convertible_regs on x86_64. This patch resolves PR target/106450, some more fall-out from more aggressive TImode scalar-to-vector (STV) optimizations. I continue to be caught out by how far TImode STV has diverged from DImode/SImode STV, and therefore requires additional (unexpected) tweaking. Many thanks to H.J. Lu for pointing out timode_remove_non_convertible_regs needs to be extended to handle XOR (and other new operations). Unhelpfully the comment above this function states that it's the TImode version of "remove_non_convertible_regs", which doesn't exist anymore, so I've resurrected an explanatory comment from the git history. By refactoring the checks for hard regs and already "marked" regs into timode_check_non_convertible_regs itself, all of its callers are simplified. This patch then FOR_EACH_INSN_USE and FOR_EACH_INSN_DEF to generically handle arbitrary (non-move) instructions (including unary and binary operations), calling timode_check_non_convertible_regs on each TImode register USE and DEF. 2022-07-31 Roger Sayle H.J. Lu gcc/ChangeLog PR target/106450 * config/i386/i386-features.cc (timode_check_non_convertible_regs): Do nothing if REGNO is set in the REGS bitmap, or is a hard reg. (timode_remove_non_convertible_regs): Update comment. Call timode_check_non_convertible_reg on all TImode register DEFs and USEs in each instruction. gcc/testsuite/ChangeLog PR target/106450 * gcc.target/i386/pr106450.c: New test case.
[Bug middle-end/106492] New: ICE in #pragma omp for simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106492
Bug ID: 106492
Summary: ICE in #pragma omp for simd
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
This is similar to PR106449; adding the simd keyword to an existing omp for
test case causes an ICE related to incompatible types.
Test case is derived from g++.dg/gomp/pr95063.C:
// PR c++/95063
template
struct S {
T a : 12;
S () : a(0)
{
#pragma omp for simd linear(a)
for (int k = 0; k < 64; ++k)
a++;
}
};
struct U {
int a : 12;
U () : a(0)
{
#pragma omp for simd linear(a)
for (int k = 0; k < 64; ++k)
a++;
}
};
S s;
U u;
$ x86_64-none-linux-gnu-g++ -fopenmp pr95063.C -S
pr95063.C: In constructor 'U::U()':
pr95063.C:19:8: error: type mismatch in binary expression
19 | a++;
| ~^~
int
a = a + D.2648;
during GIMPLE pass: omplower
pr95063.C:19:8: internal compiler error: 'verify_gimple' failed
0x1295c9d verify_gimple_in_seq(gimple*)
/path/to/gcc/tree-cfg.cc:5220
0x1167b60 execute_function_todo
/path/to/gcc/passes.cc:2093
0x1167fdb execute_todo
/path/to/gcc/passes.cc:2145
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug fortran/106487] Calls to ___builtin_nested_func_ptr_created that cannot be resolved on M1 (Apple silicon)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106487 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||iains at gcc dot gnu.org --- Comment #3 from Eric Gallager --- Probably one of these; maybe Iain can tell us specifically which one: https://github.com/iains/gcc-darwin-arm64/issues
[Bug c++/106478] GCC rejects valid code involving partial specialization of variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106478 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 71954. *** This bug has been marked as a duplicate of bug 71954 ***
[Bug c++/71954] template partial specialization for constexpr error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71954 Andrew Pinski changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 106478 has been marked as a duplicate of this bug. ***
[Bug c++/106478] GCC rejects valid code involving partial specialization of variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106478 --- Comment #1 from Andrew Pinski --- Created attachment 53392 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53392=edit full testcase without headers
[Bug target/106491] ICE when compiling ArmSVE intrinsics in PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106491 --- Comment #3 from Andrew Pinski --- 0x104f8f2 aarch64_gimple_fold_builtin ../../src/gcc/config/aarch64/aarch64.c:14096 You should report this to ubuntu as the above line does not match up with the code being invoked. as mentioned in > See for instructions.
[Bug target/106491] ICE when compiling ArmSVE intrinsics in PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106491 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > I might have fixed this for gcc 12 already. Maybe fixed them with r12-3348-g98f1dd0212d576.
[Bug fortran/77652] Invalid rank error in ASSOCIATED when rank is remapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77652 --- Comment #8 from anlauf at gcc dot gnu.org --- I have pushed a relaxed version of the checks as agreed upon on the ML. As compilers seem to differ here (we are now closer to Crayftn and Nvidia), and as suggested by Toon, Mikael plans to submit an interpretation request. We might want to keep this PR open to track updates on the issue.
[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from anlauf at gcc dot gnu.org --- Fixed for gcc-13. Closing. Thanks for the report!
[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805 --- Comment #13 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d325e7048c85e13f12ea79aebf9623eddc7ffcaf commit r13-1905-gd325e7048c85e13f12ea79aebf9623eddc7ffcaf Author: Harald Anlauf Date: Thu Jul 28 22:07:02 2022 +0200 Fortran: detect blanks within literal constants in free-form mode [PR92805] gcc/fortran/ChangeLog: PR fortran/92805 * match.cc (gfc_match_small_literal_int): Make gobbling of leading whitespace optional. (gfc_match_name): Likewise. (gfc_match_char): Likewise. * match.h (gfc_match_small_literal_int): Adjust prototype. (gfc_match_name): Likewise. (gfc_match_char): Likewise. * primary.cc (match_kind_param): Match small literal int or name without gobbling whitespace. (get_kind): Do not skip over blanks. (match_string_constant): Likewise. gcc/testsuite/ChangeLog: PR fortran/92805 * gfortran.dg/literal_constants.f: New test. * gfortran.dg/literal_constants.f90: New test. Co-authored-by: Steven G. Kargl
[Bug fortran/77652] Invalid rank error in ASSOCIATED when rank is remapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77652 --- Comment #7 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0110cfd5449bae3a772f45ea2e4c5dab5b7a8ccd commit r13-1904-g0110cfd5449bae3a772f45ea2e4c5dab5b7a8ccd Author: Harald Anlauf Date: Wed Jul 27 21:34:22 2022 +0200 Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652] gcc/fortran/ChangeLog: PR fortran/77652 * check.cc (gfc_check_associated): Make the rank check of POINTER vs. TARGET match the allowed forms of pointer assignment for the selected Fortran standard. gcc/testsuite/ChangeLog: PR fortran/77652 * gfortran.dg/associated_target_9a.f90: New test. * gfortran.dg/associated_target_9b.f90: New test.
[Bug fortran/106487] Calls to ___builtin_nested_func_ptr_created that cannot be resolved on M1 (Apple silicon)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106487 --- Comment #2 from Arun Persaud --- Thanks for the fast response... any chance to add a link to the issue you mentioned or the repo?
[Bug other/98790] [10/11 Regression] ICE in append_to_statement_list_1 (Segmentation Fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790 --- Comment #12 from Eric Gallager --- Hearing that this may still happen: https://forums.wesnoth.org/viewtopic.php?p=675418#p675418 (haven't tested myself)
[Bug other/106429] make clean in libgcc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #15 from Eric Gallager --- I'd just like to note that the "clean" target is one of the standard Makefile targets that, according to the GNU Coding Standards, all GNU programs should include in their Makefiles: https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
[Bug c++/106486] C++ warning for -Wmissing-prototypes is pure nuisance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106486 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to H. Peter Anvin from comment #0) > Note that there doesn't seem to be any way to squelch this warning, either > (e.g. a -Wno-warning-not-applicable option or similar.) I think clang puts it under -Wunknown-warning-option, IIRC...
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290 --- Comment #7 from Lewis Hyatt --- The wrong location is fixed for GCC 13. Shall I leave the PR open for now, since there was also the issue of getting a caret pointing to the name of macro, rather than just a diagnostic for the whole line? I can look into that too.
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290 --- Comment #6 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:b04c399e258e686dddad879bf7e27d9e28fd6fde commit r13-1903-gb04c399e258e686dddad879bf7e27d9e28fd6fde Author: Lewis Hyatt Date: Tue Jul 12 09:47:47 2022 -0400 c++: Fix location for -Wunused-macros [PR66290] In C++, since all tokens are lexed from libcpp up front, diagnostics generated by libcpp after lexing has completed do not get a valid location from libcpp (rather, libcpp thinks they all pertain to the end of the file.) This has long been addressed using the global variable "done_lexing", which the C++ frontend sets at the appropriate time; when done_lexing is true, then c_cpp_diagnostic(), which outputs libcpp's diagnostics, uses input_location instead of the wrong libcpp location. The C++ frontend arranges that input_location will point to the token it is currently processing, so this generally works fine. However, there is one exception currently, which is -Wunused-macros. This gets generated at the end of processing in cpp_finish (), since we need to wait until then to determine whether a macro was eventually used or not. But the locations it passes to c_cpp_diagnostic () were remembered from the original lexing and hence they should not be overridden with input_location, which is now the one incorrectly pointing to the end of the file. Fixed by setting done_lexing=false again just prior to calling cpp_finish (). I also renamed the variable from done_lexing to "override_libcpp_locations", since it's now not strictly about lexing anymore. There is no new testcase with this patch, since we already had an xfailed testcase which is now fixed. gcc/c-family/ChangeLog: PR c++/66290 * c-common.h: Rename global done_lexing to override_libcpp_locations. * c-common.cc (c_cpp_diagnostic): Likewise. * c-opts.cc (c_common_finish): Set override_libcpp_locations (formerly done_lexing) immediately prior to calling cpp_finish (). gcc/cp/ChangeLog: PR c++/66290 * parser.cc (cp_lexer_new_main): Rename global done_lexing to override_libcpp_locations. gcc/testsuite/ChangeLog: PR c++/66290 * c-c++-common/pragma-diag-15.c: Remove xfail for C++.
[Bug other/106429] make clean in libgcc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 --- Comment #14 from Jonathan Wakely --- A failure during 'make clean' certainly doesn't prevent building GCC on older distributions as you initially claimed. That's just nonsense.
[Bug other/106429] make clean in libgcc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 --- Comment #13 from Jonathan Wakely --- (In reply to Martin Vahi from comment #11) > For me the "make clean" is a standard feature that is like the close button > at the corner of a window. For me, the fact that someone does not bother to > use the close button at the corner of the window is not an excuse, why the > button at the corner of the window should not work as expected. The same > with the "make clean": it is nice to do it automatically just to make sure > that I won't waste my human-life-minutes/hours on some triviality that comes > from leaving old build results laying around. So delete the whole build tree. Why would you want to keep an empty directory around after running 'make clean'? > > Actually, with some projects, I do not remember, which, there was a > distinction between "make clean" and "make clear", where the "make clear" > reset the source tree to the state as it is expected to be after fresh > checkout and the "make clean" was allowed to not delete all build system > generated files. The GCC build should be done outside the source tree, and won't change anything in the source tree anyway, so that distinction would be pointless. The source tree is left clean, and the build tree can be removed after building. I agree it shouldn't crash, but it also doesn't need to be used at all. It's there because automake always adds a 'clean' target to makefiles, not because it's useful.
[Bug other/106429] make clean in libgcc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 --- Comment #12 from Martin Vahi --- (In reply to Andrew Pinski from comment #9) > As I mentioned this is unrelated to bash version. > > "make clean" is failing so reopening for that issue. >... I'm not competent enough to refute Your statement, but I do emphasize that for whatever reason the crash DID NOT HAPPEN with a newer version of Bash.
[Bug other/106429] make clean in libgcc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 --- Comment #11 from Martin Vahi --- (In reply to Andrew Pinski from comment #10) > It should be noted almost nobody does "make clean" really. Most just remove > the build directory instead. > Is there a reason why you build scripts are doing "make clean"? For me the "make clean" is a standard feature that is like the close button at the corner of a window. For me, the fact that someone does not bother to use the close button at the corner of the window is not an excuse, why the button at the corner of the window should not work as expected. The same with the "make clean": it is nice to do it automatically just to make sure that I won't waste my human-life-minutes/hours on some triviality that comes from leaving old build results laying around. Actually, with some projects, I do not remember, which, there was a distinction between "make clean" and "make clear", where the "make clear" reset the source tree to the state as it is expected to be after fresh checkout and the "make clean" was allowed to not delete all build system generated files. For example, different developers may use different hardware/build_machines, but between the builds by a single developer on the same machine the build machine hardware specification does not change, so hardware related information might be "cached" by the build system. That is to say, the "make clean" might intentionally not remove hardware related autodetected information and the "make clear" would also delete hardware related autodetected information. Anyways, I understand that the "make clear" part might be a bit esoteric, but in my view the "make clean" is mainstream enough to be expected to work without crashing. Thank You for the answer and thank You for reading my comment :-)
[Bug target/106491] ICE when compiling ArmSVE intrinsics in PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106491 --- Comment #1 from Andrew Pinski --- I might have fixed this for gcc 12 already.
[Bug c++/106491] New: ICE when compiling ArmSVE intrinsics in PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106491 Bug ID: 106491 Summary: ICE when compiling ArmSVE intrinsics in PCH Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: denis.yaroshevskij at gmail dot com Target Milestone: --- Created attachment 53391 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53391=edit verbose outputs and .ii files A stack trace: ``` 0xd609b3 crash_signal ../../src/gcc/toplev.c:327 0x7faec4b3951f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x10d8340 TYPE_VECTOR_SUBPARTS(tree_node const*) ../../src/gcc/tree.h:3911 0x10d8340 aarch64_sve::gimple_folder::convert_pred(gimple*&, tree_node*, unsigned int) ../../src/gcc/config/aarch64/aarch64-sve-builtins.cc:2566 0x10e49df fold ../../src/gcc/config/aarch64/aarch64-sve-builtins-base.cc:1096 0x10dae1c aarch64_sve::gimple_folder::fold() ../../src/gcc/config/aarch64/aarch64-sve-builtins.cc:2680 0x10dae1c aarch64_sve::gimple_folder::fold() ../../src/gcc/config/aarch64/aarch64-sve-builtins.cc:2667 0x10dae1c aarch64_sve::gimple_fold_builtin(unsigned int, gimple_stmt_iterator*, gcall*) ../../src/gcc/config/aarch64/aarch64-sve-builtins.cc:3610 0x104f8f2 aarch64_gimple_fold_builtin ../../src/gcc/config/aarch64/aarch64.c:14096 0xacd886 gimple_fold_call ../../src/gcc/gimple-fold.c:5400 0xacd886 fold_stmt_1 ../../src/gcc/gimple-fold.c:6098 0x16d108f lower_stmt ../../src/gcc/gimple-low.c:388 0x16d1a2c lower_sequence ../../src/gcc/gimple-low.c:217 0x16d1a2c lower_gimple_bind ../../src/gcc/gimple-low.c:473 0x16d1f16 lower_function_body ../../src/gcc/gimple-low.c:110 0x16d1f16 execute ../../src/gcc/gimple-low.c:195 ``` Reporting this one was tricky, please let me know if you need some more information With "-v" I successfully reproduce the crash "-v -save-temps" causes "-Werror=invalid-pch" to fire ``` cc1plus: error: /home/dyarosh/space/eve/build_sve512/CMakeFiles/test_pch.dir/cmake_pch.hxx.gch: not used because `__AARCH64EL__' is defined [-Werror=invalid-pch] ``` If I remove "-Werror" - passes with no crash (maybe it dropped the pch?) Attaching "-v" output, "-v -save-temps" output and all .*ii files I could find. Let me know if you need some more information to help reproduce this.
[Bug middle-end/98109] Seemingly wrong warnings from -Wnonnull when combined with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98109
Bernd Buschinski changed:
What|Removed |Added
CC||b.buschinski at googlemail dot
com
--- Comment #4 from Bernd Buschinski ---
I also hit this problem, but not 100% sure if this is a duplicate or not.
Because as far as I can remember it used to work with GCC-11 (can not test now
only have 12) and only started failing with GCC 12.
Can someone tell me if this should be a new bug or is just a duplicate?
Known to fail on:
- sys-devel/gcc-12.1.1_p20220625 (Gentoo)
- gcc-12.1.1-1.fc36.x86_64 12.1.1 20220507 (Red Hat 12.1.1-1) (Fedora)
- 12-20220319-1ubuntu1 (Ubuntu 22.04)
Compiler explorer: https://godbolt.org/z/rrWffMe9x
Code:
#include
extern void *my_memmem(const void *__haystack, size_t __haystacklen,
const void *__needle, size_t __needlelen)
__THROW __attribute_pure__ __nonnull ((1, 3))
__attribute__((access(__read_only__, 1, 2)))
__attribute__((access(__read_only__, 3, 4)));
#define CONTAINSCONST(_cstring, string)
\
({
\
size_t const tmp_CONST_LEN = sizeof(string) - 1;
\
((_cstring).length >= tmp_CONST_LEN &&
\
(my_memmem((_cstring).buffer, (_cstring).length, string, tmp_CONST_LEN) !=
\
NULL));
\
})
struct my_string {
unsigned char *buffer;
unsigned long long length;
};
int foo(struct my_string const *const ss) {
struct my_string const str_path = *ss;
if (CONTAINSCONST(str_path, "/") ||
CONTAINSCONST(str_path, ".abcd") ||
CONTAINSCONST(str_path, "?")) {
return 1;
}
return 0;
}
// $ gcc -std=gnu99 -Wall -Wextra -Walloc-zero -O2 -fsanitize=undefined -Werror
test2.c -S
// test2.c: In function 'foo':
// test2.c:13:7: error: argument 1 is null but the corresponding size argument
2 value is [5, 18446744073709551615] [-Werror=nonnull]
//13 | (my_memmem((_cstring).buffer, (_cstring).length, string,
tmp_CONST_LEN) != \
// |
^~
// test2.c:26:7: note: in expansion of macro 'CONTAINSCONST'
//26 | CONTAINSCONST(str_path, ".abcd") ||
// | ^
// test2.c:3:14: note: in a call to function 'my_memmem' declared with
attribute 'access (read_only, 3, 4)'
// 3 | extern void *my_memmem(const void *__haystack, size_t __haystacklen,
// | ^
// cc1: all warnings being treated as errors
[Bug c/106416] -Wint-conversion should be an error, not a pedwarn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416 --- Comment #5 from David Binderman --- (In reply to Andrew Pinski from comment #4) > > The second warning looks wrong to me. > > It is right. Try doing the cast to int instead of a pointer (to int). Thanks for the correction. gcc does the right thing. New warning output is: $ /home/dcb/gcc/results/bin/gcc -c -std=c2x bug834.c bug834.c: In function ‘f’: bug834.c:6:17: warning: initialization of ‘int’ from ‘int *’ makes integer from pointer without a cast [-Wint-conversion] 6 | int a = p; | ^ bug834.c:7:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 7 | int b = (int) p; | ^ $
[Bug c/106416] -Wint-conversion should be an error, not a pedwarn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416 --- Comment #4 from Andrew Pinski --- > The second warning looks wrong to me. It is right. Try doing the cast to int instead of a pointer (to int).
[Bug c++/59950] [9 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950 Jonathan Wakely changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #13 from Jonathan Wakely --- *** Bug 106489 has been marked as a duplicate of this bug. ***
[Bug c++/106489] Valid Code involving assignment rejected by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106489 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #2 from Jonathan Wakely --- Fixed by r12-6862 c++: assignment to temporary [PR59950] Given build_this of a TARGET_EXPR, cp_build_fold_indirect_ref returns the TARGET_EXPR. But that's the wrong value category for the result of the defaulted class assignment operator, which returns an lvalue, so we need to actually build the INDIRECT_REF. PR c++/59950 gcc/cp/ChangeLog: * call.cc (build_over_call): Use cp_build_indirect_ref. gcc/testsuite/ChangeLog: * g++.dg/init/assign2.C: New test. *** This bug has been marked as a duplicate of bug 59950 ***
[Bug c/106416] -Wint-conversion should be an error, not a pedwarn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #3 from David Binderman ---
Interestingly, for this C code:
extern void g( int);
void f( int *p)
{
int a = p;
int b = (int *) p;
g( a);
g( b);
}
gcc does this:
$ /home/dcb/gcc/results/bin/gcc -c -std=c2x jul31a.c
jul31a.c: In function ‘f’:
jul31a.c:6:17: warning: initialization of ‘int’ from ‘int *’ makes integer from
pointer without a cast [-Wint-conversion]
6 | int a = p;
| ^
jul31a.c:7:17: warning: initialization of ‘int’ from ‘int *’ makes integer from
pointer without a cast [-Wint-conversion]
7 | int b = (int *) p;
| ^
$
The second warning looks wrong to me.
[Bug libgomp/106490] New: loop counter overflow within omp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106490
Bug ID: 106490
Summary: loop counter overflow within omp
Product: gcc
Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: dxin at usc dot edu
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 53390
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53390=edit
minimum test case
gcc's omp implementation seems to use a signed integer type for the loop
counter. As a result, if the user's code use an unsigned loop variable with a
large loop count, the internal loop counter overflows and the loop body never
run.
This is bug only happens when omp is used, i.e. the test case runs as expected
if the omp pragma is removed.
gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
-test case begin
#include
#include
#include"omp.h"
//const unsigned int I_LIMIT=(UINT_MAX)>>1;// good, printf runs for a while
const unsigned int I_LIMIT=UINT_MAX;// bad case, crash before any printf
int main()
{
#pragma omp parallel for
for(unsigned int i=0;i<=I_LIMIT;i++){
printf("i=%u,i=%f\n",i,(float)(i));
}
return 0;
}
-test case end
gcc test_omp_overflow.c -fopenmp
./a.out
[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106334 Sergei Trofimovich changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #5 from Sergei Trofimovich --- I'll reopen this bug. I still see the crash in original example. I can make #comment1 example crash by using `-flto-partition=none` in the link phase: $ ./result/bin/g++ -O1 -flto -fPIC -g -I. -o eval-cache.o -c eval-cache.cc && ./result/bin/g++ -O1 -flto -fPIC -g -I. -o eval.o -c eval.cc && ./result/bin/g++ -O1 -flto -fPIC -g -I. -o libnixexpr.so -shared eval-cache.o eval.o -flto-partition=none lto1: internal compiler error: in dwarf2out_register_external_die, at dwarf2out.cc:6076 0x1dc6714 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1], diagnostic_t) ???:0 0x1dc7366 internal_error(char const*, ...) ???:0 0x8b7012 fancy_abort(char const*, int, char const*) ???:0 0xa07036 dwarf2out_register_external_die(tree_node*, char const*, unsigned long) ???:0 0x904efd lto_read_decls(lto_file_decl_data*, void const*, vec) ???:0 0x905c6a read_cgraph_and_symbols(unsigned int, char const**) ???:0 0x8edc52 lto_main() ???:0 The compiler should already cpntain the fix: $ ./result/bin/g++ -v | unnix Using built-in specs. COLLECT_GCC=/nix/store/w9kh67lghm1mq5gbcgg06d00d982cyj2-gcc-13.0.0/bin/g++ COLLECT_LTO_WRAPPER=/nix/store/w9kh67lghm1mq5gbcgg06d00d982cyj2-gcc-13.0.0/libexec/gcc/x86_64-unknown-linux-gnu/13.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.0.0 20220724 (experimental) (GCC)
[Bug target/106450] [13 Regression] ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106450 Roger Sayle changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #4 from Roger Sayle --- *** Bug 106488 has been marked as a duplicate of this bug. ***
[Bug target/106488] [13 Regression] ICE: in ix86_output_ssemov, at config/i386/i386.cc:5565 with -O2 -fno-dce -fno-tree-vrp -mf16c -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106488 Roger Sayle changed: What|Removed |Added Resolution|--- |DUPLICATE Target Milestone|--- |13.0 CC||roger at nextmovesoftware dot com Status|UNCONFIRMED |RESOLVED --- Comment #1 from Roger Sayle --- This is a duplicate of PR target/106450, and (will be) fixed resolved by the patch posted here: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599081.html *** This bug has been marked as a duplicate of bug 106450 ***
[Bug c++/106489] Valid Code involving assignment rejected by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106489 Jason Liam changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jason Liam --- This has already been fixed in GCC 11.3 Demo: https://godbolt.org/z/Wo95GadsK
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #12 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:351e3cad2c5d4dfe43d68ba333bde1d70fa0b807 commit r13-1902-g351e3cad2c5d4dfe43d68ba333bde1d70fa0b807 Author: Roger Sayle Date: Sun Jul 31 08:13:30 2022 +0100 PR bootstrap/106472: Add libgo depends on libbacktrace to Makefile.def This patch fixes PR bootstrap/106472 by adding a missing dependency to Makefile.def to allow make bootstrap when configured using "--enable-languages=go" (and not using make with multiple threads). 2022-07-31 Roger Sayle ChangeLog PR bootstrap/106472 * Makefile.def (dependencies): Make configure-target-libgo depend upon all-target-libbacktrace.
[Bug c++/106489] New: Valid Code involving assignment rejected by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106489
Bug ID: 106489
Summary: Valid Code involving assignment rejected by gcc
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following valid code is rejected by gcc. https://godbolt.org/z/z9MKfz3e8
```
class A{
// implicitly generated assignment operations
};
int main() {
// ...
A& a = A{} = A{};
}
```
Error says:
```
:7:12: error: cannot bind non-const lvalue reference of type 'A&' to an
rvalue of type 'A'
7 | A& a = A{} = A{};
|^
```
[Bug c++/106369] [12/13 Regression] ICE in output_constructor_regular_field, at varasm.cc:5515 since r12-2975-g32c3a75390623a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:9efe4e153d994974afcbba09c3c683f5f4a19c63
commit r13-1901-g9efe4e153d994974afcbba09c3c683f5f4a19c63
Author: Jason Merrill
Date: Tue Jul 26 11:02:21 2022 -0400
c++: constexpr, empty base after non-empty [PR106369]
Here the CONSTRUCTOR we were providing for D{} had an entry for the B base
subobject at offset 0 following the entry for the C base, causing
output_constructor_regular_field to ICE due to going backwards. It might
be
nice for that function to be more tolerant of empty fields, but it also
seems reasonable for the front end to prune the useless entry.
PR c++/106369
gcc/cp/ChangeLog:
* constexpr.cc (reduced_constant_expression_p): Return false
if a CONSTRUCTOR initializes an empty field.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-lambda27.C: New test.
