https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #16 from Jonathan Wakely ---
(In reply to Sam James from comment #15)
> After chatting with jwakely, this is now on releases/gcc-12 as
> r12-9486-g47880309516fd5
That's a different fix for a different issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108202
Christoph Reiter changed:
What|Removed |Added
CC||reiter.christoph at gmail dot
com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
--- Comment #2 from Sam James ---
Created attachment 54955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54955&action=edit
a-FetchTypes.ii.xz
I noticed the filename was 'Unified...' so I tried out
https://firefox-source-docs.mozilla.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.2
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109677
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|Access control byp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
--- Comment #11 from Adelson Oliveira ---
I'm a linux user and gfortran comes with my distro. I mean, I did not compile
gcc.
Is this patch still to be tested? Am I expected to do something to test it? Or
I just wait until a new gfortran version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109677
Bug ID: 109677
Summary: Access control bypass for function template default
argument brace initialization of private default
constructor
Product: gcc
Version: 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
Bug ID: 109676
Summary: [13/14 regression] ICE in simplify_subreg, at
simplify-rtx.cc:7426 when building firefox with -O2
-march=alderlake -g
Product: gcc
Versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109675
Bug ID: 109675
Summary: GCC 13.1: the Modula-2 front-end fails to build on
some platforms
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #15 from Sam James ---
(In reply to Jonathan Wakely from comment #14)
> I think it should be fine. I would prefer to wait until 12.4 so it has more
> bake time, but that would just mean another few months of duplicate reports
> for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109657
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109674
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109674
Bug ID: 109674
Summary: [14 Regression] linking with libhwasan is now broken
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: link-failure
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109673
--- Comment #3 from Andrew Pinski ---
(In reply to Parke from comment #2)
>
> I compile my code with -Wall -Wextra and -Werror. Consequently, in order to
> get my code to compile (on Ubuntu), I have to write the following:
>
> void * discard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109673
--- Comment #2 from Parke ---
Thank you for the explanation.
It seems to me that it would (should?) be possible for -Os to detect the
cast-to-void and therefore suppress the second warning (line 5).
It also seems to me the above change, if imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #11 from Jeffrey A. Law ---
Coming back to this.
WRT extension elimination. I've been pondering if we want a late pass to do a
bit of this that can't be handled by REE.
So let's take the case of a Zbs instruction operating on a va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109673
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109673
Bug ID: 109673
Summary: warn_unused_result warnings are incorrect (and/or
missing) and vary when -Os is specified
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 108219, which changed state.
Bug 108219 Summary: [12 Regression] requirement fails on a valid expression
since r12-5253-g4df7f8c79835d569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106969
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106969
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:458bda5432d352469e258f1c0e4c2a37c853575a
commit r12-9493-g458bda5432d352469e258f1c0e4c2a37c853575a
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #15 from CVS Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:73e86b6766cc92aa8c18cc987bf95929c4ea0672
commit r12-9492-g73e86b6766cc92aa8c18cc987bf95929c4ea0672
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:73e86b6766cc92aa8c18cc987bf95929c4ea0672
commit r12-9492-g73e86b6766cc92aa8c18cc987bf95929c4ea0672
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #31 from Romain Geissler ---
Ok thanks for confirming. I was about to ask for a deployment one of our
gcc-based toolchain in production containing the current gcc 13.1.1, I will
wait a bit that this patch lands in the gcc 13 branch t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Component|fortran |libfortran
Last reconfirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #30 from Jonathan Wakely ---
(In reply to Romain Geissler from comment #28)
> In other words, in general, is there any guarantee that something built
> using gcc N.X.0 can be run with the runtime of gcc N.Y.0 for X > Y ?
No. There h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109654
--- Comment #2 from Richard Smith ---
Hm, that doesn't explain why the second example I gave is accepted. But I
suppose what's happening there is probably just that the `packed` attribute is
ignored entirely for fields with alignment 1, so this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
--- Comment #10 from anlauf at gcc dot gnu.org ---
Created attachment 54954
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54954&action=edit
Patch (2nd try)
This one works and regtests ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #29 from Romain Geissler ---
Typo: If yes, given that you also maintain the gcc package in fedora 38
(https://src.fedoraproject.org/rpms/gcc/commits/f38), does it mean that
something built in some future up to date Fedora 38 won't ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109652
--- Comment #7 from Sergei Trofimovich ---
(In reply to Richard Biener from comment #6)
> Should be fixed now.
I confirm it fixed valgrind-3.20.0 build as well. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #4 from Christoph Reiter ---
Everything seems to be dynamically linked to libgcc, I'm out of ideas.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109651
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #4 from Jeffrey A. Law ---
If we need to handle subregs here, I would suggest something like this
if (SUBREG_P (XEXP (op0, 0))
&& subreg_lowpart_p (op0)
... other tests ...
That way we know we're extracting the low word of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671
--- Comment #2 from Patrick J. LoPresti ---
Um... OK...
So I have to "correct" my code like so:
const Foo &bug(bool x)
{
const std::string s = (x ? "x" : "y");
const Foo &f = get_foo_by_name(s);
return f;
}
But if get_foo_by_name() has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109672
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|[143 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #3 from Christoph Reiter ---
This looks very much like bug 108202 though, so I'll see if I can find
something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #2 from Christoph Reiter ---
(In reply to Christoph Reiter from comment #1)
> [...] I'll try building without that.
That didn't make a difference sadly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109672
Bug ID: 109672
Summary: [143 regression] many ICEs after
r14-323-g977a43f5ba778b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671
--- Comment #1 from Andrew Pinski ---
There is no way for GCC to know that get_foo_by_name does not store the
argument into what is returned so it warns about this case ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671
Bug ID: 109671
Summary: Spurious dangling reference warning in GCC 13
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105525
--- Comment #3 from Mikael Pettersson ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617071.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #1 from Christoph Reiter ---
Could this be another case of exceptions being broken, as indicated here
https://github.com/AdaCore/gnat-llvm/issues/25#issuecomment-1057198363 ?
I see some "-static-libgcc" in the ada Makefile.in. I'll t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105525
--- Comment #2 from Mikael Pettersson ---
The issue issue remains in gcc-13.1.0 but is no longer limited to gcov, i.e. a
vax build with --disable-gcov using gcc-13.1.0 now fails with
In file included from
/mnt/scratch/cross/sources/gcc-13.1.0/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
Bug ID: 109670
Summary: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES
compilation error on 32bit Windows starting with GCC
13
Product: gcc
Version: 13.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247
--- Comment #12 from Marek Polacek ---
I suppose we should add a porting_to.html note about this (in light of Bug
109663).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650
Georg-Johann Lay changed:
What|Removed |Added
Component|target |other
--- Comment #4 from Georg-Joha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #9 from Jonathan Wakely ---
Oh sorry, it showed as FIXED here but I must have changed it myself by
accident.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #8 from Carlos Galvez ---
> Please don't close bugs as FIXED
I did choose INVALID, was that not correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247
Andrew Pinski changed:
What|Removed |Added
CC||carlosgalvezp at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #7 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
Jonathan Wakely changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68894
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #5 from Jonathan Wakely ---
(In reply to Carlos Galvez from comment #0)
> getting a handful of errors in this type of code compiling in C++14 mode:
But the Eigen example has been rejected since r13-6765
c++: explicit ctor and list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100958
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636
--- Comment #7 from ktkachov at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> Ugh. I guess we've got no option but to force the original
> subreg into a fresh register, but that's going to pessimise
> cases where arith
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100958
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:1dd154f6407658d46faa4d21bfec04fc2551506a
commit r14-338-g1dd154f6407658d46faa4d21bfec04fc2551506a
Author: Andrew Pinski
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
Marek Polacek changed:
What|Removed |Added
CC||carlosgalvezp at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109669
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
--- Comment #6 from Carlos Galvez ---
Sounds great, thanks for the quick response! I believe "-Wall -Wextra" is the
"bare minimum" set of warnings for most projects so I'm afraid people might
still need to disable it via "-Wno*".
Adding some [[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109669
Bug ID: 109669
Summary: Internal Compiler Error when zero-initializing
std::array
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
Carlos Galvez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #18 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:650c36ec461a722d9c65e82512b4c3aeec2ffee1
commit r14-335-g650c36ec461a722d9c65e82512b4c3aeec2ffee1
Author: Roger Sayle
Date: Fri A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380
--- Comment #10 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:7bd8a81f39e084d43c6701afb6203510b5fe69a2
commit r13-7264-g7bd8a81f39e084d43c6701afb6203510b5fe69a2
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109646
Thomas Schwinge changed:
What|Removed |Added
Ever confirmed|0 |1
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108040
--- Comment #2 from Alvin Wong ---
Thanks for trying to look into the issue. The error you got looks like an
effect of
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=87235f1e5c740de9c6f72a5dd7d7eb9cb7df2e1d
that is not in GCC 12. I guess I can re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109668
Bug ID: 109668
Summary: 'python' vs. 'python3'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791
--- Comment #14 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:e2babb0540cfa66752214f3f111461e1da4b26ce
commit r10-11325-ge2babb0540cfa66752214f3f111461e1da4b26ce
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109667
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #3 from Jonathan Wakely ---
(In reply to Carlos Galvez from comment #2)
> I could reduce it to a simpler self-contained example:
That example has been rejected since r9-283-gd86d6e27db4520
CWG 2267 - list-initialization of refe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109665
--- Comment #3 from Paul Groke ---
Created attachment 54952
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54952&action=edit
Minimal repro
Added minimal repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #4 from Jonathan Wakely ---
Could the testsuite be finding an older libstdc++.so somewhere in the
LD_LIBRARY_PATH?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #3 from seurer at gcc dot gnu.org ---
It failed on just the one power 8 system where it fails every time.
configure --enable-languages=c,fortran,c++ --enable-secureplt --with-cpu=power8
--disable-bootstrap --disable-multilib
I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109665
--- Comment #2 from Paul Groke ---
-fno-schedule-insns and/or -fno-schedule-insns2 don't change the instruction
sequence for calling __cxa_begin_catch.
BTW: for compiler versions present there, it's super easy to check this with
godbolt.org. Ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #2 from Carlos Galvez ---
I could reduce it to a simpler self-contained example:
struct Foo;
Foo const& foo_maker();
struct Bar
{
explicit Bar(Foo const&);
};
void baz()
{
Bar const& b{foo_maker()};
}
Godbolt: https://go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109667
Bug ID: 109667
Summary: [12/13/14 Regression] Unnecessary temporary storage
used for 32-byte struct
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109665
Richard Biener changed:
What|Removed |Added
Target||s390x
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
Bug ID: 109666
Summary: Segmentation fault with std::array using gcc 13
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109652
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109652
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a94dcac59ee4c99b523ae593cb1c0ad43d4a110b
commit r14-326-ga94dcac59ee4c99b523ae593cb1c0ad43d4a110b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109622
--- Comment #10 from CVS Commits ---
The master branch has been updated by Julian Brown :
https://gcc.gnu.org/g:cacf65d74463600815773255e8b82b4043432bd7
commit r14-325-gcacf65d74463600815773255e8b82b4043432bd7
Author: Julian Brown
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108040
--- Comment #1 from Martin Jambor ---
It is probably me not being able to build the necessary cross compiler
properly, but I cannot build the provided testcase, I always get errors like
the following and then some more:
: note: initializing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109622
--- Comment #9 from Tobias Burnus ---
Julian submitted a patch for this (approved but not yet committed):
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html
Patrick: Can you check whether it also fixes your program?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109664
--- Comment #1 from Tobias Burnus ---
Once done, we might want to change some error propagation from a chain of
boolean-returning functions to just GOMP_PLUGIN_fatal – or not.
Cf. for instance:
https://gcc.gnu.org/pipermail/gcc-patches/2023-Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109665
Bug ID: 109665
Summary: Incorrect code generation for s390/s390x try-catch
(__cxa_begin_catch), causing SIGSEGV
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109664
Bug ID: 109664
Summary: Deadlocks with gomp_fatal called from libgomp/plugins/
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #1 from Carlos Galvez ---
I forgot to write the actual error I'm getting:
: In function 'int main()':
:11:41: error: converting to 'const MyVector' {aka 'const
Eigen::Matrix'} from initializer list would use explicit
constructor 'Ei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
Bug ID: 109663
Summary: False positive? Converting from initializer list would
use explicit constructor
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109644
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109644
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:6e6f86f22873aab7059e083fd0c9905bd58e5efa
commit r14-324-g6e6f86f22873aab7059e083fd0c9905bd58e5efa
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108752
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 113 matches
Mail list logo
