https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88438
--- Comment #2 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #1)
> At https://gcc.gnu.org/wiki/Fortran2008Status I see
>
> Unimplemented features -- based on the list in the "Introduction" of the
> F2008 standard
> ...
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
--- Comment #21 from Iain Sandoe ---
(In reply to Eric Gallager from comment #20)
> (In reply to Dominique d'Humieres from comment #18)
> > For the record with darwin15 I had to add
> >
> > /System/Library/Frameworks/Foundation.framework/Version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89150
--- Comment #7 from Richard Biener ---
Author: rguenth
Date: Tue Feb 5 08:32:16 2019
New Revision: 268530
URL: https://gcc.gnu.org/viewcvs?rev=268530&root=gcc&view=rev
Log:
2019-02-05 Richard Biener
PR middle-end/89150
* bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89082
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89150
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88930
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88914
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85206
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86404
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89200
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89090
--- Comment #4 from Csaba Ráduly ---
svn blame vector.tcc claims that the inner, apparently redundant "#if
__cplusplus >= 201103L" appeared at this change:
r265485 | glisse | 2018-10-25 15:03:13 +0200 (Thu, 25 Oct 2018) | 24 lines
Relocation (=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89032
Martin Liška changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89186
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Feb 5 09:17:18 2019
New Revision: 268531
URL: https://gcc.gnu.org/viewcvs?rev=268531&root=gcc&view=rev
Log:
PR target/89186
* optabs.c (prepare_cmp_insn): Pass x and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89203
Bug ID: 89203
Summary: Linux S/390: Unable to build GCC 8.2.0 on Red Hat
Enterprise Linux Server release 6.9
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #18 from Marc Glisse ---
Author: glisse
Date: Tue Feb 5 09:33:36 2019
New Revision: 268532
URL: https://gcc.gnu.org/viewcvs?rev=268532&root=gcc&view=rev
Log:
Rename __is_trivially_relocatable to __is_bitwise_relocatable.
2019-02-05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100
MarkEggleston changed:
What|Removed |Added
Attachment #45549|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45591
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89186
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89103
MarkEggleston changed:
What|Removed |Added
Attachment #4|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #4 from Wilco ---
(In reply to Segher Boessenkool from comment #3)
> (In reply to Wilco from comment #1)
> > len is unsigned HOST_WIDE_INT, so bits_to_bytes_round_down does an unsigned
> > division...
>
> That shouldn't make a differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
Bug ID: 89204
Summary: -floop-interchange has no effect on Fortran code
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936
--- Comment #11 from Richard Biener ---
Created attachment 45605
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45605&action=edit
prototype conservative fix
So this is a very conservative fix computing what automatic variables "escape"
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89194
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89197
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2019-02-05 00:00:00 |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
Bug ID: 89205
Summary: [8/9 Regression] Debug info size growth since r248469
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #29 from Xi Ruoyao ---
I'm sure -flto-parition=none is needed for workaround, now.
It keeps .symver directive and the function definition in the same assembly
file.
Unfortunately for large codebase -flto-partition leads to OOM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #6 from Segher Boessenkool ---
pos should be always non-negative. pos is the offset (in bits, counted from
the right) in the *field*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #7 from Jakub Jelinek ---
While I can see how doing - (HOST_WIDE_INT) len instead of - len fixes the ICE,
I wonder if what make_extraction does isn't invalid.
In particular, we have later on:
/* Unless INNER is not MEM, reject this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #8 from Jakub Jelinek ---
Created attachment 45606
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45606&action=edit
gcc9-pr89195.patch
Now in patch form (untested so far).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164
--- Comment #2 from Jonathan Wakely ---
N.B. the report is missing that it is only accepted for c++17 and c++2a modes.
For c++14 it's rejected as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89194
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
--- Comment #2 from Martin Liška ---
(In reply to Richard Biener from comment #1)
> It means debuginfo wasn't present at all before this rev. (on the reduced
> testcase). Somehow the iteration wasn't translated 1:1?
Yes, but for ./benchspec/CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
--- Comment #3 from Jakub Jelinek ---
Why is that a regression? It is desirable to emit debug info here...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> Why is that a regression? It is desirable to emit debug info here...
I guess the question is more of whether we understand the difference in
behavior
since the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
--- Comment #5 from Martin Liška ---
(In reply to Richard Biener from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Why is that a regression? It is desirable to emit debug info here...
>
> I guess the question is more of whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89000
--- Comment #4 from Martin Liška ---
Author: marxin
Date: Tue Feb 5 12:17:45 2019
New Revision: 268533
URL: https://gcc.gnu.org/viewcvs?rev=268533&root=gcc&view=rev
Log:
GCOV: remove misleading branches and calls info for -f option (PR
gcov-pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89000
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #9 from Segher Boessenkool ---
That patch is pre-approved if it regchecks fine (on more than just x86).
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #10 from Wilco ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 45606 [details]
> gcc9-pr89195.patch
>
> Now in patch form (untested so far).
That works fine indeed. It avoids accessing the object out of bounds b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Johannes Pfau ---
> Regarding the _d_dso_registry issue: Yes, as far as I can see it is a bug that
> handleForName dlcloses the handle here. I think what happened i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89187
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89182
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89116
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
--- Comment #7 from Jakub Jelinek ---
E.g. just comment out the template lines in the testcase and
suddenly even GCC 7 emits debug info.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
--- Comment #8 from Jakub Jelinek ---
Or even just reorder:
namespace a {
template void isgreater();
void isgreater();
void isgreater(double);
template void isgreaterequal();
bool isgreaterequal();
}
using a::isgreater;
using a::isgreaterequal;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88917
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88820
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #15 from Richard Biener ---
Can we (did we already?) fix the diagnostic with respect to the range printing
as said in comment#5? I'd defer the rest. Maybe we can even have
jump-threading cancel paths that would introduce these kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89206
Bug ID: 89206
Summary: Map
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702
--- Comment #8 from Martin Liška ---
Honza can you please create mozilla upstream bug where we can recommend to use
switch instead of series of if conditions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164
--- Comment #3 from Jonathan Wakely ---
This version compiles even in C++11 though:
#include
struct X {
X() = default;
X(const X&) = delete;
};
int main()
{
X x[1];
std::vector v{x, x+1};
}
The original version was only rejected prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88606
Richard Biener changed:
What|Removed |Added
Assignee|hubicka at gcc dot gnu.org |rguenth at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207
Bug ID: 89207
Summary: Symbols missing in map file with LTO
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
Bug ID: 89208
Summary: unaligned access expanded to memcpy
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #17 from Alexander Monakov ---
Well, the asm with the xor was just to make the testcase more-obviously-broken,
it's still broken when %eax is clobbered in a more subtle way, like via a
libcall for integer division like in earlier exam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89194
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164
--- Comment #4 from Jonathan Wakely ---
A similar fix is needed for uninitialized_fill and uninitialized_fill_n
otherwise this still compiles:
std::vector v3{2, X{}};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88917
--- Comment #4 from Jakub Jelinek ---
(In reply to Florian Weimer from comment #3)
> Isn't -fasynchronous-unwind-tables part of the GNU/Linux ABI and enabled by
> default? Without it, asynchronous cancellation does not work.
Yes, but nobody is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88917
--- Comment #5 from Jakub Jelinek ---
Other option is to spend a lot of energy on this. output_indirect_thunk would
need to be told if it is emitted inside of normal functions or in the magic
functions where it currently does the right thing alr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88917
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
Richard Biener changed:
What|Removed |Added
Target||arm
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207
Richard Biener changed:
What|Removed |Added
CC||hjl at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
--- Comment #3 from Bernd Edlinger ---
The problem is that this pattern may be used in the implementation of memcpy.
But it reminds me much to what you did with
-ftree-loop-distribute-patterns last year,
and how it is enabled with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
--- Comment #4 from Richard Biener ---
PR56888?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
--- Comment #5 from Bernd Edlinger ---
(In reply to Richard Biener from comment #4)
> PR56888?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
--- Comment #6 from Richard Biener ---
(In reply to Bernd Edlinger from comment #5)
> (In reply to Richard Biener from comment #4)
> > PR56888?
>
> Yes.
So is this a dup or are you after sth else?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
--- Comment #7 from Bernd Edlinger ---
both.
but if you use -fno-tree-loop-distribute-pattern I'd bet people
would not want memcpy when not having asked for...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #11 from Wilco ---
(In reply to Segher Boessenkool from comment #9)
> That patch is pre-approved if it regchecks fine (on more than just x86).
> Thanks!
check-gcc is clean on aarch64_be-none-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89090
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Tue Feb 5 14:44:56 2019
New Revision: 268536
URL: https://gcc.gnu.org/viewcvs?rev=268536&root=gcc&view=rev
Log:
PR libstdc++/89090 avoid C++17 features in C++11/C++14 code
Although GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Tue Feb 5 14:45:00 2019
New Revision: 268537
URL: https://gcc.gnu.org/viewcvs?rev=268537&root=gcc&view=rev
Log:
PR libstdc++/89130 restore support for non-MoveConstructible types
The c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89090
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88606
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88606
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Tue Feb 5 14:57:32 2019
New Revision: 268540
URL: https://gcc.gnu.org/viewcvs?rev=268540&root=gcc&view=rev
Log:
2019-02-05 Richard Biener
PR c/88606
* c-decl.c (fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
--- Comment #6 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #5)
> Looking at the standard, the requirements for the push_back call in comment
> 0 are that X is Cpp17CopyInsertable into vector, which is true. The check
> whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
--- Comment #7 from Jonathan Wakely ---
Oh, so it does.
So I guess I could revert r268537 then. The downstream package where this
caused a build failure was already changed to stop (foolishly) deleting move
ctors, so it's not causing any more pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
--- Comment #8 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #7)
> So I guess I could revert r268537 then.
I don't think it was worth spending time on in the first place, but now that
you have written it, it isn't as bad as I fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #16 from Andreas Krebbel ---
I'll commit a patch which just removes the splitter for now. I'll try to come
up with a nicer testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
--- Comment #9 from Bernd Edlinger ---
I would like to suppress the optimization when -ffreestanding,
or fno-builtin, is used, but I agree that it will probably
stretch -fno-loop-distribute-patterns a bit too much to cover this.
OTOH -fno-loop-d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
--- Comment #9 from Jonathan Wakely ---
With the removal of if constexpr we would unconditionally instantiate
__relocate_a, which could fail ... but only in cases like a deleted move
constructor. This avoids that instantiation, so it doesn't fail
1 - 100 of 225 matches
Mail list logo
