https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #11 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Dec 27 08:59:04 2016
New Revision: 243933
URL: https://gcc.gnu.org/viewcvs?rev=243933&root=gcc&view=rev
Log:
PR target/78904
* config/i386/i386.md (*cmpqi_ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78923
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78924
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78928
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78913
--- Comment #3 from Martin Liška ---
Well, I understand that char[x] can potentially be at most x-1 characters long.
On the other hand, it's quite common case where one uses a temporary buffer
(reasonable big) which is used by sprintf-family func
c-trunk --with-languages=c,cpp
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion :
(reconfigured) ../src/gcc-trunk/configure --prefix=/opt/gcc-trunk
--with-languages=c,cpp --enable-languages=c,c++,fortran,lto,objc --no-create
--no-recursion
Thread model: posix
gcc version 7.0.0 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78931
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78932
Bug ID: 78932
Summary: [ARM] -O2 generates wrong code
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78931
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78933
Bug ID: 78933
Summary: ICE: in decode_cmdline_option, at opts-common.c:671
with -fno-strong-eval-order
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270
Alexander Ivchenko changed:
What|Removed |Added
CC||aivchenk at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65705
Alexander Ivchenko changed:
What|Removed |Added
CC||aivchenk at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78933
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Dec 27 14:20:19 2016
New Revision: 243937
URL: https://gcc.gnu.org/viewcvs?rev=243937&root=gcc&view=rev
Log:
PR target/78904
* config/i386/constraints.md (Bc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78933
--- Comment #2 from Martin Liška ---
Created attachment 40415
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40415&action=edit
Untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78922
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 27 14:41:04 2016
New Revision: 243938
URL: https://gcc.gnu.org/viewcvs?rev=243938&root=gcc&view=rev
Log:
PR translation/78922
* config/i386/stringop.opt: Remove.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78922
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 27 14:45:24 2016
New Revision: 243939
URL: https://gcc.gnu.org/viewcvs?rev=243939&root=gcc&view=rev
Log:
2016-12-27 Jakub Jelinek
PR translation/78922
* config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78922
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 27 14:49:08 2016
New Revision: 243940
URL: https://gcc.gnu.org/viewcvs?rev=243940&root=gcc&view=rev
Log:
PR translation/78922
* config/i386/stringop.opt: Remove.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78922
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78925
--- Comment #2 from Jonathan Wakely ---
This is the same problem as described in PR 54376 and we decided GCC, EDG, and
MSVC were right to reject the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78631
Alexander Ivchenko changed:
What|Removed |Added
CC||aivchenk at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68725
--- Comment #3 from Lukas Wunner ---
(In reply to Andrew Pinski from comment #2)
> I think this has now been fixed on the trunk. There is a pass which combines
> stores for constants.
No, unfortunately this is not fixed in trunk.
You're right t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
Arjan van de Ven changed:
What|Removed |Added
Version|6.1.1 |6.3.0
--- Comment #6 from Arjan van d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #7 from Arjan van de Ven ---
Created attachment 40416
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40416&action=edit
prototype patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #8 from Arjan van de Ven ---
Created attachment 40417
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40417&action=edit
refined test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #9 from Arjan van de Ven ---
Created attachment 40418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40418&action=edit
Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #10 from Arjan van de Ven ---
Created attachment 40419
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40419&action=edit
generated ASM with vectorization (no patch / no fast-math)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #11 from Arjan van de Ven ---
Created attachment 40420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40420&action=edit
generated ASM with vectorization and fast-math (no patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #12 from Arjan van de Ven ---
Created attachment 40421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40421&action=edit
generated ASM without vectorization (no patch / no fast-math)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #13 from Arjan van de Ven ---
Created attachment 40422
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40422&action=edit
generated ASM with vectorization (with patch / no fast-math)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #14 from Andrew Pinski ---
So MIN_EXPR/MAX_EXPR is not safe due to NaNs. There was some work on adding an
IEEE MIN_EXPR/MAX_EXPR which is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #15 from Andrew Pinski ---
Read https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00693.html also. There is
much more to that thread than just in August IIRC. Some in September and in
October too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #16 from Arjan van de Ven ---
A comparable (but optimized to generate smaller asm) testcase is this:
#include
void RELU(float *buffer, int size)
{
float *ptr = (float *) __builtin_assume_aligned(buffer, 64);
int i;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #17 from Arjan van de Ven ---
(In reply to Andrew Pinski from comment #15)
> Read https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00693.html also. There
> is much more to that thread than just in August IIRC. Some in September and
> i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78934
Bug ID: 78934
Summary: long double%intmax_t errors, long double%double
errors.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78934
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78934
--- Comment #2 from Andrew Pinski ---
There is a function call modf which you want to use here really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #18 from Andrew Pinski ---
(In reply to Arjan van de Ven from comment #17)
> (In reply to Andrew Pinski from comment #15)
> > Read https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00693.html also. There
> > is much more to that thread t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71921
--- Comment #19 from Arjan van de Ven ---
> GCC is not just about x86.
I know that, which is why I know my patch is not correct, but more of a precise
bug report... clearly this need to be done in a way that does not hurt other
architectures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78934
Jim Michaels changed:
What|Removed |Added
Target||x86-w32-mingw32
Host|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78935
Bug ID: 78935
Summary: ICE on allocating derived type coarray with
allocatable components
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78934
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78935
--- Comment #1 from Damian Rouson ---
Workaround (4) in the original submission is mistakenly redundant. It's an
interestingly fragile ICE that disappears with seemingly minor changes to the
code. For example, it also disappears if the first al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78936
Bug ID: 78936
Summary: Interprocedural constant propagation miscompiles C++
methods on i686 Windows
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78937
Bug ID: 78937
Summary: New data.rel.ro.local section in TW's gcc
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: transla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78937
--- Comment #1 from Andrew Pinski ---
Looks like the newer GCC 6.2.1 defaults to -fPIE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78937
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78937
--- Comment #3 from Jan Engelhardt ---
Now that you mention it, I have a PIE-by-default extension installed on that
one (/usr/lib64/gcc/x86_64-suse-linux/6/defaults.spec file). Thanks for
clearing that up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78934
--- Comment #5 from Jonathan Wakely ---
(In reply to Jim Michaels from comment #0)
> this is surely not according to spec.
Wrong again.
"The operands of * and / shall have arithmetic or unscoped enumeration type;
the operands of % shall have in
49 matches
Mail list logo