It would help compilation time a little bit, but generating the
assembly code and running the entire assembler is a fairly small
percentage of the overall compilation time--e.g., 3%. It's worth
doing a fair amount of work to speed up compilation by 3%, but linking
the assembler into gcc
Quoting Andi Kleen a...@firstfloor.org:
I admit I haven't looked into gas code, but naively it can't
be all that difficult to e.g. run gas as a thread and
pass the text input through some shared memory buffer?
If you are generating text anyway, there should be little difference to
the existing
On 12/06/2010 16:52, Richard Guenther wrote:
On Sat, Jun 12, 2010 at 3:32 PM, David Browndavid.br...@hesbynett.no wrote:
Ian Lance Taylor wrote:
Manuel López-Ibáñezlopeziba...@gmail.com writes:
This also means that linking your program with non-LTO+whole-program
code may lead to
On Mon, 7 Jun 2010, Tobias Burnus wrote:
It has been reported via the FSF that 'gfortran.info' is copyrighted by
the FSF '1999-2008', although it should be under the form '1999, 2000,
[other years], 2008'.
Fixed in Rev. 160390 using the attached patch.
Thanks, Tobias!
Any chance you could
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
Quoting Andi Kleen a...@firstfloor.org:
I admit I haven't looked into gas code, but naively it can't
be all that difficult to e.g. run gas as a thread and
pass the text input through some shared memory buffer?
If you are
Hi all.
(I have never used these maillists before. Sorry if something wrong here.)
I am newbie in gcc and I need some help.
I am performing some research work in theme of code optimization.
Now I have to write my own optimization pass for gcc. And in this pass
I need to get the instruction codes
Quoting Andi Kleen a...@firstfloor.org:
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
Quoting Andi Kleen a...@firstfloor.org:
I admit I haven't looked into gas code, but naively it can't
be all that difficult to e.g. run gas as a thread and
pass the text input through some
On Sun, Jun 13, 2010 at 4:29 PM, Ilya K ilya...@gmail.com wrote:
Hi all.
(I have never used these maillists before. Sorry if something wrong here.)
I am newbie in gcc and I need some help.
I am performing some research work in theme of code optimization.
Now I have to write my own
On Sun, Jun 13, 2010 at 6:38 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sun, Jun 13, 2010 at 4:29 PM, Ilya K ilya...@gmail.com wrote:
Hi all.
(I have never used these maillists before. Sorry if something wrong here.)
I am newbie in gcc and I need some help.
I am performing
-- Forwarded Message --
Subject: gcc-4.5.0 Success Story with Freecell Solver
Date: Sunday 13 Jun 2010, 17:21:00
From: Shlomi Fish shlo...@iglu.org.il
To: Freecell Solving Discussions fc-solve-disc...@yahoogroups.com
Executive summary: I have built installed gcc-4.5.0 and
On 13/06/2010 16:01, Ilya K wrote:
And who is generating the binary file from the asm file? Does gcc call
the external program? What the name of this program? Or the sources I
need can be found inside the gcc directory?
Gcc calls out to the assembler that it detects (or is instructed to
Andi Kleen a...@firstfloor.org writes:
[...]
Yes but you can't easily pass data back, like accurate instruction lengths.
Wouldn't it be too late by then? Or are you imagining having the
compiler pass trial data to the assembler to create a feedback loop?
- FChE
On Sun, Jun 13, 2010 at 7:38 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
...
What exact use would it be to you having the opcode bytes known during an
optimisation pass? There may be a better/easier way to do whatever it is
you're trying to do.
cheers,
DaveK
My main aim is to
On Jun 13, 2010, at 7:35 AM, Joern Rennecke wrote:
An even if you have a suitable text for the assembler, to link the compiler
with the assembler requires to merge to two complex build systems, and
resolve symbol name clash issues.
Not trying to be inflammatory, but if you guys are really
Trunk g++/x86/160655 with -O0 compile test w/o errors, but with
-O[123] generates undefined symbol
-- cat 2010_06_13.cpp
namespace FOO {
template typename T
class A
{
public:
A(char *pMemMgr = 0);
void Enum();
virtual void OnProv() = 0;
virtual ~A() { }
};
typedef Achar B;
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We could perhaps do that for C/C++ code, but Fortran relies on common
symbols.
Ian
Ilya K ilya...@gmail.com writes:
My main aim is to build platform-dependent optimization based on the
minimizing of hamming distance between the instructions.
Take a look at http://code.google.com/p/mao/ .
Ian
On Sat, Jun 12, 2010 at 8:15 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jun 11, 2010 at 3:42 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
[snip]
x86 assembler isn't an optimizing assembler. -mtune only does
On Sun, 2010-06-13 at 18:29 +0400, Ilya K wrote:
Hi all.
(I have never used these maillists before. Sorry if something wrong here.)
I am newbie in gcc and I need some help.
I am performing some research work in theme of code optimization.
Now I have to write my own optimization pass for
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We could perhaps do that for C/C++ code, but Fortran relies on common
symbols.
Well
On 13/06/2010 20:57, Ian Lance Taylor wrote:
Ilya K ilya...@gmail.com writes:
My main aim is to build platform-dependent optimization based on the
minimizing of hamming distance between the instructions.
Take a look at http://code.google.com/p/mao/ .
Or in binutils, LD's relaxation
On Sun, 13 Jun 2010, Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We could perhaps do that for C/C++ code,
On Mon, 7 Jun 2010, Jonathan Wakely wrote:
Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
I ran this script, and verified that it runs daily, 55 minutes after
midnight UTC. Alas, it seems the script does not lead to the desired
result -- the libstdc++ onlinedocs/ pages appear
Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We could perhaps do that for C/C++ code, but Fortran relies on common
On Mon, 14 Jun 2010, Gerald Pfeifer wrote:
Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
I ran this script, and verified that it runs daily, 55 minutes after
midnight UTC. Alas, it seems the script does not lead to the desired
result -- the libstdc++ onlinedocs/ pages
Snapshot gcc-4.3-20100613 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100613/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 13/06/2010 23:22, David Brown wrote:
I agree that banning common symbols is not a complete solution. But
perhaps it may be a partial solution until some more complete solution
is found and implemented?
How about having a warning flag -Wcommon-lto
Incidentally, the original poster
On Mon, 14 Jun 2010, Gerald Pfeifer wrote:
Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
The script places up-to-date .html.gz files in the web infrastructure,
alas we do have older .html there -- and our web server is happy to
serve those over the compressed ones.
In any
On 13/06/2010 23:20, Joseph S. Myers wrote:
On Sun, 13 Jun 2010, Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We
On 13 June 2010 23:22, Gerald Pfeifer wrote:
On Mon, 7 Jun 2010, Jonathan Wakely wrote:
Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
I ran this script, and verified that it runs daily, 55 minutes after
midnight UTC. Alas, it seems the script does not lead to the desired
On Mon, 14 Jun 2010, Dave Korn wrote:
On 13/06/2010 23:20, Joseph S. Myers wrote:
On Sun, 13 Jun 2010, Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
On 14 June 2010 00:23, Jonathan Wakely wrote:
On 13 June 2010 23:22, Gerald Pfeifer wrote:
On Mon, 7 Jun 2010, Jonathan Wakely wrote:
Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
I ran this script, and verified that it runs daily, 55 minutes after
midnight UTC. Alas, it
On 13 June 2010 23:56, Gerald Pfeifer wrote:
On Mon, 14 Jun 2010, Gerald Pfeifer wrote:
Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
The script places up-to-date .html.gz files in the web infrastructure,
alas we do have older .html there -- and our web server is happy to
Dave Korn wrote:
On 13/06/2010 23:22, David Brown wrote:
I agree that banning common symbols is not a complete solution. But
perhaps it may be a partial solution until some more complete solution
is found and implemented?
How about having a warning flag -Wcommon-lto
Incidentally, the
Naveen H. S navee...@kpitcummins.com wrote:
Software floating point(libgcc) routines were implemented for SH in the
following links:-
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00063.html
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00614.html
David Brown david.br...@hesbynett.no writes:
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases where LTO is used. You use
-flto when compiling each source file, then link them with gcc with
-flto and -fwhole-program. Except in the
Дмитрий Дьяченко dim...@gmail.com writes:
Trunk g++/x86/160655 with -O0 compile test w/o errors, but with
-O[123] generates undefined symbol
Need i file a PR?
It certainly looks like a bug. Please do open a bug report. Thanks.
Ian
Quoting Kaz Kojima kkoj...@rr.iij4u.or.jp:
but in general the maintenance of
hand crafted assembly codes will be hard.
If you have a fixed feature set and pipeline, and have made sure the code
is correct, no further maintenance should be required - which is more
than can be said of the target
you can define a hard register HARD_FRAME_POINTER_REGNUM. Either
way, it should not be a fixed register. In the latter case, have
an elimination from FRAME_POINTER_REGNUM to HARD_FRAME_POINTER_REGNUM.
Hi Ian,
Thanks a lot for the useful suggestion.
The HARD_FRAME_POINTER_REGNUM which
--- Comment #7 from uros at gcc dot gnu dot org 2010-06-13 08:52 ---
Subject: Bug 44481
Author: uros
Date: Sun Jun 13 08:51:51 2010
New Revision: 160672
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160672
Log:
PR target/44481
* config/i386/i386.md
--- Comment #8 from ubizjak at gmail dot com 2010-06-13 08:54 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
GCC 4.5 -Wall warns if your function has a non-void return type but
returns. It can also detect an infinite loop which means that
falling off the end doesn't actually imply a return, and therefore
suppress the warning in that case.
However, if the function is static, this infinite loop detection
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-13 09:52 ---
Confirmed on x86_64-apple-darwin10.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44505
--- Comment #5 from irar at il dot ibm dot com 2010-06-13 10:29 ---
The bug is in creation of a neutral value for BIT_AND_EXPR. What is the correct
way to create it for all types? I found
double-int.h:#define ALL_ONES (~((unsigned HOST_WIDE_INT) 0))
but it won't work for signed.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-13 10:33 ---
It's because
/* Complain if there's just no return statement. */
if (warn_return_type
...
/* Normally, with -Wreturn-type, flow will complain, but we might
optimize out static functions. */
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-13 11:35 ---
(In reply to comment #5)
The bug is in creation of a neutral value for BIT_AND_EXPR. What is the
correct
way to create it for all types? I found
double-int.h:#define ALL_ONES (~((unsigned HOST_WIDE_INT) 0))
--- Comment #15 from iains at gcc dot gnu dot org 2010-06-13 11:35 ---
powerpc64-darwin9;
failed in stage3:
In file included from /usr/include/math.h:26:0,
from /GCC/gcc-live-trunk/gcc/genautomata.c:117:
/usr/include/architecture/ppc/math.h: In function
insn-attrtab.c
echo timestamp s-attrtab
rm gcov.pod gfdl.pod cpp.pod fsf-funding.pod gcc.pod
make[3]: Leaving directory `/user/inria/fsf/bldxx-20100613/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/user/inria/fsf/bldxx-20100613'
make[1]: *** [stage1-bubble] Error 2
make[1
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-13 11:46 ---
Could it be a duplicate of pr44509?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44512
--- Comment #16 from dominiq at lps dot ens dot fr 2010-06-13 11:47 ---
See also pr44512.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44509
--- Comment #7 from irar at il dot ibm dot com 2010-06-13 12:01 ---
(In reply to comment #6)
(In reply to comment #5)
The bug is in creation of a neutral value for BIT_AND_EXPR. What is the
correct
way to create it for all types? I found
double-int.h:#define ALL_ONES
/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lgmpxx -lmpc -lmpfr
-lgmp -rdynamic -ldl -L../zlib -lz -lelf
libbackend.a(print-rtl.o): In function `print_rtx':
/user/inria/fsf/bldxx-20100613-2/gcc/../../gcc/gcc
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-13 12:12
---
First, note that the *extractor*, ie, read, is slower, not the inserter. That
said, I think it's not at all obvious that read must be faster than the pointer
extractor, because in the latter case the parsing
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-13 12:25 ---
(In reply to comment #7)
(In reply to comment #6)
(In reply to comment #5)
The bug is in creation of a neutral value for BIT_AND_EXPR. What is the
correct
way to create it for all types? I found
--- Comment #3 from rsandifo at gcc dot gnu dot org 2010-06-13 12:29
---
Created an attachment (id=20902)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20902action=view)
Patch for unspec{,v}_strings definition
One fix would be to make insn-enums.c include insn-constants.h,
but I
Testcase:
/* { dg-do compile } */
/* { dg-options -std=iso9899:1990 -pedantic -Wformat } */
#include format.h
void
foo (int i)
{
printf (%d%d, i);
}
gcc-4.6:
/home/manuel/test/src/gcc/testsuite/gcc.dg/format/clang-1.c: In function 'foo':
Testcase:
templateclass T
class a {}
class temp {};
atemp b;
struct b {
}
gcc-4.6:
clang-2.C:3:15: error: multiple types in one declaration
clang-2.C:4:7: error: non-template type a used as a template
clang-2.C:4:10: error: invalid type in declaration before ; token
clang-2.C:6:1: error:
Testcase:
void bar(void);
void foo(void)
{
bar()
}
gcc-4.6:
clang-3.c:7:1: error: expected ; before } token
clang:
t.c:4:8: error: expected ';' after expression
bar()
^
;
--
Summary: improve message for missing ;
Product: gcc
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-13 12:46 ---
I don't care as long as there is a testcase that tests for this bug. Bugs
shouldn't be closed if a testcase has not been committed that prevents
regressing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16630
Testcase:
namespace services {
struct WebService { };
}
namespace myapp {
namespace servers {
struct Server { };
}
}
using namespace myapp;
void addHTTPService(servers::Server const server, ::services::WebService const
*http) {
server += http;
}
gcc-4.6:
clang-4.C:12:13: error:
Testcase:
int foo(int x, pid_t y) {
return x+y;
}
gcc-4.6:
clang-5.c:1:16: error: expected declaration specifiers or ... before pid_t
foo
clang-5.c: In function foo:
clang-5.c:2:12: error: y undeclared (first use in this function)
clang-5.c:2:12: note: each undeclared identifier is
On 4_5-branch, the objc++ encode-2.mm and encode-3.mm tests started to fail
recently on several platforms:
FAIL: obj-c++.dg/encode-2.mm scan-assembler
{?={Vecdouble=ddi}{Vecfloat=ffi}fd{Vecchar=cci}i}
FAIL: obj-c++.dg/encode-3.mm -fgnu-runtime execution test
Compare e.g.
Testcase:
struct foo { int x; }
typedef int bar;
gcc-4.6:
clang-6.c:3:9: error: two or more data types in declaration specifiers
Notice the line and the column are far away from the problem.
clang:
t.c:1:22: error: expected ';' after struct
struct foo { int x; }
^
Testcase:
struct B1 { void f(); };
struct B2 { void f(double); };
struct I1 : B1 { };
struct I2 : B1 { };
struct D: I1, I2, B2 {
using B1::f; using B2::f;
void g() {
f();
}
};
gcc-4.6:
clang-7.C:10:7: error: B1 is an ambiguous base of D
clang:
t.cc:10:5: error: ambiguous
Testcase:
struct B1 { void f(); };
struct B2 { void f(double); };
struct I1 : B1 { };
struct I2 : B1 { };
struct D: I1, I2, B2 {
void g() {
f();
}
};
gcc-4.6:
clang-8.C:9:5: error: reference to f is ambiguous
clang-8.C:2:18: error: candidates are: void B2::f(double)
clang-8.C:1:18:
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-13 13:49 ---
(In reply to comment #1)
instead. So the warning you see is really warning about no return statement,
not about control reaching the end of a non-void function. And it does so
by design just for functions with
Testcase:
namespace x {
struct a { };
}
x:a a2;
x::a a3 = a2;
gcc-4.6:
clang-9.C:5:1: error: x does not name a type
clang-9.C:6:11: error: a2 was not declared in this scope
clang:
t.cc:5:2: error: unexpected ':' in nested name specifier
x:a a2;
^
::
In addition to getting the error
Testcase:
namespace x {
struct a { };
}
template typename t
class foo {
};
foox::a a1;
foox:a a2;
x::a a3 = a2;
gcc-4.6:
clang-10.C:10:8: error: template argument 1 is invalid
clang-10.C:10:12: error: invalid type in declaration before ; token
clang-10.C:12:11: error: conversion from
Testcase:
#include map
int bar(std::mapint, float *X) {
return X.empty();
}
gcc-4.6:
/home/manuel/test/src/gcc/testsuite/g++.dg/warn/clang-11.C: In function 'int
bar(std::mapint, float*)':^M
/home/manuel/test/src/gcc/testsuite/g++.dg/warn/clang-11.C:4:12: error: request
for member 'empty' in
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-13 14:18 ---
(In reply to comment #2)
(In reply to comment #1)
instead. So the warning you see is really warning about no return
statement,
not about control reaching the end of a non-void function. And it does so
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-13 14:20 ---
Ian - testsuite regressions are not acceptable on the branch (XPASSes are ok
though).
Please restore the previous state by at least re-instantiating the XFAIL on the
branch.
Thanks.
--
rguenth at gcc dot gnu
--- Comment #2 from iains at gcc dot gnu dot org 2010-06-13 15:26 ---
Subject: Bug 44518
Author: iains
Date: Sun Jun 13 15:26:22 2010
New Revision: 160682
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160682
Log:
partial reversion of r160541.
PR testsuite/44518
--- Comment #3 from iains at gcc dot gnu dot org 2010-06-13 15:31 ---
(In reply to comment #1)
Ian - testsuite regressions are not acceptable on the branch (XPASSes are ok
though).
Well, of course, the patch did not cause any regressions on targets I have
access to.
These now XPASS.
When executing the profiling tests (e.g. gcc.dg/matrix/matrix.exp) on a remote
machine, the test run assumes that the directory structure is the same on the
remote target machine as it is on the host machine.
The path structure assumption is made based on the working directory during the
build of
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-06-13 16:05
---
Subject: Bug 31588
Author: dfranke
Date: Sun Jun 13 16:05:01 2010
New Revision: 160684
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160684
Log:
2010-06-13 Daniel Franke franke.dan...@gmail.com
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-06-13 16:05 ---
Subject: Bug 43954
Author: dfranke
Date: Sun Jun 13 16:05:01 2010
New Revision: 160684
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160684
Log:
2010-06-13 Daniel Franke franke.dan...@gmail.com
PR
Since r160684 gfortran supports generation of Makefile dependencies via libcpp.
In the example below, foo.mod is a target as it is generated from the .f90
file, but also a dependency as it used in the same source file:
$ cat foo.f90
MODULE foo
END MODULE
USE foo
END
$ gfortran-svn -cpp -M
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-06-13 16:07
---
Fixed in trunk. See PR44526 for a follow-up request for libcpp.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-06-13 16:09 ---
Makefile dependency generation is now available in trunk (-cpp -MD).
See PR44526 for a follow-up request to libcpp.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from mikpe at it dot uu dot se 2010-06-13 16:42 ---
(In reply to comment #3)
powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's
output)
I've scanned the gcc-testresults list archive for May and June quite carefully,
and I don't think anyone is
Testcase:
int foo(int X) {
__asm__ (frob%0 : +r (X));
return X;
}
gcc-4.6:
/var/folders/51/51Qw875vFdGa9KojoIi7Zk+++TM/-Tmp-//ccyXfgfZ.s:11:no such
instruction: `frob %eax'
clang:
inline asm:1:2: error: unrecognized instruction
frob%eax
^
t.c:2:11: note: generated
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-13 16:47 ---
Hmm, with a newer binutils we get a better error message:
t.c: Assembler messages:
t.c:2: Error: no such instruction: `frob %eax'
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-13 16:47 ---
GNU assembler (GNU Binutils for Debian) 2.18.0.20080103
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44527
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-13 16:49 ---
Now with Apple's as we get the weird error message you pointed out but that is
because apple's as does not support the change in line info we output:
# 2 t.c 1
frob%eax
# 0 2
--
pinskia at gcc dot
--- Comment #5 from mikpe at it dot uu dot se 2010-06-13 16:49 ---
Created an attachment (id=20903)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20903action=view)
correction to encode-2.mm
On powerpc64 encode-2.mm fails because the test case scans the assembly output
for the
): Output include of insn-constants.h
* Makefile.in (insn-enums.o): Depend on insn-constants.h.
gcc/c-family:
PR bootstrap/44512
* c-cppbuiltin.c (builtin_define_with_hex_fp_value): Add cast
for C++ standard compliance.
Modified:
branches/multi-target-20100613
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-13 16:59 ---
The column information is wrong.
The diagnostic markers are inconsistent (Error versus error).
This depends on the gnu assembler, which is not the default in many places.
--
manu at gcc dot gnu dot org changed:
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-13 17:04 ---
(In reply to comment #4)
(In reply to comment #3)
powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's
output)
I've scanned the gcc-testresults list archive for May and June quite
--- Comment #7 from iains at gcc dot gnu dot org 2010-06-13 17:07 ---
(In reply to comment #5)
Created an attachment (id=20903)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20903action=view) [edit]
correction to encode-2.mm
On powerpc64 encode-2.mm fails because the test case
--- Comment #14 from redi at gcc dot gnu dot org 2010-06-13 17:14 ---
(In reply to comment #12)
Why not make -Wconversion an error, at least this would
be consistent ;-)
You can use -Werror=conversion
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
--- Comment #8 from mikpe at it dot uu dot se 2010-06-13 17:15 ---
On ARM encode-2.mm fails in part for the same plain char mangles differently
reason as on powerpc64, but also due to a backend oddity. Here's how the
string is output in the assembly file on ARM:
.ascii
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-06-13 17:18 ---
The column information is wrong.
What column information :).
The diagnostic markers are inconsistent (Error versus error).
Report that to the binutils project.
This depends on the gnu assembler, which is not the
--- Comment #9 from iains at gcc dot gnu dot org 2010-06-13 17:20 ---
(In reply to comment #8)
On ARM encode-2.mm fails in part for the same plain char mangles differently
reason as on powerpc64, but also due to a backend oddity. Here's how the
string is output in the assembly file
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-13 17:25 ---
Actually before is more correct than saying after bar(). Because expressions
don't need to end on the same line.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44524
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-13 17:30 ---
This column information:
t.c:2:11: note: generated from here
__asm__ (frob%0 : +r (X));
^
I am not going to get into a reopen war with you anyway. I am just trying to
make a list of the diagnostic
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-13 17:33 ---
(In reply to comment #1)
Actually before is more correct than saying after bar(). Because expressions
don't need to end on the same line.
I wonder why people tend to write:
bar();
rather than
;}
Obviously the
when executing the command g++ bug_report.cc , i get the output:
/tmp/ccM7O0pr.o: In function `A::init()':
bug_report.cc:(.text._ZN1A4initEv[A::init()]+0x6): undefined reference to
`A::i'
collect2: ld returned 1 exit status
here is the output of the command ld -v
GNU ld (GNU Binutils for
--- Comment #10 from mikpe at it dot uu dot se 2010-06-13 17:42 ---
Created an attachment (id=20904)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20904action=view)
correction to encode-3.mm
The powerpc64 failure in encode-3.mm was also caused by a plain char mangling
difference.
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-13 17:53
---
*** This bug has been marked as a duplicate of 42101 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
1 - 100 of 112 matches
Mail list logo
