https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159
wipedout at yandex dot ru changed:
What|Removed |Added
CC||wipedout at yandex dot ru
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683
Bug ID: 69683
Summary: multiline raw string R"()" for C++11 warning in false
#ifdef when -std=c++98
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: majo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #10 from H.J. Lu ---
Created attachment 37589
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37589&action=edit
A different patch
I am testing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67461
--- Comment #2 from Peter Cordes ---
(In reply to Andrew Pinski from comment #1)
> Hmm, I think there needs to be a barrier between each store as each store
> needs to be observed by the other threads.
On x86, stores are already ordered wrt. oth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #9 from H.J. Lu ---
Another problem. STV is disabled even when stack is aligned:
[hjl@gnu-skl-1 pr69677]$ cat x.i
struct bar
{
int i[16] __attribute__ ((aligned(16)));
};
extern void fn2 (void);
long long a, b;
struct bar
fn1 (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682
--- Comment #2 from Mike Liang ---
Created attachment 37588
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37588&action=edit
run tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682
--- Comment #1 from Mike Liang ---
Created attachment 37587
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37587&action=edit
Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682
Bug ID: 69682
Summary: expression (a && (b==c)) with side effects rewritten
to ((b==c) & a)
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
--- Comment #3 from Patrick Palka ---
(In reply to Andrew Pinski from comment #2)
> I don't think "(int)(&foo != &bar)" is a valid constant integer expression
> in either C or C++. (definitely not in C). This is why GCC rejects it.
Oops, good p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
--- Comment #2 from Andrew Pinski ---
I don't think "(int)(&foo != &bar)" is a valid constant integer expression in
either C or C++. (definitely not in C). This is why GCC rejects it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
--- Comment #1 from Patrick Palka ---
(Sorry about the typos in the original comment. To fix them,
s/since both foo and bar/since both foo and bar are/
s/when comparing and pointers/when comparing pointers/
s/the subsequent declarations/then su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
Bug ID: 69681
Summary: C/C++ FEs do not consider comparisons of distinct
function pointers to be constant expressions
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3920
Martin Sebor changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69350
--- Comment #1 from Jonathan Wakely ---
The simplest solution might be something like:
--- a/libstdc++-v3/include/c_global/cmath
+++ b/libstdc++-v3/include/c_global/cmath
@@ -840,7 +840,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return __built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69626
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69626
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Thu Feb 4 23:47:21 2016
New Revision: 233161
URL: https://gcc.gnu.org/viewcvs?rev=233161&root=gcc&view=rev
Log:
Test for C99 stdlib.h functions with -std=c++98
PR libstdc++/696
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69680
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69680
--- Comment #1 from Jonathan Wakely ---
(In reply to Jeff Hammond from comment #0)
> It seems that none of the GCC 5.3.0 headers declare this function...
Because GCC doesn't provide a C library, it uses the one from your OS.
Presumably it doesn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69680
Bug ID: 69680
Summary: stdlib.h does not declare aligned_alloc
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 4 23:16:44 2016
New Revision: 233160
URL: https://gcc.gnu.org/viewcvs?rev=233160&root=gcc&view=rev
Log:
combine: distribute_notes again (PR69567, PR64682)
As it happens th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64682
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 4 23:16:44 2016
New Revision: 233160
URL: https://gcc.gnu.org/viewcvs?rev=233160&root=gcc&view=rev
Log:
combine: distribute_notes again (PR69567, PR64682)
As it happens th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64682
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 4 23:09:51 2016
New Revision: 233159
URL: https://gcc.gnu.org/viewcvs?rev=233159&root=gcc&view=rev
Log:
combine: distribute_notes again (PR69567, PR64682)
As it happens th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
--- Comment #5 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 4 23:09:51 2016
New Revision: 233159
URL: https://gcc.gnu.org/viewcvs?rev=233159&root=gcc&view=rev
Log:
combine: distribute_notes again (PR69567, PR64682)
As it happens th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #10 from vries at gcc dot gnu.org ---
Created attachment 37585
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37585&action=edit
tentative patch
(In reply to iverbin from comment #9)
> (In reply to vries from comment #8)
> > (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69664
--- Comment #4 from David Malcolm ---
Candidate patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00372.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29815
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
Jakub Jelinek changed:
What|Removed |Added
Summary|[5/6 Regression] ICE with |[5 Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 4 22:17:05 2016
New Revision: 233154
URL: https://gcc.gnu.org/viewcvs?rev=233154&root=gcc&view=rev
Log:
PR c/69669
* c-decl.c (finish_enum): When honoring mode at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #26 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 4 22:15:33 2016
New Revision: 233153
URL: https://gcc.gnu.org/viewcvs?rev=233153&root=gcc&view=rev
Log:
PR fortran/69368
* tree-dfa.c (get_ref_base_and_extent):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68124
--- Comment #13 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb 4 22:10:56 2016
New Revision: 233152
URL: https://gcc.gnu.org/viewcvs?rev=233152&root=gcc&view=rev
Log:
PR rtl-optimization/69577
Revert:
2015-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
--- Comment #45 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb 4 22:10:56 2016
New Revision: 233152
URL: https://gcc.gnu.org/viewcvs?rev=233152&root=gcc&view=rev
Log:
PR rtl-optimization/69577
Revert:
2015-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577
--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb 4 22:10:56 2016
New Revision: 233152
URL: https://gcc.gnu.org/viewcvs?rev=233152&root=gcc&view=rev
Log:
PR rtl-optimization/69577
Revert:
2015-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69146
Alan Modra changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582
Jeffrey A. Law changed:
What|Removed |Added
Depends on||69024, 69021, 69017
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #8 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 37584 [details]
> gcc6-pr69677.patch
>
> I'm currently bootstrapping/regtesting --with-arch=corei7 --with-cpu=corei7
> --with-fpmath=sse i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51837
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69611
Andreas Tobler changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #6 from H.J. Lu ---
STV turns:
insn 21 19 23 4 (parallel [
(set (reg:DI 102 [ val ])
(and:DI (reg/v:DI 97 [ val ])
(mem/u:DI (plus:SI (mult:SI (reg/v:SI 96 [ mode ])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #11 from Michael Meissner ---
Author: meissner
Date: Thu Feb 4 21:05:14 2016
New Revision: 233147
URL: https://gcc.gnu.org/viewcvs?rev=233147&root=gcc&view=rev
Log:
[gcc]
2016-02-04 Michael Meissner
PR target/69667
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #5 from Jakub Jelinek ---
Ah, I see, simplify-rtx.c is miscompiled.
So, it could be just the
convert_scalars_to_vector
hunk of the patch, because STV is clearly enabled in there.
If we have guaranteed that both preferred and incoming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69678
Bug ID: 69678
Summary: Missed function specialization + partial
devirtualization opportunity
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
--- Comment #4 from Bernd Edlinger ---
it is pretty much completely broken also long before gcc-5:
typedef enum __attribute__((mode(QI))) e
{
e1 = 1,
e2 = 2
} ee;
ee x;
int y;
int test()
{
y=sizeof(x);
return x == e1;
}
in "C" sizeof(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69662
--- Comment #2 from Martin Sebor ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00355.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69676
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #4 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #3)
> x86_64 gcc doesn't ICE on this with -m32 -O2 -march=corei7 -mtune=corei7
> -mfpmath=sse, nor i686-linux one.
x86_64 gcc doesn't use STV.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #9 from Michael Meissner ---
Created attachment 37582
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37582&action=edit
Proposed patch to fix the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
--- Comment #10 from amker at gcc dot gnu.org ---
This is an ivopt bug all the time. As designed, ivopt tries to identify and
reuse induction variables in the original input. Apparently we don't need to
compute such original biv with new code be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #10 from Michael Meissner ---
I agree it is better to use the right constraints, but it can be easy to
overlook things, especially since reload didn't raise an error.
Particularly when you are using the various iterators and attribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
iverbin at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Uroš Bizjak changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #8 from Vladimir Makarov ---
(In reply to Michael Meissner from comment #7)
> The error is LRA requires that every register that a constraint targets be a
> valid register for the mode. In this case, the 3 move insns that target
> TF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #1 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #0)
...
>0x086ffe29 <+25>: mov%ecx,(%esp)
>0x086ffe2c <+28>: mov%ebx,0x4(%esp)
...
> => 0x086ffe63 <+83>: movdqa (%esp),%xmm2
...
> (gdb) p $esp
> $1 = (vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Bug ID: 69677
Summary: [6 Regression] bootstrap failed with
--with-arch=corei7 --with-cpu=corei7
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69676
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |6.0
Summary|[4.9 Regression] Many
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69676
Bug ID: 69676
Summary: [4.9 Regression] Many AVX512 test failures
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
Michael Meissner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #8 from vries at gcc dot gnu.org ---
(In reply to iverbin from comment #7)
> I believe we should drop support of offloading without linker plugin.
Same failures occur with -fuse-linker-plugin though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #7 from iverbin at gcc dot gnu.org ---
I believe we should drop support of offloading without linker plugin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
vries at gcc dot gnu.org changed:
What|Removed |Added
Keywords||openmp
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619
--- Comment #6 from wilco at gcc dot gnu.org ---
Author: wilco
Date: Thu Feb 4 18:23:35 2016
New Revision: 233145
URL: https://gcc.gnu.org/viewcvs?rev=233145&root=gcc&view=rev
Log:
This patch fixes an exponential issue in ccmp.c. When deciding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284
--- Comment #4 from Gerhard Steinmetz
---
As known, causative is the class declaration of "a", when using size(a).
Some variants, replacing "class" with "type" :
$ cat z2.f90
module m
type t
end type
contains
function foo(a, b) result(ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659
--- Comment #4 from Gerhard Steinmetz
---
Another test scheme :
$ cat z4.f90
module m
type t
class(*), allocatable :: z(:)
end type
contains
subroutine s (x)
class(*), intent(in) :: x(:)
print *, size(x)
end subrou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659
--- Comment #3 from Gerhard Steinmetz
---
Responsible is the class declaration of "x" :
$ cat z1.f90
program p
type t
integer :: a
end type
contains
subroutine s (x)
class(t), intent(inout) :: x(:)
print *, x(1)%a
end
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636
--- Comment #6 from Gerhard Steinmetz
---
And for visibility of functions etc., a reduced and modified entry_16.f90 :
$ cat z4.f90
module complex
private :: cx_cadr, cx_radc
type cx
integer :: re
integer :: im
end type
interfac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636
--- Comment #5 from Gerhard Steinmetz
---
The ICE with associate_6.f03 and -fmodule-private
depends on including "implicit none" in main program :
$ cat z3.f90
module m
private
contains
pure function func (n) result (f)
integer, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636
--- Comment #4 from Gerhard Steinmetz
---
Applying same operations as in comment 1 to derived_external_function_1.f90 :
$ cat z2.f90
module m
private
type t
integer g
end type
end
type(t) function f() result(ff)
use m
ff%g = 42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636
--- Comment #3 from Gerhard Steinmetz
---
Thank you for commenting.
A few comments will follow with melt down (simplified) test cases.
Hopefully, nothing gets lost.
It might have been better to post a handful of separate problem reports
inste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
--- Comment #9 from amker at gcc dot gnu.org ---
Sorry for missing this. I will study the case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
Jakub Jelinek changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582
ryan.burn at gmail dot com changed:
What|Removed |Added
CC||ryan.burn at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67922
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |SUSPENDED
Summary|std::unor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69658
--- Comment #3 from Paolo Carlini ---
Hi Jakub and thanks. I'm looking at your patchlet and putting it together my
notes at the time, and IMO it makes a lot of sense: I even remember briefly
wondering if calling reshape_init redundantly could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69664
--- Comment #3 from David Malcolm ---
Issue appears to be with rich_location::override_column, it's called by
cpp_diagnostic_with_line, but it doesn't seem to be working. Am investigating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69664
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #6 from Segher Boessenkool ---
Choosing alt 3 in insn 9: (0) ws (1) j {*movtf_64bit_dm}
Creating newreg=229 from oldreg=171, assigning class VSX_REGS to r229
9: r229:TF=0.0
REG_EQUAL 0.0
Inserting insn r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #4 from Markus Trippelsdorf ---
(In reply to Segher Boessenkool from comment #3)
> ... but fails with -mcpu=power8.
Yeah. I forgot to mention that I configure gcc with --with-cpu=power8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Segher Boessenkool from comment #3)
> ... but fails with -mcpu=power8.
Yeah. I forgot to mention that I configure gcc with --with-cpu=power8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #3 from Segher Boessenkool ---
... but fails with -mcpu=power8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #5 from vries at gcc dot gnu.org ---
The -O0 test passes with -ftoplevel-reorder.
With -fno-toplevel-reorder, the failure shows up for the other levels:
...
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #2 from Segher Boessenkool ---
Does not fail on gcc110 (P7 BE).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675
Bug ID: 69675
Summary: [6 Regression] [graphite] ICE: verify_ssa failed
(definition in block 42 does not dominate use in block
34)
Product: gcc
Version: 6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69674
Bug ID: 69674
Summary: hsa offloading, -m32: "internal compiler error: in
hsa_build_append_simple_mov"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69673
--- Comment #2 from petschy at gmail dot com ---
Is this an accidental omission in the std, or allowing member access would
cause some trouble?
Thanks, Peter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882
--- Comment #16 from Dominique d'Humieres ---
See also pr53086 and pr69368.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #9 from Richard Biener ---
Slowdown also reproduces with -fno-schedule-insns2 which makes reading the
assembly difference easier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #7 from Richard Biener ---
So the main question remains - why's the patch not a no-op on x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #8 from Richard Biener ---
Ok, it's if in the old code operand zero didn't match we didn't process further
operands which may have had the '%'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69639
--- Comment #3 from dave.anglin at bell dot net ---
On 2016-02-04 7:04 AM, rguenth at gcc dot gnu.org wrote:
> I think this is "known" to be an issue, so did you confirm the required stack
> space grow or so? And whether that's target specific?
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #6 from Richard Biener ---
Created attachment 37580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37580&action=edit
preprocessed source
source for the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #5 from Richard Biener ---
Samples: 2M of event 'cycles', Event count (approx.): 1928893785632
36.40% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] inl1130_
28.60% gromacs_peak.am gromacs_peak.amd64-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69673
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 210 matches
Mail list logo
