On Fri, Jun 1, 2012 at 11:19 AM, Richard Guenther
wrote:
>> What about toplev.h? dump_file is defined there, after all. I don't mind
>> it in system.h, if that's not a good place for it now. The patch is OK
>> either way.
>
> I'd prefer toplev.h, too. system.h is supposed to be for system head
On 06/03/12 21:40, Xinliang David Li wrote:
Can you explain this more -- what exactly are trying to do? Are you trying
to rebuild multiple times with the same coverage data,
yes -- for instance, in the context of debugging a compiler problem,
you will need to compile the same file multiple ti
You are absolutely right, I forgot to change this as well.
Thanks!
And I really really do hope that this patch will go into GCC 4.8 trunk.
Since arm-elf is marked 'obsolete' in GCC 4.7,
all old bare-metal arm-elf-users will need
to migrate to the the new arm-eabi-toolchain in GCC 4.8.0.
I fear i
This patch adds a cross-reference to GNU libc and _FORTIFY_SOURCE (which
needs to be documented there) and mentions the optimization level
requirements.
Okay for trunk?
2012-06-04 Florian Weimer
* doc/extend.texi (Object Size Checking): Mention
_FORTIFY_SOURCE, add caveat.
On 06/04/2012 10:23 AM, Jakub Jelinek wrote:
On Mon, Jun 04, 2012 at 10:15:35AM +0200, Florian Weimer wrote:
--- gcc/doc/extend.texi (revision 187951)
+++ gcc/doc/extend.texi (working copy)
@@ -7376,8 +7376,15 @@
@findex __builtin___vfprintf_chk
GCC implements a limited buffer overflow prot
Hello,
With the attached patch to move some non-output related prototypes
from output.h to tree.h, another batch of #include output.h cleanups
is possible.
After this patch, only 9 front-end files (out of 210 *.{c,cc,h} files)
still include output.h:
c-family/c-cppbuiltin.c:#include "output.h"
On Fri, 1 Jun 2012, Jason Merrill wrote:
> On 06/01/2012 05:22 AM, Richard Guenther wrote:
> > On Thu, 31 May 2012, Jason Merrill wrote:
> >
> > > The comment mentions PCH in connection with deferred seting of
> > > DECL_ASSEMBLER_NAME; off the top of my head it occurs to me that that
> > > might
I noticed you cannot enable regular loop distribution at -O3 unless
you disable pattern recognition. This lead me to simplifying the
code, changing semantics of the flags slightly (but still compatible
with what I read into their documentation). -floop-distribution
enables loop distribution (but
On Mon, Jun 04, 2012 at 10:34:21AM +0200, Florian Weimer wrote:
> >>+This protection mechanism is only a last resort. As a programmer, you
> >>+must not rely on its presence, but use explicit buffer length checks
> >>+to avoid buffer overflows. GCC may not be able to determine buffer
> >>+sizes a
On Mon, Jun 04, 2012 at 10:15:35AM +0200, Florian Weimer wrote:
> --- gcc/doc/extend.texi (revision 187951)
> +++ gcc/doc/extend.texi (working copy)
> @@ -7376,8 +7376,15 @@
> @findex __builtin___vfprintf_chk
>
> GCC implements a limited buffer overflow protection mechanism
> -that
On 06/04/2012 11:01 AM, Jakub Jelinek wrote:
On Mon, Jun 04, 2012 at 10:34:21AM +0200, Florian Weimer wrote:
+This protection mechanism is only a last resort. As a programmer, you
+must not rely on its presence, but use explicit buffer length checks
+to avoid buffer overflows. GCC may not be a
On Sat, Jun 2, 2012 at 9:48 AM, Jakub Jelinek wrote:
> Hi!
>
> tree-chrec.c and tree-scalar-evolutions.c uses sizetype as type of
> iv->step, but the following spot would use POINTER_TYPE, which leads
> to ICEs. Fixed thusly, bootstrapped/regtested onx 86_64-linux and
> i686-linux, ok for trunk/4
On Fri, Jun 1, 2012 at 1:44 PM, Martin Jambor wrote:
> Hi,
>
> On Fri, Jun 01, 2012 at 11:31:20AM +0200, Richard Guenther wrote:
>> On Fri, Jun 1, 2012 at 6:02 AM, Andrew Pinski
>> wrote:
>> > Hi,
>> > When I modified GCC to change the majority of bitfield accesses
>> > which were done via compo
On Sat, Jun 2, 2012 at 1:36 PM, Paolo Bonzini wrote:
> The ffs function can be converted to ctz if the operand is known not
> to be zero, as is the case for example in
>
> while (x != 0) {
> bit = ffs(x) - 1;
> ...
> x &= ~(1 << bit);
> }
>
> CSE can already do this on x86,
On Sun, Jun 3, 2012 at 2:29 PM, Oleg Endo wrote:
> Hi,
>
> The attached patch adds some documentation for the sincos standard
> pattern name. Tested with 'make info dvi pdf'.
> Is the text correct and OK to apply?
> Maybe it would also make sense to apply it to the 4.7 branch?
Looks good to me.
On Mon, Jun 4, 2012 at 9:00 AM, Steven Bosscher wrote:
> On Fri, Jun 1, 2012 at 11:19 AM, Richard Guenther
> wrote:
>>> What about toplev.h? dump_file is defined there, after all. I don't mind
>>> it in system.h, if that's not a good place for it now. The patch is OK
>>> either way.
>>
>> I'd
On Mon, Jun 4, 2012 at 10:38 AM, Steven Bosscher wrote:
> Hello,
>
> With the attached patch to move some non-output related prototypes
> from output.h to tree.h, another batch of #include output.h cleanups
> is possible.
>
> After this patch, only 9 front-end files (out of 210 *.{c,cc,h} files)
>
On Mon, Jun 4, 2012 at 11:09 AM, Florian Weimer wrote:
> On 06/04/2012 11:01 AM, Jakub Jelinek wrote:
>>
>> On Mon, Jun 04, 2012 at 10:34:21AM +0200, Florian Weimer wrote:
>
> +This protection mechanism is only a last resort. As a programmer, you
> +must not rely on its presence, but
We are using the following patch from Fabien in our tree to fix
a rejects-valid bug quite appearant in our own codebase.
Re-bootstrap and regtest on the branch head currently running,
ok if that succeeds?
Thanks,
Richard.
2012-06-04 Fabien Chêne
PR c++/52841
* parser.c (cp_p
Hi
I updated the patch to correct the length of insn adddi3_neon.
thanks
Carrot
2012-06-04 Wei Guozhi
PR target/53447
* gcc.target/arm/pr53447-1.c: New testcase.
2012-06-04 Wei Guozhi
PR target/53447
* config/arm/arm-protos.h (const_ok_for_adddi): New p
On 06/04/2012 11:46 AM, Richard Guenther wrote:
I think "accurately" is a wrong word here - doesn't that suggest it might
get "wrong"? The answer should always be conservatively correct, so
it might just be not as constrained as it should. So I think you need
to elaborate on "accurately" here.
On Mon, Jun 04, 2012 at 11:59:59AM +0200, Florian Weimer wrote:
> What about this?
>
> +This protection mechanism is only a last resort. As a programmer, you
> +must not rely on its presence, but use explicit buffer length checks
> +to avoid buffer overflows. GCC may not be able to determine obj
On Mon, Jun 4, 2012 at 11:59 AM, Florian Weimer wrote:
> On 06/04/2012 11:46 AM, Richard Guenther wrote:
>>
>> I think "accurately" is a wrong word here - doesn't that suggest it might
>> get "wrong"? The answer should always be conservatively correct, so
>> it might just be not as constrained as
On Mon, 4 Jun 2012, Richard Guenther wrote:
> On Fri, 1 Jun 2012, Jason Merrill wrote:
>
> > Or use your first patch, and decide that we don't care about the linkage
> > name
> > of unreachable types. What types are affected by this, anyway?
So like the following.
Bootstrapped and tested on x
On 06/04/2012 12:11 PM, Jakub Jelinek wrote:
On Mon, Jun 04, 2012 at 11:59:59AM +0200, Florian Weimer wrote:
What about this?
+This protection mechanism is only a last resort. As a programmer, you
+must not rely on its presence, but use explicit buffer length checks
+to avoid buffer overflows.
Without this change, cp_parser_constant_expression reports errors in
C++11 mode, but does not provide any indication to callers, which
continue processing and produce misleading errors.
The changes to check_bitfield_decl and build_enumerator are required for
identical error report in C++11 and
On Mon, Jun 4, 2012 at 11:42 AM, Richard Guenther
wrote:
> There is already statistics.h and tree-dump.h, why is dump_file not in
> tree-dump.h for example? I admit it's all some of a mess ;)
Because tree-dump.h is about tree dumps (and gimple dumps). Yes, it is a mess.
> But system.h
> doesn't
> > - s = s; // { dg-message "synthesized|deleted" }
> > + s = s;
>
> Why do we lose this error?
Good question.
This is the result of a weird behaviour of DejaGNU, I think.
For the record, here is the whole test:
1 // { dg-do compile }
2 // Origin: Mark Mitchell
3
4
2012/6/3 Gabriel Dos Reis :
> On Sun, Jun 3, 2012 at 10:56 AM, Fabien Chêne wrote:
>> 2012/6/3 Jason Merrill :
>>> On 05/24/2012 09:18 AM, Jason Merrill wrote:
OK, thanks.
>>>
>>>
>>> I notice you haven't checked the patch in yet, is there a problem?
>>
>> Not at all, just lack of time,
On Thu, May 31, 2012 at 7:10 AM, H.J. Lu wrote:
> On Thu, May 31, 2012 at 6:50 AM, Jakub Jelinek wrote:
>> On Thu, May 31, 2012 at 06:35:19AM -0700, H.J. Lu wrote:
>>> This patch makes __WCHAR_TYPE__/wchar_t the same for gcc -m32 on
>>> Linux/i386 and Linux/x86-64. OK for trunk?
>>
>> That looks
On 06/04/2012 08:36 AM, Dodji Seketeli wrote:
- /* Build the assignment expression. */
+ /* Build the assignment expression. Its default
+location is the location of the '=' token. */
+ input_location = loc;
expr = build_x_modif
Please add a comment explaining why flag_generate_lto matters there. OK
with that change.
Jason
When the default for CASE_VECTOR_PC_RELATIVE was added to defaults.h
back in 2004 the check in m68k.md wasn't updated.
Andreas.
PR target/53461
* config/m68k/m68k.md ("tablejump"): Fix check for
CASE_VECTOR_PC_RELATIVE.
Index: config/m68k/m68k.md
=
This removes a pointless stmt -> RDG index hash (simply use gimple_uid)
and arranges to compute and analyze data-references once instead of
O(stmts^4) when looking for common data accesses (ugh!).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-06-04 Richard Guenthe
On Mon, 4 Jun 2012, Jason Merrill wrote:
> Please add a comment explaining why flag_generate_lto matters there. OK with
> that change.
Committed as follows.
Thanks,
Richard.
2012-06-04 Richard Guenther
PR middle-end/53471
* dwarf2out.c (dwarf2out_finish): If generating LTO
> On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka wrote:
> >> Actually Dehao also plans to teach the static predictor to understand
> >> standard library functions more (e.g IO functions) and add more naming
> >
> > How this differ from annotating the library?
>
> I find them more suitable to be com
Hi Richard,
Here's a revision of the hoist-adjacent-loads patch. I'm sorry for the
delay since the last revision, but my performance testing has been
blocked waiting for a fix to PR53487. I ended up applying a test
version of the patch to 4.7 and ran performance numbers with that
instead, with n
On Mon, Jun 04, 2012 at 08:45:20AM -0500, William J. Schmidt wrote:
> 2012-06-04 Bill Schmidt
>
> * opts.c: Add -fhoist_adjacent_loads to -O2 and above.
The option name has hyphens instead of underscores in it, so the above is
wrong.
> --- gcc/common.opt(revision 187805)
> +++ gcc/c
This is the last TLC kind of patches for loop distribution. It moves
more loop distribution specific code from tree-data-ref.c to
tree-loop-distribution.c thereby simplifying it. It should now be
reasonably easy and efficient to add more pattern recognitions
(I was thinking about even BLAS-like
Hello YunFeng,
Thank you for taking the time to work on this. I cannot accept or
deny your patches, but I thought I could maybe comment on some parts
of them.
First, IMHO, some of the new plugin events you are proposing to add to
libcpp seem to make sense, at least so that people can write
etags
Hi,
in this "error reporting routines re-entered" ICE we try to emit a
warning from ocp_convert while we are already producing an error message
(we get to ocp_convert via the usual tsubst (tf_none) called by
dump_template_bindings). I considered whether we could avoid the
specific problem by
Jason Merrill writes:
> On 06/04/2012 08:36 AM, Dodji Seketeli wrote:
>> - /* Build the assignment expression. */
>> + /* Build the assignment expression. Its default
>> + location is the location of the '=' token. */
>> + input_location = loc;
>>
Likewise for | comments on m68k. Checked in as obvious.
Andreas.
* g++.dg/debug/dwarf2/nested-3.C: Allow for | comments.
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
b/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
index 56f3dfb..ab8e0d0 100644
--- a/gcc/testsuite/g++.dg/deb
I regression tested the patch presented in the PR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53559
for the following branches:
4.5 branch svn revision 188125
4.6 branch svn revision 188124
4.7 branch svn revision 188128
4.8 trunk svn revision 187734
All bootstrapped with no regressions for po
On Mon, Jun 4, 2012 at 10:08 AM, Edmar wrote:
> I regression tested the patch presented in the PR:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53559
>
> for the following branches:
> 4.5 branch svn revision 188125
> 4.6 branch svn revision 188124
> 4.7 branch svn revision 188128
> 4.8 trunk sv
This PR was reopened because Luke Dalessandro found a testcase that was
still causing the stack corruption.
The problem here is that we split the block and call gsi_start_bb() to
start scanning the new block, but immediately after we call gsi_next()
which essentially skips the first instructio
On 06/04/2012 09:04 AM, Aldy Hernandez wrote:
> PR middle-end/47530
> * trans-mem.c (expand_block_edges): Do not skip the first
> statement when resetting the BB.
Ok.
r~
Hello Dimitrios,
I cannot approve or deny your patch, but I have one question.
[...]
> 2012-06-04 Dimitrios Apostolou
>
> * line-map.c (linemap_enter_macro): Don't zero max_column_hint in
> every macro. This improves performance by reducing the number of
> reallocations whe
First, I would like to ping my move_alloc coarray patches. The handling
is in line with the J3-approved interpretation request F08/0040 with
some remarks of the WG5 convenor (John Reid), cf. PR for the links:
- http://gcc.gnu.org/ml/fortran/2012-05/msg00171.html
- http://gcc.gnu.org/ml/fortran/2
On Mon, Jun 4, 2012 at 12:49 AM, Nathan Sidwell wrote:
> On 06/03/12 21:40, Xinliang David Li wrote:
>
>>> Can you explain this more -- what exactly are trying to do? Are you
>>> trying
>>> to rebuild multiple times with the same coverage data,
>>
>>
>> yes -- for instance, in the context of debu
OK.
Jason
On 06/01/2012 03:55 PM, Florian Weimer wrote:
On 06/01/2012 06:19 PM, Jason Merrill wrote:
On 06/01/2012 11:40 AM, Florian Weimer wrote:
I'm puzzled why build_new is even invoked after detecting that there is
a non-constant expression.
I'd accept a patch to change that.
I don't really now w
On 05/31/2012 10:55 AM, Paolo Carlini wrote:
On 05/31/2012 04:43 PM, Jason Merrill wrote:
Does the C front end warn about this mismatch?
I just tried the first test of g++.old-deja/g++.other/cond5.C and the C
front-end does *not* warn neither by default, neither with -Wall.
Do we warn about
On Sun, Jun 3, 2012 at 11:17 PM, Dehao Chen wrote:
> I've updated the patch using deferred option.
>
> http://codereview.appspot.com/6281047
>
> Thanks,
> Dehao
>
> The new patch:
>
> 2012-06-01 Dehao Chen
>
> * gcc/cgraph.c (cgraph_match_attribute_by_name): New function.
> (cgrap
On Mon, Jun 4, 2012 at 6:24 AM, Jan Hubicka wrote:
>> On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka wrote:
>> >> Actually Dehao also plans to teach the static predictor to understand
>> >> standard library functions more (e.g IO functions) and add more naming
>> >
>> > How this differ from annotat
Hello,
libgcc/config/t-vxworks has
<< LIBGCC2_INCLUDES = -nostdinc -I \
`case "/$$(MULTIDIR)" in \
*/mrtp*) echo $(WIND_USR)/h ;; \
*) echo $(WIND_BASE)/target/h ;; \
esac`
>>
The double "$" was useful back when libgcc was built
within gcc/ and we had
<< gcc/Makefile.in
l
On Fri, Jun 1, 2012 at 4:38 PM, Gabriel Dos Reis
wrote:
> On Fri, Jun 1, 2012 at 6:07 PM, Sterling Augustine
> wrote:
>> After finding yet another bug in the previous patch dealing with
>> pretty-printing
>> decls for dwarf in canonical form, I have figured out a way to do it that is
>> less inv
Hi,
On 06/04/2012 06:55 PM, Jason Merrill wrote:
On 05/31/2012 10:55 AM, Paolo Carlini wrote:
On 05/31/2012 04:43 PM, Jason Merrill wrote:
Does the C front end warn about this mismatch?
I just tried the first test of g++.old-deja/g++.other/cond5.C and the C
front-end does *not* warn neither b
On 06/01/2012 01:34 PM, Jakub Jelinek wrote:
Have you looked at the assembly differences with this in?
It's not great.
Here's an example:
void
write(std::vector& blob, unsigned n, float v1, float v2, float
v3, float v4)
{
blob[n] = v1;
blob[n + 1] = v2;
blob[n + 2] = v3;
blob[n + 3]
Hi,
We should enable x32 run-time library if --with-abi={x32|mx32} is used
to configure GCC i[34567]86-*-* and x86_64-*-*. Tested on Linux/x86-64.
OK for trunk?
Thanks.
H.J.
---
2012-06-04 H.J. Lu
PR target/53575
* config.gcc: Enable x32 run-time library if --with-abi={x32|
On 06/04/2012 10:15 AM, Paolo Carlini wrote:
@@ -5413,7 +5413,7 @@ build_op_delete_call (enum tree_code code, tree ad
fns = lookup_name_nonclass (fnname);
/* Strip const and volatile from addr. */
- addr = cp_convert (ptr_type_node, addr);
+ addr = cp_convert (ptr_type_node, addr, t
Hello,
The attached patch removes one more #include output.h, this time from
c-family/c-pch.c.
Anything written out to asm_out_file between pch_init and
c_common_write_pch is read back in by c_common_write_pch and dumped to
the PCH that's being written out. In c_common_read_pch this data is
writt
On 06/04/2012 01:52 PM, Paolo Carlini wrote:
Ok, this would be simple to do. The only issue I can see, is that in C++
-Wenum-compare has a name, thus can be easily disabled but it's ON by
default.
The warning is already on by default, so that wouldn't be a change; this
just creates a way for u
The following patch solves the problem. Instead of pressure classes
which are focused on relation register moves with memory costs, we use
an uniform classes whose register move costs are the same for all their
sublcasses. The unifrom classes is used not to slow down the 2nd pass.
The pa
On 06/04/2012 06:36 AM, Florian Weimer wrote:
(Sorry if Thunderbird has garbled the changelog entries.)
I add the ChangeLog to the top of the patch to avoid this. :)
- if (TREE_CODE (w) != INTEGER_CST)
+ if (w == error_mark_node)
+ ; /* Continue with error processing below. *
On 06/04/2012 08:24 PM, Jason Merrill wrote:
On 06/04/2012 01:52 PM, Paolo Carlini wrote:
Ok, this would be simple to do. The only issue I can see, is that in C++
-Wenum-compare has a name, thus can be easily disabled but it's ON by
default.
The warning is already on by default, so that wouldn't
On Jun 4, 2012, at 5:36 AM, Dodji Seketeli wrote:
>>> - s = s; // { dg-message "synthesized|deleted" }
>>> + s = s;
>>
>> Why do we lose this error?
>
> Good question.
>
> This is the result of a weird behaviour of DejaGNU, I think.
Yup, that is truly weird. The problem is that the | operato
On Mon, 4 Jun 2012, Florian Weimer wrote:
On 06/01/2012 01:34 PM, Jakub Jelinek wrote:
Have you looked at the assembly differences with this in?
It's not great.
Here's an example:
void
write(std::vector& blob, unsigned n, float v1, float v2, float v3,
float v4)
{
blob[n] = v1;
blob[n +
On Fri, Jun 1, 2012 at 8:08 PM, rbmj wrote:
> Hi all,
>
> In libgfortran/intrinsics/time_1.h:181, there is a typo that refers to
> user_usecs (should be user_usec). This patch fixes it. I don't have commit
> access, so someone please apply this for me. It should be obvious.
Thanks for catching
On 06/04/2012 02:50 PM, Paolo Carlini wrote:
Ok. The below passes the testsuite on x86_64-linux. Ok for mainline and
4.7.1?
OK. But let's leave the bug open until we fix the warning not to
complain about this testcase even with -Wenum-compare on.
Jason
On 06/04/2012 09:16 PM, Jason Merrill wrote:
On 06/04/2012 02:50 PM, Paolo Carlini wrote:
Ok. The below passes the testsuite on x86_64-linux. Ok for mainline and
4.7.1?
OK. But let's leave the bug open until we fix the warning not to
complain about this testcase even with -Wenum-compare on.
> "Lawrence" == Lawrence Crowl writes:
Lawrence> Because libcpp was using a typedef hash_table, that typedef has been
Lawrence> renamed cpp_hash_table and uses of it have changed.
The libcpp changes are ok.
Tom
On 06/04/2012 02:54 PM, Mike Stump wrote:
Yup, that is truly weird. The problem is that the | operator is binding funny
because there are no () around the substituted variables in the matching
expressions in the .exp files, and the messages for a single line get the
opportunity to match and e
On 06/04/2012 09:07 PM, Marc Glisse wrote:
On Mon, 4 Jun 2012, Florian Weimer wrote:
void
write(std::vector& blob, unsigned n, float v1, float v2, float
v3, float v4)
{
blob[n] = v1;
blob[n + 1] = v2;
blob[n + 2] = v3;
blob[n + 3] = v4;
}
Would be great if it ended up testing only n and n+3.
On 05/22/2012 04:37 PM, rbmj wrote:
This patch adds an AC_ARG_ENABLE option to build/not build
libstdc++-v3. I wrote the patch in order to allow the user to
override the automatic disable for libstdc++-v3 for certain targets.
Hi all,
What are the barriers to getting this in? I wrote this so
(xf. http://gcc.gnu.org/ml/gcc/2012-06/msg00043.html)
On Mon, Jun 4, 2012 at 7:05 PM, Jason Merrill wrote:
>>> Jason, is this flag something that we could deprecate for GCC 4.7 and
>>> remove?
>>
>>
>> The docs say the flag is not useful these days as BSS is widely available.
>
>
> Right. So yes
In wwwdocs I would also mention that the flag has no effect on most
targets. In fact, I'm not sure it affects any targets that we still
actually support; are there any a.out targets left?
Jason
On 06/04/2012 08:40 PM, Jason Merrill wrote:
On 06/04/2012 06:36 AM, Florian Weimer wrote:
(Sorry if Thunderbird has garbled the changelog entries.)
I add the ChangeLog to the top of the patch to avoid this. :)
Good idea.
- if (TREE_CODE (w) != INTEGER_CST)
+ if (w == error_mark_node)
+ ;
On Mon, Jun 4, 2012 at 9:45 PM, Jason Merrill wrote:
> In wwwdocs I would also mention that the flag has no effect on most targets.
How about this:
Index: htdocs/gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/cha
>>> - error ("enumerator value for %qD is not an integer constant",
>>> - name);
>>> + if (value != error_mark_node)
>>> + error ("enumerator value for %qD is not an integer constant",
>>> + name);
>>
>>
>> Hmm, I don't see these errors as redundant, but rather as giving context
>> for the previous
On 06/04/2012 09:35 PM, rbmj wrote:
On 05/22/2012 04:37 PM, rbmj wrote:
This patch adds an AC_ARG_ENABLE option to build/not build
libstdc++-v3. I wrote the patch in order to allow the user to
override the automatic disable for libstdc++-v3 for certain targets.
Hi all,
What are the barriers
Hi Tobias,
ASSOCIATE names are (wrongly) initialized by -finit-real=*, thus, their
values are wrong.
The fix seems to be rather obvious, but I am not really an associate
expert.
I'd say it is obvious. OK for trunk, also OK for backporting.
I am unsure whether to put it into 4.7.1, though. Opi
On 06/04/2012 04:30 PM, Steven Bosscher wrote:
How about this:
OK, looks good.
There is still a file config/arm/aout.h
I noticed that, but it seems to be used together with elfos.h, so it
seems not to be a.out-specific. :)
Jason
On 06/04/2012 04:12 PM, Florian Weimer wrote:
This doesn't make sense to me. parser->integral_constant_expression_p
should always be true at this point if you're moving the restore later
(which also seems unnecessary).
I think parser->integral_constant_expression_p reflects the result of
the cp
On Jun 4, 2012, at 12:30 PM, Jason Merrill wrote:
> On 06/04/2012 02:54 PM, Mike Stump wrote:
>> Yup, that is truly weird. The problem is that the | operator is binding
>> funny because there are no () around the substituted variables in the
>> matching expressions in the .exp files, and the mes
On 06/04/2012 05:27 PM, Mike Stump wrote:
That one is, the problem is the work that added error: and warning: processing
differentiation puts together a new expression with concatenation and it is
that use that _also_ needs protecting.
Aha! Sneaky gcc-dg.exp.
- set expmsg [lindex $ne
Now that there are three different varieties of unit, it seems useful to
have a single predicate for them.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit c879217dbfeaddebdde9121eb6750b75f650fe9f
Author: Jason Merrill
Date: Sun May 6 12:24:05 2012 -0400
* dwarf2out.c (is_unit_die)
On Mon, Jun 4, 2012 at 11:59 AM, Sriraman Tallam wrote:
> Hi,
>
> Attaching updated patch for function multiversioning which brings
> in plenty of changes.
>
> * As suggested by Richard earlier, I have made cgraph aware of
> function versions. All nodes of function versions are chained and the
>
On Jun 4, 2012, at 12:45 PM, Jason Merrill wrote:
> In wwwdocs I would also mention that the flag has no effect on most targets.
> In fact, I'm not sure it affects any targets that we still actually support;
> are there any a.out targets left?
The flag can go... The days of not having bss are
This patch fixes PR 53487, so that -misel will no longer cause an unknown insn
error. Andrew Pinksi's changes on May 4th, 2012, changed to use the
movcc pattern instead of the cstore4 in some cases, when a target
machine defines both patterns. The cstore4 pattern had checks in it to
prevent ISELs
On 2012/06/02 01:52:28, asharif wrote:
A trunk version of this patch is already under review. I'm creating
this CL in
order to get this patch in before the branch date.
Ping.
http://codereview.appspot.com/6273045/
Hello Everyone,
This patch is for the Cilkplus branch affecting the C++ compiler. The
compiler crashes when a throw() is set for a spawned function. This patch
should fix that.
Thanks,
Balaji V. iyer.Index: gcc/cp/cilk.c
===
-
The following source change enables coddingconventions.html to
pass the HTML validator at validator.w3.org.
Okay?
Index: codingconventions.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.66
d
On Mon, Jun 4, 2012 at 5:42 PM, Lawrence Crowl wrote:
> The following source change enables coddingconventions.html to
> pass the HTML validator at validator.w3.org.
>
> Okay?
Looks obvious! :-)
-- gaby
On Sat, Jun 2, 2012 at 3:27 PM, H.J. Lu wrote:
> ix86_sched_reorder should skip debug insns. Tested on Linux/ia32.
> OK to install?
>
> 2012-06-02 H.J. Lu
>
> PR bootstrap/53555
> * config/i386/i386.c (ix86_sched_reorder) Skip debug insns.
OK.
Thanks,
Uros.
On 06/04/2012 06:55 PM, Paolo Carlini wrote:
If, more generally, you mean we should remove it completely, I'm afraid
some cases are rather nasty. For example, I think that whenever we go
through implicit_conversion, thus its flags &=, the following function
calls can easily have at the same time
On 06/05/2012 01:23 AM, Jason Merrill wrote:
On 06/04/2012 06:55 PM, Paolo Carlini wrote:
If, more generally, you mean we should remove it completely, I'm afraid
some cases are rather nasty. For example, I think that whenever we go
through implicit_conversion, thus its flags &=, the following fu
On 06/05/2012 01:45 AM, Paolo Carlini wrote:
On 06/05/2012 01:23 AM, Jason Merrill wrote:
On 06/04/2012 06:55 PM, Paolo Carlini wrote:
If, more generally, you mean we should remove it completely, I'm afraid
some cases are rather nasty. For example, I think that whenever we go
through implicit_c
This patch adds three new arguments to validate_failures.py so
it can be used outside the build directory:
--ignore_missing_failures
When a failure is expected in the manifest but it is not found in
the actual results, the script produces a note alerting to this
fact. This means that t
On Mon, Jun 4, 2012 at 5:51 PM, Michael Meissner
wrote:
> This patch fixes PR 53487, so that -misel will no longer cause an unknown insn
> error. Andrew Pinksi's changes on May 4th, 2012, changed to use the
> movcc pattern instead of the cstore4 in some cases, when a target
> machine defines both
1 - 100 of 114 matches
Mail list logo
