On Thu, Jan 26, 2012 at 05:07:38PM -0800, Roland McGrath wrote:
> What do folks think about this change? It obviously should have no effect
> whatsoever on builds not using glibc. I'm pretty confident that it won't
> have any bad effect on a build using any extant version of glibc that had
> pthr
That's a Fortran 2008 feature.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-27 Tobias Burnus
PR fortran/51953
* match.c (gfc_match_allocate): Allow more than allocate
object with SOURCE=.
2012-01-27 Tobias Burnus
PR fortran/51953
* gfortran.dg/allocate_allo
As listed in the GCC Coding Conventions
http://gcc.gnu.org/codingconventions.html
"command line" is a noun phrase, and the adjective form is hyphenated,
as in "command-line option". Since invoke.texi talks a lot about
command-line options to GCC, we ought to describe them correctly. ;-)
I'
I noticed that the documentation for -Wcoverage-mismatch was placed in
the wrong section in invoke.texi. Fixed thusly.
-Sandra
2012-01-27 Sandra Loosemore
gcc/
* doc/invoke.texi (Language Independent Options): Move
-Wcoverage-mismatch blurb from here
(Wa
On Thu, 2012-01-26 at 19:13 -0500, David Edelsohn wrote:
> On Thu, Jan 26, 2012 at 5:30 PM, Peter Bergner wrote:
> > The 476 cpu has dynamic branch prediction, so we don't want to always
> > use static branch prediction hints. Is the following patch ok assuming
> > my currently running bootstrap/
Emit some state hidden in cp/decl2.c: pending_statics, deferred_fns, and
no_linkage_decls.
One tests is now passing, two tests are now okay, and three tests have
improved, but are still failing.
Index: gcc/testsuite/ChangeLog.pph
2012-01-26 Lawrence Crowl
* g++.dg/pph/x1tmplclass1.
> > OK. The attached is closer, but still not quite there.
>
> one step further, to avoid the endless recursion in the install-debug
> target. unsure if that is the right approach. the install now works,
> but the debug library is now built in the install step, not in the
> build step.
As check
For GNU systems, the fact that libgcc/libstdc++ refers to pthread_cancel is
utterly bizarre. I don't know of any rationale for this that has ever
applied to glibc. AFAICT the choice was made based on the foibles of
various non-glibc systems.
In practice, things are working fine on GNU systems no
On Thu, 26 Jan 2012, Josh Stone wrote:
> I noticed that the porting example for c++11 user-defined literals is
> using "smart" double quotes, when code should have straight quotes.
> There's also an operator term that should be in the nearby block.
Good catches, both of them, Josh! And thanks fo
On Thu, Jan 26, 2012 at 5:30 PM, Peter Bergner wrote:
> The 476 cpu has dynamic branch prediction, so we don't want to always
> use static branch prediction hints. Is the following patch ok assuming
> my currently running bootstrap/regtesting doesn't uncover any regressions?
>
> Is this appropria
Hi,
I noticed that the porting example for c++11 user-defined literals is
using "smart" double quotes, when code should have straight quotes.
There's also an operator term that should be in the nearby block.
Thanks,
Josh
2012-01-26 Josh Stone
* htdocs/gcc-4.7/porting_to.html: Use s
Dominique found out that there is no diagnostic for polymorphic arrays.
This patch adds it.
From the F2008 standard:
"C1289 All dummy arguments of an elemental procedure shall be scalar
noncoarray dummy data objects and shall not have the POINTER or
ALLOCATABLE attribute."
"An elemental sub
Hello Everyone,
This patch is for the Cilkplus branch affecting both the C and C++
Compilers. This patch will fix a bug for max and min-index builtin function.
The original implemention was comparing the max/min index with the value in the
array. This patch will add a new variable and store
I have once again merged trunk to gccgo branch, this time revision
183589.
Ian
> The second hunk was already in? Still OK.
Yeah, Jakub asked me to change the numbers for the DW_FORM codes for
upstream checkin, but the DW_AT codes we're using are OK.
-cary
On 01/26/2012 05:15 PM, Dodji Seketeli wrote:
Jason Merrill writes:
Hmm...what if rather than trying to ignore levels when comparing, we
make it so the sibling list always has level 1?
I am not sure to understand how you'd do that. You mean that instead of
pointing to the actual vector of i
On 1/26/12 5:50 PM, Cary Coutant wrote:
OK to backport this from trunk to google/main and google/gcc-4_6?
Sorry, that diff isn't right, since an earlier version of this patch
is already in those branches. Here's the right diff...
The second hunk was already in? Still OK.
Diego.
> OK to backport this from trunk to google/main and google/gcc-4_6?
Sorry, that diff isn't right, since an earlier version of this patch
is already in those branches. Here's the right diff...
-cary
2012-01-26 Cary Coutant
* dwarf2.h (enum dwarf_form): Update Fission extensions, add
w
On Thu, Jan 26, 2012 at 17:45, Cary Coutant wrote:
> OK to backport this from trunk to google/main and google/gcc-4_6?
Yes.
Diego.
OK to backport this from trunk to google/main and google/gcc-4_6?
[I've fixed the include/ChangeLog entry from "include/dwarf2.h" to "dwarf2.h".]
-cary
On Thu, Jan 26, 2012 at 2:04 PM, Cary Coutant wrote:
>> Especially in this case where it is primarily for experimenting with it I
>> think usi
From: Richard Henderson
Date: Fri, 27 Jan 2012 09:41:10 +1100
> On 01/27/2012 09:34 AM, David Miller wrote:
>> From: Richard Henderson
>> Date: Fri, 27 Jan 2012 09:29:00 +1100
>>
>>> Two of the patches have been posted here before; the libstdc++
>>> patch was approved by Benjamin.
>>>
>>> All o
On 01/27/2012 09:34 AM, David Miller wrote:
> From: Richard Henderson
> Date: Fri, 27 Jan 2012 09:29:00 +1100
>
>> Two of the patches have been posted here before; the libstdc++
>> patch was approved by Benjamin.
>>
>> All of the patches tested on sparc64-linux, and sanity checked
>> on x86_64-li
From: Richard Henderson
Date: Fri, 27 Jan 2012 09:29:00 +1100
> Two of the patches have been posted here before; the libstdc++
> patch was approved by Benjamin.
>
> All of the patches tested on sparc64-linux, and sanity checked
> on x86_64-linux. I've cross-compiled for m68k-linux, but I've
> o
The 476 cpu has dynamic branch prediction, so we don't want to always
use static branch prediction hints. Is the following patch ok assuming
my currently running bootstrap/regtesting doesn't uncover any regressions?
Is this appropriate for the 4.6 and 4.5 branches as well?
Peter
* conf
Two of the patches have been posted here before; the libstdc++
patch was approved by Benjamin.
All of the patches tested on sparc64-linux, and sanity checked
on x86_64-linux. I've cross-compiled for m68k-linux, but I've
only been able to visually sanity check the code in libstdc++.
Committed. H
On Thu, Jan 26, 2012 at 02:20:12PM -0800, Cary Coutant wrote:
> >> 2012-01-26 Cary Coutant
> >>
> >> * include/dwarf2.h (enum dwarf_form): Add Fission extensions.
> >> (enum dwarf_attribute): Likewise.
> >
> > This is ok.
>
> Thanks. I don't remember what the procedure is, though --
>> 2012-01-26 Cary Coutant
>>
>> * include/dwarf2.h (enum dwarf_form): Add Fission extensions.
>> (enum dwarf_attribute): Likewise.
>
> This is ok.
Thanks. I don't remember what the procedure is, though -- do I check
it in to both gcc and binutils trees, or just one and let it sync
On Thu, Jan 26, 2012 at 02:04:59PM -0800, Cary Coutant wrote:
> 2012-01-26 Cary Coutant
>
> * include/dwarf2.h (enum dwarf_form): Add Fission extensions.
> (enum dwarf_attribute): Likewise.
This is ok.
> commit 0097fed73afa307f5cfc5de9cae0d3041f66193f
> Author: Cary Coutant
> Dat
Jason Merrill writes:
> Hmm...what if rather than trying to ignore levels when comparing, we
> make it so the sibling list always has level 1?
I am not sure to understand how you'd do that. You mean that instead of
pointing to the actual vector of innermost template parms,
TEMPLATE_PARM_SIBLING
Comparing by same_type_p means that we treat any template parameter of
the appropriate level and index as equivalent. But that should be OK,
since we only have one set of level N template parameters in scope. So
I think we should be able to just compare the level of the template
parameter to
Hmm...what if rather than trying to ignore levels when comparing, we
make it so the sibling list always has level 1?
BTW, let's avoid calling a function named *_real directly from client code.
Jason
On Thu, Jan 26, 2012 at 11:18:24AM -0800, Cary Coutant wrote:
> FORM codes aren't added very often because they do break
> compatibility, so I wouldn't expect values in the 0x70-7f range to
> collide with any future standard FORM codes. I did want to keep them
> in the single-byte LEB128 range, alt
When generating hash and equality functions for types, it's not
necessary to generate them for private fields of named structs defined
in different packages. There is no way that the code can call those
functions directly anyhow. Generating them is problematic because it
may lead to calls to func
Hi!
When a VALUE contains already some constant location, it will be always
preferable to expressing it by some other expression - const (or some
similar reverse operation), so we just should point at adding the
reverse_op.
This fixes the testcase from the PR on mips64-linux, bootstrapped/regtest
A small fixlet to deal with files that have errors in them. When we
are about to generate PPH output, we check if there have been errors
emitted for the file. If so, we disable PPH generation.
Testing this, I found that we were not clearing pph_out_stream
when disabling PPH. Fixed.
2012-01-26
This patch fixes expressions involving polymorphic arrays and, thus,
MOVE_ALLOC.
I have also two minor fixes (cf. trans-decl.c).
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-26 Tobias Burnus
PR fortran/51970
PR fortran/51977
* primary.c (gfc_match_varspec. gfc_m
Rainer Orth writes:
> Ian Lance Taylor writes:
>
>>> This also broke bootstrap on x86_64-unknown-linux-gnu (CentOS 5.5):
>>>
>>> /vol/gcc/src/hg/trunk/local/libgo/go/net/fd_linux.go:40:46: error:
>>> reference to undefined identifier 'syscall.EPOLL_CLOEXEC'
>>
>> Thanks. Fixed like so. Bootst
> If the DW_FORM_ values are meant to be in a vendor range of forms
> (which DWARF4 unfortunately doesn't have), aren't they too low, i.e. isn't
> there risk that eventually they'll clash with standard forms?
> The forms numbers aren't limited to 0 .. 0x7f, at the expense of a slightly
> bigger abb
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 to check for sysroot
Hello Everyone,
This patch is for the Cilkplus branch affecting both C and C++ compiler. It
implements the builtin function called "__sec_implicit_index" that is part of
the Array Notations in Cilkplus.
Thanking You,
Yours Sincerely,
Balaji V. Iyer.
diff --git a/gcc/ChangeLog.cilk b/gcc/Ch
Hello Everyone,
This patch is for the Cilkplus branch affecting both C and C++ compiler. It
implements the builtin function called "__sec_implicit_index" that is part of
the Array Notations in Cilkplus.
Thanking You,
Yours Sincerely,
Balaji V. Iyer.diff --git a/gcc/ChangeLog.cilk b/gcc/Cha
On 01/26/2012 01:27 PM, Jakub Jelinek wrote:
> On Thu, Jan 26, 2012 at 11:05:21AM +0100, Andreas Krebbel wrote:
>> *** gcc/testsuite/gfortran.dg/reassoc_4.f.orig
>> --- gcc/testsuite/gfortran.dg/reassoc_4.f
>> ***
>> *** 1,6
>> --- 1,7
>> ! { dg-do compile }
>> ! { dg-opti
This patch fixes a bug in the handling of #include files in PPH files.
The bug is a bit convoluted, so an example is easier. Given the files
foo.h
#include "1.h"
#include "2.h"
#include "3.h"
1.h
#include "2.h"
Assume that all the files are properly double-guarded, and that we are
generating P
> 2012-01-25 Jakub Jelinek
>
> PR rtl-optimization/51978
> * ree.c (make_defs_and_copies_lists): Change set_pat type
> to const_rtx.
> (combine_reaching_defs): Likewise.
> (struct re_info): Remove.
> (add_removable_extension): Remove x and data arguments,
>
On Thu, Jan 26, 2012 at 3:23 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 24 Jan 2012, Richard Guenther wrote:
>
>> > + && !is_gimple_reg (t))
>> > +
>>
>> Ok with the excessive vertical space removed.
>
> Actually the patch as is was regressing some testcases (pr48794.f90, fixed
> with an tr
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 to check for sysroot set to '/' and
special case this in two places. Afaics, there are no
Hi!
My recent change to make_relative_prefix_1 introduced a warning, if alloca
is defined as a macro.
Fixed thusly, committed to trunk and sources CVS as obvious.
2012-01-26 Jakub Jelinek
* make-relative-prefix.c (make_relative_prefix_1): Avoid warning
about using preprocesso
Hi,
On Tue, 24 Jan 2012, Richard Guenther wrote:
> > + && !is_gimple_reg (t))
> > +
>
> Ok with the excessive vertical space removed.
Actually the patch as is was regressing some testcases (pr48794.f90, fixed
with an tree-eh change in another thread) and pack9.adb, which is fixed
with
On Thu, 26 Jan 2012, Eric Botcazou wrote:
> > Of course get_inner_reference looks through these kind of
> > conversions when returning the ultimate decl in MEM [&foo],
> > see the jumps in tree-ssa-alias.c we perform to re-discover
> > the view-converting cases ... (at some point I realized that
>
> Of course get_inner_reference looks through these kind of
> conversions when returning the ultimate decl in MEM [&foo],
> see the jumps in tree-ssa-alias.c we perform to re-discover
> the view-converting cases ... (at some point I realized that
> this probably wasn't the best design decision). S
On Thu, 26 Jan 2012, Richard Guenther wrote:
> On Thu, 26 Jan 2012, Eric Botcazou wrote:
>
> > > Now that Richi has fixed up SRA not to pessimize code by changing non-BLK
> > > mode arguments into their BLKmode subparts, I think it would be nice
> > > to fix up also the expansion of the BLKmode M
Privet, my gentleman
True love comes quietly, without banners or flashing lights. If you
hear bells, get your ears checked.
In the vast uncertainly in the space we call life I know one beautiful
day you will come into my mind and fill the emptiness of my life. The
hollow ring of the wind will h
On 01/25/12 14:16, Richard Henderson wrote:
On 01/25/2012 01:30 PM, Patrick Marlier wrote:
From my point of view, no. When it is a thread local, it should not
be shared to someone else. If the thread dies, what happens to the
thread local variable? Should it be discarded completely and this
pie
> Hmm, how can store_field run into an "alias set conflict"? ...
Bad wording... I meant an alias set issue. The two alias sets (that of the
BLKmode type and that of the non-BLKmode type) precisely don't conflict when
store_field does its spilling trick (third "if" in the function) so it stops.
On 01/26/2012 06:40 AM, Paolo Carlini wrote:
Ok for Stage 1?
Yep.
Jason
On 01/26/2012 06:01 AM, Paolo Carlini wrote:
The fix I'm proposing for 4.7.0 seems to me very safe
OK.
but for 4.8 we may
want to revisit these things, maybe we want to keep the invariant that
even in error conditions the arguments are always stored in a TREE_VEC
I think I prefer the curren
On Thu, 26 Jan 2012, Eric Botcazou wrote:
> > Now that Richi has fixed up SRA not to pessimize code by changing non-BLK
> > mode arguments into their BLKmode subparts, I think it would be nice
> > to fix up also the expansion of the BLKmode MEM_REFs that have non-BLKmode
> > non-addressable base d
> Now that Richi has fixed up SRA not to pessimize code by changing non-BLK
> mode arguments into their BLKmode subparts, I think it would be nice
> to fix up also the expansion of the BLKmode MEM_REFs that have non-BLKmode
> non-addressable base decl. While this doesn't happen for this testcase
>
Hi,
On Thu, 26 Jan 2012, Richard Henderson wrote:
> On 01/26/2012 03:04 AM, Michael Matz wrote:
> > Actually, resx/eh_dispatch always are the last BB statements, so the loop
> > doesn't need to look at all statements in a BB, making it quite somewhat
> > faster. Consider the tree-eh.c to be lo
2012/1/26 Richard Guenther :
> On Wed, Jan 25, 2012 at 10:00 PM, Andrew Pinski wrote:
>> On Wed, Jan 25, 2012 at 12:58 PM, Richard Henderson wrote:
>>> On 01/26/2012 05:44 AM, Kai Tietz wrote:
the following patch fixes a bootstrap issue for libjava (compile of
verify.cc ICEs). It is ca
On Thu, Jan 26, 2012 at 11:05:21AM +0100, Andreas Krebbel wrote:
> *** gcc/testsuite/gfortran.dg/reassoc_4.f.orig
> --- gcc/testsuite/gfortran.dg/reassoc_4.f
> ***
> *** 1,6
> --- 1,7
> ! { dg-do compile }
> ! { dg-options "-O3 -ffast-math -fdump-tree-reassoc1" }
> ! { d
On Tue, Jan 24, 2012 at 04:38:46PM +0100, Richard Guenther wrote:
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
> 2012-01-24 Richard Guenther
>
> PR tree-optimization/50444
> * expr.c (expand_assignment): Handle misaligned bases consistently,
> even when
2012-01-26 Andreas Krebbel
* gcc.dg/ssa-dom-thread-4.c: Set -mbranch-cost=2 for s390 and
s390x.
---
gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c |1 +
1 file changed, 1 insertion(+)
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
Hello,
In the example of the patch, the U in 'typename U::X r' should bind to
the template parameter U rather than the class member U.
I think the problem comes from parameter_of_template_p that compares
parameters by using pointer equality, rather than by using type
equivalence like compparms do
Hi,
the straightforward fix per the audit trail. Tested x86_64-linux.
Ok for Stage 1?
Thanks,
Paolo.
/cp
2012-01-26 Paolo Carlini
PR c++/51989
* typeck2.c (build_x_arrow): Take a tsubst_flags_t argument and
propagate it.
* cp-tree.h
On 26 January 2012 10:47, Jakub Jelinek wrote:
> Hi!
>
> On this testcase we ICE because we have
> (insn 65 64 9 2 (set (reg/f:SI 2 r2 [141])
> (unspec:SI [
> (reg/f:SI 2 r2 [141])
> (const_int 8 [0x8])
> (const_int 1 [0x1])
> ] UNSPEC
On Thu, Jan 26, 2012 at 10:35 AM, Tom de Vries wrote:
> Richard,
>
> This patch fixes PR51990.
>
> The patch adds handling of WITH_SIZE_EXPR in copy_reference_ops_from_ref and
> create_component_ref_by_pieces_1, preventing ICEs on the test-cases.
The create_component_ref_by_pieces_1 handling is i
Hi,
in this minor diagnostic regression we ICE in dump_decl when we try to
print the template arguments, which in this case are just
error_mark_node, nothing sensible, not a TREE_VEC actually (the user
entered repeated ).
The fix I'm proposing for 4.7.0 seems to me very safe but for 4.8 we m
On Wed, Jan 25, 2012 at 10:54 PM, Richard Henderson wrote:
> On 01/26/2012 03:04 AM, Michael Matz wrote:
>> Actually, resx/eh_dispatch always are the last BB statements, so the loop
>> doesn't need to look at all statements in a BB, making it quite somewhat
>> faster. Consider the tree-eh.c to be
On Wed, Jan 25, 2012 at 10:00 PM, Andrew Pinski wrote:
> On Wed, Jan 25, 2012 at 12:58 PM, Richard Henderson wrote:
>> On 01/26/2012 05:44 AM, Kai Tietz wrote:
>>> the following patch fixes a bootstrap issue for libjava (compile of
>>> verify.cc ICEs). It is caused by the assumption that a GIMPL
On Wed, Jan 25, 2012 at 5:01 PM, Jakub Jelinek wrote:
> Hi!
>
> Apparently $(inst_sources) is included in libc__98convenience_la_SOURCES and
> libc__98_la_SOURCES twice, once directly, once through $(host_sources_extra)
> included in $(sources). On x86_64-linux and others it causes just lots
> of
Hi!
On this testcase we ICE because we have
(insn 65 64 9 2 (set (reg/f:SI 2 r2 [141])
(unspec:SI [
(reg/f:SI 2 r2 [141])
(const_int 8 [0x8])
(const_int 1 [0x1])
] UNSPEC_PIC_BASE)) rh784748.i:13 187 {pic_add_dot_plus_eight}
Hi,
I've applied the attached patch to mainline in order to make some
testsuite fails to disappear on s390 and s390x.
gcc.dg/pr46309.c: This testcase depends on branch cost being above 1.
I've copied the AVR solution and added a -mbranch-cost option
to the back-end. That's probabl
Richard,
This patch fixes PR51990.
The patch adds handling of WITH_SIZE_EXPR in copy_reference_ops_from_ref and
create_component_ref_by_pieces_1, preventing ICEs on the test-cases.
Bootstrapped and reg-tested on x86_64.
Ok for stage4 or stage1?
Thanks,
- Tom
2012-01-26 Tom de Vries
On 25 January 2012 20:55, Richard Henderson wrote:
> On 01/26/2012 02:35 AM, Greta Yorsh wrote:
>> Before the change, __sync_lock_release expanded into STRD, storing DI value
>> 0.
>
> The most important question is: Is STRD guaranteed to perform the store
> atomically? (And conversely, does LDR
On Wed, 25 Jan 2012, Jason Merrill wrote:
> The problem here turns out to be that when free_lang_data_in_cgraph tries to
> find all the decls and types in a function, it doesn't catch a type that only
> appears in the fntype of a GIMPLE_CALL. This patch fixes the bug; is there a
> better way to h
On Wed, Jan 25, 2012 at 05:54:26PM -0800, Cary Coutant wrote:
> I'd like to add these new DW_AT and DW_FORM codes for the Fission project:
>
>http://gcc.gnu.org/wiki/DebugFission
>
> We're currently working on the Fission implementation in GCC, gold,
> and binutils, but I'd like to at least l
77 matches
Mail list logo
