[Bug tree-optimization/109571] potential null pointer dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571 --- Comment #3 from Frank Heckenbach --- Thanks for the explanation, that was really helpful. If I understand it correctly, since B has a vtable and A doesn't, upcasting means to add some offset to the pointer, but of course not if it's null. That's why null has to be special-cased which leads to the warning in one branch. (Since the compiler can't see that I won't actually put any null pointers there.) Now I know what to watch out for if I get more such warnings.
[Bug target/108812] gcc.target/powerpc/p9-sign_extend-runnable.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108812 --- Comment #2 from CVS Commits --- The releases/gcc-12 branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:a8f45d61caba90649b3f264babab17353d774751 commit r12-9460-ga8f45d61caba90649b3f264babab17353d774751 Author: Haochen Gui Date: Fri Apr 21 10:11:32 2023 +0800 rs6000: correct vector sign extend builtins on Big Endian gcc/ PR target/108812 * config/rs6000/vsx.md (vsx_sign_extend_qi_): Rename to... (vsx_sign_extend_v16qi_): ... this. (vsx_sign_extend_hi_): Rename to... (vsx_sign_extend_v8hi_): ... this. (vsx_sign_extend_si_v2di): Rename to... (vsx_sign_extend_v4si_v2di): ... this. (vsignextend_qi_): Remove. (vsignextend_hi_): Remove. (vsignextend_si_v2di): Remove. (vsignextend_v2di_v1ti): Remove. (*xxspltib__split): Replace gen_vsx_sign_extend_qi_v2di with gen_vsx_sign_extend_v16qi_v2di and gen_vsx_sign_extend_qi_v4si with gen_vsx_sign_extend_v16qi_v4si. * config/rs6000/rs6000.md (split for DI constant generation): Replace gen_vsx_sign_extend_qi_si with gen_vsx_sign_extend_v16qi_si. (split for HSDI constant generation): Replace gen_vsx_sign_extend_qi_di with gen_vsx_sign_extend_v16qi_di and gen_vsx_sign_extend_qi_si with gen_vsx_sign_extend_v16qi_si. * config/rs6000/rs6000-builtins.def (__builtin_altivec_vsignextsb2d): Set bif-pattern to vsx_sign_extend_v16qi_v2di. (__builtin_altivec_vsignextsb2w): Set bif-pattern to vsx_sign_extend_v16qi_v4si. (__builtin_altivec_visgnextsh2d): Set bif-pattern to vsx_sign_extend_v8hi_v2di. (__builtin_altivec_vsignextsh2w): Set bif-pattern to vsx_sign_extend_v8hi_v4si. (__builtin_altivec_vsignextsw2d): Set bif-pattern to vsx_sign_extend_si_v2di. (__builtin_altivec_vsignext): Set bif-pattern to vsx_sign_extend_v2di_v1ti. * config/rs6000/rs6000-builtin.cc (lxvrse_expand_builtin): Replace gen_vsx_sign_extend_qi_v2di with gen_vsx_sign_extend_v16qi_v2di, gen_vsx_sign_extend_hi_v2di with gen_vsx_sign_extend_v8hi_v2di and gen_vsx_sign_extend_si_v2di with gen_vsx_sign_extend_v4si_v2di. gcc/testsuite/ PR target/108812 * gcc.target/powerpc/p9-sign_extend-runnable.c: Set corresponding expected vectors for Big Endian. * gcc.target/powerpc/int_128bit-runnable.c: Likewise. (cherry picked from commit a213e2c965382c24fe391ee5798effeba8da0fdf)
[Bug target/109535] [13/14] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535 --- Comment #14 from JuzheZhong --- (In reply to Mathieu Malaterre from comment #12) > @JuzheZhong > > Technically you are supposed to simply remove the keyword '14' from the > title and close when backported on 13... Thank you for correcting me. I reopen this bug and let wait for kito backport to GCC 13 to close this bug. Thanks.
[Bug tree-optimization/109581] [13/14 Regression] Comparing with -HUGE_VAL wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581 --- Comment #3 from Daniel Schürmann --- I can confirm that -fno-finite-math-only fixes the issue. Since this a new behavior in GCC 13 and it is also a hard to find issue, which took us many hours to dig it down, it would be nice tho have at least a warning something like: warning: comparison of infinity constant is always false. The issue is that this happens silently after a compiler update. It can cause real live issues, but is only recognized by a chance in a big code base. Is there a use case of explicit compare with HUGE_VAL/-HUGE_VAL and than disable it with -ffinite-math-only?
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 --- Comment #4 from Jeffrey A. Law --- Vineet, we've got some bits here you might want to play with. I'm about to leave for the evening, but I'll put you in touch with Raphael tomorrow afternoon.
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 --- Comment #3 from Vineet Gupta --- Debugging of ctz3 case The insns of interest are: insn_cost 4 for 6: r74:SI=ctz(r73:DI#0) REG_DEAD r73:DI insn_cost 4 for 7: r72:DI=sign_extend(r74:SI) REG_DEAD r74:SI Before the commit in question, combine is able to mush them allowing combination of insns 6 and 7 original costs 4 + 4 = 8 replacement cost 8 deferring deletion of insn with uid = 6. modifying insn i3 7: r72:DI=sign_extend(ctz(r76:DI#0)) With the commit in questions, it takes the new code patch introduced combine_simplify_rtx simplify_context::simplify_unary_operation_1 case SIGN_EXTEND + if (val_signbit_known_clear_p + simplify_gen_unary (ZERO_EXTEND, mode, op, GET_MODE (op)); return expand_compound_operation (x); // x is ZERO_EXTEND now
[Bug c++/109576] access checking done on constexpr even if the access was done in the class itself when used inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97740, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96716 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > Yes and those are dups of each other too :). Or at least related.
[Bug c++/109576] access checking done on constexpr even if the access was done in the class itself when used inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576 --- Comment #5 from Andrew Pinski --- (In reply to Alex Wang from comment #4) > Just realized my previous searches were only searching the summary. > > Is this bug a duplicate of either > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96716 and/or > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97740? Yes and those are dups of each other too :).
[Bug c++/109576] access checking done on constexpr even if the access was done in the class itself when used inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576 --- Comment #4 from Alex Wang --- Just realized my previous searches were only searching the summary. Is this bug a duplicate of either https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96716 and/or https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97740?
[Bug target/109535] [13/14] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535 JuzheZhong changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|ASSIGNED --- Comment #13 from JuzheZhong --- reopen
[Bug tree-optimization/109581] [13/14 Regression] Comparing with -HUGE_VAL wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581 --- Comment #2 from Andrew Pinski --- >From evrp: Folding predicate inf.2_3 < -1.79769313486231570814527423731704356798070567525844996599e+308 to 0 Removing basic block 3 Merging blocks 2 and 4 Because there is nothing smaller than that with -ffinite-math-only really.
[Bug tree-optimization/109581] [13/14 Regression] Comparing with -HUGE_VAL wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- -ffast-math implies -ffinite-math-only which implies INF will not show up. "Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs." https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Options.html#index-ffinite-math-only
[Bug tree-optimization/109581] [13/14 Regression] Comparing with -HUGE_VAL wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Component|c |tree-optimization Keywords||wrong-code Summary|Comparing with -HUGE_VAL|[13/14 Regression] |wrong result|Comparing with -HUGE_VAL ||wrong result CC||aldyh at gcc dot gnu.org
[Bug c/109581] New: Comparing with -HUGE_VAL wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581
Bug ID: 109581
Summary: Comparing with -HUGE_VAL wrong result
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daschuer at mixxx dot org
Target Milestone: ---
Comparing with -HUGE_VAL gives the wrong result with gcc (GCC) 13.0.1 20230401
(Red Hat 13.0.1-0).
GCC 12.2 is and clang are not effected.
This bug breaks Mixxx after compiling it on openSUSE Tumbleweed and Fedora 38
https://github.com/mixxxdj/mixxx/issues/11483
The workaround is to store -HUGE_VAL as a volatile first.
This is a minimal code that demonstrates the issue:
#include
#include
int main(int num) {
long long rawInf = 0xfff0;
volatile double inf = *(double*)(void*)
if (inf == -HUGE_VAL) {
puts("Success");
} else {
puts("Error");
}
return 0;
}
The following flags are used:
-g -pipe -O3 -ffast-math -funroll-loops -fomit-frame-pointer -mtune=generic
-Wall -Wextra -Wfloat-conversion -Werror=return-type
Result
GCC 12.2 and lower "Success"
GCC 13.0 "Error"
Details: https://godbolt.org/z/7bnb77hv4
[Bug tree-optimization/109565] -Wstrict-overflow false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565 --- Comment #6 from Andrew Pinski --- Yes it should mention overflow on pointers. Anyways also see https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fwrapv-pointer and right below that with fstrict-overflow .
[Bug analyzer/109580] New: #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109580 Bug ID: 109580 Summary: #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: eggert at gnu dot org Target Milestone: --- Created attachment 54896 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54896=edit compressed test program illustrating false positive This is gcc (GCC) 13.0.1 20230401 (Red Hat 13.0.1-0), and I ran into this problem when compiling Emacs. This is a regression compared to GCC 12. Compile the attached compressed program with: gzip -d emacs1.i.gz gcc -fanalyzer -O2 -S emacs1.i GCC will generate output starting with: In function ‘Fdaemon_initialized’: cc1: warning: leak of file descriptor ‘dup2(nfd, 0)’ [CWE-775] [-Wanalyzer-fd-leak] However, the first line of emacs1.i is: #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" so that diagnostic should not be emitted.
[Bug middle-end/109578] fail to remove dead code due to division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed > later on that GCC didn't realize divide could trap. I was right on that, it was a dup of bug 41239 which was fixed in GCC 4.5.0. The problem was exactly what I thought it was, a trapping instruction being scheduled before the call. And yes it has been fixed for a long time, 13 years in fact.
[Bug middle-end/109578] fail to remove dead code due to division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578 --- Comment #4 from Vincent Lefèvre --- (In reply to Andrew Pinski from comment #3) > Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed > later on that GCC didn't realize divide could trap. OK, thanks, I can see your update marking PR 29968 as a duplicate of PR 41239 (fixed).
[Bug rtl-optimization/41239] Scheduler reorders division by zero before a call that might not return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41239 Andrew Pinski changed: What|Removed |Added CC||tiamat at komi dot mts.ru --- Comment #7 from Andrew Pinski --- *** Bug 29968 has been marked as a duplicate of this bug. ***
[Bug c/29968] integer division by zero with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup of bug 41239 in the end which was fixed in GCC 4.5.0. *** This bug has been marked as a duplicate of bug 41239 ***
[Bug c/29968] integer division by zero with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 --- Comment #5 from Andrew Pinski --- (In reply to Vincent Lefèvre from comment #4) > (In reply to Andreas Schwab from comment #2) > > Your program is invoking undefined behaviour. You should not perform the > > division if the divisor is zero. > > But PR109578 Comment 1 says that side effects should be visible before > undefined behavior occurs. Thus this bug should be reopened. Except it can no longer reproduce it so the issue has been fixed a long time ago.
[Bug middle-end/109578] fail to remove dead code due to division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578 --- Comment #3 from Andrew Pinski --- (In reply to Vincent Lefèvre from comment #2) > (In reply to Andrew Pinski from comment #1) > > We don't removing code before undefined behavior ... > > That is GCC does not know that printf does not have side effects. > > Then GCC is incorrect in bug 29968, because it does the division *before* > the printf. Or was a bug which has since been fixed. For sparc GCC 12.2.0 we get: sethi %hi(.LC0), %o0 callputs, 0 or %o0, %lo(.LC0), %o0 ta 5 Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed later on that GCC didn't realize divide could trap.
[Bug c/29968] integer division by zero with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #4 from Vincent Lefèvre --- (In reply to Andreas Schwab from comment #2) > Your program is invoking undefined behaviour. You should not perform the > division if the divisor is zero. But PR109578 Comment 1 says that side effects should be visible before undefined behavior occurs. Thus this bug should be reopened.
[Bug analyzer/109570] detect fclose on unopened or NULL files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570 --- Comment #2 from David Malcolm --- Thanks for filing this bug. I think -fanalyzer should warn about fclose(NULL), but not for free(NULL).
[Bug target/109567] Useless stack adjustment by 16 around calls with odd stack-argument counts on SysV x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109567 --- Comment #1 from Andrew Pinski --- Compiling with -fno-omit-frame-pointer shows what is happening really. It is reserving space for the frame pointer on the stack. I am not 100% sure but I think that is required even if the frame pointer is not saved/restored.
[Bug middle-end/109578] fail to remove dead code due to division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578 --- Comment #2 from Vincent Lefèvre --- (In reply to Andrew Pinski from comment #1) > We don't removing code before undefined behavior ... > That is GCC does not know that printf does not have side effects. Then GCC is incorrect in bug 29968, because it does the division *before* the printf.
[Bug tree-optimization/109568] Spurious "potential null pointer dereference" in shared_ptr_base.h with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109571 --- Comment #7 from Andrew Pinski --- This is basically similar to PR 109571 except using dynamic_cast rather than a downcast. But the same issue is there from jump threading from code emitted from the front-end.
[Bug analyzer/109579] New: -Wanalyzer-out-of-bounds false positive in Emacs mapping stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109579
Bug ID: 109579
Summary: -Wanalyzer-out-of-bounds false positive in Emacs
mapping stack
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 54895
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54895=edit
compressed test program illustrating false positive
This is gcc (GCC) 13.0.1 20230401 (Red Hat 13.0.1-0) on x86-64, and I ran into
this problem when compiling Emacs. Take the attached file ccl1.i.gz and then
run:
gzip -d ccl1.i.gz
gcc -S -fanalyzer -O2 ccl1.i
The incorrect diagnostics are as follows. These diagnostics are wrong since the
two uses of "mapping_stack_pointer--" in lines 33010 and 33011 are protected
due to those lines being in the else-part of "if (mapping_stack_pointer <=
(mapping_stack + 1))", which means mapping_stack_pointer cannot possibly
underrun the buffer simply by subtracting one from it twice.
I can work around this by compiling with -Wno-analyzer-out-of-bounds but this
seems a bit drastic.
Here are the incorrect diagnostics. These diagnostics are a regression since
GCC 12.
-
ccl1.i: In function ‘ccl_driver’:
ccl1.i:33010:107: warning: buffer under-read [CWE-127]
[-Wanalyzer-out-of-bounds]
33010 | do { mapping_stack_pointer--; (map_set_rest_length) =
mapping_stack_pointer->rest_length; (orig_op) =
mapping_stack_pointer->orig_val; } while (0);
|
~~^
‘Fccl_execute_on_string’: events 1-4
|
|33434 | __attribute__((section (".subrs"))) static union Aligned_Lisp_Subr
Sccl_execute_on_string = {{{ PVEC_SUBR << PSEUDOVECTOR_AREA_BITS }, { .a5 =
Fccl_execute_on_string }, 3, 5, "ccl-execute-on-string", {0}, 0}}; Lisp_Object
Fccl_execute_on_string
| |
^~
| |
|
| |
(1)
entry to ‘Fccl_execute_on_string’
|..
|33446 | if (! setup_ccl_program (, ccl_prog))
| | ~
| | |
| | (2) following ‘true’ branch...
|33447 | error ("Invalid CCL program");
|33448 | CHECK_VECTOR (status);
| | ~
| | |
| | (3) ...to here
| | (4) calling ‘CHECK_VECTOR’ from ‘Fccl_execute_on_string’
|
+--> ‘CHECK_VECTOR’: events 5-6
|
| 5942 | CHECK_VECTOR (Lisp_Object x)
| | ^~~~
| | |
| | (5) entry to ‘CHECK_VECTOR’
| 5943 | {
| 5944 | CHECK_TYPE (VECTORP (x), builtin_lisp_symbol (1495), x);
| | ~~~
| | |
| | (6) calling ‘VECTORP’ from ‘CHECK_VECTOR’
|
+--> ‘VECTORP’: events 7-8
|
| 5933 | VECTORP (Lisp_Object x)
| | ^~~
| | |
| | (7) entry to ‘VECTORP’
| 5934 | {
| 5935 | return VECTORLIKEP (x) && ! (ASIZE (x) & (
| |~
| ||
| |(8) inlined call to
‘ASIZE’ from ‘VECTORP’
|
+--> ‘ASIZE’: event 9
|
| 5916 | ((0 <= size) ? (void) 0 :
__builtin_unreachable ());
| |
^~~
| | |
| | (9) following
‘false’ branch (when ‘size >= 0’)...
|
<--+
|
‘VECTORP’: event 10
|
| 5935 | return
[Bug tree-optimization/109568] Spurious "potential null pointer dereference" in shared_ptr_base.h with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
Andrew Pinski changed:
What|Removed |Added
Summary|[12/13/14 Regression] |Spurious "potential null
|Spurious "potential null|pointer dereference" in
|pointer dereference" in |shared_ptr_base.h with
|shared_ptr_base.h with |"-O1"
|"-O1" |
Component|libstdc++ |tree-optimization
Target Milestone|12.3|---
--- Comment #6 from Andrew Pinski ---
This has nothing to do with libstd++, a similar warning can happen with:
struct Base {
virtual ~Base() = default;
int b = 0;
};
struct Derived : public Base {};
bool empty(Base* var) {
auto* var_ref = dynamic_cast(var);
if (var_ref->b) return false;
return true;
}
[Bug middle-end/109578] fail to remove dead code due to division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- We don't removing code before undefined behavior ... That is GCC does not know that printf does not have side effects.
[Bug middle-end/109578] New: fail to remove dead code due to division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
Bug ID: 109578
Summary: fail to remove dead code due to division by zero
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
This is about the opposite of the invalid bug 29968:
#include
int f (int i, int k)
{
if (k == 0)
printf ("k = 0\n");
return i/k;
}
int main (void)
{
return f (1, 0);
}
With gcc-12 (Debian 12.2.0-14) 12.2.0 and -O3 optimization, I get:
k = 0
zsh: illegal hardware instruction (core dumped) ./tst
But since the case k == 0 corresponds to an undefined behavior (which is the
justification behind that GCC is correct in bug 29968), the code
if (k == 0)
printf ("k = 0\n");
should have been removed as an optimization.
[Bug tree-optimization/109573] [12/13/14 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 when building chromium's maglev-assembler-x64.cc with -march=ivybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Keywords||needs-bisection, ||needs-reduction --- Comment #1 from Andrew Pinski --- Reducing this too.
[Bug fortran/109575] Implement runtime check for valid function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-04-20 Priority|P3 |P4 --- Comment #1 from kargl at gcc dot gnu.org --- Change status to "new" as I agree with Harald that this would be a nice runtime warning for debugging. Changed to 'P4'
[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
Georg-Johann Lay changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #15 from Georg-Johann Lay ---
The error is in the combine pass.
Prior to combine, we have the followng insn for divmod (from -da init-regs
dump):
(insn 9 7 11 3 (parallel [
(set (reg:SI 50)
(udiv:SI (reg/v:SI 47 [ n ])
(reg:SI 51)))
(set (reg:SI 49)
(umod:SI (reg/v:SI 47 [ n ])
(reg:SI 51)))
(clobber (reg:SI 18 r18))
(clobber (reg:SI 22 r22))
(clobber (reg:HI 26 r26))
(clobber (reg:HI 30 r30))
]) "bug.c":6:15 403 {udivmodsi4}
(expr_list:REG_UNUSED (reg:HI 30 r30)
(expr_list:REG_UNUSED (reg:HI 26 r26)
(expr_list:REG_UNUSED (reg:SI 22 r22)
(expr_list:REG_UNUSED (reg:SI 18 r18)
(nil))
This basically encodes a transparent libgcc call to __udivmodsi4 (insn
"*udivmodsi4_call").
The combine dump however reads:
(insn 9 7 11 3 (set (reg:SI 49)
(umod:SI (reg/v:SI 47 [ n ])
(reg:SI 51))) "bug.c":6:15 403 {udivmodsi4}
(expr_list:REG_UNUSED (reg:HI 30 r30)
(expr_list:REG_UNUSED (reg:HI 26 r26)
(expr_list:REG_UNUSED (reg:SI 22 r22)
(expr_list:REG_UNUSED (reg:SI 18 r18)
(nil))
(insn 11 9 14 3 (set (reg/v:SI 45 [ n ])
(reg/v:SI 47 [ n ])) 119 {*movsi_split}
(expr_list:REG_DEAD (reg/v:SI 47 [ n ])
(nil)))
(insn 14 11 15 3 (set (reg/v:SI 47 [ n ])
(udiv:SI (reg/v:SI 47 [ n ])
(reg:SI 51))) "bug.c":7:7 119 {*movsi_split}
(expr_list:REG_DEAD (reg:SI 50)
(nil)))
These udiv and umod insn do not exist and are unrecognizable. Combine should
never have split the original udivmodsi4.
I used the original test case from comment #0 with
$ avr-gcc bug.c -S -O1 -mmcu=atmega8 -da
where avr-gcc is from 2023-03-03 master (future v13).
With -fdisable-rtl-combine no ICE occurs.
[Bug analyzer/109577] New: -Wanalyzer-allocation-size mishandles __builtin_mul_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577
Bug ID: 109577
Summary: -Wanalyzer-allocation-size mishandles
__builtin_mul_overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
This is (GCC) 13.0.1 20230401 (Red Hat 13.0.1-0) on x86-64.
Compile the following program with 'gcc -O2 -S -fanalyzer t.c'. GCC will
incorrectly complain "warning: allocated buffer size is not a multiple of the
pointee's size [CWE-131]". But the allocated buffer size must be a multiple of
sizeof (double), due to the checked call to __builtin_mul_overflow. As the
code's comment suggests, if the code uses plain * (integer multiply) instead
the bogus warning goes away.
I ran into this problem when compiling Emacs, which is often careful about
checking integer overflow. As a result I think I'll compile Emacs with
-Wno-analyzer-allocation-size to suppress false alarms, which would be a real
shame since this warning is useful for lower-quality code.
#include
int
main (int argc, char **argv)
{
size_t s;
double *d;
if (__builtin_mul_overflow (argc, sizeof *d, ))
return 1;
// No warning if the above is replaced with 's = argc * sizeof *d;'.
d = malloc (s);
if (d && s)
{
d[0] = argc;
d[argc - 1] = argc + 1;
return d[0];
}
return 0;
}
[Bug c++/109576] access checking done on constexpr even if the access was done in the class itself when used inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.7.1, 5.1.0
--- Comment #3 from Andrew Pinski ---
Another testcase:
```
struct static_string {
constexpr operator const char*() const { return _; }
constexpr static_string() : chars_(0) {}
private:
char chars_ ;//= '\0';
};
constexpr static_string enum_name_v{};
template
struct s{
static constexpr const char* local_name = enum_name_v;
};
auto t = s<0>::local_name;
```
Note the above fails in GCC 4.6.1 differently:
:12:51: error: '(const char*){'\000'}' is not a constant expression
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #22 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-April/059202.html
[Bug c++/109576] access checking done on constexpr even if the access was done in the class itself when used inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-04-20
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Another one:
```
struct static_string {
constexpr operator const char*() const { return _; }
private:
char chars_{'\0'};
};
constexpr static_string enum_name_v{};
template
constexpr const char* local_name = enum_name_v;
auto t = local_name<0>;
```
Confirmed.
[Bug c++/109576] access checking done on constexpr even if the access was done in the class itself when used inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
Andrew Pinski changed:
What|Removed |Added
Summary|Incorrect rejection of |access checking done on
|constexpr local var due to |constexpr even if the
|private member even with|access was done in the
|visible conversion operator |class itself when used
||inside a template
--- Comment #1 from Andrew Pinski ---
Another testcase:
```
struct static_string {
constexpr operator const char*() const { return _; }
private:
char chars_{'\0'};
};
constexpr static_string enum_name_v{};
template
struct s{
static constexpr const char* local_name = enum_name_v;
};
auto t = s<0>::local_name;
```
[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 Georg-Johann Lay changed: What|Removed |Added Last reconfirmed||2023-04-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/109576] New: Incorrect rejection of constexpr local var due to private member even with visible conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
Bug ID: 109576
Summary: Incorrect rejection of constexpr local var due to
private member even with visible conversion operator
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ts826848 at gmail dot com
Target Milestone: ---
My apologies in advance for the title. I'm honestly not sure how to summarize
this.
GCC appears to incorrectly flag the creation of a constexpr local variable when
a conversion operator is used that accesses a private member of a class.
According to Godbolt, the code compiles under Clang 5.0.0-16.0.0 and the MSVC
19.14-19.latest, but GCC 7.1 and up rejects the code.
(For a little bit of context, I ran into this when using Neargye/magic_enum for
some enum reflection, and I create some constexpr local variables to hold
stringified enum names)
Here is the heavily reduced code ([Godbolt](https://godbolt.org/z/hGTMWvPrz)):
struct static_string {
constexpr operator const char*() const { return {_}; }
private:
char chars_{'\0'};
};
constexpr static_string enum_name_v{};
constexpr const char* nonlocal_name = enum_name_v;
template
constexpr auto enum_name() {
constexpr const char* local_name = enum_name_v;
return local_name;
}
auto n = enum_name<0>();
GCC complains about local_name:
: In instantiation of 'constexpr auto enum_name() [with auto V =
0]':
:17:22: required from here
:13:40: error: 'char static_string::chars_' is private within this
context
13 | constexpr const char* local_name = enum_name_v;
|^~~
:4:10: note: declared private here
4 | char chars_{'\0'};
| ^~
Compiler returned: 1
This seems like valid C++ to me. enum_name_v should be convertible via the
operator string_view, and I'm not sure why the visibility of chars_ is relevant
at all. In addition, some non-visibility-related changes gets the code to
compile, which seems inconsistent with this being a visibility issue:
- Making `local_name` a non-local variable (e.g., `nonlocal_name`)
- Making `local_name` non-`constexpr`
- Making `enum_name` a non-template function
[Bug tree-optimization/109571] potential null pointer dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571
--- Comment #2 from Andrew Pinski ---
You get the same warning with:
struct A
{
int i = 0;
};
struct B: A
{
virtual ~B ();
};
int f(B *tmp)
{
A *a = tmp;
return a->i;
}
[Bug tree-optimization/109571] potential null pointer dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Keywords||diagnostic --- Comment #1 from Andrew Pinski --- >so I'd like to understand what's actually causing this warning, so I can avoid >it. It comes from jump threading. Considering -Wnull-dereference is not turned on via either -Wextra or -Wall. Just turn off the warning. Basically when the front-end expands does: B *tmp; A *a = tmp; It expands it as: if (D.30650 != 0B) goto ; [INV] else goto ; [INV] : iftmp.0 = >D.28785; goto ; [INV] : iftmp.0 = 0B; : a = iftmp.0; And then there is a jump threading with the check of the null pointer and then propagating the null pointer into the deference.
[Bug fortran/109575] New: Implement runtime check for valid function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575 Bug ID: 109575 Summary: Implement runtime check for valid function result Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- Split off from the discussion in pr109500: consider program main implicit none integer, allocatable :: p p = f() ! <- this assignment may fail print *, allocated (p) contains function f() integer, allocatable :: f allocate (f, source=42) deallocate (f) ! <- this renders the function invalid end function end This code is invalid as the function result must be defined: F2018:15.6.2.2 On completion of execution of the function, the value returned is that of its function result. If the function result is a data pointer, the shape of the value returned by the function is determined by the shape of the function result when the execution of the function is completed. If the function result is not a pointer, its value shall be defined by the function. If the function result is a pointer, on return the pointer association status of the function result shall not be undefined. A runtime check that can detect the failing assignment needs to check that the function result is defined when the function returns.
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993 --- Comment #8 from Andrew Pinski --- (In reply to Pablo Anigstein from comment #7) > Here is an updated example: https://godbolt.org/z/YePjhxKE4. I don't see an updated example, all I see is an URL ...
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #7 from Pablo Anigstein ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Jonathan Wakely from comment #3)
> > (In reply to Pablo Anigstein from comment #2)
> > > (In reply to Andrew Pinski from comment #1)
> > > > Hmm,
> > > > I noticed that since GCC 7 with -std=c++17, the b.x is not initialized
> > > > at
> > > > all. So the question I have is there a difference between C++ standards
> > > > here?
> >
> > Derived is an aggregate in C++17, so b{} does aggregate init, not value
> > init.
>
> And that means its Base subobject is copy-initialized from {} which means we
> get a value-initialized object, so it's correct that b.x is not initialized
> in C++17 (which is what is shown in your godbolt link, because you didn't
> specify any -std option to override the -std=gnu++17 default).
>
> With -std=c++14 it looks like b.x is always set to zero, if I'm reading the
> assembly output correctly (but I'm probably not).
Here is an updated example: https://godbolt.org/z/YePjhxKE4. Note that now
Derived is not an aggregate for any standard version due to the private member.
Still zero-initialization does not happen for the Base sub-object for the case
where Base has a user-provided default constructor when compiling with -O1 and
above.
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #6 from Pablo Anigstein ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Pablo Anigstein from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Hmm,
> > > I noticed that since GCC 7 with -std=c++17, the b.x is not initialized at
> > > all. So the question I have is there a difference between C++ standards
> > > here?
>
> Derived is an aggregate in C++17, so b{} does aggregate init, not value init.
>
> > > Note the issue is we call Base's constructor after doing the zero
> > > initialization and the Base's constructor has a clobber in it which I
> > > think
> > > is correct.
>
> Maybe we should only clobber in the complete object constructor _ZN4BaseC1Ev
> and not in _ZN4BaseC2Ev.
>
> > > This is all front-end generation and not exactly related to the
> > > optimizations directly.
> >
> > There is no difference between C++ standards in this respect.
>
> Before C++11 there was no zero-init at all. Since C++11 the spec keeps
> changing, but the effects of zero-init are substantially the same. But
> Derived is an aggregate since C++17.
Thank you for the correction. I still think there is non-conformance for all
standards including C++17, I will post a modified example in a comment below.
>
> Aside: What does the comment "not a default constructor" mean in the
> testcase?
I guess he meant "user-provided".
[Bug tree-optimization/109573] [12/13/14 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 when building chromium's maglev-assembler-x64.cc with -march=ivybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |12.3
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 --- Comment #21 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #19) > PS: I think what you want to with a runtime check and an undefine > function result is a good idea. I haven't looked to see where > and how hard this might be to implement. I am considering to create a separate PR to track this.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 --- Comment #20 from anlauf at gcc dot gnu.org --- Created attachment 54894 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54894=edit Extended testcase Testcase for Steve's variant of the diagnostic, checking that we also catch procedure pointers with the same interface. This testcase has been cross-checked with NAG. The missing diagnostic with Intel has been acknowledged, see: https://community.intel.com/t5/Intel-Fortran-Compiler/Allocatable-function-result-should-not-have-allocatable/m-p/1478494#M166138 I think we can proceed so that people can fix their codes in time for gcc-14.
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 Andrew Pinski changed: What|Removed |Added CC||vineetg at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 109574 has been marked as a duplicate of this bug. ***
[Bug target/109574] RISC-V: gcc.dg/pr90838.c failing due to extra ANDI 127 on releases/gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109574 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 106888. *** This bug has been marked as a duplicate of bug 106888 ***
[Bug target/109574] New: RISC-V: gcc.dg/pr90838.c failing due to extra ANDI 127 on releases/gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109574
Bug ID: 109574
Summary: RISC-V: gcc.dg/pr90838.c failing due to extra ANDI 127
on releases/gcc-13
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vineetg at gcc dot gnu.org
Target Milestone: ---
int ctz3 (unsigned x)
{
static int table[32] =
{
0, 1, 2,24, 3,19, 6,25, 22, 4,20,10,16, 7,12,26,
31,23,18, 5,21, 9,15,11,30,17, 8,14,29,13,28,27
};
if (x == 0) return 32;
x = (x & -x) * 0x04D7651F;
return table[x >> 27];
}
riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zbb
Before
ctz3:
ctzwa0,a0
ret
Now
ctz3:
ctzwa0,a0
andia0,a0,127
ret
Bisected this to c23a9c87cc62bd177 ("Some additional zero-extension related
optimizations in simplify-rtx.")
[Bug tree-optimization/109564] [13/14 Regression] libkeccak miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564 --- Comment #19 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:17aa9ddb34581855dd013745c8be27dda024de4a commit r14-122-g17aa9ddb34581855dd013745c8be27dda024de4a Author: Andrew MacLeod Date: Thu Apr 20 13:10:40 2023 -0400 Do not ignore UNDEFINED ranges when determining PHI equivalences. Do not ignore UNDEFINED name arguments when registering two-way equivalences from PHIs. PR tree-optimization/109564 gcc/ * gimple-range-fold.cc (fold_using_range::range_of_phi): Do no ignore UNDEFINED range names when deciding if all PHI arguments are the same, gcc/testsuite/ * gcc.dg/torture/pr109564-1.c: New testcase. * gcc.dg/torture/pr109564-2.c: Likewise. * gcc.dg/tree-ssa/evrp-ignore.c: XFAIL. * gcc.dg/tree-ssa/vrp06.c: Likewise.
[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011 --- Comment #22 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:87c9bae4e32b54829dce0a93ff735412d5f684f8 commit r14-121-g87c9bae4e32b54829dce0a93ff735412d5f684f8 Author: Jakub Jelinek Date: Thu Apr 20 19:44:27 2023 +0200 tree-vect-patterns: One small vect_recog_ctz_ffs_pattern tweak [PR109011] I've noticed I've made a typo, ifn in this function this late is always only IFN_CTZ or IFN_FFS, never IFN_CLZ. Due to this typo, we weren't using the originally intended .CTZ (X) = .POPCOUNT ((X - 1) & ~X) but .CTZ (X) = PREC - .POPCOUNT (X | -X) instead when we want to emit __builtin_ctz*/.CTZ using .POPCOUNT. Both compute the same value, both are defined at 0 with the same value (PREC), both have same number of GIMPLE statements, but I think the former ought to be preferred, because lots of targets have andn as a single operation rather than two, and also putting a -1 constant into a vector register is often cheaper than vector with broadcast PREC power of two value. 2023-04-20 Jakub Jelinek PR tree-optimization/109011 * tree-vect-patterns.cc (vect_recog_ctz_ffs_pattern): Use .CTZ (X) = .POPCOUNT ((X - 1) & ~X) in preference to .CTZ (X) = PREC - .POPCOUNT (X | -X).
[Bug libgomp/107041] [13/14 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107041 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3d7ab53d6c59499624aa41c8dea0664976820b3b commit r14-120-g3d7ab53d6c59499624aa41c8dea0664976820b3b Author: Jakub Jelinek Date: Thu Apr 20 19:26:17 2023 +0200 c: Avoid -Wenum-int-mismatch warning for redeclaration of builtin acc_on_device [PR107041] The new -Wenum-int-mismatch warning triggers with -Wsystem-headers in , for obvious reasons the builtin acc_on_device uses int type argument rather than enum which isn't defined yet when the builtin is created, while the OpenACC spec requires it to have acc_device_t enum argument. The header makes sure it has int underlying type by using negative and __INT_MAX__ enumerators. I've tried to make the builtin typegeneric or just varargs, but that changes behavior e.g. when one calls it with some C++ class which has cast operator to acc_device_t, so the following patch instead disables the warning for this builtin. 2023-04-20 Jakub Jelinek PR c/107041 * c-decl.cc (diagnose_mismatched_decls): Avoid -Wenum-int-mismatch warning on acc_on_device declaration. * gcc.dg/goacc/pr107041.c: New test.
[Bug tree-optimization/109573] New: [12/13/14 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 when building chromium's maglev-assembler-x64.cc with -march=ivybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573
Bug ID: 109573
Summary: [12/13/14 regression] ICE in
vectorizable_live_operation, at tree-vect-loop.cc:9060
when building chromium's maglev-assembler-x64.cc with
-march=ivybridge
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Occurs when building chromium. Originally reported in Gentoo at
https://bugs.gentoo.org/904455.
Needs -march=ivybridge. GCC 11 is OK, but 12/13 and presumably 14 are not.
(Unlike my recent reports, does not need checking.)
```
out/Release $ g++-13 -MMD -MF
obj/v8/v8_base_without_compiler/maglev-assembler-x64.o.d -DUSE_UDEV
-DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -DNDEBUG
-DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DV8_INTL_SUPPORT
-DV8_USE_EXTERNAL_STARTUP_DATA -DV8_ATOMIC_OBJECT_FIELD_WRITES
-DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO
-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH -DV8_SHORT_BUILTIN_CALLS
-DV8_EXTERNAL_CODE_SPACE -DV8_ENABLE_MAGLEV -DV8_ENABLE_TURBOFAN
-DV8_ENABLE_WEBASSEMBLY -DV8_ALLOCATION_FOLDING -DV8_ALLOCATION_SITE_TRACKING
-DV8_ADVANCED_BIGINT_ALGORITHMS -DV8_STATIC_ROOTS -DV8_USE_ZLIB
-DV8_USE_LIBM_TRIG_FUNCTIONS -DV8_ENABLE_WASM_SIMD256_REVEC
-DV8_COMPRESS_POINTERS -DV8_COMPRESS_POINTERS_IN_SHARED_CAGE
-DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_ENABLE_SANDBOX -DV8_DEPRECATION_WARNINGS
-DCPPGC_CAGED_HEAP -DCPPGC_YOUNG_GENERATION -DCPPGC_POINTER_COMPRESSION
-DCPPGC_SLIM_WRITE_BARRIER -DV8_TARGET_ARCH_X64 -DV8_HAVE_TARGET_OS
-DV8_TARGET_OS_LINUX -DUSING_SYSTEM_ICU=1
-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DU_IMPORT=U_EXPORT
-DUSE_SYSTEM_ZLIB=1 -I../.. -Igen -I../../v8 -I../../v8/include -Igen/v8
-Igen/v8/include -Igen/shim_headers/icui18n_shim -Igen/shim_headers/icuuc_shim
-Igen/shim_headers/zlib_shim -Wno-unused-local-typedefs
-Wno-maybe-uninitialized -Wno-deprecated-declarations -Wno-comments
-Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-unused-parameter
-Wno-psabi -fno-ident -fno-strict-aliasing --param=ssp-buffer-size=4
-fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC
-pipe -pthread -fno-omit-frame-pointer -fvisibility=hidden -Wno-strict-overflow
-Wno-return-type -Wno-int-in-bool-context -Wno-deprecated -Wno-narrowing
-Wno-class-memaccess -std=gnu++2a -fno-exceptions -fno-rtti
-fvisibility-inlines-hidden -O2 -march=ivybridge -pipe -O2 -march=ivybridge
-pipe -c ../../v8/src/maglev/x64/maglev-assembler-x64.cc -o
obj/v8/v8_base_without_compiler/maglev-assembler-x64.o
during GIMPLE pass: slp
../../v8/src/maglev/x64/maglev-assembler-x64.cc: In member function ‘void
v8::internal::maglev::MaglevAssembler::Prologue(v8::internal::maglev::Graph*)’:
../../v8/src/maglev/x64/maglev-assembler-x64.cc:515:6: internal compiler error:
in vectorizable_live_operation, at tree-vect-loop.cc:10117
515 | void MaglevAssembler::Prologue(Graph* graph) {
| ^~~
0x6a599b vectorizable_live_operation(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*, int, bool,
vec*)
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230419-r1/gcc-13.1.0-RC2-20230419/gcc/tree-vect-loop.cc:10117
0x1cea7e0 can_vectorize_live_stmts
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230419-r1/gcc-13.1.0-RC2-20230419/gcc/tree-vect-stmts.cc:11206
0x1d110b2 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230419-r1/gcc-13.1.0-RC2-20230419/gcc/tree-vect-stmts.cc:11607
0x10925a0 vect_schedule_slp_node
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230419-r1/gcc-13.1.0-RC2-20230419/gcc/tree-vect-slp.cc:8952
0x10a3198 vect_schedule_scc
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230419-r1/gcc-13.1.0-RC2-20230419/gcc/tree-vect-slp.cc:9147
0x10a2e32 vect_schedule_scc
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230419-r1/gcc-13.1.0-RC2-20230419/gcc/tree-vect-slp.cc:9128
0x10a36fc vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230419-r1/gcc-13.1.0-RC2-20230419/gcc/tree-vect-slp.cc:9287
0x10a60fe vect_slp_region
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230419-r1/gcc-13.1.0-RC2-20230419/gcc/tree-vect-slp.cc:7496
0x10a6b89 vect_slp_bbs
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #25 from Jonathan Wakely --- ... and non-empty types, I'm just saying that's the obvious case that proves it's possible.
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #24 from Jonathan Wakely ---
(In reply to Arthur O'Dwyer from comment #23)
> - There may be padding in the middle of an object, and I'm not confident
> that the Standard actually forbids it from being used. Of course your
> approach works fine on the Itanium ABI, and probably works everywhere that
> actually exists. If you've got chapter+verse proving that it must work
> *everywhere*, I'd appreciate seeing it, just for my own information.
I don't care about everywhere, only GCC-like compilers on the targets they
support.
> - If GCC were ever to add a builtin for this notion, IMO the proper name
> would be `__datasizeof(T)`. See
> https://danakj.github.io/2023/01/15/trivially-relocatable.html#data-size
I think it should have a __builtin_ prefix unless it directly implements a
standard trait like __is_object.
> - You can implement your library trait like this; see
> https://quuxplusone.github.io/blog/2023/03/04/trivial-swap-prize-update/
> #step-1.-std-swap-can-t-assume-it
>
> template
> struct __libcpp_datasizeof {
> struct _Up {
> [[__no_unique_address__]] _Tp __t_;
> char __c_;
> };
> static const size_t value = __builtin_offsetof(_Up, __c_);
> };
>
> Unfortunately it looks like GCC doesn't support
> `__attribute__((__no_unique_address__))` in C++03 mode. (Neither does Clang.
> What is up with that!)
Which is OK, because you can't have final types in C++03 either, so testing it
using inheritance is good enough for C++03.
> Your suggested trait implementation is slightly wrong for `is_final` types:
> you return 0 but really a final type _can_ have usable tail padding. See
> https://godbolt.org/z/P6x459MEq
Ah, I didn't think that padding would actually be used by an adjacent member
subobject. But of course it can be for an empty class, where it consists of a
single byte of padding which can be reused by another member of a different
type.
[Bug target/104338] RISC-V: Subword atomics result in library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 --- Comment #14 from Patrick O'Neill --- I picked this back up, v7 is here: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616080.html
[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387 --- Comment #13 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #9) > The _M_num_put cache exists to avoid doing the RTTI check implied by > use_facet every time we use the stream. But that RTTI check has been removed > for GCC 13 anyway. Since the cached facet is the cause of this bug, we can > just ignore it for powercp64le when we support two forms of long double. I've backported this to gcc-12, but we don't have the optimization to make std::use_facet faster on gcc-12 (and it requires new exported symbols, so can't be backported). That means there's a performance hit for those iostream ops on gcc-12 now. But they don't segfault! Maybe I should look into a powerpc64le-specific change to avoid that performance hit on the branch. Or maybe only avoid the cached facet when outputting an __ieee128, as that's when the cached facet is not usable.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #19 from Steve Kargl ---
On Thu, Apr 20, 2023 at 05:22:59AM +, kargl at gcc dot gnu.org wrote:
>
> I think we agree on all points. Here's the diff I envision.
> NOte, I've restricted it to user defined functions. Remove
> the esym check will enable it for any subprogram.
>
>
> diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
> index db79b104dc2..f3bcdd76d6a 100644
> --- a/gcc/fortran/interface.cc
> +++ b/gcc/fortran/interface.cc
> @@ -3622,6 +3622,18 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap,
> gfc_formal_arglist *formal,
> goto match;
> }
>
> + if (a->expr->expr_type == EXPR_FUNCTION
> + && a->expr->value.function.esym
> + && f->sym->attr.allocatable)
> + {
> + if (where)
> + gfc_error ("Actual argument for %qs at %L is a function result "
> + "and the dummy argument is ALLOCATABLE",
> + f->sym->name, >expr->where);
> + ok = false;
> + goto match;
> + }
> +
>/* Check intent = OUT/INOUT for definable actual argument. */
>if (!in_statement_function
> && (f->sym->attr.intent == INTENT_OUT
>
The patch passes regtesting.
PS: I think what you want to with a runtime check and an undefine
function result is a good idea. I haven't looked to see where
and how hard this might be to implement.
[Bug tree-optimization/109564] [13/14 Regression] libkeccak miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564 --- Comment #18 from Andrew Macleod --- (In reply to Richard Biener from comment #16) > (In reply to Richard Biener from comment #15) > > Created attachment 54892 [details] > > patch I am testing > > Bootstrapped and tested on x86_64-unknown-linux-gnu, the XFAILs of > gcc.dg/pr102648.c and gcc.dg/pr103359.c are not necessary. > > > This is the patch I am testing which XFAILs the four testcases. It would be > > nice to somehow recover the unexecutable edge cases and somehow distinguish > > them from UNDEFINED arguments. I'm not sure if ranger has anything to > > track that besides relying on UNDEFINED being propagated as range across > > such > > edges? btw, thanks for all the investigation/patch work. much appreciated :-)
[Bug testsuite/109572] New: new test case gcc.dg/vect/pr109011-4.c from r14-108-g705b0d2b62318b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109572
Bug ID: 109572
Summary: new test case gcc.dg/vect/pr109011-4.c from
r14-108-g705b0d2b62318b fails
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:705b0d2b62318b3935214f08a1cf023b1117acb8, r14-108-g705b0d2b62318b
make -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/pr109011-4.c"
FAIL: gcc.dg/vect/pr109011-4.c scan-tree-dump-times optimized " = .CTZ \\(" 4
FAIL: gcc.dg/vect/pr109011-4.c -flto -ffat-lto-objects scan-tree-dump-times
optimized " = .CTZ \\(" 4
# of expected passes2
# of unexpected failures2
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/pr109011-4.c
-fdiagnostics-plain-output -O3 -fno-unroll-loops
--param=vect-epilogues-nomask=0 -fdump-tree-optimized -mpower9-vector -S -o
pr109011-4.s
PASS: gcc.dg/vect/pr109011-4.c (test for excess errors)
gcc.dg/vect/pr109011-4.c: pattern found 3 times
FAIL: gcc.dg/vect/pr109011-4.c scan-tree-dump-times optimized " = .CTZ \\(" 4
Also
FAIL: gcc.dg/vect/pr109011-5.c -flto -ffat-lto-objects scan-tree-dump-times
optimized " = .CLZ (" 3
FAIL: gcc.dg/vect/pr109011-5.c scan-tree-dump-times optimized " = .CLZ (" 3
Author: Jakub Jelinek
Date: Thu Apr 20 11:55:16 2023 +0200
tree-vect-patterns: Pattern recognize ctz or ffs using clz, popcount or ctz
[PR109011]
[Bug target/109535] [13/14] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535 --- Comment #12 from Mathieu Malaterre --- @JuzheZhong Technically you are supposed to simply remove the keyword '14' from the title and close when backported on 13...
[Bug rtl-optimization/78952] Combine does not convert 8-bit sign-extract to a zero-extract for QImode operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952 --- Comment #10 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:272484dae6b5264baa0f41eba80a9521e9b7ecf5 commit r14-117-g272484dae6b5264baa0f41eba80a9521e9b7ecf5 Author: Uros Bizjak Date: Thu Apr 20 16:51:56 2023 +0200 i386: Handle sign-extract for QImode operations with high registers [PR78952] Introduce extract_operator predicate to handle both, zero-extract and sign-extract extract operations with expressions like: (subreg:QI (zero_extract:SWI248 (match_operand 1 "int248_register_operand" "0") (const_int 8) (const_int 8)) 0) As shown in the testcase, this will enable generation of QImode instructions with high registers when signed arguments are used. gcc/ChangeLog: PR target/78952 * config/i386/predicates.md (extract_operator): New predicate. * config/i386/i386.md (any_extract): Remove code iterator. (*cmpqi_ext_1_mem_rex64): Use extract_operator predicate. (*cmpqi_ext_1): Ditto. (*cmpqi_ext_2): Ditto. (*cmpqi_ext_3_mem_rex64): Ditto. (*cmpqi_ext_3): Ditto. (*cmpqi_ext_4): Ditto. (*extzvqi_mem_rex64): Ditto. (*extzvqi): Ditto. (*insvqi_2): Ditto. (*extendqi_ext_1): Ditto. (*addqi_ext_0): Ditto. (*addqi_ext_1): Ditto. (*addqi_ext_2): Ditto. (*subqi_ext_0): Ditto. (*subqi_ext_2): Ditto. (*testqi_ext_1): Ditto. (*testqi_ext_2): Ditto. (*andqi_ext_0): Ditto. (*andqi_ext_1): Ditto. (*andqi_ext_1_cc): Ditto. (*andqi_ext_2): Ditto. (*qi_ext_0): Ditto. (*qi_ext_1): Ditto. (*qi_ext_2): Ditto. (*xorqi_ext_1_cc): Ditto. (*negqi_ext_2): Ditto. (*ashlqi_ext_2): Ditto. (*qi_ext_2): Ditto. gcc/testsuite/ChangeLog: PR target/78952 * gcc.target/i386/pr78952-4.c: New test.
[Bug target/108247] Missed opportunity to generate shNadd on risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108247 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jeffrey A. Law --- Per c#1 and c#2.
[Bug target/108248] Some insns in the risc-v backend do not have mappings to functional units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/108248] Some insns in the risc-v backend do not have mappings to functional units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248 --- Comment #7 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:07e2576d6f344acab338deeb051845c90c1cf6a3 commit r14-116-g07e2576d6f344acab338deeb051845c90c1cf6a3 Author: Raphael Zinsly Date: Thu Apr 20 08:48:08 2023 -0600 [PR target/108248] [RISC-V] Break down some bitmanip insn types This is primarily Raphael's work. All I did was adjust it to apply to the trunk and add the new types to generic.md's scheduling model. The basic idea here is to make sure we have the ability to schedule the bitmanip instructions with a finer degree of control. Some of the bitmanip instructions are likely to have differing scheduler characteristics across different implementations. So rather than assign these instructions a generic "bitmanip" type, this patch assigns them a type based on their RTL code by using the iterator for the type. Naturally we have to add a few new types. It affects clz, ctz, cpop, min, max. We didn't do this for things like shNadd, single bit manipulation, etc. We certainly could if the needs presents itself. I threw all the new types into the generic_alu bucket in the generic scheduling model. Seems as good a place as any. Someone who knows the sifive uarch should probably add these types (and bitmanip) to the sifive scheduling model. We also noticed that the recently added orc.b didn't have a type at all. So we added it as a generic bitmanip type. This has been bootstrapped in a gcc-12 base and I've built and run the testsuite without regressions on the trunk. Given it was primarily Raphael's work I could probably approve & commit it. But I'd like to give the other RISC-V folks a chance to chime in. PR target/108248 gcc/ * config/riscv/bitmanip.md (clz, ctz, pcnt, min, max patterns): Use as the type to allow for fine grained control of scheduling these insns. * config/riscv/generic.md (generic_alu): Add bitmanip, clz, ctz, pcnt, min, max. * config/riscv/riscv.md (type attribute): Add types for clz, ctz, pcnt, signed and unsigned min/max.
[Bug target/109535] [13/14] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535 JuzheZhong changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from JuzheZhong --- fixed
[Bug tree-optimization/109564] [13/14 Regression] libkeccak miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564 --- Comment #17 from Andrew Macleod --- Created attachment 54893 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54893=edit new patch Alternatively, we can simply allow undefined SSA_NAMES to also be checked or single arguments like everything else. We were ignoring SSA_NAMEs that were UNDEFINED when it came to comparing arguments, which allows them to "ignored" basically. I kicked off a build with this patch but I am traveling today so may not be too timely. I think its should also fully resolve this. For the next release I was thinking about adding one way equivalences for PHIs.. or at leats treating ithis situation differently. that is looking like a better idea :-)
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #12 from Puneet B --- Thanks for update , since we are using gcc-2.34 , this need to picked as fix. but do you seen any side impact of this fix which need to be validated?
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #23 from Arthur O'Dwyer ---
(In reply to Jonathan Wakely from comment #22)
>
> Richi suggested that we could avoid these runtime branches (which hurt
> optimization, see PR 109445) if we knew how many bytes of tail padding there
> are in _Tp [...]
> We don't have a built-in to tell us the number of [trailing] padding bytes,
> but we
> might be able to use something like this
Three thoughts that might be helpful:
- There may be padding in the middle of an object, and I'm not confident that
the Standard actually forbids it from being used. Of course your approach works
fine on the Itanium ABI, and probably works everywhere that actually exists. If
you've got chapter+verse proving that it must work *everywhere*, I'd appreciate
seeing it, just for my own information.
- If GCC were ever to add a builtin for this notion, IMO the proper name would
be `__datasizeof(T)`. See
https://danakj.github.io/2023/01/15/trivially-relocatable.html#data-size
- You can implement your library trait like this; see
https://quuxplusone.github.io/blog/2023/03/04/trivial-swap-prize-update/#step-1.-std-swap-can-t-assume-it
template
struct __libcpp_datasizeof {
struct _Up {
[[__no_unique_address__]] _Tp __t_;
char __c_;
};
static const size_t value = __builtin_offsetof(_Up, __c_);
};
Unfortunately it looks like GCC doesn't support
`__attribute__((__no_unique_address__))` in C++03 mode. (Neither does Clang.
What is up with that!)
Your suggested trait implementation is slightly wrong for `is_final` types: you
return 0 but really a final type _can_ have usable tail padding. See
https://godbolt.org/z/P6x459MEq
[Bug libstdc++/107852] [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2e4210698c644e44f9e0645dc7bc49710fd60ce8 commit r12-9457-g2e4210698c644e44f9e0645dc7bc49710fd60ce8 Author: Jonathan Wakely Date: Tue Nov 29 15:50:06 2022 + libstdc++: Avoid bogus warning in std::vector::insert [PR107852] GCC assumes that any global variable might be modified by operator new, and so in the testcase for this PR all data members get reloaded after allocating new storage. By making local copies of the _M_start and _M_finish members we avoid that, and then the compiler has enough info to remove the dead branches that trigger bogus -Warray-bounds warnings. libstdc++-v3/ChangeLog: PR libstdc++/107852 PR libstdc++/106199 PR libstdc++/100366 * include/bits/vector.tcc (vector::_M_fill_insert): Copy _M_start and _M_finish members before allocating. (vector::_M_default_append): Likewise. (vector::_M_range_insert): Likewise. (cherry picked from commit cca06f0d6d76b08ed4ddb7667eda93e2e9f2589e)
[Bug tree-optimization/100366] [11/12 Regression] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366 --- Comment #17 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2e4210698c644e44f9e0645dc7bc49710fd60ce8 commit r12-9457-g2e4210698c644e44f9e0645dc7bc49710fd60ce8 Author: Jonathan Wakely Date: Tue Nov 29 15:50:06 2022 + libstdc++: Avoid bogus warning in std::vector::insert [PR107852] GCC assumes that any global variable might be modified by operator new, and so in the testcase for this PR all data members get reloaded after allocating new storage. By making local copies of the _M_start and _M_finish members we avoid that, and then the compiler has enough info to remove the dead branches that trigger bogus -Warray-bounds warnings. libstdc++-v3/ChangeLog: PR libstdc++/107852 PR libstdc++/106199 PR libstdc++/100366 * include/bits/vector.tcc (vector::_M_fill_insert): Copy _M_start and _M_finish members before allocating. (vector::_M_default_append): Likewise. (vector::_M_range_insert): Likewise. (cherry picked from commit cca06f0d6d76b08ed4ddb7667eda93e2e9f2589e)
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493 --- Comment #31 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e016a6ddbf0038056b9d8f2bc0bad350ff026632 commit r12-9456-ge016a6ddbf0038056b9d8f2bc0bad350ff026632 Author: Jonathan Wakely Date: Tue Apr 4 12:04:14 2023 +0100 libstdc++: Fix outdated docs about demangling exception messages The string returned by std::bad_exception::what() hasn't been a mangled name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the docs showing how to demangle it. libstdc++-v3/ChangeLog: * doc/xml/manual/extensions.xml: Remove std::bad_exception from example program. * doc/html/manual/ext_demangling.html: Regenerate. (cherry picked from commit 688d126b69215db29774c249b052e52d765782b3)
[Bug tree-optimization/106199] [12/13 Regression] incorrect warning: memcpy writing 1 or more bytes into a region of size 0 overflows the destination with std::vector::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2e4210698c644e44f9e0645dc7bc49710fd60ce8 commit r12-9457-g2e4210698c644e44f9e0645dc7bc49710fd60ce8 Author: Jonathan Wakely Date: Tue Nov 29 15:50:06 2022 + libstdc++: Avoid bogus warning in std::vector::insert [PR107852] GCC assumes that any global variable might be modified by operator new, and so in the testcase for this PR all data members get reloaded after allocating new storage. By making local copies of the _M_start and _M_finish members we avoid that, and then the compiler has enough info to remove the dead branches that trigger bogus -Warray-bounds warnings. libstdc++-v3/ChangeLog: PR libstdc++/107852 PR libstdc++/106199 PR libstdc++/100366 * include/bits/vector.tcc (vector::_M_fill_insert): Copy _M_start and _M_finish members before allocating. (vector::_M_default_append): Likewise. (vector::_M_range_insert): Likewise. (cherry picked from commit cca06f0d6d76b08ed4ddb7667eda93e2e9f2589e)
[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387 --- Comment #12 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:24cf9f4c6f45f7d8b37757cdb34576ee5d2d40e1 commit r12-9454-g24cf9f4c6f45f7d8b37757cdb34576ee5d2d40e1 Author: Jonathan Wakely Date: Tue Mar 28 21:07:21 2023 +0100 libstdc++: Do not use facets cached in ios for ALT128 build [PR103387] For the powerpc64le build with two different long double representations, we cannot use the ios_base::_M_num_put and ios_base::_M_num_get pointers, because they might have been initialized in a translation unit using the other long double type. With the changes to add __try_use_facet to GCC 13 the cache isn't really needed now, we can just access the right facet in the locale directly, without needing RTTI checks. libstdc++-v3/ChangeLog: PR libstdc++/103387 * include/bits/istream.tcc (istream::_M_extract(ValueT&)): Use std::use_facet instead of cached _M_num_get facet. (istream::operator>>(short&)): Likewise. (istream::operator>>(int&)): Likewise. * include/bits/ostream.tcc (ostream::_M_insert(ValueT)): Use std::use_facet instead of cached _M_num_put facet. (cherry picked from commit ec12639c82e944d37200a744156e183ea19add00)
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #22 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> const ptrdiff_t _Num = __last - __first;
> - if (_Num)
> + if (__builtin_expect(_Num > 1, true))
> __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
> + else if (_Num == 1)
Richi suggested that we could avoid these runtime branches (which hurt
optimization, see PR 109445) if we knew how many bytes of tail padding there
are in _Tp, e.g.,
__builtin_memmove(__result, __first, sizeof(_Tp) * _Num - __padding_bytes);
This would mean we copy whole objects for the first Num - 1 elements, and then
only copy the non-padding bytes for the last element. This would be conforming,
because there's no guarantee that padding bits are copied by assignment anyway,
and std::copy is specified in terms of assignment.
When copying a single base-class object (the subject of this bug) the last
element is the only element, so we solve the problem.
We don't have a built-in to tell us the number of padding bytes, but we might
be able to use something like this:
template
constexpr size_t
potentially_overlapping_tail_padding()
{
if constexpr (is_final::value)
return 0;
else
{
struct D1 : T
{
char c1;
};
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Winvalid-offsetof"
return sizeof(T) - offsetof(D1, c1);
#pragma GCC diagnostic pop
}
}
For pre-C++17 we would need to use tag dispatching and __is_final instead of
if-constexpr, but that's doable. For pre-C++14 it can't be constexpr, but
that's OK too.
[Bug c++/109571] New: potential null pointer dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571
Bug ID: 109571
Summary: potential null pointer dereference
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat test.cpp
#include
struct A
{
int i = 0;
};
struct B: A
{
virtual ~B ();
};
struct C
{
std::vector v;
virtual ~C () { for (A *a: v) a->i++; }
};
int main ()
{
C c;
}
% gcc --std=c++20 -c -Wall -Wnull-dereference -O3 test.cpp
test.cpp: In destructor ‘C::~C()’:
test.cpp:16:36: warning: potential null pointer dereference
[-Wnull-dereference]
16 | virtual ~C () { for (A *a: v) a->i++; }
| ~~~^
test.cpp:16:37: warning: potential null pointer dereference
[-Wnull-dereference]
16 | virtual ~C () { for (A *a: v) a->i++; }
| ^~
In destructor ‘virtual C::~C()’,
inlined from ‘virtual C::~C()’ at test.cpp:16:41:
test.cpp:16:36: warning: potential null pointer dereference
[-Wnull-dereference]
16 | virtual ~C () { for (A *a: v) a->i++; }
| ~~~^
test.cpp:16:37: warning: potential null pointer dereference
[-Wnull-dereference]
16 | virtual ~C () { for (A *a: v) a->i++; }
|
Of course, strictly speaking any pointer dereference is *potentially* a null
pointer dereference, but there's no particular reason to assume one here. (In
fact, when making v private, the compiler could actually know that v will
always be empty, but still warns.)
Even more stragely, this warning depends on many factors that have nothing to
do with the elements by v being null or not, such as both the calling function
and some function in B being virtual, the for-loop variable being A* (not B*)
etc.
My actual code is of course more complex, so I'd like to understand what's
actually causing this warning, so I can avoid it. (Or should I just disable
it?)
And why is the same warning given 4 times?
[Bug analyzer/109570] detect fclose on unopened or NULL files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
--- Comment #1 from Ivan Sorokin ---
Generalizing. Perhaps similarly free(NULL) can be detected?
void* obj = malloc(...);
if (!obj)
{
free(obj);
return false;
}
Unliky fclose(NULL), free(NULL) is completely well defined operation, but it
does nothing and perhaps should be removed.
[Bug analyzer/109570] New: detect fclose on unopened or NULL files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
Bug ID: 109570
Summary: detect fclose on unopened or NULL files
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
While cleaning up one not particularly well written program I noticed this code
fragment:
FILE* file = fopen(...);
if (!file)
{
fclose(file);
return false;
}
Passing NULL to fclose is undefined behavior. Perhaps -fanalyzer could warn
about code like this?
[Bug libstdc++/109568] [12/13/14 Regression] Spurious "potential null pointer dereference" in shared_ptr_base.h with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568 --- Comment #5 from zed.three at gmail dot com --- Ah ok, I see the whole thing now. It still feels like a confusing warning, but it seems reasonable that there isn't much that can be done about it.
[Bug target/109535] [13/14] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535 --- Comment #10 from CVS Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:a2d12abedc89a9439fd6aadc38730fdadca0684f commit r14-113-ga2d12abedc89a9439fd6aadc38730fdadca0684f Author: Ju-Zhe Zhong Date: Wed Apr 19 18:41:51 2023 +0800 RISC-V: Fix wrong check of register occurrences [PR109535] count_occurrences will conly count same RTX (same code and same mode), but what we want to track is the occurrence of a register, a register might appeared in the insn with different mode or contain in SUBREG. Testcase coming from Kito. gcc/ChangeLog: PR target/109535 * config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New function. (pass_vsetvl::cleanup_insns): Fix bug. gcc/testsuite/ChangeLog: PR target/109535 * g++.target/riscv/rvv/base/pr109535.C: New test. * gcc.target/riscv/rvv/base/pr109535.c: New test. Signed-off-by: Ju-Zhe Zhong Co-authored-by: kito-cheng
[Bug tree-optimization/109546] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-3596-ge7310e24b1c0ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546 Martin Liška changed: What|Removed |Added CC||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Summary|[13/14 Regression] Missed |[13/14 Regression] Missed |Dead Code Elimination when |Dead Code Elimination when |using __builtin_unreachable |using __builtin_unreachable ||since ||r13-3596-ge7310e24b1c0ca --- Comment #1 from Martin Liška --- Started with r13-3596-ge7310e24b1c0ca.
[Bug target/109535] [13/14] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535 Kito Cheng changed: What|Removed |Added Target Milestone|--- |13.2 Summary|internal compiler error: in |[13/14] internal compiler |finalize_new_accesses, at |error: in |rtl-ssa/changes.cc:471 |finalize_new_accesses, at ||rtl-ssa/changes.cc:471
[Bug tree-optimization/105651] [12 Regression] bogus "may overlap" memcpy warning with std::string and operator+ at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651 Jonathan Wakely changed: What|Removed |Added CC||jvb at cyberscience dot com --- Comment #26 from Jonathan Wakely --- *** Bug 105545 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/105545] [12/13/14 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #11 from Jonathan Wakely --- It was fixed by r13-2618-g723ef5a937dbab so let's close this as a dup of PR 105651 *** This bug has been marked as a duplicate of bug 105651 ***
[Bug tree-optimization/109564] [13/14 Regression] libkeccak miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564 --- Comment #16 from Richard Biener --- (In reply to Richard Biener from comment #15) > Created attachment 54892 [details] > patch I am testing Bootstrapped and tested on x86_64-unknown-linux-gnu, the XFAILs of gcc.dg/pr102648.c and gcc.dg/pr103359.c are not necessary. > This is the patch I am testing which XFAILs the four testcases. It would be > nice to somehow recover the unexecutable edge cases and somehow distinguish > them from UNDEFINED arguments. I'm not sure if ranger has anything to > track that besides relying on UNDEFINED being propagated as range across such > edges?
[Bug c++/109569] warning: ‘void* __builtin_memmove(void*, const void*, long unsigned int)’ writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569 --- Comment #7 from Jonathan Wakely --- Probably either PR 105329 or PR 105651
[Bug c++/109569] warning: ‘void* __builtin_memmove(void*, const void*, long unsigned int)’ writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569 --- Comment #6 from Frank Heckenbach --- (In reply to Frank Heckenbach from comment #4) > Thanks. > > I just got another similar one, this time with string.insert. But I guess > it's pointless to dissect this one, or do you need more examples for your > test suite? Actually, on a closer look, this one is a bit different. Do you need an example for that, or should it also be fixed in trunk? In static member function 'static constexpr std::char_traits::char_type* std::char_traits::copy(char_type*, const char_type*, std::size_t)', inlined from 'static constexpr void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /usr/include/c++/12/bits/basic_string.h:423:21, inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits, _Allocator>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_replace(size_type, size_type, const _CharT*, size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /usr/include/c++/12/bits/basic_string.tcc:532:22, inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::replace(size_type, size_type, const _CharT*, size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /usr/include/c++/12/bits/basic_string.h:2171:19, inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::insert(size_type, const _CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /usr/include/c++/12/bits/basic_string.h:1928:22, inlined from 'std::string mpf_to_string(mpf_class, size_t)' at pi.cpp:102:12: /usr/include/c++/12/bits/char_traits.h:431:56: error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' accessing 9223372036854775810 or more bytes at offsets -4611686018427387902 and [-4611686018427387903, 4611686018427387904] may overlap up to 9223372036854775813 bytes at offset -3 [-Werror=restrict] 431 | return static_cast(__builtin_memcpy(__s1, __s2, __n)); | ^
[Bug c++/109569] warning: ‘void* __builtin_memmove(void*, const void*, long unsigned int)’ writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569 --- Comment #5 from Jonathan Wakely --- So it's a dup of one of these: PR libstdc++/107852 PR libstdc++/106199 PR libstdc++/100366
[Bug c++/109569] warning: ‘void* __builtin_memmove(void*, const void*, long unsigned int)’ writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569 --- Comment #4 from Frank Heckenbach --- Thanks. I just got another similar one, this time with string.insert. But I guess it's pointless to dissect this one, or do you need more examples for your test suite?
[Bug c++/109569] warning: ‘void* __builtin_memmove(void*, const void*, long unsigned int)’ writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569 Jonathan Wakely changed: What|Removed |Added Keywords|needs-bisection | --- Comment #3 from Jonathan Wakely --- Fixed by r13-4393-gcca06f0d6d76b0
[Bug libstdc++/109568] [12/13/14 Regression] Spurious "potential null pointer dereference" in shared_ptr_base.h with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568 --- Comment #4 from Jakub Jelinek --- (In reply to zed.three from comment #3) > But should the warning not be on the `var_ref->empty()` call itself then, > instead of inside `shared_ptr::operator==`? I guess that it's ultimately > triggered by the implicit `this` in accessing `_M_ptr`, but it would be more > obvious it it were bubbled up to `var_ref` The method is inlined and the warning is diagnosed only after that happens, so it diagnoses it on the actual (potential, it isn't unconditional) null pointer dereference it sees at that point.
[Bug libstdc++/109568] [12/13/14 Regression] Spurious "potential null pointer dereference" in shared_ptr_base.h with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568 --- Comment #3 from zed.three at gmail dot com --- Ah, I see what you mean. Putting in a guard clause if (!var_ref) return false; does indeed silence the warning. But should the warning not be on the `var_ref->empty()` call itself then, instead of inside `shared_ptr::operator==`? I guess that it's ultimately triggered by the implicit `this` in accessing `_M_ptr`, but it would be more obvious it it were bubbled up to `var_ref`
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #11 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the > weak refs in gthr-posix.h I think that is indeed the correct fix, as you originally asked about. But only for glibc 2.34 and later.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #10 from Jonathan Wakely --- Ah, it works for C++ because of r12-5108-g80fe172ba98201 With a recent glibc __gthread_cond_timedwait just calls pthread_cond_timedwait directly, so use correctly redirected to __pthread_cond_timedwait64. If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the weak refs in gthr-posix.h
[Bug c++/109569] warning: ‘void* __builtin_memmove(void*, const void*, long unsigned int)’ writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Known to work||13.0 Known to fail||12.2.0 Last reconfirmed||2023-04-20 Keywords||needs-bisection Status|UNCONFIRMED |NEW --- Comment #2 from Richard Biener --- I think it's a false positive, GCC 13 no longer diagnoses this so it's likely a duplicate of another bug. Might be either suppressed in libstdc++ or avoided in the diagnostic code.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2023-04-20 --- Comment #9 from Jonathan Wakely --- It works correctly with 10.4.1 and 11.3.0 and 12.1.0 so it looks like this isn't true: (In reply to Puneet B from comment #3) > It can be reproduceable in gcc master branch or latest release..dont look at > it as GCC particular version bug. You haven't provided a testcase though, so we don't know what you're seeing.
