https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93860
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
Target M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
Richard Biener changed:
What|Removed |Added
Keywords||lto
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93641
--- Comment #7 from Iain Sandoe ---
if the invoke.texi entry does not need a change, then this should now be fixed,
correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #17 from rguenther at suse dot de ---
On Fri, 21 Feb 2020, bugdal at aerifal dot cx wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
>
> --- Comment #10 from Rich Felker ---
> I don't think it's at all clear that -fno-si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #18 from rguenther at suse dot de ---
On Fri, 21 Feb 2020, bugdal at aerifal dot cx wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
>
> --- Comment #12 from Rich Felker ---
> To me the meaning of internal consistency is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #19 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 #15 from Vincent Lefèvre ---
> Note that there are very few ways t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833
Martin Liška changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #3 from M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
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)
> {
> flo
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:
f
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
Priorit
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 from
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 sequenc
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 #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
> c
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=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 c
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=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
--- 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 #4 from Martin Liška ---
Both comments are valid to me!
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
Compon
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=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=93869
Bug ID: 93869
Summary: ICE in contains_struct_check with -Wmismatched-tags
upon redundant typename
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: norm
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 the
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=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=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 ca
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&action=edit
New test case
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 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
John Paul Adrian Glaubitz changed:
What|Removed |Added
CC||glaubitz at physik dot
fu-be
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=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: Fr
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: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
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
--- 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=93869
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
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=93848
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
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=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=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=92955
--- Comment #6 from Matheus Castanho ---
Hi. Any updates on this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92492
Tamar Christina changed:
What|Removed |Added
Target|i386, x86-64, aarch64 |i386, x86-64
Status|ASSIGN
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=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 Fe
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=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
discussi
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
Severity:
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=93301
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93835
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||markeggleston at gcc do
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 su
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=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=93871
--- Comment #1 from Thomas Henlich ---
Created attachment 47883
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47883&action=edit
Proposed patch for COTAN speedup
This is basically the same method mpc uses internally to compute mpc_tan (onl
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 co
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=93869
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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
Severi
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=93753
Martin Sebor changed:
What|Removed |Added
Known to work||10.0
Summary|[8/9/10 Regressio
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=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 not
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=93871
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
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 e
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
Pro
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=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 com
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 #5 from Thomas Henlich ---
Created attachment 47884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47884&action=edit
Test case
Output:
th@THe-Surface:~$ /opt/gcc/bin/gfortran -L/opt/gcc/lib64 -Wl,-rpath
-Wl,/opt/gcc/lib64 -fdec
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 evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|c
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=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
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 1
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 1
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=93874
Bug ID: 93874
Summary: ICE due to command line options
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
A
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
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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 definitel
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=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=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=93871
Fritz Reese changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCON
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
--- 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=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: Fr
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=39612
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
> ===
1 - 100 of 108 matches
Mail list logo
