To Dodji Seketeli:
Thanks, I will republish my libcpp patch later.
2012/6/4 Dodji Seketeli :
> 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 pl
This patch to libgo includes the TLS size in the requested stack size of
a new thread, if possible. This relies on the glibc-specific (and
undocumented) _dl_get_tls_static_info call. This is particularly
necessary when using glibc, because glibc removes the static TLS size
from the requested stac
On Sun, 3 Jun 2012, Tom G. Christensen wrote:
> Latest results for 4.7.x
Thanks, Tom!
Gerald
Recently the version of in glibc changed to pick up
some anonymous unions:
http://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/unix/sysv/linux/bits/resource.h;h=62cb257410cb294799eddf83602fdd8de30f772f;hp=be852e52472e8f3cd721cc0201a275fcbea89558;hb=5e1a27a96de16ad0cd67a81e25741790b32e2c25
On Jun 4, 2012, at 7:46 PM, Mike Stump wrote:
> g++.dg/other/warning1.C -std=c++11 (test for warnings, line 10)
> g++.dg/other/warning1.C -std=c++11 (test for warnings, line 11)
> g++.dg/other/warning1.C -std=c++11 (test for excess errors)
> g++.dg/other/warning1.C -std=c++98 (test for warnings,
Continuing fixes in the series... I'll add () where they influence the
semantics of what is tested. I'll see about removing them when they are
unnecessary because the underlying issue is fixed.
Index: testsuite/g++.dg/cpp0x/regress/template-function1.C
=
`/home/sandeep/gimple_build/gcc'
Here is the changeLog.in testsuite/ChangeLog.gimplefe
2012-06-05 Sandeep Soni
*gimple.dg/20120604-1.gimple : New.
*gimple.dg/20120604-2.gimple : New.
*gimple.dg/20120605-1.gimple: New.
*gimple.dg/20120605-2.gimple: New.
In fixing a testsuite driver issue, I discovered that some test cases don't
match the actual output of the compiler. I'll check in the obvious fixes, I
believe the below is one such obvious fix. If people want to argue the
compiler should instead be changed to match the testcase, let me know.
On Jun 4, 2012, at 2:34 PM, Jason Merrill wrote:
> 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.
>
On 06/04/2012 08:22 PM, Paolo Carlini wrote:
In fact, I think setting complain to tf_warning may work better.
Sounds plausible.
Jason
New patch attached.
About using mangled name, I'm afraid this will make the command line
too long for C++. And also, using bfd_name makes it easier to specify
the pattern for common names. E.g. many class many have Log functions,
but they are all likely to be cold. Using bfd_name, we only need to
Hi Dodji,
On Mon, 4 Jun 2012, Dodji Seketeli wrote:
Hello Dimitrios,
I cannot approve or deny your patch, but I have one question.
Who should I CC then? I saw that you have commits in that file.
I am wondering why this change implies better performance.
Is this because when we later want
On Fri, Jun 1, 2012 at 11:57 AM, Edmar wrote:
> Freescale would like to contribute these patches to gcc.
>
> It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
> description, and set proper default flags for the e5500 and e6500 cores.
>
> Some Altivec extensions for e6500 wil
On 06/04/2012 04:32 PM, Paolo Carlini wrote:
Remember that all the libstdc++-v3 patches should also go to
libstd...@gcc.gnu.org.
This isn't really a libstdc++ patch - it's actually a patch against
top-level configure.ac that doesn't touch the libstdc++-v3 subdirectory.
But if I should still cr
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
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 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
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/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 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 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
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
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
===
-
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/
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 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
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
>
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 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
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 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 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
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 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
>>> - 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 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
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)
+ ;
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
(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
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
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 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
> "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 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.
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 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 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 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 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 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. *
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 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
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 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
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/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,
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 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
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 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
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 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 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
OK.
Jason
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
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
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
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~
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 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
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
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
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;
>>
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
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
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
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
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 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
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
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
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
=
Please add a comment explaining why flag_generate_lto matters there. OK
with that change.
Jason
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
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
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,
> > - 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
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
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 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.
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 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, 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 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.
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
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
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
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 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 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.
1 - 100 of 114 matches
Mail list logo
