https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #6 from Tim Shen ---
(In reply to Tomalak Geret'kal from comment #4)
> To be honest I'd expect this in less trivial circumstances too. If, at a
> given stage of processing, the only possible paths towards a match all
> require a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88938
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jan 22 16:35:53 2019
New Revision: 268157
URL: https://gcc.gnu.org/viewcvs?rev=268157=gcc=rev
Log:
PR target/88938
* config/i386/i386.c (ix86_expand_builtin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #6 from Segher Boessenkool ---
That patch looks good, and is pre-approved. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88938
--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jan 22 16:32:47 2019
New Revision: 268156
URL: https://gcc.gnu.org/viewcvs?rev=268156=gcc=rev
Log:
PR target/88938
* config/i386/i386.c (ix86_expand_builtin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #23 from Jakub Jelinek ---
Created attachment 45496
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45496=edit
gcc9-pr87064.patch
Patch I've so far tested on powerpc64le-linux only, where it fixed
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983
Bug ID: 88983
Summary: ICE in label_matches, at cp/constexpr.c:4035
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88984
Bug ID: 88984
Summary: [9 Regression] ICE in genericize_switch_stmt, at
cp/cp-gimplify.c:377
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88982
Bug ID: 88982
Summary: ICE in tsubst_pack_expansion, at cp/pt.c:12221
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #5 from Tim Shen ---
(In reply to Tomalak Geret'kal from comment #4)
> To be honest I'd expect this in less trivial circumstances too. If, at a
> given stage of processing, the only possible paths towards a match all
> require a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88909
--- Comment #1 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Jan 22 16:20:25 2019
New Revision: 268155
URL: https://gcc.gnu.org/viewcvs?rev=268155=gcc=rev
Log:
i386: Add mask2 to builtin_description
There are
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #22 from Bill Schmidt ---
(I'll test with both disabled for LE and report results.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #21 from Bill Schmidt ---
We should probably disable the _v4sf_scalar one for LE also, as this seems to
be doing a similar trick for V4SF.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #20 from Bill Schmidt ---
Oh, sorry, I missed that in all the commentary. I had looked at the code and
seen the "obvious" problem in the expansion, and noted you had suggested that
also. Should have read further.
I think that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88740
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88740
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Tue Jan 22 16:08:18 2019
New Revision: 268154
URL: https://gcc.gnu.org/viewcvs?rev=268154=gcc=rev
Log:
PR libstdc++/88740 Print assertion messages to stderr
PR libstdc++/88740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88981
Tom de Vries changed:
What|Removed |Added
Keywords||openacc
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88981
Bug ID: 88981
Summary: [nvptx, openacc, libgomp] How to handle async regions
without corresponding wait
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86756
--- Comment #7 from Jonathan Wakely ---
There are more changes needed to the library code, to stop using chdir, mkdir
etc. when not supported. This was first brought up in
https://gcc.gnu.org/ml/libstdc++/2019-01/msg00039.html
I'm not sure how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #8 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, maratrus at mail dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
>
> --- Comment #7 from Marat Stanichenko ---
> (In reply to rguent...@suse.de from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88980
Bug ID: 88980
Summary: [9 regression] segfault on allocatable string member
assignment
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #18 from Segher Boessenkool ---
(In reply to Alan Modra from comment #17)
> > Is anything broken though?
>
> Yes, as demonstrated by the testcase.
I couldn't get the testcase to link, I don't think I have an __floatunsidf
anywhere,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
--- Comment #23 from Jonathan Wakely ---
Actually, I wonder if it's caused by r264958 because 'std::string' is no longer
unambiguous in libstdc++.so
In some translation units it is a typedef for std::basic_string and in
other translation units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #4 from Tomalak Geret'kal ---
To be honest I'd expect this in less trivial circumstances too. If, at a given
stage of processing, the only possible paths towards a match all require a
prefix that's already been ruled out, that should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #6 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Jan 22 14:53:41 2019
New Revision: 268152
URL: https://gcc.gnu.org/viewcvs?rev=268152=gcc=rev
Log:
i386: Load external function address via GOT slot
With noplt attribute, we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #7 from Marat Stanichenko ---
(In reply to rguent...@suse.de from comment #6)
> > Do you believe that compiler can do better in such situations? Or the
> > current
> > behaviour is perfectly valid and no improvements are really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
--- Comment #22 from Jonathan Wakely ---
Pedro, I'm seeing this again with GDB 8.2 (specifically gdb-8.2-6.fc29.x86_64).
Is it likely to be something different, or a GDB regression?
(I still want a libstdc++ fix that works for older GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
--- Comment #3 from Alexander Monakov ---
Note, without the attribute gcc passes the union on an SSE register, so it
doesn't look like TImode on the union matters (otherwise it would be passed via
rdx:rax register pair):
typedef unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979
Bug ID: 88979
Summary: [C++20] P0634R3 not working for constructor parameter
types
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88978
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88978
Bug ID: 88978
Summary: Failed outer loop vectorization with grouped accesses
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919
--- Comment #4 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, clyon at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919
>
> Christophe Lyon changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #22 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, ktkachov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
>
> --- Comment #21 from ktkachov at gcc dot gnu.org ---
> So the actual hot loop in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Summary|[7/8/9 regression] AAPCS - |[7/8 regression] AAPCS -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #6 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, maratrus at mail dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
>
> --- Comment #5 from Marat Stanichenko ---
>
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936
--- Comment #10 from Richard Biener ---
So the idea for the fix is to make locals that escape through recursive edges
behave as if they were really *ptr with ptr pointing to ,
where localp would be "the other locals". This could be done on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #21 from ktkachov at gcc dot gnu.org ---
So the actual hot loop in xz_r does:
typedef unsigned char __uint8_t;
typedef unsigned int __uint32_t;
typedef unsigned long long __uint64_t;
int
foo (const __uint64_t len_limit, const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #6 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Jan 22 14:03:22 2019
New Revision: 268151
URL: https://gcc.gnu.org/viewcvs?rev=268151=gcc=rev
Log:
[arm] PR target/88469 fix incorrect argument passing with 64-bit bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #5 from Anton Blanchard ---
Martin: "gcc -c x.c" was enough to hit it on a build of trunk on my POWER9
ppc64le box.
Jakub: Thanks, that fixes it for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044
--- Comment #17 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #16)
> Fixed.
I confirm the problem I mentioned in #c3 is now fixed. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88948
--- Comment #3 from Uroš Bizjak ---
Created attachment 45494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45494=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #11 from Thomas De Schampheleire ---
Any feedback? With the reduced testcase qemu is out of the picture.
Do you agree that this is a bug in gcc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88977
Bug ID: 88977
Summary: __builtin_is_constant_evaluated() as function template
argument causes substitution failure
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #5 from Marat Stanichenko ---
(In reply to Richard Biener from comment #1)
> This is because it still needs to generate the std::string objects at the
> caller
Thank you very much for the comment! That is probably why I had to add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936
--- Comment #9 from Richard Biener ---
(In reply to Jan Hubicka from comment #7)
> Hi,
> there is ipa_reduced_postorder that will compute SCCs and store scc
> index.
OK, from looking at examples it seems that I can access node->aux
as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88976
Bug ID: 88976
Summary: ICE in fold_convert_loc, at fold-const.c:2552
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88975
Bug ID: 88975
Summary: ICE: Segmentation fault (in verify_ssa or gimple_code)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88974
Bug ID: 88974
Summary: [9 Regression] ICE: Segmentation fault (in
linemap_resolve_location)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
--- Comment #3 from Jakub Jelinek ---
The problem is that for these packed structs the DECL_BIT_FIELD_REPRESENTATIVE
is not integral FIELD_DECL that the c-omp.c code assumes. BIT_FIELD_REF seems
to work with non-integral base types from which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Arseny Solokha changed:
What|Removed |Added
Component|c |middle-end
--- Comment #2 from Arseny
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51765
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #11 from Uroš Bizjak ---
(In reply to Christopher Leonard from comment #10)
> Getting contradictory statements now:
> >reg:reg+1 maps to lo:hi on x86.
> >On x86, we don't allow register pairs in asm at all.
>
> Not allowing, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #1)
> This is because it still needs to generate the std::string objects at the
> caller
> site (outside of the if (print)). This involves quite some code to get
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88972
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #2 from Jonathan Wakely ---
(In reply to Richard Biener from comment #1)
> rid of, and even at -O3 we do not inline basic_string::basic_string it seems
> (ISTR that is out-of-line in the library):
There's an explicit instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
Jakub Jelinek changed:
What|Removed |Added
Attachment #45491|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
--- Comment #7 from Jakub Jelinek ---
Actually no, with HONOR_SIGNED_ZEROS it shouldn't be optimized out.
So, if we don't have other way how to make distinction between a normal chrec
with step +0.0 and loop invariant var, we should punt at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88972
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88970
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
--- Comment #6 from Jakub Jelinek ---
In the spot which I'm changing IMHO shouldn't, that + 0.0 really should be
folded (and if not, we should tweak create_iv not to do any addition if
real_zerop). Though of course for other floating point IVs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #4 from Richard Biener ---
LGTM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
--- Comment #5 from Richard Biener ---
Hmm, I wonder if handling FP inductions during interchange causes correctness
issues as well (FP rounding, etc.). Otherwise the patch looks obvious.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88862
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88862
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Tue Jan 22 11:28:56 2019
New Revision: 268147
URL: https://gcc.gnu.org/viewcvs?rev=268147=gcc=rev
Log:
2019-01-22 Richard Biener
PR tree-optimization/88862
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Bug ID: 88973
Summary: New -Wrestrict warning since r268048
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #27 from Chris Elrod ---
g++ -mrecip=all -O3 -fno-signed-zeros -fassociative-math -freciprocal-math
-fno-math-errno -ffinite-math-only -fno-trapping-math -fdump-tree-optimized -S
-march=native -shared -fPIC -mprefer-vector-width=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #5 from Richard Biener ---
For indirect calls the attributes on the function type pointed to a relevant.
Unioning attributes from the actually called function (if the compiler can
figure that out) can be appropriate depending on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88950
Matthew Malcomson changed:
What|Removed |Added
Known to fail||5.4.0
--- Comment #5 from Matthew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #26 from Chris Elrod ---
> You can try enabling -mrecip to see RSQRT in .optimized - there's
> probably late 1/sqrt optimization on RTL.
No luck. The full commands I used:
gfortran -Ofast -mrecip -S -fdump-tree-optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
--- Comment #4 from Jakub Jelinek ---
Created attachment 45491
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45491=edit
gcc9-pr88964.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #9 from Devin Hussey ---
(In reply to Andrew Pinski from comment #6)
> Try using 128 (or 256) and you might see that aarch64 falls down similarly.
yup. Oof.
test:
sub sp, sp, #560
stp x29, x30, [sp]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #25 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, elrodc at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
>
> --- Comment #24 from Chris Elrod ---
> The dump looks like this:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88972
Bug ID: 88972
Summary: popcnt of limited 128-bit number with unnecessary
zeroing
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88950
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #24 from Chris Elrod ---
The dump looks like this:
vect__67.78_217 = SQRT (vect__213.77_225);
vect_ui33_68.79_248 = { 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0,
1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88948
--- Comment #2 from Uroš Bizjak ---
The problem is with can_assign_to_reg_without_clobbers_p in gcse.c, where we
have:
/* If the test insn is valid and doesn't need clobbers, and the target also
has no objections, we're good. */
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953
--- Comment #5 from Jan Kossmann ---
You are right, I verified with:
gcc version 9.0.0 20190122 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-o' 'test.cpp.o'
'-shared-libgcc' '-march=z13' '-mno-htm' '-mzarch' '-m64'
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
Bug ID: 88971
Summary: Branch optimization inconsistency (missed
optimization)
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953
--- Comment #4 from Andreas Krebbel ---
Looks like a problem which was fixed with r265158:
S/390: Fix problem with vec_init expander
gcc/ChangeLog:
2018-10-15 Andreas Krebbel
* config/s390/s390.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37398
--- Comment #4 from Dominique d'Humieres ---
> This correctly gives the expected error messages since at least gfortran 5.4.
> Closing as FIXED?
FORALL(i=1:4) a(i) = st3 (i) is still not caught.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88906
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88904
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88897
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #8 from Richard Biener ---
You can try the attached patch, it "fixes" the issue on the GIMPLE side but
appearantly the BIT_FIELD_REF stores go a weird path during RTL expansion
and so we end up spilling again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #7 from Marc Glisse ---
See PR 55266 (and several others).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88862
--- Comment #2 from Richard Biener ---
Huh. We get here from originally (integer(kind=4)) The
stmt we analyze is
if (_4 != _316)
I have a simple patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
101 - 200 of 256 matches
Mail list logo
