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
* doc/doxygen/user.cfg.in
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., ui
Ian Lance Taylor 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 GNU/Linux. I
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 d
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 s
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
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
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: gcc.dg/simulate-thread/atomic-load-
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 Fe
On Wed, Dec 07, 2011 at 08:09:06PM +0100, Uros Bizjak wrote:
> On Wed, Dec 7, 2011 at 7:58 PM, Iain Sandoe
> 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-loa
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 is
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
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
>
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 t
On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
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 cond_execs before reload, as l
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: 952-660
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.
* testsuite/30_threads/call_once/call_once1
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 f
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
non-
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', h
Tested by building 'info' for epiphany-elf, and by bootstrapping
x86_64-unknown-linux-gnu .
2012-02-07 Jeremy Bennett
Joern Rennecke
* doc/extend.texi: Expand and update information on interrupt
attribute for Epiphany.
Index: doc/extend.texi
=
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
* g
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 b
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
-flax-vector-conversions
objc.dg/stabs-1.m fails for mips*-elf* targets because tm_file is
missing a dbxelf.h include. A fix for that isn't suitable during
stage 4, so let's fail it in the meantime.
Tested on mips64-linux-gnu and various ELF targets. Applied.
Richard
gcc/testsuite/
PR target/52152
* o
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 coul
On Tue, Feb 7, 2012 at 11:00 AM, Uros Bizjak 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
>
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
* config/rs6000/rs
On Tue, Feb 7, 2012 at 5:57 PM, Richard Henderson 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 02/07/2012 08:37 AM, Uros Bizjak wrote:
> On Tue, Feb 7, 2012 at 1:59 PM, Uros Bizjak 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.
On Tue, Feb 7, 2012 at 1:59 PM, Uros Bizjak 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 overflow (and carry
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 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-paddin
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 t
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 -fabi
> 2012-02-06 Jakub Jelinek
>
> 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 i0src_c
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
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
On Tue, 7 Feb 2012, Joseph S. Myers wrote:
> 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_INI
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
* MAINTAINERS (Various Maintainers):
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.
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'
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
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 rs6000/sy
Hello!
Attached patch declares CCZmode compatible with CCGOC, CCGO and CCNO modes.
2012-02-07 Uros Bizjak
* config/i386/i386.c (ix86_cc_modes_compatible): Declare CCZmode
compatible with CCGOCmode, CCGCmode and CCNOmode.
Bootstrapped on x86_64-pc-linux-gnu, regression test st
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 ty
Committed as obvious.
Richard.
2012-02-07 Richard Guenther
* gimple-pretty-print.c (dump_gimple_phi): Avoid excessive
newline in -alias dumps.
Index: gcc/gimple-pretty-print.c
===
--- gcc/gimple-pretty-print.c
On Tue, Feb 7, 2012 at 12:53 PM, 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:
Ok.
Thanks,
Richard.
> 2012-
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
* config/freebsd-spec.h: Add comment about what macros c
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 wrote:
>>> On Sat, 21 Jan 2012, Tijl Coosemans wrote:
I've been using this patch now. It's similar to the above url
On Tue, Feb 7, 2012 at 11:48 AM, Richard Guenther
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 the whole
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 PTHREAD_RECURSIVE_M
On Tue, Feb 7, 2012 at 11:46 AM, Uros Bizjak wrote:
> On Tue, Feb 7, 2012 at 11:04 AM, Richard Guenther
> 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
On Tue, Feb 7, 2012 at 11:04 AM, Richard Guenther
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 the whole
> compile
On Tue, Feb 7, 2012 at 11:00 AM, Uros Bizjak wrote:
> On Mon, Feb 6, 2012 at 10:30 PM, Uros Bizjak 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
bit position to it (if any).
>
>
> 2012-02-07 Eric Botcazou
>
> * gcc.c-torture/execute/20120207-1.c: New test.
>
>
> --
> Eric Botcazou
On Mon, Feb 6, 2012 at 10:30 PM, Uros Bizjak 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
>>
>> [(op
On Tue, Feb 7, 2012 at 10:11 AM, Jakub Jelinek 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 gcc, becaus
Eric Botcazou
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
* gcc.c-torture/execute/20120207-1.c: New test.
--
Eric Botcazou
Index: expr.c
On Tue, Feb 7, 2012 at 9:54 AM, 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 wrote:
>> > On Sat, 21 Jan 2012, Tijl Coosemans wrote:
>> >> I've been using this patch now. It's similar to the above url,
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
>
> PR libstdc++/51906
> PR libstdc++/51296
> * gthr-posix.h: Allow static initializer mac
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 th
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
> 2012-02-01 Jakub Jelinek
>
> 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.
--
Eric Botc
On Mon, Jan 23, 2012 at 12:03:27PM +0100, Richard Guenther wrote:
> On Mon, Jan 23, 2012 at 12:23 AM, Gerald Pfeifer 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 to support
65 matches
Mail list logo
