https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119704
--- Comment #2 from Andrew Pinski ---
I don't want to be added to the CC list of x86 mem* because I am just helping
triaging bug reports and x86 is not my main target that I care about.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119704
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |target
--- Comment #1 from Andrew Pinsk
-Explorer-Build-gcc-ca4e6e6317ae0ceada8c46ef5db5ece165a6d1c4-binutils-2.42)
15.0.1 20250409 (experimental)
... and got the same result.
I have not verified memcpy, I suspect it might suffer the same problem.
src:
void zero(char *buf)
{
__builtin_memset(buf, 0, SIZE);
}
compiled like so:
cc -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119661
--- Comment #6 from Jakub Jelinek ---
https://wg21.link/cwg1836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #12 from Hongtao Liu ---
Let's just fix it in GCC16, either solution is ugly.
-ca4e6e6317ae0ceada8c46ef5db5ece165a6d1c4-binutils-2.42)
15.0.1 20250409 (experimental)
... and got the same result.
I have not verified memcpy, I suspect it might suffer the same problem.
src:
void zero(char *buf)
{
__builtin_memset(buf, 0, SIZE);
}
compiled like so:
cc -O2 -DSIZE=48 -mno-sse
-mmemset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #11 from Haochen Jiang ---
We have two temporary solutions in GCC 14 and GCC 15 since we could not simply
reject -mno-evex512. In GCC 16, since it is deprecated, no more issue for that.
Plan A: Use vmovq to only clear lower 64 bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119661
--- Comment #5 from Jakub Jelinek ---
https://eel.is/c++draft/expr.ref#5.sentence-2
says though
"The class type shall be complete unless the class member access appears in the
definition of that class."
Isn't that the case here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
--- Comment #4 from rguenther at suse dot de ---
On Wed, 9 Apr 2025, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
>
> Richard Sandiford changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115259
Andrew Pinski changed:
What|Removed |Added
Attachment #61054|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Simon Sobisch changed:
What|Removed |Added
CC||simonsobisch at gnu dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119661
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115259
--- Comment #10 from Andrew Pinski ---
Comment on attachment 61054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61054
Maybe a testcase
There is a typo in the testcase.
if (e[0] != 2)
should be
if (e[0] != 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #2 from Richard Biener ---
getenv is also not the cheapest thing to do, so I'd at least put it behind a
debug option (or param?).
So for now, amend the existing -f{flex,trace,yacc}-debug flags with
a -fextra-debug flag and replace t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115259
--- Comment #8 from Andrew Pinski ---
Created attachment 61054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61054&action=edit
Maybe a testcase
I tried this on x86_64 with:
-O2 -fdisable-tree-cselim -march=skylake-avx512 -fno-vect-cost-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #17 from Richard Biener ---
(In reply to Jan Hubicka from comment #14)
>
> Counting latencies, I think vinserti64x2 is 1 cycle and vpinst is
> integer->sse move that is slower and set to 4 cycles.
> Overall it is wrong that we use ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116153
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #5 from Sam James ---
Fixed b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #16 from Richard Biener ---
(In reply to Jan Hubicka from comment #15)
> I made sily stand-alone test:
>
> long test[4];
> __attribute__ ((noipa))
> void
> foo (unsigned long a, unsigned long b, unsigned long c, unsigned long d)
> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104277
Bug 104277 depends on bug 116153, which changed state.
Bug 116153 Summary: -fdebug-compare failure when building bmake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116153
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116153
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
Bug ID: 119702
Summary: PPCLE: Inefficient auto-vectorization for 64-bit
shifts on Power9
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #10 from Sam James ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119695
Simon Sobisch changed:
What|Removed |Added
CC||simonsobisch at gnu dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115259
--- Comment #7 from Andrew Pinski ---
Created attachment 61053
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61053&action=edit
preprocessed testcase
Note this is runable testcase but this is the preprocessed source for all_l4.c
that seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115259
--- Comment #6 from Andrew Pinski ---
So there is a sink difference in the loop which sets extent[n].
Before we had:
```
extent[n_207] = _20;
if (_20 < 0)
goto ; [41.00%]
else
goto ; [59.00%]
[local count: 48082917]:
extent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #8 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115259
--- Comment #5 from Andrew Pinski ---
The error exacted message "Incorrect extent in return value of ALL intrinsic in
dimension" comes from _gfortran_all_l4 which is defined in
gfortran/generated/all_l4.c .
This is the code which does the chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61304
--- Comment #2 from Andrew Pinski ---
With -O3 -fno-trapping-math, GCC 14+ can vectorize this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> Looks to be fixed on the trunk (since at least 20241023).
I was wrong it was after 20241023 but it works today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551
--- Comment #6 from Hongtao Liu ---
(In reply to Jan Hubicka from comment #5)
> as discussed in PR111551 the SPEC train run does not include hottest loop of
> MorphologyApply, so MeanShiftImage may have same issue and auto-fdo may be
> kind of c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85517
Sam James changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490
--- Comment #17 from GCC Commits ---
The releases/gcc-14 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:630bca9fa83236e108e9421549bdd5058133c3dd
commit r14-11578-g630bca9fa83236e108e9421549bdd5058133c3dd
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119574
--- Comment #10 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:f3862ab07943d1fc6e6a0416657ae4b7d1f3941d
commit r15-9350-gf3862ab07943d1fc6e6a0416657ae4b7d1f3941d
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105926
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
--- Comment #3 from Sam James ---
r15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110502
--- Comment #6 from Andrew Pinski ---
I am trying to understand something here:
```
[local count: 8687547538]:
_11 = j_lsm.17_4 + 1;
_12 = s_lsm.19_35 > 2;
_13 = s_lsm.19_35 == 0;
_22 = _12 | _13;
_30 = (int) _22;
_15 = _30 * -3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105926
Andrew Pinski changed:
What|Removed |Added
Alias||LWG3746
--- Comment #4 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105926
Ville Voutilainen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85517
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108358
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119682
Robert Dubner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94876
Thomas Schwinge changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119692
Thomas Schwinge changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #18 from Andrew Pinski ---
Note to test on aarch64 you need to add the extra field:
int e[1024];
to force the use of memset libcall. And yes the trunk works now too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116153
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119701
Bug ID: 119701
Summary: Ada.Calendar.Formatting.Day_Of_Week returns wrong
value after Ada.Calendar.Time is incremented via
Ada.Calendar.Arithmetic."+".
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119700
Bug ID: 119700
Summary: Add va_list and other va_* functions in JIT
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #20 from Bruno Haible ---
Joseph,
When you integrate PO files into GCC's git, would you be willing to install the
newest GNU gettext release, in order to get error checking from "msgfmt -c"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119699
--- Comment #1 from Andrew Pinski ---
Also for:
```
class x
{
public:
x ();
x (const x&);
int func ();
private:
int a;
};
x g ()
{
return x{};
}
```
We should be able just do a tail call to `x::x()` (but that depends on 67797
which I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #19 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #17)
> This is a different issue where the C++ front-end does not add a fnspec for
> the constructor (and deconstructor) with `targetm.cxx.cdtor_returns_this ()`
> re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119699
Bug ID: 119699
Summary: fnspec for constructors/deconstructors don't say they
return this when targetm.cxx.cdtor_returns_this ()
returns true
Product: gcc
Versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
Andrew Pinski changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119574
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:630bca9fa83236e108e9421549bdd5058133c3dd
commit r14-11578-g630bca9fa83236e108e9421549bdd5058133c3dd
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119574
--- Comment #11 from GCC Commits ---
The releases/gcc-14 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:ff5fdb3cad1a76768406e0fcec2010cdd72f49fc
commit r14-11577-gff5fdb3cad1a76768406e0fcec2010cdd72f49fc
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
Vineet Gupta changed:
What|Removed |Added
Status|NEW |ASSIGNED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046
--- Comment #3 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:d69f73c0334486f3c66937388f02008736809e87
commit r15-9351-gd69f73c0334486f3c66937388f02008736809e87
Author: Patrick Palka
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490
--- Comment #16 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:d69f73c0334486f3c66937388f02008736809e87
commit r15-9351-gd69f73c0334486f3c66937388f02008736809e87
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
--- Comment #35 from lucier at math dot purdue.edu ---
(In reply to Jakub Jelinek from comment #34)
> (In reply to lucier from comment #33)
> > It is my understanding that with the set of patches related to this PR, GCC
> > 15 with -foptimize-ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119682
--- Comment #2 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:6704d95ec859d9e7480da130bff1e6b58fe37350
commit r15-9349-g6704d95ec859d9e7480da130bff1e6b58fe37350
Author: Bob Dubner
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698
Bug ID: 119698
Summary: gen_il-main: raised PROGRAM_ERROR : finalize/adjust
raised exception
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #19 from Bruno Haible ---
Jakub,
(In reply to Jakub Jelinek from comment #18)
> ... if during patch review the submitter is reminded to
> post a patch against gettext, there could be a few months before it is
> actually needed (Feb-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96966
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #17 from Bruno Haible ---
Jakub, Eric,
What's your take on comment #9 and comment #11? How would you like the GCC team
and GNU gettext developers to collaborate in the future?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #18 from Jakub Jelinek ---
I'm afraid implementing format specifier extensions months or years before they
are actually used in the compiler is not possible, they are added when we need
them for something. Usually that is during gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119696
--- Comment #3 from Christoph Steefel ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am 99% sure this was a fix and the warning is correct now vs what it was
> > before and not being hidden.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
--- Comment #34 from Jakub Jelinek ---
(In reply to lucier from comment #33)
> Sorry, I screwed up and fired off my comment before it was finished. Here's
> the rest:
>
> (c) With today's GCC mainline head, those tail calls *are* optimized, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119697
Bug ID: 119697
Summary: Support for exception subclass matching in analyzer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
--- Comment #32 from Andrew Pinski ---
(In reply to lucier from comment #31)
> I'm trying to analyze some failures I'm seeing where
>
> (a) GCC 14 does not "optimize" tail calls with -foptimize-sibling-calls with
> a system that expects this op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119664
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
--- Comment #33 from lucier at math dot purdue.edu ---
Sorry, I screwed up and fired off my comment before it was finished. Here's
the rest:
(c) With today's GCC mainline head, those tail calls *are* optimized, as
confirmed with the musttail at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2082
Andrew Pinski changed:
What|Removed |Added
Resolution|WONTFIX |DUPLICATE
--- Comment #13 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196
Andrew Pinski changed:
What|Removed |Added
CC||dbaron at fas dot harvard.edu
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
lucier at math dot purdue.edu changed:
What|Removed |Added
CC||feeley at iro dot umontre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119664
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4203060a73e65e4fa3e091b060a973c3296b84e9
commit r15-9345-g4203060a73e65e4fa3e091b060a973c3296b84e9
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
--- Comment #12 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
--- Comment #11 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:76d902a68d8331fa3d06f3ba04d361795b17bb5a
commit r15-9343-g76d902a68d8331fa3d06f3ba04d361795b17bb5a
Author: Andrew Pinski
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
--- Comment #10 from Andrew Pinski ---
So the max strlen should be `PTRDIFF_MAX - 1`. Because the max array size is
PTRDIFF_MAX which includes the null character so it should be -1.
So this is the confusing part I think. And where the `off by o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119696
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
Bug 101603 depends on bug 119696, which changed state.
Bug 119696 Summary: [14/15 Regression] Visibility warning when using a
pointer-to-member-function to a hidden member method as a template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119696
--- Comment #1 from Andrew Pinski ---
I am 99% sure this was a fix and the warning is correct now vs what it was
before and not being hidden.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #17 from Iain Sandoe ---
(In reply to Robert Dubner from comment #16)
> Mainframe programmers sometimes think differently, I believe.
>
> If my understanding from discussions with an old-school mainframe programmer
> -- who admitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118309
--- Comment #2 from GCC Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:cee353c2653d274768a67677c8ea37fd23422b3c
commit r15-9342-gcee353c2653d274768a67677c8ea37fd23422b3c
Author: Iain Buclaw
Date: Wed A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
--- Comment #6 from Jann Horn ---
@Andrew/Jakub: I am not convinced that that is theoretically in line with the
standard, but you've convinced me that it might be somewhat reasonable for the
compiler to assume in practice.
(Though regarding the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118309
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117832
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #15 from Roland Illig ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Roland Illig from comment #1)
> > I wrote a little program to check these, and while doing this, I noticed the
> > ambiguity that %td could mean a t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
--- Comment #9 from Harald van Dijk ---
(In reply to Jann Horn from comment #8)
> (In reply to Harald van Dijk from comment #7)
> > I think implementations have two valid ways of dealing with this: either
> > malloc must fail to allocate such a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
--- Comment #8 from Jann Horn ---
(In reply to Harald van Dijk from comment #7)
> I think implementations have two valid ways of dealing with this: either
> malloc must fail to allocate such a large object, or standard library
> functions must h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
Richard Sandiford changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
--- Comment #7 from Harald van Dijk ---
(In reply to Jakub Jelinek from comment #5)
> but you shouldn't call standard string/memory functions on it,
> you are then on your own to deal with it.
Does the standard say so anywhere? Yes, it says poi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
--- Comment #5 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #4)
> (In reply to Iain Sandoe from comment #2)
> > it's always been broken, unfortunately (for a start, it gets the range
> > wrong)
> > At that stage, there were not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119664
--- Comment #5 from Waldemar Brodkorb ---
Hi,
the patch works fine. Resulting kernel boots up fine.
best regards
Waldemar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117878
--- Comment #13 from GCC Commits ---
The releases/gcc-14 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:acb636a9c3ac18e7234e37c99bd6e9200b80b9bd
commit r14-11556-gacb636a9c3ac18e7234e37c99bd6e9200b80b9bd
Author: Pan Li
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 119320, which changed state.
Bug 119320 Summary: unexpected -Wstringop-overflow= when using memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119320
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119696
Bug ID: 119696
Summary: Visibility warning when using a
pointer-to-member-function to a hidden member method
as a template argument
Product: gcc
Version: 14.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
--- Comment #4 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #2)
> it's always been broken, unfortunately (for a start, it gets the range wrong)
> At that stage, there were not many exes that were large enough to trigger an
> iss
1 - 100 of 250 matches
Mail list logo
