https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986
Bug ID: 61986
Summary: ICE on valid code at -O3 on x86_64-linux-gnu
indecide_about_value, at ipa-cp.c:3480
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
--- Comment #13 from Richard Biener ---
(In reply to vries from comment #12)
> Created attachment 33220 [details]
> Alternative patch
>
> > But that line is never executed at runtime (well, unless tail
> > merging comes along and makes it the on
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
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
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
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=61982
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
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=61980
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=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=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
--- 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=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 #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=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=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=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=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=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=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=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=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=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=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=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=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 #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 #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 #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 #8 from Jonathan Wakely ---
VC++ and the book are both wrong.
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=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=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
--- 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
Jonathan Wakely changed:
What|Removed |Added
Component|web |spam
Resolution|MOVED
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=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
--- 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
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
--- 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 #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=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=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=61990
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=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=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 #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 #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 #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=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=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=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=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=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=60953
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--
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=60693
Jakub Jelinek changed:
What|Removed |Added
CC||filip.svoboda at netajo dot cz
--- Comme
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=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=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=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=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=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=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=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=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
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=59823
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=53492
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=57138
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=59645
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=51253
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=61895
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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
--- 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=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
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version|4.10.0
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=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=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=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=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=61993
--- Comment #2 from steveren ---
Ah, it is a dupe; sorry, I missed that one.
1 - 100 of 102 matches
Mail list logo
