The comment is still valid now.
r
gcc/Changelog:
2011-10-25 Roberto Agostino Vitillo raviti...@lbl.gov
PR c++/30066
* doc/invoke.texi (fvisibility-inlines-hidden): Documentation change.
gcc/c-family/Changelog:
2011-10-25 Roberto Agostino Vitillo raviti...@lbl.gov
PR
The new testcase:
Index: gcc/testsuite/g++.dg/ext/visibility/fvisibility-inlines-hidden-4.C
===
--- gcc/testsuite/g++.dg/ext/visibility/fvisibility-inlines-hidden-4.C
(revision 0)
+++
It's really not possible that this is being used by anyone, as far as
I can see. So let's just kill it all off.
Any objections?
None.
--
Eric Botcazou
Applied a fix to trunk at rev. 180423 and to 4.6.x branch at rev. 180422.
Regards,
Kai
On Mon, 24 Oct 2011, Jakub Jelinek wrote:
On Mon, Oct 24, 2011 at 04:09:49PM +0200, Richard Guenther wrote:
This one bootstraps and regtests fine on x86_64-unknown-linux-gnu.
I didn't find a good pattern to split out, eventually how we call
the vectorizable_* routines should be re-factored
On Mon, Oct 24, 2011 at 6:27 PM, Xinliang David Li davi...@google.com wrote:
Well, you seem to keep not reading what I write. I am not opposed
to adding -fopt-info/report nor to funnel messages to stdout/err. What
I am opposed is the way you want to introduce them. I want you to
fix what we
Hi!
For -masm=intel we currently emit invalid assembler for the v*gather*
insns,
vpgatherdd ymm0, (rax, ymm1, 1), ymm2
is some weird mixture of ATT and Intel syntax. Furthermore,
by requiring a register as a base we unnecessarily penalize the code,
even when the base is constant or symbol,
Andi Kleen a...@firstfloor.org writes:
From: Andi Kleen a...@linux.intel.com
Slim LTO requires running ar/nm/ranlib with the LTO plugin. The most
convenient way to get this into existing Makefiles is using small
wrappers that pass the plugin. This matches how other compilers
(LLVM, icc) do
The following libgcc patches haven't been reviewed since July:
CFT: [build] Move crtstuff support to toplevel libgcc
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01273.html
CFT: [build] Move libgcc1 to toplevel libgcc
Hi folks,
I've just committed this:
Index: ChangeLog
===
--- ChangeLog (revision 180428)
+++ ChangeLog (revision 180429)
@@ -1,3 +1,7 @@
+2011-10-25 Kirill Yukhin kirill.yuk...@intel.com
+
+ * MAINTAINERS (Write After
Hi,
this fixes an ICE on invalid which occurs inside
composite_pointer_type_r, now a bit more stressed post fix for PR38174.
Tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
//
/cp
2011-10-25 Paolo Carlini paolo.carl...@oracle.com
PR c++/50858
*
My recent patch to add -mcpu=generic-armv7-a omitted support for big
endian. This patch should solve that.
As far as I know the only this missing is the linker spec. (I have no
big-endian targets to test with.)
OK?
Andrew
2011-10-25 Andrew Stubbs a...@codesourcery.com
gcc/
*
Richard,
I have a patch for the i686 bootstrap problem reported in PR50763 comment 10.
pr50763-2.c looks like this before tail_merge_optimize:
...
std_canonical_va_list_type (union tree_node * typeD.1608)
{
_BoolD.1576 pretmp.6D.2739;
union tree_node * pretmp.5D.2738;
_BoolD.1576
On 25/10/11 11:51, Andrew Stubbs wrote:
My recent patch to add -mcpu=generic-armv7-a omitted support for big
endian. This patch should solve that.
As far as I know the only this missing is the linker spec. (I have no
big-endian targets to test with.)
OK?
Andrew
be.patch
On 09/24/2011 01:42 PM, Richard Guenther wrote:
On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
In the end I'd probably say the patch is ok without the option (thus
turned on by default), but if
Hi,
this fixes an ICE on invalid new in mainline. Tested x86_64-linux.
Ok?
Thanks,
Paolo.
/cp
2011-10-25 Paolo Carlini paolo.carl...@oracle.com
PR c++/50861
* pt.c (tsubst_copy_and_build): Check return value of
tsubst_copy_and_build for
On 25/10/11 13:19, Richard Earnshaw wrote:
2011-10-25 Andrew Stubbsa...@codesourcery.com
gcc/
* config/arm/bpabi.h (BE8_LINK_SPEC): Recognize generic-armv7 tuning.
--- a/gcc/config/arm/bpabi.h
+++ b/gcc/config/arm/bpabi.h
@@ -58,6 +58,7 @@
#define BE8_LINK_SPEC \
This has been broken because since mainline revision r160124, which
(correctly) causes 'y' to be flagged as noreturn -- y never returns via
the normal function return route. If ipa-pure-const.c is hacked to
check that a function does not perform non-local gotos before marking
it noreturn, the
On Tue, Oct 25, 2011 at 10:21 AM, Jakub Jelinek ja...@redhat.com wrote:
For -masm=intel we currently emit invalid assembler for the v*gather*
insns,
vpgatherdd ymm0, (rax, ymm1, 1), ymm2
is some weird mixture of ATT and Intel syntax. Furthermore,
by requiring a register as a base we
OK.
Jason
PING!
Also, PING for parts 2/3 and 3/3 of this (loosely related) patch series:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01642.html
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01644.html
On Tue, Oct 18, 2011 at 17:42, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
in a few places
OK.
Jason
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 Japanese team of translators. The file is available at:
http://translationproject.org/latest/gcc/ja.po
(This file, 'gcc-4.6.1.ja.po', has
On 25/10/11 13:48, Andrew Stubbs wrote:
On 25/10/11 13:19, Richard Earnshaw wrote:
2011-10-25 Andrew Stubbsa...@codesourcery.com
gcc/
* config/arm/bpabi.h (BE8_LINK_SPEC): Recognize generic-armv7 tuning.
--- a/gcc/config/arm/bpabi.h
+++ b/gcc/config/arm/bpabi.h
@@ -58,6 +58,7 @@
On Mon, Oct 24, 2011 at 8:17 PM, Richard Henderson r...@redhat.com wrote:
The ones that expand to VPERM can be handled by generic code.
The even v4si and v4sf expanders remain until vector.md can be
updated to not invoke them directly.
+;; ??? This is still used directly by vector.md
On Tue, 25 Oct 2011, Richard Guenther wrote:
This moves lto-wrapper over to use common option processing to
parse and re-emit options from COLLECT_GCC_OPTIONS. In a second
step I will move the merging/complaining about different options
in different LTO input files to the LTO driver (which
Hi,
the patch below adds a compile time warning which is present on the
32-bit target but not on the 64-bit target.
I think it is missing since the beginning.
The patches 'fixes' the gcc.dg/20021014-1.c test case on x86_64-freebsd.
Ok for trunk and 4.6?
Thanks,
Andreas
2011-10-25 Andreas
On 11-10-25 01:23 , Andi Kleen wrote:
Andi Kleena...@firstfloor.org writes:
From: Andi Kleena...@linux.intel.com
Slim LTO requires running ar/nm/ranlib with the LTO plugin. The most
convenient way to get this into existing Makefiles is using small
wrappers that pass the plugin. This matches
On 10/22/11 00:43, Mike Stump wrote:
Index: reload.c
===
--- reload.c (revision 180265)
+++ reload.c (working copy)
@@ -7231,7 +7231,7 @@ regno_clobbered_p (unsigned int regno, r
{
rtx elt = XVECEXP (PATTERN
The following patch still needs a libiberty maintainer's review.
(it has been reviewed viz-a-viz Darwin).
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01622.html
On Tue, 25 Oct 2011, Rainer Orth wrote:
CFT: [build] Move crtstuff support to toplevel libgcc
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01273.html
OK, updated for changes to GCC since this was posted (at least, for my
change to make i[34567]86-*-elf* and x86_64-*-elf* use
I've committed these two patches, which correct some problems where the
libgcc implementation didn't quite match the ABI.
Bernd
Index: libgcc/ChangeLog
===
--- libgcc/ChangeLog(revision 180431)
+++ libgcc/ChangeLog(working
On Tue, 25 Oct 2011, Richard Guenther wrote:
Joseph, does this look like a sensible use of the common
machinery? Do we want the init from COLLECT_GCC_OPTIONS
in opts-common.c instead?
Certainly there should be a single function to process COLLECT_GCC_OPTIONS
into an array of strings, even
On Thu, Oct 20, 2011 at 5:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
@@ -1392,16 +1393,20 @@ inline_small_functions (void)
if (!edge-inline_failed)
continue;
- /* Be sure that caches are maintained consistent. */
#ifdef ENABLE_CHECKING
+ /* Be sure that caches are
Ian,
It's possible that this patch will once again break the Solaris and Irix
support. I've tried to ensure that I didn't make any stupid errors, but
I haven't done any actual testing. Sorry about any problems.
it did (as expected :-), but in easy to fix ways (at least for getting
libgo to
The Go language was changed slightly to prohibit calling close on a
receive-only channel. This patch changes the Go frontend accordingly.
This patch also implements a better panic for an attempt to close a nil
channel. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to
I'd like to ping Andrey's patch (quoted below).
Additionally, the following patch is needed to fix a different instance where
sel-sched does not expect quirky regions in the vicinity of
__builtin_unreachable.
Both patches were bootstrapped and regtested on x86_64-linux, OK for trunk?
2011-10-25
First round of comments.
I think we should add this to google/main. It's in sufficiently good
shape for it. You can keep improving it in the branch.
It is now too late for 4.7's stage 1, so I think a reasonable way to
proceed is to keep it in google/main and then present it for trunk
On 24/10/11 14:30, Sebastian Huber wrote:
Hello,
what about the attached patch based on the original patch provided by Bernd
Schmidt with modifications suggested by Richard Earnshaw.
pr49641.patch
* config/arm/arm.c (store_multiple_sequence): Avoid cases where
the
On Mon, 24 Oct 2011, Kohei Takahashi wrote:
I'm GCC mirror admin of ftp.tsukuba.wide.ad.jp. Could you change my mail
address of mirror lists to tsukuba-ftp-serv...@tsukuba.wide.ad.jp ?
Sure, just done by means of the patch below. Thanks for letting us
know!
Gerald
Index: mirrors.html
The Go language has picked up a predeclared function delete which may be
used to delete an element from a map. This will eventually replace the
tuple assignment statement
m[k] = v, false
which is currently used to delete a map entry. This patch adds the
delete function to the Go
While doing that other update here earlier today I wondered whether we
really want/need to munge e-mail addresses on that page. This kind of
munging provides no real benefit today, so I applied the patch below
which at least removes this from the domain part of e-mail addresses.
Gerald
Index:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01622.html
In general, target-specific parts of libiberty may be committed with
only that target's maintainer's approval.
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
it did (as expected :-), but in easy to fix ways (at least for getting
libgo to compile again):
Thanks. I committed your patch.
Unfortunately, testsuite results are a mess: all link tests fail like
this:
Undefined
On 10/25/2011 10:20 AM, Andrew MacLeod wrote:
+ /* Otherwise there is a lockfree match, transform the call from:
+void fn(T* mem, T* desired, T* return, model)
+ into
+*((In *)return = fn (T* mem, *((In *)desired, model) */
This is, in general, an aliasing violation
In a new-expression, we try to pre-evaluate all of the arguments to a
constructor before allocating the memory in order to improve EH region
nesting. In the case of a list-initialized object, we want to
pre-evaluate the arguments to any constructors for each of the
subobjects. If the
The patch for 41449 introduced more EH cleanup regions in aggregate
initialization, which caused problems with EH regions trying to overlap.
Since individual subobject initializations are each full-expressions,
the solution here is to treat them as such by wrapping them with a
On 10/25/2011 02:18 PM, Richard Henderson wrote:
On 10/25/2011 10:20 AM, Andrew MacLeod wrote:
+ /* Otherwise there is a lockfree match, transform the call from:
+void fn(T* mem, T* desired, T* return, model)
+ into
+*((In *)return = fn (T* mem, *((In *)desired, model)
On Oct 25, 2011, at 10:52 AM, DJ Delorie wrote:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01622.html
In general, target-specific parts of libiberty may be committed with
only that target's maintainer's approval.
Ok, then, thanks. You're good to go Iain, since I've reviewed and approved it.
On Oct 19, 2011, at 11:45 PM, Terry Guo wrote:
These four cases check the amount of the desired instructions. At O2 level,
some factors like loop unroll will increase the amount of them. This patch
is proposing to adjust the optimization level to O1 (the minimal
requirement) to avoid such
On Oct 22, 2011, at 6:48 PM, Jonathan Gray wrote:
fixincludes was changing the definition of
NULL on OpenBSD from
#ifndef NULL
#ifdef __GNUG__
#define NULL__null
#else
#define NULL((void *)0)
#endif
#endif
to
#ifndef NULL
#ifdef __GNUG__
#define NULL__null
#else
PR libstdc++/50862
* include/std/condition_variable (condition_variable_any::wait): Fix
deadlock and ensure _Lock::lock() is called on exit.
(condition_variable_any::native_handle): Remove, as per LWG 1500.
*
Hi,
There is no difference bewteen *mmx_maskmovq_rex and *mmx_maskmovq_rex
execept for :SI vs :DI. This patch removes *mmx_maskmovq_rex and use
:P instead. OK for trunk if there are no regressions?
Thanks.
H.J.
---
2011-10-25 H.J. Lu hongjiu...@intel.com
* config/i386/mmx.md
On 10/25/2011 02:09 PM, H.J. Lu wrote:
* config/i386/mmx.md (*mmx_maskmovq): Replace :SI with :P and
remove !TARGET_64BIT
(*mmx_maskmovq_rex): Removed.
Ok.
r~
On Tue, Oct 25, 2011 at 5:15 AM, Tom de Vries tom_devr...@mentor.com wrote:
Richard,
I have a patch for the i686 bootstrap problem reported in PR50763 comment 10.
pr50763-2.c looks like this before tail_merge_optimize:
...
std_canonical_va_list_type (union tree_node * typeD.1608)
{
This is a follow up to my last two changes to the condition_variable
code. For some reason G++ didn't reject the explicitly-defaulted
functions in src/condition_variable.cc even though they had different
exception specifications to the declaration. I will try to file that
in bugzilla but can't
This is exactly the same thinko as that of rs6000:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01624.html
with the same fallout, i.e. assertion failure in gt_ggc_m_S.
Fixed thusly, tested on ia64-hpux, applied on the mainline as obvious.
2011-10-25 Eric Botcazou ebotca...@adacore.com
Now that expand_binop handles lowering vec_extract_even to vec_perm,
we can remove the last two unnecessary vec_extract patterns from the
Altivec backend.
Ok?
r~
---
gcc/config/rs6000/altivec.md | 68 --
gcc/config/rs6000/rs6000.c |7 -
On 10/25/2011 12:12 PM, Andrew MacLeod wrote:
OK, how's this. (just the c-common.c file)
It seems to work fine. Past all the basic tests, and bootstraps in an
incremental bootstrap. I'll kick off a full scratch bootstrap/test before
feeling all warm and fuzzy tho :-)
Looks good.
r~
GNAT uses the special DW_AT_GNAT_descriptive_type attribute to describe the
structure of complex types (discriminated records with variant parts). This
attribute points to another record type, which can partially replicate the
structure of the original type. In particular, it can indirectly
Eric, could you please take a look again at your reload bug fix
first posted at:
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01671.html
It looks correct to me, and I can reproduce it with the VIS3 fp moves
enabled by simply adjusting the costs and register class preferences
such
From: Eric Botcazou ebotca...@adacore.com
Date: Wed, 26 Oct 2011 00:22:26 +0200
Eric, could you please take a look again at your reload bug fix
first posted at:
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01671.html
It looks correct to me, and I can reproduce it with the VIS3 fp moves
I noticed that gimplification made some code in tree-eh.c unnecessary,
but did not actually remove it. This patch cleans up tree-eh.c to
remove the unnecessary code and simplify the do_return_redirection
function slightly. Bootstrapped and ran testsuite on
x86_64-unknown-linux-gnu. Committed to
On Tue, Oct 25, 2011 at 03:01:37PM -0700, Richard Henderson wrote:
Now that expand_binop handles lowering vec_extract_even to vec_perm,
we can remove the last two unnecessary vec_extract patterns from the
Altivec backend.
Ok?
Just to be sure, the lowering doesn't depend on -ftree-vectorize
Two testcases for MS format attributes needed updating after Paolo
Bonzini's 2010-11-13 improvements to format checking diagnostics
(r166698). I've applied this patch to update them. Tested with cross to
i686-mingw32.
2011-10-25 Joseph Myers jos...@codesourcery.com
*
Hi,
double checked that gcc.pot is now ok and committed as trivial
Thanks,
Paolo.
PS: eh, I patched 'main'! ;)
//
2011-10-25 Paolo Carlini paolo.carl...@oracle.com
PR translation/46617
* gcc.c (main): Fix fatal_error string for translation.
Index: gcc.c
The external library only provides the
__atomic_fetch_{add,sub,and,or,xor,nand} routines, which fetch the value
in memory before the operation is performed. It does not provide the
alternate operation which fetches the value after the operation (it is
trivial to calculate).
If the
67 matches
Mail list logo
