https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79932
--- Comment #2 from Jakub Jelinek ---
Created attachment 40905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40905&action=edit
gcc7-pr79932-2.patch
Found further 64 intrinsics that weren't available at -O0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79931
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79901
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 7 08:04:38 2017
New Revision: 245946
URL: https://gcc.gnu.org/viewcvs?rev=245946&root=gcc&view=rev
Log:
PR rtl-optimization/79901
* expr.c (expand_expr_real_2): F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79901
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 7 08:11:30 2017
New Revision: 245947
URL: https://gcc.gnu.org/viewcvs?rev=245947&root=gcc&view=rev
Log:
PR rtl-optimization/79901
* config/i386/sse.md (*avx512bw_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915
--- Comment #2 from Jan Smets ---
Reduced test case, only occurs on the vxworks port, not on linux.
namespace a {
template class c;
class d {
public:
virtual ~d();
};
template class e : d {};
template class c : virtual e {};
class g : c {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935
--- Comment #1 from Richard Biener ---
Sounds like a bug in the dynamic loader then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79934
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79901
--- Comment #5 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #5 from Jakub Jelinek ---
Does Darwin have so ridiculously low stack size limits by default, or is that
just some setting you've done?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79920
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728
--- Comment #5 from Xi Ruoyao ---
(In reply to Bernd Schmidt from comment #4)
> Actually here's mine from last week:
> https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00176.html
So please ignore my mumble...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937
Bug ID: 79937
Summary: ICE in replace_placeholders_r
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862
Sumit changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862
--- Comment #9 from Andrew Pinski ---
Looks like the stdint.h is not defining all the needed types ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79855
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Mar 7 09:36:44 2017
New Revision: 245948
URL: https://gcc.gnu.org/viewcvs?rev=245948&root=gcc&view=rev
Log:
PR c/79855: add full stop to store merging param descripti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79855
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
Bug ID: 79938
Summary: gcc unnecessarily spills xmm register to stack when
inserting vector items
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
mpf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
mpf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||7.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012
mpf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #6 from Dominique d'Humieres ---
> Does Darwin have so ridiculously low stack size limits by default,
> or is that just some setting you've done?
On darwin1(0|6) ulimit gives
stack size (kbytes, -s) 65532
and the envir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79914
mpf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79473
mpf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904
--- Comment #5 from Jakub Jelinek ---
Created attachment 40907
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40907&action=edit
gcc7-pr79904.patch
Untested optimization that fixes the original testcase, but doesn't the one
without uniform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
mpf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #7 from Jakub Jelinek ---
stack size (kbytes, -s) 65532
is 64M, that should be more than enough. Of course unless darwin
pthread_create does something dumb, like using far smaller stack sizes for
threads by default.
In t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862
--- Comment #10 from Jonathan Wakely ---
Libstdc++ should handle those types being missing, but it doesn't do so
correctly.
Try making the inclusion of conditional:
--- include/std/future
+++ include/std/future
@@ -40,7 +40,9 @@
#include
#i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862
--- Comment #11 from Jonathan Wakely ---
(In reply to Sumit from comment #2)
> I understand that 4.8.1 is no longer supported.
> Actually, our project in current state can't move to any version beyond
> 4.8.1 for some maintainability reasons.
No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862
--- Comment #12 from Jonathan Wakely ---
Created attachment 40908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40908&action=edit
Make atomic depend on _GLIBCXX_USE_C99_STDINT_TR1
Here's a patch for trunk, which I'll commit after GCC 7 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79919
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79896
Jakub Jelinek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |error-recovery
Target|arm-li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915
Jan Smets changed:
What|Removed |Added
Target|mips|mips64-linux-gnuabi64
Summary|ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915
--- Comment #4 from Jan Smets ---
Created attachment 40910
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40910&action=edit
testcase pr79951
mips64-linux-gnuabi64-gcc -xc++ pr79951.i -o /dev/null -S -mlong-calls
-mno-abicalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79896
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79899
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #5 from mpf at gcc dot gnu.org ---
I think there are some relatively serious issues in the riscv backend here.
What I understand so far:
1) Only floating point modes are allowed in FPRs
2) There is an alternative in the movqi_intern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
--- Comment #1 from Richard Biener ---
The situation is slightly better with GCC 7, only two spill/loads are
remaining.
Possibly BIT_INSERT_EXPR helps here. For the testcase you want to add
__attribute__((noinline)) to haddd_epu8 as otherwise el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79347
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79939
Bug ID: 79939
Summary: [nvptx] gcc hangs in nvptx_assemble_value
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79939
--- Comment #1 from Tom de Vries ---
With -O2 at .optimized, we have for gomp4:
...
main (int argc, char * * argv)
{
v4si x;
int _2;
:
_2 = MEM[(int *)&x + 16B];
x ={v} {CLOBBER};
return _2;
}
...
and for mainline:
...
main (int ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #6 from Kito Cheng ---
Hi Matthew:
Thanks for you feedback, I will disuses with other RISC-V maintainer for the
GPR <-> FPR issue, however it's still hang on LRA for pr52750.c when use soft
float[1] and work if revert r245655 too, do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891
Martin Liška changed:
What|Removed |Added
CC||hubicka at ucw dot cz
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270
--- Comment #5 from Martin Liška ---
Author: marxin
Date: Tue Mar 7 14:12:52 2017
New Revision: 245951
URL: https://gcc.gnu.org/viewcvs?rev=245951&root=gcc&view=rev
Log:
Use array_at_struct_end_p in tree-chkp.c (PR middle-end/68270).
2017-03-0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155
--- Comment #8 from Segher Boessenkool ---
*** Bug 69034 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69034
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
--- Comment #2 from postmaster at raasu dot org ---
(In reply to Richard Biener from comment #1)
> The situation is slightly better with GCC 7, only two spill/loads are
> remaining.
> Possibly BIT_INSERT_EXPR helps here.
With gcc 6.2.0 and
gcc -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #7 from mpf at gcc dot gnu.org ---
The same fix will resolve soft-float as well I think. In the soft-float case I
believe it is reasonably logical that preferred_reload_class is wrong as there
are no registers in FPR_REGS available at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79834
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270
Martin Liška changed:
What|Removed |Added
Known to work||7.0
--- Comment #6 from Martin Liška ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #8 from Kito Cheng ---
Hi Matthew:
Oh, my fault, I just go another way[1] to fix this issue, but I got worse code
gen for both hard-float and soft-float after r245655, before.*.s is generate by
gcc with revert r245655, *rv32imafd.s fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67520
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530
Bug 65530 depends on bug 67520, which changed state.
Bug 67520 Summary: libmpx should abort() instead of exit(255) on bound
violation detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67520
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #9 from Kito Cheng ---
Code gen in previous comment is output for riscv32-unknown-linux-gnu-gcc
pr52750.c -S
ARM got worse code gen too:
configure: --target=arm-eabi
$ arm-eabi-gcc pr52750.c -S
For pr52750.c:
$ diff before.arm.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78339
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78631
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79762
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79415
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=65530
Bug 65530 depends on bug 79762, which changed state.
Bug 79762 Summary: [6/7 Regression][CHKP] ICE in verify_cgraph_node failed
(node is weakref but not an transparent_alias)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79762
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
--- Comment #3 from postmaster at raasu dot org ---
With -mssse3 instead of -msse4.1, the issue gets even worse:
---
...
pxor%xmm1, %xmm1
movl$.LC0, %esi
movl$1, %edi
movd%eax, %xmm0
movdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #10 from mpf at gcc dot gnu.org ---
(In reply to Kito Cheng from comment #8)
> [1]
> diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
> index 89567f7..148967b 100644
> --- a/gcc/config/riscv/riscv.c
> +++ b/gcc/config/r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79940
Bug ID: 79940
Summary: OpenMP pragma - internal compiler error with taskloop
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79940
Aidan Chalk changed:
What|Removed |Added
CC||aidan.chalk at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79910
--- Comment #4 from Bernd Schmidt ---
(In reply to Zdenek Sojka from comment #0)
> Trying 27, 28 -> 33:
> ...
> Successfully matched this instruction:
> (set (reg:QI 128 [ _6 ])
> (plus:QI (subreg:QI (reg:DI 111 [ p1D.1798 ]) 0)
> (su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79941
Bug ID: 79941
Summary: [7 Regression] Altivec vec_vmuleub regression
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79941
Jakub Jelinek changed:
What|Removed |Added
Target||powerpc*-*
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77730
PeteVine changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79845
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79940
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79941
Bill Schmidt changed:
What|Removed |Added
CC||willschm at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #3 from DJ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79942
Bug ID: 79942
Summary: Wrong declaration of __builtin_cpu_init
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #8 from Thomas Koenig ---
I have read people complaining about very low OMP stack sizes
on OSX.
Should we set this to a more reasonable default value in libgfortran?
Less than 800k is quite ridiculous.
Alternatively, is there a way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79623
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79484
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79888
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79943
Bug ID: 79943
Summary: Loop splitting breaks with loops of pointer type
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: critical
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79809
--- Comment #9 from Marek Polacek ---
Author: mpolacek
Date: Tue Mar 7 17:30:53 2017
New Revision: 245955
URL: https://gcc.gnu.org/viewcvs?rev=245955&root=gcc&view=rev
Log:
PR middle-end/79809
* gimple-ssa-warn-alloca.c (pass_wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79809
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79796
--- Comment #8 from Marek Polacek ---
Author: mpolacek
Date: Tue Mar 7 17:42:30 2017
New Revision: 245957
URL: https://gcc.gnu.org/viewcvs?rev=245957&root=gcc&view=rev
Log:
PR c++/79796 - ICE with NSDMI and this pointer
* call.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #9 from Dominique d'Humieres ---
> I have read people complaining about very low OMP stack sizes
> on OSX.
What is setting the limit?
> Should we set this to a more reasonable default value in libgfortran?
> Less than 800k is quite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79796
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72783
felix changed:
What|Removed |Added
CC||felix.von.s at posteo dot de
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #11 from Eric Botcazou ---
> I recommend that on balance for all targets the current behavior is a
> reasonable compromise. I have said elsewhere that I am happy to continue
> working in this area and would welcome any further help to
40915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40915&action=edit
reproducer
Reduced from kernel miscompilation, but reproduces with user-space asan as
well.
gcc version 7.0.1 20170307 (experimental) (GCC)
Last Changed Rev: 245952
Last Changed Date: 2017-03-07 15:13:10 +0100 (Tue,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79785
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
--- Comment #1 from Jakub Jelinek ---
I'll have a look tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79945
Bug ID: 79945
Summary: ppc64le Default_Bit_Order in Ada
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assi
1 - 100 of 162 matches
Mail list logo
