https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81116
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Wed Aug 16 17:21:22 2017
New Revision: 251125
URL: https://gcc.gnu.org/viewcvs?rev=251125&root=gcc&view=rev
Log:
2017-08-16 Thomas Koenig
PR fortran/81116
* frontend
On Wed, 16 Aug 2017, Eric Gallager wrote:
> I see Richi redid all his 7.2 release changes; does that imply that
> the server restore is now complete?
No, there's still a search process ongoing to identify corrupted or
missing files by comparison with the last backup.
My expectation is that all
On Wed, 16 Aug 2017, NightStrike wrote:
> On Mon, Aug 14, 2017 at 11:10 PM, Martin Sebor wrote:
> > On 08/14/2017 04:22 PM, Eric Gallager wrote:
> >>
> >> I'm emailing this manually to the list because Bugzilla is down and I
> >> can't file a bug on Bugzilla about Bugzilla being down. The error
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861
--- Comment #6 from Maxim Ostapenko ---
Created attachment 41990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41990&action=edit
Untested fix
The problem is that LTO doesn't propagate changed
ix86_stack_protector_guard_reg value:
6654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81116
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81651
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81869
Bug ID: 81869
Summary: [8 Regression] --enable-checking=yes,rtl failed to
bootstrap on 32-bit hosts
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78666
--- Comment #7 from Martin Sebor ---
The following nonsensical declaration is also not diagnosed:
void __attribute__ ((alloc_align (1))) f (void*);
The attribute handler should check that the referenced argument has integer
type and that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81870
Bug ID: 81870
Summary: -fsanitize=undefined doesn't pay attention to
__builtin_assume_aligned()
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81869
--- Comment #1 from H.J. Lu ---
On 64-bit host, I got
Number of expanded macros: 25177
Average number of tokens per macro expansion: 34
Line Table allocations during the compilation process
Number of ordinary maps used:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81871
Bug ID: 81871
Summary: bogus attribute alloc_align accepted
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78666
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81870
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861
Uroš Bizjak changed:
What|Removed |Added
Component|lto |target
--- Comment #7 from Uroš Bizjak --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81488
--- Comment #4 from Bill Schmidt ---
With a cross it doesn't reproduce for current trunk (r251128) either, but does
reproduce with r250217 as originally reported. So I can look at that. Going
to check what made the problem go away also...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81870
--- Comment #2 from Petr ---
I see, so if I understand it correctly then:
1. `__builtin_assume_aligned()` should be used to promote the type to a higher
than natural alignment, for example 16 bytes for easier auto-vectorization.
2. `__attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81869
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81869
--- Comment #3 from H.J. Lu ---
(In reply to H.J. Lu from comment #2)
> On 64-bit hosts, I got
>
> (gdb) p cfun->cfg->x_last_basic_block
> $1 = 432
> (gdb) call debug_tree (cfun->decl)
Please ignore this. I didn't use --enable-checking=yes,rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81872
Bug ID: 81872
Summary: Enable __float128 by default on PowerPC Linux systems
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81872
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81869
--- Comment #4 from H.J. Lu ---
It doesn't happen with the preprocessed source.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
Arnd Bergmann changed:
What|Removed |Added
Known to work|6.3.1 |
--- Comment #1 from Arnd Bergmann ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81488
--- Comment #5 from Bill Schmidt ---
Just for the record, the problem disappears with r250523, in which a change to
reassociation of multiplication in match.pd causes the SLSR opportunities to
disappear. So the SLSR problem has just gone latent,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81873
Bug ID: 81873
Summary: spurious -Wreturn-type calling a locally declared
noreturn function
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81873
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
--- Comment #24 from Randy MacLeod ---
This ICE still happens with gcc-7.2.
Here's the stacktrace:
(gdb) bt
#0 store_expr_with_bounds (exp=exp@entry=0x76275900,
target=target@entry=0x7625d660, call_param_p=call_param_p@entry=0,
nontemp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938
--- Comment #6 from Alan Modra ---
Author: amodra
Date: Thu Aug 17 02:03:03 2017
New Revision: 251140
URL: https://gcc.gnu.org/viewcvs?rev=251140&root=gcc&view=rev
Log:
[RS6000] PR 80938, Don't emit frame info for regs that don't need saving
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81855
--- Comment #2 from Xingcan Lan ---
Checked diassembly code and found that __declspec(dllexport) never applied to
explicitly instantiated `Template`.
If I change the code from
`extern template struct __declspec(dllexport) Template;` to
`extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81709
--- Comment #2 from Anatol ---
Theoretically it is possible to do things like this manually. Track functions
x86 extensions usage and save registers accordingly. But I would love to see a
more automated and less error-prone way to do it. Similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81873
--- Comment #2 from Andrew Pinski ---
This is not so much an -Wreturn-type issue but a symptom of the C++ front-end
not merging decls for globals. You filed a few other cases which are accepts
invalid which are the same here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81709
--- Comment #3 from H.J. Lu ---
(In reply to Anatol from comment #2)
> Theoretically it is possible to do things like this manually. Track
> functions x86 extensions usage and save registers accordingly. But I would
> love to see a more automate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81834
--- Comment #2 from Geoffrey Allott ---
Hi Richard, I agree that this seems quite 'arcane' at first glance; I should
explain that I found it when an empty for loop failed to optimize out in rust -
the reduced test case failed to optimize in clang
201 - 232 of 232 matches
Mail list logo
