https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84248
H.J. Lu changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84224
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84259
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84227
Richard Biener changed:
What|Removed |Added
Version|unknown |8.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84221
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84226
Richard Biener changed:
What|Removed |Added
Version|unknown |8.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
--- Comment #2 from Jan Hubicka ---
> Huh, __builtin_va_arg_pack_len is only valid within varargs functions. The
> difference seems to be that without LTO we simply emit a library call and
> not emit aa.i:open (which is invalid) but with LTO we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84217
Tom de Vries changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84261
Bug ID: 84261
Summary: gcc fails to call a simd-vectorized function
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84233
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84234
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization, openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84235
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84240
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84241
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84245
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84234
--- Comment #2 from Florian Lemaitre ---
Well, I should mention that using __attribute((simd)) also has the issue.
So I don't think the problem lies in OpenMP front end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84251
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84262
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84234
--- Comment #3 from Jakub Jelinek ---
The forward declaration is not ignored, but you either need to use #pragma omp
simd on the loop you want to vectorize, or tell the compiler your function
doesn't have any side-effects that would prevent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84261
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84250
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84261
--- Comment #2 from Marcin Krotkiewski ---
(In reply to Richard Biener from comment #1)
> This is because reduction operations like 'exp' are not supported. Also
> vectorization of loops with using vectors isn't supported.
>
> So not sure what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311
--- Comment #13 from Richard Biener ---
Please leave the bug open - it does point at an undesirable transform which
would conflict with GCC ever treating the use of uninitialized vars as "more"
undefined as it does right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84234
--- Comment #4 from Florian Lemaitre ---
Ah... ok. I understand.
Indeed, declaring the function const works as expected.
So, I guess we can say it is not a bug, and close the bug report?
However, I really think this should be documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84252
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84262
--- Comment #2 from Serguei Kolos ---
If you read my original message through the end you should have noticed that I
have admitted that already. My question was different:
Is it normal that the same code (seemingly bogus) compiles fine with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84261
--- Comment #3 from Marcin Krotkiewski ---
(In reply to Richard Biener from comment #1)
> Also vectorization of loops with using vectors isn't supported.
Not sure what you mean. If instead of a function call I do some floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84234
--- Comment #5 from Jakub Jelinek ---
#pragma omp declare simd or simd attribute say that on the definition compiler
should create alternate entry point(s) for the vectorized variants, and on
declarations that on the definition they were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
Aldy Hernandez changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263
Bug ID: 84263
Summary: [8 Regression] ICE in lookup_page_table_entry at
gcc/ggc-page.c:646 on valid C++ code
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263
Nathan Sidwell changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84265
Bug ID: 84265
Summary: ICE in vect_permute_load_chain, at
tree-vect-data-refs.c:5933
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84059
--- Comment #3 from Martin Liška ---
Author: marxin
Date: Wed Feb 7 13:16:04 2018
New Revision: 257451
URL: https://gcc.gnu.org/viewcvs?rev=257451=gcc=rev
Log:
Revert behavior to r251316.
2018-02-07 Martin Liska
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84262
--- Comment #3 from Jonathan Wakely ---
(In reply to Serguei Kolos from comment #0)
> According to the article 9.4.2/4 of the C++ standard the code is probably
> missing definitions of the c1, c2 and c3 constants:
>
> "If a static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
--- Comment #6 from Jakub Jelinek ---
This changed with r146817, so I'd look at a problem in expansion rather than
much earlier. DECL_SIZE_UNIT should match what sizeof is, so you can't just
change it at will, it is part of the ABI. Arrays of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84265
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84262
--- Comment #4 from Jonathan Wakely ---
(In reply to Serguei Kolos from comment #2)
> If you read my original message through the end you should have noticed that
> I have admitted that already. My question was different:
>
> Is it normal that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264
Bug ID: 84264
Summary: ICE in rs6000_emit_le_vsx_store, at
config/rs6000/rs6000.c:10367
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84252
--- Comment #5 from Jakub Jelinek ---
Created attachment 43358
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43358=edit
gcc8-pr84252.patch
Full untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84234
--- Comment #6 from Florian Lemaitre ---
I want auto-vectorization, not guided vectorization.
Basically, I try to write a fast RSQRT that will not break auto vectorization,
and this will be integrated in a large scale project where it is easy to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
--- Comment #8 from Jakub Jelinek ---
Though, in e.g. *.ehcleanup2 dump we still have:
pretmp.25_64 = D.1613_19 /[ex] 16;
D.2749_73 = _61->b{off: pretmp.25_64 * 16}[0];
ivtmp.35_86 = (long unsigned int) D.2749_73;
both before and after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
--- Comment #7 from Jakub Jelinek ---
The difference with that revision is:
addq$2, %rax
cmpq%rcx, %rax
jne .L3
- leaq(%r12,%rdx), %rdx
+ andq$-16, %rdx
xorl%eax, %eax
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #38 from Christophe Lyon ---
(In reply to Aldy Hernandez from comment #37)
> (In reply to Christophe Lyon from comment #31)
> > Created attachment 43352 [details]
> > Reduced testcase
> >
> > I commented out most calls, since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84265
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83204
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
--- Comment #9 from Jakub Jelinek ---
I think the bug is in the ARRAY_REF design, because at least in C one can have
arrays of over-aligned types the design choice that ARRAY_REF TREE_OPERAND (,
3)
is measured in multiplies of TYPE_ALIGN_UNIT of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84241
H.J. Lu changed:
What|Removed |Added
Target|powerpc64-unknown-linux-gnu |
|, aarch64-none-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84252
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 43358 [details]
> gcc8-pr84252.patch
>
> Full untested fix.
Thanks. Bootstrapped & regression-tested on aarch64-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
--- Comment #10 from rguenther at suse dot de ---
On Wed, 7 Feb 2018, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
>
> --- Comment #9 from Jakub Jelinek ---
> I think the bug is in the ARRAY_REF design,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80589
Martin Liška changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80589
Martin Liška changed:
What|Removed |Added
Known to work|8.0 |
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264
--- Comment #2 from Segher Boessenkool ---
It ICEs on
gcc_assert (!lra_in_progress && !reload_completed);
but this is called from the movv4si expander, and that is something LRA is
allowed to use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84241
--- Comment #8 from Jan Hubicka ---
I am testing fix for the missing resolution info. It turns out to be related to
rather early LTO hack to not put into symbol table symbols used only by
external definitions.
Concerning multiversioning this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
--- Comment #11 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #10)
> On Wed, 7 Feb 2018, jakub at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
> >
> > --- Comment #9 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84240
--- Comment #2 from xvl5190 at psu dot edu ---
Please try this example with optimization level -O1/-O2/-O3:
/* Executable testcase for 'output flags.' */
/* { dg-do rund *nbum; } */
char TestC() {
char r;
__asm__("stc": "=@ccc" (r));
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84258
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266
Bug ID: 84266
Summary: mmintrin.h intrinsic headers for PowerPC code fails on
power9
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037
--- Comment #21 from Richard Biener ---
So after r257453 we improve the situation pre-IVOPTs to just
6 IVs (duplicated but trivially equivalent) plus one counting IV. But then
when SLP is enabled IVOPTs comes along and adds another 4 IVs which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037
--- Comment #22 from Richard Biener ---
Author: rguenth
Date: Wed Feb 7 15:46:17 2018
New Revision: 257453
URL: https://gcc.gnu.org/viewcvs?rev=257453=gcc=rev
Log:
2018-02-07 Richard Biener
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037
--- Comment #23 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #21)
> So after r257453 we improve the situation pre-IVOPTs to just
> 6 IVs (duplicated but trivially equivalent) plus one counting IV. But then
> when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266
Bill Seurer changed:
What|Removed |Added
CC||munroesj at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Wed Feb 7 16:02:50 2018
New Revision: 257454
URL: https://gcc.gnu.org/viewcvs?rev=257454=gcc=rev
Log:
PR c++/84182 - ICE with captured lambda
PR c++/84181
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84182
--- Comment #1 from Jason Merrill ---
Author: jason
Date: Wed Feb 7 16:02:50 2018
New Revision: 257454
URL: https://gcc.gnu.org/viewcvs?rev=257454=gcc=rev
Log:
PR c++/84182 - ICE with captured lambda
PR c++/84181
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84182
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181
Jason Merrill changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84212
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
--- Comment #9 from Pat Haugen ---
(In reply to Andrey Belevantsev from comment #8)
> I will take a look. The ICE is within the code that models the scheduling
> loop in order to get the proper insn ticks and everything for later MD
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
Pat Haugen changed:
What|Removed |Added
Summary|[8 Regression] ICE in |[7/8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257
--- Comment #3 from 191919 <191919 at gmail dot com> ---
In macOS 10.12.6 with SIP disabled, the value of DYLD_LIBRARY_PATH was modified
to the same as in macOS 10.13.3, but the compilation speed was not affected.
I guess this is a regression of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
--- Comment #5 from rguenther at suse dot de ---
On Wed, 7 Feb 2018, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
>
> Aldy Hernandez changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263
--- Comment #2 from Nathan Sidwell ---
Martin has confirmed i686 host & target. (not just target)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #39 from Christophe Lyon ---
Maybe we can demote this from P1?
I'm sure armeb is getting a lot of attention, given other bug reports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84213
--- Comment #3 from Richard Biener ---
So the issue here is that the early debug generated for module_ra_gfdleta.F90
contains relocations to text symbols. That's a no-no.
So this is reproducible with just compiling this file with -flto -g, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84213
--- Comment #4 from Richard Biener ---
MODULE MODULE_RA_GFDLETA
REAL , SAVE :: EM1(28,180)
REAL ,SAVE, DIMENSION(5040):: EM1V
EQUIVALENCE (EM1V(1),EM1(1,1))
END MODULE module_RA_GFDLETA
101 - 177 of 177 matches
Mail list logo