https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
--- Comment #9 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #8)
> It's the same error message, but the actual cause is different. Please open
> a new PR for this and attach the pre-processed source file that fails to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
--- Comment #8 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #6)
> I'm seeing this exact problem SH as well when trying to build webkit2gtk:
>
> internal compiler error: in extract_constrain_insn, at recog.c:2211
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #195 from Peter Bisroev ---
Hi Dave,
I was doing a bit more searching and found this doc from HP, "Solaris to HP-UX
Porting Guide"
(http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.475.5577=rep1=pdf).
I know it is not from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #194 from Peter Bisroev ---
(In reply to dave.anglin from comment #193)
> I presume that if you compile main.cc with g++, hello() becomes weak. You
> could test with a second instance of hello.
Yes, sorry forgot to mention that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #13 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:58:59PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #11 from Steve Kargl ---
> On Fri, Feb 21, 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #193 from dave.anglin at bell dot net ---
On 2020-02-21 7:36 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #192 from Peter Bisroev ---
> (In reply to dave.anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|10.0|11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #192 from Peter Bisroev ---
(In reply to dave.anglin from comment #191)
> On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
> The problem seems to be that HP ld doesn't handle the PCREL21B relocation
> correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #12 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:40:22PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> Ugh, this diff fixes constant-folding (without your mpc_sincos) patch.
>
> Index: gcc/fortran/simplify.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
Jeffrey A. Law changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93875
Bug ID: 93875
Summary: confusing type in an error about an invalid call to a
specialization on data member pointer
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93759
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8d1780b56d0cb1d50115d4e925e81cd8b9cb2923
commit r10-6794-g8d1780b56d0cb1d50115d4e925e81cd8b9cb2923
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #11 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:44:25PM +, foreese at gcc dot gnu.org wrote:
>
> --- Comment #10 from Fritz Reese ---
> Thomas, thank you for discovering this. Steve, thanks for your investigative
> work and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
--- Comment #7 from Andrew Pinski ---
(In reply to John Paul Adrian Glaubitz from comment #6)
> I'm seeing this exact problem SH as well when trying to build webkit2gtk:
Please report this speerately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Fritz Reese changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #9 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:33:04PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #8 from Steve Kargl ---
> On Fri, Feb 21, 2020 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
--- Comment #5 from Stephan Bergmann ---
(In reply to Stephan Bergmann from comment #4)
> So users will have to be careful when they fix a -Wredundant-tags warning in
> an included file. They may have to introduce a forward declaration into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #8 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:19:01PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> program foo
> complex, parameter :: z = cotan((1.,1.))
> print *, z
> end program foo
>
Something is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93874
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
--- Comment #4 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #3)
> Ah, I see. I'm not sure there's anything I can do about the first case --
> the warning there is by design.
So users will have to be careful when they fix a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93874
Bug ID: 93874
Summary: ICE due to command line options
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:25f0909af87171395d9ee21cf2873f4d9b5ebc91
commit r10-6792-g25f0909af87171395d9ee21cf2873f4d9b5ebc91
Author: Jeff Law
Date: Fri Feb 21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:47772af10c00f7e1e95cd52557fc893dc602a420
commit r10-6791-g47772af10c00f7e1e95cd52557fc893dc602a420
Author: Feng Xue
Date: Mon Feb 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93860
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #7 from Steve Kargl ---
On Fri, Feb 21, 2020 at 07:45:39PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #6 from Thomas Henlich ---
> (In reply to kargl from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93860
--- Comment #3 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:147add96091790d5c1d8eb938f84ea775ad81b84
commit r10-6790-g147add96091790d5c1d8eb938f84ea775ad81b84
Author: Iain Sandoe
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #6 from Thomas Henlich ---
(In reply to kargl from comment #2)
> Can you post the code you used for testing? Your patch to simplify.c
> affects compile-time constant folding. simplify.c has nothing to do
> with a run-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #5 from Thomas Henlich ---
Created attachment 47884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47884=edit
Test case
Output:
th@THe-Surface:~$ /opt/gcc/bin/gfortran -L/opt/gcc/lib64 -Wl,-rpath
-Wl,/opt/gcc/lib64 -fdec-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623
--- Comment #14 from Jakub Jelinek ---
Then please attach the preprocessed source that still ICEs, together with
gcc/g++ command line that reproduces it. It doesn't have to be reduced, we can
do that ourselves.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #4 from Steve Kargl ---
On Fri, Feb 21, 2020 at 06:53:18PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to kargl from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873
--- Comment #1 from Emil Fihlman ---
Oh yeah and platform was Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2
(2018-10-27) x86_64 GNU/Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873
Bug ID: 93873
Summary: gcc or lto-wrapper does not consider individual
bitfield values on static analysis and instead tests
the whole value of all bitfield bits combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Can you post the code you used for testing? Your patch to simplify.c
> affects compile-time constant folding. simplify.c has nothing to do
> with a run-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
Martin Sebor changed:
What|Removed |Added
Status|WAITING |NEW
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
--- Comment #2 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #1)
> The tag is redundant in both cases and can be removed without causing an
> ambiguity. Why do you think the warnings are wrong?
In the test2.cc case, S has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93753
Martin Sebor changed:
What|Removed |Added
Known to work||10.0
Summary|[8/9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93753
--- Comment #5 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:dbfba41e95d1d93b17e907b7f516b52ed3a3c415
commit r10-6789-gdbfba41e95d1d93b17e907b7f516b52ed3a3c415
Author: Martin Sebor
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93872
Bug ID: 93872
Summary: std::move(first, last, out) doesn't work in -std=c++2a
when value type is move-only
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869
--- Comment #3 from Martin Sebor ---
Go ahead, Marek. I'll deal with the conflict if there is one. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #10 from joseph at codesourcery dot com ---
On Fri, 21 Feb 2020, vincent-gcc at vinc17 dot net wrote:
> Concerning the STDC FP_CONTRACT pragma, implementing it would not be
> sufficient. GCC would also need to restrict how it does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #1 from Thomas Henlich ---
Created attachment 47883
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47883=edit
Proposed patch for COTAN speedup
This is basically the same method mpc uses internally to compute mpc_tan (only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Bug ID: 93871
Summary: COTAN is slow for complex types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Martin Sebor changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93032
--- Comment #2 from David Malcolm ---
I'm not convinced that the above patch is correct. What if one or two of the
fopen calls fail? Then the else branch of the "if" will be followed, and no
fclose will be called on the fp for the calls that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93835
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||markeggleston at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264
Roman Zhuykov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93870
Bug ID: 93870
Summary: User-defined conversion function not working in
evaluation of template argument
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040
--- Comment #3 from Roman Zhuykov ---
(In reply to Roman Zhuykov from comment #2)
> Same ICE also appears when compiling gcc.c-torture/execute/pr71550.c with
So, I've opened separate PR93264 for that example, and now we have some related
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93825
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93586
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:91e50b2aa2dece9e22ae793d2a1a14b33bf3859d
commit r10-6781-g91e50b2aa2dece9e22ae793d2a1a14b33bf3859d
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #4 from Vincent Lefèvre ---
Perhaps this was not the intent of the standard (and this is far from being
clear because this might affect optimizations -- there are already many things
that are forbidden with pointers though they could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92492
Tamar Christina changed:
What|Removed |Added
Target|i386, x86-64, aarch64 |i386, x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955
--- Comment #6 from Matheus Castanho ---
Hi. Any updates on this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295
--- Comment #5 from Marek Polacek ---
Another test from Bug 93867:
template
struct basic_fixed_string
{
constexpr basic_fixed_string(const CharT *p) {
for (int i = 0; i < N; ++i) {
m_data[i] = p[i];
}
}
CharT m_data[N] {};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93867
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295
Marek Polacek changed:
What|Removed |Added
CC||pkeir at outlook dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93776
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623
--- Comment #6 from calixte ---
(In reply to Alexander Monakov from comment #5)
> (In reply to calixte from comment #2)
> > I think the reset is useless in the case of exec** functions since the
> > counters are lost when an exec** is called. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93845
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:4d6bf96b583d77336cf6ca643d92d068a88414fa
commit r10-6779-g4d6bf96b583d77336cf6ca643d92d068a88414fa
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93845
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:4d6bf96b583d77336cf6ca643d92d068a88414fa
commit r10-6779-g4d6bf96b583d77336cf6ca643d92d068a88414fa
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #24 from Alexander Cherepanov ---
(In reply to Vincent Lefèvre from comment #11)
> But what does "internal consistency" mean?
That's a good question. Here we talk about cases (like
-funsafe-math-optimizations) that are not covered by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
John Paul Adrian Glaubitz changed:
What|Removed |Added
CC||glaubitz at physik dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #2 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #1)
> Hmm, but as you say there isn't an actual access and taking the address of
> one-after the array is allowed. With p[2] it appropriately warns.
No, what I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #3 from José Rui Faustino de Sousa ---
Created attachment 47882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47882=edit
New test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #2 from José Rui Faustino de Sousa ---
Looked a bit further into this and found additional problems both under:
gfortran version 10.0.1 20200219 (experimental) (GCC)
and
gfortran version 9.2.1 20200219 (GCC)
With the new test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868
--- Comment #3 from Richard Biener ---
What's more we cannot modify the SLP nodes stmt order since they are cached in
the SLP node cache. So a "simple" fix might be to COW the whole SLP sub-tree
we re-arrange...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93863
Charalampos Stratakis changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93863
--- Comment #2 from Charalampos Stratakis ---
That would be latest version of gcc 10 in Fedora rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1462579
I see the issue was fixed some days ago. I will close the bugzilla for now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869
Bug ID: 93869
Summary: ICE in contains_struct_check with -Wmismatched-tags
upon redundant typename
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #23 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #22)
> Note that if one adds "if (s == u)" (which is true, and noticed by GCC)
Sorry, this is not noticed by GCC (I used an incorrect command line).
Anyway, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868
Bug ID: 93868
Summary: [10 Regression] wrong-code with permuted SLP reduction
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623
--- Comment #4 from Martin Liška ---
Both comments are valid to me!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623
--- Comment #3 from calixte ---
And about fork, no need to lock when resetting in the child process since we've
only one thread.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623
--- Comment #2 from calixte ---
I think the reset is useless in the case of exec** functions since the counters
are lost when an exec** is called. So it can probably be removed too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623
Martin Liška changed:
What|Removed |Added
Version|unknown |10.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #22 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #21)
> Note that GCC does FP contraction across stmt boundaries so
> even s = a * b; t = s + c; is contracted. If that is already
> a bug in your eyes then of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93863
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #9 from Richard Biener ---
Note fixin(In reply to Vincent Lefèvre from comment #8)
> Concerning the STDC FP_CONTRACT pragma, implementing it would not be
> sufficient. GCC would also need to restrict how it does contraction, as it
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93867
Bug ID: 93867
Summary: ICE using class type NTTPs and class template argument
deduction
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #8 from Vincent Lefèvre ---
Concerning the STDC FP_CONTRACT pragma, implementing it would not be
sufficient. GCC would also need to restrict how it does contraction, as it
currently does not contract only expressions, but also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #21 from rguenther at suse dot de ---
On Fri, 21 Feb 2020, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
>
> --- Comment #20 from Vincent Lefèvre ---
> (In reply to rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93866
Bug ID: 93866
Summary: [debug] Methods with pointer receiver incorrectly
named
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709
--- Comment #5 from Jiu Fu Guo ---
There are below difference between data/instructions for P8 and P9:
(maxlocval_4.f90)
f29=-inf
f30=-inf
f31=nan
P9:
xsmaxcdp vs31,vs29,vs31 ==> vs31/f31:nan (smax(-inf, nan)-->nan)
b 0x10004b60
P8:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #20 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #18)
> GCC indeed happily evaluates a floating-point expression multiple times,
> for example for
>
> void foo(float a, float b, float *x, float *y)
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
1 - 100 of 108 matches
Mail list logo
