https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78908
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879
--- Comment #11 from Yuan Pengfei ---
It seems that if a variable has two or more constant values, gcc does not treat
it as a constant and b_c_p returns 0. Is that correct?
If so, I might have figured out where the problem is.
With unordered_re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78893
--- Comment #3 from William Bader ---
Thanks! Increasing the allocated memory fixed the problem, and the gcc build
completed. Regards, William
$ /usr/bin/free -h
totalusedfree shared buff/cache available
Mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78909
Bug ID: 78909
Summary: local variables unavailable in constructor under
Oracle dbx
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58114
--- Comment #7 from Jonathan Wakely ---
(In reply to Chris Wilson from comment #6)
> I disagree with the assessment of this bug as a duplicate of bug 43452. That
> bug was resolved by the creation of the -Wdelete-incomplete option, upon
> which t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
--- Comment #12 from Jakub Jelinek ---
Created attachment 40407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40407&action=edit
gcc7-pr78901-1.patch
Untested fix. With this snprintf in -std=c++11 and above will be actually
noexcept even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879
Yuan Pengfei changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73550
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78496
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58114
Chris Wilson changed:
What|Removed |Added
CC||chris+gccbugzilla at qwirx dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78908
Bug ID: 78908
Summary: lto1: internal compiler error: in lto_read_decls, at
lto/lto.c:1814
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78907
--- Comment #2 from hr.jonas.hansen at gmail dot com ---
This is not an issue with g++ 5.2.1, did the default stack size change?
There is actually no need for using 65536 even -fconstexpr-depth=26000 will
ensure the crash, on my computer.
How do I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #7 from Segher Boessenkool ---
Ah, "high byte" registers are never a separate register in the i386
backend, I see.
combine would need to combine four insns to arrive at your current
pattern, but it doesn't try because it thinks they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78907
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
--- Comment #9 from Jakub Jelinek ---
Actually, it seems similarly declared strlen, strchr or sprintf are all
nothrow, so there might be some bug with handling C99 builtins in C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #6 from Uroš Bizjak ---
A better testcase:
--cut here--
struct S1
{
char pad1;
unsigned char val;
short pad2;
};
struct S1 test (struct S1 a, struct S1 b)
{
a.val += b.val;
return a;
}
--cut here--
compiles with -O2 to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78907
Bug ID: 78907
Summary: internal compiler error segmentation fault with
recursive constexpr
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78496
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #5 from Uroš Bizjak ---
Created attachment 40405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40405&action=edit
Prototype patch for addqi_ext_[1,2] patterns
The prototype patch compiles the testcase to:
movl%edi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78856
--- Comment #5 from Jeffrey A. Law ---
So what appears to be happening is we have two loops, one natural, and an inner
irreducible loop.
We have a potential jump thread that starts on outside the outer loop and
targets a block that is in the irr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #4 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > No, unfortunately the above is not a valid x86 insn. x86 has two-operand
> > instructions, so output has to match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119
Bug 51119 depends on bug 66189, which changed state.
Bug 66189 Summary: Block loops for inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66189
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66189
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
Bug 37131 depends on bug 66189, which changed state.
Bug 66189 Summary: Block loops for inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66189
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78239
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78906
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Thu Dec 22 20:29:07 2016
New Revision: 243897
URL: https://gcc.gnu.org/viewcvs?rev=243897&root=gcc&view=rev
Log:
PR c++/78906 - ICE with member variable template
* pt.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78239
--- Comment #12 from Thomas Koenig ---
Author: tkoenig
Date: Thu Dec 22 20:27:52 2016
New Revision: 243895
URL: https://gcc.gnu.org/viewcvs?rev=243895&root=gcc&view=rev
Log:
2016-12-22 Thomas Koenig
Backport from trunk
PR for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #3 from Segher Boessenkool ---
(In reply to Uroš Bizjak from comment #2)
> No, unfortunately the above is not a valid x86 insn. x86 has two-operand
> instructions, so output has to match one of the operands.
But these are pseudos.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #2 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #1)
> ===
> Trying 10, 9 -> 11:
> Failed to match this instruction:
> (parallel [
> (set (reg:QI 88 [ _2 ])
> (plus:QI (subreg:QI (zero_extract:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
--- Comment #8 from Jakub Jelinek ---
Created attachment 40404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40404&action=edit
gcc7-pr78901.patch
There are multiple issues, this patch hopefully fixes just one of them - the
case when the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78856
--- Comment #4 from Jeffrey A. Law ---
I can't prove it yet, but I suspect this is another case where transformations
have collapsed loops and invalidated the cached iteration information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #3 from Jerry DeLisle ---
(In reply to janus from comment #2)
> (In reply to janus from comment #0)
> > It seems like the first character is being swallowed somewhere ...
>
> Moreover the EOF is supposed to be an EOR?
I will start l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216
--- Comment #10 from Segher Boessenkool ---
(In reply to Rin Okuyama from comment #9)
> > > However, I have a question on this fix. How about the case where
> > > "-Wa,-mXXX" option is given without "-mcpu=YYY" option specified?
> >
> > That mig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899
Jakub Jelinek changed:
What|Removed |Added
Attachment #40402|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
--- Comment #7 from Martin Sebor ---
Here's a smaller test case:
$ cat t.C && gcc -O1 -S -Wall t.C
extern "C" int snprintf (char *, __SIZE_TYPE__, const char *, ...);
int foo ()
{
try {
return snprintf (0, 0, "");
} catch (...) { }
}
t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78906
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78856
--- Comment #3 from Jeffrey A. Law ---
Mostly to record my thoughts...
Loop unrolling inserts a __builtin_unreachable as part of unrolling one of the
loops. DOM3 looks at the first 10 or so blocks determines they all have a
statically determine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78906
Ville Voutilainen changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78906
Bug ID: 78906
Summary: ICE with a member variable template whose type is a
decltype of a member variable template of a class
template
Product: gcc
Version: 7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
--- Comment #4 from Matt Clarkson ---
That's OK. I'm not particularly looking for the macro to be backported to 4.9.
Just as we move forward the new macro is available. If not it's not the end of
the world I can always maintain the snippet intern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
--- Comment #6 from Martin Sebor ---
(In reply to Markus Trippelsdorf from comment #5)
> This is what creduce finally came up with:
Thanks for the test case. The ICE goes away if the snprintf declaration is
declared throw() or attribute nothro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
Bug ID: 78905
Summary: Add a macro to determine that the library is
implemented
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
--- Comment #2 from Matt Clarkson ---
Because wehen I compile with clang against the libstdc++ the problem will still
occur and __GNUC__ will not be defined. This happens on any distro where GCC is
the default but ships clang as an alternative co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
--- Comment #1 from Andrew Pinski ---
Why don't you use:
__GNUC__ >=5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9)
instead for checking GCC version?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
--- Comment #9 from Jakub Jelinek ---
(In reply to Martin Liška from comment #7)
> > I also think warning on malloc(0) can be useful. GCC 7 has -Walloc-zero
> > that warns on all zero-size allocations. Unfortunately, it's not in -Wall
> > or -W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
--- Comment #8 from rguenther at suse dot de ---
On December 22, 2016 5:36:56 PM GMT+01:00, "msebor at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
>
>Martin Sebor changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
--- Comment #7 from Martin Liška ---
(In reply to Martin Sebor from comment #6)
> Warning on malloc with an unused return value sounds like a good idea to me
> (in fact, it seems that all allocation functions to be declared with
> warn_unused_res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745
--- Comment #4 from Frederic Marchal ---
More multi-line descriptions in gcc/config/i386/i386.opt at line 567, 577, 844.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71474
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78239
--- Comment #11 from Thomas Koenig ---
Author: tkoenig
Date: Thu Dec 22 17:05:13 2016
New Revision: 243891
URL: https://gcc.gnu.org/viewcvs?rev=243891&root=gcc&view=rev
Log:
2016-12-22 Thomas Koenig
Backport from trunk
PR for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754
--- Comment #10 from Jakub Jelinek ---
Perhaps doing it in grokdeclarator where build_function_type is called, if
initialized == false? But it is unclear to me where all the side-effects can
hide. E.g.
int fn3();
void fn4(int (*)[fn3 ()][fn3 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754
--- Comment #9 from Jakub Jelinek ---
Though, it seems they can be hiding pretty much everywhere:
int fn3();
void (**fn5) (int[][fn3 ()]);
void fn1 () {
int a[10][fn3 ()];
(**fn5) (a);
}
ICEs with -O2 -flto, so does:
int fn3();
typedef void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
Martin Liška changed:
What|Removed |Added
Attachment #40399|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78903
--- Comment #2 from chrysn at fsfe dot org ---
I don't care about the function being inlined in general, I just don't want it
inlined into different sections -- that's why I'd consider noinline a
workaround.
Anyhow, if that is the definite answer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66681
--- Comment #9 from Damian Rouson ---
I wonder if this is related to pr78892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78898
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42329
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Thu Dec 22 15:19:54 2016
New Revision: 243890
URL: https://gcc.gnu.org/viewcvs?rev=243890&root=gcc&view=rev
Log:
PR c++/78898 - ICE on constructor with TTP
PR c++/42329
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78898
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Thu Dec 22 15:19:54 2016
New Revision: 243890
URL: https://gcc.gnu.org/viewcvs?rev=243890&root=gcc&view=rev
Log:
PR c++/78898 - ICE on constructor with TTP
PR c++/42329
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
Bug ID: 78904
Summary: zero-extracts are not effective
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #14 from Georg-Johann Lay ---
Author: gjl
Date: Thu Dec 22 15:02:43 2016
New Revision: 243889
URL: https://gcc.gnu.org/viewcvs?rev=243889&root=gcc&view=rev
Log:
gcc/testsuite/
PR testsuite/52641
* gcc.dg/fold-and-rshi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78898
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78903
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
--- Comment #4 from Marc Glisse ---
(In reply to Martin Liška from comment #3)
> Yep, it's strange, should be p = NULL. As mentioned in MAN page:
> If size is 0, then malloc() returns either NULL, or a unique pointer value
> that can later be suc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
--- Comment #3 from Martin Liška ---
(In reply to Marc Glisse from comment #2)
> The p=malloc(0) transformation looks strange.
> (I never know if we are supposed to unlink_stmt_vdef, etc)
Yep, it's strange, should be p = NULL. As mentioned in MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
--- Comment #2 from Marc Glisse ---
The p=malloc(0) transformation looks strange.
(I never know if we are supposed to unlink_stmt_vdef, etc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78903
Bug ID: 78903
Summary: __attribute__((section(".ram"))) ignored with -Os or
-flto
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
--- Comment #1 from Martin Liška ---
Created attachment 40399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40399&action=edit
Patch candidate
Would be such change acceptable in GCC 7, or should be wait for GCC 8?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78886
--- Comment #9 from Martin Liška ---
(In reply to Marc Glisse from comment #8)
> (In reply to Jakub Jelinek from comment #5)
> > I'd say tree-ssa-strlen.c is not the pass that should remove the malloc.
>
> We probably want another PR about this,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
Bug ID: 78902
Summary: Missed malloc optimizations: malloc w/ LHS and zero
argument
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78886
--- Comment #8 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #5)
> I'd say tree-ssa-strlen.c is not the pass that should remove the malloc.
We probably want another PR about this, because a malloc whose return value is
ignored sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68887
--- Comment #11 from Dominique d'Humieres ---
If the tests are compiled on darwin with an instrumented gfortran, execution
gives
==82783==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200150 at pc 0x000101b79d39 bp 0x7fff5e0a6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78886
Martin Liška changed:
What|Removed |Added
Summary|[5/6/7 Regression] |[5/6 Regression]
|Segme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78886
--- Comment #6 from Martin Liška ---
Author: marxin
Date: Thu Dec 22 13:09:11 2016
New Revision: 243886
URL: https://gcc.gnu.org/viewcvs?rev=243886&root=gcc&view=rev
Log:
Fix tree-optimization/78886.
PR tree-optimization/78886
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
--- Comment #2 from h2+bugs at fsfe dot org ---
Created attachment 40398
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40398&action=edit
intermediate file for test_random
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
--- Comment #1 from h2+bugs at fsfe dot org ---
Created attachment 40397
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40397&action=edit
intermediate file for test_blast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
Bug ID: 78901
Summary: internal compiler error: verify_gimple failed
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78900
Bug ID: 78900
Summary: ICE in gcc.target/powerpc/signbit-3.c
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |5.5
Summary|ICE in create_tmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #13 from Georg-Johann Lay ---
Author: gjl
Date: Thu Dec 22 12:42:35 2016
New Revision: 243885
URL: https://gcc.gnu.org/viewcvs?rev=243885&root=gcc&view=rev
Log:
gcc/testsuite/
PR testsuite/52641
* gcc.dg/pr35258.c (ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899
Bug ID: 78899
Summary: [7 Regression] Vestorized loop with optmized mask
stores motion is completely deleted after r242520.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #7 from YunQiang Su ---
(In reply to YunQiang Su from comment #6)
> With revert some change, with patch:
>
> Index: gcc-7-7-20161217/src/gcc/combine.c
> ===
> --- gcc-7-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
YunQiang Su changed:
What|Removed |Added
CC||syq at debian dot org
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663
--- Comment #2 from Jakub Jelinek ---
This probably needs to go to upstream compiler-rt first. Also, it would be
cleaner not to define SI_MEMMEM to 1 on Windows and move the comment there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78859
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78858
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78858
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Thu Dec 22 11:48:39 2016
New Revision: 243884
URL: https://gcc.gnu.org/viewcvs?rev=243884&root=gcc&view=rev
Log:
PR middle-end/78858
* c-c++-common/ubsan/pr78858.c: New te
1 - 100 of 118 matches
Mail list logo
