https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #3 from Chris Elrod ---
Created attachment 45353
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45353=edit
g++ assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #2 from Chris Elrod ---
Created attachment 45352
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45352=edit
gfortran assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
Bug ID: 88713
Summary: _gfortran_internal_pack@PLT prevents vectorization
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #1 from Chris Elrod ---
Created attachment 45351
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45351=edit
C++ version of the vectorization test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81980
Eric Gallager changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80789
--- Comment #2 from Eric Gallager ---
not sure whether to cc the C++ FE maintainers or the diagnostics maintainers on
this...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78502
Eric Gallager changed:
What|Removed |Added
CC||jason at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156
Eric Gallager changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88607
--- Comment #10 from Jonathan Wakely ---
Author: redi
Date: Sun Jan 6 00:49:11 2019
New Revision: 267607
URL: https://gcc.gnu.org/viewcvs?rev=267607=gcc=rev
Log:
PR libstdc++/88607 add tests using -finput-charset=ascii
This verifies that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
Devin Hussey changed:
What|Removed |Added
CC||husseydevin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81871
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81871
--- Comment #4 from Eric Gallager ---
(In reply to Martin Sebor from comment #3)
> Let me fix this.
Any progress?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #4 from Marc Glisse ---
(In reply to Matthias Kretz from comment #3)
> Did you consider the error introduced by scaling with __amax? I made sure
> that the division is without error by zeroing the mantissa bits. Here's a
> motivating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88712
Andrew Pinski changed:
What|Removed |Added
Target||x86_64
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88712
Bug ID: 88712
Summary: Optimization: mov edx, 0 not replaced with xor edx,
edx in this case
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88710
--- Comment #4 from c...@mnet-mail.de ---
Thanks, this caught the bounds violation with the following output:
lbound/ubound(a):-1-1 1 2 1 1
lbound/ubound(b):-1-1 1 2 1 1
lbound/ubound(c):-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88710
--- Comment #3 from Dominique d'Humieres ---
> For what it's worth, I have compiled the code also with '-Wall'
> and '-Warray-bounds' but both these options didn't give any warning.
The relevant option is -fcheck=bounds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85052
--- Comment #9 from Matthias Kretz ---
(In reply to Devin Hussey from comment #7)
> Wait, silly me, this isn't about optimizations, this is about patterns.
Regarding optimizations, PR85048 is a first step (it lists all x86
single-instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88710
--- Comment #2 from c...@mnet-mail.de ---
Yes, the said block accesses 't' outside its bounds (because
the returned bounds are wrong).
Thanks for mentioning this.
For what it's worth, I have compiled the code also with '-Wall'
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #3 from Matthias Kretz ---
Did you consider the error introduced by scaling with __amax? I made sure that
the division is without error by zeroing the mantissa bits. Here's a motivating
example that shows an error of 1 ulp otherwise:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #26 from Gary Mills ---
> I have no concerns about removal of gcc support for Solaris 10: That is an
I've only mentioned it to make clear that the oldest version of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #26 from Gary Mills ---
I have no concerns about removal of gcc support for Solaris 10: That is an
obsolete operating system, after all. illumos is equivalent to Solaris 11.
gas is used for illumos compilers on x86. It works on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88710
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711
--- Comment #1 from kargl at gcc dot gnu.org ---
> The likely cause of this regression is
>
>
> r267600 | hubicka | 2019-01-05 09:47:34 -0800 (Sat, 05 Jan 2019) | 2 lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85052
--- Comment #8 from Jakub Jelinek ---
Note, I've posted in the meantime a newer version of the patch that should
handle the 2x narrowing or 2x widening cases better, see
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00129.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85052
--- Comment #7 from Devin Hussey ---
Wait, silly me, this isn't about optimizations, this is about patterns.
It does the same thing it was doing for this code:
typedef unsigned u32x2 __attribute__((vector_size(8)));
typedef unsigned long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85052
--- Comment #6 from Devin Hussey ---
The patch seems to be working.
typedef unsigned u32x2 __attribute__((vector_size(8)));
typedef unsigned long long u64x2 __attribute__((vector_size(16)));
u64x2 cvt(u32x2 in)
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711
Bug ID: 88711
Summary: [regression 9.0] scan-ipa-dump inline "Inlined
tp_sum/
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88710
Bug ID: 88710
Summary: [F08] Sourced allocation of array fails, yielding
wrong bounds and result
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88653
--- Comment #14 from Murat Tekeev ---
I will establish anew Cygwin and I will try to repeat compilation.
When I used version 7.3, everything was good.
Eventually, there are also other compilers, except gfortran.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88708
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88706
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> I think the same problem exists for the other work around in
> nvptx_adjust_parallelism, this one:
> ...
> /* FIXME: This is overly conservative; worker and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85855
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
Dominique d'Humieres changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 85855, which changed state.
Bug 85855 Summary: [7/8/9 Regression] (Maybe) uninitialized descriptor fields
of an allocatable array component of a function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85855
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85855
Seth Johnson changed:
What|Removed |Added
CC||johnsonsr at ornl dot gov
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88709
Jakub Jelinek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88709
Bug ID: 88709
Summary: Improve store-merging
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009
--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Jan 5 14:32:12 2019
New Revision: 267598
URL: https://gcc.gnu.org/viewcvs?rev=267598=gcc=rev
Log:
2019-01-05 Janus Weil
PR fortran/88009
* class.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #10 from Devin Hussey ---
Well what about a special type attribute or some kind of transparent_union like
thing for Intel's types? It seems that Intel's intrinsics are the main (only)
platform that uses generic types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88653
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #13 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88708
Bug ID: 88708
Summary: help-dummy.o file left behind
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88632
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88707
--- Comment #2 from Iain Sandoe ---
(on Darwin17 I had a recent build)
I find that a built exe fails quite often; here's a sample of the hung program
(it appears deadlocked, not consuming any CPU).
The correct libraries are being loaded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88707
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563
--- Comment #19 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jan 5 12:44:12 2019
New Revision: 267597
URL: https://gcc.gnu.org/viewcvs?rev=267597=gcc=rev
Log:
2019-01-05 Dominique d'Humieres
PR target/60563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88707
Bug ID: 88707
Summary: Random failures of libgomp.c++/task-reduction-(8|10).C
on x86_64-apple-darwin18
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82564
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88620
Jakub Jelinek changed:
What|Removed |Added
Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88653
--- Comment #12 from Dominique d'Humieres ---
It seems that the problem comes from your installation.
Did you build gfortran yourself or did you get it from some binary
distribution? If the later, from where? Did you report the problem to them?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563
--- Comment #18 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jan 5 11:17:40 2019
New Revision: 267596
URL: https://gcc.gnu.org/viewcvs?rev=267596=gcc=rev
Log:
2019-01-05 Dominique d'Humieres
PR target/60563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88706
Bug ID: 88706
Summary: [og8, nvptx, openacc] Inconsistencies when vector
length set using vector_length clause or fopenacc-dim
Product: gcc
Version: unknown
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88620
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Sat Jan 5 11:14:12 2019
New Revision: 267595
URL: https://gcc.gnu.org/viewcvs?rev=267595=gcc=rev
Log:
PR middle-end/82564
PR target/88620
* expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82564
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Sat Jan 5 11:14:12 2019
New Revision: 267595
URL: https://gcc.gnu.org/viewcvs?rev=267595=gcc=rev
Log:
PR middle-end/82564
PR target/88620
* expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #9 from Marc Glisse ---
(In reply to Devin Hussey from comment #2)
> What I am saying is that I think -flax-vector-conversions should be default,
> or we should only have minimal warnings instead of errors.
>
> That will make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88635
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Sat Jan 5 11:12:35 2019
New Revision: 267594
URL: https://gcc.gnu.org/viewcvs?rev=267594=gcc=rev
Log:
PR debug/88635
* dwarf2out.c (const_ok_for_output_1): Reject MINUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563
--- Comment #17 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jan 5 11:09:11 2019
New Revision: 267593
URL: https://gcc.gnu.org/viewcvs?rev=267593=gcc=rev
Log:
2019-01-05 Dominique d'Humieres
PR target/60563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88638
--- Comment #3 from Dominique d'Humieres ---
> I submitted the patch below for review. Dominique, if you have
> an opportunity to test it on Darwin and let me know if there are
> any outstanding problems that would be great.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #8 from Andrew Pinski ---
(In reply to Devin Hussey from comment #7)
> I mean, sure, but how about this?
>
> What about meeting in the middle?
The problem is how do you implement the rules that are required by both the
Altivec and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #7 from Devin Hussey ---
I mean, sure, but how about this?
What about meeting in the middle?
-fno-lax-vector-conversions generates errors like it does now.
-flax-vector-conversions shuts GCC up.
No flag causes warnings on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702
--- Comment #4 from Jan Hubicka ---
> The only pass that can do about this (at least right now) is reassoc (both 1
> and 2), which is too late for inlining. So, either teach fnsplit not to
> separate multiple if comparisons of the same variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
65 matches
Mail list logo
