On 11/04/2013 06:10 AM, Ian Lance Taylor wrote:
Clang's blocks are more powerful than GCC's nested functions, because
blocks may be placed on the heap, and therefore returned from a
function.
And they don't need code generation at run time.
--
Florian Weimer / Red Hat Product Security Team
On Sat, 2 Nov 2013, Richard Sandiford wrote:
Jakub Jelinek ja...@redhat.com writes:
On Sat, Nov 02, 2013 at 03:15:44PM +, Richard Sandiford wrote:
What should integer_onep mean if we have a signed 1-bit bitfield in
which the bit is set? Seen as a 1-bit value it's obviously 1,
but
On Sat, 2 Nov 2013, Marc Glisse wrote:
On Sat, 2 Nov 2013, Jakub Jelinek wrote:
On Sat, Nov 02, 2013 at 05:38:53PM +, Richard Sandiford wrote:
OK, thanks. I should have realised this earlier, but we have:
/* Return 1 if EXPR is the integer constant one or the corresponding
On 04/11/13 06:18, pins...@gmail.com wrote:
On Nov 3, 2013, at 9:10 PM, Ian Lance Taylor i...@google.com
wrote:
On Sun, Nov 3, 2013 at 8:49 PM, pins...@gmail.com wrote:
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov
ma...@kugelworks.com wrote:
Hi,
I am considering a project to
More than a decade ago, there was some work in GCC and glibc about
propagating bounds information for pointers. I could find the old web
page on archive.org, but I'm wondering if there's a concise report how
it actually worked and how much software could be ported over with what
amount of
The question:
The insn which causes the segfault is:
(debug_insn 1548 1547 1886 11 (var_location:V4HI __b (subreg:V4HI
(reg:V8HI 125 d31 [orig:657 vr ] [657]) 0)) upsampling_neon.c:850 -1
(nil))
The variable vr is declared as a NEON vector of 8 16bit integers, and
On Mon, Nov 04, 2013 at 11:44:57AM +0100, Florian Weimer wrote:
More than a decade ago, there was some work in GCC and glibc about
propagating bounds information for pointers. I could find the old
web page on archive.org, but I'm wondering if there's a concise
report how it actually worked
On Wed, Oct 30, 2013 at 8:17 PM, Toon Moene t...@moene.org wrote:
Consider this:
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02329.html
and
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02258.html
/scratch/toon/bd5894/./prev-gcc/xg++ -B/scratch/toon/bd5894/./prev-gcc/
On Mon, 2013-11-04 at 17:28 +1300, Maxim Kuvyrkov wrote:
I am considering a project to add Apple's blocks [*] extension to GCC. I am
looking at adding blocks support to C, C++ and Obj-C/C++ front-ends.
There are many challenges (both technical and copyright) that require work
before any
Hi
I hope this isn't a silly question. I am running gcc 4.6.3 on Ubuntu 12. When
I compile my source code I get compiler errors in a form that I don't expect.
For example:
EVD.cpp:(.text+0x1c6e): undefined reference to `Matrixstd::complexdouble
::Matrix()'
Why is the location of the error
On 11/04/2013 02:56 PM, David Aldrich wrote:
I hope this isn't a silly question. I am running gcc 4.6.3 on Ubuntu 12. When
I compile my source code I get compiler errors in a form that I don't expect.
For example:
EVD.cpp:(.text+0x1c6e): undefined reference to `Matrixstd::complexdouble
On Monday 04 November 2013 13:56:46 David Aldrich wrote:
EVD.cpp:(.text+0x1c6e): undefined reference to `Matrixstd::complexdouble
::Matrix()'
Because it's the linker which is complaining, not the compiler. Undefined
reference means you're referencing a library the linker can't find.
--
Thanks for your answer. Sorry I used the wrong list.
David
-Original Message-
From: fidell...@mykolab.com [mailto:fidell...@mykolab.com]
Sent: 04 November 2013 14:34
To: gcc@gcc.gnu.org
Cc: David Aldrich
Subject: Re: Why doesn't gcc 4.6 show line numbers in error messages?
On
On 11/04/13 03:44, Florian Weimer wrote:
More than a decade ago, there was some work in GCC and glibc about
propagating bounds information for pointers. I could find the old web
page on archive.org, but I'm wondering if there's a concise report how
it actually worked and how much software could
On Mon, 4 Nov 2013, Maxim Kuvyrkov wrote:
Joseph, Richard, as C front-end maintainers, would you be supportive of
Blocks extension implemented for C front-end?
Yes. I believe the point (or one of the points) is that at least some
system headers in current Darwin require this extension (more
On Mon, 4 Nov 2013, Torvald Riegel wrote:
What is the status of this or similar features (eg, lambdas) in ISO C?
IOW, what was the feedback on the blocks part of
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf, and are there
any follow-ups? IMHO, it would be preferable to support
On Mon, 4 Nov 2013, Jeff Law wrote:
You might also be referring to Greg McGary's work on bounded pointers, I don't
think that ever got integrated or if it did, it got pulled long ago.
It was integrated in 2000, removed in 2002/2003 (I removed the relics from
glibc earlier this year). By
On Mon, 2013-11-04 at 16:39 +, Joseph S. Myers wrote:
On Mon, 4 Nov 2013, Torvald Riegel wrote:
What is the status of this or similar features (eg, lambdas) in ISO C?
IOW, what was the feedback on the blocks part of
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf, and are
On 11/04/2013 11:34 AM, Joseph S. Myers wrote:
On Mon, 4 Nov 2013, Maxim Kuvyrkov wrote:
Joseph, Richard, as C front-end maintainers, would you be supportive of
Blocks extension implemented for C front-end?
Yes. I believe the point (or one of the points) is that at least some
system headers
Hi,
When configuring a gcc build with --disable-bootstrap --enable-languages=c I
run into this error:
...
libtool: compile: g++
-B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-gnu/bin/
-B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-gnu/lib/
-isystem
Hi Tom,
Please see my response below:
Thanks,
Balaji V. Iyer.
-Original Message-
From: Tom de Vries [mailto:tom_devr...@mentor.com]
Sent: Monday, November 4, 2013 2:15 PM
To: gcc@gcc.gnu.org
Cc: Iyer, Balaji V
Subject: libcilkrts breaks non-bootstrap build
Hi,
When
Hi Tom,
This is what I tried for --enable-languages=c,c++
../trunk-gcc/configure --disable-bootstrap --enable-languages=c,c++
--prefix=/home /install_dir/trunk-install-disable-bootstrap
And it seem to compile fine. Did you any other tags to configure?
Thanks,
Balaji V. Iyer.
Tobias Burnus wrote:
Gerald Pfeifer wrote:
To make it easier to reproduce builds of software and entire GNU/Linux
distributions, RMS had the idea of adding a warning to GCC that warns
about the use of __DATE__ and __TIME__.
I assume that he also likes to have a warning for __TIMESTAMP__.
I
On 28 October 2013 21:13, Ian Lance Taylor wrote:
On Sun, Oct 27, 2013 at 12:04 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
To make it easier to reproduce builds of software and entire GNU/Linux
distributions, RMS had the idea of adding a warning to GCC that warns
about the use of __DATE__
On Mon, 4 Nov 2013, Jonathan Wakely wrote:
On 28 October 2013 21:13, Ian Lance Taylor wrote:
I don't have any strong objection, but I'll note that it's even easier
to use -D options.
CC='gcc -D__DATE__=today'
It's undefined behaviour in both C and C++ to redefine pre-defined
macros such as
On 04/11/13 21:23, Iyer, Balaji V wrote:
Hi Tom,
This is what I tried for --enable-languages=c,c++
../trunk-gcc/configure --disable-bootstrap --enable-languages=c,c++
--prefix=/home /install_dir/trunk-install-disable-bootstrap
And it seem to compile fine. Did you any other tags to
The warning should say macro not Macro and I think reproducing not
reproduce. The c-family and libcpp changes are OK with that fixed.
--
Joseph S. Myers
jos...@codesourcery.com
On Nov 3, 2013, at 8:49 PM, pins...@gmail.com wrote:
What benefits does blocks have over nested functions in C and over lambas in
C++?
The ability to compile existing code. The ability to compile code that uses
system header files on macosx. The ability to use third party libraries on
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov ma...@kugelworks.com wrote:
I am considering a project to add Apple's blocks [*] extension to GCC.
I have a funny story about that one… I was just about ready to submit the
work, the GPLv3 happened. Ah… life goes on.
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov ma...@kugelworks.com wrote:
Mike, as Obj-C/C++ front-end maintainers, would you be supportive of Blocks
extension implemented for Obj-C/C++ front-ends?
Sure.
Though, I'd really love a front-end extension to allow one to implement Blocks
as a pure
On 4 November 2013 22:26, Andreas Schwab wrote:
The undefined behaviour study group of the C++ committee are
considering making it ill-formed, which would require a diagnostic.
That still wouldn't cover command line arguments.
Ah yes, as it would still be predefined, but to the value given
-Original Message-
From: Tom de Vries [mailto:tom_devr...@mentor.com]
Sent: Monday, November 4, 2013 2:15 PM
To: gcc@gcc.gnu.org
Cc: Iyer, Balaji V
Subject: libcilkrts breaks non-bootstrap build
Hi,
When configuring a gcc build with --disable-bootstrap --enable-
languages=c
On Mon, Nov 04, 2013 at 01:29:10PM +0100, Richard Biener wrote:
On Wed, Oct 30, 2013 at 8:17 PM, Toon Moene t...@moene.org wrote:
Consider this:
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02329.html
and
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02258.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2013-11-04 00:00:00 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, before IPA-CP, foo had:
_10 = BIT_FIELD_REF p, 32, 0;
_11 = _10 507904;
Now, IPA-CP does:
Modification phase of node foo.constprop.0/3
Aggregate replacements: 0[14]=1,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Here, single_imm_use can set the stmt to NULL:
/* If there aren't any uses whatsoever, we're done. */
if (ptr == ptr-next)
{
return_false:
*use_p =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Note that likely since r199252 Aggregate replacements: 0[14]=1, 0[8]=0, 0[0]=1
is replaced with just 0[0]=1, still the effect is exactly the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org ---
When I introduced RO_ARROW_STAR I didn't realize it could end up in
invalid_indirection_error, probably just needs an extra case there.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #6)
That doesn't look safe, negative rbitpos is not necessarily undefined
behavior.
Can't you get the same with say
struct S {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Thus, hopefully:
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -6479,8 +6479,9 @@ all_imm_uses_in_stmt_or_feed_cond (tree var, gimple stmt,
basic_blo
single_imm_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015
--- Comment #33 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nathan Ridge from comment #32)
No one, but they need to know about issues like this in order to do
something about them.
It's been in the MinGW bug tracker for years,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58983
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase:
int
foo (int x)
{
switch (x)
{
case 0:
case 1:
case 9:
break;
default:
__builtin_unreachable ();
}
return x;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #7)
(In reply to Jakub Jelinek from comment #6)
That doesn't look safe, negative rbitpos is not necessarily undefined
behavior.
Can't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 31147
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31147action=edit
gcc49-pr58970.patch
Untested fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Well, what does OpenCL specify here? IIRC we've decided on -1 (all bits set)
as true for vectors and 0 as false. I'd prefer to allow trivial lowering
to | and which IIRC are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 31148
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31148action=edit
gcc49-pr58978.patch
While your patch will work too, I think it is better to fix it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #10 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
but this should'nt be neccessary then?
if (bitoffset *bitpos)
{
HOST_WIDE_INT adjust = bitoffset - *bitpos;
-
gcc_assert ((adjust % BITS_PER_UNIT) ==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #10)
but this should'nt be neccessary then?
if (bitoffset *bitpos)
{
HOST_WIDE_INT adjust = bitoffset - *bitpos;
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Assignee|mpolacek at gcc dot gnu.org|jakub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #11)
(In reply to Bernd Edlinger from comment #10)
but this should'nt be neccessary then?
if (bitoffset *bitpos)
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #12)
I meant the change here is not necessary, because after the
if (*bitpos 0) {...},
*offset can no longer be NULL, and I'd leave the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51671
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Another testcase:
template typename T, typename U
struct S
{
static void f()
{
typedef T q;
typedef U q;
}
};
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 4 Nov 2013, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
Jakub Jelinek jakub at gcc dot gnu.org changed:
What
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58946
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Mon Nov 4 10:29:42 2013
New Revision: 204348
URL: http://gcc.gnu.org/viewcvs?rev=204348root=gccview=rev
Log:
PR tree-optimization/58946
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #14 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #13)
(In reply to Bernd Edlinger from comment #12)
I meant the change here is not necessary, because after the
if (*bitpos 0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58981
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00179.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #8 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
Well, what does OpenCL specify here?
The logical operators and (), or (||) operate on all scalar and vector
built-in types. For scalar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
Created attachment 31148 [details]
gcc49-pr58978.patch
While your patch will work too, I think it is better to fix it differently,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #15 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Bernd Edlinger from comment #14)
(In reply to Jakub Jelinek from comment #13)
(In reply to Bernd Edlinger from comment #12)
I meant the change here is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58946
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #9 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 4 Nov 2013, glisse at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #8 from Marc Glisse glisse at gcc dot gnu.org ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #10 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #9)
Thus no short-circuiting for vector or ||.
Indeed. Though we already deviated from OpenCL for ?: and as mentioned in my
patch we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
I've posted a patch for this a while ago, but so far it hasn't showed up on
gcc-patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #15)
(In reply to Bernd Edlinger from comment #14)
(In reply to Jakub Jelinek from comment #13)
(In reply to Bernd Edlinger from comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #17 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
struct T {
unsigned char b : 8;
unsigned char s : 1;
};
struct S {
char x;
struct T t[1];
};
void function(int x, struct S *p)
{
if (x == -1)
p-t[x].s = 0;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #18 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Well, how about this version?
Does'nt it look like a much smaller change?
--- expr.c.jj2013-10-31 14:57:05.0 +0100
+++ expr.c2013-11-04 12:51:55.013931114
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #18)
Well, how about this version?
Does'nt it look like a much smaller change?
--- expr.c.jj 2013-10-31 14:57:05.0 +0100
+++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
CC||hp at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58943
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
Bug ID: 58985
Summary: [4.7 Regression]: gcc.dg/pr57518.c scan-rtl-dump-not
ira REG_EQUIV...
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58942
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #15 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Could you all give me some idea on how soon this might be applied?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
Created attachment 31149
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31149action=edit
pr57518.c.211r.ira
IRA dump at r204211 (plus reverted breakage patch) as scanned by the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
Created attachment 31150
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31150action=edit
pr57518.c.210r.ira
IRA dump of r204212 (plus reverted breakage patch) as scanned by the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58933
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58915
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
True, it may still help in some cases though.
On my list of nice-things-to-have is still a generic predicate collecting
simplification machinery similar to what we have with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
Created attachment 31151
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31151action=edit
pr57518.s
Generated assembly. The contents at r204211 is identical to that at r204212.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58986
Bug ID: 58986
Summary: [C++11] Narrowing for initializer lists must be an
error
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58966
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
Target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58964
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58958
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
--- Comment #9 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
See also PR58985.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58956
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58955
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58951
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Ah, the reason why r199252 doesn't fix this is that esra changes o.f0 = 1;
into a MEM_REF, essentially *(char *)o = 1, because the f0 has 8 bits.
So, determine_known_aggregate_parts
1 - 100 of 315 matches
Mail list logo
