https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120
Bug ID: 84120
Summary: Syntax for used for PDT constructors is incorrect
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65968
Leslie Zhai changed:
What|Removed |Added
CC||lesliezhai at llvm dot org.cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84119
Bug ID: 84119
Summary: Type parameter inquiry for PDT returns array instead
of scalar
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83828
--- Comment #7 from Kirill Yukhin ---
On the other hand, if masked variant of vpopcnt[w,q] is being issued: there's
no way for reload to put 32/64 bit mask into mask register, since kmov[d,q] are
only available under -mavx512bw switch.
We can i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666
--- Comment #5 from Jeffrey A. Law ---
Aldy,
It's less about whether or not there is a cmov (I get one with and without
PRE), but more about what part of the loop we're using the cmov for.
Consider what we get in the .optimized dump at -O3 corr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83828
Kirill Yukhin changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81010
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81010
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
Aldy Hernandez changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83147
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
Aldy Hernandez changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #5 from Aldy Hernandez
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068
Aldy Hernandez changed:
What|Removed |Added
CC||wdijkstr at arm dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
Arseny Solokha changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089
--- Comment #2 from dave.anglin at bell dot net ---
Attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
Aldy Hernandez changed:
What|Removed |Added
Attachment #43282|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
--- Comment #5 from Aldy Hernandez ---
Created attachment 43282
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43282&action=edit
untested patch
Proposed patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84118
Bug ID: 84118
Summary: filesystem::path concat does not accept value_type
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #14 from Martin Sebor ---
Yes, the attribute affects all callers in the same translation unit and so it
needs to match across both the declarations and the definition.
I (and others) tested Glibc with this patch and if this had been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83937
--- Comment #7 from Marek Polacek ---
Actually this might be just a missing TARGET_EXPR_DIRECT_INIT_P check in
build_special_member_call:
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8824,7 +8824,8 @@ build_special_member_call (tree instance, tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
--- Comment #7 from Michael Matz ---
(In reply to Jakub Jelinek from comment #6)
> Sure, but some of the mentioned SSA_NAMEs are registered for update and SCEV
> code is called before that happens.
Yes, sure. That still doesn't necessarily mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84096
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Mon Jan 29 23:38:01 2018
New Revision: 257167
URL: https://gcc.gnu.org/viewcvs?rev=257167&root=gcc&view=rev
Log:
PR libgomp/84096
* omp.h.in (omp_init_nest_lock_with_hint)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
--- Comment #6 from Jakub Jelinek ---
Sure, but some of the mentioned SSA_NAMEs are registered for update and SCEV
code is called before that happens.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
Michael Matz changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |matz at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84091
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871
Yann Collet changed:
What|Removed |Added
CC||yann.collet.73 at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84087
Berni changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84042
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550
--- Comment #11 from Michael Meissner ---
Author: meissner
Date: Mon Jan 29 22:30:34 2018
New Revision: 257166
URL: https://gcc.gnu.org/viewcvs?rev=257166&root=gcc&view=rev
Log:
2018-01-29 Michael Meissner
PR target/81550
* c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #13 from Jakub Jelinek ---
(In reply to Martin Sebor from comment #12)
> AFAIK, specifying attribute const and pure on a function definition has no
> effect on the code emitted for the function itself or on its callers in
> other tran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
Aldy Hernandez changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #12 from Martin Sebor ---
AFAIK, specifying attribute const and pure on a function definition has no
effect on the code emitted for the function itself or on its callers in other
translation units, so what you describe doesn't sound m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84109
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #31 from acsawdey at gcc dot gnu.org ---
I'm not sure where the copy happens, I am just surmising that it must have been
added because the code clearly assumes it won't be copied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84098
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #30 from rsandifo at gcc dot gnu.org
---
(In reply to acsawdey from comment #29)
> The problematic expression was:
>
> (mem/c:QI (plus:DI (plus:DI (reg/f:DI 187) (const_int 32 [0x20])) (const_int
> 72 [0x48]))
>
> and internal_arg_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #11 from Jakub Jelinek ---
There is a valid use case, you have some public interface which you only want
to guarantee to be pure, the result depends on the arguments and e.g. on some
OSes or in some specific cases needs read-only acce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086
--- Comment #8 from Harald Anlauf ---
(In reply to jsberg from comment #7)
> As to why I think this is a bug (and why I think Intel's compiler is doing
> the right thing), referencing the 2008 standard (N1830):
In the F2018 DIS (N2146) the corre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #5 from Arnd Bergmann ---
Here are some additional instances in the kernel. I'm currently trying to get a
reliable build first and haven't got a log of all the messages, but there are a
number of changes I did that are related, shutti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835
--- Comment #3 from Marek Polacek ---
Perhaps we also want to set TARGET_EXPR_DIRECT_INIT_P here:
6785 /* If this is a constructor or a function returning an aggr type,
6786we need to build up a TARGET_EXPR. */
6787
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
Joseph S. Myers changed:
What|Removed |Added
Target Milestone|8.0 |7.4
--- Comment #25 from Joseph S. Mye
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #24 from Joseph S. Myers ---
Author: jsm28
Date: Mon Jan 29 21:00:52 2018
New Revision: 257165
URL: https://gcc.gnu.org/viewcvs?rev=257165&root=gcc&view=rev
Log:
Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467).
PR tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Mon Jan 29 20:58:36 2018
New Revision: 257164
URL: https://gcc.gnu.org/viewcvs?rev=257164&root=gcc&view=rev
Log:
PR c++/82461 - constexpr list-initialized member
* conste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83996
Marek Polacek changed:
What|Removed |Added
Summary|[6/7/8] Regression] ICE |[6/7] Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68810
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68810
--- Comment #19 from Jason Merrill ---
Author: jason
Date: Mon Jan 29 20:56:00 2018
New Revision: 257161
URL: https://gcc.gnu.org/viewcvs?rev=257161&root=gcc&view=rev
Log:
PR c++/68810 - wrong location for reinterpret_cast error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83996
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Mon Jan 29 20:54:12 2018
New Revision: 257160
URL: https://gcc.gnu.org/viewcvs?rev=257160&root=gcc&view=rev
Log:
PR c++/83996
* constexpr.c (cxx_fold_indirect_ref): Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
--- Comment #2 from Arnd Bergmann ---
Created attachment 43281
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43281&action=edit
preprocessed simplified sm_sideeffect.c, compressed
I managed to get a standalone testcase now, manually reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #10 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #9)
This is not a style warning. Because there is no valid use case for having
both attribute const and pure on two declarations of the same function, in the
absence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066
--- Comment #7 from H.J. Lu ---
(In reply to igor.v.tsimbalist from comment #6)
> >
> > reg_ssp must be in word_mode, not in Pmode.
>
> reg_ssp is word_mode. It's reg_adj that is Pmode (it's increment to shadow
> stack).
OK.
> > Please show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68810
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066
--- Comment #6 from igor.v.tsimbalist at intel dot com ---
(In reply to H.J. Lu from comment #5)
> (In reply to igor.v.tsimbalist from comment #4)
> > Created attachment 43280 [details]
> > updated patch
>
> - mem = gen_rtx_MEM (Pmode, plus_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #4 from Martin Sebor ---
Thanks.
Just for reference in case more of these should pop up, I see two -Wrestrict
instances in my build (below). The first one looks correct but the second one
could be an instance of the false positive r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #9 from Jakub Jelinek ---
If you mean it as a coding style warning (at least for const/pure), then it is
at least worded incorrectly, there is no conflict between those and if what you
do is that you ignore const attribute because ear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
Andrew Pinski changed:
What|Removed |Added
CC||antoshkka at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84103
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24928
Andrew Pinski changed:
What|Removed |Added
CC||antoshkka at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84099
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066
--- Comment #5 from H.J. Lu ---
(In reply to igor.v.tsimbalist from comment #4)
> Created attachment 43280 [details]
> updated patch
- mem = gen_rtx_MEM (Pmode, plus_constant (Pmode, operands[0],
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066
--- Comment #4 from igor.v.tsimbalist at intel dot com ---
Created attachment 43280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43280&action=edit
updated patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #29 from acsawdey at gcc dot gnu.org ---
The problematic expression was:
(mem/c:QI (plus:DI (plus:DI (reg/f:DI 187) (const_int 32 [0x20])) (const_int 72
[0x48]))
and internal_arg_pointer was (plus:DI (reg/f:DI 187) (const_int 32 [0x2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
--- Comment #4 from Jakub Jelinek ---
Seems this is during
#0 follow_copies_to_constant (var=) at
../../gcc/tree-scalar-evolution.c:1548
#1 0x010ce55e in analyze_scalar_evolution_1 (loop=0x7fffefb99550,
var=)
at ../../gcc/tree-scala
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #3 from Arnd Bergmann ---
(In reply to Martin Sebor from comment #2)
> (In reply to Arnd Bergmann from comment #0)
>
> Let me work on this.
>
> I tested the warning with the kernel but don't recall coming across this
> false positiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117
Bug ID: 84117
Summary: [8 Regression] ICE in gimplify_modify_expr, at
gimplify.c:5798
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #28 from rsandifo at gcc dot gnu.org
---
(In reply to acsawdey from comment #27)
> So, I think the problem is that the rtx given by
> crtl->args.internal_arg_pointer is not canonical as expected. So near the
> beginning of vt_add_fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84116
Bug ID: 84116
Summary: [7/8 Regression] ICE in gfc_match_omp_clauses, at
fortran/openmp.c:1354
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115
--- Comment #1 from G. Steinmetz ---
A few more testcases :
$ cat z2.f90
subroutine s(x)
character(:), allocatable :: x
associate (y => x)
print *, y
end associate
end
$ cat z3.f90
subroutine s(x)
character(:), allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115
Bug ID: 84115
Summary: [8 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'indirect_ref'
in add_decl_as_local, at fortran/trans-decl.c:256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84108
--- Comment #3 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #1)
> I vaguely remember the behavior of packed + aligned(N) kept changing in the
> past, some versions of GCC treated it just like packed, others as aligned.
> Is this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83975
--- Comment #7 from G. Steinmetz ---
Some additional testcases :
$ cat z2.f90
subroutine s(x)
character(*) :: x
associate (y => [x])
print *, size(y), len(y), y
end associate
end
$ cat z3.f90
subroutine s(x)
character(*) ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84090
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114
Bug ID: 84114
Summary: global reassociation pass prevents fma usage,
generates slower code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077
--- Comment #5 from Flössie ---
Created attachment 43278
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43278&action=edit
Complete -v output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #17 from Jonathan Wakely ---
For the avoidance of doubt:
C++98 did not support reading hex floats from an istream.
Libstdc++ still follows the C++98 spec, so does not read hex floats. "0x1" is
read as "0". "0x1p1" is also read as "0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #1 from Douglas Mencken ---
ah yep, it’s at first stage
$ cat stage_current
stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #23 from Jeffrey A. Law ---
I've got no objection Joseph. But I think you need to make your case to Richi
and Jakub -- I doubt they're on CC for this BZ :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84108
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83966
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #22 from joseph at codesourcery dot com ---
What do the m68k maintainers think about the suggestion of backporting to
GCC 7 (and for that matter GCC 6)? This is a regression in the sense of
"libgcc used to build for ColdFire, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088
--- Comment #6 from Paul Thomas ---
(In reply to Tom de Vries from comment #5)
> Hmm. Probably this failure would have been picked up by
> libgomp-plugin-host_nonshm.
Hi Tom,
Although my patch caused it, I am not in a position to pick this one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83966
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Mon Jan 29 18:20:01 2018
New Revision: 257159
URL: https://gcc.gnu.org/viewcvs?rev=257159&root=gcc&view=rev
Log:
PR c/83966
* c-format.c (check_function_format): Check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
--- Comment #3 from Jakub Jelinek ---
Seems during cunroll we end up with:
y_8 = PHI
...
y_29 = PHI
...
y_37 = PHI
where all 3 PHIs are degenerate and thus:
1539static tree
1540follow_copies_to_constant (tree var)
1541{
1542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
Bug ID: 84113
Summary: gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler
error: in extract_insn, at recog.c:2311
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80867
--- Comment #11 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Mon Jan 29 18:00:49 2018
New Revision: 257158
URL: https://gcc.gnu.org/viewcvs?rev=257158&root=gcc&view=rev
Log:
gcc/ChangeLog:
2018-01-29 Richard Biener
Kelvi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965
--- Comment #8 from amker at gcc dot gnu.org ---
I think there is inconsistent semantics between call in vect_do_peeling:
scale_loop_profile (prolog, prob_prolog, bound_prolog);
and implementation of scale_loop_profile.
When the loop is predi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84112
--- Comment #1 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #0)
> The following testcase ICEs with -mcpu=power8 -O3 -fstack-protector-strong
> -fpic on powerpc64le-linux with:
> rh1539812.i: In function ‘foo’:
> rh1539812.i:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #8 from Martin Sebor ---
The purpose of the warning is to detect coding mistakes. There is no valid use
case for declaring the same function const and pure so it must be a mistake.
As the test case shows, the mistake can lead to sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84108
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
1 - 100 of 238 matches
Mail list logo
