https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087
--- Comment #2 from Adam Badura ---
(In reply to Andrew Pinski from comment #1)
> Zero sized arrays are a gcc extension.
The problem is with `std::array` rather than C-array. It seems to me
`std::array` can have `0` size - it is not an extensio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087
--- Comment #1 from Andrew Pinski ---
Zero sized arrays are a gcc extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087
Bug ID: 111087
Summary: -Wnonnull issued for std::array of zero size when
under C++20
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111086
--- Comment #2 from Tony Josi ---
In that case I think the warning should be generated for all the fields in the
struct, why just the first 2 fields (ch1 and ch2 in the example struct in the
bug report)?
Also the warning is listed under [-Watt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111086
--- Comment #1 from Andrew Pinski ---
if (STRICT_ALIGNMENT)
warning (OPT_Wpacked, "packed attribute causes inefficient "
"alignment for %qE", name);
else
warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111086
Bug ID: 111086
Summary: Possibly incorrect warning: arm-none-eabi-gcc:packed
attribute causes inefficient alignment for
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111002
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111084
--- Comment #6 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #5)
> Also buildroot uses sysroots and chroot/containers instead.
>
> Containers/chroot is the better approach anyways.
We use sysroot and chroot since Linux From Scratc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111084
--- Comment #5 from Andrew Pinski ---
Also buildroot uses sysroots and chroot/containers instead.
Containers/chroot is the better approach anyways.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111084
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #13 from waffl3x ---
I am finding myself realizing that implementing this as a member function and
turning off member function bits seems to be more difficult than implementing
it as a static function and implementing member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111062
--- Comment #1 from Hongtao.liu ---
(In reply to Zdenek Sojka from comment #0)
> Created attachment 55755 [details]
> reduced testcase
>
> Compiler output:
> $ x86_64-pc-linux-gnu-gcc -O -mavx10.1-256 -mavx512bw -mno-avx512f testcase.c
> cc1: w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111002
--- Comment #2 from Andrew Pinski ---
here is the corrected patch:
diff --git a/gcc/match.pd b/gcc/match.pd
index 851f1af6eac..81666f28465 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4718,6 +4718,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111082
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-08-20
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111085
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111085
--- Comment #2 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:a724c6e93dfce3a86f9c0fbf8be4316c37dd5a40
commit r14-3346-ga724c6e93dfce3a86f9c0fbf8be4316c37dd5a40
Author: Gaius Mulley
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108143
--- Comment #5 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:a724c6e93dfce3a86f9c0fbf8be4316c37dd5a40
commit r14-3346-ga724c6e93dfce3a86f9c0fbf8be4316c37dd5a40
Author: Gaius Mulley
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111085
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2023-08-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111085
Bug ID: 111085
Summary: nexttoward and nexttowardf have incorrect definitions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111084
--- Comment #3 from Henrique ---
Hello, the reason is that linux from scratch bootstraps an initial toolchain
decoupled from the host toolchain before installing the final system. The final
installation will use the correct paths. The initial to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111084
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556
Andrew Pinski changed:
What|Removed |Added
CC||hdante at gmail dot com
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111084
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111084
Bug ID: 111084
Summary: Support configurable dynamic linker path
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: drive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
--- Comment #2 from gnzlbg ---
Update: the reference implementation is now merged into libc++ and will release
with LLVM 17.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49588
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110756
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110756
--- Comment #5 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:40a6803c6d8ca244a7bdda8e4ec986c418362b24
commit r14-3344-g40a6803c6d8ca244a7bdda8e4ec986c418362b24
Author: Thiago Jung Bauermann
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110919
--- Comment #5 from Andrew Pinski ---
Or take:
```
_Bool g(int a, int b)
{
b &= 1;
_Bool t = a == b;
_Bool e = a != 0;
_Bool g = t & e;
return g;
}
int g0(int a, int b)
{
b &= 1;
_Bool t = 1 == b;
_Bool e = a == 1;
_Bool g = t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110919
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111082
Andrew Pinski changed:
What|Removed |Added
Summary|ICE in |[14 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111081
--- Comment #1 from Iain Sandoe ---
This seems likely related to whether we consider type info to be weak linkage.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111083
--- Comment #1 from Iain Sandoe ---
since this is a scan-dump test, we do not need to execute it - I guess we could
add "-fno-PIE" to the options - AFAIR we will only reject this when linking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111083
Francois-Xavier Coudert changed:
What|Removed |Added
Last reconfirmed||2023-08-20
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111083
Bug ID: 111083
Summary: Test failure of g++.dg/ipa/pr67056.C on darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #12 from Gašper Ažman ---
Replies to relevant snippets inline.
That was quite a write-up!
> The only compelling case I can think of for such a thing would be passing a
> pointer type that isn't related by inheritance anyway. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111082
--- Comment #1 from Manuel Lauss ---
Created attachment 55767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55767&action=edit
another compressed unreduced testcase
Another testcase. it triggers with "-march=zvner1" but not e.g. "core2"
pressed unreduced testcase
gcc version 14.0.0 20230820 (experimental)
d77c280454cfba48ef38357145cecdabc8c1b05c
# gcc -O2 -march=znver4 -mtune=znver4 -pipe -std=gnu++11 gcc14-bf.ii
In file included from
/tmp-ram/portage/media-gfx/hugin-2022.0.0/work/hugin-2022.0.0/src/hugin_base/panodata/PanoramaDa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111081
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111081
Bug ID: 111081
Summary: LTO link failure on darwin: g++.dg/lto/pr65276
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080
--- Comment #2 from sagebar at web dot de ---
@Andrew Pinski
Of course: yes. I did make a mistake there, but only for this case:
> int (*fun_t)(struct foo *); // Leak (even w/o restrict!)
asm:
...
.globl fun_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080
Andrew Pinski changed:
What|Removed |Added
Summary|restrict qualifier causes |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080
--- Comment #1 from Andrew Pinski ---
> static int (*fun_t)(struct foo *); // Leak (even w/o restrict!)
> int (*fun_t)(struct foo *); // Leak (even w/o restrict!)
The above should include the foo debug information as th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080
Bug ID: 111080
Summary: restrict qualifier leaks debug info
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110919
--- Comment #3 from Andrew Pinski ---
The first change we get is threadfull1 where there is an extra jump threading.
And then phiopt2 changes:
[local count: 719407024]:
if (l_15(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
into:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110918
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-08-20
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111036
Andrew Pinski changed:
What|Removed |Added
Depends on||99309
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111027
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.5.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111043
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070
--- Comment #3 from Andrew Pinski ---
In this case name1 and name2 are both ADDR_EXPR rather than SSA_NAMES.
We start with:
```
[local count: 1073741822]:
_1 = (long unsigned int) &c_ary[0];
_2 = _1 & 7;
if (_2 != 0)
goto ; [34.00%]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-08-20
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986
--- Comment #20 from Andrew Pinski ---
Only the scalar testcase remains failing now. I will come up with a solution
next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111006
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986
--- Comment #19 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:70c50c87273d940918225d5c6b03f1ccfb6f978e
commit r14-3337-g70c50c87273d940918225d5c6b03f1ccfb6f978e
Author: Andrew Pinski
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111006
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:70c50c87273d940918225d5c6b03f1ccfb6f978e
commit r14-3337-g70c50c87273d940918225d5c6b03f1ccfb6f978e
Author: Andrew Pinski
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
--- Comment #6 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #5)
> See
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054899.html
>
> Also
This is just a buggy test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111063
--- Comment #2 from Andrew Pinski ---
Also I tested GCC 13.2.0 with -fsanitize=float-cast-overflow and GCC does
produce an error message at runtime for the original testcase too.
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/format:1489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111063
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
62 matches
Mail list logo
