[Bug c++/102600] [modules] ICE Segmentation fault during GIMPLE pass evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102600 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-05 CC||nathan at gcc dot gnu.org Known to fail||11.2.1 --- Comment #1 from Richard Biener --- Confirmed. The enumeral type 'byte' ends up without TYPE_MIN/MAX_VALUE which are eventually not streamed to the module or not re-built at read-in time. I do see TYPE_MIN/MAX_VALUE being processed in the module code so it must go wrong elsewhere (maybe at write-out time they are not present?).
[Bug c++/102593] [10/11/12 Regression] ICE in cp_oacc_check_attachments, at cp/semantics.c:6561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102593 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2
[Bug target/102591] Failure to optimize search for value in vector-sized area to use SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102591 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-10-05 Status|UNCONFIRMED |WAITING --- Comment #1 from Richard Biener --- Hmm, but __builtin_memcpy(&values, tpl, 16); could trap since 'tpl' is not aligned to 16 bytes? So LLVM creates wrong code here?
[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540 --- Comment #7 from rguenther at suse dot de --- On Mon, 4 Oct 2021, amacleod at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540 > > --- Comment #6 from Andrew Macleod --- > > > > > > It removes a > > > relationship between c_10 and _2. The reason ranger no longer can fold _2 > > > == 0 > > > is because the sequence is now: > > > > > > a.0_1 = a; > > > _2 = (unsigned int) a.0_1; > > > b = _2; > > > _6 = a.0_1 & 4294967295; > > > c_10 = _6; > > > if (c_10 != 0) > > > goto ; [INV] > > > > > > We do not find _2 is non-zero on the outgoing edge because _2 is not > > > related to > > > the calculation in the condition. (ie c_10 no longer has a dependency on > > > _2) > > > > > > We do recalculate _2 based on the outgoing range of a.0_1, but with it > > > being a > > > 64 bit value and _2 being 32 bits, we only know the outgoing range of > > > a.0_1 is > > > non-zero.. we dont track any of the upper bits... > > > 2->3 (T) a.0_1 : long int [-INF, -1][1, +INF] > > > And when we recalculate _2 using that value, we still get varying because > > > 0x in not zero, but can still produce a zero in _2. > > > > > > The problem is that the condition c_10 != 0 no longer related to the > > > value of > > > _2 in the IL... so ranger never sees it. and we cant represent the 2^16 > > > subranges that end in [1,0x]. > > > > > > Before that transformation, > > > _2 = (unsigned int) a.0_1; > > >b = _2; > > > c_10 = (long int) _2; > > > The relationship is obvious, and ranger would relate the c_10 != 0 to _2 > > > no > > > problem. > > > > I see - too bad. Note the transform made the dependence chain of _6 > > one instruction shorter without increasing the number of instructions > > so it's a profitable transform. > > > > Btw, the relation is still there but only indirectly via a.0_1. The > > old (E)VRP had this find_asserts(?) that produced assertions based > > on the definitions - sth that now range-ops does(?), so it would > > eventually have built assertions for a.0_1 for both conditions and > > allow relations based on that? I can't seem to find my way around > > the VRP code now - pieces moved all over the place and so my mind > > fails me on the searching task :/ > > We do know that a.0_1 is non-zero on that edge: > 2->3 (T) a.0_1 : long int [-INF, -1][1, +INF] > > the problem is that we can't currently represent that the bitmask operation > causes all patterns ending in 0x to not occur.. we just leave it at > ~[0,0]. which isn't sufficient for this use case. Hmm, but we do have nonzero bits on SSA where we also store global ranges, so there is a way to store the info and you could intersect the sliced range produced from it with the range you got? > we don't currently track any equivalences between values of different > precision.. (even though ranger once did). Handling it as a general > equivalence was fraught with issues. > > We might be able to add a new equivalence class "slice" or something.. I had > considered it but hadn't seen a great need case. This would make _6 a 32 bit > slice of a.0_1 with range [1, 0x]. > Then when we are querying for the cast > _2 = (unsigned int) a.0_1; > we could also query the 32 bit equivalence slices of a.0_1, find _6, and get > the outgoing range of [1,0x].. and apply that value. > > It would probably resolve an entire class of things where we don't recognize > an > equivalence between a cast and a bitmask of equivalent precision. > > This would also mean the reverse would apply.. ie if we instead branched on _2 > != 0 we would also understand that _6 will be non-zero. I believe tracking known zero/one bits in addition to a range is more useful - would that help in this case?
[Bug c++/84469] GCC rejects valid code in structured binding in range-based-for in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469 Andrew Pinski changed: What|Removed |Added CC||1997.rajatjain at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 102590 has been marked as a duplicate of this bug. ***
[Bug c++/102590] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102590 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Dup of bug 84469. *** This bug has been marked as a duplicate of bug 84469 ***
[Bug c++/102590] structured binding inside for all loop thinks it is type depedent when it is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102590
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||rejects-valid
Summary|Templated operations on |structured binding inside
|variables in structured |for all loop thinks it is
|binding don't work when |type depedent when it is
|templated functions/lambdas |not.
|require type deduction |
Ever confirmed|0 |1
Last reconfirmed||2021-10-05
--- Comment #3 from Andrew Pinski ---
Reduced testcase (without any includes):
struct Foo
{
template T get() const { return 0; }
};
struct f
{
int t;
Foo t1;
};
template
void error_func(T elem)
{
f arr[1];
for(const auto& [_, val] : arr)
{
val.get(); // Error here
}
}
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 H.J. Lu changed: What|Removed |Added Attachment #51549|0 |1 is obsolete|| --- Comment #13 from H.J. Lu --- Created attachment 51551 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51551&action=edit The v4 patch Please try the v4 patch.
[Bug libgcc/102601] [maybe not a bug] libgcc requires pthread.h even i use --disable-thread --without-headers --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102601 cqwrteur changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from cqwrteur --- use this for mailing list to send file.
[Bug libgcc/102601] [maybe not a bug] libgcc requires pthread.h even i use --disable-thread --without-headers --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102601 --- Comment #1 from cqwrteur --- In file included from ../../../../../../gcc/libgcc/gthr.h:148, from ../../../../../../gcc/libgcc/libgcov-interface.c:27: ./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory 35 | #include | ^~~ compilation terminated. In file included from ../../../../../../gcc/libgcc/gthr.h:148, from ../../../../../../gcc/libgcc/libgcov-interface.c:27: ./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory 35 | #include | ^~~
[Bug libgcc/102601] New: [maybe not a bug] libgcc requires pthread.h even i use --disable-thread --without-headers --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102601 Bug ID: 102601 Summary: [maybe not a bug] libgcc requires pthread.h even i use --disable-thread --without-headers --disable-shared Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 51550 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51550&action=edit config.log what's wrong with my cross build? I did that successfully before, did recent updates on GCC break something here? Or i just do things wrong??
[Bug libstdc++/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 --- Comment #6 from cqwrteur --- (In reply to cqwrteur from comment #5) > actually a lot of dlls are not copied correctly. > > libstdc++-6.dll libatomic.dll libquadmath.dll libssp.dll are all copied with > 32 bit dlls. > > And libgcc_seh.dll is not copied. > > I think the copy to bin behavior should be removed. It should be just like > normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32. or just provide a toggle for not copying DLLs. thank you
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 --- Comment #12 from Thiago Macieira --- Commit 7e0c0500808d58bca5b8e23cbd474022c32234e4 + your patch.
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #11 from Thiago Macieira ---
$ for ((i=0;i<32;++i)); do ~/dev/gcc/bin/gcc "-DCONSTANT=(1<<$i)" -S -o - -O2
/tmp/test.cpp | grep bts; done
lock btsl $0, (%rdi)
lock btsl $1, (%rdi)
lock btsl $2, (%rdi)
lock btsl $3, (%rdi)
lock btsl $4, (%rdi)
lock btsl $5, (%rdi)
lock btsl $6, (%rdi)
lock btsl $7, (%rdi)
lock btsl $8, (%rdi)
lock btsl $9, (%rdi)
lock btsl $10, (%rdi)
lock btsl $11, (%rdi)
lock btsl $12, (%rdi)
lock btsl $13, (%rdi)
lock btsl $14, (%rdi)
lock btsl $15, (%rdi)
lock btsl $16, (%rdi)
lock btsl $17, (%rdi)
lock btsl $18, (%rdi)
lock btsl $19, (%rdi)
lock btsl $20, (%rdi)
lock btsl $21, (%rdi)
lock btsl $22, (%rdi)
lock btsl $23, (%rdi)
lock btsl $24, (%rdi)
lock btsl $25, (%rdi)
lock btsl $26, (%rdi)
lock btsl $27, (%rdi)
lock btsl $28, (%rdi)
lock btsl $29, (%rdi)
lock btsl $30, (%rdi)
lock btsl $31, (%rdi)
And after changing to long:
$ for ((i=32;i<64;++i)); do ~/dev/gcc/bin/gcc "-DCONSTANT=(1L<<$i)" -S -o - -O2
/tmp/test.cpp | grep bts; done
lock btsq $32, (%rdi)
lock btsq $33, (%rdi)
lock btsq $34, (%rdi)
lock btsq $35, (%rdi)
lock btsq $36, (%rdi)
lock btsq $37, (%rdi)
lock btsq $38, (%rdi)
lock btsq $39, (%rdi)
lock btsq $40, (%rdi)
lock btsq $41, (%rdi)
lock btsq $42, (%rdi)
lock btsq $43, (%rdi)
lock btsq $44, (%rdi)
lock btsq $45, (%rdi)
lock btsq $46, (%rdi)
lock btsq $47, (%rdi)
lock btsq $48, (%rdi)
lock btsq $49, (%rdi)
lock btsq $50, (%rdi)
lock btsq $51, (%rdi)
lock btsq $52, (%rdi)
lock btsq $53, (%rdi)
lock btsq $54, (%rdi)
lock btsq $55, (%rdi)
lock btsq $56, (%rdi)
lock btsq $57, (%rdi)
lock btsq $58, (%rdi)
lock btsq $59, (%rdi)
lock btsq $60, (%rdi)
lock btsq $61, (%rdi)
lock btsq $62, (%rdi)
lock btsq $63, (%rdi)
But:
$ cat /tmp/test2.cpp
#include
bool tbit(std::atomic &i)
{
return i.fetch_or(1, std::memory_order_relaxed) & (~1);
}
$ ~/dev/gcc/bin/gcc -S -o - -O2 /tmp/test2.cpp
.file "test.cpp"
.text
/tmp/test.cpp: In function ‘bool tbit(std::atomic&)’:
/tmp/test.cpp:2:6: error: type mismatch in binary expression
2 | bool tbit(std::atomic &i)
| ^~~~
long int
long unsigned int
__int_type
_9 = _6 & -2;
during GIMPLE pass: fab
/tmp/test.cpp:2:6: internal compiler error: verify_gimple failed
0x119fbba verify_gimple_in_cfg(function*, bool)
/home/tjmaciei/src/gcc/gcc/tree-cfg.c:5576
0x106ced7 execute_function_todo
/home/tjmaciei/src/gcc/gcc/passes.c:2042
0x106d8fb execute_todo
/home/tjmaciei/src/gcc/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101807 --- Comment #4 from Andrew Pinski --- related to PR 101807
[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185 Arjun Shankar changed: What|Removed |Added CC||arjun.is at lostca dot se --- Comment #3 from Arjun Shankar --- If the code is compiled as C, gcc produces essentially the same code as clang with some differences in the schedule of instructions: https://godbolt.org/z/8nsq16Pen It's when the code is compiled as C++ that gcc does worse: https://godbolt.org/z/dK8hTEhjr The difference lies in the front-ends. The C front-end already appears to know that this is a XOR. testcase.c.004t.original looks like: return (int) (x < 0 ^ y <= 0); On the other hand, g++ outputs: return = x >= 0 == y <= 0;
[Bug c++/102600] New: [modules] ICE Segmentation fault during GIMPLE pass evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102600
Bug ID: 102600
Summary: [modules] ICE Segmentation fault during GIMPLE pass
evrp
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
main.cpp:
```C++
import;
void push(std::byte) {}
void write(char v) { push(static_cast(v)); }
int main() { write(char{}); }
```
Compile commands:
```
gcc -std=c++23 -O3 -fmodules-ts -x c++-system-header -c cstddef
gcc -std=c++23 -O3 -fmodules-ts -c main.cpp
```
Output:
```
during GIMPLE pass: evrp
main.cpp: In function ‘void write(char)’:
main.cpp:4:29: internal compiler error: Segmentation fault
4 | int main() { write(char{}); }
| ^
0x2068f9d internal_error(char const*, ...)
???:0
0xca4c68 wi::to_wide(tree_node const*)
???:0
0x1f85553 operator_cast::inside_domain_p(generic_wide_int
const&, generic_wide_int const&, irange const&) const
???:0
0x1f8c51d operator_cast::fold_pair(irange&, unsigned int, irange const&, irange
const&) const
???:0
0x1f8cb6a operator_cast::fold_range(irange&, tree_node*, irange const&, irange
const&, tree_code) const
???:0
0x1e723b0 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
???:0
0x1e73142 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
???:0
0x1e67484 gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
???:0
0x1e681ff gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
???:0
0x14ec2f1 range_query::value_of_expr(tree_node*, gimple*)
???:0
0x1e7bda8 rvrp_folder::value_of_expr(tree_node*, gimple*)
???:0
0x138eebe substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
???:0
0x1e37697 dom_walker::walk(basic_block_def*)
???:0
0x138e03d substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 H.J. Lu changed: What|Removed |Added Attachment #51543|0 |1 is obsolete|| --- Comment #10 from H.J. Lu --- Created attachment 51549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51549&action=edit The v3 patch Please try the v3 patch.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #28 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #21)
> Reduced testcase:
>
> int
> qy (void)
> {
> int tw = 4;
> int fb[tw];
> return fb[2];
> }
For this reduced testing case, if compiled with
/home/opc/Install/latest/bin/gcc -c -O -ftrivial-auto-var-init=zero
-fdump-tree-all t.c
**t.c.032t.cpp1:
int qy (int l9)
{
unsigned char fb.3[16];
int tw;
int[0:D.1984] * fb.1;
sizetype D.1984;
void * saved_stack.2_16;
int _27;
:
saved_stack.2_16 = __builtin_stack_save ();
fb.1_25 = &fb.3;
(*fb.1_25) = .DEFERRED_INIT (16, 2, 1);
_27 = (*fb.1_25)[2];
..
}
**t.c.033t.forwprop1:
int qy (int l9)
{
unsigned char fb.3[16];
int tw;
int[0:D.1984] * fb.1;
sizetype D.1984;
void * saved_stack.2_16;
int _27;
:
saved_stack.2_16 = __builtin_stack_save ();
MEM[(int[0:D.1984] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);
_27 = MEM[(int[0:D.1984] *)&fb.3][2];
..
}
the problem with the above IR for .DEFERRED_INIT expansion is:
for MEM[(int[0:D.1984] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);
after the "ccp" and "forwprop", the original VLA *fb.1 is replaced with the the
new fixed array &fb.3, however, the VAR_TYPE still is the old VLA type
int[0:D.1984]. if we can replace the var_type to the new "unsigned char [16]"
for both the LHS and the call to .DEFERRED_INIT. then expansion through
assign_expand should work.
We might need to special handling the LHS to get the new type for "fb.3"
instead of the old "var_type" for "assign_expand".
[Bug fortran/102599] Wrong simplification of inquiry parameters for complex arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102599 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from anlauf at gcc dot gnu.org --- Replacing real,parameter :: r(*) = x%re real,parameter :: i(*) = x%im by real,parameter :: r(*) = real (x) real,parameter :: i(*) = imag (x) fixes things. Similarly, the scalar variant real,parameter :: y= real (x(1)) real,parameter :: z= imag (x(1)) print *, y, z works fine, but real,parameter :: y= x(1)%re real,parameter :: z= x(1)%im print *, y, z ICEs in trans-array::gfc_get_descriptor_field, since we miss the simplification.
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588 Andrew Pinski changed: What|Removed |Added URL|https://buildd.debian.org/s | |tatus/fetch.php?pkg=openori | |enteering-mapper&arch=sparc | |64&ver=0.9.5-1&stamp=163312 | |0814&raw=0 | --- Comment #4 from Andrew Pinski --- https://buildd.debian.org/status/fetch.php?pkg=openorienteering-mapper&arch=sparc64&ver=0.9.5-1&stamp=1633120814&raw=0
[Bug c++/102593] [10/11/12 Regression] ICE in cp_oacc_check_attachments, at cp/semantics.c:6561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102593 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.4
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 qinzhao at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #27 from qinzhao at gcc dot gnu.org --- since the call to MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1); is NOT expanded at all during RTL expansion phase, The auto variable "int fb[tw]"; is not initialized to zero with this patch, which is not what we want. So, I think that we might need to reconsider the patch for this bug. I'm reopening this bug for a further discussion.
[Bug fortran/102596] [11/12 Regression] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102596 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.3
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #26 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #25)
> (In reply to Richard Biener from comment #22)
> > Hmm, my proposed patch seems to work. I've adjusted it to not regress
> > previously correctly handled cases and will test it fully.
>
> I guess the reason for it worked for you because you tested it after the
> patch for 102587?
>
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -3035,7 +3035,8 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
>/* Expand this memset call. */
>expand_builtin_memset (m_call, NULL_RTX, TYPE_MODE (var_type));
> }
> - else
> + /* ??? Deal with poly-int sized registers. */
> + else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type)))
> {
>/* If this variable is in a register, use expand_assignment might
> generate better code. */
because for the following IR:
MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);
The "var_type" of the LHS is "int[0:D.1993]", which is not an integer constant
(even though the type for fb.3 should be the new type for the new temporary
variable char[16]).
As a result, the new added check
> + /* ??? Deal with poly-int sized registers. */
> + else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type)))
excluded it from expanding through expand_assign.
[Bug fortran/93148] Pointer-function-result as LVALUE variable – function called multiple times with copy-in/out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93148 --- Comment #3 from Tobias Burnus --- Additionally, it seems as if the contiguous check used for gfortran.dg/contiguous_10.f90 currently unconditionally copies in the data – which causes a problem when the pointer address escapes. (Okay, whether that works is implementation defined per F2018:15.5.2.4 paragraph 9, but it is still a missed optimizion.) – Lightly related to the issue above as the issue shows up with copy-in/copy-out. Possible fix - which causes a multi-call issue for gfortran.dg/contiguous_10.f90, see previous comment: --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -6528,5 +6528,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, gfc_conv_subref_array_arg (&parmse, e, nodesc_arg, fsym->attr.intent, -fsym->attr.pointer); +fsym->attr.pointer, fsym, +sym->name, NULL, +/* check_contiguous= */ true); } else
[Bug fortran/102599] New: Wrong simplification of inquiry parameters for complex arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102599
Bug ID: 102599
Summary: Wrong simplification of inquiry parameters for complex
arrays
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
Consider:
program p
implicit none
complex, parameter :: x(2) = 1
real,parameter :: r(*) = x%re
real,parameter :: i(*) = x%im
print *, r,all(r== 1) ! wrong
print *, i,all(i== 0) ! wrong
print *, x%re, all(x%re == 1) ! OK
print *, x%im, all(x%im == 0) ! OK
end
This prints:
1. 0. T
1. 0. F
1. 1. T
0. 0. T
The first two lines should be identical to the last two.
The dump-tree has:
static real(kind=4) r[2] = {__complex__ (1.0e+0, 0.0), __complex__ (1.0e+0,
0.0)};
static real(kind=4) i[2] = {__complex__ (1.0e+0, 0.0), __complex__ (1.0e+0,
0.0)};
static complex(kind=4) x[2] = {__complex__ (1.0e+0, 0.0), __complex__
(1.0e+0, 0.0)};
which is nonsense for r, i.
Furthermore, all(x%re == 1) and all(x%im == 0) are not simplified, but that's
another story...
[Bug c++/102528] Unused out-of-line functions emitted for trivial coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528 --- Comment #5 from Iain Sandoe --- hmm let me see if I can reproduce this (I didn't see it in my earlier tests): .L41: ud2 test(): ret which would make things look somewhat strange indeed (the functions are all TU-local - so absent a reference, the 'normal' processes should elide them.
[Bug fortran/93148] Pointer-function-result as LVALUE variable – function called multiple times with copy-in/out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93148 --- Comment #2 from Tobias Burnus --- Also when looking at gfc_conv_subref_array_arg – the function is called seemingly up to 3 times – once per: * gfc_conv_loop_setup (&loop, &expr->where); which calls gfc_conv_loop_setup → gfc_conv_loop_setup → gfc_conv_procedure_call → gfc_trans_create_temp_array * gfc_conv_expr (&lse, expr); * gfc_conv_is_contiguous_expr (&cont_se, expr); (which calls: "gfc_conv_expr_descriptor (&array_se, expr);")
[Bug c++/102528] Unused out-of-line functions emitted for trivial coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528 --- Comment #4 from Iain Sandoe --- note I looked at master (trunk) and 11.2.
[Bug c++/102528] Unused out-of-line functions emitted for trivial coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528 --- Comment #3 from Iain Sandoe --- (In reply to Mathias Stearn from comment #0) > https://godbolt.org/z/aoab9W4xG > > This should all compile away, and test() should just be a single ret > instruction. That is not what happens now, even with -O3. Hi Mathias, Yes, ideally, that would be the case - so I agree it's a missed optimisation. On the other hand, to say that the emitted code is unused is not quite right; We inline the ramp but fail to inline the 'actor' (i.e. the resume). GCC does not have 'halo' coroutine frame elision, so that we create a frame in the inlined ramp, and that holds references to the resumer and destroyer. The net result is that all the code is "used" in the sense that it is referred to by the emitted test (). I have an idea (old not new) about altering the internal interfaces in the generated code to avoid a devirtualisation being necessary to see the inline opportunity - although I cannot be sure that this is the effect in play, it seems plausible. -- so the bottom line is that this is a failure to inline rather than a failure to elide unused code.
[Bug c++/102528] Unused out-of-line functions emitted for trivial coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2021-10-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Iain Sandoe --- (In reply to Mathias Stearn from comment #0) > https://godbolt.org/z/aoab9W4xG > > This should all compile away, and test() should just be a single ret > instruction. That is not what happens now, even with -O3.
[Bug c++/102598] [modules] ICE in pp_string, at pretty-print.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102598 --- Comment #1 from Johel Ernesto Guerrero Peña --- Attempts to reduce another wrong-code bug lead to this.
[Bug c++/33925] [10/11/12 Regression] gcc -Waddress lost some useful warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925 Martin Sebor changed: What|Removed |Added Keywords||patch Known to fail||11.2.0, 12.0, 4.1.0 Summary|gcc -Waddress lost some |[10/11/12 Regression] gcc |useful warnings |-Waddress lost some useful ||warnings --- Comment #9 from Martin Sebor --- As noted in comment 1, this is a regression. Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580899.html
[Bug tree-optimization/102571] FAIL: libgomp.c/../libgomp.c-c++-common/atomic-21.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102571
Jakub Jelinek changed:
What|Removed |Added
Component|libgomp |tree-optimization
--- Comment #1 from Jakub Jelinek ---
Seems like tree DSE bug to me.
We have before dse1:
D.2119 = 0.0;
MEM [(long double *)&D.2119 + 10B] = {};
__builtin_GOMP_atomic_start ();
_58 = MEM[(long double * {ref-all})&ld];
D.2118 = _58;
MEM [(long double *)&D.2118 + 10B] = {};
_13 = __builtin_memcmp (&D.2118, &D.2119, 16);
where D.2119 and D.2118 have long double type.
But dse1 says:
Deleted redundant store: MEM [(long double *)&D.2119 + 10B] = {};
and removes that store, but that isn't really redundant, because long double
has padding bits.
For OpenMP, perhaps I could get away around this and if I prove the non-padding
bits in the type are contiguous followed by padding bits the boundary between
the two is on a byte boundary, I could optimize the
__builtin_clear_padding (&arg1); __builtin_clear_padding (&arg2); x =
__builtin_memcmp (&arg1, &arg2, 16); // or 12 for ia32 into just
x = __builtin_memcmp (&arg1, &arg2, 10);
(and I'll probably implement it tomorrow).
But it won't really help libstdc++, which will once the
https://gcc.gnu.org/pipermail/libstdc++/2021-September/053210.html patch is in,
use __builtin_clear_padding + __atomic_*, most likely in different inline
functions and will almost certainly suffer from this.
In
val = 0;
MEM ... [&val + ...] = {};
the second stmt is only redundant if the type doesn't have any padding bits...
I guess gimple-fold.c could provide an even cheaper helper whether the type has
padding bits than what is currently provided.
Then there is the question on unions, __builtin_clear_padding needs to be
conservative for unions and only clear bits that are proven to be padding in
all union members. But to disable the DSE optimization, we probably need to
ask a different question, instead of "does the type have any padding bits that
would be cleared by __builtin_clear_padding?" ask "can the type have any
padding bits?" where for unions the answer would be true if any member has them
rather than if all the members have them in the same positions.
[Bug c++/102598] New: [modules] ICE in pp_string, at pretty-print.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102598
Bug ID: 102598
Summary: [modules] ICE in pp_string, at pretty-print.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/3rGTTr6jE.
write.cpp:
```C++
export module write;
export void write(const auto &v) {}
```
main.cpp:
```C++
import write;
int main() { write(char{}); }
```
Compile commands:
```
gcc -Wall -Wextra -fmodules-ts -std=c++23 -c write.cpp
gcc -Wall -Wextra -fmodules-ts -std=c++23 -c main.cpp
```
Output:
```
In module write, imported at main.cpp:1:
in pp_string, at pretty-print.c:1827
0x2068f9d internal_error(char const*, ...)
???:0
0x973872 fancy_abort(char const*, int, char const*)
???:0
0x2086861 pp_format(pretty_printer*, text_info*)
???:0
0x2087d92 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x2067adf diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x2068720 warning_at(unsigned int, int, char const*, ...)
???:0
0xca067c do_warn_unused_parameter(tree_node*)
???:0
0xa3ba82 finish_function(bool)
???:0
0xb77dfb instantiate_decl(tree_node*, bool, bool)
???:0
0xb9b883 instantiate_pending_templates(int)
???:0
0xa50e3c c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/102597] New: ICE in gfc_get_extern_function_decl, at fortran/trans-decl.c:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102597 Bug ID: 102597 Summary: ICE in gfc_get_extern_function_decl, at fortran/trans-decl.c:2243 Product: gcc Version: 12.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 r7 : $ cat z1.f90 program p use iso_fortran_env associate (y => (compiler_version)) end associate end $ cat z0.f90 program p use iso_fortran_env associate (y => compiler_version) end associate end $ gfortran-12-20211003 -c z1.f90 z1.f90:3:38: 3 |associate (y => (compiler_version)) | 1 internal compiler error: Segmentation fault 0xd41bdf crash_signal ../../gcc/toplev.c:331 0x86c901 gfc_get_extern_function_decl(gfc_symbol*, gfc_actual_arglist*, char const*) ../../gcc/fortran/trans-decl.c:2243 0x86d0ad gfc_get_extern_function_decl(gfc_symbol*, gfc_actual_arglist*, char const*) ../../gcc/fortran/trans-decl.c:2121 0x86d9c7 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1772 0x87d3e8 gfc_conv_variable ../../gcc/fortran/trans-expr.c:2994 0x87958a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9074 0x879696 gfc_conv_expr_op ../../gcc/fortran/trans-expr.c:3771 0x879696 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9062 0x889881 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11359 0x8bc04c trans_associate_var ../../gcc/fortran/trans-stmt.c:2201 0x8c2771 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2314 0x84adc7 trans_code ../../gcc/fortran/trans.c:2014 0x871974 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6905 0x7f77b6 translate_all_program_units ../../gcc/fortran/parse.c:6572 0x7f77b6 gfc_parse_file() ../../gcc/fortran/parse.c:6841 0x843f3f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102596] New: [11/12 Regression] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102596 Bug ID: 102596 Summary: [11/12 Regression] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20201108 and 20201115 : (ICEs with an allocatable) $ cat z1.f90 program p integer, allocatable :: r r = 0 !$omp target parallel reduction(task, +:r) r = r + 1 !$omp end target parallel end $ gfortran-12-20211003 -c z1.f90 -fopenmp during GIMPLE pass: omplower z1.f90:5:12: 5 |r = r + 1 |^ internal compiler error: in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713 0x8af41b gfc_omp_clause_default_ctor(tree_node*, tree_node*, tree_node*) ../../gcc/fortran/trans-openmp.c:713 0xc1fc2e lower_rec_input_clauses ../../gcc/omp-low.c:6460 0xc239a6 lower_omp_taskreg ../../gcc/omp-low.c:12407 0xc14f21 lower_omp_1 ../../gcc/omp-low.c:14086 0xc14f21 lower_omp ../../gcc/omp-low.c:14287 0xc18a44 lower_omp_target ../../gcc/omp-low.c:12834 0xc18a44 lower_omp_1 ../../gcc/omp-low.c:14148 0xc18a44 lower_omp ../../gcc/omp-low.c:14287 0xc152e8 lower_omp_1 ../../gcc/omp-low.c:14064 0xc152e8 lower_omp ../../gcc/omp-low.c:14287 0xc153bd lower_omp_1 ../../gcc/omp-low.c:14077 0xc153bd lower_omp ../../gcc/omp-low.c:14287 0xc1c511 execute_lower_omp ../../gcc/omp-low.c:14326 0xc1c511 execute ../../gcc/omp-low.c:14374
[Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102385 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #6 from rsandifo at gcc dot gnu.org --- Mine.
[Bug fortran/102595] New: ICE in var_element, at fortran/decl.c:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 Bug ID: 102595 Summary: ICE in var_element, at fortran/decl.c:298 Product: gcc Version: 12.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 r10 : $ cat z1.f90 program p complex, parameter :: x(0) = 2 data x%im /3.0/ end $ cat z2.f90 program p complex, parameter :: x(1) = 2 data x%im /3.0/ end $ gfortran-12-20211003 -c z2.f90 z2.f90:3:12: 3 |data x%im /3.0/ |1 Error: PARAMETER 'x' shall not appear in a DATA statement at (1) $ gfortran-12-20211003 -c z1.f90 f951: internal compiler error: Segmentation fault 0xd41bdf crash_signal ../../gcc/toplev.c:331 0x77b0ed var_element ../../gcc/fortran/decl.c:298 0x77d4c4 top_var_list ../../gcc/fortran/decl.c:338 0x77d4c4 gfc_match_data() ../../gcc/fortran/decl.c:655 0x7eb6f1 match_word ../../gcc/fortran/parse.c:65 0x7f065e decode_statement ../../gcc/fortran/parse.c:469 0x7f13ca next_free ../../gcc/fortran/parse.c:1384 0x7f13ca next_statement ../../gcc/fortran/parse.c:1616 0x7f2aeb parse_spec ../../gcc/fortran/parse.c:4151 0x7f58bc parse_progunit ../../gcc/fortran/parse.c:6117 0x7f7041 gfc_parse_file() ../../gcc/fortran/parse.c:6658 0x843f3f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug c++/102594] New: ICE in decay_conversion, at cp/typeck.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102594
Bug ID: 102594
Summary: ICE in decay_conversion, at cp/typeck.c:2311
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r8 :
$ cat z1.cc
struct s {
s() {}
};
s a[1][1];
auto [b](a);
$ g++-12-20211003 -c z1.cc
z1.cc:5:11: internal compiler error: Segmentation fault
5 | auto [b](a);
| ^
0xe17d4f crash_signal
../../gcc/toplev.c:331
0x92719a decay_conversion(tree_node*, int, bool)
../../gcc/cp/typeck.c:2311
0x80f80a build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
../../gcc/cp/init.c:4297
0x81012f build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
../../gcc/cp/init.c:4528
0x81062b build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/cp/init.c:1823
0x7ee8ed build_aggr_init_full_exprs
../../gcc/cp/decl.c:7048
0x7ee8ed check_initializer
../../gcc/cp/decl.c:7209
0x7efbb1 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:8211
0x88ecbc cp_parser_decomposition_declaration
../../gcc/cp/parser.c:15427
0x88ecbc cp_parser_simple_declaration
../../gcc/cp/parser.c:15066
0x8b642f cp_parser_declaration
../../gcc/cp/parser.c:14828
0x8b6ebb cp_parser_translation_unit
../../gcc/cp/parser.c:4987
0x8b6ebb c_parse_file()
../../gcc/cp/parser.c:47774
0x988802 c_common_parse_file()
../../gcc/c-family/c-opts.c:1237
[Bug c++/102548] [9/10/11/12 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102548 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 51548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51548&action=edit gcc12-pr102548.patch Untested fix.
[Bug c++/102593] New: [10/11/12 Regression] ICE in cp_oacc_check_attachments, at cp/semantics.c:6561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102593
Bug ID: 102593
Summary: [10/11/12 Regression] ICE in
cp_oacc_check_attachments, at cp/semantics.c:6561
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20191215 and 20200105 :
$ cat z1.cc
template
void f ()
{
struct t { int a; };
#pragma acc data detach (t.a)
;
}
$ g++-12-20211003 -c z1.cc -fopenacc
z1.cc: In function 'void f()':
z1.cc:5:32: internal compiler error: Segmentation fault
5 | #pragma acc data detach (t.a)
|^
0xe17d4f crash_signal
../../gcc/toplev.c:331
0x8f6da6 cp_oacc_check_attachments
../../gcc/cp/semantics.c:6561
0x90842a finish_omp_clauses(tree_node*, c_omp_region_type)
../../gcc/cp/semantics.c:7850
0x897fb4 cp_parser_oacc_all_clauses
../../gcc/cp/parser.c:39710
0x8b3009 cp_parser_oacc_data
../../gcc/cp/parser.c:44231
0x8b3009 cp_parser_omp_construct
../../gcc/cp/parser.c:46870
0x8897b9 cp_parser_pragma
../../gcc/cp/parser.c:47594
0x8905b7 cp_parser_statement
../../gcc/cp/parser.c:12266
0x8913d4 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12722
0x89148f cp_parser_compound_statement
../../gcc/cp/parser.c:12671
0x8af888 cp_parser_function_body
../../gcc/cp/parser.c:24902
0x8af888 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:24953
0x8afd36 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:31083
0x8b0c57 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:30999
0x8b0c57 cp_parser_init_declarator
../../gcc/cp/parser.c:22436
0x8b35b6 cp_parser_single_declaration
../../gcc/cp/parser.c:31586
0x8b37d5 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:31151
0x8b3f9b cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:31417
0x8b3f9b cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:31436
0x8b61f9 cp_parser_declaration
../../gcc/cp/parser.c:14759
[Bug target/102485] -Wa,-many no longer has any effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485 --- Comment #2 from Paul Clarke --- GCC putting the base ".machine" directive at the beginning of the file makes any command-line use of "-many" (-Wa,-many) be ignored. Is that OK? "-many" is supposed to make those black boxes just work. This worked before recent changes to binutils/GCC. Is there any valid use of "-Wa,-many" now?
[Bug target/102485] -Wa,-many no longer has any effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485
Peter Bergner changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org,
||bergner at gcc dot gnu.org,
||dje at gcc dot gnu.org,
||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
--- Comment #1 from Peter Bergner ---
I agree it is GCC's job to emit a ".machine CPU" directive that allows the
assembler to correctly assemble the code GCC generates. Your test case however
uses inline asm and GCC does not know that you are using the mfppr32 mnemonic.
The assembler code you write in an inline asm is basically a black box to the
compiler. It is therefor up to the programmer to ensure that either the
-mcpu=CPU GCC option that is being used (which emits".machine CPU" directive)
is enough to assemble the mnemonics in the inline asm or you have to emit them
in your inline asm. For the later, you can fix your test case like:
bergner@pike:~$ cat mfppr32.c
long f () {
long ppr;
asm volatile ("mfppr32 %0" : "=r"(ppr));
return ppr;
}
bergner@pike:~$ cat mfppr32-2.c
long f () {
long ppr;
asm volatile (".machine push\n\
.machine power7\n\
mfppr32 %0\n\
.machine pop" : "=r"(ppr));
return ppr;
}
bergner@pike:~$ gcc -c mfppr32.c
/tmp/ccSpp2V8.s: Assembler messages:
/tmp/ccSpp2V8.s:19: Error: unrecognized opcode: `mfppr32'
bergner@pike:~$ gcc -c mfppr32-2.c
bergner@pike:~$
Therefore, I'm not sure there is anything for GCC to do here.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #22)
> Hmm, my proposed patch seems to work. I've adjusted it to not regress
> previously correctly handled cases and will test it fully.
I guess the reason for it worked for you because you tested it after the patch
for 102587?
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -3035,7 +3035,8 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
/* Expand this memset call. */
expand_builtin_memset (m_call, NULL_RTX, TYPE_MODE (var_type));
}
- else
+ /* ??? Deal with poly-int sized registers. */
+ else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type)))
{
/* If this variable is in a register, use expand_assignment might
generate better code. */
[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540 --- Comment #6 from Andrew Macleod --- > > > It removes a > > relationship between c_10 and _2. The reason ranger no longer can fold _2 > > == 0 > > is because the sequence is now: > > > > a.0_1 = a; > > _2 = (unsigned int) a.0_1; > > b = _2; > > _6 = a.0_1 & 4294967295; > > c_10 = _6; > > if (c_10 != 0) > > goto ; [INV] > > > > We do not find _2 is non-zero on the outgoing edge because _2 is not > > related to > > the calculation in the condition. (ie c_10 no longer has a dependency on > > _2) > > > > We do recalculate _2 based on the outgoing range of a.0_1, but with it > > being a > > 64 bit value and _2 being 32 bits, we only know the outgoing range of a.0_1 > > is > > non-zero.. we dont track any of the upper bits... > > 2->3 (T) a.0_1 : long int [-INF, -1][1, +INF] > > And when we recalculate _2 using that value, we still get varying because > > 0x in not zero, but can still produce a zero in _2. > > > > The problem is that the condition c_10 != 0 no longer related to the value > > of > > _2 in the IL... so ranger never sees it. and we cant represent the 2^16 > > subranges that end in [1,0x]. > > > > Before that transformation, > > _2 = (unsigned int) a.0_1; > >b = _2; > > c_10 = (long int) _2; > > The relationship is obvious, and ranger would relate the c_10 != 0 to _2 no > > problem. > > I see - too bad. Note the transform made the dependence chain of _6 > one instruction shorter without increasing the number of instructions > so it's a profitable transform. > > Btw, the relation is still there but only indirectly via a.0_1. The > old (E)VRP had this find_asserts(?) that produced assertions based > on the definitions - sth that now range-ops does(?), so it would > eventually have built assertions for a.0_1 for both conditions and > allow relations based on that? I can't seem to find my way around > the VRP code now - pieces moved all over the place and so my mind > fails me on the searching task :/ We do know that a.0_1 is non-zero on that edge: 2->3 (T) a.0_1 : long int [-INF, -1][1, +INF] the problem is that we can't currently represent that the bitmask operation causes all patterns ending in 0x to not occur.. we just leave it at ~[0,0]. which isn't sufficient for this use case. we don't currently track any equivalences between values of different precision.. (even though ranger once did). Handling it as a general equivalence was fraught with issues. We might be able to add a new equivalence class "slice" or something.. I had considered it but hadn't seen a great need case. This would make _6 a 32 bit slice of a.0_1 with range [1, 0x]. Then when we are querying for the cast _2 = (unsigned int) a.0_1; we could also query the 32 bit equivalence slices of a.0_1, find _6, and get the outgoing range of [1,0x].. and apply that value. It would probably resolve an entire class of things where we don't recognize an equivalence between a cast and a bitmask of equivalent precision. This would also mean the reverse would apply.. ie if we instead branched on _2 != 0 we would also understand that _6 will be non-zero.
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Iain Buclaw --- Fix committed.
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
--- Comment #6 from qinzhao at gcc dot gnu.org ---
with the committed patch, this testing case still failed but in a later rtl
stage:
qinzhao@gcc116:~/Bugs/102587$ sh t
/home/qinzhao/Install/latest/bin/gcc -ftrivial-auto-var-init=zero t.c -S
during RTL pass: pro_and_epilogue
t.c: In function ‘foo’:
t.c:1:33: internal compiler error: Segmentation fault
1 | void foo() { __SVFloat64_t f64; }
| ^
0xe18fab crash_signal
../../latest_gcc_git/gcc/toplev.c:331
0x122ed20 aarch64_add_offset
../../latest_gcc_git/gcc/config/aarch64/aarch64.c:5042
0x123044f aarch64_sub_sp
../../latest_gcc_git/gcc/config/aarch64/aarch64.c:5225
0x123044f aarch64_allocate_and_probe_stack_space
../../latest_gcc_git/gcc/config/aarch64/aarch64.c:8502
0x1230cfb aarch64_expand_prologue()
../../latest_gcc_git/gcc/config/aarch64/aarch64.c:8841
0x169fb63 gen_prologue()
../../latest_gcc_git/gcc/config/aarch64/aarch64.md:853
0x1226d17 target_gen_prologue
../../latest_gcc_git/gcc/config/aarch64/aarch64.md:7448
0xa9495f make_prologue_seq
../../latest_gcc_git/gcc/function.c:5825
0xa94b8b thread_prologue_and_epilogue_insns()
../../latest_gcc_git/gcc/function.c:6043
0xa95293 rest_of_handle_thread_prologue_and_epilogue
../../latest_gcc_git/gcc/function.c:6534
0xa95293 execute
../../latest_gcc_git/gcc/function.c:6610
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:a5b9ac0301c850a02d045b5630aa08b4ceab20c1 commit r9-9756-ga5b9ac0301c850a02d045b5630aa08b4ceab20c1 Author: Iain Buclaw Date: Sun Oct 3 16:02:24 2021 +0200 d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library Adds handling of `-static-libstc++' in the gdc driver, so that libstdc++ is appropriately linked if libstdc++ is either needed or seen on the command-line. PR d/102574 gcc/d/ChangeLog: * d-spec.cc (lang_specific_driver): Link libstdc++ statically if -static-libstdc++ was given on command-line. (cherry picked from commit c86a16b07b76604a8e3d556f135babab80e2b747)
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:41e21afc427ffe4a320616d4a454144b1e93a670 commit r10-10167-g41e21afc427ffe4a320616d4a454144b1e93a670 Author: Iain Buclaw Date: Sun Oct 3 16:02:24 2021 +0200 d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library Adds handling of `-static-libstc++' in the gdc driver, so that libstdc++ is appropriately linked if libstdc++ is either needed or seen on the command-line. PR d/102574 gcc/d/ChangeLog: * d-spec.cc (lang_specific_driver): Link libstdc++ statically if -static-libstdc++ was given on command-line. (cherry picked from commit c86a16b07b76604a8e3d556f135babab80e2b747)
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:dd6098467ff83351948435efc826e1c4b4b27f99 commit r11-9068-gdd6098467ff83351948435efc826e1c4b4b27f99 Author: Iain Buclaw Date: Sun Oct 3 16:02:24 2021 +0200 d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library Adds handling of `-static-libstc++' in the gdc driver, so that libstdc++ is appropriately linked if libstdc++ is either needed or seen on the command-line. PR d/102574 gcc/d/ChangeLog: * d-spec.cc (lang_specific_driver): Link libstdc++ statically if -static-libstdc++ was given on command-line. (cherry picked from commit c86a16b07b76604a8e3d556f135babab80e2b747)
[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102544 --- Comment #9 from miko at predsci dot com --- Both the C and Fortran versions returned "-1".
[Bug c++/97573] Implement C++20 [depr.arith.conv.enum]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97573 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/97573] Implement C++20 [depr.arith.conv.enum]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97573 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:2dda00b734888d3b53ac91160083b5c6cd5ca5c8 commit r12-4148-g2dda00b734888d3b53ac91160083b5c6cd5ca5c8 Author: Marek Polacek Date: Wed Sep 29 11:45:24 2021 -0400 c-family: Implement -Warray-compare [PR97573] This patch addresses one of my leftovers from GCC 11. C++20 introduced [depr.array.comp]: "Equality and relational comparisons between two operands of array type are deprecated." so this patch adds -Warray-compare. Since the code in question is dubious (the comparison doesn't actually compare the array elements), I've added this warning for C too, and enabled it in all C++ modes. PR c++/97573 gcc/c-family/ChangeLog: * c-common.h (do_warn_array_compare): Declare. * c-warn.c (do_warn_array_compare): New. * c.opt (Warray-compare): New option. gcc/c/ChangeLog: * c-typeck.c (parser_build_binary_op): Call do_warn_array_compare. gcc/cp/ChangeLog: * typeck.c (cp_build_binary_op): Call do_warn_array_compare. gcc/ChangeLog: * doc/invoke.texi: Document -Warray-compare. gcc/testsuite/ChangeLog: * c-c++-common/Warray-compare-1.c: New test. * c-c++-common/Warray-compare-2.c: New test.
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #9 from Thiago Macieira ---
Looks like it doesn't work for the sign bit.
$ cat /tmp/test.cpp
#include
bool tbit(std::atomic &i)
{
return i.fetch_or(CONSTANT, std::memory_order_relaxed) & CONSTANT;
}
$ ~/dev/gcc/bin/gcc -DCONSTANT='(1<<30)' -S -o - -O2 /tmp/test.cpp | sed -n
'/startproc/,/endproc/p'
.cfi_startproc
lock btsl $30, (%rdi)
setc%al
ret
.cfi_endproc
$ ~/dev/gcc/bin/gcc -DCONSTANT='(1<<31)' -S -o - -O2 /tmp/test.cpp | sed -n
'/startproc/,/endproc/p'
.cfi_startproc
movl(%rdi), %eax
.L2:
movl%eax, %ecx
movl%eax, %edx
orl $-2147483648, %ecx
lock cmpxchgl %ecx, (%rdi)
jne .L2
shrl$31, %edx
movl%edx, %eax
ret
.cfi_endproc
Changing to std::atomic makes no difference.
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
--- Comment #7 from Segher Boessenkool ---
(In reply to Richard Biener from comment #5)
> Not sure whether targets should have a special-case pattern here or whether
> that's for combine to un-canonicalize it?
Is the shift defined anywhere as the canonical form?
We already get a shift at expand time, for e.g.
long f(long a) { return a+a; }
I cannot find the code that does this easily, it is quite a maze :-) There
is code for changing a multiplication by a power of two (which we have in
Gimple already) into a shift, but then there should be something changing
the addition with self into a multiplication, and I cannot find that either.
Combine should absolutely not un-canonicalise it. It could try multiple
ways of writing this, but is it important enough to allow this, to justify
the (potential) combinatorial explosion this causes?
If we want combine to try many ways of writing something (not a bad idea an
sich btw, I support it), we need ways to battle such an explosion, and esp.
to make the amount of garbage RTL created manageable (it is not, currently).
Currently combine has to create GC'ed RTL to recog() it. Maybe we could
have some "GC stuff created between points X and Y" interface?
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #8 from Thiago Macieira ---
$ cat /tmp/test.cpp
#include
bool tbit(std::atomic &i)
{
return i.fetch_or(1, std::memory_order_relaxed) & 1;
}
$ ~/dev/gcc/bin/gcc -S -o - -O2 /tmp/test.cpp
.file "test.cpp"
.text
.p2align 4
.globl _Z4tbitRSt6atomicIiE
.type _Z4tbitRSt6atomicIiE, @function
_Z4tbitRSt6atomicIiE:
.LFB339:
.cfi_startproc
lock btsl $0, (%rdi)
setc%al
ret
.cfi_endproc
.LFE339:
.size _Z4tbitRSt6atomicIiE, .-_Z4tbitRSt6atomicIiE
.ident "GCC: (GNU) 12.0.0 20211004 (experimental)"
.section.note.GNU-stack,"",@progbits
+1
[Bug sanitizer/102515] UBSAN misses signed division instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102515 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #9 from Richard Biener --- Fixed now.
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:c86a16b07b76604a8e3d556f135babab80e2b747 commit r12-4146-gc86a16b07b76604a8e3d556f135babab80e2b747 Author: Iain Buclaw Date: Sun Oct 3 16:02:24 2021 +0200 d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library Adds handling of `-static-libstc++' in the gdc driver, so that libstdc++ is appropriately linked if libstdc++ is either needed or seen on the command-line. PR d/102574 gcc/d/ChangeLog: * d-spec.cc (lang_specific_driver): Link libstdc++ statically if -static-libstdc++ was given on command-line.
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 --- Comment #7 from Thiago Macieira --- (In reply to H.J. Lu from comment #5) > Created attachment 51536 [details] > A patch > > Please try this. Give me an hour (will try v2).
[Bug ipa/102554] [10/11 Regression] Inlining missed at -O3 with non-default --param=early-inlining-insns and pragma optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102554 --- Comment #4 from Martin Liška --- > I can confirm I am seeing g:r12-4038-g6de9f0c13b27c343 resolve the issue. > > Is it possible to get this applied into the upcoming 10.4, 11.3 releases? Sorry, but it won't be possible. It's a pretty significant change that can potentially break some software build. That's why it will target 12.1 release only. > It's making upgrading to 10.x / 11.x versions challenging in certain latency > sensitive production environments.
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588
--- Comment #3 from Martin Liška ---
Reduced test-case:
namespace std {
typedef int size_t;
template class vector {
public:
typedef size_t size_type;
};
} // namespace std
typedef int quint32;
typedef double qreal;
class QPointF {
qreal yp;
};
namespace OpenOrienteering {
class MapCoord;
class MapCoordF : QPointF {};
typedef std::vector MapCoordVector;
class PathCoord {
public:
using size_type = quint32;
using length_type = float;
using param_type = MapCoordF;
size_type index;
param_type param;
length_type clen;
};
class PathObject {
public:
PathCoord findPathCoordForIndex(MapCoordVector::size_type);
};
struct ObjectPathCoord : PathCoord {
ObjectPathCoord(PathObject *, size_type);
};
ObjectPathCoord::ObjectPathCoord(PathObject *object, size_type)
: PathCoord{object->findPathCoordForIndex(index)} {}
} // namespace OpenOrienteering
[Bug tree-optimization/102570] missed fully redudant with internal function of add_overflow in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102570 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #24 from Richard Biener --- commit 7e0c0500808d58bca5b8e23cbd474022c32234e4 (origin/master, origin/HEAD) Author: Richard Biener Date: Mon Oct 4 11:34:27 2021 +0200 middle-end/102285 - refine .DEFERRED_INIT expansion This refines the way we figure whether we are facing a register that cannot be initialized by emitting a memset away from inspecting expanded RTL of the LHS to using the predicates expand_assignment is using to detect decls or MEM_REFs with non-memory DECL_RTL. 2021-10-04 Richard Biener * expr.h (non_mem_decl_p): Declare. (mem_ref_refers_to_non_mem_p): Likewise. * expr.c (non_mem_decl_p): Export. (mem_ref_refers_to_non_mem_p): Likewise. * internal-fn.c (expand_DEFERRED_INIT): Do not expand the LHS but check the base with mem_ref_refers_to_non_mem_p and non_mem_decl_p. * c-c++-common/pr102285.c: New testcase.
[Bug tree-optimization/102570] missed fully redudant with internal function of add_overflow in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102570 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:55a3be2f5255d69e740d61b2c5aaba1ccbc643b8 commit r12-4143-g55a3be2f5255d69e740d61b2c5aaba1ccbc643b8 Author: Richard Biener Date: Mon Oct 4 10:57:45 2021 +0200 tree-optimization/102570 - teach VN about internal functions We're now using internal functions for a lot of stuff but there's still missing VN support out of laziness. The following instantiates support and adds testcases for FRE and PRE (hoisting). 2021-10-04 Richard Biener PR tree-optimization/102570 * tree-ssa-sccvn.h (vn_reference_op_struct): Document we are using clique for the internal function code. * tree-ssa-sccvn.c (vn_reference_op_eq): Compare the internal function code. (print_vn_reference_ops): Print the internal function code. (vn_reference_op_compute_hash): Hash it. (copy_reference_ops_from_call): Record it. (visit_stmt): Remove the restriction around internal function calls. (fully_constant_vn_reference_p): Use fold_const_call and handle internal functions. (vn_reference_eq): Compare call return types. * tree-ssa-pre.c (create_expression_by_pieces): Handle generating calls to internal functions. (compute_avail): Remove the restriction around internal function calls. * gcc.dg/tree-ssa/ssa-fre-96.c: New testcase. * gcc.dg/tree-ssa/ssa-pre-33.c: Likewise.
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #24 from Jakub Jelinek --- I wanted to look at #c20, but at least my i9-7960X for e.g. lock; btsl $65, var acts the same as lock; btsl $1, var rather than lock; btsl $1, var+8, so maybe #c20 is not possible.
[Bug ipa/102554] [10/11 Regression] Inlining missed at -O3 with non-default --param=early-inlining-insns and pragma optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102554 John S changed: What|Removed |Added Known to fail|12.0| --- Comment #3 from John S --- (In reply to Martin Liška from comment #2) > (In reply to Richard Biener from comment #1) > > I suspect that the optimize() attribute resets the param value to its > > default. > > Yes, it's fixed on master with g:r12-4038-g6de9f0c13b27c343. > > > > > Martin - can you investigate / bisect? > > Sure, it started with r10-4944-g1e83bd7003e03160. > > I tend closing that as fixed, what do you think Richi? I can confirm I am seeing g:r12-4038-g6de9f0c13b27c343 resolve the issue. Is it possible to get this applied into the upcoming 10.4, 11.3 releases? It's making upgrading to 10.x / 11.x versions challenging in certain latency sensitive production environments.
[Bug libstdc++/102592] [11/12 Regression] heap-use-after-free when constructing std::filesystem::path from iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592 Jonathan Wakely changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |11.3
[Bug libstdc++/102592] [11/12 Regression] heap-use-after-free when constructing std::filesystem::path from iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592
Jonathan Wakely changed:
What|Removed |Added
Summary|heap-use-after-free when|[11/12 Regression]
|constructing|heap-use-after-free when
|std::filesystem::path from |constructing
|iterator pair |std::filesystem::path from
||iterator pair
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Keywords||wrong-code
Last reconfirmed||2021-10-04
Known to work||10.3.1
Status|UNCONFIRMED |ASSIGNED
Known to fail||11.2.1, 12.0
--- Comment #1 from Jonathan Wakely ---
The problem is the last line of this function:
template
static auto
_S_convert(const _Tp& __str)
{
if constexpr (is_same_v<_Tp, string_type>)
return __str;
else if constexpr (is_same_v<_Tp, basic_string_view>)
return __str;
else if constexpr (is_same_v)
return basic_string_view(__str.data(), __str.size());
else
return _S_convert(__str.data(), __str.data() + __str.size());
}
That returns a basic_string_view referring to the contents of __str,
but that is an rvalue basic_string that goes out of scope before the
result is used.
[Bug libstdc++/102592] New: heap-use-after-free when constructing std::filesystem::path from iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592
Bug ID: 102592
Summary: heap-use-after-free when constructing
std::filesystem::path from iterator pair
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dean.gcc.bugzilla at gmail dot com
Target Milestone: ---
The std::filesystem::path constructor that takes an iterator pair produces a
heap-use-after-free error (address sanitizer) in case the iterators are
non-contiguous and value_type != char.
Full self-contained reproducible example on Compiler Explorer:
https://godbolt.org/z/3nxqq5Ef8 I've also included the reproduction code and
error below for completeness.
Affected versions: 11.x, trunk
Not affected: 10.x
As far as I've been able to track this in the std::filesystem::path
constructor, for the case of non-contiguous, non-char iterators, a temporary
container is created and then assigned to a std::string_view. However that temp
container has a shorter lifetime than the std::string_view.
The code:
#include
namespace fs = std::filesystem;
fs::path to_path(std::string_view sv) {
struct AsU8 {
std::string_view::const_iterator it;
using iterator_category = std::forward_iterator_tag;
using difference_type = std::ptrdiff_t;
using value_type = char8_t;
using reference = const value_type&;
using pointer = const value_type*;
char8_t operator*() const { return static_cast(*it); }
AsU8& operator++() { return ++it, *this; }
bool operator==(const AsU8&) const = default;
};
return {AsU8{sv.begin()}, AsU8{sv.end()}};
}
int main() {
return
to_path("/long/path/to/a/file/to/avoid/small/string/opt").string().size();
}
=1==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400010 at
pc 0x7fed85f999c0 bp 0x7ffdddc9ccc0 sp 0x7ffdddc9c470
READ of size 46 at 0x60400010 thread T0
#0 0x7fed85f999bf in __interceptor_memcpy
(/opt/compiler-explorer/gcc-11.2.0/lib64/libasan.so.6+0x3c9bf)
#1 0x4039e5 in std::char_traits::copy(char*, char const*, unsigned
long)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/char_traits.h:409
#2 0x405214 in std::__cxx11::basic_string,
std::allocator >::_S_copy(char*, char const*, unsigned long)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:359
#3 0x4058f1 in std::__cxx11::basic_string,
std::allocator >::_S_copy_chars(char*, char const*, char const*)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:406
#4 0x405109 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char
const*, char const*, std::forward_iterator_tag)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.tcc:225
#5 0x40578b in void std::__cxx11::basic_string, std::allocator >::_M_construct_aux(char const*, char const*, std::__false_type)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:255
#6 0x404a8e in void std::__cxx11::basic_string, std::allocator >::_M_construct(char
const*, char const*)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:274
#7 0x404119 in std::__cxx11::basic_string,
std::allocator >::basic_string(char const*, unsigned long,
std::allocator const&)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:521
#8 0x404e66 in std::__cxx11::basic_string,
std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator >::__sv_wrapper,
std::allocator const&)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:154
#9 0x404373 in std::__cxx11::basic_string,
std::allocator >::basic_string >, void>(std::basic_string_view > const&, std::allocator const&)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:664
#10 0x402c63 in path
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/fs_path.h:292
#11 0x4024ae in to_path[abi:cxx11](std::basic_string_view >) /app/example.cpp:19
#12 0x40265c in main /app/example.cpp:23
#13 0x7fed85a140b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#14 0x40226d in _start (/app/output.s+0x40226d)
[Bug c++/102482] Winit-list-lifetime false positive for temporaries with std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102482 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #8 from Jonathan Wakely --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580771.html
[Bug libstdc++/100444] std::random_device isn't random on AMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444 --- Comment #14 from Jonathan Wakely --- Created attachment 51547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51547&action=edit Proposed patch
[Bug target/102591] New: Failure to optimize search for value in vector-sized area to use SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102591
Bug ID: 102591
Summary: Failure to optimize search for value in vector-sized
area to use SIMD
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool match8(char *tpl)
{
int found = 0;
for (int at = 0; at < 16; at++)
if (tpl[at] == 0)
found = 1;
return found;
}
This function can be greatly optimized by using SIMD. It can be optimized to
something like this:
typedef char v16i8 __attribute__((vector_size(16)));
bool match8v2(char *tpl)
{
v16i8 values;
__builtin_memcpy(&values, tpl, 16);
v16i8 compared = (values == 0);
return _mm_movemask_epi8((__m128i)compared) != 0;
}
This optimization is done by LLVM, but not by GCC.
PS: I've marked this as an x86 bug, but only because I could not find a
portable way of expressing `_mm_movemask_epi8((__m128i)compared)`, I would
assume other architectures have similar ways of expressing the same thing
cheaply.
(For example, Altivec should be able to implement that operation with a
`vec_extract(vec_vbpermq((__vector unsigned char)compared, perm), 1)` with
`perm` looking like this: `{120, 112, 104, 96, 88, 80, 72, 64, 56, 48, 40, 32,
24, 16, 8, 0}` and the 1 replaced with 14 on big-endian)
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Resolution|FIXED |--- Status|RESOLVED|ASSIGNED Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #5 from rsandifo at gcc dot gnu.org --- Reopening because I don't think we can simply ignore the option like this, at least not without a warning. Hope to fix sometime in stage 3.
[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102544 --- Comment #8 from Andrew Stubbs --- Did you get the C version to return anything other than "-1"? (The expected result is "2".) I'm still trying to determine if the device is compatible, but the mapping problem looks like a different issue. Your code works fine on my device using a somewhat more recent GCC build. (I can't install that exact toolchain right now.)
[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586 --- Comment #4 from Jakub Jelinek --- Seems in the C++ FE it is CLASSTYPE_AS_BASE, so shall clear_padding_type for FIELD_DECLs where DECL_SIZE_UNIT (fld) is smaller than TYPE_SIZE_UNIT (TREE_TYPE (fld)) call some new langhook which for C++ would return CLASSTYPE_AS_BASE? All gimple_fold_builtin calls for BUILT_IN_CLEAR_PADDING should fold the call away, so I'd hope that all the folding happens before IPA.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #23 from Richard Biener --- I do have to check the result before this fix attempt but at least with it the overall testsuite state isn't so great. You can do make check RUNTESTFLAGS="--target_board=unix/-ftrivial-auto-var-init=zer" to check all of the testsuite (besides Ada ACATS which doesn't honor RUNTESTFLAGS, you have to edit gcc/testsuite/ada/acats/run_all.sh and amend the toplevel 'gccflags' variable there. I see ICEs and runfails there. I'll file a separate bug about these (some may be due to the DECL_VALUE_EXPR thing).
[Bug target/93183] SVE does not use neg as conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183
--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > We get:
> > .L3:
> > ld1bz0.b, p0/z, [x1, x3]
> > movprfx z2, z0
> > and z2.b, z2.b, #0xc0
> > neg z1.b, p1/m, z0.b ;;; THIS
> > cmpeq p2.b, p1/z, z2.b, #0
> > sel z0.b, p2, z0.b, z1.b AND THIS
> > st1bz0.b, p0, [x0, x3]
> > incbx3
> > whilelo p0.b, w3, w2
> > b.any .L3
> >
> > The two instructions marked should be combined.
>
> The problem is that it isn't a straight combination of the
> NEG and SEL, because the condition is the inverse of the one
> that we want for predication.
IIUC, sel is redundant and we could generate following code
instead for the inner loop ?
ld1bz0.b, p0/z, [x1, x2]
movprfx z2, z0
and z2.b, z2.b, #0xc0
cmpne p2.b, p1/z, z2.b, #0
neg z0.b, p2/m, z0.b
st1bz0.b, p0, [x0, x3]
incbx3
whilelo p0.b, w3, w2
b.any .L3
>
> This is one of the things that the IFN_COND_* functions were
> designed to fix. We should probably add unary versions of those.
The input to isel pass is:
vect__3.11_39 = .MASK_LOAD (_22, 8B, loop_mask_38);
vect_t1_15.12_41 = vect__3.11_39 & { 192, ... };
vect_t_12.13_42 = -vect__3.11_39;
_44 = vect_t1_15.12_41 == { 0, ... };
vect_iftmp.14_45 = VEC_COND_EXPR <_44, vect__3.11_39, vect_t_12.13_42>;
where vect__3.11_39 and vect_t_12.13_42 are negatives of each other.
I suppose in isel pass if we come across vec_cond_expr of the form:
op2 = vec_cond_expr
then we could lower it to a new internal function say IFN_COND_NEG.
IFN_COND_NEG could use a new optab say cond_neg_optab to expand it to:
movprfx op2, op1
set predicate according to inverted cond
op2 = predicate/m neg op2
Does this look reasonable ?
Thanks,
Prathamesh
[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So, seems the C9 type is 32-byte, with 8-byte virtual table pointers at offset 0 and 16 bytes (and the rest is padding), C5 is 24-byte with virtual table pointers at offsets 0 and 8 bytes (and the rest is padding), C4 is 16-byte with virtual table pointers at offset 0 (and the rest is padding). But what the middle-end sees is that there is a FIELD_DECL with C5 type at offset 0 with size 9 bytes and then a FIELD_DECL with C4 type at offset 16 with size 9 bytes. The __builtin_clear_padding handling code when called on a FIELD_DECL with smaller DECL_SIZE_UNIT than TYPE_SIZE_UNIT is able to ignore fields that are wholy beyond the size and also the default behavior is that everything is padding until proven otherwise, so for padding bytes nothing changes. The reason for the ICE is that the first FIELD_DECL with C5 type says 9 bytes and the type has 8 byte, 8 byte and 1 byte fields (2 virtual table pointers and one padding byte). So, in that case it is unclear what the code should do. Shall it treat the fields that partially fall into the range and partially don't as padding (ignore them), or is there no way to do this using the TREE_TYPE of FIELD_DECLs that the middle-end sees and one needs to use some other types (I vaguely remember the C++ FE has some variant RECORD_TYPEs for the virtual bases that actually reflect what is present and where, but I have no idea if that is visible to the middle-end somewhere)?
[Bug c++/102590] Templated operations on variables in structured binding don't work when templated functions/lambdas require type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102590 --- Comment #2 from Rajat Jain <1997.rajatjain at gmail dot com> --- Yeah .template works as well. This is in the latest release too. I wasn't sure whether I should write the oldest version that this is in (since other 8.x releases would need a patch as well), or the latest. Let me change that.
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
--- Comment #6 from Uroš Bizjak ---
(In reply to Richard Biener from comment #5)
> The GIMPLE IL is now using BIT_INSERT_EXPRs consistently for all cases and
> combine does
>
> Trying 8 -> 11:
> 8: {r90:SI=r89:SI<<0x1;clobber flags:CC;}
> REG_DEAD r89:SI
> REG_UNUSED flags:CC
>11: strict_low_part(r92:V4QI#0)=r90:SI#0
> REG_DEAD r90:SI
> Failed to match this instruction:
> (set (strict_low_part (subreg:QI (reg:V4QI 92 [ v ]) 0))
> (ashift:QI (subreg:QI (reg:SI 89 [ v ]) 0)
> (const_int 1 [0x1])))
>
> where it fails to try (add:QI (subreg...) (subreg...)) instead of the shift
> by 1.
>
> Not sure whether targets should have a special-case pattern here or whether
> that's for combine to un-canonicalize it?
We do have this pattern in i386.md, but please see the FIXME:
(define_insn "*ashl3_1_slp"
[(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+"))
(ashift:SWI12 (match_operand:SWI12 1 "register_operand" "0")
(match_operand:QI 2 "nonmemory_operand" "cI")))
(clobber (reg:CC FLAGS_REG))]
"(!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun))
/* FIXME: without this LRA can't reload this pattern, see PR82524. */
&& rtx_equal_p (operands[0], operands[1])"
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Aldy Hernandez --- fixed
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 --- Comment #7 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:fa3ccf8bfe9940b439d6cc2c38ee8da134b0ff2d commit r12-4139-gfa3ccf8bfe9940b439d6cc2c38ee8da134b0ff2d Author: Aldy Hernandez Date: Sun Oct 3 19:42:10 2021 +0200 Remove static marker for range in alloca pass. The m_ranges[] field in int_range are trees, so they live in GC space. Since invalid_range is static, it must be marked with GTY magic. However, calculating invalid_range is not particularly slow, or on a critical path, so we can just put it in local scope and recalculate every time. Tested on x86-64 Linux. gcc/ChangeLog: PR tree-optimization/102560 * gimple-ssa-warn-alloca.c (alloca_call_type): Remove static marker for invalid_range. gcc/testsuite/ChangeLog: * g++.dg/Walloca2.C: New test.
[Bug c++/102319] ICE in cpp_atomic_builtins, at c-family/c-cppbuiltin.c:746 since r12-3495-g76b75018b3d053a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102319 --- Comment #3 from Martin Liška --- @Jason: May I please ping this issue. It's still not addressed after g:4320a4b717dcccddf230d0b944bfc5a7ae282508.
[Bug c++/102590] Templated operations on variables in structured binding don't work when templated functions/lambdas require type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102590 --- Comment #1 from Andrew Pinski --- My bet is gcc mistaken it for being a dependent type which meaning you can use the template keyword to workaround the issue. Also gcc 8.x series is over 3 years old so this might be fixed already in a newer version of gcc.
[Bug c++/102590] New: Templated operations on variables in structured binding don't work when templated functions/lambdas require type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102590
Bug ID: 102590
Summary: Templated operations on variables in structured
binding don't work when templated functions/lambdas
require type deduction
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 1997.rajatjain at gmail dot com
Target Milestone: ---
Foreach loops written with a structured-binding declaration error out if any of
the captured types contains a template member-function which is used inside the
loop.
This only happens if such a loop is placed inside a templated lambda/function.
A minimal example of the above is:
struct Foo
{
template
T get() const
{
return static_cast(0);
}
};
template
void error_func(T elem)
{
std::array, 1> arr;
for(const auto& [_, val] : arr)
{
val.get(); // Error here
}
}
The error disappears if T is replaced with any concrete type. It also
disappears if instead of structured bindings, a tuple is used with auto type
specifier.
The above code also works if one writes:
const auto& [_, val] = arr[0];
val.get();
Compilation flags: -std=c++17
Reported error:
test.cpp:19:17: error: expected primary-expression before 'int'
val.get();
^~~
test.cpp:19:17: error: expected ';' before 'int'
val.get();
^~~
;
[Bug libstdc++/102589] spaceship: std::map does not use specialised operator< for value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102589
--- Comment #2 from Jonathan Wakely ---
Overloading < for shared_ptr like that is a bit questionable anyway.
You can use std::lexicographical_compare with a custom comparison function if
you want the custom less-than behaviour:
if (std::lexicographical_compare(largerMap.begin(), largerMap.end(),
smallerMap.begin(), smallerMap.end(), [](const auto& l, const auto& r) { return
l.first < r.first || (l.first == r.first && *l.second < *r.second); }))
This does the same thing in C++17 and C++20.
[Bug libstdc++/102589] spaceship: std::map does not use specialised operator< for value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102589 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- (In reply to Gregor Jasny from comment #0) > I stumbled over this issue when porting a code base from C++17 to C++20. > Both: GNU libstdc++ as well as MSVC STL show the unexpected behaviour. > Libc++ seems to do the right thing. Probably because it doesn't implement <=> support in the standard library at all. Libstdc++ and MSVC do. > Describe the bug > > Compiling the test case with C++17 works as expected whereas compiling it > with C++20 makes the test assumption fail. The assumption is wrong. > The reason is that for C++ 20 builds the specialised operator<(const FooPtr& > left, const FooPtr& right) is not picked up. Instead the default operator<=> > for std::shared_ptr is used which only compares the raw pointers and not the > content they point to. This is the correct behaviour. > Expected behavior > > I'd expect that with C++17 and C++20 the STL would prefer the specialised > operator<(const FooPtr& left, const FooPtr& right) over the synthesised <=> > one. That would also align with the strong backwards compatibilities C++ > strives for. No. Comparing the two std::map objects has to use <=> because there is no < for std::map in C++20, so you get a synthesized < from the <=> for std::map. And obviously <=> for std::map is going to try to use <=> for its elements. So it uses <=> for std::pair which uses <=> for its members, so it uses <=> for std::shared_ptr. The only < comparison that happens is the one for std::map, after that everything is a three-way comparison.
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
Richard Biener changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #5 from Richard Biener ---
The GIMPLE IL is now using BIT_INSERT_EXPRs consistently for all cases and
combine does
Trying 8 -> 11:
8: {r90:SI=r89:SI<<0x1;clobber flags:CC;}
REG_DEAD r89:SI
REG_UNUSED flags:CC
11: strict_low_part(r92:V4QI#0)=r90:SI#0
REG_DEAD r90:SI
Failed to match this instruction:
(set (strict_low_part (subreg:QI (reg:V4QI 92 [ v ]) 0))
(ashift:QI (subreg:QI (reg:SI 89 [ v ]) 0)
(const_int 1 [0x1])))
where it fails to try (add:QI (subreg...) (subreg...)) instead of the shift by
1.
Not sure whether targets should have a special-case pattern here or whether
that's for combine to un-canonicalize it?
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Confirmed, reducing that right now..
[Bug libstdc++/102589] New: spaceship: std::map does not use specialised operator< for value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102589 Bug ID: 102589 Summary: spaceship: std::map does not use specialised operator< for value Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gjasny at googlemail dot com Target Milestone: --- Created attachment 51546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51546&action=edit Testcase Hello, I stumbled over this issue when porting a code base from C++17 to C++20. Both: GNU libstdc++ as well as MSVC STL show the unexpected behaviour. Libc++ seems to do the right thing. Describe the bug Compiling the test case with C++17 works as expected whereas compiling it with C++20 makes the test assumption fail. The reason is that for C++ 20 builds the specialised operator<(const FooPtr& left, const FooPtr& right) is not picked up. Instead the default operator<=> for std::shared_ptr is used which only compares the raw pointers and not the content they point to. Expected behavior I'd expect that with C++17 and C++20 the STL would prefer the specialised operator<(const FooPtr& left, const FooPtr& right) over the synthesised <=> one. That would also align with the strong backwards compatibilities C++ strives for. GCC version g++-11 (Debian 11.2.0-8) 11.2.0 Links Microsoft STL Issue: https://github.com/microsoft/STL/issues/2234 Debian Sid based reproducer: https://github.com/gjasny/map-spaceship-testcase Godbolt: https://godbolt.org/z/objPnjo84 Thanks, Gregor
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #22 from Richard Biener --- Hmm, my proposed patch seems to work. I've adjusted it to not regress previously correctly handled cases and will test it fully.
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 102073, which changed state. Bug 102073 Summary: gcc/ada/socket.c: 2 * missing return https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102073 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug ada/102073] gcc/ada/socket.c: 2 * missing return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102073 Arnaud Charlet changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|UNCONFIRMED |RESOLVED --- Comment #3 from Arnaud Charlet --- .
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588 --- Comment #1 from John Paul Adrian Glaubitz --- Created attachment 51545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51545&action=edit Preprocessed source.
[Bug target/102588] New: ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588
Bug ID: 102588
Summary: ICE: in smallest_mode_for_size, at stor-layout.c:356
when building openorienteering-mapper
Product: gcc
Version: 10.3.0
URL: https://buildd.debian.org/status/fetch.php?pkg=openori
enteering-mapper&arch=sparc64&ver=0.9.5-1&stamp=163312
0814&raw=0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com,
matorola at gmail dot com
Target Milestone: ---
Target: sparc64-*-*-*
Trying to build openorienteering-mapper on sparc64 fails on Debian unstable
with:
[ 68%] Building CXX object
src/CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o
cd /<>/obj-sparc64-linux-gnu/src && /usr/bin/c++
-DMAPPER_BIG_ENDIAN -DMAPPER_COMMON_LIB -DMAPPER_USE_GDAL
-DMAPPER_USE_NMEA_POSITION_PLUGIN -DMAPPER_USE_POWERSHELL_POSITION_PLUGIN
-DMAPPER_USE_SENSORS -DNDEBUG -DQT_CONCURRENT_LIB -DQT_CORE_LIB
-DQT_DISABLE_DEPRECATED_BEFORE=0x050500 -DQT_GUI_LIB -DQT_NETWORK_LIB
-DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG
-DQT_NO_DEBUG_OUTPUT -DQT_NO_WARNING_OUTPUT -DQT_PRINTSUPPORT_LIB
-DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DSCALING_ICON_ENGINE_PLUGIN -DUNICODE
-DWITH_COVE -D_USE_MATH_DEFINES
-I/<>/obj-sparc64-linux-gnu/src/Mapper_Common_autogen/include
-I/<>/src -I/<>/3rd-party/cove
-I/<>/obj-sparc64-linux-gnu/src -isystem
/usr/include/sparc64-linux-gnu/qt5/QtCore/5.15.2 -isystem
/usr/include/sparc64-linux-gnu/qt5/QtCore/5.15.2/QtCore -isystem
/usr/include/sparc64-linux-gnu/qt5/QtGui/5.15.2 -isystem
/usr/include/sparc64-linux-gnu/qt5/QtGui/5.15.2/QtGui -isystem
/usr/include/polyclipping -isystem /usr/include/sparc64-linux-gnu/qt5 -isystem
/usr/include/sparc64-linux-gnu/qt5/QtWidgets -isystem
/usr/include/sparc64-linux-gnu/qt5/QtGui -isystem
/usr/include/sparc64-linux-gnu/qt5/QtCore -isystem
/usr/lib/sparc64-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/sparc64-linux-gnu/qt5/QtConcurrent -isystem
/<>/src/printsupport -isystem
/usr/include/sparc64-linux-gnu/qt5/QtPrintSupport -isystem
/usr/include/sparc64-linux-gnu/qt5/QtNetwork -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wpedantic
-Wextra -O3 -DNDEBUG -fPIC -std=gnu++14 -MD -MT
src/CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o -MF
CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o.d -o
CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o -c
/<>/src/tools/edit_line_tool.cpp
during RTL pass: expand
In file included from /<>/src/tools/cut_tool.h:34,
from /<>/src/tools/cut_tool.cpp:22:
/<>/src/core/objects/object.h: In member function
‘OpenOrienteering::ObjectPathCoord
OpenOrienteering::CutTool::findEditPoint(const OpenOrienteering::MapCoordF&,
int, int) const’:
/<>/src/core/objects/object.h:1275:50: internal compiler error: in
smallest_mode_for_size, at stor-layout.c:356
1275 | : PathCoord { object->findPathCoordForIndex(index) }
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Attaching preprocessed source.
Full log in:
https://buildd.debian.org/status/fetch.php?pkg=openorienteering-mapper&arch=sparc64&ver=0.9.5-1&stamp=1633120814&raw=0
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #21 from Richard Biener ---
Reduced testcase:
int
qy (void)
{
int tw = 4;
int fb[tw];
return fb[2];
}
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- .
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 --- Comment #3 from Richard Biener --- The ICE is fixed, but VLA registers are uninitialized.
