https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
Roman Zhuykov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93143
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 9 08:18:51 2020
New Revision: 280029
URL: https://gcc.gnu.org/viewcvs?rev=280029&root=gcc&view=rev
Log:
PR target/93141
* config/i386/i386.md (subv4): Use SWIDWI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93202
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 9 08:20:25 2020
New Revision: 280030
URL: https://gcc.gnu.org/viewcvs?rev=280030&root=gcc&view=rev
Log:
PR inline-asm/93202
* config/riscv/riscv.c (riscv_print_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93039
--- Comment #5 from Alexander Monakov ---
Ah, in that sense. The extra load is problematic in cold code where it's likely
a TLB miss. For hot code: the load does not depend on any previous computations
and so does not increase dependency chains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93051
Richard Biener changed:
What|Removed |Added
Depends on||65752, 61502
--- Comment #4 from Richar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208
Bug ID: 93208
Summary: duplicated memory_resource, monotomic_buffer_resource
vtable, type_info d/t all-inline virtual functions
Product: gcc
Version: 10.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
Richard Biener changed:
What|Removed |Added
Blocks||93051
--- Comment #6 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208
Marc Mutz changed:
What|Removed |Added
Version|10.0|9.1.0
--- Comment #1 from Marc Mutz ---
Als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088
Roman Zhuykov changed:
What|Removed |Added
CC||zhroma at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93057
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93209
Bug ID: 93209
Summary: What is a bitfield's "underlying type"?
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93063
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93073
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93072
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93075
Richard Biener changed:
What|Removed |Added
Keywords||wrong-debug
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93076
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93077
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93078
--- Comment #4 from Richard Biener ---
So anything left here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080
--- Comment #2 from Richard Biener ---
It's a bugfix so applicable for stage3... pre-approved with a testcase.
wonder how complicated it would be to handle
vector int g(vector int a)
{
int b = a[0];
(*(vector unsigned int *)&a)[0] = b;
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93081
--- Comment #2 from Richard Biener ---
OK for trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
--- Comment #34 from Toni Neubert ---
Thank you both! Now everything works. :)
I'll keep that in mind.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93078
--- Comment #5 from Jakub Jelinek ---
Yes, handling ceil/floor etc. similarly to rint/nearbyint. Though that is just
a cleanup, not something that would result in different code generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84135
Tobias Burnus changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93092
Richard Biener changed:
What|Removed |Added
Keywords||memory-hog
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93210
Bug ID: 93210
Summary: Sub-optimal code optimization on struct/combound
constexpr (gcc vs. clang)
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93075
--- Comment #2 from tatyana at synopsys dot com ---
> the only suspicious thing is that both stdc-predef.h and t2.h appear to be
> at lineno 31/32?
Yes, line numbers for "-include" files also start from 31 for me.
The question is also should '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93092
--- Comment #2 from Richard Biener ---
On trunk:
(gdb) p cfun->cfg->x_last_basic_block
$1 = 8940
(gdb) p cfun->cfg->x_n_edges
$2 = 14897
so we miss
if (n_basic_blocks_for_fn (cfun) > 500
&& n_edges_for_fn (cfun) / n_basic_blocks_for_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93094
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93100
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93101
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
Summary|[regression] IC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> We've already bumped the library version to libstdc++.so.6.0.26
Typo! That should be libstdc++.so.6.0.27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #20 from Martin Liška ---
@Martin, Jakub: What's the status of the PR? Is there a consensus that it'a a
wrong-code issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93102
--- Comment #3 from Richard Biener ---
Implementation-wise the issue is we're committing too early to piecewise
init of C2029 during gimplification where IMHO we should always emit
an aggregate copy
C2029 = *.LC0;
which would allow opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #21 from Jakub Jelinek ---
There is no consensus on the #c0 testcase, but there are several other
testcases in this PR that are IMO unquestionably valid (or can be easily turned
into).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93112
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
--- Comment #5 from Richard Bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93092
--- Comment #3 from Thorsten Otto ---
I can confirm that -fno-var-trackings makes situation better, but it must
somehow be related to generating debug infos:
$ time g++ -O2 -g -c nfosmesa_init.i
real4m58.028s
user4m57.749s
sys 0m0.28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58334
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||markeggleston at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93117
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93112
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93118
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93209
--- Comment #1 from John Adriaan ---
I've also looked at the `unsigned : 0;` anonymous field. Frankly, it changes
nothing. Maybe it should?
struct S {
bool b : 1;
unsigned i : 1;
unsigned : 0;
}; // S
With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93118
--- Comment #5 from Jakub Jelinek ---
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Thu Jan 9 10:29:54 2020
New Revision: 280034
URL: https://gcc.gnu.org/viewcvs?rev=280034&root=gcc&view=rev
Log:
2020-01-09 Richard Biener
PR tree-optimization/93040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93209
--- Comment #2 from John Adriaan ---
Wow: I just realised. The following code for my proposal is problematic:
struct S {
bool b : 1;
unsigned i : 1;
unsigned : 0;
char c : 8;
}; // S
Should `c`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #14 from Richard Biener ---
Don't we want this in reassoc where I believe we do related transforms? That's
IMHO better than recursively pickling large expressions via match.pd patterns
(which incidentially has a recursion limit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #15 from Jakub Jelinek ---
Indeed, reassoc could be taught to handle that and do it both in the inside of
bb opt as well as when the & or | are actually && or || and split across
multiple bbs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Thu Jan 9 10:41:38 2020
New Revision: 280039
URL: https://gcc.gnu.org/viewcvs?rev=280039&root=gcc&view=rev
Log:
2020-01-09 Richard Biener
PR middle-end/93054
* gim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141
--- Comment #10 from Richard Biener ---
*** Bug 93142 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93142
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93143
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #16 from Andrew Pinski ---
So combineif should be mostly in reassoc then? That is definitely gcc 11
material. I have to think of how that would work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93144
--- Comment #2 from Richard Biener ---
Does code size change as well? It jumps back down and then up again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93159
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93160
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #17 from Jakub Jelinek ---
Dunno about others, but this particular optimization could be done in a new
function called next to optimize_range_tests_cmp_bitwise and
optimize_range_tests_var_bound because reassoc already has a framework
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165
--- Comment #6 from Richard Biener ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Alexander Monakov from comment #3)
> > So perhaps an unpopular opinion, but I'd say a
> > __builtin_branchless_select(c, a, b) (guaranteed to live t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93167
--- Comment #1 from Richard Biener ---
probably duplicate - hard to say w/ the backtrace not including ISL itself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93173
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93144
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93202
--- Comment #9 from Luís Marques ---
Thank you all participating in this discussion for your prompt replies and
fixes!
As usual, Jim spoils us with a comprehensive and clear description of the
subject matter.
I agree that those constraint modifi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93179
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93202
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93200
--- Comment #4 from Richard Biener ---
(In reply to Martin Sebor from comment #1)
> Created attachment 47612 [details]
> Translation unit to reproduce the warning.
>
> Attached is a cjdns-v20.4 translation unit that reproduces the warning with
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93134
--- Comment #10 from Martin Liška ---
*** Bug 93167 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
Bug 59859 depends on bug 93167, which changed state.
Bug 93167 Summary: [graphite] One another ICE with isl-0.22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93167
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93167
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93209
Richard Biener changed:
What|Removed |Added
Keywords||documentation
--- Comment #3 from Richa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93209
--- Comment #4 from John Adriaan ---
@RichardBiener,
I used the different types to prove my point: if they're all `unsigned`, it
still happens.
And the ABI merely defines whether `-fstrict-volatile-bitfields` is the default
or not (for ARM, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
--- Comment #7 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #6)
> or whether the backend "forgets" to set DECL_SECTION_NAME or the like.
That caused problems (don't remember which ones exactly, maybe to make
-fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #18 from Jakub Jelinek ---
Guess best would be to go through the ranges from first to last, check for the
pattern we are interested in (ranges[i].exp being SSA_NAME with BIT_AND_EXPR
def with constant where ranges[i].low == ranges[i].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93144
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #15 from Martin Sebor ---
Author: msebor
Date: Thu Jan 9 11:59:41 2020
New Revision: 280041
URL: https://gcc.gnu.org/viewcvs?rev=280041&root=gcc&view=rev
Log:
PR middle-end/93200 - spurious -Wstringop-overflow due to assignment
vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 93200, which changed state.
Bug 93200 Summary: [10 Regression] spurious -Wstringop-overflow due to
assignment vectorization to multiple members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93200
What|Remov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93200
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93200
--- Comment #5 from Martin Sebor ---
Author: msebor
Date: Thu Jan 9 11:59:41 2020
New Revision: 280041
URL: https://gcc.gnu.org/viewcvs?rev=280041&root=gcc&view=rev
Log:
PR middle-end/93200 - spurious -Wstringop-overflow due to assignment
vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92429
--- Comment #4 from Martin Liška ---
@avieira: Any progress on this one please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #16 from Martin Sebor ---
I would expect r280041 to suppress the warnings but I haven't tested it.
Thomas or Tobias, can one of you please verify they are gone and resolve the
bug if appropriate?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196
--- Comment #10 from xiehongbiao ---
(In reply to Andrew Pinski from comment #8)
> Can you also add -Wl,-v ; this will cause collect2 to print it runs?
It reports error :"gcc: error: unrecognized command line option ‘-Wl’".
Please let me know i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196
--- Comment #11 from Martin Liška ---
(In reply to xiehongbiao from comment #10)
> (In reply to Andrew Pinski from comment #8)
> > Can you also add -Wl,-v ; this will cause collect2 to print it runs?
>
> It reports error :"gcc: error: unrecogniz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93134
--- Comment #11 from Arseny Solokha ---
*** Bug 90004 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
Bug 59859 depends on bug 90004, which changed state.
Bug 90004 Summary: [graphite] ICE: Segmentation fault (in
scop_get_dependences(scop*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90004
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90004
Arseny Solokha changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 186 matches
Mail list logo
