[Bug target/107713] Wrong implementation atomic_exchange on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713 --- Comment #1 from Jinyang He --- Created attachment 53906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53906=edit a simple test
[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7c6cd9c05efca29a1a9635b81c86cbad25bbdbbe commit r13-4081-g7c6cd9c05efca29a1a9635b81c86cbad25bbdbbe Author: Jakub Jelinek Date: Wed Nov 16 07:30:07 2022 +0100 ragen-op-float: Fix up float_binary_op_range_finish [PR107668] The following testcase ICEs, because when !HONOR_NANS but HONOR_SIGNED_ZEROS, if we see lhs = op1 * op2; and know that lhs is [-0.0, 0.0] and op2 is [0.0, 0.0], the division of these two yields UNDEFINED and clear_nan () on it fails an assert. With HONOR_NANS it would actually result in a known NAN, but when NANs aren't honored, we clear the NAN bits. Now, for the above case we actually don't know anything about the op1 range (except that it isn't a NAN/INF because of !HONOR_NANS !HONOR_INFINITIES), so I think the best is just to return VARYING for the case we get UNDEFINED as well. If we want, the op[12]_range methods perhaps can handle the corner cases earlier separately, say for lhs [0.0, 0.0] and op2 [0.0, 0.0] when HONOR_SIGNED_ZEROS this would be just [0.0, MAX]. 2022-11-16 Jakub Jelinek PR tree-optimization/107668 * range-op-float.cc (float_binary_op_range_finish): Set VARYING also when r is UNDEFINED. * gcc.dg/ubsan/pr107668.c: New test.
[Bug target/107713] New: Wrong implementation atomic_exchange on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713
Bug ID: 107713
Summary: Wrong implementation atomic_exchange on
LoongArch
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hejinyang at loongson dot cn
Target Milestone: ---
Created attachment 53905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53905=edit
preprocessed file
Target: loongarch64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --libdir=/usr/lib64
--build=x86_64-cross-linux-gnu --host=loongarch64-unknown-linux-gnu
--target=loongarch64-unknown-linux-gnu --enable-__cxa_atexit
--enable-threads=posix --with-system-zlib --enable-libstdcxx-time
--enable-checking=release --with-build-sysroot=/opt/mylaos/sysroot
--enable-default-pie --enable-languages=c,c++,fortran,objc,obj-c++,lto
gcc version 13.0.0 20220801 (experimental) (GCC)
test_of_sync_lock_test_and_set.c:
char lock;
char hello()
{
return __sync_lock_test_and_set (, 1);
}
Cmdline:
gcc test_of_sync_lock_test_and_set.c -S --save-temps
Output Fragment:
1:
ll.w$r12,$r16,0
and $r19,$r12,$r14
bne $r19,$r15,2f <--- Wrong
and $r19,$r12,$r17
or $r19,$r19,$r18
sc.w$r19,$r16,0
beq $zero,$r19,1b
b 3f
2:
dbar0x700
3:
[Bug fortran/107669] [13 Regression] commit r13-3931 causes lots of testcase failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669 Haochen Jiang changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Haochen Jiang --- Solved on trunk.
[Bug rtl-optimization/90259] ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259
--- Comment #8 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:63e1b2e767a3f4695373c2406ff719c0a60c1858
commit r13-4079-g63e1b2e767a3f4695373c2406ff719c0a60c1858
Author: Kewen Lin
Date: Tue Nov 15 20:26:07 2022 -0600
rtl: Try to remove EH edges after {pro,epi}logue generation [PR90259]
After prologue and epilogue generation, the judgement on whether
one memory access onto stack frame may trap or not could change,
since we get more exact stack information by now.
As PR90259 shows, some memory access becomes impossible to trap
any more after prologue and epilogue generation, it can make
subsequent optimization be able to remove it if safe, but it
results in unexpected control flow status due to REG_EH_REGION
note missing.
This patch proposes to try to remove EH edges with function
purge_all_dead_edges after prologue and epilogue generation,
it simplifies CFG as early as we can and don't need any fixup
in downstream passes.
CFG simplification result with PR90259's case as example:
*before*
18: %1:TF=call [`__gcc_qdiv'] argc:0
REG_EH_REGION 0x2
77: NOTE_INSN_BASIC_BLOCK 3
19: NOTE_INSN_DELETED
20: NOTE_INSN_DELETED
110: [%31:SI+0x20]=%1:DF
REG_EH_REGION 0x2
116: NOTE_INSN_BASIC_BLOCK 4
111: [%31:SI+0x28]=%2:DF
REG_EH_REGION 0x2
22: NOTE_INSN_BASIC_BLOCK 5
108: %0:DF=[%31:SI+0x20]
REG_EH_REGION 0x2
117: NOTE_INSN_BASIC_BLOCK 6
109: %1:DF=[%31:SI+0x28]
REG_EH_REGION 0x2
79: NOTE_INSN_BASIC_BLOCK 7
26: [%31:SI+0x18]=%0:DF
104: pc=L69
105: barrier
*after*
18: %1:TF=call [`__gcc_qdiv'] argc:0
REG_EH_REGION 0x2
77: NOTE_INSN_BASIC_BLOCK 3
19: NOTE_INSN_DELETED
20: NOTE_INSN_DELETED
110: [%31:SI+0x20]=%1:DF
111: [%31:SI+0x28]=%2:DF
108: %0:DF=[%31:SI+0x20]
109: %1:DF=[%31:SI+0x28]
26: [%31:SI+0x18]=%0:DF
104: pc=L69
105: barrier
PR rtl-optimization/90259
gcc/ChangeLog:
* function.cc (rest_of_handle_thread_prologue_and_epilogue): Add
parameter fun, and call function purge_all_dead_edges.
(pass_thread_prologue_and_epilogue::execute): Name unamed parameter
as fun, and use it for rest_of_handle_thread_prologue_and_epilogue.
gcc/testsuite/ChangeLog:
* g++.target/powerpc/pr90259.C: New.
[Bug libstdc++/107701] [13 Regression] static linking broken when using iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107701 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug libstdc++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 --- Comment #9 from Tomoya Suzuki --- Thanks for clarifying the cause. I don't think you need to add the macro just for me, gcc11 behavior is not critical for me.
[Bug libstdc++/107712] New: std::format does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107712
Bug ID: 107712
Summary: std::format does not work for clang
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
/home/cqwrteur/toolchains/native/native/include/c++/13.0.0/format:1030:12:
error: use of undeclared identifier '__builtin_toupper'; did you mean
'__builtin_launder'?
*__p = __builtin_toupper(*__p);
^
/home/cqwrteur/toolchains/native/native/include/c++/13.0.0/new:194:14: note:
'__builtin_launder' declared here
{ return __builtin_launder(__p); }
^
In file included from concat_vs_format.cc:5:
/home/cqwrteur/toolchains/native/native/include/c++/13.0.0/format:1030:12:
error: non-pointer argument to '__builtin_launder' is not allowed
*__p = __builtin_toupper(*__p);
^~~
/home/cqwrteur/toolchains/native/native/include/c++/13.0.0/format:2852:37:
error: no member named '__float128_t' in namespace 'std::__format'
return type_identity<__format::__float128_t>();
~~^
3 errors generated.
[Bug analyzer/107711] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711 Bug ID: 107711 Summary: internal compiler error: Segmentation fault Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: urs at akk dot org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu Created attachment 53904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53904=edit internal compiler error: Segmentation fault gcc build from git @ 6052482f841634522c6d2e56c4231f8df2dc6d3e with configure --program-suffix=-13 --enable-languages=c,lto --enable-lto --disable-multilib make -j 4 BOOT_CFLAGS='-pipe -O0 -w' bootstrap on x86_64-pc-linux-gnu (Intel(R) Core(TM) i7-6700T); Ubuntu 22.04.1 LTS; GLIBC 2.35-0ubuntu3.1 gcc-13 -I. -I../include -DHAVE_CONFIG_H -DDEBUG -g -std=c11 -O2 -Wextra -Wpedantic -Wall -Winline -Wshadow -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wbad-function-cast -Wnested-externs -Wcast-align -Wpointer-arith -Waggregate-return -Wcast-qual -Wwrite-strings -Wundef -Wpacked -Wfloat-equal -Wunused-macros -Wold-style-definition -Winit-self -Wmissing-include-dirs -Wlogical-op -Wjump-misses-init -Wformat=2 -Wshift-overflow=2 -Wnull-dereference -Wduplicated-cond -Walloc-zero -Walloca -Wstringop-overflow=2 -Wduplicated-branches -Wno-format-nonliteral -Wno-stringop-truncation -Wno-format-truncation -fanalyzer -o makecfg ./makecfg.c results in ./makecfg.c: At top level: ./makecfg.c:552:1: internal compiler error: Segmentation fault 552 | } | ^ 0x7feba1f0151f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x7feba1ee8d8f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7feba1ee8e3f __libc_start_main_impl ../csu/libc-start.c:392 Please submit a full bug report, with preprocessed source (by using -freport-bug). I can't see the issue with additional "-v -save-temps -freport-bug" or without "-fanalyzer".
[Bug middle-end/107702] {,unsigned} __int128 to _Float16 conversion shouldn't use libgcc routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702 --- Comment #2 from joseph at codesourcery dot com --- (Where "check for any high bits being set" needs appropriate adjustment in the case of negative values for conversion from signed __int128, e.g. "the high 64 bits aren't the sign-extension of the low 64 bits" would be an appropriate condition to know there must be an overflow.)
[Bug middle-end/107702] {,unsigned} __int128 to _Float16 conversion shouldn't use libgcc routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702
--- Comment #1 from joseph at codesourcery dot com ---
On Tue, 15 Nov 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:
> _Float16 f9 (__int128 x) { return x; }
> _Float16 f10 (__int128 x) { return x; }
I suppose one of those is meant to be unsigned __int128?
> verifies that the __floattihf implementation always gives the same answer as
> does signed SImode -> SFmode cast followed by SFmode -> HFmode conversion.
> Isn't a conversion of a value > 65504 && value < -65504 UB in both C and C++?
No, an overflow is defined to produce an appropriately rounded value,
either an infinity or the largest finite value with the right sign,
depending on the rounding mode, with "overflow" and "inexact" raised (note
that the exact threshold for overflow depends on the rounding mode).
> So, can't we just implement the TI -> HF conversions by say ignoring upper 64
> bits of the __int128?
No. You could check for any high bits being set and e.g. use a different
path that converts a smaller value of the right sign that's still
guaranteed to overflow, if that's beneficial on a particular architecture
(it might well be if there's a hardware instruction for converting from
32-bit or 64-bit integers to _Float16, but not one for conversion from
128-bit integers, for example). Or you could go via converting such a
saturated value to SFmode if that's beneficial (standard C doesn't provide
any way to count the number of times an exception is raised by a single
operation, or the order in which they are raised, so it's OK that such an
approach may raise "inexact" before "overflow" and possibly more than
once).
[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation since r13-3358-ge0403e95689af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661 --- Comment #7 from Sergei Trofimovich --- Looking -fdump-ipa-cp-all I see the following clone ``` IPA decision stage: Evaluating opportunities for static void function_ref::callback_fn(void*) [with Callable = seemingly_unused_foo(int)::L]/30. Evaluating opportunities for static void function_ref::callback_fn(void*) [with Callable = void()]/29. Evaluating opportunities for void getWaitStatesSince3(int, function_ref)/18. - considering value callback_fn for param #1 Expired, offset: 0 (caller_count: 1) good_cloning_opportunity_p (time: 33, size: 37, freq_sum: 1) -> evaluation: 891.89, threshold: 500 Creating a specialized node of void getWaitStatesSince3(int, function_ref)/18. Accounting size:5.00, time:14.00 on predicate exec:(true) the new node is void getWaitStatesSince3.constprop(int, function_ref)/33. Aggregate replacements: 1[0]=callback_fn overall size reached 88 Evaluating opportunities for void getWaitStatesSince6(int, int, int, function_ref)/17. - considering value 0 for param #0 MBB (caller_count: 2) good_cloning_opportunity_p (time: 1, size: 21, freq_sum: 2, self_scc, single_call) -> evaluation: 80.95, threshold: 500 good_cloning_opportunity_p (time: 1, size: 21, freq_sum: 2, self_scc, single_call) -> evaluation: 80.95, threshold: 500 - considering value 42 for param #2 WaitStates (caller_count: 2) good_cloning_opportunity_p (time: 1.5, size: 20, freq_sum: 2, self_scc, single_call) -> evaluation: 127.50, threshold: 500 good_cloning_opportunity_p (time: 1.5, size: 20, freq_sum: 2, self_scc, single_call) -> evaluation: 127.50, threshold: 500 - considering value callback_fn for param #3 Expired, offset: 0 (caller_count: 2) good_cloning_opportunity_p (time: 33, size: 29, freq_sum: 1.4888, self_scc, single_call) -> evaluation: 1440.03, threshold: 500 Creating a specialized node of void getWaitStatesSince6(int, int, int, function_ref)/17. Accounting size:2.00, time:11.00 on predicate exec:(true) Accounting size:3.00, time:12.00 on predicate exec:(true) Accounting size:3.00, time:12.00 on predicate exec:(true) Accounting size:5.00, time:6.84 on predicate exec:(true) the new node is void getWaitStatesSince6.constprop(int, int, int, function_ref)/34. Aggregate replacements: 3[0]=callback_fn overall size reached 109 Evaluating opportunities for void getWaitStatesSince6(int, int, int, function_ref)/17. - considering value 0 for param #0 MBB (caller_count: 1) good_cloning_opportunity_p (time: 1, size: 21, freq_sum: 1, self_scc, single_call) -> evaluation: 40.48, threshold: 500 good_cloning_opportunity_p (time: 1, size: 21, freq_sum: 1, self_scc, single_call) -> evaluation: 40.48, threshold: 500 - considering value 42 for param #2 WaitStates (caller_count: 1) good_cloning_opportunity_p (time: 1.5, size: 20, freq_sum: 1, self_scc, single_call) -> evaluation: 63.75, threshold: 500 good_cloning_opportunity_p (time: 1.5, size: 20, freq_sum: 1, self_scc, single_call) -> evaluation: 63.75, threshold: 500 - adding an extra caller void getWaitStatesSince6(int, int, int, function_ref)/17 of void getWaitStatesSince6.constprop(int, int, int, function_ref)/34 Evaluating opportunities for void Exec(function_ref)/13. - considering value callback_fn for param #0 fr, offset: 0 (caller_count: 1) good_cloning_opportunity_p (time: 33, size: 8, freq_sum: 1) -> evaluation: 4125.00, threshold: 500 Creating a specialized node of void Exec(function_ref)/13. Accounting size:4.00, time:16.00 on predicate exec:(true) the new node is void Exec.constprop(function_ref)/35. Aggregate replacements: 0[0]=callback_fn ipa-prop: Discovered an indirect call to a known target (void Exec.constprop(function_ref)/35 -> static void function_ref::callback_fn(void*) [with Callable = seemingly_unused_foo(int)::L]/30), for stmt _1 (_2); ../a.cc:37:14: optimized: converting indirect call in void Exec.constprop(function_ref)/35 to direct call to static void function_ref::callback_fn(void*) [with Callable = seemingly_unused_foo(int)::L]/30 Accounting size:2.00, time:11.00 on predicate exec:(true) overall size reached 117 Evaluating opportunities for void Exec(function_ref)/13. Not considering void Exec.constprop(function_ref)/35 for ipa bitwise propagation ; -fipa-bit-cp: disabled. ... IPA constant propagation end ``` When debug reports unqualified `Aggregate replacements: 1[0]=callback_fn` does it mean ipa-cp does not distinguish between: * static void function_ref::callback_fn(void*) [with Callable = seemingly_unused_foo(int)::L]/30. * static void function_ref::callback_fn(void*) [with Callable = void()]/29. ? I suspect it does not and that results in a wrong callback_fn inline.
[Bug c++/107492] Unhelpful -Wignored-qualifiers warning in template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107492 --- Comment #7 from Jonathan Wakely --- I think clang warns there too, but we could.
[Bug c++/107492] Unhelpful -Wignored-qualifiers warning in template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107492 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Resolved. Do we want to revert r13-3607?
[Bug c++/107492] Unhelpful -Wignored-qualifiers warning in template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107492
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:ed1797ddf8285f59a50d9c883beb97705279d980
commit r13-4077-ged1797ddf8285f59a50d9c883beb97705279d980
Author: Marek Polacek
Date: Tue Nov 1 11:49:03 2022 -0400
c++: Disable -Wignored-qualifiers for template args [PR107492]
It seems wrong to issue a -Wignored-qualifiers warning for code like:
static_assert(!is_same_v);
because there the qualifier matters. Likewise in template
specialization:
template struct S { };
template<> struct S { };
template<> struct S { }; // OK, not a redefinition
And likewise in other type-id contexts such as trailing-return-type:
auto g() -> const void (*)();
This patch limits the warning to the function declaration context only.
PR c++/107492
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Only emit a -Wignored-qualifiers
warning
when funcdecl_p.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wignored-qualifiers3.C: New test.
[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #9 from anlauf at gcc dot gnu.org ---
Something like the following rejects NULL when there is no interface:
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index 49dbd1d886c..62b325b726d 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -4160,6 +4180,14 @@ gfc_procedure_use (gfc_symbol *sym, gfc_actual_arglist
**ap, locus *where)
return false;
}
+ if (a->expr && a->expr->expr_type == EXPR_NULL)
+ {
+ gfc_error ("Passing intrinsic NULL as actual argument at %L "
+"requires an explicit interface", >expr->where);
+ a->expr->error = 1;
+ return false;
+ }
+
/* TS 29113, C407b. */
if (a->expr && a->expr->expr_type == EXPR_VARIABLE
&& symbol_rank (a->expr->symtree->n.sym) == -1)
[Bug target/107243] ice in arithmetic_instr with invalid inline-asm and %I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107243 --- Comment #2 from David Binderman --- Nothing has happened on this for over a month. The bug still exists in current sources.
[Bug c++/104066] "constinit extern long (*const f) ();" doesn't compile: gcc thinks "constinit" applies to return value, not to function pointer itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Ah, I suppose I should've checked funcdecl_p before giving the error.
[Bug c++/107710] error: 'constinit' on function return type is not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107710 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 104066. *** This bug has been marked as a duplicate of bug 104066 ***
[Bug c++/104066] "extern constinit long (* const syscall_reexported) (long, ...); " doesn't compile: gcc thinks "constinit" applies to return value, not to function pointer itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066 Andrew Pinski changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 107710 has been marked as a duplicate of this bug. ***
[Bug c++/107710] New: error: ‘constinit’ on function return type is not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107710 Bug ID: 107710 Summary: error: ‘constinit’ on function return type is not allowed Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- constinit void (*p)() = nullptr; With -std=c++20 this is rejected: func.cc:1:1: error: ‘constinit’ on function return type is not allowed 1 | constinit void (*p)() = nullptr; | ^ Clang and EDG accept it.
[Bug middle-end/107709] New: IVOPTs is introducing a non-zero assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107709
Bug ID: 107709
Summary: IVOPTs is introducing a non-zero assumption
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amacleod at redhat dot com
Target Milestone: ---
Ive been working on fixing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655 ,
which basically adds an inferred range to
ptr1 = ptr2 + non-zero-const
such that ptr2 will be non-zero after this statement. Ive spent the last
couple of days trying to figure out why fortran is failing in a bootstrap, and
I think I finally have it figured out. fortran/scanner.c is being miscompiled
at -O2, and it boils down to the following testcase:
char *nextc;
void huh ()
{
int i;
char c;
for (i = 0; i < 5; i++)
{
c = (nextc == 0) ? '\n' : *nextc++;
if (c != ' ')
break;
}
}
The very beginning of this function, just before going into ivopts, looks like:
char * prephitmp_3;
char * pretmp_4;
unsigned int ivtmp_14;
unsigned int ivtmp_15;
[local count: 243289824]:
pretmp_4 = nextc;
[local count: 894749065]:
# prephitmp_3 = PHI <_2(7), pretmp_4(2)>
# ivtmp_14 = PHI
if (prephitmp_3 != 0B)
goto ; [96.34%]
else
goto ; [3.66%]
[local count: 32747817]:
[local count: 243289824]:
return;
note that prephitmp_3 will be pretmp4 to start the loop (edge 2->3), and then
it is checked against 0 (NULL) and processing only continues to BB5 if it isnt
NULL.
After IVOPTS runs, this is transformed into:
[local count: 243289824]:
pretmp_4 = nextc;
_12 = pretmp_4 + 5; <-- New introduction
[local count: 894749065]:
# prephitmp_3 = PHI <_2(7), pretmp_4(2)>
if (prephitmp_3 != 0B)
goto ; [96.34%]
else
goto ; [3.66%]
[local count: 32747817]:
[local count: 243289824]:
return;
Note it has added
_12 = pretmp_4 + 5
to basic block 2.
With the new code to instruct VRP that ptr1 = ptr2 + const means ptr2 is
non-null, it now propagates a range of [+1, +INF] for pretmp_4 on the edge
2->3, and that allows the condition which checks prephitmp_3 != 0 to be folded,
as _2 is always non-zero as well.
It seems that IVOPTS should not be adding that statement into BB2? It is
introducing a non-zero assumption that is not there before.
[Bug c++/107638] [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638 John David Anglin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from John David Anglin --- Thanks!
[Bug c++/106072] Bogus -Wnonnull warning breaks rust bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072 --- Comment #3 from Rainer Orth --- At least when building the devel/rust/master branch as of 2022, the warning doesn't occur any longer. I haven't investigated why, though.
[Bug fortran/107695] Non conforming shape during assignment is not detected at run-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107695 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-11-15 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. There seems to be no bounds checking of the rhs expression data(:,:), and I don't see that we generate a shape check here.
[Bug fortran/107680] ICE in arith_power, at fortran/arith.cc:989 and :1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from anlauf at gcc dot gnu.org --- Taking: https://gcc.gnu.org/pipermail/fortran/2022-November/058509.html
[Bug c/106765] [12/13 Regression] ICE (invalid code) in tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc since r12-7222-g3f10e0d50b5e3b3f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106765 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
[Bug lto/107708] LTO causes gnu::constructor functions to not be called with correct arguments if there is more than one constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107708 --- Comment #2 from Christoph Steefel --- Ok. If passing arguments to a constructor function is explicitly undefined, and gcc is willing to optimize based on that, should it be documented in the constructor attribute docs?
[Bug c/100532] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100532 Andrew Pinski changed: What|Removed |Added Target Milestone|12.3|--- Keywords||ice-checking Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
[Bug c/100525] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100525 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Resolution|--- |FIXED Keywords||ice-checking See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107305 --- Comment #5 from Andrew Pinski --- This was fixed with r13-3397-g8e2b5cf7cde999 .
[Bug c/101057] [gimplefe] GIMPLE frontend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057 Bug 101057 depends on bug 100525, which changed state. Bug 100525 Summary: ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100525 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/101285] [10/11/12/13 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_safe_arg_type_equiv_p, at c/c-typeck.c:5830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101285 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2022-11-15 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Keywords||ice-checking
[Bug c/101313] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in count_type_elements, at expr.c:6273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101313 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||ice-checking
[Bug c/101364] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_type_promotes_to, at c/c-typeck.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101364 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||ice-checking
[Bug middle-end/107307] [12/13 Regression] ICE tree check: expected class 'type', have 'exceptional' (error_mark) in canonicalize_component_ref, at gimplify.cc:2923 since r12-3278-g823685221de986af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107307 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/106764] [12/13 Regression] ICE on invalid code in tree check: expected function_type or method_type, have error_mark in gimplify_call_expr, at gimplify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106764 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/107680] ICE in arith_power, at fortran/arith.cc:989 and :1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #3) > I thought the call to gfc_type_convert_binary in eval_intrinsic was taking > care of mismatching types, doesn't it? It does, and then it doesn't do it sometimes... For real, parameter :: x(*) = [real :: ([1])] ** 2.0 after adding breakpoints in gfc_type_convert_binary and arith_power, I see correct types in the former (e->value.op.op2->ts.type = BT_REAL) but incorrect types in the latter (op1->ts.type = BT_INTEGER). It seems to be the ratatouille of parentheses, array constructors, typespec, and arithmetic operation that is crucial to get this type of error. In 12-branch, I also see other bad things happening, which I believe have partially been fixed by the series of patches for pr107000 and friends. Try: print *, [integer :: ([3.0])] ** 2.0 This gives 0. for all versions <= 12, and 9. for mainline. Given these observations, I suspect that typespecs are not consistently handled... See also the previous discussions.
[Bug libstdc++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #8 from Jonathan Wakely --- Thanks for the reduced example code, I can see what the problem is now. The mt19937 engine produces consistent results, but the commit that Andrew linked to alters the output of std::uniform_int_distribution, due to a different (much faster) algorithm used to downscale the random bits produced by std::mt19937 to the number of elements being shuffled. The only requirement on the uniform_int_distribution is that it produces values uniformly distributed between the minimum and maximum values. Unlike std::mt19937 it doesn't have to produce a specific sequence of values. I supposed we could add a macro that disables the new fast implementation, for users who prefer to get the same sequence of values as GCC 10, even though it's slower.
[Bug lto/107708] LTO causes gnu::constructor functions to not be called with correct arguments if there is more than one constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107708 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- The argument passing here is not defined at all. Yes glibc does it for ones used inside DT_INIT_ARRAY but that does mean it will always work.
[Bug lto/107708] New: LTO causes gnu::constructor functions to not be called with correct arguments if there is more than one constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107708
Bug ID: 107708
Summary: LTO causes gnu::constructor functions to not be called
with correct arguments if there is more than one
constructor
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: cfsteefel at arista dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When a function is marked with the constructor attribute, if there is more than
one function marked with the constructor attribute, the function's arguments
are not passed when LTO inlines the function into DT_INIT_ARRAY. If LTO is
disabled, the function will instead be passed argc, argv, and envp by glibc
(other libc implementation may or may not pass anything).
See the following code:
#include
namespace {
int c;
char ** a;
[[ gnu::constructor ]]
void foo( int argc, char ** argv ) {
a = argv;
c = argc;
}
[[ gnu::constructor ]]
void bar( int argc, char ** argv ) {
asm( "" );
}
}
int main() {
std::cerr << "argc: " << c << std::endl;
std::cerr << std::hex << a << std::endl;
return 0;
}
When compiled and run as:
> g++ text.cpp -g -shared -o libMain.so -fPIC -O2 -flto -Wall -Wextra
> g++ libMain.so
> LD_LIBRARY_PATH=. ./a.out 4 1 2 4
A sample output is:
argc: -638171435
0x7f20366efdd0
(the use of cerr is only meaningful for actually seeing output, and is not
needed to reproduce the error)
Using a specific and unique priority for the `gnu::constructor` attribute will
lead to the arguments being passed correctly, and argc will end up correct.
If the function is instead not defined inside an anonymous namespace, as just:
int c;
char ** a;
[[ gnu::constructor ]]
void foo( int argc, char ** argv ) {
a = argv;
c = argc;
}
g++ instead reports the error (using -Wall -Wextra):
In function '_sub_I_65535_0':
text.cpp:8:6: warning: 'argv' is used uninitialized [-Wuninitialized]
8 |a = argv;
| ^
lto1: note: 'argv' was declared here
text.cpp:9:6: warning: 'argc' is used uninitialized [-Wuninitialized]
9 |c = argc;
| ^
lto1: note: 'argc' was declared here
Using a unique constructor priority again will disable that warning.
g++ (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2)
glibc 2.34
[Bug c/107705] [12/13 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in ix86_function_type_abi, at config/i386/i386.cc:1529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107705 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||error-recovery Ever confirmed|0 |1 Last reconfirmed||2022-11-15 Target Milestone|--- |12.3 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- I am going to take this one.
[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 Bug 106003 depends on bug 106140, which changed state. Bug 106140 Summary: RFE: analyzer could complain about misuses of socket APIs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106140 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug analyzer/106140] RFE: analyzer could complain about misuses of socket APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106140 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #5 from David Malcolm --- Implemented for GCC 13 by the above patch.
[Bug analyzer/107472] Support for the Linux kernel's memory-management APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107472 Bug 107472 depends on bug 106302, which changed state. Bug 106302 Summary: RFE: provide a way for -fanalyzer to use target flags https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug analyzer/106301] RFE: analyzer support of mmap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106301 Bug 106301 depends on bug 106302, which changed state. Bug 106302 Summary: RFE: provide a way for -fanalyzer to use target flags https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 Bug 106003 depends on bug 106302, which changed state. Bug 106302 Summary: RFE: provide a way for -fanalyzer to use target flags https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug analyzer/106140] RFE: analyzer could complain about misuses of socket APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106140 Bug 106140 depends on bug 106302, which changed state. Bug 106302 Summary: RFE: provide a way for -fanalyzer to use target flags https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug analyzer/106302] RFE: provide a way for -fanalyzer to use target flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Implemented for GCC 13 by the above patch.
[Bug analyzer/107472] Support for the Linux kernel's memory-management APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107472 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:d8aba860b34203621586df8c5a6756b18c2a0c32 commit r13-4073-gd8aba860b34203621586df8c5a6756b18c2a0c32 Author: David Malcolm Date: Tue Nov 15 13:53:42 2022 -0500 c, analyzer: support named constants in analyzer [PR106302] The analyzer's file-descriptor state machine tracks the access mode of opened files, so that it can emit -Wanalyzer-fd-access-mode-mismatch. To do this, its symbolic execution needs to "know" the values of the constants "O_RDONLY", "O_WRONLY", and "O_ACCMODE". Currently analyzer/sm-fd.cc simply uses these values directly from the build-time header files, but these are the values on the host, not those from the target, which could be different (PR analyzer/106302). In an earlier discussion of this issue: https://gcc.gnu.org/pipermail/gcc/2022-June/238954.html we talked about adding a target hook for this. However, I've also been experimenting with extending the fd state machine to track sockets (PR analyzer/106140). For this, it's useful to "know" the values of the constants "SOCK_STREAM" and "SOCK_DGRAM". Unfortunately, these seem to have many arbitrary differences from target to target. For example: Linux/glibc general has SOCK_STREAM == 1, SOCK_DGRAM == 2, as does AIX, but annoyingly, e.g. Linux on MIPS has them the other way around. It seems to me that as the analyzer grows more ambitious modeling of the behavior of APIs (perhaps via plugins) it's more likely that the analyzer will need to know the values of named constants, which might not even exist on the host. For example, at LPC it was suggested to me that -fanalyzer could check rules about memory management inside the Linux kernel (probably via a plugin), but doing so involves a bunch of GFP_* flags (see PR 107472). So rather than trying to capture all this knowledge in a target hook, this patch attempts to get at named constant values from the user's source code. The patch adds an interface for frontends to call into the analyzer as the translation unit finishes. The analyzer can then call back into the frontend to ask about the values of the named constants it cares about whilst the frontend's data structures are still around. The patch implements this for the C frontend, which looks up the names by looking for named CONST_DECLs (which handles enum values). Failing that, it attempts to look up the values of macros but only the simplest cases are supported (a non-traditional macro with a single CPP_NUMBER token). It does this by building a buffer containing the macro definition and rerunning a lexer on it. The analyzer gracefully handles the cases where named values aren't found (such as anything more complicated than described above). The patch ports the analyzer to use this mechanism for "O_RDONLY", "O_WRONLY", and "O_ACCMODE". I have successfully tested my socket patch to also use this for "SOCK_STREAM" and "SOCK_DGRAM", so the technique seems to work. gcc/ChangeLog: PR analyzer/106302 * Makefile.in (ANALYZER_OBJS): Add analyzer/analyzer-language.o. (GTFILES): Add analyzer/analyzer-language.cc. * doc/analyzer.texi: Document __analyzer_dump_named_constant. gcc/analyzer/ChangeLog: PR analyzer/106302 * analyzer-language.cc: New file. * analyzer-language.h: New file. * analyzer.h (get_stashed_constant_by_name): New decl. (log_stashed_constants): New decl. * engine.cc (impl_run_checkers): Call log_stashed_constants. * region-model-impl-calls.cc (region_model::impl_call_analyzer_dump_named_constant): New. * region-model.cc (region_model::on_stmt_pre): Handle __analyzer_dump_named_constant. * region-model.h (region_model::impl_call_analyzer_dump_named_constant): New decl. * sm-fd.cc (fd_state_machine::m_O_ACCMODE): New. (fd_state_machine::m_O_RDONLY): New. (fd_state_machine::m_O_WRONLY): New. (fd_state_machine::fd_state_machine): Initialize the new fields. (fd_state_machine::get_access_mode_from_flag): Use the new fields, rather than using the host values. gcc/c/ChangeLog: PR analyzer/106302 * c-parser.cc: Include "analyzer/analyzer-language.h" and "toplev.h". (class ana::c_translation_unit): New. (c_parser_translation_unit): Call ana::on_finish_translation_unit. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/analyzer-decls.h (__analyzer_dump_named_constant): New decl. * gcc.dg/analyzer/fd-4.c (void): Likewise.
[Bug analyzer/106140] RFE: analyzer could complain about misuses of socket APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106140 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:86a90006864840c2e222d46ead551850caba184b commit r13-4074-g86a90006864840c2e222d46ead551850caba184b Author: David Malcolm Date: Tue Nov 15 13:53:42 2022 -0500 analyzer: add warnings relating to sockets [PR106140] This patch generalizes the analyzer's file descriptor state machine so that it tracks the states of sockets. It adds two new warnings relating to misuses of socket APIs: * -Wanalyzer-fd-phase-mismatch (e.g. calling 'accept' on a socket before calling 'listen' on it) * -Wanalyzer-fd-type-mismatch (e.g. using a stream socket operation on a datagram socket) gcc/analyzer/ChangeLog: PR analyzer/106140 * analyzer-language.cc (on_finish_translation_unit): Stash named constants "SOCK_STREAM" and "SOCK_DGRAM". * analyzer.opt (Wanalyzer-fd-phase-mismatch): New. (Wanalyzer-fd-type-mismatch): New. * engine.cc (impl_region_model_context::get_state_map_by_name): Add "out_sm_context" param. Allow out_sm_idx to be NULL. * exploded-graph.h (impl_region_model_context::get_state_map_by_name): Add "out_sm_context" param. * region-model-impl-calls.cc (region_model::impl_call_accept): New. (region_model::impl_call_bind): New. (region_model::impl_call_connect): New. (region_model::impl_call_listen): New. (region_model::impl_call_socket): New. * region-model.cc (region_model::on_call_pre): Special-case "bind". (region_model::on_call_post): Special-case "accept", "bind", "connect", "listen", and "socket". * region-model.h (region_model::impl_call_accept): New decl. (region_model::impl_call_bind): New decl. (region_model::impl_call_connect): New decl. (region_model::impl_call_listen): New decl. (region_model::impl_call_socket): New decl. (region_model::on_socket): New decl. (region_model::on_bind): New decl. (region_model::on_listen): New decl. (region_model::on_accept): New decl. (region_model::on_connect): New decl. (region_model::add_constraint): Make public. (region_model::check_for_poison): Make public. (region_model_context::get_state_map_by_name): Add out_sm_context param. (region_model_context::get_fd_map): Likewise. (region_model_context::get_malloc_map): Likewise. (region_model_context::get_taint_map): Likewise. (noop_region_model_context::get_state_map_by_name): Likewise. (region_model_context_decorator::get_state_map_by_name): Likewise. * sm-fd.cc: Include "analyzer/supergraph.h" and "analyzer/analyzer-language.h". (enum expected_phase): New enum. (fd_state_machine::m_new_datagram_socket): New. (fd_state_machine::m_new_stream_socket): New. (fd_state_machine::m_new_unknown_socket): New. (fd_state_machine::m_bound_datagram_socket): New. (fd_state_machine::m_bound_stream_socket): New. (fd_state_machine::m_bound_unknown_socket): New. (fd_state_machine::m_listening_stream_socket): New. (fd_state_machine::m_m_connected_stream_socket): New. (fd_state_machine::m_SOCK_STREAM): New. (fd_state_machine::m_SOCK_DGRAM): New. (fd_diagnostic::describe_state_change): Handle socket states. (fd_diagnostic::get_meaning_for_state_change): Likewise. (class fd_phase_mismatch): New. (enum expected_type): New enum. (class fd_type_mismatch): New. (fd_state_machine::fd_state_machine): Initialize new states and stashed named constants. (fd_state_machine::is_socket_fd_p): New. (fd_state_machine::is_datagram_socket_fd_p): New. (fd_state_machine::is_stream_socket_fd_p): New. (fd_state_machine::on_close): Handle the socket states. (fd_state_machine::check_for_open_fd): Complain about fncalls on sockets in the wrong phase. Support socket FDs. (add_constraint_ge_zero): New. (fd_state_machine::get_state_for_socket_type): New. (fd_state_machine::on_socket): New. (fd_state_machine::check_for_socket_fd): New. (fd_state_machine::check_for_new_socket_fd): New. (fd_state_machine::on_bind): New. (fd_state_machine::on_listen): New. (fd_state_machine::on_accept): New. (fd_state_machine::on_connect): New. (fd_state_machine::can_purge_p): Don't purge socket values.
[Bug analyzer/106302] RFE: provide a way for -fanalyzer to use target flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:d8aba860b34203621586df8c5a6756b18c2a0c32 commit r13-4073-gd8aba860b34203621586df8c5a6756b18c2a0c32 Author: David Malcolm Date: Tue Nov 15 13:53:42 2022 -0500 c, analyzer: support named constants in analyzer [PR106302] The analyzer's file-descriptor state machine tracks the access mode of opened files, so that it can emit -Wanalyzer-fd-access-mode-mismatch. To do this, its symbolic execution needs to "know" the values of the constants "O_RDONLY", "O_WRONLY", and "O_ACCMODE". Currently analyzer/sm-fd.cc simply uses these values directly from the build-time header files, but these are the values on the host, not those from the target, which could be different (PR analyzer/106302). In an earlier discussion of this issue: https://gcc.gnu.org/pipermail/gcc/2022-June/238954.html we talked about adding a target hook for this. However, I've also been experimenting with extending the fd state machine to track sockets (PR analyzer/106140). For this, it's useful to "know" the values of the constants "SOCK_STREAM" and "SOCK_DGRAM". Unfortunately, these seem to have many arbitrary differences from target to target. For example: Linux/glibc general has SOCK_STREAM == 1, SOCK_DGRAM == 2, as does AIX, but annoyingly, e.g. Linux on MIPS has them the other way around. It seems to me that as the analyzer grows more ambitious modeling of the behavior of APIs (perhaps via plugins) it's more likely that the analyzer will need to know the values of named constants, which might not even exist on the host. For example, at LPC it was suggested to me that -fanalyzer could check rules about memory management inside the Linux kernel (probably via a plugin), but doing so involves a bunch of GFP_* flags (see PR 107472). So rather than trying to capture all this knowledge in a target hook, this patch attempts to get at named constant values from the user's source code. The patch adds an interface for frontends to call into the analyzer as the translation unit finishes. The analyzer can then call back into the frontend to ask about the values of the named constants it cares about whilst the frontend's data structures are still around. The patch implements this for the C frontend, which looks up the names by looking for named CONST_DECLs (which handles enum values). Failing that, it attempts to look up the values of macros but only the simplest cases are supported (a non-traditional macro with a single CPP_NUMBER token). It does this by building a buffer containing the macro definition and rerunning a lexer on it. The analyzer gracefully handles the cases where named values aren't found (such as anything more complicated than described above). The patch ports the analyzer to use this mechanism for "O_RDONLY", "O_WRONLY", and "O_ACCMODE". I have successfully tested my socket patch to also use this for "SOCK_STREAM" and "SOCK_DGRAM", so the technique seems to work. gcc/ChangeLog: PR analyzer/106302 * Makefile.in (ANALYZER_OBJS): Add analyzer/analyzer-language.o. (GTFILES): Add analyzer/analyzer-language.cc. * doc/analyzer.texi: Document __analyzer_dump_named_constant. gcc/analyzer/ChangeLog: PR analyzer/106302 * analyzer-language.cc: New file. * analyzer-language.h: New file. * analyzer.h (get_stashed_constant_by_name): New decl. (log_stashed_constants): New decl. * engine.cc (impl_run_checkers): Call log_stashed_constants. * region-model-impl-calls.cc (region_model::impl_call_analyzer_dump_named_constant): New. * region-model.cc (region_model::on_stmt_pre): Handle __analyzer_dump_named_constant. * region-model.h (region_model::impl_call_analyzer_dump_named_constant): New decl. * sm-fd.cc (fd_state_machine::m_O_ACCMODE): New. (fd_state_machine::m_O_RDONLY): New. (fd_state_machine::m_O_WRONLY): New. (fd_state_machine::fd_state_machine): Initialize the new fields. (fd_state_machine::get_access_mode_from_flag): Use the new fields, rather than using the host values. gcc/c/ChangeLog: PR analyzer/106302 * c-parser.cc: Include "analyzer/analyzer-language.h" and "toplev.h". (class ana::c_translation_unit): New. (c_parser_translation_unit): Call ana::on_finish_translation_unit. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/analyzer-decls.h (__analyzer_dump_named_constant): New decl. * gcc.dg/analyzer/fd-4.c (void): Likewise.
[Bug rust/105914] gccrs setting warn_unused_variable breaks thousands of non-Rust tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105914 Arthur Cohen changed: What|Removed |Added CC||cohenarthur.dev at gmail dot com --- Comment #2 from Arthur Cohen --- Hi there :) This should be fixed now. We decided to enable the warning from within the frontend instead of within the build files.
[Bug fortran/107707] ICE in gfc_compare_actual_formal, at fortran/interface.cc:3284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707 kargl at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 CC||kargl at gcc dot gnu.org Last reconfirmed||2022-11-15 Priority|P3 |P4 Status|UNCONFIRMED |NEW --- Comment #1 from kargl at gcc dot gnu.org --- Another example of why -fmax-errors=1 should be the default. A run-on warning triggers tried to get a gmp value from a BT_REAL entity. Fixed by diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc index d3e199535b3..ce68d863fdf 100644 --- a/gcc/fortran/interface.cc +++ b/gcc/fortran/interface.cc @@ -3271,10 +3271,14 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal, and assumed-shape dummies, the string length needs to match exactly. */ if (a->expr->ts.type == BT_CHARACTER - && a->expr->ts.u.cl && a->expr->ts.u.cl->length + && a->expr->ts.u.cl + && a->expr->ts.u.cl->length + && a->expr->ts.u.cl->length->ts.type == BT_INTEGER && a->expr->ts.u.cl->length->expr_type == EXPR_CONSTANT - && f->sym->ts.type == BT_CHARACTER && f->sym->ts.u.cl + && f->sym->ts.type == BT_CHARACTER + && f->sym->ts.u.cl && f->sym->ts.u.cl->length + && f->sym->ts.u.cl->length->ts.type == BT_INTEGER && f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT && (f->sym->attr.pointer || f->sym->attr.allocatable || (f->sym->as && f->sym->as->type == AS_ASSUMED_SHAPE))
[Bug fortran/107707] New: ICE in gfc_compare_actual_formal, at fortran/interface.cc:3284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707 Bug ID: 107707 Summary: ICE in gfc_compare_actual_formal, at fortran/interface.cc:3284 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p character(3), allocatable :: c c = 'abc' call s(c) contains subroutine s(x) character(real(3)), allocatable :: x end end $ gfortran-13-20221106 -c z1.f90 z1.f90:7:16: 7 | character(real(3)), allocatable :: x |1 Error: Expression at (1) must be of INTEGER type, found REAL f951: internal compiler error: Segmentation fault 0xf4697f crash_signal ../../gcc/toplev.cc:314 0x80de4a gfc_compare_actual_formal(gfc_actual_arglist**, gfc_formal_arglist*, int, int, bool, locus*) ../../gcc/fortran/interface.cc:3284 0x80e5e6 gfc_procedure_use(gfc_symbol*, gfc_actual_arglist**, locus*) ../../gcc/fortran/interface.cc:4167 0x87ad0a resolve_specific_s0 ../../gcc/fortran/resolve.cc:3636 0x87ad0a resolve_specific_s ../../gcc/fortran/resolve.cc:3656 0x87ad0a resolve_call ../../gcc/fortran/resolve.cc:3810 0x87839f gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:12231 0x87a387 resolve_codes ../../gcc/fortran/resolve.cc:17624 0x87a44e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17659 0x862214 resolve_all_program_units ../../gcc/fortran/parse.cc:6631 0x862214 gfc_parse_file() ../../gcc/fortran/parse.cc:6887 0x8b0c8f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug fortran/107706] New: ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:7572
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107706 Bug ID: 107706 Summary: ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:7572 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r13 between 20220925 and 20221009 : $ cat z1.f90 integer function f(i) implicit none integer, value :: i !$omp assume holds(i < g()) block end block f = 3 contains function g() integer :: g(2) g = 4 end end $ gfortran-13-20221106 -c z1.f90 -fopenmp z1.f90:4:30: 4 |!$omp assume holds(i < g()) | 1 internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.cc:7572 0x8b373b gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.cc:7572 0x8a506a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9452 0x8a5462 gfc_conv_expr_op ../../gcc/fortran/trans-expr.cc:3903 0x8a5462 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9448 0x8e8aad gfc_trans_omp_assume ../../gcc/fortran/trans-openmp.cc:4588 0x8e8aad gfc_trans_omp_directive(gfc_code*) ../../gcc/fortran/trans-openmp.cc:7532 0x873e17 trans_code ../../gcc/fortran/trans.cc:2245 0x89d4ce gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7659 0x81f57e translate_all_program_units ../../gcc/fortran/parse.cc:6696 0x81f57e gfc_parse_file() ../../gcc/fortran/parse.cc:7002 0x86ccbf gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug c/107705] New: [12/13 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in ix86_function_type_abi, at config/i386/i386.cc:1529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107705
Bug ID: 107705
Summary: [12/13 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
ix86_function_type_abi, at config/i386/i386.cc:1529
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20210822 and 20210905 :
$ cat z1.c
int f (void)
{
int (*p) (void) = 0;
return p ();
int p = 1;
}
$ gcc-13-20221106 -c z1.c
z1.c: In function 'f':
z1.c:5:7: error: conflicting types for 'p'; have 'int'
5 | int p = 1;
| ^
z1.c:3:9: note: previous definition of 'p' with type 'int (*)(void)'
3 | int (*p) (void) = 0;
| ^
z1.c:4:10: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in ix86_function_type_abi, at
config/i386/i386.cc:1529
4 | return p ();
| ^~~~
0x6aed15 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.cc:8896
0x130184c tree_class_check(tree_node const*, tree_code_class, char const*, int,
char const*)
../../gcc/tree.h:3911
0x130184c ix86_function_type_abi(tree_node const*)
../../gcc/config/i386/i386.cc:1529
0x130373d ix86_return_in_memory
../../gcc/config/i386/i386.cc:4249
0xb289d0 aggregate_value_p(tree_node const*, tree_node const*)
../../gcc/function.cc:2119
0xbbbea5 gimplify_modify_expr_rhs
../../gcc/gimplify.cc:5775
0xbbcb0e gimplify_modify_expr
../../gcc/gimplify.cc:6100
0xbad0f7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16352
0xbb0fd8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7211
0xbabe5e gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.cc:492
0xbabe5e gimplify_return_expr
../../gcc/gimplify.cc:1680
0xbabe5e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16614
0xbb0fd8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7211
0xbac3cb gimplify_statement_list
../../gcc/gimplify.cc:2019
0xbac3cb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16797
0xbb0fd8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7211
0xbb1963 gimplify_bind_expr
../../gcc/gimplify.cc:1430
0xbac8da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16553
0xbb0fd8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7211
0xbb2bde gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:17612
[Bug libstdc++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660
--- Comment #7 from Tomoya Suzuki ---
The following code appears to me to work differently with gcc10 and gcc11.
#include
#include
#include
int kRandSeed = 27491095;
int
main()
{
const int n = 16384;
std::vector v(n);
std::mt19937 rng(kRandSeed);
//std::minstd_rand rng;
for (int i=0; i < n; i++)
v[i] = i;
std::shuffle(v.begin(), v.end(), rng);
for (int i=0; i < n; i++)
printf("%d\n", v[i]);
}
[Bug libstdc++/107701] [13 Regression] static linking broken when using iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107701
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-11-15
--- Comment #1 from Patrick Palka ---
D'oh, not sure how I missed this. For some reason, the ios_base::Init __ioinit
initializer disappears when statically linking.
$ nm libstdc++.a | grep _GLOBAL__sub
t _GLOBAL__sub_I_eh_alloc.cc
t _GLOBAL__sub_I_bitmap_allocator.cc
t _GLOBAL__sub_I.00090_ios_init.cc
t _GLOBAL__sub_I_parallel_settings.cc
t _GLOBAL__sub_I_cxx11_locale_inst.cc
t _GLOBAL__sub_I_cxx11_wlocale_inst.cc
t _GLOBAL__sub_I_future.cc
t _GLOBAL__sub_I_ios_errcat.cc
t _GLOBAL__sub_I_locale_inst.cc
t _GLOBAL__sub_I_system_error.cc
t _GLOBAL__sub_I_wlocale_inst.cc
t _GLOBAL__sub_I_memory_resource.cc
$ ./a.out # g++ -static gcc/testsuite/g++.old-deja/g++.benjamin/15071.C
Segmentation fault
$ nm a.out | grep _GLOBAL__sub
00403c00 t _GLOBAL__sub_I_cxx11_locale_inst.cc
00403c80 t _GLOBAL__sub_I_cxx11_wlocale_inst.cc
00403a10 t _GLOBAL__sub_I_eh_alloc.cc
00403d00 t _GLOBAL__sub_I_ios_errcat.cc
00403890 t _GLOBAL__sub_I_locale_inst.cc
00403d20 t _GLOBAL__sub_I_system_error.cc
00403950 t _GLOBAL__sub_I_wlocale_inst.cc
I'm not sure why some global initializers (notably
_GLOBAL__sub_I.00090_ios_init.cc) are missing in the statically linked
executable vs libstdc++.a?
If we define the __ioinit object in e.g. c++11/ios_errcat.cc instead of
c++98/ios_init.cc then the ios_base::Init initializer runs and static linking
works, not sure why that is.
diff --git a/libstdc++-v3/src/c++11/ios_errcat.cc
b/libstdc++-v3/src/c++11/ios_errcat.cc
index 12192447b8b..aa778810009 100644
--- a/libstdc++-v3/src/c++11/ios_errcat.cc
+++ b/libstdc++-v3/src/c++11/ios_errcat.cc
@@ -76,6 +76,8 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
+#include "../c++98/ios_base_init.h"
+
const error_category&
iostream_category() noexcept
{ return io_category_instance.cat; }
diff --git a/libstdc++-v3/src/c++98/ios_init.cc
b/libstdc++-v3/src/c++98/ios_init.cc
index 4016fcab785..1b5132f1c2d 100644
--- a/libstdc++-v3/src/c++98/ios_init.cc
+++ b/libstdc++-v3/src/c++98/ios_init.cc
@@ -75,8 +75,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
extern wostream wclog;
#endif
-#include "ios_base_init.h"
-
ios_base::Init::Init()
{
if (__gnu_cxx::__exchange_and_add_dispatch(&_S_refcount, 1) == 0)
[Bug target/107704] [13 Regression] Testsuite regression after recent DCE changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 Target||sh CC||rguenth at gcc dot gnu.org
[Bug target/107704] New: [13 Regression] Testsuite regression after recent DCE changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704 Bug ID: 107704 Summary: [13 Regression] Testsuite regression after recent DCE changes Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- This change: commit be2c74fdcd0e8d66c3667008ba2561ab5dcc379b Author: Richard Biener Date: Thu Nov 10 15:04:10 2022 +0100 Make last DCE remove empty loops The following makes the last DCE pass CD-DCE and in turn the last CD-DCE pass a DCE one. That ensues we remove empty loops that become empty between the two. I've also moved the tail-call pass after DCE since DCE can only improve things here. The two testcases were the only ones scanning cddce3 so I've changed them to scan the dce7 pass that's now in this place. The testcases scanning dce7 also work when that's in the earlier position. PR tree-optimization/84646 * tree-ssa-dce.cc (pass_dce::set_pass_param): Add param wheter to run update-address-taken. (pass_dce::execute): Honor it. * passes.def: Exchange last DCE and CD-DCE invocations. Swap pass_tail_calls and the last DCE. * g++.dg/tree-ssa/pr106922.C: Continue to scan earlier DCE dump. * gcc.dg/tree-ssa/20030808-1.c: Likewise. Is causing minor regressions on the sh targets. On sh3-linux-gnu for example: Tests that now fail, but worked before (1 tests): gcc.target/sh/pr51244-19.c scan-assembler-not movt AFAICT this looks like a target issue -- the RTL looks suitable for avoiding the movt, but it doesn't happen for some reason. I didn't consider it important enough to chase down further given the other things on my plate.
[Bug middle-end/107703] New: Some integral to __bf16 conversions and __bf16 to integral conversions are implemented incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107703
Bug ID: 107703
Summary: Some integral to __bf16 conversions and __bf16 to
integral conversions are implemented incorrectly
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
__bf16 f1 (long long x) { return x; }
__bf16 f2 (unsigned long long x) { return x; }
__bf16 f3 (int x) { return x; }
__bf16 f4 (unsigned int x) { return x; }
__bf16 f5 (short x) { return x; }
__bf16 f6 (unsigned short x) { return x; }
__bf16 f7 (signed char x) { return x; }
__bf16 f8 (unsigned char x) { return x; }
__bf16 f9 (__int128 x) { return x; }
__bf16 f10 (unsigned __int128 x) { return x; }
long long f11 (__bf16 x) { return x; }
unsigned long long f12 (__bf16 x) { return x; }
__int128 f13 (__bf16 x) { return x; }
unsigned __int128 f14 (__bf16 x) { return x; }
We implement f1 as DI->XF->BF conversion which is valid I think, because
XFmode can represent all the 63 bits exactly, for f3 SI->DF->BF too,
f5/f7 as {H,Q}I->SF->BF looks ok too.
But for f9/f10 we emit __floattibf/__floatuntibf which aren't implemented in
libgcc and I think they have to.
11 is done as BF->SF->DI which looks good, BF->SF is value preserving
conversion.
But for f12/f13 we emit __fixbfti/__fixunsbfti which again aren't implemented
and I think we need them because __BFLT16_MAX__ is (2^8 − 1) * 2^−7 * 2^127.
[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668
--- Comment #10 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #8)
> While the patch passed bootstrap/regtest, I'm afraid it is not correct.
>
> What we have is lhs = op1 * 0.0; with range of lhs [-0.0, 0.0] and range of
> op2 [0.0, 0.0] and we call fop_mult.op1_range to determine range of op1.
> Now, if it would be HONOR_NANS, the division lhs / op2 aka [-0.0, 0.0] /
> [0.0, 0.0] would compute NAN and float_binary_op_range_finish would take the:
> // If we get a known NAN from reverse op, it means either that
> // the other operand was known NAN (in that case we know nothing),
> // or the reverse operation introduced a known NAN.
> // Say for lhs = op1 * op2 if lhs is [-0, +0] and op2 is too,
> // 0 / 0 is known NAN. Just punt in that case.
> // Or if lhs is a known NAN, we also don't know anything.
> if (r.known_isnan () || lhs.known_isnan ())
> {
> r.set_varying (type);
> return true;
> }
> path. VARYING is the range we want in this case btw, because anything times
> 0.0
> is 0.0 or -0.0 (well, if INF/NANs are honored, we could make it [-MAX, MAX],
> or
> if honoring signed zeros and lhs range would be just [0.0, 0.0] or [-0.0,
> -0.0]
> or op2 one of these it could be even [-MAX, -0.0] or [0.0, MAX].
> But because NANs aren't honored and INFs neither, we get from [-0.0, 0.0] /
> [0.0, 0.0] division UNDEFINED range (NAN with NAN removed).
> So, a safe fix would be to handle r.undefined_p () the same as r.known_isnan
> () or lhs.known_isnan () and if we want to eventually improve the
> op[12]_range
> calls for individual ops for some special cases, we can.
>
> Aldy, thoughts on this?
OMG, head hurts on this one.
Yeah, op1 could have been anything so varying seems like the right thing to do.
I was curious if we were doing something in operator_div::op1_range for
integers, but we haven't even thought that far :).
OK for trunk btw.
[Bug libstdc++/107701] [13 Regression] static linking broken when using iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107701 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||wrong-code
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #5 from Iain Buclaw ---
(In reply to Uroš Bizjak from comment #4)
> from:
> movl%esi, %ecx
> movl$1, %eax
> sall%cl, %eax
> testl %edi, %eax
> setne %al
> movzbl %al, %eax
>
> to:
> xorl%eax, %eax
> btl %esi, %edi
> setc%al
>
> The patch adapts *jcc_bt patterns to similar *scc_bt patterns.
Thanks, have been tinkering with the pointer index version, and found that I
can coax scc_bt_mask to match if I cast the lhs to a signed type. It's not
obvious to me why there would be a difference.
return ((__INT32_TYPE__)p[bitnum >> 5] & (1 << (bitnum & 31))) != 0;
movl%esi, %eax
shrl$5, %eax
movl(%rdi,%rax,4), %eax
btl %esi, %eax
setc%al
Things get even stranger once I expand to "bit test and op" variants though
(better to put in another PR though)
__INT32_TYPE__ btc32(__UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
__INT32_TYPE__ result = ((__INT32_TYPE__)p[bitnum >> 5]
& (1 << (bitnum & 31))) != 0;
p[bitnum >> 5] ^= 1 << (bitnum & 31);
return result;
}
Patch changes code-gen in the following way.
from:
movl%esi, %eax
movl%esi, %ecx
shrl$5, %eax
leaq(%rdi,%rax,4), %rdx
movl(%rdx), %eax
movl%eax, %esi
sarl%cl, %eax
btcl%ecx, %esi
andl$1, %eax
movl%esi, (%rdx)
to:
movl%esi, %eax
shrl$5, %eax
leaq(%rdi,%rax,4), %rdx
movl(%rdx), %eax
movl%eax, %ecx
btcl%esi, %ecx
btl %esi, %eax
setc%al
movl%ecx, (%rdx)
movzbl %al, %eax
[Bug middle-end/107702] New: {,unsigned} __int128 to _Float16 conversion shouldn't use libgcc routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702
Bug ID: 107702
Summary: {,unsigned} __int128 to _Float16 conversion shouldn't
use libgcc routines
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Seems for {,unsigned} __int128 to _Float16 conversions we always at least on
x86_64 emit __floattihf calls.
_Float16 f1 (long long x) { return x; }
_Float16 f2 (unsigned long long x) { return x; }
_Float16 f3 (int x) { return x; }
_Float16 f4 (unsigned int x) { return x; }
_Float16 f5 (short x) { return x; }
_Float16 f6 (unsigned short x) { return x; }
_Float16 f7 (signed char x) { return x; }
_Float16 f8 (unsigned char x) { return x; }
_Float16 f9 (__int128 x) { return x; }
_Float16 f10 (__int128 x) { return x; }
_Float32 f11 (long long x) { return x; }
_Float32 f12 (unsigned long long x) { return x; }
_Float32 f13 (int x) { return x; }
_Float32 f14 (unsigned int x) { return x; }
_Float32 f15 (short x) { return x; }
_Float32 f16 (unsigned short x) { return x; }
_Float32 f17 (signed char x) { return x; }
_Float32 f18 (unsigned char x) { return x; }
_Float32 f19 (__int128 x) { return x; }
_Float32 f20 (__int128 x) { return x; }
Any reason for that? _Float16 range is -65504 to 65504 (65504 is
__FLT16_MAX__), and
int
main ()
{
for (int i = 0; i < 65504; ++i)
{
volatile __int128 j = i;
_Float16 a = j;
_Float16 b = (float) i;
if (a != b)
__builtin_printf ("%d %a %a\n", i, (double) a, (double) b);
}
}
verifies that the __floattihf implementation always gives the same answer as
does signed SImode -> SFmode cast followed by SFmode -> HFmode conversion.
Isn't a conversion of a value > 65504 && value < -65504 UB in both C and C++?
So, can't we just implement the TI -> HF conversions by say ignoring upper 64
bits of the __int128?
[Bug libstdc++/107701] New: [13 Regression] static linking broken when using iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107701 Bug ID: 107701 Summary: [13 Regression] static linking broken when using iostream Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: ppalka at gcc dot gnu.org Target Milestone: --- Since r13-3707-g4e4e3ffd10f53e, static linking with iostreams has been broken. This affects most "embedded" targets (the "*-elf" and "*-eabi" ones; the "vast majority" that don't do dynamic linking) but also plain -static. For a repeater, run "make check-gcc-c++ 'RUNTESTFLAGS=--target_board=unix/-static old-deja.exp=15071.C'" a trivial test-case which just does cout << "hi" << endl;. This works before r13-3707-g4e4e3ffd10f53e but SEGV's afterwards, in my case "Debian 11" x86_64, but expected to manifest on any native build. (BTW, looks like we miss a specific test-case exercising static linking at least with iostreams.)
[Bug rust/107700] New: Several testsuite failures on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107700 Bug ID: 107700 Summary: Several testsuite failures on SPARC Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Host: sparc*-sun-solaris2.11 Target: sparc*-sun-solaris2.11 Build: sparc*-sun-solaris2.11 Once I'd worked around PR rust/107633, I'd found a couple of testsuite failures on Solaris/SPARC: * 32 and 64-bit: FAIL: rust/compile/const-issue1440.rs at line 49 (test for errors, line 48) FAIL: rust/compile/const-issue1440.rs at line 61 (test for errors, line 60) FAIL: rust/compile/const-issue1440.rs (test for excess errors) Excess errors: /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:41:44: error: expected 'u8' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:53:55: error: expected 'u8' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:41:44: error: expected 'u16' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:53:55: error: expected 'u16' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:41:44: error: expected 'u32' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:53:55: error: expected 'u32' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:41:44: error: expected 'u64' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:53:55: error: expected 'u64' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:41:44: error: expected 'u128' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:53:55: error: expected 'u128' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:41:44: error: expected 'usize' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/const-issue1440.rs:53:55: error: expected 'usize' got '()' The test lacks big-endian support. FAIL: rust/compile/torture/issue-1432.rs -O0 (test for excess errors) FAIL: rust/compile/torture/issue-1432.rs -O1 (test for excess errors) FAIL: rust/compile/torture/issue-1432.rs -O2 (test for excess errors) FAIL: rust/compile/torture/issue-1432.rs -O2 -flto (test for excess errors) FAIL: rust/compile/torture/issue-1432.rs -O2 -flto -flto-partition=none (test for excess errors) FAIL: rust/compile/torture/issue-1432.rs -O3 -g (test for excess errors) FAIL: rust/compile/torture/issue-1432.rs -Os (test for excess errors) Excess errors: /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:45:44: error: expected 'u8' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:56:55: error: expected 'u8' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:45:44: error: expected 'u16' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:56:55: error: expected 'u16' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:45:44: error: expected 'u32' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:56:55: error: expected 'u32' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:45:44: error: expected 'u64' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:56:55: error: expected 'u64' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:45:44: error: expected 'usize' got '()' /vol/gcc/src/hg/master/rust/gcc/testsuite/rust/compile/torture/issue-1432.rs:56:55: error: expected 'usize' got '()' Again no big-endian support. * 32-bit only: FAIL: rust/execute/torture/builtin_macros1.rs -O0 output pattern test FAIL: rust/execute/torture/builtin_macros1.rs -O1 output pattern test FAIL: rust/execute/torture/builtin_macros1.rs -O2 output pattern test FAIL: rust/execute/torture/builtin_macros1.rs -O2 -flto output pattern test FAIL: rust/execute/torture/builtin_macros1.rs -O2 -flto -flto-partition=none output pattern test FAIL: rust/execute/torture/builtin_macros1.rs -O3 -g output pattern test FAIL: rust/execute/torture/builtin_macros1.rs -Os output pattern test Output was: Should match: rust/execute/torture/builtin_macros1.rs already in 20220118 build FAIL: rust/execute/torture/loop-condition-eval.rs -O0 output pattern test FAIL: rust/execute/torture/loop-condition-eval.rs -O1 output pattern test FAIL: rust/execute/torture/loop-condition-eval.rs -O2 output pattern test FAIL:
[Bug c++/99625] GCC does not detect narrowing in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99625 --- Comment #5 from Giuseppe D'Angelo --- No problem, thanks for working on GCC :)
[Bug c++/99625] GCC does not detect narrowing in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99625 --- Comment #4 from Marek Polacek --- (In reply to Giuseppe D'Angelo from comment #3) > Hi, > > Sorry to ping, but some time has gone by -- I guess this fell through the > cracks? Yes, it did. Sorry. :-(
[Bug c++/107638] [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638 --- Comment #5 from Jan-Benedict Glaw --- All my affected builds are restored.
[Bug sanitizer/107698] ASAN misses a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107698 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-11-15 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Martin Liška --- I think it's a variation of https://github.com/google/sanitizers/issues/869, but I will take a look deeper.
[Bug c++/99625] GCC does not detect narrowing in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99625 --- Comment #3 from Giuseppe D'Angelo --- Hi, Sorry to ping, but some time has gone by -- I guess this fell through the cracks?
[Bug libstdc++/107693] undefined reference to `_ZSt8to_charsPcS_DF128_St12chars_formati' std::format does not work on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107693 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jonathan Wakely --- Fixed. __float128 is not formattable on this target.
[Bug libstdc++/107693] undefined reference to `_ZSt8to_charsPcS_DF128_St12chars_formati' std::format does not work on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107693 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ce86d9678b7f3d914133a035fbf8088504d8bad8 commit r13-4059-gce86d9678b7f3d914133a035fbf8088504d8bad8 Author: Jonathan Wakely Date: Tue Nov 15 13:44:38 2022 + libstdc++: Fix detection of std::format support for __float128 [PR107693] std::format gives linker errors on targets that define __float128 but do not support using it with std::to_chars. This improves the handling of 128-bit flaoting-point types so they are disabled if unsupportable. libstdc++-v3/ChangeLog: PR libstdc++/107693 * include/std/format (_GLIBCXX_FORMAT_F128): Define to 2 when basic_format_arg needs to use its _M_f128 member. (__extended_floating_point, __floating_point): Replace with ... (__formattable_floating_point): New concept. * testsuite/std/format/functions/format.cc: Check whether __float128 is supported. Also test _Float128.
[Bug target/107665] g++.dg/cpp23/ext-floating1.C fails after r13-3387-g79d38dd46e6b07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107665
--- Comment #2 from Jakub Jelinek ---
Strange.
When I try with a cross to powerpc64le-linux simplified:
namespace std
{
template struct integral_constant {
static constexpr T value = v;
};
typedef integral_constant false_type;
typedef integral_constant true_type;
template
struct is_same : std::false_type {};
template
struct is_same : std::true_type {};
}
static_assert (std::is_same::value);
out of this, I get with any of
-std=gnu++23 -mlong-double-{64,128 -mabi={ieee,ibm}longdouble}
a successful compilation.
So, what type do you get instead?
static machine_mode
rs6000_c_mode_for_suffix (char suffix)
{
if (TARGET_FLOAT128_TYPE)
{
if (suffix == 'q' || suffix == 'Q')
return (FLOAT128_IEEE_P (TFmode)) ? TFmode : KFmode;
/* At the moment, we are not defining a suffix for IBM extended double.
If/when the default for -mabi=ieeelongdouble is changed, and we want
to support __ibm128 constants in legacy library code, we may need to
re-evalaute this decision. Currently, c-lex.cc only supports 'w' and
'q' as machine dependent suffixes. The x86_64 port uses 'w' for
__float80 constants. */
}
return VOIDmode;
}
should return TFmode or KFmode and the c-family code should prefer
float128t_type_node over float128_type_node for the q/w suffixes.
[Bug c++/107697] -Wredundant-move misses std::move applied to const objects (instead of const references)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107697 --- Comment #2 from Marek Polacek --- I guess this is GCC 14 material at this point.
[Bug c++/107697] -Wredundant-move misses std::move applied to const objects (instead of const references)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107697
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Keywords||diagnostic
Ever confirmed|0 |1
CC||mpolacek at gcc dot gnu.org
Last reconfirmed||2022-11-15
--- Comment #1 from Marek Polacek ---
Confirmed. Currently the code does only:
/* Also try to warn about redundant std::move in code such as
T f (const T& t)
{
return std::move(t);
}
[Bug c++/107699] New: False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
Bug ID: 107699
Summary: False positive -Warray-bounds, non-existent offset
reported by GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi,
The following code:
#include
#include
std::size_t getCount();
int foo()
{
std::array data{3, 2, 1};
std::sort(data.begin(), data.begin() + getCount());
return data.front();
}
Built with -Wall -O3 triggers:
In file included from
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/algorithm:61,
from :2:
In function 'void std::__final_insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]',
inlined from 'void std::__final_insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]' at
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:1854:5,
inlined from 'void std::__sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]' at
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:1950:31,
inlined from 'void std::__sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]' at
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:1942:5,
inlined from 'void std::sort(_RAIter, _RAIter) [with _RAIter = int*]' at
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:4860:18,
inlined from 'int foo()' at :9:14:
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:1859:32:
warning: array subscript 16 is outside array bounds of 'std::array [1]'
[-Warray-bounds]
1859 | std::__insertion_sort(__first, __first + int(_S_threshold),
__comp);
|
~^~
: In function 'int foo()':
:8:24: note: at offset 64 into object 'data' of size 12
8 | std::array data{3, 2, 1};
|^~~~
Compiler returned: 0
Repro: https://godbolt.org/z/Ma8KK1MKE
There is nowhere in the code any "offset 64". The compiler cannot possibly know
if there is OOB or not, since that depends on the function "getCount" which is
implemented in a separate translation unit.
Therefore the warning violates what the documentation says:
"It warns about subscripts to arrays that are always out of bounds"
This is not true in this case. It's not "always" out of bounds.
[Bug sanitizer/107698] New: ASAN misses a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107698
Bug ID: 107698
Summary: ASAN misses a global-buffer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, `gcc-trunk -O1 -fsanitize=address` misses the
global-buffer-overflow, while `gcc-trunk -Ox -fsanitize=address` (x=0,2,3, or
s) can detect it.
clang can detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/5Tcjrc4zf
% cat a.c
int a=0, d=1;
int *b = , *c =
int main() {
*b = 0;
b = b + 1;
*c = 1;
*b = d;
}
%
% gcc-tk -O1 -fsanitize=address a.c && ./a.out
%
% gcc-tk -O3 -fsanitize=address a.c && ./a.out
=
==851733==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00404284 at pc 0x00401130 bp 0x7ffd4cb2a6a0 sp 0x7ffd4cb2a698
WRITE of size 4 at 0x00404284 thread T0
#0 0x40112f in main
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/work119_1/a.c:7
#1 0x7fb79dc33082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40119d in _start
(/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/work119_1/a.out+0x40119d)
0x00404284 is located 0 bytes to the right of global variable 'a' defined
in 'a.c:1:5' (0x404280) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/work119_1/a.c:7 in main
Shadow bytes around the buggy address:
0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9
0x80078810: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
0x80078820: f9 f9 f9 f9 00 00 00 00 00 00 00 00 f9 f9 f9 f9
0x80078830: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x80078840: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
=>0x80078850:[04]f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800788a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==851733==ABORTING
%
[Bug modula2/107629] runtime libs don't link on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107629 --- Comment #1 from Rainer Orth --- Created attachment 53903 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53903=edit Initial patch This patch allowed me to finish the libgm2 build on macOS. As usuual, it contains only the non-generated parts. Again, it would be better to centralize this to avoid adding to the current duplication with libcc1, libitm, and libsanitizer.
[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107696 --- Comment #4 from Li Shaohua --- Thanks for the prompt reply.
[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612 --- Comment #2 from Rainer Orth --- Created attachment 53902 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53902=edit Initial patch The attached patch allowed the plugin to build on macOS. I'm not really happy about it for a couple of reasons: * It duplicates code that would better be imported from config/gcc-plugin.m4 (or moved there, like soext). libcc1/configure.ac and Makefile.am have yet another instance, conditional on DARWIN_DYNAMIC_LOOKUP. This permanent (partial) duplication is one primary problem of some areas of the GCC code base. * config/gcc-plugin.m4 should use config/picflag.m4 both to avoid duplicating PICFLAG and messing around with CFLAGS/CXXFLAGS to remove -mdynamic-pic with sed. Instead, it would adding -mno-cynamic-no-pic for free (and only in one place), and could easily export something like PLUGINCFLAGS/PLUGiNCXXFLAGS and add PLUGINLDFLAGS, preferable AC_SUBST'ing those itself instead of having the callers do it. I've now idea if such a patch would be acceptable in stage 3, though. PICLDFLAGS
[Bug c++/107697] New: -Wredundant-move misses std::move applied to const objects (instead of const references)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107697
Bug ID: 107697
Summary: -Wredundant-move misses std::move applied to const
objects (instead of const references)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
Consider this testcase:
#include
using T = std::vector;
void f(T);
void use1(const T t) { f(std::move(t)); }
void use2(const T ) { f(std::move(t)); }
void use3() {
const T t;
f(std::move(t));
}
Currently -Wredundant-move warns only for case 2. But in all three cases
std::move is actually not doing anything good (copy constructor is always
selected). It would be nice if they all were diagnosed.
If I change `f` to `void f(const T &)` then there's no warning at all. I'm
thinking that probably this case should be diagnosed as well.
Clang-tidy's performance-move-const-arg diagnoses them all.
[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107696 --- Comment #3 from Martin Liška --- So here again depends on the order of stack variables and a[4] is a valid access to 'b' variable, see what happens with a[6]: = ==6539==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffd5f8 at pc 0x00401291 bp 0x7fffd590 sp 0x7fffd588 WRITE of size 4 at 0x7fffd5f8 thread T0 #0 0x401290 in main (/home/marxin/Programming/testcases/a.out+0x401290) #1 0x7762c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af) #2 0x7762c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678) #3 0x4010c4 in _start ../sysdeps/x86_64/start.S:115 Address 0x7fffd5f8 is located in stack of thread T0 at offset 72 in frame #0 0x4011a5 in main (/home/marxin/Programming/testcases/a.out+0x4011a5) This frame has 2 object(s): [48, 52) 'a' (line 3) [64, 72) 'b' (line 2) <== Memory access at offset 72 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/marxin/Programming/testcases/a.out+0x401290) in main Shadow bytes around the buggy address: 0x10007fff7a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7a90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x10007fff7ab0: 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 04 f2 00[f3] 0x10007fff7ac0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107696
--- Comment #2 from Li Shaohua ---
(In reply to Martin Liška from comment #1)
> > int i;
> > int a[1];
> > for (; i < 1;){
>
> This depends on the uninitialized value of 'i', which is:
>
> (gdb) p i
> $1 = 32767
>
> if I run it with -O0 on my local machine. You can try
> -ftrivial-auto-var-init=zero.
Sorry, I over-reduced the test, for the following new test, I can still observe
the inconsistent results across optimization levels:
Compiler explorer: https://godbolt.org/z/b7x9zx5Ej
% cat a.c
int main() {
int b[2];
int a[1];
int i;
for (i=0; i < 1; i++)
i = i + 3;
a[i] = 1;
}
%
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671 --- Comment #4 from Uroš Bizjak --- Created attachment 53901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53901=edit Patch that adds relevant zero_extract patterns This patch adds relevant zero_extract patterns that optimize: return ((v & (1 << (bitnum & 31 != 0; return ((v & (1L << (bitnum & 63 != 0; return (v >> (bitnum & 31)) & 1; return (v >> (bitnum & 63)) & 1; from: movl%esi, %ecx movl$1, %eax sall%cl, %eax testl %edi, %eax setne %al movzbl %al, %eax to: xorl%eax, %eax btl %esi, %edi setc%al The patch adapts *jcc_bt patterns to similar *scc_bt patterns. Please note that the patch optimizes only to SETB conditional set instruction, since it builds on a combine transformation to the ZERO_EXTRACT rtx.
[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677 --- Comment #5 from Carlos Galvez --- Wow, that was mind blowing, thanks for the clarification! Such thing I'd like to have in the docs, it's very easy to confuse with the other message: note: at offset 48 into object '' of size 48 So one offset is an actual index, and the other is a "mathematical range of indices". Back to my example: error: array subscript [-536870912, -1] is outside array bounds I don't see these numbers in my code. Therefore I wonder: how does GCC compute these numbers? Are they based on my code, or are they based on: "if the user pass you the number -536870912 as input at runtime, then you'll do out-of-bounds"?
[Bug c++/98822] [CWG2596] Rejects-valid: instantiation of class template instantiates (all) constrained non-template friend definitions (, even those) with unsatisfied constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98822 Patrick Palka changed: What|Removed |Added Alias||cwg2596 Summary|Rejects-valid: |[CWG2596] Rejects-valid: |instantiation of class |instantiation of class |template instantiates (all) |template instantiates (all) |constrained non-template|constrained non-template |friend definitions (, even |friend definitions (, even |those) with unsatisfied |those) with unsatisfied |constraints |constraints Blocks||94404 --- Comment #4 from Patrick Palka --- >From r13-4035-gc41bbfcaf9d6ef: commit c41bbfcaf9d6ef5b57a7e89bba70b861c08a686b Date: Fri Nov 11 00:45:02 2022 -1000 c++: only declare satisfied friends A friend declaration can only have constraints if it is defined. If multiple instantiations of a class template define the same friend function signature, it's an error, but that shouldn't happen if it's constrained to only be declared in one instantiation. Currently we don't mangle requirements, so the foos all mangle the same and actually instantiating #1 will break, but for now we can test that they're considered distinct. gcc/cp/ChangeLog: * pt.cc (tsubst_friend_function): Check satisfaction. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-friend11.C: New test. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 [Bug 94404] [meta-bug] C++ core issues
[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677 --- Comment #4 from Andrew Pinski --- Note range syntax of [a, b] is math syntax not to be confused with array deference syntax of c.
[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107696
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Martin Liška ---
> int i;
> int a[1];
> for (; i < 1;){
This depends on the uninitialized value of 'i', which is:
(gdb) p i
$1 = 32767
if I run it with -O0 on my local machine. You can try
-ftrivial-auto-var-init=zero.
[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677 --- Comment #3 from Carlos Galvez --- The warning message is also hard to decipher. For example, what does this mean? error: array subscript [-536870912, -1] is outside array bounds What is a 2-dimensional subscript applied on a 1D array?
[Bug sanitizer/107696] New: GCC trunk misses a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107696
Bug ID: 107696
Summary: GCC trunk misses a stack-buffer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, `gcc-trunk -O0 -fsanitize=address` misses the
stack-buffer-overflow, while `gcc-trunk -Ox -fsanitize=address` (x=1,2,3, or s)
can detect it.
clang can detect it at all optimization levels.
gcc-8 can detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/z18Kzhxq5
% cat a.c
int main() {
int i;
int a[1];
for (; i < 1;){
i = 2;
a[i] = 1;
}
__builtin_printf("%d\n", a[i]);
}
%
% gcc-tk -O0 -fsanitize=address a.c &&./a.out
0
% gcc-tk -O3 -fsanitize=address a.c &&./a.out
=
==1940238==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7f9590400028 at pc 0x00401147 bp 0x7fff56ba4240 sp 0x7fff56ba4238
READ of size 4 at 0x7f9590400028 thread T0
#0 0x401146 in main
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.c:8
#1 0x7f9592de7082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4011dd in _start
(/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.out+0x4011dd)
Address 0x7f9590400028 is located in stack of thread T0 at offset 40 in frame
#0 0x4010bf in main
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.c:1
This frame has 1 object(s):
[32, 36) 'a' (line 3) <== Memory access at offset 40 overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.c:8 in
main
Shadow bytes around the buggy address:
0x0ff332077fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332077fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332077fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332077fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332077ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff332078000: f1 f1 f1 f1 04[f3]f3 f3 00 00 00 00 00 00 00 00
0x0ff332078010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332078020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332078030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332078040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332078050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==1940238==ABORTING
%
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7ca912b46e0eb45ebefeb0eda4c28afe1513d272/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7ca912b46e0eb45ebefeb0eda4c28afe1513d272
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221108 (experimental) (GCC)
%
[Bug target/107692] [13 regression] r13-3950-g071e428c24ee8c breaks many test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 --- Comment #3 from Segher Boessenkool --- Hi! (In reply to Hongyu Wang from comment #2) > I've tested the patch with cross-compler and all the fails disappeared, but > I don't have a powerpc to do full bootstrap & regtest (I'm still applying > for gcc farm account). [ I approved that account ] -munroll-only-small-loops does not turn on or off -funroll-loops, and it should not, so that it does what it says, if nothing else. We do not want -frename-registers either (at -O2 at least), it hurts performance.
[Bug libstdc++/107693] undefined reference to `_ZSt8to_charsPcS_DF128_St12chars_formati' std::format does not work on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107693 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |13.0 Ever confirmed|0 |1 Last reconfirmed||2022-11-15 --- Comment #3 from Jonathan Wakely --- It's just a bug in the macro definitions in , we don't have std::to_chars for _Float128 for mingw so shouldn't try to support it in std::format. I have a patch already.
[Bug fortran/107695] New: Non conforming shape during assignment is not detected at run-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107695 Bug ID: 107695 Summary: Non conforming shape during assignment is not detected at run-time Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: edouard.ca...@univ-rennes1.fr Target Milestone: --- Created attachment 53900 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53900=edit Fortran test program which reveals the bug At run-time, the attached program leads to memory problems (only detected by valgrind). It is compiled by the following command: $ gfortran -fbounds-check -g -o test test.f90 The bug occurs at least for GCC versions from 8.5 to 12.2 In the following assignment: z(ind,ind) = data(:,:) I thought that data is recognized as a scalar (shape is [1,1]) and its value spread to the four elements of z. This is not the case. However: z(ind,ind) = data(1,1) gives the correct result as expected. Of course, the problem cannot be detected at compile-time since both 'z' and 'data' arrays are allocatable.
[Bug fortran/107680] ICE in arith_power, at fortran/arith.cc:989 and :1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- I thought the call to gfc_type_convert_binary in eval_intrinsic was taking care of mismatching types, doesn't it?
[Bug tree-optimization/107326] [13 Regression] ICE: verify_gimple failed (error: type mismatch in binary expression) since r13-3219-g25413fdb2ac249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326 avieira at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from avieira at gcc dot gnu.org --- Closing this then.
[Bug libstdc++/107693] undefined reference to `_ZSt8to_charsPcS_DF128_St12chars_formati' std::format does not work on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107693 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Can you retry without LTO, so that it is clearer where the undefined references come from? from_chars/to_chars is on Linux supported even for _Float128. readelf -Wrs libstdc++.a | grep DF128_ | grep -v '\.text\.' Relocation section '.rela.gcc_except_table._ZNSt12_GLOBAL__N_117from_chars_strtodIDF128_EESt17from_chars_resultPKcS3_RT_St12chars_format' at offset 0x67ce0 contains 2 entries: 00013b0d 00540001 R_X86_64_64 .rodata._ZNSt12_GLOBAL__N_117from_chars_strtodIDF128_EESt17from_chars_resultPKcS3_RT_St12chars_format.str1.1 + 0 00014a08 00540001 R_X86_64_64 .rodata._ZNSt12_GLOBAL__N_117from_chars_strtodIDF128_EESt17from_chars_resultPKcS3_RT_St12chars_format.str1.1 + 0 0861 00580002 R_X86_64_PC32 .gcc_except_table._ZNSt12_GLOBAL__N_117from_chars_strtodIDF128_EESt17from_chars_resultPKcS3_RT_St12chars_format + 0 08b5 00580002 R_X86_64_PC32 .gcc_except_table._ZNSt12_GLOBAL__N_117from_chars_strtodIDF128_EESt17from_chars_resultPKcS3_RT_St12chars_format + 14 84: 0 SECTION LOCAL DEFAULT 81 .rodata._ZNSt12_GLOBAL__N_117from_chars_strtodIDF128_EESt17from_chars_resultPKcS3_RT_St12chars_format.str1.1 87: 730 FUNCLOCAL DEFAULT 84 _ZNSt12_GLOBAL__N_117from_chars_strtodIDF128_EESt17from_chars_resultPKcS3_RT_St12chars_format 88: 0 SECTION LOCAL DEFAULT 86 .gcc_except_table._ZNSt12_GLOBAL__N_117from_chars_strtodIDF128_EESt17from_chars_resultPKcS3_RT_St12chars_format 89: 26 FUNCLOCAL DEFAULT 82 _ZNSt12_GLOBAL__N_117from_chars_strtodIDF128_EESt17from_chars_resultPKcS3_RT_St12chars_format.cold 182: 9 FUNCGLOBAL DEFAULT 88 _ZSt10from_charsPKcS0_RDF128_St12chars_format 00029bb0 00470001 R_X86_64_64 .rodata._ZSt29__floating_to_chars_precisionIDF128_ESt15to_chars_resultPcS1_T_St12chars_formati.str1.1 + 0 00029c0d 00470001 R_X86_64_64 .rodata._ZSt29__floating_to_chars_precisionIDF128_ESt15to_chars_resultPcS1_T_St12chars_formati.str1.1 + 0 00037ed9 00630001 R_X86_64_64 .rodata._ZSt28__floating_to_chars_shortestIDF128_ESt15to_chars_resultPcS1_T_St12chars_format.part.0.str1.1 + 0 00037f25 00630001 R_X86_64_64 .rodata._ZSt28__floating_to_chars_shortestIDF128_ESt15to_chars_resultPcS1_T_St12chars_format.part.0.str1.1 + 0 07dd 00730002 R_X86_64_PC32 .gcc_except_table._ZSt8to_charsPcS_DF128_ + 0 07f9 00750002 R_X86_64_PC32 .gcc_except_table._ZSt8to_charsPcS_DF128_St12chars_format + 0 081d 00770002 R_X86_64_PC32 .gcc_except_table._ZSt8to_charsPcS_DF128_St12chars_formati + 0 9: 670 FUNCLOCAL DEFAULT 14 _ZSt22__handle_special_valueIDF128_ESt8optionalISt15to_chars_resultEPcS3_T_St12chars_formati 70: 1997 FUNCLOCAL DEFAULT 69 _ZSt23__floating_to_chars_hexIDF128_ESt15to_chars_resultPcS1_T_St8optionalIiE.isra.0 71: 0 SECTION LOCAL DEFAULT 71 .rodata._ZSt29__floating_to_chars_precisionIDF128_ESt15to_chars_resultPcS1_T_St12chars_formati.str1.1 73: 1731 FUNCLOCAL DEFAULT 72 _ZSt29__floating_to_chars_precisionIDF128_ESt15to_chars_resultPcS1_T_St12chars_formati 99: 0 SECTION LOCAL DEFAULT 92 .rodata._ZSt28__floating_to_chars_shortestIDF128_ESt15to_chars_resultPcS1_T_St12chars_format.part.0.str1.1 101: 5211 FUNCLOCAL DEFAULT 93 _ZSt28__floating_to_chars_shortestIDF128_ESt15to_chars_resultPcS1_T_St12chars_format.part.0 115: 0 SECTION LOCAL DEFAULT 114 .gcc_except_table._ZSt8to_charsPcS_DF128_ 117: 0 SECTION LOCAL DEFAULT 117 .gcc_except_table._ZSt8to_charsPcS_DF128_St12chars_format 119: 0 SECTION LOCAL DEFAULT 120 .gcc_except_table._ZSt8to_charsPcS_DF128_St12chars_formati 252: 20 FUNCGLOBAL DEFAULT 112 _ZSt8to_charsPcS_DF128_ 255: 47 FUNCGLOBAL DEFAULT 115 _ZSt8to_charsPcS_DF128_St12chars_format 256: 18 FUNCGLOBAL DEFAULT 118 _ZSt8to_charsPcS_DF128_St12chars_formati But the intent was that this would be only enabled if long double is the mode as _Float128, or for
[Bug libstdc++/106676] [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Last reconfirmed||2022-11-15 Resolution|INVALID |--- --- Comment #4 from Jonathan Wakely --- Reopening.
[Bug other/107694] New: Bogus stringop-overflow warning in gcc 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107694
Bug ID: 107694
Summary: Bogus stringop-overflow warning in gcc 12
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
Reproducer:
```
#include
class nsISupports {
public:
virtual int Release();
};
struct JSPrincipals {
std::atomic refcount;
};
class nsJSPrincipals : nsISupports, JSPrincipals {
static nsJSPrincipals* get(JSPrincipals* principals) {
return static_cast(principals);
}
void Destroy(JSPrincipals* jsprin);
};
void nsJSPrincipals::Destroy(JSPrincipals* jsprin) {
nsJSPrincipals* nsjsprin = nsJSPrincipals::get(jsprin);
nsjsprin->refcount.fetch_add(1, std::memory_order_acq_rel);
nsjsprin->Release();
}
```
Compile with: g++ -c -O2 -Werror=stringop-overflow
It says:
```
In file included from /builds/worker/fetches/gcc/include/c++/12.2.0/atomic:41,
from Unified_cpp_caps0.ii.cpp:1:
In member function 'std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::fetch_add(__int_type, std::memory_order) [with _ITp
= int]',
inlined from 'void nsJSPrincipals::Destroy(JSPrincipals*)' at
Unified_cpp_caps0.ii.cpp:19:30:
/builds/worker/fetches/gcc/include/c++/12.2.0/bits/atomic_base.h:618:34: error:
'unsigned int __atomic_fetch_add_4(volatile void*, unsigned int, int)' writing
4 bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
618 | { return __atomic_fetch_add(&_M_i, __i, int(__m)); }
|~~^~
cc1plus: some warnings being treated as errors
```
