https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #8 from Michael Karcher ---
The patch looks like it should work fine, I guess John Paul Adrian Glaubitz is
going to test it soon. But I wonder whether the determination of alignment is
in types.cc really needed, as user-specified alig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #7 from Ian Lance Taylor ---
Can someone with m68k hardware please test the patch at
https://golang.org/cl/35478? Thanks. (To download just the patch as a zip
file: https://go-review.googlesource.com/changes/35478/revisions/1/patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #6 from Ian Lance Taylor ---
I don't think it's the type descriptors that need to be aligned, I think it's
just the GC symbol pointers. Those are the ones whose names end in "$gc" in
the list above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72793
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72792
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72792
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Fri Jan 20 02:36:16 2017
New Revision: 244680
URL: https://gcc.gnu.org/viewcvs?rev=244680&root=gcc&view=rev
Log:
PR72792 PR72793 relax requirements on rebind members
PR libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72793
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Fri Jan 20 02:36:16 2017
New Revision: 244680
URL: https://gcc.gnu.org/viewcvs?rev=244680&root=gcc&view=rev
Log:
PR72792 PR72793 relax requirements on rebind members
PR libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146
--- Comment #1 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Jan 20 02:27:46 2017
New Revision: 244679
URL: https://gcc.gnu.org/viewcvs?rev=244679&root=gcc&view=rev
Log:
PR go/79146
crypto/elliptic: explicitly ignore p256_s39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79091
--- Comment #7 from scott snyder ---
Confirmed that this fixes the original problem from which the test case
was derived. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69321
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79140
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Fri Jan 20 01:22:27 2017
New Revision: 244677
URL: https://gcc.gnu.org/viewcvs?rev=244677&root=gcc&view=rev
Log:
rs6000: Fix the new SSP guard configuration code (PR79140)
I foolis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69321
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Fri Jan 20 01:22:54 2017
New Revision: 244678
URL: https://gcc.gnu.org/viewcvs?rev=244678&root=gcc&view=rev
Log:
PR69321 fix any_cast(any*) for non-copyable T
PR libstdc++/69321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78875
--- Comment #5 from Segher Boessenkool ---
Author: segher
Date: Fri Jan 20 01:22:27 2017
New Revision: 244677
URL: https://gcc.gnu.org/viewcvs?rev=244677&root=gcc&view=rev
Log:
rs6000: Fix the new SSP guard configuration code (PR79140)
I foolis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59960
Martin Dorey changed:
What|Removed |Added
CC||martindorey at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79009
Martin Dorey changed:
What|Removed |Added
CC||martindorey at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64903
--- Comment #6 from Jonathan Wakely ---
Author: redi
Date: Fri Jan 20 00:33:25 2017
New Revision: 244675
URL: https://gcc.gnu.org/viewcvs?rev=244675&root=gcc&view=rev
Log:
PR64903 simplify last fix to std::is_partitioned
PR libstdc++/64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043
--- Comment #15 from Jonathan Wakely ---
The result is supposed to be a null-terminated string, so we could do what
glibc's printf does for null pointers and print "(nil)" but we'd have to widen
the string to the stream's char_type. Alternatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79127
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Fri Jan 20 00:07:14 2017
New Revision: 244668
URL: https://gcc.gnu.org/viewcvs?rev=244668&root=gcc&view=rev
Log:
PR79156 fix std::__enable_shared_from_this extension
PR libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79144
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64903
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64382
Adam Butcher changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64903
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 19 23:30:18 2017
New Revision: 244661
URL: https://gcc.gnu.org/viewcvs?rev=244661&root=gcc&view=rev
Log:
PR64903 fix number of predicate tests in std::is_partitioned
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333
--- Comment #9 from Tony Kelman ---
How can we help get this moving towards resolution? This has kept us stuck on
GCC 4.9, which is getting increasingly problematic. We can attempt to reduce
this to "minimal working piece of opt.exe with gcc 4.9"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79144
--- Comment #3 from Alan Modra ---
Author: amodra
Date: Thu Jan 19 23:19:19 2017
New Revision: 244659
URL: https://gcc.gnu.org/viewcvs?rev=244659&root=gcc&view=rev
Log:
[RS6000] PR79144, cmpstrnsi optimization breaks glibc
glibc compiled with c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2012-01-24 00:00:00 |2017-1-19
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085
--- Comment #14 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 19 23:07:52 2017
New Revision: 244656
URL: https://gcc.gnu.org/viewcvs?rev=244656&root=gcc&view=rev
Log:
PR67085 pass comparison functions by reference in heap algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69992
--- Comment #1 from acsawdey at gcc dot gnu.org ---
At some point the doloop analysis must have changed and as a result declared
that the loop might run infinitely if compiled with -m64. This in turn causes
SMS to bail out and the test fails. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #25 from Uroš Bizjak ---
(In reply to Joel Sherrill from comment #24)
> Would you mind applying this to the 6.x branch? That was where the issue was
> initially spotted.
Sure, but let's wait for a week if everything works OK in the m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68972
--- Comment #9 from Bill Schmidt ---
The test has gone back to not failing anymore at some point:
https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg01932.html
I don't know why.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160
seurer at gcc dot gnu.org changed:
What|Removed |Added
Target||powerpc64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160
Bug ID: 79160
Summary: gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #17 from David Malcolm ---
Remaining XFAILs for this bug:
c-c++-common/pr69558.c (C++ only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543
--- Comment #11 from David Malcolm ---
(In reply to David Malcolm from comment #10)
> The lines in comment #9 came from 18f0e0e551a995687e1822aabb9b7d7ee8f11492
> aka r186971 (affecting gcc.dg/cpp/pragma-diagnostic-2.c)
This was:
"[PATCH 07/11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69992
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #24 from Joel Sherrill ---
Would you mind applying this to the 6.x branch? That was where the issue was
initially spotted.
I don't know what to do about this extra line in rtemself.h though. It was not
present in the master
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543
--- Comment #10 from David Malcolm ---
The lines in comment #9 came from 18f0e0e551a995687e1822aabb9b7d7ee8f11492
aka r186971 (affecting gcc.dg/cpp/pragma-diagnostic-2.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #23 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 19 21:38:44 2017
New Revision: 244653
URL: https://gcc.gnu.org/viewcvs?rev=244653&root=gcc&view=rev
Log:
PR target/78478
Revert:
2013-11-05 Uros
++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
gcc version 7.0.0 20170119 gives what appears to be a spurious warning
for this example when compiling with -O3 (tested on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79158
Bug ID: 79158
Summary: gcc.target/powerpc/pr70669.c fails on powerpc BE
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543
--- Comment #9 from David Malcolm ---
(In reply to David Malcolm from comment #8)
> The following testcases still have xfails:
> c-c++-common/pr69543-3.c
> c-c++-common/pr69543-4.c
> so this isn't quite fixed yet.
These XFAILs are fixed (for
chard Smith.
>
Nice. Your [much cleaner] patch sorts out the starred case above too. With
GCC master (7.0.0 20170119) with your patch the results are:
auto l0 = [&](auto z) { f (z); };// C:8 G:1 G':8 G'':8
auto l1 = [&](auto) { f (2.4); };// C:8 G:1 G':8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79154
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543
--- Comment #8 from David Malcolm ---
The following testcases still have xfails:
c-c++-common/pr69543-3.c
c-c++-common/pr69543-4.c
so this isn't quite fixed yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63256
--- Comment #10 from acsawdey at gcc dot gnu.org ---
Looking at this again. Present state of play is:
sms-4.c fails with -m64 BE and LE
sms-8.c fails with -m32 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157
Bug ID: 79157
Summary: gfortran crashed on sparc with openmpi build
Product: gcc
Version: 5.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #22 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 19 21:00:53 2017
New Revision: 244651
URL: https://gcc.gnu.org/viewcvs?rev=244651&root=gcc&view=rev
Log:
PR target/78478
* config/ax_check_define.m4: New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156
--- Comment #1 from Jonathan Wakely ---
(In reply to mib.bugzilla from comment #0)
> Changing "friend void" to "friend auto" would be a simple fix.
That wouldn't compile in C++11 mode. I think shouldn't return anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156
Bug ID: 79156
Summary: incorrect c++ usage in gcc7 void function
returns a value
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085
--- Comment #12 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 19 20:29:07 2017
New Revision: 244650
URL: https://gcc.gnu.org/viewcvs?rev=244650&root=gcc&view=rev
Log:
Fix unsafe moves inside loops
PR libstdc++/67085
* incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
--- Comment #9 from Matt Clarkson ---
(In reply to Jonathan Wakely from comment #7)
> GCC 7 now defines _GLIBCXX_RELEASE (with the same value as __GNUC__ has,
> i.e. the GCC major version, as an integer constant, but defined by the
> library head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79155
Bug ID: 79155
Summary: Typo in cpuid.h comment
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082
--- Comment #5 from Martin Sebor ---
I see no warning at -O0 on
snprintf (buffer, 4, "%03hx", val & 0xfff);
or at -O2 on:
snprintf (buffer, 3, "%2d", (val < 0) ? -(val % 100) : val % 100);
(It does warn at -O0 as expected.) This is on x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79154
Bug ID: 79154
Summary: omp declare simd in pure function?
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #21 from Uroš Bizjak ---
(In reply to Joel Sherrill from comment #20)
> Looks like it works, Thanks.
>
> Based on my testing, these need to be applied to both the gcc 6 branch and
> master. Should I just commit them with the PR not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79049
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79153
Bug ID: 79153
Summary: -Wimplicit-fallthrough missed warning
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79152
Bug ID: 79152
Summary: -Wimplicit-fallthrough false positive triggered by
goto statements
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085
--- Comment #11 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 19 18:26:41 2017
New Revision: 244648
URL: https://gcc.gnu.org/viewcvs?rev=244648&root=gcc&view=rev
Log:
PR67085 move comparison functions in heap operations
PR libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082
--- Comment #4 from Franz Sirl ---
Hmm, %hhd is not usable on some of our platforms and also only really helpful
with exact %x outputs:
snprintf(buffer, 3, "%02hhx", val);
What about:
snprintf(buffer, 4, "%03hx", val & 0xfff);
Here the 'h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79130
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79151
Bug ID: 79151
Summary: Missed vectorization with identical formulas
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62161
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
atexit
--enable-checking=all
Thread model: posix
gcc version 7.0.0 20170119 (experimental) (GCC)
I've looked into this a little, but I'd appreciate some help.
Sorry for being so late in reporting this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79051
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Martin Sebor ---
> Thanks. The patch looks good to me. You should be able to commit the patch
> without approval.
Indeed, done.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79051
--- Comment #12 from Rainer Orth ---
Author: ro
Date: Thu Jan 19 17:42:50 2017
New Revision: 244647
URL: https://gcc.gnu.org/viewcvs?rev=244647&root=gcc&view=rev
Log:
Fix gcc.dg/attr-alloc_size-4.c on i?86 (PR testsuite/79051)
PR testsu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77455
wilco at gcc dot gnu.org changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #20 from Joel Sherrill ---
(In reply to Uroš Bizjak from comment #19)
> (In reply to Joel Sherrill from comment #18)
> > I changed that line to
> >
> > #ifdef _SOFT_FLOAT
> > #include "config/fpu-generic.h"
> >
> > and it built. Is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085
--- Comment #10 from Jonathan Wakely ---
The changes in r244150 turned some internal copies into moves, improving the PR
70898 testcase from 61 seconds to 29 seconds.
If I modify the testcase attached here to track moves as well as copies, GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
--- Comment #8 from Jonathan Wakely ---
(In reply to Matt Clarkson from comment #2)
> Because wehen I compile with clang against the libstdc++ the problem will
> still occur and __GNUC__ will not be defined.
N.B. Clang does define __GNUC__ but i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79051
--- Comment #11 from Martin Sebor ---
Thanks. The patch looks good to me. You should be able to commit the patch
without approval.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71648
--- Comment #6 from Bill Schmidt ---
This actually appears to be fixed in GCC 6 as well, so the fix must have been
backported. Konstantinos, can you please try with GCC 6.3 and confirm that the
problem goes away for you?
Thanks,
Bill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
--- Comment #6 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 19 16:40:46 2017
New Revision: 244642
URL: https://gcc.gnu.org/viewcvs?rev=244642&root=gcc&view=rev
Log:
PR78905 define _GLIBCXX_RELEASE macro
PR libstdc++/78905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #25 from Martin Liška ---
Created attachment 40549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40549&action=edit
GCC 7 -fmem-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #24 from Martin Liška ---
Created attachment 40548
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40548&action=edit
GCC 6 -fmem-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #23 from Martin Liška ---
Depending on memory layout of the structure, but these 2 structures increase
memory of about ((32+88)*3258685)/(1024**2) ~372 MB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71264
--- Comment #23 from Rainer Orth ---
(In reply to rguent...@suse.de from comment #22)
> On Mon, 24 Oct 2016, ebotcazou at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71264
> >
> > --- Comment #21 from Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #14 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Thu Jan 19 16:05:59 2017
New Revision: 244640
URL: https://gcc.gnu.org/viewcvs?rev=244640&root=gcc&view=rev
Log:
MIPS: PR target/78176 add -mlxc1-sxc1.
gcc/
PR target/781
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79051
--- Comment #10 from Rainer Orth ---
Created attachment 40547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40547&action=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79051
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #19 from Uroš Bizjak ---
(In reply to Joel Sherrill from comment #18)
> I changed that line to
>
> #ifdef _SOFT_FLOAT
> #include "config/fpu-generic.h"
>
> and it built. Is that OK?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71648
--- Comment #5 from Bill Schmidt ---
This appears to be fixed on trunk -- between David and me we've tested this on
AIX 32- and 64-bit, PPC64LE on P8, and PPC64 on P7. We'll need to bisect and
see what fixed the problem and work on a backport fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696
--- Comment #12 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Thu Jan 19 15:52:32 2017
New Revision: 244637
URL: https://gcc.gnu.org/viewcvs?rev=244637&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:
2017-01-19 Andre Vehreschild
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #21 from Martin Liška ---
Looking at distinct number of value ranges and bits, we can get:
grep hash_vr /tmp/7.dump.ipa | sort | uniq -c | wc -l
65224
grep hash_bits /tmp/7.dump.ipa | sort | uniq -c | wc -l
13421
Where total # of j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79144
--- Comment #2 from acsawdey at gcc dot gnu.org ---
Alan,
Thanks for jumping in here. What I tried yesterday was this code to try to
get the correct name:
+ const char *id =
+ IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79127
--- Comment #14 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 19 15:41:15 2017
New Revision: 244636
URL: https://gcc.gnu.org/viewcvs?rev=244636&root=gcc&view=rev
Log:
PR target/79127
* acinclude.m4 (LIBGFOR_CHECK_AVX512F): E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #18 from Joel Sherrill ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Joel Sherrill from comment #16)
> > Thanks for all the feedback. With this patch, it now builds. Is the style of
> > change to configure.host OK?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
Bug ID: 79149
Summary: bad optimization on MIPS and ARM leading to excessive
stack usage in some cases
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78900
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79148
Bug ID: 79148
Summary: stack addresses are spilled to stack slots on x86-64
at -Os instead of rematerializing the addresses
Product: gcc
Version: unknown
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #15 from Jan Hubicka ---
Now I get (for 500 invocations)
real user sys
GCC 7:0m9.816s 0m6.274s 0m3.546s
GCC 6:0m7.880s 0m4.253s 0m3.605s
GCC 5:0m7.655s 0m4.264s 0m3.159s
GCC 4.6: 0m7.271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146
Richard Biener changed:
What|Removed |Added
Keywords||build
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #20 from Richard Biener ---
Look at tree-ssanames.c:range_info_def for "tricks" (make them variable size):
/* Value range information for SSA_NAMEs representing non-pointer variables.
*/
struct GTY ((variable_size)) range_info_def
1 - 100 of 145 matches
Mail list logo
