https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979
--- Comment #5 from Andrew Pinski ---
Where is the testcase, this is only the assembly output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979
--- Comment #4 from Srikanth ---
In the Above comment-3 assembly code with black color letter are the repeated
code i.e storing the float variable twice in FPU stack during conditional
checking for parity flag and zero flag. I just patch that one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61993
--- Comment #2 from steveren ---
Ah, it is a dupe; sorry, I missed that one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979
--- Comment #3 from Srikanth ---
Comment on attachment 33225
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33225
In this assemble code line number at 22-25 and after 27-30 both are same
instructions repeated for conditional checking.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979
--- Comment #2 from Srikanth ---
Created attachment 33225
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33225&action=edit
In this assemble code line number at 22-25 and after 27-30 both are same
instructions repeated for conditional checki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Sat Aug 2 05:52:30 2014
New Revision: 213515
URL: https://gcc.gnu.org/viewcvs?rev=213515&root=gcc&view=rev
Log:
PR c/59855
* gcc.dg/Wdesignated-init-2.c: New test.
Added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52366
Andrew Pinski changed:
What|Removed |Added
CC||q@rsn-tech.co.uk
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61993
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version|4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895
--- Comment #4 from ian at gcc dot gnu.org ---
Author: ian
Date: Sat Aug 2 00:54:15 2014
New Revision: 213513
URL: https://gcc.gnu.org/viewcvs?rev=213513&root=gcc&view=rev
Log:
PR other/61895
runtime: Ignore small argv[0] file for backtrac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895
--- Comment #3 from ian at gcc dot gnu.org ---
Author: ian
Date: Sat Aug 2 00:53:58 2014
New Revision: 213512
URL: https://gcc.gnu.org/viewcvs?rev=213512&root=gcc&view=rev
Log:
PR other/61895
runtime: Ignore small argv[0] file for backtrac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Sat Aug 2 00:52:09 2014
New Revision: 213511
URL: https://gcc.gnu.org/viewcvs?rev=213511&root=gcc&view=rev
Log:
PR c++/60417
* init.c (build_vec_init): Set CONSTRUCTOR_IS_DIRECT_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61994
--- Comment #1 from Jeremy Maitin-Shepard ---
With gcc 4.9.1:
The following test program produces an ICE:
typedef unsigned long limb_t __attribute__ ((__vector_size__ (16),
__may_alias__));
struct X {
limb_t limb = {1,1};
};
const X table[1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61994
Bug ID: 61994
Summary: constexpr vector array ICE [4.9.1 regression]
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61993
Bug ID: 61993
Summary: constexpr static member function "is not constant"
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59707
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59645
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59633
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57138
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51239
Jason Merrill changed:
What|Removed |Added
CC||jmetcalfe at acm dot org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53492
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59823
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59956
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59956
--- Comment #8 from Jason Merrill ---
Author: jason
Date: Fri Aug 1 18:33:47 2014
New Revision: 213501
URL: https://gcc.gnu.org/viewcvs?rev=213501&root=gcc&view=rev
Log:
PR c++/59956
* friend.c (do_friend): Pass the TEMPLATE_DECL to add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Fri Aug 1 18:33:41 2014
New Revision: 213500
URL: https://gcc.gnu.org/viewcvs?rev=213500&root=gcc&view=rev
Log:
PR c++/60241
* pt.c (lookup_template_class_1): Update DECL_TEMPLAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59823
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Fri Aug 1 18:33:54 2014
New Revision: 213502
URL: https://gcc.gnu.org/viewcvs?rev=213502&root=gcc&view=rev
Log:
PR c++/59823
Core DR 1138
* call.c (reference_binding): Pass L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Fri Aug 1 18:33:35 2014
New Revision: 213499
URL: https://gcc.gnu.org/viewcvs?rev=213499&root=gcc&view=rev
Log:
PR c++/60361
* parser.c (cp_parser_template_id): Don't set up a CP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61992
--- Comment #1 from Rafał Mużyło ---
...if there's any confusion, aclocal.m4 is just a random pick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61992
Bug ID: 61992
Summary: git web interface handles some paths badly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: web
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #7 from Jakub Jelinek ---
(In reply to Daniel Krügler from comment #6)
> (In reply to Avi Kivity from comment #5)
> > Ah, I see that non-trivial destructors were fixed in gcc 4.9.
>
> I'm not sure whether I can agree with "fixed" her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #6 from Daniel Krügler ---
(In reply to Avi Kivity from comment #5)
> Ah, I see that non-trivial destructors were fixed in gcc 4.9.
I'm not sure whether I can agree with "fixed" here. A related (yet unresolved)
core-language issue is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61988
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693
Jakub Jelinek changed:
What|Removed |Added
CC||filip.svoboda at netajo dot cz
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61963
--- Comment #2 from Kirill Yukhin ---
Author: kyukhin
Date: Fri Aug 1 17:20:02 2014
New Revision: 213494
URL: https://gcc.gnu.org/viewcvs?rev=213494&root=gcc&view=rev
Log:
PR other/61963
gcc/cp/
* parser.c (cp_parser_array_notation): A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60953
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61991
Bug ID: 61991
Summary: Destructors not always called for statically
initialized thread_local objects
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #5 from Avi Kivity ---
Ah, I see that non-trivial destructors were fixed in gcc 4.9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61963
--- Comment #1 from Kirill Yukhin ---
Author: kyukhin
Date: Fri Aug 1 17:06:00 2014
New Revision: 213493
URL: https://gcc.gnu.org/viewcvs?rev=213493&root=gcc&view=rev
Log:
PR other/61963
gcc/cp/
* parser.c (cp_parser_array_notation): A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61455
--- Comment #4 from Kirill Yukhin ---
Author: kyukhin
Date: Fri Aug 1 17:00:51 2014
New Revision: 213492
URL: https://gcc.gnu.org/viewcvs?rev=213492&root=gcc&view=rev
Log:
PR middle-end/61455
gcc/c-family/
* array-notation-common.c (ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61455
--- Comment #3 from Kirill Yukhin ---
Author: kyukhin
Date: Fri Aug 1 16:54:27 2014
New Revision: 213491
URL: https://gcc.gnu.org/viewcvs?rev=213491&root=gcc&view=rev
Log:
PR middle-end/61455
gcc/c-family/
* array-notation-common.c (ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #4 from Marc Glisse ---
(In reply to Avi Kivity from comment #3)
> I observed this with non-trivial destructors as well.
>
> In fact, something like:
>
> X::~X() { i = 3; }
>
> also emits a store.
Not for me, at least at -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
--- Comment #3 from Jonathan Wakely ---
(In reply to lukeocamden from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > This is by design.
>
> I don't really follow - do you mean a consequence of the design, or does the
> standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #3 from Avi Kivity ---
I observed this with non-trivial destructors as well.
In fact, something like:
X::~X() { i = 3; }
also emits a store.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
--- Comment #2 from lukeocamden at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> This is by design.
I don't really follow - do you mean a consequence of the design, or does the
standard mandate copying/moving the object into t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #2 from Jakub Jelinek ---
The CLOBBER for non-decl expressions is added in the destructors, here we have
trivial destructor, so it is "inlined" already by the frontend and thus not
emitted. Perhaps we could emit it in the places wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #8 from Kostya Serebryany ---
(In reply to Daniel Pinol from comment #7)
> thank you everybody for your great feedback!
>
> @kostya: I provide here the full log. Even removing the #if's, it still
> aborts. strict_memcmp=0 worked like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61990
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61990
Bug ID: 61990
Summary: Incorrect caret location for type mismatches in
function calls
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #7 from Daniel Pinol ---
thank you everybody for your great feedback!
@kostya: I provide here the full log. Even removing the #if's, it still aborts.
strict_memcmp=0 worked like a charm. Thanks!
I guess there's no way to just report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
--- Comment #18 from rguenther at suse dot de ---
On Fri, 1 Aug 2014, froydnj at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
>
> --- Comment #17 from Nathan Froyd ---
> (In reply to Richard Biener from comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
--- Comment #17 from Nathan Froyd ---
(In reply to Richard Biener from comment #15)
> Instead aligned the string.
This is kind of unfortunate, as the motivating testcase was something more
like:
...
static const char string[] = "Private";
u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
--- Comment #16 from Richard Biener ---
Author: rguenth
Date: Fri Aug 1 12:40:37 2014
New Revision: 213454
URL: https://gcc.gnu.org/viewcvs?rev=213454&root=gcc&view=rev
Log:
2014-08-01 Richard Biener
PR middle-end/61762
* gcc.dg/pr6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
--- Comment #14 from Richard Biener ---
Argh. Then we fall into the c_strlen wart to not break strlenopt... which
means the fancy folding never triggers.
Oh well. I guess simply XFAIL for strict-align targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
--- Comment #13 from Richard Biener ---
Does the following additional patch fix the existing testcase?
Index: varpool.c
===
--- varpool.c (revision 213342)
+++ varpool.c (workin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989
Jonathan Wakely changed:
What|Removed |Added
Component|web |spam
Resolution|MOVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989
--- Comment #2 from Iwona ---
(In reply to Iwona from comment #1)
> comments
there is no comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989
Iwona changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989
--- Comment #3 from Iwona ---
(In reply to Iwona from comment #1)
> comments
there is no comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989
Bug ID: 61989
Summary: gregr
Product: gcc
Version: trans-mem
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
--- Comment #8 from Jonathan Wakely ---
VC++ and the book are both wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980
--- Comment #6 from Sabrina Souto ---
OK, Thank you.
(In reply to Richard Biener from comment #5)
> (In reply to Sabrina Souto from comment #4)
> > I don't have much experience with GCC, so I'm a bit confused with your 2
> > answers, please help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
--- Comment #7 from Yuanming Gao ---
Please read the book: <>. The code comes from <<7.1
Templates>>. The author thought the function int foo(int) must be selected.
Visual C++ can select the int foo(int) correctly. I don't know whether it is an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980
--- Comment #5 from Richard Biener ---
(In reply to Sabrina Souto from comment #4)
> I don't have much experience with GCC, so I'm a bit confused with your 2
> answers, please help me understanding what is happening: Based both on the
> documenta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
--- Comment #6 from Yuanming Gao ---
Visual C++ can select the int foo(int) correctly. I don't know whether it is
an implementation issue, or it is by design.
Best regards,
Yuanming
> From: gcc-bugzi...@gcc.gnu.org
> To: gaoyuanm...@hotmail.co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980
--- Comment #4 from Sabrina Souto ---
I don't have much experience with GCC, so I'm a bit confused with your 2
answers, please help me understanding what is happening: Based both on the
documentation and the results, I understood that the result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #6 from Jakub Jelinek ---
(In reply to Daniel Pinol from comment #3)
> #if defined(__has_feature)
> # if __has_feature(address_sanitizer)
> __attribute__((no_sanitize_address))
> # endif
> #endif
> void triggerLang(ReemWindo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #5 from Kostya Serebryany ---
Also check if strict_memcmp=0 helps you.
https://code.google.com/p/address-sanitizer/wiki/Flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980
--- Comment #3 from Richard Biener ---
It's intended for debugging only:
@item -fcheck-data-deps
@opindex fcheck-data-deps
Compare the results of several data dependence analyzers. This option
is used for debugging the data dependence analyzers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980
--- Comment #2 from Sabrina Souto ---
Thank you for the confirmation Richard.
Just a suggestion: if the option -fcheck-data-deps does not work well, maybe
this option should be removed from the code or at least have a comment in the
documentatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #4 from Kostya Serebryany ---
Note that the blacklist can not disable the checking inside the memcmp
interceptor. But it will disable instrumenting globals in QT, so
if this is a global from QT (you did not post the full log) you wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #3 from Daniel Pinol ---
I agree with Kostya.
I get an error within Qt, and I cannot modify its source code. Another option
would be having a flag for not aborting execution when an error is detected (as
in valgrind)
I tried adding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
--- Comment #5 from Jonathan Wakely ---
G++ and clang++ call f(double) four times, because that is the only function
visible in the template definition. foo(int) is only visible at the point of
instantiation, so could only be found by ADL, but in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61988
--- Comment #1 from Filip Svoboda ---
Created attachment 33224
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33224&action=edit
failing source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61988
Bug ID: 61988
Summary: compiler error when misplascing "memcpy(" instead of
"memset("
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
--- Comment #4 from Andrew Pinski ---
(In reply to Yuanming Gao from comment #3)
> Please read the book: <>. The code comes from
> <<7.1 Templates>>. The author thought the function int foo(int) must be
> selected.
Well I disagree with that book
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
--- Comment #3 from Yuanming Gao ---
Please read the book: <>. The code comes from <<7.1
Templates>>. The author thought the function int foo(int) must be selected.
Best regards,
Yuanming Gao
> From: gcc-bugzi...@gcc.gnu.org
> To: gaoyuanm...@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61375
--- Comment #3 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Fri Aug 1 09:46:47 2014
New Revision: 213436
URL: https://gcc.gnu.org/viewcvs?rev=213436&root=gcc&view=rev
Log:
2014-08-01 Thomas Preud'homme
Backport from mainli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
--- Comment #2 from Andrew Pinski ---
I don't think this is a bug as foundmental types does not have an associated
namespace associated with it. So the overload set is only what is declared
before the template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #8 from andysem at mail dot ru ---
We have a similar problem in Boost.Atomic:
https://svn.boost.org/trac/boost/ticket/10204
There we mark all boost::atomic<> functions as always_inline to make sure the
compiler sees the memory order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
--- Comment #1 from Yuanming Gao ---
Created attachment 33223
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33223&action=edit
source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
Bug ID: 61987
Summary: Name Resolution within a Template
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61375
--- Comment #2 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Fri Aug 1 08:56:17 2014
New Revision: 213426
URL: https://gcc.gnu.org/viewcvs?rev=213426&root=gcc&view=rev
Log:
2014-08-01 Thomas Preud'homme
Backport from mainli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510
--- Comment #6 from jgreenhalgh at gcc dot gnu.org ---
Author: jgreenhalgh
Date: Fri Aug 1 08:56:05 2014
New Revision: 213425
URL: https://gcc.gnu.org/viewcvs?rev=213425&root=gcc&view=rev
Log:
[Patch] Not very subtle fix for pr61510
gcc/
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #2 from Kostya Serebryany ---
Yea. This has been discussed a couple of times before.
using an attribute in the source is clearly the preferable way.
Unfortunately, it is not always technically possible, so we *have* to use the
black
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60953
--- Comment #5 from multya ---
I update system to 8.4 and no mo errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
--- Comment #17 from Anders Kaseorg ---
Thanks. I verified that GCC 4.8 r213405 fixes my test case and the original
Kerberos problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
--- Comment #15 from Richard Biener ---
Author: rguenth
Date: Fri Aug 1 07:40:01 2014
New Revision: 213405
URL: https://gcc.gnu.org/viewcvs?rev=213405&root=gcc&view=rev
Log:
2014-08-01 Richard Biener
PR tree-optimization/61964
* tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
--- Comment #14 from Richard Biener ---
Author: rguenth
Date: Fri Aug 1 07:36:16 2014
New Revision: 213404
URL: https://gcc.gnu.org/viewcvs?rev=213404&root=gcc&view=rev
Log:
2014-08-01 Richard Biener
PR tree-optimization/61964
* tre
1 - 100 of 102 matches
Mail list logo
