https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
Bug ID: 108623
Summary: We need to grow the precision field in
tree_type_common for PowerPC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108624
Bug ID: 108624
Summary: [OpenMP] Map(ptr, ptr[2:N-2]) will cause a segfault,
'map(ptr, ptr[0:N])'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
Richard Biener changed:
What|Removed |Added
Component|other |middle-end
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
manolis.tsamis at vrull dot eu changed:
What|Removed |Added
CC||manolis.tsamis at vrull d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106
Thomas Schwinge changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #13 from Richard Biener ---
(In reply to Tamar Christina from comment #7)
> (In reply to Andrew Pinski from comment #1)
> > So here is how I would tackle this:
> > Put all the needed .i/.ii files in a response file.
> >
> >
> > $CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #11 from Richard Biener ---
And now the recursion is avoided completely. I'm going to backport this last
fix after some time and would be interested if that solves your original issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #14 from Hongtao.liu ---
> I think we should remove the vect_can_peel_nonlinear_iv_p call from
> vectorizable_nonlinear_induction and adjust vect_can_peel_nonlinear_iv_p
> to require a .is_constant () VF.
Yes, testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108625
Bug ID: 108625
Summary: forwprop introduces new UB
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598
--- Comment #2 from Pavel Šimovec ---
Thanks for the insightful response.
We agree with the resolution, and I have missed that one of the tools actually
verifies the error:
https://github.com/aufover/aufover-benchmark/blob/77f9432747988bfbfb3a9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107499
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 107499, which changed state.
Bug 107499 Summary: [13 Regression] 433.milc regressed by 6-8% on zen3 at -O2
-flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107499
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756
Bug 100756 depends on bug 107499, which changed state.
Bug 107499 Summary: [13 Regression] 433.milc regressed by 6-8% on zen3 at -O2
-flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107499
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108607
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bfc070595bfb00abef88a002eee5d9117f5b86a7
commit r13-5621-gbfc070595bfb00abef88a002eee5d9117f5b86a7
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108607
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13 Regression] ICE in |[12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
Bug ID: 108626
Summary: GCC doesn't combine string literals for const
char*const and const char b[]
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756
--- Comment #8 from rdapp at gcc dot gnu.org ---
For completeness: haven't observed any fallout on s390 since and the regression
is fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108627
Bug ID: 108627
Summary: A new crash with using a simple class, inheritance and
a function (version 2)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #3 from rsandifo at gcc dot gnu.org
---
The explanation is in the SET_TYPE_VECTOR_SUBPARTS code:
/* We have two coefficients that are each in the range 1 << [0, 63],
so supporting all combinations would require 6 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
--- Comment #14 from User99627 ---
(In reply to fiesh from comment #13)
> User99627, a few points:
>
> * My test case does require lto to be present. There's nothing to be gained
> from your statement that the bug doesn't require lto, there ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108628
Bug ID: 108628
Summary: ASAN at -O3 misses a stack-use-after-return
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sani
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108573
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e4473d7cf871c8ddf8f22d105c5af6375ebe37bf
commit r13-5625-ge4473d7cf871c8ddf8f22d105c5af6375ebe37bf
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108573
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108624
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #14 from Jonathan Wakely ---
$ g++ -E -include type_traits -x c++ /dev/null | fgrep int128
struct __is_integral_helper<__int128>
struct __is_integral_helper
, signed __int128
, unsigned __int128
struct __make_unsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
--- Comment #4 from Gaius Mulley ---
Created attachment 54383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54383&action=edit
Proposed fix v2
Here is version 2 of the proposed fix which should also help resolve
PR modula2/108551.
Note a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517
--- Comment #7 from Jakub Jelinek ---
Or perhaps when considering the constprop see that for __first_5(D) being 0B
there would be pointer arithmetics on NULL (the __first_5(D) p+ 16) and so
would invoke UB or likely invoke UB and so not worth co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108629
Bug ID: 108629
Summary: 549.fotonik3d_r regresses 15-24% at -O2 -flto
-march=x86-64-v3 since r13-1203-g038b077689bb53
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
Bug ID: 108630
Summary: build failure with LTO enabled
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108631
Bug ID: 108631
Summary: gcc/rust/backend/rust-constexpr.cc:2099:33: error: too
few arguments to function ‘tree_node*
Rust::Compile::unshare_constructor(tree, const char*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108631
--- Comment #1 from Martin Liška ---
Created attachment 54384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54384&action=edit
Patch candidate
Please check what you get with -fmem-report with the suggested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #1 from Andre Heider ---
Forgot to mention:
CXXFLAGS_FOR_TARGET="$CFLAGS_FOR_TARGET"
Obviously :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108481
Jakub Jelinek changed:
What|Removed |Added
Known to work|12.2.0 |
Summary|[13 Regression] UBs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108572
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:1d77bfdf11fb9d7f9fcce7ed8817fc2877b3ded2
commit r13-5626-g1d77bfdf11fb9d7f9fcce7ed8817fc2877b3ded2
Author: Martin Liska
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108572
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108481
--- Comment #6 from Jakub Jelinek ---
I'd say the implementation intends to warn about UB that still remains in the
code after optimizations, if a result of some UB invoking operation isn't used
(the DCE case) or as in this case the UB happens o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108135
Martin Liška changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #2 from Andre Heider ---
Additionally, LDFLAGS_FOR_TARGET isn't part of the configure help:
./configure --help|grep FOR_TARGET
LD_FOR_TARGET is, attempting to shove LTO in there yields other problems (or I
am be doing it wrong).
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107755
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:5ce8961b46f050a96e8c542b34b1cf024ba95f1b
commit r13-5627-g5ce8961b46f050a96e8c542b34b1cf024ba95f1b
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107755
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:fb2d50f72caf3b84b315bc760368670680999749
commit r12-9095-gfb2d50f72caf3b84b315bc760368670680999749
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107755
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Summary|[10/11/12/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598
--- Comment #3 from David Malcolm ---
Yeah, it would be good if -fanalyzer detected such issues within loops, and
identified the iteration at which the access goes out-of-bounds. Handling that
is bug 108432 (which I'm treating as an RFE).
Than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432
--- Comment #6 from David Malcolm ---
Another example: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598#c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #10 from Martin Liška ---
(In reply to ValdikSS from comment #9)
> May I ask why was is closed as WONTFIX?
Because we're not planning to support such legacy hardware.
> It fails on VIA Eden Eshter.
Is it critical that the feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108628
Martin Liška changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108509
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:78589691ee158e689fa9bb7dec1165da475ea634
commit r13-5629-g78589691ee158e689fa9bb7dec1165da475ea634
Author: Martin Liska
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108509
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #11 from ValdikSS ---
Well, the function is called __builtin_cpu_supports, for which one might expect
that it just checks CPUID and returns reliable results, while in reality it
operates using the build-in CPU support list. The funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435
--- Comment #4 from Jakub Jelinek ---
I think the problem is that normally when gimplifying
OMP_CLAUSE_LASTPRIVATE_STMT we force a BIND_EXPR around it:
push_gimplify_context ();
if (TREE_CODE (OMP_CLAUSE_LASTPRIVATE_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #6 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:881bf8de9b07fb501d61ade8f521f1cc9dbe712e
commit r13-5630-g881bf8de9b07fb501d61ade8f521f1cc9dbe712e
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
Martin Liška changed:
What|Removed |Added
CC||Mayshao-oc at zhaoxin dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108632
Bug ID: 108632
Summary: [13 Regression] libstdc++ std/time/hh_mm_ss/1.cc on
"packed" platforms
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
Barnabás Pőcze changed:
What|Removed |Added
CC||pobrn at protonmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #11 from Andrew Macleod ---
To be clear, the reason it is unlikely to be ported to GCC12 is because this
depends on relation support in GORI to recognize the LHS and operand 1 are
equivalent. That support was first added in GCC13, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
--- Comment #5 from Martin Liška ---
(In reply to Gaius Mulley from comment #4)
> Created attachment 54383 [details]
> Proposed fix v2
>
> Here is version 2 of the proposed fix which should also help resolve
> PR modula2/108551.
>
> Note a new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108559
--- Comment #6 from Marek Polacek ---
*** Bug 108627 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108627
Marek Polacek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
--- Comment #5 from Andrew Macleod ---
I do not seem to be able to reproduce this... is it still valid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #10 from Kyle Shores ---
Ah, wait I lied. I must not have recompiled or something because everything
works now. Thank you again for addressing this and sorry for submitting a false
positive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
--- Comment #6 from Gaius Mulley ---
Will do - I'm currently seeing problems on a bootstrap build and regression
tests
(after a rebase). Once this clears I'll commit / push the changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107017
--- Comment #1 from David Malcolm ---
Should probably also handle scanf-style functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #12 from dhekir at gmail dot com ---
Created attachment 54386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54386&action=edit
another test case, this time with 1M calls and structs as arguments
A more complex test case, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #13 from dhekir at gmail dot com ---
Thank you very much for the work.
Running the attached file with `-O -finline-small-functions` does compile in
under 30 seconds on my computer.
However, when trying to compile the original progra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #20 from Tamar Christina ---
> > I don't think so for addhn, because it wouldn't truncate the top bits, it
> > truncates the bottom bits.
> >
> > The instruction does
> > element1 = Elem[operand1, e, 2*esize];
> > element2 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #1 from Andrew Pinski ---
I think what clang did is an invalid transformation.
You can use -fmerge-all-constants to get this same transformation in gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
Jakub Jelinek changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
Jakub Jelinek changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #4 from Michael Meissner ---
I must have missed the spare bits. I think it is better to use the full 16
bits for precision. I also think your other changes to realign bit fields
greater than 1 bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108632
--- Comment #1 from CVS Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:a939dd835798efd40b78f7c0070177616e3f36d3
commit r13-5633-ga939dd835798efd40b78f7c0070177616e3f36d3
Author: Hans-Peter Nilsson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551
--- Comment #11 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:9fadd8dec79876d3c393daccc62959f6f4853cc5
commit r13-5634-g9fadd8dec79876d3c393daccc62959f6f4853cc5
Author: Gaius Mulley
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
--- Comment #7 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:9fadd8dec79876d3c393daccc62959f6f4853cc5
commit r13-5634-g9fadd8dec79876d3c393daccc62959f6f4853cc5
Author: Gaius Mulley
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #5 from Segher Boessenkool ---
The failure was not detected, only things down the road broke up, can we add
something for that? Just a strategically placed assert should do fine.
Less important if we grow the field all the way to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103994
--- Comment #2 from Melven.Roehrig-Zoellner at DLR dot de ---
Can confirm this with current trunk (see https://godbolt.org/z/16K1jhrsW).
I stumbled upon this while trying to include the C++ library Eigen in the
global module fragment (same stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2023-02-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #7 from Michael Meissner ---
Created attachment 54387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54387&action=edit
Proposed patch combining Richard's patch and an assertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #13 from Jakub Jelinek ---
I have tried a cross with the genmultilib exit 1 commented out, and the
difference between the previous state of just MULTILIB_DIRNAMES = 64 and 64 32
is
--- multilib.h 2023-02-01 18:41:31.013661359 +0100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107944
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:8495d80f44488b2566afc84b3f5704dd7c999e21
commit r12-9096-g8495d80f44488b2566afc84b3f5704dd7c999e21
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #5 from Marek Polacek ---
Sorry, I'm not sure if the false positive in comment 0 can be fixed. I can't
simply compare the type of the temporary argument and the return type, because
we may be returning a subobject of the temporary a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570
--- Comment #4 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #3)
> Aldy/Andrew, any ideas about this?
patch already in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-02-01
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
--- Comment #2 from Steve Kargl ---
On Wed, Feb 01, 2023 at 06:13:33PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
>
> This appears to be related to Sandra and Tobias's work on CFI. In particula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #2 from Marat Radchenko ---
Thanks for the pointer to -fmerge-all-constants, that helped me to google out
why such transformation is invalid: https://stackoverflow.com/a/70328102
Should I close this issue as INVALID (and probably op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #7 from Marek Polacek ---
Sure, I could (lookup_member?). It's still just guessing but maybe it would be
worth it. Let me try...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108609
--- Comment #2 from seurer at gcc dot gnu.org ---
I tried the patch and it seems to work fine.
make -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/pr108527.f90"
# of expected passes3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #14 from James McKelvey ---
Okay I installed gcc-12, built about 10/29/2022:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/12.2.1/lto-wrapper.exe
Target: x86_64-pc-cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #15 from Jakub Jelinek ---
(In reply to James McKelvey from comment #14)
> Okay I installed gcc-12, built about 10/29/2022:
>
> $ g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #16 from James McKelvey ---
$ find /usr/local/lib/gcc -name libgcc_s\*.dll -o -name libgcc.a
/usr/local/lib/gcc/x86_64-pc-cygwin/11.3.1/libgcc.a
/usr/local/lib/gcc/x86_64-pc-cygwin/12.1.1/libgcc.a
/usr/local/lib/gcc/x86_64-pc-cygwin/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103869
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #8 from joseph at codesourcery dot com ---
See also bug 102989 (C2x _BitInt) regarding another case for which growing
TYPE_PRECISION would be useful.
1 - 100 of 133 matches
Mail list logo
