https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
Bug 45223 depends on bug 42108, which changed state.
Bug 42108 Summary: [4.9 Regression] 50% performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69720
Richard Biener changed:
What|Removed |Added
Known to work||6.0
Summary|[4.9/5/6 Regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69991
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69990
Richard Biener changed:
What|Removed |Added
CC||mliska at suse dot cz
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69990
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69989
--- Comment #9 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #3)
> WRT fallout and reverting on the gcc-5 branch. Based on what I'm seeing,
> that may make sense.
>
> The problem in this particular case is we've marked loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012
--- Comment #1 from Richard Biener ---
Might be a testsuite artifact in not reaching the cost model check but
rejecting vectorization earlier (try bumping N to 32, after peeling for
alignment no
vectorized iteration would be left so we don't peel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70007
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70005
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70001
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.4
Summary|[5 regression] I
with the
case of a structure passed in slot #15
(sparc_function_arg_advance): Likewise.
(function_arg_padding): Minor tweak.
Added:
trunk/gcc/testsuite/gcc.target/sparc/20160229-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c
trunk/gcc/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69972
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70007
--- Comment #1 from Uroš Bizjak ---
PRE pass is moving (insn 7) out of the loop. Before the transformation, we
have:
(code_label 84 2 5 3 2 "" [1 uses])
(note 5 84 6 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 6 5 7 3 (set (reg:DI 117 [ v32u64_1+24 ])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
--- Comment #2 from Richard Biener ---
So we fail analyzing the loop nest because a) the loop header check of the
inner
loop makes it conditionally executed, b) we have outer loop IV computes i+-1
guarded by that check.
For a/b) it would be best
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70007
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994
--- Comment #2 from Richard Biener ---
On ppc64le I see
offset.3_15 = ~stride.2_11;
_45 = (unsigned long) stride.2_11;
_49 = (unsigned long) offset.3_15;
_14 = _45 + 1;
_51 = _14 + _49;
which is supposed to be optimized via
/* ~A +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70004
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69972
--- Comment #2 from Marek Polacek ---
The first warning is shown by default and comes from parser_build_binary_op:
3612 if (TREE_OVERFLOW_P (result.value)
3613 && !TREE_OVERFLOW_P (arg1.value)
3614 && !TREE_OVERFLOW_P (arg2.value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69973
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69993
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994
--- Comment #3 from Richard Biener ---
Created attachment 37821
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37821&action=edit
untested fix
Patch I am testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69942
--- Comment #2 from Yuri Rumyantsev ---
I attached patch which resolves failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69942
--- Comment #3 from Yuri Rumyantsev ---
Created attachment 37822
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37822&action=edit
proposed patch
Patch to resolve ifcvt5.c failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69989
--- Comment #10 from Richard Biener ---
So - we have an irreducible region that has a reducible part (a memset loop).
The entry into that reducible part is marked as EDGE_IRREDUCIBLE_LOOP.
Loop distribution re-directs the src of the exit of that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70015
Bug ID: 70015
Summary: Finalizer not called depending on declaration order
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70015
Troy Korjuslommi changed:
What|Removed |Added
URL||http://tksoft.com/people/tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69760
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69980
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Mon Feb 29 13:24:24 2016
New Revision: 233809
URL: https://gcc.gnu.org/viewcvs?rev=233809&root=gcc&view=rev
Log:
2016-02-19 Richard Biener
PR tree-optimization/69980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69980
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70004
--- Comment #2 from ktkachov at gcc dot gnu.org ---
The function that changes is:
test_corners_sisd_si (Int32x1 b)
{
force_simd_si (b);
b = b >> 31;
force_simd_si (b);
b = b >> 0;
b += b >> 33; /* { dg-warning "right shift count >= width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69954
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69954
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69990
--- Comment #5 from Alan Modra ---
I don't think we can make the decl with the larger alignment prevail. Aren't
we stuck with "c" due to it being referenced by the constructor?
It goes like:
1) "c" is referenced in a constructor, thus make_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #12 from David Malcolm ---
(In reply to Manuel López-Ibáñez from comment #11)
> (In reply to Markus Trippelsdorf from comment #6)
> > Bingo! With both files present I can even reproduce it on my x86_64 machine.
>
> Unfortunately, I c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #13 from Markus Trippelsdorf ---
Yeah, see also comment 5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #14 from David Malcolm ---
(gdb) p *map
$8 = { = {start_location = 98229568, reason = LC_RENAME_VERBATIM},
to_file = 0x2709850 "cmds-check.c", to_line = 7836,
included_from = -1, sysp = 0 '\000', m_column_and_range_bits = 12,
m_ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Mon Feb 29 14:25:57 2016
New Revision: 233810
URL: https://gcc.gnu.org/viewcvs?rev=233810&root=gcc&view=rev
Log:
PR c++/69995
* constexpr.c (cxx_eval_store_expression): Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #15 from David Malcolm ---
A minimal reproducer:
$ cat t3.c
extern int printf (const char *__restrict __format, ...);
void test (void)
{
printf
("%llu012334567890123345678901233456789012334567890123345678901233456789012334567890123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #16 from David Malcolm ---
Created attachment 37825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37825&action=edit
Minimal reproducer
Looks like BZ line-wrapped the inline copy; here it is as an attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69798
--- Comment #3 from Marek Polacek ---
Started with r204172.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #17 from David Malcolm ---
(In reply to David Malcolm from comment #16)
> Created attachment 37825 [details]
> Minimal reproducer
>
> Looks like BZ line-wrapped the inline copy; here it is as an attachment.
Interestingly, Chromium l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016
Bug ID: 70016
Summary: [Regression] pr52429.c fails since r233745
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
--- Comment #10 from Ilya Enkovich ---
Author: ienkovich
Date: Mon Feb 29 14:32:24 2016
New Revision: 233811
URL: https://gcc.gnu.org/viewcvs?rev=233811&root=gcc&view=rev
Log:
gcc/testsuite/
2016-02-29 Yuri Rumyantsev
PR tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
--- Comment #3 from Bill Schmidt ---
I'll have a look at the differences in output from GCC 5 and GCC 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70008
--- Comment #1 from Richard Earnshaw ---
Huh? The attribute
(set_attr "arch" "*,a")
Should disable the second alternative for Thumb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Mon Feb 29 14:49:17 2016
New Revision: 233813
URL: https://gcc.gnu.org/viewcvs?rev=233813&root=gcc&view=rev
Log:
PR c++/69995
* constexpr.c (cxx_eval_store_expression): Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Mon Feb 29 14:49:12 2016
New Revision: 233812
URL: https://gcc.gnu.org/viewcvs?rev=233812&root=gcc&view=rev
Log:
PR c++/65985
* constexpr.c (build_constexpr_constructor_me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016
--- Comment #2 from ktkachov at gcc dot gnu.org ---
this_target_ira_int->x_init_cost is NULL when it's used, causing the ICE.
I would have expected target_reinit to have properly initialised it when called
through save_target_globals_default_opts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #2 from Edmar Wienskoski ---
Right, but the variables A and B are *unsigned short*.
Both A, and B are promoted to signed int, but max value is 65535.
So, the result of A*B *can* be bigger than 31 bits.
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Mon Feb 29 15:30:50 2016
New Revision: 233816
URL: https://gcc.gnu.org/viewcvs?rev=233816&root=gcc&view=rev
Log:
2016-02-29 Richard Biener
PR tree-optimization/69994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281
Bernd Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70007
H.J. Lu changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #3 from H.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69798
--- Comment #4 from Marek Polacek ---
There are two c_parser_postfix_expression calls that should probably be guarded
with something like
8044 if (c_parser_peek_2nd_token (parser)->type !=
CPP_OPEN_PAREN
8045 ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65189
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #18 from Manuel López-Ibáñez ---
I think the heuristic I implemented to figure out on which map we can encode
the new location does not work.
The heuristic assumes that if map[0].start_location <= loc + offset <
map[1].start_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63433
Ramana Radhakrishnan changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
--- Comment #6 from marc at kdab dot com ---
To expand on my previous comment: the compiler is even allowed to elide the
copy if that would save a read/write from a volatile object. So I don't see how
this can be implemented anywhere except the fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
--- Comment #3 from marc at kdab dot com ---
This really should be top priority. But no comment on it for almost three years
by GCC devs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #4 from Edmar Wienskoski ---
I forgot that default on x86 is 64 bits.
Repeating the test with -m32 still shows the signed comparison.
Here:
#include
void main ()
{
unsigned short int A, B;
unsigned long C,D;
unsigned long E =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #19 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #18)
> I don't really understand why this is the case: we seem to waste a lot of
> location numbers that do not point to anything. If there is a way to tel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
--- Comment #4 from Thomas Braun ---
(I'm no gcc dev at all)
In general gcc is much better in doing NRVO/URVO than other compilers according
to my analysis [1]. So maybe the competitors need to get better first ;)
[1]: http://www.byte-physics.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70014
--- Comment #1 from Richard Earnshaw ---
More importantly, the constraint on operand 2 is for just a constant. but the
predicate accepts a register. That's something the register allocator could
not handle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
--- Comment #5 from Richard Biener ---
comment #2 (In reply to Richard Biener from comment #2)
> So we fail analyzing the loop nest because a) the loop header check of the
> inner
> loop makes it conditionally executed, b) we have outer loop IV c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Bill Schmidt changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #20 from David Malcolm ---
In r230331 I added a range-packing optimization; looks like I forgot to update
linemap_position_for_loc_and_offset accordingly. Sorry. The input "offset" is
a column offset, and that is no longer applicabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69788
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70006
--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> > OK, How about WONTFIX? If the programmer fixes the
> > issue reported in the "duplicate" error message, then
> > the problem goes away.
>
> W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #5 from Jakub Jelinek ---
Even if the computation is 32-bit, by the time you multiply say (unsigned short
int) 0x with itself, you get undefined behavior.
So, as has been said, if you want to perform the multiplication in unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
Bug ID: 70017
Summary: Ada: c52103x test failure on s390x
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69811
Jakub Jelinek changed:
What|Removed |Added
Summary|[5/6 Regression] A gcc |A gcc folding issue at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #6 from Edmar Wienskoski ---
Hummm, You are almost convincing me, one last question,
be patient with me.
As Andrew posted:
C = A * B
should be equivalent to:
C = (unsigned long)( ((int)A) * ((int)B) )
The variables are promoted *bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
Andrew Pinski changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #7 from Andrew Pinski ---
(In reply to Edmar Wienskoski from comment #6)
> Hummm, You are almost convincing me, one last question,
> be patient with me.
>
> As Andrew posted:
> C = A * B
> should be equivalent to:
> C = (unsigned lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #8 from Jakub Jelinek ---
0x7fff * 0x7 is 0x3fff0001 and that is representable in int, so there is no
overflow.
0xb504 * 0xb504 is 0x7ffea810 and thus also representable in int, no overflow.
0xb505ULL * 0xb505ULL is 0x80001219ULL,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009
Andrew Pinski changed:
What|Removed |Added
Target|powerpc*-*-*|powerpc*-*-*, aarch64-*-*
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 148 matches
Mail list logo
