On Sat, Jun 27, 2009 at 2:55 AM, Ian Lance Taylori...@google.com wrote:
Matt m...@use.net writes:
* Develop some trial patches which require C++, e.g., convert VEC to
std::vector.
Do you have any ideas for the easiest starting points? Is there
anywhere that is decently self-contained, or
Interesting. I've been testing my -Wc++-compat patches with full
bootstraps including Ada, but I just looked at my make log and it does
indeed appear that -Wc++-compat doesn't make it onto the Ada files.
It seems to be because of this line in ada/gcc-interface/Make-lang.in:
ada-warn =
On Fri, 2009-06-26 at 12:52 -0700, Ian Lance Taylor wrote:
Arnaud Charlet char...@adacore.com writes:
Switching gnatbind to generate Ada if there's nothing against
it might be a better solution since stage1 uses the system gnatbind, so
a patch to current gnatbind will not help (unless we
This was the only va_arg usage, may be we should apply it on trunk too
as the patched version is supposed to work for both C and C++.
Yes, but I'm testing a patch for trunk with more changes.
--
Eric Botcazou
On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote:
This was the only va_arg usage, may be we should apply it on trunk too
as the patched version is supposed to work for both C and C++.
Yes, but I'm testing a patch for trunk with more changes.
For reference here is my current draft
On Sat, 2009-06-27 at 13:51 +0200, Laurent GUERBY wrote:
On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote:
This was the only va_arg usage, may be we should apply it on trunk too
as the patched version is supposed to work for both C and C++.
Yes, but I'm testing a patch for trunk
All that above said - do you expect us to carry both vec.h (for VEC in
GC memory) and std::vector (for VECs in heap memory) (and vec.h
for the alloca trick ...)? Or do you think we should try to make the GTY
machinery C++ aware and annotate the standard library (ick...)?
Since the
Daniel Berlin wrote:
All that above said - do you expect us to carry both vec.h (for VEC in
GC memory) and std::vector (for VECs in heap memory) (and vec.h
for the alloca trick ...)? Or do you think we should try to make the GTY
machinery C++ aware and annotate the standard library (ick...)?
CC=../../xgcc -B../../ \
+ LINKER=$(CXX) \
CFLAGS=$(CFLAGS) $(WARN_CFLAGS) \
I think you should rather do
CC=../../xgcc -B../../ \
+ CXX=../../g++ -B../../ \
CFLAGS=$(CFLAGS) $(WARN_CFLAGS) \
+ CXXFLAGS=$(CXXFLAGS) $(WARN_CFLAGS) \
and copy the
Ian Lance Taylor i...@google.com writes:
I would like to encourage people to try using --enable-build-with-cxx in
other configuration--other bootstraps, cross-compilers--to see how well
it works. Please let me know if you run into problems that you don't
know how, or don't have time, to fix.
On Thu, Jun 25, 2009 at 4:32 PM, Ian Lance Taylori...@google.com wrote:
I would like to encourage people to try using --enable-build-with-cxx in
other configuration--other bootstraps, cross-compilers--to see how well
it works. Please let me know if you run into problems that you don't
know
On Sat, Jun 27, 2009 at 11:51, David Edelsohndje@gmail.com wrote:
2) The Graphite CLooG headers are not C++-clean, so enabling Graphite
fails in CXX mode.
I did applied the patches from Ian to the cloog-ppl git.
The git version should compile with a C++ compiler.
Sebastian
Hello All the gurus,
I've been fiddling my luck with gcc 4.3.2 inline assembly on powerpc
There are a few queries
1. asm volatile or simply asm produce the same assembly code.
Tried with a few examples but didnt find any difference by adding
volatile with asm
2. Use of memory and clobbered
Main changes from binutils 2.19.51.0.10:
Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337.
Add STB_GNU_UNIQU support.
H.J.
---
This is the beta release of binutils 2.19.51.0.11 for Linux, which is
based on binutils 2009 0627 in CVS on sourceware.org plus various
changes. It
Richard Guenther richard.guent...@gmail.com writes:
All that above said - do you expect us to carry both vec.h (for VEC in
GC memory) and std::vector (for VECs in heap memory) (and vec.h
for the alloca trick ...)? Or do you think we should try to make the GTY
machinery C++ aware and annotate
Hi, all,
I just tried to build gcc-in-cxx with some older gcc compilers on x86_64
linux. This is Debian testing, with 4.3.3 as the system compiler.
Here's what I've gotten so far:
2.95.3 Doesn't support x86_64
3.0.4 Doesn't support x86_64
3.1.1 Fails to bootstrap
3.2.3 Fails to
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-06-27 06:23 ---
Delete all the cpp HAVE_mpc goo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-27 09:49 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
void f(int x) { char c = x ? 23 : throw bla; }
error: aggregate value used where an integer was expected
because we call convert_to_integer on the throw_expression.
--
Summary: rejects promoted throw
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||3.3.6 4.0.0 4.4.1 4.5.0
Known to work|
On Linux/ia32, revision 149002:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00987.html
caused:
FAIL: gcc.dg/vect/O3-pr36098.c (test for excess errors)
FAIL: gcc.dg/vect/O3-pr39675-2.c (test for excess errors)
FAIL: gcc.dg/vect/O3-pr39675-2.c scan-tree-dump-times vect vectorized 1 loops
1: dump
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40567
--- Comment #1 from bonzini at gnu dot org 2009-06-27 14:40 ---
Subject: Bug 40567
Author: bonzini
Date: Sat Jun 27 14:40:29 2009
New Revision: 149006
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149006
Log:
2009-06-27 Paolo Bonzini bonz...@gnu.org
PR testsuite/40567
--- Comment #109 from bonzini at gnu dot org 2009-06-27 14:48 ---
Subject: Bug 26854
Author: bonzini
Date: Sat Jun 27 14:48:34 2009
New Revision: 149010
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149010
Log:
2009-06-07 Paolo Bonzini bonz...@gnu.org
PR
--- Comment #8 from CaptainSifff at gmx dot de 2009-06-27 15:44 ---
This also happens in gcc-4.2.1 on i686.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
C_SIZEOF should be a function in ISO_C_BINDING, however, in gfortran it is a
normal intrinsic.
Expected:
- The USE statement works
- Using C_SIZEOF should give an error
use iso_c_binding, only: so = c_sizeof
implicit none
print *, c_sizeof(1)
end
--
Summary: F2008: C_SIZEOF is in
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-06-27 16:05 ---
I noticed for version 4.4 (x86_64-*-mingw* and i686-*-mingw*) this issue still
exist. On 4.5 branch it is fixed. I would like that it the patch is getting
applied on the 4.4.1 branch, too. It fixed a crash in
Fortran 2008 adds the two inquiry subroutines, which return a string.
In GCC the version string is in version.h:
extern const char version_string[];
The options string has to constructed manually; the question is whether one
wants to skip certain options. Optimally, one would record exactly
--- Comment #2 from hjl at gcc dot gnu dot org 2009-06-27 16:43 ---
Subject: Bug 40489
Author: hjl
Date: Sat Jun 27 16:43:28 2009
New Revision: 149014
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149014
Log:
2009-06-27 H.J. Lu hongjiu...@intel.com
PR target/40489
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-27 17:50 ---
Subject: Bug 40024
Author: ktietz
Date: Sat Jun 27 17:50:20 2009
New Revision: 149015
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149015
Log:
2009-06-27 Kai Tietz kai.ti...@onevision.com
Merged
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-06-27 17:52 ---
Subject: Bug 40024
Author: ktietz
Date: Sat Jun 27 17:52:29 2009
New Revision: 149016
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149016
Log:
2009-06-27 Kai Tietz kai.ti...@onevision.com
Merged
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-06-27 17:56 ---
I did regression test for 4.3 and 4.4 branches and it was successful.
I committed the patch for PR other/40024 to both branches.
Committed revision 149015 for 4.3 branch and committed revision 149016 for 4.4
branch.
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-27 17:56 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
I just tried to compile the Suse Linux package qemacs-0.3.1-381.2
with the G++ compiler version 4.5 snapshot 20090625.
The compiler said
css.c:819:24: warning: cast from pointer to integer of different size
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See
--- Comment #1 from dcb314 at hotmail dot com 2009-06-27 18:08 ---
Created an attachment (id=18079)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18079action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-27 18:38 ---
Hm, for me it endlessly recurses
#49 0x087e631e in cgraph_clone_inlined_nodes (e=0xb78db340, duplicate=0 '\0',
update_original=1 '\001') at /home/richard/src/trunk/gcc/ipa-inline.c:261
261
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-27 19:06 ---
Created an attachment (id=18080)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18080action=view)
reduced testcase
slightly reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
For the missing inquiry function, see PR 40569.
Do not forget to update intrinsic.texi!
Missing are the following integer arrays/scalars:
CHARACTER_KINDS
[ 1, 4 ]
INTEGER_KINDS
[ 1, 2, 4 ...]
LOGICAL_KINDS
[ 1, 2, 4, ...]
REAL_KINDS
[ 4, 8, ... ]
IO_INQUIRE_INTERNAL_UNIT
some
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-27 19:44 ---
Do not forget to update intrinsic.texi!
For the missing constants in ISO_FORTRAN_ENV, see PR 40571
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-06-27 20:07
---
Reduced testcase:
===
struct A
{
char x[12], y[35];
};
struct B
{
char z[50];
};
inline void foo(char* dest, const char* __restrict src,
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-06-27 20:18
---
This appears to still be broken in 32-bit mode.
Yes, I've seen similar problems with 4.4.0 and 4.5.0 on x86. Probably the
stack realignment stuff. I'd suggest opening a new PR.
--
I've tried my hardest to build gcc without resorting to the use of
LD_LIBRARY_PATH. I simply can't understand why if LD_FLAGS is set to the path
of the mpfr library, the compiler can't use them.
My compile bombs out with the well known error:
error: cannot compute suffix of object files: cannot
--- Comment #1 from david dot kirkby at onetel dot net 2009-06-27 20:25
---
Created an attachment (id=18081)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18081action=view)
Top level config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
--- Comment #2 from david dot kirkby at onetel dot net 2009-06-27 20:29
---
Created an attachment (id=18082)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18082action=view)
sparc-sun-solaris2.10/libgcc/config.log
This is the file, which shows it can't find the library, a couple
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-27 20:35 ---
What is the LDFLAGS supposed to do? Is it supposed to adjust the run-path of
the built executables to find the mpfr/gmp libraries to not need
LD_LIBRARY_PATH
set?
Note that setting LDFLAGS maybe not what you want
--- Comment #4 from david dot kirkby at onetel dot net 2009-06-27 20:57
---
(In reply to comment #3)
What is the LDFLAGS supposed to do? Is it supposed to adjust the run-path of
the built executables to find the mpfr/gmp libraries to not need
LD_LIBRARY_PATH
set?
Note that
--- Comment #5 from david dot kirkby at onetel dot net 2009-06-27 21:00
---
(In reply to comment #3)
Note that setting LDFLAGS maybe not what you want (it affects stage1 only
AFAIK), you likely want to set BOOT_LDFLAGS.
Sorry, forget to comment on that.
I'll try that. I would
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-27 21:46 ---
LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are
running programs which use shared libraries stored in a non standard place.
--
pinskia at gcc dot gnu dot org changed:
What
In the attached testcase (which will be added to the GDB testsuite), func1 is
both emitted as a function and inlined into main and func2. The generated
DWARF output looks like this with mainline:
11bf: Abbrev Number: 2 (DW_TAG_subprogram)
1c0 DW_AT_external: 1
1c1 DW_AT_name
--- Comment #1 from drow at gcc dot gnu dot org 2009-06-27 22:12 ---
Created an attachment (id=18083)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18083action=view)
Test case
Compile with -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573
--- Comment #7 from david dot kirkby at onetel dot net 2009-06-27 22:31
---
(In reply to comment #6)
LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are
running programs which use shared libraries stored in a non standard place.
So is any user who uses the
--- Comment #8 from david dot kirkby at onetel dot net 2009-06-27 22:57
---
It looks as though we will have to agree to differ about the LD_LIBRARY_PATH
being the right way to do things.
But do you not agree that this probably should be found at an earlier stage in
the build
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-06-27 23:39 ---
This is just like building any other program and running the result if you link
with a library stored somewhere else. /usr/local/lib not being standard is up
to your distro really, it is a standard location
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-06-27 23:39
---
It is semi hard to figure out early on really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-27 23:41 ---
I believe the following (but yet untested) patch fixes this issue.
I will bootstrap and test it once I have a testcase that is simple
enough to be put into the testsuite. I hope to do all of this on
Monday.
--- Comment #11 from david dot kirkby at onetel dot net 2009-06-28 03:51
---
(In reply to comment #3)
Note that setting LDFLAGS maybe not what you want (it affects stage1 only
AFAIK), you likely want to set BOOT_LDFLAGS.
FWIW, BOOT_LDFLAGS. that did not solve it either. I think
56 matches
Mail list logo
