yazdanbakhsh amir.yazdanbak...@gmail.com writes:
I want to exclude XORI from the instruction set of a cpu. I deleted all the
XORI in md file. But when I compiled my program some XORI operation still
exist. how this would be possible?
It could be printed directly from a .c file in your
STL is good, but may surplus what GCC really needs, and will introduce
many complex, uncontrollable C++ features.
Personally, I think what GCC need most is an simple, generic, one
layer containers of pointers to objects, with their iterators.
Instead of containers of arbitrary types.
Steven Bosscher stevenb@gmail.com wrote on 02/06/2010 06:13:36 PM:
On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell m...@codesourcery.com
wrote:
Ulrich Weigand wrote:
So the question is: The goal is to have hooks, not macros, right? If
so, can reviewers please take care to reject
On 06/02/2010 09:19 PM, DJ Delorie wrote:
Robert Dewar de...@adacore.com writes:
I would create a specific committee to reccommend a C++ coding
standard (preferably based on one of the standard ones available, such
as Google).
Doing things in secret like that is not the Open Source Way.
On 06/01/2010 08:10 AM, Ian Lance Taylor wrote:
Mark Mitchellm...@codesourcery.com writes:
I am pleased to report that the GCC Steering Committee and the FSF have
approved the use of C++ in GCC itself. Of course, there's no reason for
us to use C++ features just because we can. The goal is
On Thu, Jun 3, 2010 at 10:24 AM, Andrew Haley a...@redhat.com wrote:
On 06/02/2010 09:19 PM, DJ Delorie wrote:
Robert Dewar de...@adacore.com writes:
I would create a specific committee to reccommend a C++ coding
standard (preferably based on one of the standard ones available, such
as
On Thu, Jun 3, 2010 at 1:49 AM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
As I was about to check in the -mrecip changes for powerpc on GCC 4.6, I
figured to get a start on documentation, and I was going to edit the
gcc-4.6/changes.html file. I realize this is early in the cycle, but
Steven Bosscher wrote:
Indeed. It is, well, perhaps not surprising, but quite annoying (to me
at least) that a possible move to C++ as implementation language of
GCC is so much bigger news than all the amazing amounts of work done
in the last few years on things like LTO, the vectorizer, IRA,
On Thu, Jun 3, 2010 at 9:01 AM, Ira Rosen i...@il.ibm.com wrote:
Steven Bosscher stevenb@gmail.com wrote on 02/06/2010 06:13:36 PM:
On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell m...@codesourcery.com
wrote:
Ulrich Weigand wrote:
So the question is: The goal is to have hooks, not
On Thu, Jun 3, 2010 at 12:51 PM, Robert Dewar de...@adacore.com wrote:
Steven Bosscher wrote:
Indeed. It is, well, perhaps not surprising, but quite annoying (to me
at least) that a possible move to C++ as implementation language of
GCC is so much bigger news than all the amazing amounts of
Richard Guenther richard.guent...@gmail.com wrote on 03/06/2010 02:00:00
PM:
tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST
tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST
tree-vectorizer.h:#ifndef TARG_SCALAR_STMT_COST
tree-vectorizer.h:#ifndef TARG_SCALAR_LOAD_COST
On Thu, Jun 3, 2010 at 1:14 PM, Ira Rosen i...@il.ibm.com wrote:
Richard Guenther richard.guent...@gmail.com wrote on 03/06/2010 02:00:00
PM:
tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST
tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST
tree-vectorizer.h:#ifndef
Hello!
I'm looking into i386.md, where we have a bunch of instances of
following comment:
; Current assemblers are broken and do not allow @GOTOFF in
; ought but a memory context.
Code, following this comment disables or special-cases pic_symbolic_operands.
I'm
2010/6/3 Uros Bizjak ubiz...@gmail.com:
Hello!
I'm looking into i386.md, where we have a bunch of instances of
following comment:
; Current assemblers are broken and do not allow @GOTOFF in
; ought but a memory context.
Code, following this comment disables or
On Thu, 3 Jun 2010, Richard Guenther wrote:
As I was about to check in the -mrecip changes for powerpc on GCC 4.6,
I figured to get a start on documentation, and I was going to edit the
gcc-4.6/changes.html file. I realize this is early in the cycle, but
did we want to create the gcc-4.6
On Thu, Jun 03, 2010 at 03:31:30PM +0200, Gerald Pfeifer wrote:
On Thu, 3 Jun 2010, Richard Guenther wrote:
As I was about to check in the -mrecip changes for powerpc on GCC 4.6,
I figured to get a start on documentation, and I was going to edit the
gcc-4.6/changes.html file. I realize
On 06/03/2010 12:51 PM, Robert Dewar wrote:
Steven Bosscher wrote:
Indeed. It is, well, perhaps not surprising, but quite annoying (to me
at least) that a possible move to C++ as implementation language of
GCC is so much bigger news than all the amazing amounts of work done
in the last few
On 06/03/2010 12:09 PM, Richard Guenther wrote:
On Thu, Jun 3, 2010 at 12:51 PM, Robert Dewar de...@adacore.com wrote:
Steven Bosscher wrote:
Indeed. It is, well, perhaps not surprising, but quite annoying (to me
at least) that a possible move to C++ as implementation language of
GCC is so
On Thu, Jun 3, 2010 at 6:09 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Indeed ;) I'd like us to switch to the C / C++ common soon (thus,
use C for stage1 and C++ for stage2 and stage3). That will help
us sort out problems on the various host/target combinations that
will surely
On Thu, 2010-06-03 at 13:05 -0500, Gabriel Dos Reis wrote:
On Thu, Jun 3, 2010 at 6:09 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Indeed ;) I'd like us to switch to the C / C++ common soon (thus,
use C for stage1 and C++ for stage2 and stage3). That will help
us sort out
Mark Mitchell m...@codesourcery.com:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
initial subset of C++ used in GCC.
Umm...?
Larry Evans cppljev...@suddenlink.net:
claims that switch statements are faster than virtual function calls.
That's not really interesting, is it? The overhead and downsides of
virtual functions are well known.
The upside is the possibility to use polymorphism to make frameworks.
All kinds
On Thu, 2010-06-03 at 14:24 +0200, Uros Bizjak wrote:
I'm looking into i386.md, where we have a bunch of instances of
following comment:
; Current assemblers are broken and do not allow @GOTOFF in
; ought but a memory context.
Code, following this comment disables
Steinar Bang s...@dod.no writes:
Mark Mitchell m...@codesourcery.com:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
initial subset
On Thu, Jun 3, 2010 at 6:09 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Indeed ;) I'd like us to switch to the C / C++ common soon (thus,
use C for stage1 and C++ for stage2 and stage3). That will help
us sort out problems on the various host/target combinations that
will
Andrew Haley wrote:
Right, but I didn't think there was any plan to convert en masse to
C++ -- just to allow people to use it where appropriate. Apart from
anything else, there's always a nonzero probablility of breaking
something.
It's the where appropriate that is the sneaky detail here
Steinar Bang wrote:
Mark Mitchell m...@codesourcery.com:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
initial subset of C++ used in
Okay, I guess we 'll just disable the __wur's by default then -- as introducing
an unnecessary hard-to-avoid noise. I recon many other people do the same.
Thanks nevertheless. It's still a useful feature, just not flexible enough to
use it for *everyday* compilation.
Denis
On 3 June 2010 20:35, Steinar Bang wrote:
Mark Mitchell m...@codesourcery.com:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
initial
Snapshot gcc-4.5-20100603 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100603/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi,
On Mon, May 17, 2010 at 15:15, Sandeep Soni soni.sande...@gmail.com wrote:
Hi,
As part of GSoC 2010, I am developing a front end for GIMPLE.
You can find the basic theme of the project at:
http://gcc.gnu.org/wiki/GimpleFrontEnd
One of the most important components in this GIMPLE Front
Bonjour,
pour l'achat ou la vente de votre propriété (maison, chalet, condo, terrain, ou
commerce),
pour du prêt hypothécaire ou une reprise de finance, visitez:
http://www.voscomplicesimmobilier.com
Un service complet, rapide et professionnel.
Merci.
Vos complices immobiliers.
Jean-Pierre et
--- Comment #7 from rwild at gcc dot gnu dot org 2010-06-03 06:33 ---
Subject: Bug 42798
Author: rwild
Date: Thu Jun 3 06:32:27 2010
New Revision: 160210
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160210
Log:
Import AC_CHECK_DECL for C++ fixes from git Autoconf.
config/:
--- Comment #8 from rwild at gcc dot gnu dot org 2010-06-03 06:45 ---
Subject: Bug 42798
Author: rwild
Date: Thu Jun 3 06:45:02 2010
New Revision: 160211
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160211
Log:
Fix PR bootstrap/42798.
libiberty/:
PR bootstrap/42798
--- Comment #58 from iains at gcc dot gnu dot org 2010-06-03 07:57 ---
(In reply to comment #57)
(In reply to comment #46)
Other than that, you guys manage to write a lot about this but still not
answer
all questions (both of which makes it unattractive for others to look at a
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-03 08:47 ---
(In reply to comment #9)
I've been experimenting with this patch, which warns if there is a missing
mem-initializer for a scalar.
It gives a false positive for cases were the member is assigned to in the
--- Comment #59 from jakub at gcc dot gnu dot org 2010-06-03 09:10 ---
Why would be volatile needed? pthread_join returning guarantees that the other
thread's thread function finished, and the variable is only written in that
thread, there is no data race on it.
--
--- Comment #11 from jwakely dot gcc at gmail dot com 2010-06-03 09:18
---
(In reply to comment #10)
(In reply to comment #9)
I've been experimenting with this patch, which warns if there is a missing
mem-initializer for a scalar.
It gives a false positive for cases were the
--- Comment #32 from iains at gcc dot gnu dot org 2010-06-03 09:21 ---
(In reply to comment #31)
The latest proposed patch triggers one additional g++ tls failure...
FAIL: g++.dg/tls/init-2.C (test for excess errors)
this test is not enabled for emutls at present;
yes, I know it
--- Comment #12 from jwakely dot gcc at gmail dot com 2010-06-03 09:27
---
Apart from the false positives, another problem is that the check for
layout_pod_type_p is not right. An empty class is a POD but doesn't need
initialising.
--
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-03 09:30 ---
Unfortunately the preprocessed source from comment #1 seems to be
damaged, I get loads of errors like error: stray '\336' in program.
Can you please re-upload it? Thanks.
--
--- Comment #13 from paolo dot carlini at oracle dot com 2010-06-03 10:16
---
About -Weffc++, we also have a PR (16166) about splitting it... Not that I
think we should really do that - adding a dozen of -Weffc++-type warnings - but
I believe it would be a good idea to finally resolve
Booting with rev. 160214:
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44397
--- Comment #60 from rwild at gcc dot gnu dot org 2010-06-03 10:33 ---
(In reply to comment #59)
Why would be volatile needed? pthread_join returning guarantees that the
other
thread's thread function finished, and the variable is only written in that
thread, there is no data race
Probably introduced by the fix for bug 44385, given it happens in the same
place and removing -fuse-linker-plugin fixes it again: With gcc 4.5.1 rev
160157, linking Qt's moc with -flto -fuse-linker-plugin results in
g++ -Wl,-rpath-link,/usr/src/ark/BUILD/qt/lib -m64 -O2 -fomit-frame-pointer
-fweb
--- Comment #1 from bero at arklinux dot org 2010-06-03 10:44 ---
Created an attachment (id=20816)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20816action=view)
ltrace output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44398
--- Comment #61 from jakub at gcc dot gnu dot org 2010-06-03 10:47 ---
Of course pthread_join implies all outstanding memory stores of the dead thread
complete before pthread_join returns. And, pthread_join is a non-inlined
function call, a_in_other_thread is a global variable, so the
--- Comment #62 from iains at gcc dot gnu dot org 2010-06-03 10:59 ---
(In reply to comment #60)
(In reply to comment #59)
Is this bug just a dupe of PR 44132 now?
No, PR44132 applies to all darwin versions.
However, I think it *is* a dup of PR44304 (which relates to the fail of
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-06-03 11:12 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #14 from jwakely dot gcc at gmail dot com 2010-06-03 11:24
---
Created an attachment (id=20817)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20817action=view)
better -Wmeminit patch
This version ignores empty classes and checks for a nontrivial default ctor
instead
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 11:28 ---
That isn't very helpful ;) Can you try to reproduce this with current trunk?
What version of gold are you using?
Can you produce a testcase? Try doing an incremental link (-r), and strip
libraries and object
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-03 11:28 ---
ipa-reference.c:(.text+0x28825): undefined reference to
`lto_varpool_encoder_size'
has been fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from bero at arklinux dot org 2010-06-03 11:38 ---
Exact same error with 4.5.1 branch rev. 160157, compiling trunk
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-03 12:07 ---
Subject: Bug 44375
Author: jakub
Date: Thu Jun 3 12:07:18 2010
New Revision: 160219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160219
Log:
PR debug/44375
* tree-cfg.c
I'm trying to write windows console application working with directories, and i
discover that arguments processed not right. For example:
#include iostream
int main ( int argc, char *argv[], char *envp[] ) {
std::cout you have argc arguments;
}
resulting:
a.exe a a
you have 2 arguments
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-03 12:29 ---
This is a problem of your execution environment, not GCC. And AFAICS your
observerd behavior is what is expected.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from lists at eitanadler dot com 2010-06-03 12:38 ---
gcc 4.6.0.20100529 + the patch fixes the problem.
--
lists at eitanadler dot com changed:
What|Removed |Added
--- Comment #63 from iains at gcc dot gnu dot org 2010-06-03 12:50 ---
(In reply to comment #62)
(In reply to comment #60)
(In reply to comment #59)
Is this bug just a dupe of PR 44132 now?
No, PR44132 applies to all darwin versions.
OK, I need to refine that comment.
--- Comment #2 from alexandrfedorov at gmail dot com 2010-06-03 12:50
---
I'm executing my application via cmd.exe from Windows XP. As i know in windows
NOTHING is escaping with backslash. Standard utilities like cacls.exe working
well with such arguments.
Please pay attention to this
--- Comment #64 from howarth at nitro dot med dot uc dot edu 2010-06-03
13:03 ---
I've also had a report for the fink gcc45-4.5.0-1000 package of the boot strap
comparison failure occuring (rarely) on a single processor PowerPC (building
with make -j 1).
--
--- Comment #65 from iains at gcc dot gnu dot org 2010-06-03 13:17 ---
*** Bug 44304 has been marked as a duplicate of this bug. ***
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from iains at gcc dot gnu dot org 2010-06-03 13:17 ---
*** This bug has been marked as a duplicate of 43170 ***
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 13:18 ---
GCC does not have any influence on how arguments are split, it is your
execution environment (including the runtime, which might be cygwin or
mingw).
This is not a GCC bug, please do not reopen it.
--
rguenth
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-06-03 13:24
---
If it's a cygwin executable the behaviour might be caused by cygwin's globber
In any case, it's not gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44399
--- Comment #66 from howarth at nitro dot med dot uc dot edu 2010-06-03
13:46 ---
At the risk of confusing the issues here, I would point out...
http://gcc.gnu.org/ml/gcc/2010-04/msg00044.html
where I observed that 20_util/shared_ptr/thread/default_weaktoshared.cc
execution test
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-06-03 13:47
---
The problem seems to have vanished, so eventually the fix can be backported
(together with the typo fix in the configure script obviously).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
Sent from my iPhone
On Jun 3, 2010, at 5:15 AM, alexandrfedorov at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
I'm trying to write windows console application working with
directories, and i
discover that arguments processed not right. For example:
#include iostream
int main ( int
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-03 13:48 ---
Mine. See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02424.html for an
outline for a possible fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gmail dot com 2010-06-03 13:48 ---
Subject: Re: New: Problem with command line arguments in windows
Sent from my iPhone
On Jun 3, 2010, at 5:15 AM, alexandrfedorov at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
I'm trying to write windows
--- Comment #5 from zsojka at seznam dot cz 2010-06-03 14:03 ---
This stopped crashing sometimes between r158969 and r159387 (at x86_64-linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43688
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-06-03 14:14
---
We bootstrap it again and it now seems to install fine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-03 14:22 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
lto/41584
* gcc.dg/lto/20100603-1_0.c: New testcase.
* gcc.dg/lto/20100603-2_0.c: Likewise.
* gcc.dg/lto/20100603-3_0.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.dg/lto/20100603-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20100603-2_0.c
trunk/gcc/testsuite/gcc.dg/lto
--- Comment #2 from christine dot mecklenborg at gmail dot com 2010-06-03
14:33 ---
(In reply to comment #1)
gcc/ld is trying to link as i386
Well the option -arch x86_64 does not exist for the FSF GCC; it is -m64. I
think the issue is that your makefile is built for Apple's GCC
--- Comment #33 from dominiq at lps dot ens dot fr 2010-06-03 14:52 ---
On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of r160219
cause
=== libjava Summary for unix/-m64 ===
# of expected passes2459
# of unexpected failures62
This code is accepted by GCC and compiles
typedef void F();
struct X { F X; };
Not valid according to 9.2/13bullet2. It seems that GCC thinks that F X; is a
data-member (declaring data-members with the name of the class is valid, as
long as there are no user declared constructors).
--
--- Comment #6 from hjl at gcc dot gnu dot org 2010-06-03 14:53 ---
Subject: Bug 43688
Author: hjl
Date: Thu Jun 3 14:53:06 2010
New Revision: 160224
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160224
Log:
Add a testcasef for PR tree-optimization/43688.
2010-06-03 H.J. Lu
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-03 14:55 ---
Fixed by revision 159343:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00395.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
This code is valid, but GCC rejects it:
struct X { int X; };
int X::*p = X::X;
// error: taking address of constructor 'X::X'
GCC apparently seems to think that X::X looks up to the injected class name,
and thus (by 3.4.3.1/1a) would name the constructor. But the name of the
non-static data
--- Comment #34 from iains at gcc dot gnu dot org 2010-06-03 15:03 ---
(In reply to comment #33)
On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of
r160219
cause
=== libjava Summary for unix/-m64 ===
# of expected passes2459
#
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-06-03 15:03 ---
This is fixed. I have a testcase + testsuite patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
This code is valid, but rejected by GCC:
struct A { void f(); };
typedef void F();
struct B { friend F A::f; };
// error: type 'A' is not derived from type 'B'
--
Summary: GCC does not accept friend function declarations using a
typedef for function type.
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-03 15:07 ---
The assert has been removed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 15:08 ---
*** Bug 42675 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:08 ---
Similar to PR41844.
*** This bug has been marked as a duplicate of 41844 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-03 15:13 ---
Re-confirmed on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-03 15:14 ---
Ah, it does not work because we mangle foobar to foobar.1234, not because
we eliminate it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038
--- Comment #35 from dominiq at lps dot ens dot fr 2010-06-03 15:21 ---
Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:
...
set_ld_library_path_env_vars:
ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
invoke:
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:24 ---
Re-confirmed on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:26 ---
Reconfirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 15:28 ---
Fixed for 4.6.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:31 ---
Cary - why does lto-plugin get invoked when gold has errors?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-03 15:32 ---
There was a defect report in the C++ standard about X::X; I cannot remember
what happens with a member variable being named the same as the class name
though.
--
For the following function:
void xxx(short* __restrict__ a, short* __restrict__ b)
{
int i;
for (i = 0; i 8; i++)
{
a[i] = b[i];
}
}
the following is generated in the .optimized file:
xxx (short int * restrict a, short int * restrict b)
{
vector(2) short int * vect_p.27;
--- Comment #1 from roy dot 1rosen at gmail dot com 2010-06-03 15:49
---
Created an attachment (id=20818)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20818action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44403
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 16:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
lto/41921
* lib/lto.exp: Always load gcc.exp.
(lto-obj): For C source files invoke gcc_target_compile.
* g++.dg/lto/20100603-1_0.C: New testcase.
* g++.dg/lto/20100603-1_1.c: Likewise.
Added:
trunk/gcc/testsuite/g++.dg/lto/20100603-1_0.C
trunk/gcc/testsuite/g
--- Comment #36 from iains at gcc dot gnu dot org 2010-06-03 16:08 ---
(In reply to comment #35)
Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:
...
set_ld_library_path_env_vars:
ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
lto/41921
* lib/lto.exp: Always load gcc.exp.
(lto-obj): For C source files invoke gcc_target_compile.
* g++.dg/lto/20100603-1_0.C: New testcase.
* g++.dg/lto/20100603-1_1.c: Likewise.
Modified:
trunk/gcc/testsuite/lib/lto.exp
--
http://gcc.gnu.org/bugzilla
1 - 100 of 176 matches
Mail list logo
