On Tue, 28 Aug 2012, Cary Coutant wrote:
> 2012-08-28 Cary Coutant
>
> * gcc/dwarf2out.c (clone_tree_partial): Remove.
> (copy_decls_walk): Don't copy children of a declaration
> into a type unit.
Can't say anything about the patch but watch out with the
changelog entry: put
This patch is for trunk and the google/gcc-4_7 branch.
When a class template instantiation is moved into a separate type unit,
it can bring along a lot of other referenced types into the type unit,
especially if the template is derived from another (large) type that
does not have an actually have
> > ... finally got around to fixing up the generated HTML, so that
> > charset is set to UTF-8.
>
> I regenerated doc/html and checked it in. Attached are the diffs.
... here using xhtml that will validate with W3c checkers.
-benjamindiff --git a/libstdc++-v3/doc/Makefile.am b/libstdc++-v3/do
... finally got around to fixing up the generated HTML, so that charset
is set to UTF-8.
Sorry this took so long.
tested x86/linux
-benjamindiff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 3853472..5c86bb9 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/config
> I'll need a more surgical fix to this, but I'm having trouble creating
> a small test case that demonstrates the problem I'm seeing in the
> pathological test case I have, so it's been a real pain to analyze.
OK, I think I have a reasonably small test case that illustrates the
problem. Here we h
On Tue, Aug 28, 2012 at 5:55 PM, H.J. Lu wrote:
>
> Here is a patch. OK to install?
>
> Thanks.
>
> --
> H.J.
> ---
> * argv.c (dupargv): Replace malloc with xmalloc. Don't check
> xmalloc return.
> (buildargv): Likewise.
> (expandargv): Don't check dupargv return
On Tue, Aug 28, 2012 at 5:09 PM, Ian Lance Taylor wrote:
> On Tue, Aug 28, 2012 at 11:33 AM, H.J. Lu wrote:
>>
>> buildargv uses alloca to allocate buffer, whose size may exceed stack
>> limit. This patch replaces alloca with xmalloc/free. OK to install?
>>
>> Thanks.
>>
>> H.J.
>> ---
>>
On 28 August 2012 11:08, François Dumont wrote:
> (erase(const key_type&)): Use latters.
Let's put "Use the new member functions" here in the ChangeLog, I
don't think you can make a plural out of "latter" :-)
> * testsuite/23_containers/unordered_map/erase/54296.cc: New.
> * testsuit
On Tue, Aug 28, 2012 at 11:33 AM, H.J. Lu wrote:
>
> buildargv uses alloca to allocate buffer, whose size may exceed stack
> limit. This patch replaces alloca with xmalloc/free. OK to install?
>
> Thanks.
>
> H.J.
> ---
> PR binutils/14526
> * argv.c (buildargv): Replace alloca w
Oleg Endo wrote:
> I think it would be better to rename the option '-menable-tas' (new in
> 4.8) to '-mtas', since no other SH specific option has an 'enable' in
> the name. Tested with
> make all-gcc
> make info dvi pdf
>
> OK?
OK.
Regards,
kaz
Oleg Endo wrote:
> This cleans up SH's MD a little by using some iterators.
> No functional changes, just cosmetics.
> Tested briefly with
> 'make all'
> make -k check-gcc RUNTESTFLAGS="sh.exp --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> and comparing
> The CLEANUP_CFG_CHANGED path looks unnecessary, it looks like this is
> mostly for repairing loops but I don't see a reason for this in
> postreload (loops have been freed at that point). I could do
> cleanup_cfg(0) but there shouldn't be much to clean up other than
> unreachable blocks. I see de
Hans-Peter Nilsson writes:
> On Tue, 28 Aug 2012, Richard Sandiford wrote:
>> Hans-Peter Nilsson writes:
>> > On Sun, 26 Aug 2012, Richard Sandiford wrote:
>> >> I'm preparing a patch to turn gcc.target/mips into a torture-like
>> >> testsuite.
>> >
>> > While on the subject of gcc.target/mips an
On 08/23/2012 03:51 AM, Chung-Lin Tang wrote:
WRT only the code expansion aspects in store_fixed_bit_field(), would a
test of "STRICT_ALIGNMENT&& MEM_ALIGN(op0)< GET_MODE_ALIGNMENT(mode)"
be sufficient to detect instead of a packedp parameter?
As an experiment, I tried putting in an assertio
On Tue, 28 Aug 2012, Richard Sandiford wrote:
> Hans-Peter Nilsson writes:
> > On Sun, 26 Aug 2012, Richard Sandiford wrote:
> >> I'm preparing a patch to turn gcc.target/mips into a torture-like
> >> testsuite.
> >
> > While on the subject of gcc.target/mips and its extensions, it
> > also doesn'
On Tue, Jun 28, 2011 at 8:49 AM, H.J. Lu wrote:
> On Tue, Jun 28, 2011 at 4:59 AM, Diego Novillo wrote:
>> On 11-06-27 19:09 , Doug Kwan wrote:
>>>
>>> This patch enables both ld and gold in gcc using the -fuse-ld switch. The
>>> original patch use written by Nick Clifton and was subsequently up
On Tue, 28 Aug 2012, Mike Stump wrote:
> So, I was thinking about this a little... Native compilers usually want
> the pretty verbose stuff and can usually pay the price. Cross compilers
> as a class, are less able to pay the price. Maybe we want to default
> based merely on target != host?
Since last merge PARISC bootstrap fails. The following patch fixes it.
The patch was successfully bootstrapped on x86/x86-64 and PARISC.
Committed as rev. 190759.
2012-08-28 Vladimir Makarov
* lra-constraints.c (extract_loc_address_regs): Check on a simple
plus when index r
Hans-Peter Nilsson writes:
> On Sun, 26 Aug 2012, Richard Sandiford wrote:
>> I'm preparing a patch to turn gcc.target/mips into a torture-like
>> testsuite.
>
> While on the subject of gcc.target/mips and its extensions, it
> also doesn't handle a build configured with --with-synci=yes.
> (Well,
Hi,
buildargv uses alloca to allocate buffer, whose size may exceed stack
limit. This patch replaces alloca with xmalloc/free. OK to install?
Thanks.
H.J.
---
PR binutils/14526
* argv.c (buildargv): Replace alloca with xmalloc/free.
diff --git a/libiberty/argv.c b/libiberty/ar
On 28 August 2012 18:27, Michael Haubenwallner wrote:
>>
>> Does it actually produce a segfault? I suppose it might on some
>> platforms, but not all, so I'm not sure it's worth changing.
>
> It does segfault here on (32bit each):
> i686-pc-linux-gnu
> ia64-hp-hpux11.31
> i386-pc-solaris2.10
>
On 28/08/2012 10:51, Tobias Burnus wrote:
> DECL_PURE_P was also set for elemental procedures, which is wrong if
> they are IMPURE.
>
> Additionally, we do the same checks for PURE also for
> attr.implicit_pure. I think the checks are strict enough that we can
> dare to set DECL_PURE_P also for gf
On 28 August 2012 18:29, Mike Stump wrote:
> On Aug 27, 2012, at 10:15 AM, Jonathan Wakely wrote:
>> Unless anyone has objections I'm going to commit this to trunk,
>
>> implementing Sebastian's idea to disable the verbose terminate handler
>> and the "pure virtual function called" message, which w
On Tue, Jun 23, 2009 at 5:37 AM, Paolo Carlini wrote:
> Hi,
>
> tested x86_64-linux, committed to mainline.
>
> Paolo.
>
> ///
>
> 2009-06-23 Paolo Carlini
>
> PR libstdc++/40518
> * include/bits/basic_string.h (basic_string<>::_Rep::
> _M_set_len
>> 2012-08-25 Cary Coutant
>>
>> gcc/
>> * dwarf2out.c (is_template_instantiation): New function.
>> (should_move_die_to_comdat): Reject types that are template
>> instantiations.
I'm withdrawing this patch. While it does solve the problem in the
specific test case I ha
On Aug 27, 2012, at 10:15 AM, Jonathan Wakely wrote:
> Unless anyone has objections I'm going to commit this to trunk,
> implementing Sebastian's idea to disable the verbose terminate handler
> and the "pure virtual function called" message, which write to stderr
> when a process terminates. This
On 08/28/2012 06:46 PM, Jonathan Wakely wrote:
> On 28 August 2012 16:15, Michael Haubenwallner wrote:
>> Hi,
>>
>> in some old, large, originally C-written application (using gcc-4.2.4 still)
>> I did have to find a bug that boils down to something like this:
>>
>>std::string x;
>>strcpy(
On 28 August 2012 16:15, Michael Haubenwallner wrote:
> Hi,
>
> in some old, large, originally C-written application (using gcc-4.2.4 still)
> I did have to find a bug that boils down to something like this:
>
>std::string x;
>strcpy( (char*) x.c_str(), "abc");
>
> Any subsequent empty std:
> Hi,
>
> On Sun, Aug 19, 2012 at 07:43:45AM +0200, Jan Hubicka wrote:
> >
> > * gcc.dg/ipa/iinline-1.c: Update testcase to test inline hints.
> >
> > * ipa-inline.c (want_inline_small_function_p): Bypass
> > inline limits for hinted functions.
> > (edge_badness): Dump hints;
On 28 August 2012 16:20, Christophe Lyon wrote:
> This makes writing exhaustive, portable (big and little endian),
> executable tests a painful task.
>
For instance, considering the attached sample code, I obtain a
different result in big-endian vs little-endian, while the input
values are the sam
Hi,
in some old, large, originally C-written application (using gcc-4.2.4 still)
I did have to find a bug that boils down to something like this:
std::string x;
strcpy( (char*) x.c_str(), "abc");
Any subsequent empty std::string instance did contain "abc" instead of "",
which was the issue
First, I have now regtested and committed the show_locus bug fix as Rev.
190752.
Cf. http://gcc.gnu.org/ml/fortran/2012-08/msg00197.html
Secondly, the attached patch fixes two valgrind-reported memory issues
when compiling the Polyhedron 2005 files:
a) decl.c: DATA statement's value matching.
Revision to earlier patch to augment the gcov program summary with working set
information. We now emit the non-zero arc counter histogram entries into the
summary, instead of computing the working set information and emitting that
into the summary. The working set information is computed by the c
On Mon, Aug 20, 2012 at 9:58 AM, Ollie Wild wrote:
>
> Jason, any idea when you can look at this?
>
> The patch is about as short as they come, so it shouldn't take long to
> review.
Ping?
On Tue, Aug 28, 2012 at 9:14 AM, Andi Kleen wrote:
\> RDRAND is more for cryptographic purposes (key generation etc.), it's not
> supposed to replace pseudo random generators for simulations.
And that's exactly what random_device is for. It's not an random
number engine like the rest. It's supo
On 27 August 2012 21:29, Janis Johnson wrote:
> On 08/27/2012 08:02 AM, Christophe Lyon wrote:
>> I guess that the 'right' (portable) was of initializing a vector is to
>> load it from an array, right?
>
> See http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01114.html for Richard
> Earnshaw's suggest
Ulrich Drepper writes:
>
> Anyway, another change in the patch is support for a less expensive
> implementation on Ivy Bridge processors. That processor has the
> rdrand instruction. The code uses it if the instruction is usable.
> Has been tested on real hardware. This is not the type of
> arc
Hello,
I think it would be better to rename the option '-menable-tas' (new in
4.8) to '-mtas', since no other SH specific option has an 'enable' in
the name. Tested with
make all-gcc
make info dvi pdf
OK?
Cheers,
Oleg
ChangeLog:
* config/sh/sh.opt (menable-tas): Rename to mtas.
On Tue, Aug 28, 2012 at 8:42 AM, Marc Glisse wrote:
> Thank you for your answers. My main concern was whether it was best to
> implement __get_random_word in libstdc++, or __builtin_random in gcc. But it
> looks like your solution of doing it in libstdc++ makes more sense (at least
> for now).
Th
On Tue, 28 Aug 2012, Ulrich Drepper wrote:
On Tue, Aug 28, 2012 at 3:47 AM, Marc Glisse wrote:
I assume they are different enough that they can't all be abstracted
behind a nice common builtin (with default implementation in libgcc
and/or a macro advertising fast implementations of it) :-(
W
Hello,
This cleans up SH's MD a little by using some iterators.
No functional changes, just cosmetics.
Tested briefly with
'make all'
make -k check-gcc RUNTESTFLAGS="sh.exp --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and comparing CSiBE result-size for '-m
On Tue, Aug 28, 2012 at 3:47 AM, Marc Glisse wrote:
> I assume they are different enough that they can't all be abstracted
> behind a nice common builtin (with default implementation in libgcc
> and/or a macro advertising fast implementations of it) :-(
What is different is the way to interact wi
On Tue, Aug 28, 2012 at 4:44 AM, Paolo Carlini wrote:
> Again, without context, I think this is not the point: random_device is meant
> to be just a simple high level wrapper
> around things like dev/random, inspired by facilities like dev/random on
> unix-like OSes. The brutal "fall back" we ha
Chung-Lin Tang writes:
> * config/mips/mips.md (get_thread_pointer): New pattern.
> * config/mips/mips-protos.h (mips_expand_thread_pointer): Add extern
> declaration.
> * config/mips/mips.c (mips_expand_thread_pointer): Renamed from
> mips_get_tp.
> (mips_g
Hi
Here is the patch for this issue. I introduced 2 distinct methods
to erase elements from a key. The one when keys are unique is rather
simple and now use the same underlying code that the erase method from
iterator. The other one when keys are not unique first look for nodes
matching t
I intent to commit the attached patch as obvious. The current code has:
cmax = (c1 < c2) ? c2 : c1;
if (cmax > terminal_width - 5)
offset = cmax - terminal_width + 5;
...
c1 -= offset;
c2 -= offset;
p = &(lb->line[offset]);
for (i = 0; i <= cmax; i++)
{
int spaces, j;
On Tue, Aug 28, 2012 at 11:24 AM, Igor Zamyatin wrote:
> I'd like this patch (original version at the bottom) also to be
> backported into 4.7.
>
> Is it safe to backport?
Looks safe to me.
OK if there are no objections from RMs in the next 24h.
Thanks,
Uros.
Hi!
I'd like this patch (original version at the bottom) also to be
backported into 4.7.
Is it safe to backport?
On Fri, Aug 24, 2012 at 11:35 AM, Uros Bizjak wrote:
> On Fri, Aug 24, 2012 at 9:22 AM, Igor Zamyatin wrote:
>
>> Following change enables look ahead feature in the code scheduler f
DECL_PURE_P was also set for elemental procedures, which is wrong if
they are IMPURE.
Additionally, we do the same checks for PURE also for
attr.implicit_pure. I think the checks are strict enough that we can
dare to set DECL_PURE_P also for gfortran's attr.implicit_pure
procedures. What do y
Hi again,
Marc Glisse ha scritto:
>On Mon, 27 Aug 2012, Ulrich Drepper wrote:
>
>> This is done in the attached patch. It's rather ugly because of the
>> business with the TR1 support. Is this really still needed? Can't
>we
>> remove that? It really makes not much sense for a random_device t
On 12/7/12 2:53 PM, Chung-Lin Tang wrote:
> Finally, what I personally need, the MIPS parts.
>
> Thanks,
> Chung-Lin
>
> * config/mips/mips.c (mips_get_tp): Add 'target' parameter for
> generating to specific reg.
> (mips_legitimize_tls_address): Update calls to mips_get_t
On 12/7/12 下午2:52, Chung-Lin Tang wrote:
> xtensa parts. No other notes.
>
> Thanks,
> Chung-Lin
>
> * config/xtensa/xtensa.c
> (xtensa_expand_builtin_thread_pointer): Add hook function for
> TARGET_EXPAND_BUILTIN_THREAD_POINTER.
> (xtensa_expand_builtin_set_thread
On 12/7/18 8:05 PM, Andreas Krebbel wrote:
> On 07/12/2012 08:52 AM, Chung-Lin Tang wrote:
>> * config/s390/s390.c (s390_builtin,code_for_builtin_64,
>> code_for_builtin_31,s390_init_builtins,s390_expand_builtin):
>> Remove.
>> (s390_expand_builtin_thread_pointer): A
On 12/7/12 5:47 PM, Ramana Radhakrishnan wrote:
> On 12 July 2012 07:52, Chung-Lin Tang wrote:
>> ARM parts, no further notes.
>>
>
> ARM parts are ok, modulo approval for generic parts and no
> regressions with testing on arm-linux-gnueabi.
ARM parts updated to use MD patterns.
Thanks,
Chung-
On 12/7/12 2:52 PM, Chung-Lin Tang wrote:
> Alpha parts. Note that now the machine-independent
> __builtin_thread_pointer() is now marked as const/readonly, slightly
> different from the original alpha backend code.
Alpha patch updated to use MD pattern.
* config/alpha/alpha.md (get_threa
Hi,
Marc Glisse ha scritto:
>On Mon, 27 Aug 2012, Ulrich Drepper wrote:
>
>> This is done in the attached patch. It's rather ugly because of the
>> business with the TR1 support. Is this really still needed? Can't
>we
>> remove that? It really makes not much sense for a random_device to
>be
On 12/7/12 2:52 PM, Chung-Lin Tang wrote:
> Core parts adding the new hooks. BUILT_IN_THREAD_POINTER and
> BUILT_IN_SET_THREAD_POINTER are different hooks, as some targets only
> implement one of them (thread pointer read).
Following Richard H.'s advice, I have revised the patch to use a
standard
On Mon, 27 Aug 2012, Ulrich Drepper wrote:
This is done in the attached patch. It's rather ugly because of the
business with the TR1 support. Is this really still needed? Can't we
remove that? It really makes not much sense for a random_device to be
predictable.
Er, I haven't read the cont
On Mon, May 21, 2012 at 2:56 AM, Richard Guenther
wrote:
> On Sun, May 20, 2012 at 1:40 AM, Andrew Pinski wrote:
>> The problem here is that tree-if-conv.c produces COND_EXPR instead of
>> the MAX/MIN EXPRs. When I added the expansion from COND_EXPR to
>> conditional moves, I assumes that the ex
59 matches
Mail list logo
