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=119695
Simon Sobisch changed:
What|Removed |Added
CC||simonsobisch at gnu dot org
--- Comment
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=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=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
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #8 from And
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=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=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=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=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=119694
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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=11196
Andrew Pinski changed:
What|Removed |Added
CC||dbaron at fas dot harvard.edu
--- Commen
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=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=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
--- 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=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=116153
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
See Also|
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=119533
Vineet Gupta changed:
What|Removed |Added
Status|NEW |ASSIGNED
See Also|
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=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=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=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=119682
Robert Dubner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=85517
Sam James changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-04-09
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
--- Comment #3 from Andrew Pinski ---
>so I think you're allowed to have bigger objects as long as you don't do
>pointer arithmetic on them.
Right but strlen could be defined as `char *start = arg; char *end = start;
while (!*end) end++; retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119592
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119689
--- Comment #16 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:07de7717a22b1503760e9b79dfbe22a0f428
commit r15-9334-g07de7717a22b1503760e9b79dfbe22a0f428
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119689
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117832
--- Comment #3 from GCC Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:3e3b665cc77791f2e088aeee124d8a9fb7f6eb41
commit r15-9333-g3e3b665cc77791f2e088aeee124d8a9fb7f6eb41
Author: Iain Buclaw
Date: Wed A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117682
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:08e381e8af3ec9beaa887824c41d4551b54e5063
commit r14-11552-g08e381e8af3ec9beaa887824c41d4551b54e5063
Author: Robin Dapp
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #14 from Jan Hubicka ---
> > I am OK with using addss cost of 3 for trunk&release branches and make this
> > more precise next stage1.
>
> That's what we use now? But I still don't understand why exactly
> 538.imagick_r regresses
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=119664
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=119692
Thomas Schwinge changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
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=108358
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=105926
Ville Voutilainen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
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=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
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=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=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=119682
Robert Dubner changed:
What|Removed |Added
Last reconfirmed||2025-04-09
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364
--- Comment #18 from Robert Dubner ---
The revised code will be based on passing pointers to lists of integers.
(I have managed to talk Jim out of his desire to pass structures created with
GENERIC to the library code. He thinks I am a sissy f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #14 from rdubner at symas dot com ---
> -Original Message-
> From: iains at gcc dot gnu.org
> Sent: Wednesday, April 9, 2025 11:19
> To: rdub...@gcc.gnu.org
> Subject: [Bug cobol/119414] cobol driver unconditionally adds plat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364
--- Comment #19 from Jakub Jelinek ---
(In reply to Robert Dubner from comment #18)
> The revised code will be based on passing pointers to lists of integers.
>
> (I have managed to talk Jim out of his desire to pass structures created
> with G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
Bug ID: 119694
Summary: Excessive getenv uses in cobol FE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: cobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Robert Dubner changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
Bug ID: 119693
Summary: GCC assumes wrong bounds for strlen() return value,
causing bogus bounds check elimination
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113646
--- Comment #6 from Jan Hubicka ---
The problem is that the internal loop in hottest function changes between train
and ref run (train run uses different variant of the loop). This disables
vectorization of the loop believed to be cold causing -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #13 from rguenther at suse dot de ---
On Wed, 9 Apr 2025, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
>
> --- Comment #12 from Jan Hubicka ---
> > Btw, it was your r8-4018-gf6fd8f2bd4e9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
--- Comment #10 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:07de7717a22b1503760e9b79dfbe22a0f428
commit r15-9334-g07de7717a22b1503760e9b79dfbe22a0f428
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116308
--- Comment #5 from GCC Commits ---
The releases/gcc-14 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:f3ac41f84249d10a1685c73d67e5d071902fcc4c
commit r14-11547-gf3ac41f84249d10a1685c73d67e5d071902fcc4c
Author: Jeff Law
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116256
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:47b509fef536455d59aeb7b8e97851099c6b29a5
commit r14-11546-g47b509fef536455d59aeb7b8e97851099c6b29a5
Author: Jeff Law
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117995
--- Comment #3 from Christophe Lyon ---
(In reply to Iain Buclaw from comment #2)
> @Christophe, I can only assume this is fixed, but have no way to test.
It seems so, has the test been renamed? I can see this with recent trunk:
PASS: libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #10 from Jakub Jelinek ---
E.g. one major problem with doing -rpath behind the scenes is that it totally
breaks GCC's relocatability. One should be able to move the gcc install
directories into other place and it should still work (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364
--- Comment #20 from Jakub Jelinek ---
As for the last declarative_1.cob issue,
--- gcc/cobol/structs.cc.jj 2025-04-08 16:21:34.775594364 +0200
+++ gcc/cobol/structs.cc2025-04-09 17:07:43.362275712 +0200
@@ -157,6 +157,7 @@ tree cblc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #15 from Iain Sandoe ---
(In reply to rdubner from comment #14)
> > -Original Message-
> > From: iains at gcc dot gnu.org
> > Sent: Wednesday, April 9, 2025 11:19
> > To: rdub...@gcc.gnu.org
> > Subject: [Bug cobol/119414] c
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=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=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=119414
--- Comment #12 from Iain Sandoe ---
(In reply to rdubner from comment #11)
> COBOL comes from long ago, and far away. And the vast bulk of code that I
> never forget is where my boss, paying my salary, hopes to someday actually
> make some m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
--- Comment #4 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:334545194d9023fb9b2f72ee0dcde8af94930f25
commit r15-9340-g334545194d9023fb9b2f72ee0dcde8af94930f25
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364
--- Comment #17 from Robert Dubner ---
Oi. "Wait for me, I'm your leader!"
Jim and I are in the process of a complete rewrite of how the declaratives and
exception processing are handled. I believe that most, if not all, of the
concerns raise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119636
Robert Dubner changed:
What|Removed |Added
CC||rdubner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #13 from Jakub Jelinek ---
(In reply to rdubner from comment #11)
>IDENTIFICATION DIVISION.
>PROGRAM-ID. caller.
>PROCEDUREDIVISION.
>CALL "callee1" ON EXCEPTION
> CALL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119636
--- Comment #2 from Robert Dubner ---
(In reply to Robert Dubner from comment #1)
> The revised code will be based on passing pointers to lists of integers.
>
> Those lists of integers are being established as static arrays of type
> integer_ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
--- Comment #6 from Jan Hubicka ---
as discussed in PR111551 the SPEC train run does not include hottest loop of
imagick (in ref loop), so we optimize it for size (in particular disable
vectorization) and get poor performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113646
--- Comment #7 from Jan Hubicka ---
Details are in PR111551
1 - 100 of 250 matches
Mail list logo
