On Mon, Nov 29, 2010 at 11:51 PM, Miles Bader mi...@gnu.org wrote:
Ian Lance Taylor i...@google.com writes:
We could decide not to do anything about this, but I don't think it's a
non-issue. With -std=gnu++98 g++ accepts this invalid code. That is,
it is a g++ extension, and the code is
On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?
'cause I want the compiler to be able to use (inline) the underlying values.
On Tue, Nov 30, 2010 at 2:17 AM, Miles Bader mi...@gnu.org wrote:
On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?
'cause I
Gabriel Dos Reis g...@integrable-solutions.net writes:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?
'cause I want the compiler to be able to use (inline) the underlying values.
then write even simple code:
On Tue, Nov 30, 2010 at 2:33 AM, Miles Bader mi...@gnu.org wrote:
Gabriel Dos Reis g...@integrable-solutions.net writes:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?
'cause I want the compiler to be able to
Gabriel Dos Reis g...@integrable-solutions.net writes:
I.e., I can choose between various types of ugliness -- wrong namespace,
funny syntax, or (currently) gcc-dependence. I used to choose gcc-
dependence, but then switched to funny syntax. In the future when c++0x
support is more
On Tue, Nov 30, 2010 at 9:17 AM, Miles Bader mi...@gnu.org wrote:
On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?
'cause I
On Tue, 30 Nov 2010, Richard Guenther wrote:
On Tue, Nov 30, 2010 at 9:17 AM, Miles Bader mi...@gnu.org wrote:
On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing)
Richard Guenther richard.guent...@gmail.com writes:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?
'cause I want the compiler to be able to use (inline) the underlying values.
I think it'll do that with
Hi,
I am working on how to improve restrict. I noticed
that my changes lead to failure of pr38212. After looking
at its code, I think the test may not be valid according
to c99 standard.
C99 standard 6.7.3.1:
EXAMPLE 4 The rule limiting assignments between restricted pointers does not
On Tue, Nov 30, 2010 at 2:07 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am working on how to improve restrict. I noticed
that my changes lead to failure of pr38212. After looking
at its code, I think the test may not be valid according
to c99 standard.
C99 standard 6.7.3.1:
EXAMPLE 4
On 2010-11-29, 22:26:31 -0800, Andrew Pinski pins...@gmail.com wrote:
Except it is documented as a Deprecated feature already so it is
different from a documented extension. I would say we should just
drop it as it is documented already as deprecated.
Are you going to drop the feature from
-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com]
Sent: 30 November 2010 13:53
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org
Subject: Re: Revisit of pr38212 regarding restrict definition
On Tue, Nov 30, 2010 at 2:07 PM, Bingfeng Mei b...@broadcom.com wrote:
On Tue, Nov 30, 2010 at 3:29 PM, Bingfeng Mei b...@broadcom.com wrote:
-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com]
Sent: 30 November 2010 13:53
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org
Subject: Re: Revisit of pr38212 regarding restrict definition
On
gcc 4.4.5, powerpc32 does not fail
const char wd[6] = Wednes;
even though wd only has room for 6 chars. Is this intended?
Jocke
On Tue, Nov 30, 2010 at 5:39 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Nov 30, 2010 at 9:17 AM, Miles Bader mi...@gnu.org wrote:
On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
If you are doing that, why don't you write a simpler code
CALL FOR PAPERS
===
Ninth Workshop on Explicitly Parallel Instruction
Computing Architectures and Compiler Technology (EPIC-9)
April 2 or 3 (TBD), 2011
Chamonix, France
In conjunction with the IEEE/ACM International Symposium
on Code Generation and Optimization (CGO)
Researchers
Hi Joakim,
On Tue, Nov 30, 2010 at 03:40:12PM +0100, Joakim Tjernlund wrote:
gcc 4.4.5, powerpc32 does not fail
const char wd[6] = Wednes;
even though wd only has room for 6 chars. Is this intended?
Which language are you using? ;-)
In C++, it's forbidden (there has to be enough space for the
On Tue, Nov 30, 2010 at 11:40 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
I agree. I think we have a case here where people will
say anything to justify a (mis)feature that leads to brittle
codes
Why does it lead to brittle codes?
If people are worried about multiple
On Tue, Nov 30, 2010 at 9:07 AM, Miles Bader mi...@gnu.org wrote:
If people are worried about multiple translation units, they
will still have to provide a definition outside the class -- most
likely
Why?
Because its address may be silently taken (through
binding to references), therefore a
Andrew Pinski pins...@gmail.com writes:
On Mon, Nov 29, 2010 at 4:20 PM, Ian Lance Taylor i...@google.com wrote:
We could decide not to do anything about this, but I don't think it's a
non-issue. With -std=gnu++98 g++ accepts this invalid code. That is,
it is a g++ extension, and the code
Hello,
I'm not able to build GCC (4.4.5 and 4.5.1 from the official releases) on AIX
(config.guess: powerpc-ibm-aix6.1.0.0). They both fail exactly the same way:
build/genattrtab ../../gcc/config/rs6000/rs6000.md \
insn-conditions.md tmp-attrtab.c
out of memory allocating 16 bytes after a
The problem was caused by ulimits, so please ignore my report.
I feel sorry for generating spurious input -- the platform is totally insane.
Best regards
Piotr Wyderski
Why is not
const char cstr[] = mystr;
const int myint = 3;
added to a read only section?
Especially since
const int myarr[]={1,2,3};
is placed in .rodata.
hmm, -G 0 does place these in .rodata but why do I have to specify that?
This is a follow up / rediff to my previous patch at
http://gcc.gnu.org/ml/fortran/2010-11/msg00339.html, incorporating the
comments by Ralf and Matthias.
Changes:
- Parts of the patch have been committed separately
- Removed licence text from .texi file following the suggestion of
Matthias -
This is related to http://gcc.gnu.org/ml/gcc/2010-11/msg00623.html
I write about it again because the following seems too bad:
$ cat test1.cc
struct X {
X()=default;
X(X)=default;
X(X const)=delete;
//some very large or non-copyable content
};
X test() {
X const x={};
{
//a lot
Tobias Burnus bur...@net-b.de writes:
@@ -186,5 +194,20 @@
multilib_arg=
fi
+
+# We would like our source tree to be readonly. However when releases or
+# pre-releases are generated, the flex/bison generated files as well as the
+# various formats of manuals need to be included
On 30 November 2010 20:33, Roman Kononov wrote:
This is related to http://gcc.gnu.org/ml/gcc/2010-11/msg00623.html
I write about it again because the following seems too bad:
$ cat test1.cc
struct X {
X()=default;
X(X)=default;
X(X const)=delete;
//some very large or non-copyable
On 30 November 2010 20:40, Jonathan Wakely wrote:
On 30 November 2010 20:33, Roman Kononov wrote:
This is related to http://gcc.gnu.org/ml/gcc/2010-11/msg00623.html
I write about it again because the following seems too bad:
$ cat test1.cc
struct X {
X()=default;
X(X)=default;
X(X
2010-11-30 20:40 CST, Jonathan Wakely jwakely@gmail.com said:
On 30 November 2010 20:33, Roman Kononov wrote:
$ cat test1.cc
struct X {
X()=default;
X(X)=default;
X(X const)=delete;
//some very large or non-copyable content
};
X test() {
X const x={};
{
//a lot of code
2010-11-30 20:46 CST, Jonathan Wakely jwakely@gmail.com said:
On 30 November 2010 20:40, Jonathan Wakely wrote:
$ cat test1.cc
struct X {
X()=default;
X(X)=default;
X(X const)=delete;
//some very large or non-copyable content
};
X test() {
X const x={};
{
//a lot of code
On Tue, Nov 30, 2010 at 12:53 PM, Roman Kononov ro...@binarylife.net wrote:
2010-11-30 20:40 CST, Jonathan Wakely jwakely@gmail.com said:
However, that doesn't change the fact you're trying to move from a
const object, which is obviously wrong.
Not really, because the 2 const objects are
On Tue, 30 Nov 2010, Tobias Burnus wrote:
This is a follow up / rediff to my previous patch at
http://gcc.gnu.org/ml/fortran/2010-11/msg00339.html, incorporating the
comments by Ralf and Matthias.
Changes:
- Parts of the patch have been committed separately
- Removed licence text from
On Tue, 30 Nov 2010, Tobias Burnus wrote:
+Bugs in the GCC Quad-Precision Math Library implementation should be
+reported via @uref{http://gcc.gnu.org/bugzilla/, bugzilla}.
Do not hardcode bug reporting URLs like this. You should allow them to
vary with --with-bugurl (see what the main GCC
On Tue, Nov 30, 2010 at 2:53 PM, Roman Kononov ro...@binarylife.net wrote:
2010-11-30 20:40 CST, Jonathan Wakely jwakely@gmail.com said:
On 30 November 2010 20:33, Roman Kononov wrote:
$ cat test1.cc
struct X {
X()=default;
X(X)=default;
X(X const)=delete;
//some very large or
2010-11-30 13:03 CST, James Dennett james.denn...@gmail.com said:
If you want to be able to change an object during its lifetime, don't
make it const.
I exactly want to be unable to change an object during its lifetime
except when it is moved-and-destroyed.
Thanks
On Tue, Nov 30, 2010 at 3:02 PM, Roman Kononov ro...@binarylife.net wrote:
2) define a copy constructor, explicitly-defaulted if you wish.
What if the copy constructor is too expensive and I have to use move
constructor?
the discussion would be less confused if you identify clearly the
Mozilla seems to receive a report of an exploitable operator new[]
overflow every couple of months now. Obviously, this is not good.
What is necessary so that GCC can fix this code generation issue?
I've created a patch, together with a test case, but it has not been
approved, nor have I been
On Tue, Nov 30, 2010 at 3:11 PM, Roman Kononov ro...@binarylife.net wrote:
2010-11-30 13:03 CST, James Dennett james.denn...@gmail.com said:
If you want to be able to change an object during its lifetime, don't
make it const.
I exactly want to be unable to change an object during its lifetime
2010-11-30 15:13 CST, Gabriel Dos Reis g...@integrable-solutions.net
said:
On Tue, Nov 30, 2010 at 3:11 PM, Roman Kononov ro...@binarylife.net wrote:
I exactly want to be unable to change an object during its lifetime
except when it is moved-and-destroyed.
isn't that a question for C++ forums?
On 30 November 2010 21:18, Roman Kononov ro...@binarylife.net wrote:
2010-11-30 15:13 CST, Gabriel Dos Reis g...@integrable-solutions.net
said:
On Tue, Nov 30, 2010 at 3:11 PM, Roman Kononov ro...@binarylife.net wrote:
I exactly want to be unable to change an object during its lifetime
except
2010-11-30 21:20 CST, Jonathan Wakely jwakely@gmail.com said:
We do. The point is your question is off-topic on this list, because
you are complaining about the C++0x language, which as far as we know
GCC implements correctly. If you don't like the language, complain
somewhere else.
Then
On Tue, 30 Nov 2010, Florian Weimer wrote:
Mozilla seems to receive a report of an exploitable operator new[]
overflow every couple of months now. Obviously, this is not good.
What is necessary so that GCC can fix this code generation issue?
I've created a patch, together with a test case,
On Tue, Nov 30, 2010 at 3:34 PM, Roman Kononov ro...@binarylife.net wrote:
2010-11-30 21:20 CST, Jonathan Wakely jwakely@gmail.com said:
We do. The point is your question is off-topic on this list, because
you are complaining about the C++0x language, which as far as we know
GCC implements
On Tue, Nov 30, 2010 at 3:38 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Tue, 30 Nov 2010, Florian Weimer wrote:
Mozilla seems to receive a report of an exploitable operator new[]
overflow every couple of months now. Obviously, this is not good.
What is necessary so that GCC can
On 30 November 2010 21:45, Gabriel Dos Reis wrote:
On Tue, Nov 30, 2010 at 3:34 PM, Roman Kononov ro...@binarylife.net wrote:
2010-11-30 21:20 CST, Jonathan Wakely jwakely@gmail.com said:
We do. The point is your question is off-topic on this list, because
you are complaining about the C++0x
Roman Kononov ro...@binarylife.net writes:
2010-11-30 15:13 CST, Gabriel Dos Reis g...@integrable-solutions.net
said:
On Tue, Nov 30, 2010 at 3:11 PM, Roman Kononov ro...@binarylife.net wrote:
I exactly want to be unable to change an object during its lifetime
except when it is
The two programs below differ by the location of =default applied to
the move constructor. In the first program, it is defaulted inside
the class during declaration. In the second program, it is defaulted
outside the class in the definition.
The first program does not compile. The second does
Snapshot gcc-4.4-20101130 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20101130/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, Nov 30, 2010 at 01:49:23PM -0800, Gabriel Dos Reis wrote:
The existing GCC behaviour is a bit more perverse than the
C malloc() case as in
new T[n]
there is no multiplication that could be credited to careless programmer.
The multiplication is introduced by GCC.
... which
On 30 November 2010 22:51, Roman Kononov wrote:
The two programs below differ by the location of =default applied to
the move constructor. In the first program, it is defaulted inside
the class during declaration. In the second program, it is defaulted
outside the class in the definition.
Hi
Minor build bug: The cpp sanity check fails because it is looking for cpp
in /lib instead of /usr/bin
Summary of test results:
=== gcc Summary ===
# of expected passes72577
# of unexpected failures22
# of unexpected successes 32
# of expected
Quoting Richard Guenther richard.guent...@gmail.com:
Btw, I think these partial conversions are not appropriate for stage3
and if accepted for stage1 you should commit yourself to do a
transition that at least allows converting targets (thus, I don't like
your incremental patches at all).
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Attachment #22403|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46717
--- Comment #6 from Maeyanie maeyanie at deathwyrm dot com 2010-11-30
08:15:41 UTC ---
Created attachment 22576
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22576
Profiling data
Since this crash appears only with -fprofile-use, the related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46716
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674
--- Comment #4 from Jie Zhang jiez at gcc dot gnu.org 2010-11-30 10:00:05 UTC
---
Hah, I now know the root cause. It's *__GI_memchr that is added into the
visible point set since it's a user provided name. But GCC looks for
__GI_memchr later,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45949
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-30
10:00:13 UTC ---
Author: rguenth
Date: Tue Nov 30 10:00:06 2010
New Revision: 167291
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167291
Log:
2010-11-30 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46717
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44986
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-30
10:00:58 UTC ---
Author: rguenth
Date: Tue Nov 30 10:00:51 2010
New Revision: 167292
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167292
Log:
2010-11-30 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43659
devurandom at gmx dot net changed:
What|Removed |Added
CC||devurandom at gmx dot net
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46718
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #30 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-30
10:15:02 UTC ---
From a quick look I can see that with -fstrict-aliasing we will never consider
ptr-link.next to alias ptr-list.next (so if they are made to alias via
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46719
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-30
10:36:42 UTC ---
Reduced to get rid of library dependencies:
template typename Return, typename... ArgTypes
struct function
{
templatetypename Functor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46718
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46719
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46717
--- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2010-11-30 10:57:31
UTC ---
The compilation chokes with:
buf$_M_ptr_138 = PHI D.353926_28(30), buf$_M_ptr_132(40), (54)
Is this correct gimple?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46721
Summary: Unnecessary stack instructions are generated for SPU
when returning a struct
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674
--- Comment #5 from Jie Zhang jiez at gcc dot gnu.org 2010-11-30 11:17:47 UTC
---
Created attachment 22577
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22577
The patch
I'm testing this patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46717
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45949
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44986
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-30
12:17:31 UTC ---
Confirmed.
Also doesn't work with -flto-partition=none:
./xgcc -B. -o t t.c -flto -m32 -march=i386 -flto-partition=none
In file included from t.c:16:0,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46716
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-30
12:22:26 UTC ---
I think there is a dup somewhere. Note that IMHO disabling sse2 makes the
code suspicious as it cannot fulfill the ABI (I think the kernel uses
-mno-sse2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #10 from Michael Haubenwallner michael.haubenwallner at salomon
dot at 2010-11-30 12:22:43 UTC ---
(In reply to comment #9)
I believe the line number field in XCOFF is defined in
/usr/include/linenum.h.
According to that file, in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46717
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46716
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46718
--- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2010-11-30 12:52:46 UTC ---
Author: paolo
Date: Tue Nov 30 12:52:38 2010
New Revision: 167294
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167294
Log:
2010-11-30 Paolo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #31 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-30
12:57:29 UTC ---
From a quick look I can see that with -fstrict-aliasing we will never consider
ptr-link.next to alias ptr-list.next (so if they are made to alias via
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46594
--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-30
12:58:47 UTC ---
Author: burnus
Date: Tue Nov 30 12:58:42 2010
New Revision: 167295
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167295
Log:
2010-11-30 Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46717
--- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-30
13:12:59 UTC ---
Before transform:
;; succ: 50 (eh,exec) 40 [100.0%] count:63 (fallthru,exec)
bb 39:
D.479965_99 = MEM[(struct _List_node_base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46721
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46716
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46722
Summary: [4.6 Regression] Missed fma for x*x + y
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46722
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723
Summary: internal compiler error: in
get_initial_def_for_induction, at
tree-vect-loop.c:2431
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723
--- Comment #1 from Matthias Kretz kretz at kde dot org 2010-11-30 13:50:55
UTC ---
Created attachment 22578
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22578
preprocessed source which makes G++ 4.5.1 ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
Summary: Wrong debug info: Invalid variable location
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: debug
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
Andreas Krebbel krebbel at gcc dot gnu.org changed:
What|Removed |Added
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46717
--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-30
14:33:03 UTC ---
Author: rguenth
Date: Tue Nov 30 14:33:00 2010
New Revision: 167298
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167298
Log:
2010-11-30 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46717
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org 2010-11-30
14:37:39 UTC ---
Compiling with
GCC 4.5.2 (gcc version 4.5.2 20101108 (prerelease) [gcc-4_5-branch revision
166433] (GCC))
GDB returns value optimized out for 'a2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46722
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=46594
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46722
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #32 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-30
15:10:58 UTC ---
The problem appears to be deeply rooted in the Ring construct, more precisely
in the HEAD trick. IIUC the idea is to attach a doubly-linked list to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46725
Summary: [4.6 Regression] ICE when compiling
libstdc++-v3/include/precompiled/stdc++.h
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: blocker
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263
--- Comment #7 from Michael Schulze mschulze at ivs dot cs.ovgu.de 2010-11-30
15:16:20 UTC ---
Created attachment 22579
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22579
alternative patch using register r15 instead of r20 avoids
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46726
Summary: x*x has different cost than pow(x,2) with -ffast-math
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
1 - 100 of 175 matches
Mail list logo
