https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107867
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0976b012d89e3d819d83cdaf0dab05925b3eb3a0
commit r13-4316-g0976b012d89e3d819d83cdaf0dab05925b3eb3a0
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107867
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876
--- Comment #4 from Richard Biener ---
It's a latent issue before this rev. since clean_up_after_unswitching ends up
removing all exit edges from one copy, keeping an infinite loop. The function
uses remove_edge () for this, not remove_edge_and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107892
--- Comment #1 from Eric Biggers ---
The reproducer I gave in my first comment doesn't reproduce the bug on
releases/gcc-11.1.0, so it must have regressed between then and trunk. I can
do a bisection if needed.
However, I actually still see th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107892
--- Comment #2 from Eric Biggers ---
This is also reproducible with SSE2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890
--- Comment #4 from Andrew Pinski ---
There is always a trade off here.
We made the decision that signed integer overflow is undefined because we want
to do optimizations. Gcc does provide an option which makes them behave well
defined at runtim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #13 from Rama Malladi ---
(In reply to CVS Commits from comment #12)
> The master branch has been updated by Wilco Dijkstra :
>
> https://gcc.gnu.org/g:0c1b0a23f1fe7db6a2e391b7cb78cff90032
>
> commit r13-4291-g0c1b0a23f1fe7db6a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
Bug ID: 107893
Summary: gcc trunk at -O0 (UBSan) misses a
Null-pointer-dereference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #8 from Jamaika ---
First lesson on the page https://www.modernescpp.com/index.php/latches-in-c-20
I use GCC from 11.3.1 to 13.0.0 20221124
```
// workers.cpp
#include
#include
#include
#include
std::latch workDone(6);
std::mut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107892
--- Comment #3 from Hongtao.liu ---
> In the bad version, I noticed that the RTL initially has two separate insns
> for 'a += *p': one to do the addition and write the result to a new pseudo
> register, and one to convert the value from mode V8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
--- Comment #1 from Jakub Jelinek ---
You don't store the shift result anywhere and there are no side-effects in the
expression, so nothing prevents the compiler from optimizing out the whole
expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469
--- Comment #7 from Jakub Jelinek ---
The patch unfortunately regresses the OpenMP g++.dg/gomp/for-21.C test:
template
void
f6 (S (&a)[10])
{
#pragma omp for collapse (2)
for (auto [i, j, k] : a) // { dg-error "use of 'i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
--- Comment #2 from Richard Biener ---
Well, it first performs the a[1] access which segfaults, isn't that expected?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
--- Comment #3 from Richard Biener ---
That is,
int main() {
int *a = 0;
(a[0] | a[1]) >> 056;
}
works at -O0:
t.c:3:6: runtime error: load of null pointer of type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:238cf114de16518c6569f0cdd2c4d6211ac98a74
commit r13-4317-g238cf114de16518c6569f0cdd2c4d6211ac98a74
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
--- Comment #4 from Li Shaohua ---
(In reply to Richard Biener from comment #3)
> That is,
>
> int main() {
> int *a = 0;
>(a[0] | a[1]) >> 056;
> }
>
> works at -O0:
>
> t.c:3:6: runtime error: load of null pointer of type 'int'
Yes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Andrea Corallo :
https://gcc.gnu.org/g:e0dd75fe90ef4cda94f431747d239d6cfcf5656f
commit r13-4330-ge0dd75fe90ef4cda94f431747d239d6cfcf5656f
Author: Stam Markianos-Wright
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrea Corallo :
https://gcc.gnu.org/g:31df339a50c30712c1e071d2b18f304b148a3165
commit r13-4331-g31df339a50c30712c1e071d2b18f304b148a3165
Author: Stam Markianos-Wright
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrea Corallo :
https://gcc.gnu.org/g:2fefb8931d566cc8a4cbba81601972b0d2002f95
commit r13-4332-g2fefb8931d566cc8a4cbba81601972b0d2002f95
Author: Stam Markianos-Wright
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #17 from Jakub Jelinek ---
(In reply to dave.anglin from comment #16)
> This is what the test prints:
> 6.47518e-4966 6e-4966
> xxx.cc:79: void test(std::chars_format): Assertion 'ec4 == std::errc() &&
> ptr4 == ptr1' failed.
> ABORT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
--- Comment #4 from Jonathan Wakely ---
(In reply to Richard Biener from comment #3)
> Supposedly C defines literal suffixes for int32_t? Otherwise using (1L <<
> 17) might work as well here.
Yes, it could be:
INT32_C(1) << 17
That expands t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ee629d242d9f93a38e49bed904bb334bbe15dde1
commit r13-4353-gee629d242d9f93a38e49bed904bb334bbe15dde1
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #9 from Jonathan Wakely ---
Please read https://gcc.gnu.org/bugs/ and provide the requested info!
It asks for several things which are still missing and should not be difficult,
e.g. the output of `gcc -v`
It works fine for me with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107889
--- Comment #2 from Jonathan Wakely ---
I think this is https://wg21.link/cwg1828 which was resolved by
https://wg21.link/p1787 which GCC does not implement yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107889
--- Comment #3 from Jonathan Wakely ---
(In reply to David Mazières from comment #0)
> A similar problem was reported in bug #59766 for friend functions returning
> auto.
That's unrelated.
The problem here is that decltype(auto)::f is a nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #18 from Jakub Jelinek ---
Or better yet
#include
#include
int
main ()
{
char *end;
const char *p = "6e-4966";
long double l = strtold (p, &end);
if (l != __LDBL_DENORM_MIN__ || end != p + 7)
printf ("%Le %s\n", l, end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #19 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:5dd4d2e93e3de60d4ef1068b6dfd06b6b9fff16e
commit r13-4354-g5dd4d2e93e3de60d4ef1068b6dfd06b6b9fff16e
Author: Yuri Gribov
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #20 from Martin Liška ---
Fixed on master. Do we want to do a backport?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
--- Comment #3 from Paul Thomas ---
Created attachment 53975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53975&action=edit
Fix for this PR
This is a trivial bug. The ICE is occurring in resolve.cc(derived_inaccessible)
because derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107493
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:2b293a949c0fbe21e47c4bc99f807dc941c02bb6
commit r13-4357-g2b293a949c0fbe21e47c4bc99f807dc941c02bb6
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107493
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176
Bug 107176 depends on bug 107493, which changed state.
Bug 107493 Summary: [13 Regression] Wrong code at -Os on x86_64-linux-gnu since
r13-3486-g4c5b116077638277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107493
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107894
Bug ID: 107894
Summary: [feature request] _GLIBCXX_ASSERTIONS for
std::optional
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107895
Bug ID: 107895
Summary: mt19937 bad performance on LP64
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107885
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107894
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102712
Jonathan Wakely changed:
What|Removed |Added
CC||tim at klingt dot org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107895
--- Comment #1 from Jan Engelhardt ---
clang-15.0.5+gnustdlibc timing distribution.
-m32 -m64
mt19937 6.0 4.7
mt19937_64 9.2 4.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
--- Comment #5 from Jonathan Wakely ---
Oh, except that we pass it to cplus_demangle(const char*, int) and so anything
above the first 16 bits is lost anyway. Should that function use int32_t
instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
--- Comment #3 from Richard Biener ---
I suppose it's the
+ MEM [(integer(kind=4) *)_13] = { -1, 1, -1, 1 };
...
+ .LEN_STORE (vectp.75_247, 64B, 11, { 255, 255, 255, 255, 0, 0, 0, 1, 255,
255, 255, 255, 0, 0, 0, 1 }, -1);
..
+ MEM [(integ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
--- Comment #4 from Richard Biener ---
Created attachment 53976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53976&action=edit
patch
Can you please test this patch? Visually inspecting the fortran testcase and
the GIMPLE testcase shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107895
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #10 from Jamaika ---
```
Using built-in specs.
COLLECT_GCC=g++.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-nls --enable-languages=c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #11 from Jamaika ---
without #define __cpp_lib_atomic_wait 201907L
```
Using built-in specs.
COLLECT_GCC=g++.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32
--target=x86_64-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #12 from Jamaika ---
with 'latch.h'
```
Using built-in specs.
COLLECT_GCC=g++.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-nls --ena
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801
--- Comment #11 from Jonathan Wakely ---
I don't think we want to build (parts of) the library with non-default options
like that. It might affect the ABI of the library, and all users would have to
use the same options for their own code.
I th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #19 from dave.anglin at bell dot net ---
On 2022-11-28 4:39 a.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
>
> --- Comment #18 from Jakub Jelinek ---
> Or better yet
> #include
> #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #11)
> I think we can just use bitset::size_type for the _M_bytes member.
This compiles for all multilibs of x86_64, h8300-elf, and msp430-elf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107895
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
--- Comment #5 from Jakub Jelinek ---
It is the foperator_mult::op{1,2}_range and can be seen even on:
double
foo (double x, double y)
{
double z = x * y;
if (z == 0.0)
return x;
return 42.0;
}
testcase.
2->3 (T) x_2(D) : [frange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
--- Comment #4 from Paul Thomas ---
Created attachment 53977
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53977&action=edit
Ongoing patch for PR37336
Fixes this PR, so testcase will be added to the collection.
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
--- Comment #5 from Paul Thomas ---
Hi Thomas,
I hope that you are well and that the lack of time is for a good cause?
I have just returned to my finalizer patch. With it applied, your testcase
produces the same output as NAG.
I will attach t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a64775a0edd46980036b757041f0c065ed9f8d22
commit r13-4364-ga64775a0edd46980036b757041f0c065ed9f8d22
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382
--- Comment #6 from Paul Thomas ---
(In reply to Thomas Koenig from comment #4)
> To add some variety to the tests, nagfor gives
>
> destructor4(complicated) 2.000 2.000
> destructor5 (simple2) 5
> destructor5 (simple2) 6
> dest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #13 from Jonathan Wakely ---
(In reply to Jamaika from comment #6)
> I don't understand something. Why _GLIBCXX_HAS_GTHREADS works for
> std::jthread but not for std::latch
std::jthread doesn't depend on _GLIBCXX_HAS_GTHREADS, it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #14 from Jonathan Wakely ---
(In reply to Jamaika from comment #11)
> without #define __cpp_lib_atomic_wait 201907L
You should not be defining this anyway, it's defined by the library when the
feature is supported. You can't change
figure
--prefix=/data_sdb/toolchain/cc1s/arm-lin --enable-languages=c,c++
--disable-bootstrap --target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221128 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807
David Malcolm changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #15 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896
Andrew Pinski changed:
What|Removed |Added
Summary|ICE in |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868
--- Comment #3 from Richard Biener ---
a backport depends on r11-3610-gb6158faacbfb7d
Your reduced testcase doesn't compile since it references undeclared 'pobj'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896
--- Comment #1 from Andrew Pinski ---
Going backwards:
gcc_assert (VECTOR_MODE_P (intermediate_mode));
..
intermediate_mode = insn_data[icode1].operand[0].mode;
...
if ((icode1 = optab_handler (optab1, vec_mode)) == CODE_FOR_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868
--- Comment #4 from Richard Biener ---
I can confirm backporting the two revs fixes the -O1 execute FAIL of
20_util/allocator/1.cc on the branch. Fully testing that now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #16 from Jonathan Wakely ---
Something like ...
--- include/bits/atomic_wait.h 2022-11-07 15:38:32.551751184 +
+++ /tmp/inc/bits/atomic_wait.h 2022-11-28 16:27:51.352489618 +
@@ -33,7 +33,7 @@
#pragma GCC system_header
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107773
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107885
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:7b79fa930917da735f02b4f6911dfbb0a91f9714
commit r13-4369-g7b79fa930917da735f02b4f6911dfbb0a91f9714
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:75e562d2c4303d3918be9d1563284b0c580c5e45
commit r13-4371-g75e562d2c4303d3918be9d1563284b0c580c5e45
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801
--- Comment #14 from Jonathan Wakely ---
src/c++17/memory_resource.cc builds now with trunk, but I still get the
assembler errors for src/c++17/fs_dir.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107885
--- Comment #2 from Jonathan Wakely ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107888
--- Comment #2 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
> which means we fail to optimize a > b ? 1 : b as well, no?
Yes that is correct.
Even for max, "a >= b ? a : 6;" would need to be "reverted" 6 back to b.
[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105129
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105127
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-11-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
Bug ID: 107897
Summary: [13 Regression] ICE in verify_curr_properties, at
passes.cc:2201
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107898
Bug ID: 107898
Summary: [11/12/13 Regression] ICE in irange_intersect, at
value-range.cc:1640
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868
--- Comment #5 from Victor Do Nascimento
---
(In reply to Richard Biener from comment #3)
> a backport depends on r11-3610-gb6158faacbfb7d
>
> Your reduced testcase doesn't compile since it references undeclared 'pobj'.
How embarassing. Accid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107899
Bug ID: 107899
Summary: ICE in resolve_deallocate_expr, at
fortran/resolve.cc:7576
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #17 from Jamaika ---
Testing atomic_wait, errors are still there. Thanks for taking up the topic.
```
In file included from c:\gcc1300\include\c++\13.0.0\mutex:60,
from c:\gcc1300\include\c++\13.0.0\bits\atomic_wait.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772
--- Comment #2 from Avi Kivity ---
I expect something like this:
f(int*, int*):
cmp rdi, rsi
je .L10
.L4:
cmp DWORD PTR [rsi], 0
jne .L14
.L3
add rsi, 4
cmp rsi, rdi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772
--- Comment #3 from Andrew Pinski ---
(In reply to Avi Kivity from comment #2)
> I expect something like this:
Right doing shrink wrapping like that is "hard" really and someone would need
to add a full infrastructure for this. I doubt it will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107898
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105126
--- Comment #5 from Andrew Pinski ---
Note for aarch64, is_bin_1 produces better code on the trunk than is_bin_0.
There is an extra zero extent for is_bin_0 there.
So I suspect this is we get a promotion/demotion pass, it will definitely need
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105130
--- Comment #3 from Andrew Pinski ---
I would have thought this was by design. a statement expression last statement
is "used" there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105130
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #23 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:2200b7054638bbf157192a4dca23886dd420becb
commit r13-4374-g2200b7054638bbf157192a4dca23886dd420becb
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #24 from Alexander Monakov ---
(In reply to Peter Cordes from comment #23)
> But at least on Linux, I don't think there's a way for user-space to even
> ask for a page of WT or WP memory (or UC or WC). Only WB memory is easily
> ava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #14 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:07b9bcc1d1484f8f1c850ff14db678fb6b1e4d36
commit r13-4375-g07b9bcc1d1484f8f1c850ff14db678fb6b1e4d36
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105127
--- Comment #2 from Sam Darwin ---
yes, reported: https://cygwin.com/pipermail/cygwin/2022-January/250693.html
I don't know where the bug originates, in gcc or cygwin. If an expert in gcc
could submit a fix to cygwin or vice versa.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #25 from Peter Cordes ---
(In reply to Alexander Monakov from comment #24)
>
> I think it's possible to get UC/WC mappings via a graphics/compute API (e.g.
> OpenGL, Vulkan, OpenCL, CUDA) on any OS if you get a mapping to device
> m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
1 - 100 of 235 matches
Mail list logo
