On Mon, Jan 23, 2012 at 12:03:27PM +0100, Richard Guenther wrote:
On Mon, Jan 23, 2012 at 12:23 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
On Sat, 21 Jan 2012, Tijl Coosemans wrote:
I've been using this patch now. It's similar to the above url, but
conditional on TARGET_LIBC_PROVIDES_SSP
2012-02-01 Jakub Jelinek ja...@redhat.com
PR middle-end/52074
* expr.c (expand_expr_addr_expr_1): For CONSTANT_CLASS_P or CONST_DECL
if modifier EXPAND_SUM call force_operand on the result.
* gcc.c-torture/compile/pr52074.c: New test.
This looks fine to me.
--
Hi!
In Fedora (but several other distros do the same) we ship cpp
as a separate package, unfortunately the lto plugin support means (IMHO
unnecessarily) that the plugin needs to be included in the cpp package
rather than gcc, because the driver looks for the plugin and complains
if not found even
On 6 February 2012 06:40, Jakub Jelinek wrote:
On Sun, Feb 05, 2012 at 08:26:22PM +, Jonathan Wakely wrote:
This has been testing on darwin, if Rainer tests it successfully on
Tru64 will the gthr-posix.h change be acceptable?
Ok with a suitable ChangeLog entry.
Jakub, further to the
On Tue, Feb 07, 2012 at 09:11:38AM +, Jonathan Wakely wrote:
gthr-posix.h changes OK as attached, with this ChangeLog?
Okay. Thanks.
libgcc/
2012-02-07 Jonathan Wakely jwakely@gmail.com
PR libstdc++/51906
PR libstdc++/51296
* gthr-posix.h: Allow static
On Tue, Feb 7, 2012 at 9:54 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jan 23, 2012 at 12:03:27PM +0100, Richard Guenther wrote:
On Mon, Jan 23, 2012 at 12:23 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
On Sat, 21 Jan 2012, Tijl Coosemans wrote:
I've been using this patch now. It's
Eric Botcazou ebotca...@adacore.com
PR middle-end/51994
* expr.c (get_inner_reference): If there is an offset, add a negative
bit position to it (if any).
2012-02-07 Eric Botcazou ebotca...@adacore.com
* gcc.c-torture/execute/20120207-1.c: New test.
--
Eric
On Tue, Feb 7, 2012 at 10:11 AM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
In Fedora (but several other distros do the same) we ship cpp
as a separate package, unfortunately the lto plugin support means (IMHO
unnecessarily) that the plugin needs to be included in the cpp package
rather than
On Mon, Feb 6, 2012 at 10:30 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hmm. Well, the only thing that's going to work for x86 is the double-compare
elimination portion.
If we want to use this pass for x86, then for 4.8 we should also fix the
discrepancy between the compare-elim canonical
* gcc.c-torture/execute/20120207-1.c: New test.
--
Eric Botcazou
On Tue, Feb 7, 2012 at 11:00 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Feb 6, 2012 at 10:30 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hmm. Well, the only thing that's going to work for x86 is the
double-compare
elimination portion.
If we want to use this pass for x86, then for 4.8
On Tue, Feb 7, 2012 at 11:04 AM, Richard Guenther
richard.guent...@gmail.com wrote:
(BTW: I think that the change to combine.c would be nice to have, to
find more other combine opportunities. I will propose the patch
separately.)
Shouldn't there be a canonical order for parallels throughout
On Tue, Feb 7, 2012 at 11:46 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Feb 7, 2012 at 11:04 AM, Richard Guenther
richard.guent...@gmail.com wrote:
(BTW: I think that the change to combine.c would be nice to have, to
find more other combine opportunities. I will propose the patch
On 6 February 2012 19:24, Mike Stump wrote:
On Feb 5, 2012, at 12:26 PM, Jonathan Wakely wrote:
PRs libstdc++/51296 and libstdc++/51906 are both caused by problems
with the Pthreads static initializer macros such as
PTHREAD_MUTEX_INITIALIZER.
On Mac OS X 10.7 the
On Tue, Feb 7, 2012 at 11:48 AM, Richard Guenther
richard.guent...@gmail.com wrote:
(BTW: I think that the change to combine.c would be nice to have, to
find more other combine opportunities. I will propose the patch
separately.)
Shouldn't there be a canonical order for parallels throughout
On Tuesday 07 February 2012 09:54:43 Jakub Jelinek wrote:
On Mon, Jan 23, 2012 at 12:03:27PM +0100, Richard Guenther wrote:
On Mon, Jan 23, 2012 at 12:23 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
On Sat, 21 Jan 2012, Tijl Coosemans wrote:
I've been using this patch now. It's similar to the
On Tue, Feb 07, 2012 at 12:17:59PM +0100, Tijl Coosemans wrote:
Everything still works on FreeBSD.
After discussion about this on IRC Richard expressed his preference
for the following variant instead:
2012-02-07 Jakub Jelinek ja...@redhat.com
* config/freebsd-spec.h: Add comment
On Tue, Feb 7, 2012 at 12:53 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 07, 2012 at 12:17:59PM +0100, Tijl Coosemans wrote:
Everything still works on FreeBSD.
After discussion about this on IRC Richard expressed his preference
for the following variant instead:
Ok.
Thanks,
Committed as obvious.
Richard.
2012-02-07 Richard Guenther rguent...@suse.de
* gimple-pretty-print.c (dump_gimple_phi): Avoid excessive
newline in -alias dumps.
Index: gcc/gimple-pretty-print.c
===
---
The following patch rewrites the bitfield handling of the C++ memory
model and enables it unconditionally to fix PR52080. As I suggested
earlier at some point this moves computation of what the memory model
considers the underlying object we may access to the point where we
lay out a structure
Hello!
Attached patch declares CCZmode compatible with CCGOC, CCGO and CCNO modes.
2012-02-07 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.c (ix86_cc_modes_compatible): Declare CCZmode
compatible with CCGOCmode, CCGCmode and CCNOmode.
Bootstrapped on x86_64-pc-linux-gnu,
On Tue, 7 Feb 2012, Jakub Jelinek wrote:
So, if this mess is really needed (does anybody actually use -mcall-freebsd
on non-freebsd targets?), IMHO freebsd-spec.h must avoid defining non-FBSD_
I've argued for a long time that the -mcall-* support should be removed
and targets using
On Tue, Feb 07, 2012 at 01:13:35PM +, Joseph S. Myers wrote:
On Tue, 7 Feb 2012, Jakub Jelinek wrote:
So, if this mess is really needed (does anybody actually use -mcall-freebsd
on non-freebsd targets?), IMHO freebsd-spec.h must avoid defining non-FBSD_
I've argued for a long time
On Tue, 7 Feb 2012, Richard Guenther wrote:
If the C frontend would stop using DECL_INITIAL temporarily for
bitfield FIELD_DECLs we could avoid adding a new member to struct
tree_field_decl - Joseph, is it possible to avoid using DECL_INITIAL?
C++ does the same thing with DECL_INITIAL so I'd
On Tuesday 07 February 2012 12:53:24 Jakub Jelinek wrote:
On Tue, Feb 07, 2012 at 12:17:59PM +0100, Tijl Coosemans wrote:
Everything still works on FreeBSD.
After discussion about this on IRC Richard expressed his preference
for the following variant instead:
Works too.
Hi,
I am starting to work on a new project and won't be able to continue with
vectorizer maintenance.
I'd like to thank all the people I had a chance to work with for making my
GCC experience so enjoyable.
All the best,
Ira
2012-02-08 Ira Rosen i...@il.ibm.com
* MAINTAINERS
On Tue, 7 Feb 2012, Jonathan Wakely wrote:
Hi Richard,
re http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00280.html (I'm not
subscribed to gcc-patches so only read it in the archive)
Note that in the above case
tail-padding is _not_ reused (for some reason).
Tail-padding in PODs can't
On Tue, 7 Feb 2012, Richard Guenther wrote:
That would be nice. I suppose that doing
if (DECL_INITIAL (x))
{
unsigned HOST_WIDE_INT width = tree_low_cst (DECL_INITIAL (x),
1);
DECL_SIZE (x) = bitsize_int (width);
DECL_BIT_FIELD (x) = 1;
2012-02-06 Jakub Jelinek ja...@redhat.com
PR rtl-optimization/52060
* combine.c (try_combine): Add i0src_copy and i0src_copy2 variables,
copy i1src to i1src_copy whenever added_sets_2 i1_feeds_i2_n already
before i1dest - i1src substitution in newpat, copy i0src to
Testcase is for example g++.dg/abi/bitfield5.C, bit layout annotated:
struct A {
virtual void f();
int f1 : 1;--- bit 64
};
struct B : public A {
int f2 : 1; // { dg-warning ABI }--- bit 65
int : 0;
int f3 : 4;
int f4 : 3;
};
maybe it was a bug (above happens with
When we re-play the symbol table for a PPH image, we are executing
from libcpp's #include handler. This means that the lexer thinks that
it is inside the #include directive.
This alters the lexer behaviour in subtle ways. In this test case,
for example, the parsing of the escaped quotes inside
On 7 February 2012 14:00, Richard Guenther wrote:
On Tue, 7 Feb 2012, Jonathan Wakely wrote:
Hi Richard,
re http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00280.html (I'm not
subscribed to gcc-patches so only read it in the archive)
Note that in the above case
tail-padding is _not_ reused
On Tue, Feb 07, 2012 at 04:01:31PM +, Jonathan Wakely wrote:
What would it have said for -fabi-version=1 where for
we place s.i and s.d into the same byte?
I think it says they shouldn't be in the same byte :-)
They don't, except for compatibility with the old ABI.
I think easiest
On Tue, Feb 7, 2012 at 1:59 PM, Uros Bizjak ubiz...@gmail.com wrote:
Attached patch declares CCZmode compatible with CCGOC, CCGO and CCNO modes.
Actually, CCZ mode is not compatible with CCNO mode, since the later
only declares that overflow flag is not set. CCGOC and CCGO declare
garbage in
On Tue, Feb 7, 2012 at 5:57 PM, Richard Henderson r...@redhat.com wrote:
Attached patch declares CCZmode compatible with CCGOC, CCGO and CCNO modes.
Actually, CCZ mode is not compatible with CCNO mode, since the later
only declares that overflow flag is not set. CCGOC and CCGO declare
David pointed out that I had not updated the error message for
-mno-pointers-to-nested-functions when I changed the name of the switch. I
installed the following patch as obvious after making sure it bootstrapped and
ran make check.
[gcc]
2012-02-07 Michael Meissner meiss...@linux.vnet.ibm.com
On Tue, Feb 7, 2012 at 11:00 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hmm. Well, the only thing that's going to work for x86 is the
double-compare
elimination portion.
If we want to use this pass for x86, then for 4.8 we should also fix the
discrepancy between the compare-elim canonical
Given the unacceptability of the original builtins patch:
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01564.html
I've decided to go for this MIPS-specific version. I've also made
the test specific to MIPS and XFAILed it for EABI32 (the failures
there don't seem to be a regression). We
As explained in PR 52155, a disagreement between GCC and newlib about
the best choice of 32-bit type causes lots of conversion errors when
loongson.h is included on 32-bit mips*-elf* targets. This patch works
around them by forcing -mlong64. An alternative would be to use
The Go compiler currently supports using __asm__ in Go code to set the
externally visible name of a function declaration. This is used to
permit Go code to call C code directly. The problem with __asm__ is
that it is not supported by the gofmt program, which means that Go code
that uses can not
This breaks LTO bootstrap because of warnings for apparently incompatible types
at the interface between C and Ada. Given that it's very likely not possible
to fix them all, let's keep accepting them.
Tested on i586-suse-linux, applied on the mainline.
2012-02-07 Eric Botcazou
Tested by building 'info' for epiphany-elf, and by bootstrapping
x86_64-unknown-linux-gnu .
2012-02-07 Jeremy Bennett jeremy.benn...@embecosm.com
Joern Rennecke joern.renne...@embecosm.com
* doc/extend.texi: Expand and update information on interrupt
attribute for
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.7-b20120128.de.po',
Hi!
On the following testcase we hit two bugs during cfglayout merge_blocks.
One is that b-il.rtl-header has some jumptable in it, followed by
barrier. We call emit_insn_after_noloc to insert the whole b's header
after BB_END (a) and then delete_insn_chain it, with the intention that only
Hi Andrew
I find it interesting that cond_exec's in this form survive all the
way till reload and work. AFAIK we could never have cond_exec's
before reload . The documentation doesn't appear to mention this,
therefore I would like to see if the cond_exec's can be recast as
if_then_else forms
I added powerpc-ibm-aix* to some tests twice with an overzealous sed
command, this fixes it.
* testsuite/30_threads/call_once/39909.cc: Remove duplicate target
selector.
* testsuite/30_threads/call_once/49668.cc: Likewise.
*
The patch implements suggestions made by Andreas Schwab. Tested on
hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to trunk.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX:
On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
ramana.radhakrish...@linaro.org wrote:
Hi Andrew
I find it interesting that cond_exec's in this form survive all the
way till reload and work. AFAIK we could never have cond_exec's
before reload .
There is nothing wrong per-se with
Hello,
this fixes the fairly recent PR50981 patch
[http://gcc.gnu.org/ml/fortran/2011-12/msg00170.html] which didn't work
for subroutine calls, as they use code-resolved_sym instead of
code-expr1 to store the procedure symbol.
The first patch moves gfc_walk_elemental_function_args's code to
tisdag 20 december 2011 22.56.45 skrev du:
On Tue, 20 Dec 2011, Magnus Granberg wrote:
This patch make -D and -U work in the spec language, bug pr48524.
Tested on x86_64-unknown-linux-gnu snapshot 4.7-20111217
Thanks for your contributions. As you've contributed before, this patch
brings
On Tue, 7 Feb 2012, Richard Guenther wrote:
The following patch rewrites the bitfield handling of the C++ memory
model and enables it unconditionally to fix PR52080. As I suggested
earlier at some point this moves computation of what the memory model
considers the underlying object we may
On 26.01.2012 18:57, Joseph S. Myers wrote:
On Thu, 26 Jan 2012, Matthias Klose wrote:
On 25.01.2012 17:45, Joseph S. Myers wrote:
On Wed, 25 Jan 2012, Matthias Klose wrote:
This can end up in generation for dependency files, and other files
parsing
the output. The solution I came up with
On Wed, Dec 07, 2011 at 08:09:06PM +0100, Uros Bizjak wrote:
On Wed, Dec 7, 2011 at 7:58 PM, Iain Sandoe
develo...@sandoe-acoustics.co.uk wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
simulation test
FAIL:
Add note on thread improvements to libstdc++ changes.
Committed to cvs.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.75
diff -u -r1.75 changes.html
--- changes.html5
On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread simulation
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread simulation
test
FAIL:
On Wed, 8 Feb 2012, Matthias Klose wrote:
there is one more issue, when configuring
--with-sysroot=/ --with-gxx-include-dir=/usr/include/c++/4.7
in that the leading / is stripped away in configure.ac. This case needs an
explicit check. Ok for the trunk?
This looks like a case where any
On 08.02.2012 02:01, Joseph S. Myers wrote:
On Wed, 8 Feb 2012, Matthias Klose wrote:
there is one more issue, when configuring
--with-sysroot=/ --with-gxx-include-dir=/usr/include/c++/4.7
in that the leading / is stripped away in configure.ac. This case needs an
explicit check. Ok for the
Hi,
The problem in this PR is that with PIE, getsectdata does not return the
position of tm_clone_table after the relocation.
While _dyld_get_image_vmaddr_slide(0) is enough for PIE, this is not
enough for dylib.
I did not find an easy API function to get position of the
tm_clone_table for a
On Tue, Feb 07, 2012 at 10:36:41PM -0500, Patrick Marlier wrote:
Hi,
The problem in this PR is that with PIE, getsectdata does not return the
position of tm_clone_table after the relocation.
While _dyld_get_image_vmaddr_slide(0) is enough for PIE, this is not
enough for dylib.
I did not
Ian Lance Taylor i...@google.com writes:
Right now it looks like there is a bug, or at least an incompatibility,
in the 64-bit versions of getcontext and setcontext. It looks like
calling setcontext on the 32-bit version does not change the value of
TLS variables, which is also the case on
This patch to the Go compiler checks arguments to make for overflow if
they have types larger than uintptr. In an attempt to be efficient on
32-bit systems, gccgo will continue to pass uintptr arguments in the
normal case. If make is called with a value whose type is larger than
uintptr (e.g.,
Debugging pdf output on current linux indicates that the long-standing
PDF_HYPERLINKS issue turns out to just be a pool_size limitation in
TeX, which can be worked around by increasing pool size. Document.
tested x86_64/linux
-benjamin
2012-02-07 Benjamin Kosnik b...@redhat.com
*
62 matches
Mail list logo
