On 01.04.2013 12:38, Andrey Belevantsev wrote:
On 22.02.2013 17:30, Andrey Belevantsev wrote:
Hello,
As found by Jakub and explained in the PR audit trail by Alexander, this
patch fixes the selective scheduler merge glitch of 2008 that added the
unnecessary JUMP_P check to the flush_pending_lis
On Fri, Apr 5, 2013 at 10:37 AM, Jakub Jelinek wrote:
> On Thu, Apr 04, 2013 at 09:53:30PM +0200, Bernhard Reutner-Fischer wrote:
>> uClibc can be built without Largefile support, add the corresponding
>> guards. uClibc does not have __libc_malloc()/__libc_free(), add guard.
>
> Ugh, this is very
On Thu, Apr 04, 2013 at 09:53:30PM +0200, Bernhard Reutner-Fischer wrote:
> uClibc can be built without Largefile support, add the corresponding
> guards. uClibc does not have __libc_malloc()/__libc_free(), add guard.
Ugh, this is very ugly. In addition to the stuff mentioned by Konstantin
that t
[resending in plain text]
On Fri, Apr 5, 2013 at 10:24 AM, Konstantin Serebryany
wrote:
> Hi Bernhard,
>
> The libsanitizer code is the exact copy of some revision of the upstream
> code in LLVM repo.
> libsanitizer/README.gcc:
> Trivial and urgent fixes (portability, build fixes, etc.) may go
This patch updates the gcc docs on programming language standards to
mention the Go 1 standard. Bootstrapped on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.
Ian
2013-04-04 Ian Lance Taylor
* doc/standards.texi (Standards): The Go frontend supports the Go
1
From: Zhouyi Zhou
Sender: Zhouyi Zhou
To:
Subject: [PATCH] inline fail reporting: reporting inline fail caused by
overwritable function
When inline failed because of callee is overwritable, gcc will not report it
in dump file as other inline failing cases do. This patch correct this.
Ch
The C++ changes are OK.
Jason
OK, thanks.
Jason
Hi!
Re-visiting this patch/commit after a mere ten years, ha, ha. :-) Surely
everyone must still be having context on this issue... (MIPS and soft-fp
maintainers CCed.)
On 01 Apr 2003 18:44:53 -0300, Alexandre Oliva wrote:
> Index: gcc/ChangeLog
> from Alexandre Oliva
>
> * real.h (E
Hi,
Current Makefile.in does not match Makefile.def. Regenerate it by
"autogen Makefile.def".
Tested the patched google/gcc-4_8 with crosstool-validate.py
--testers=crosstool.
OK for google/gcc-4_8?
Thanks,
Jing
Index: Makefile.in
Hi Balaji.
This is a patch against, the [cilkplus] branch (not the [cilkplus-merge]
branch). I have taken the liberty to start cleaning up the <#pragma
simd> stuff on your development branch, while the array notation
patchset is being reviewed by Joseph.
Herein lies a potpourri of fixes, re
Hi,
in the audit trail of c++/56815 Manuel noticed that, inconsistently with
the documentation, a LangEnabledBy was missing for -Wpointer-arith vs
-Wpedantic.
Then I noticed that a clean up was possible in the actual pedwarn calls,
which, in fact, also fixes a bug: we don't want to actually
On Mon, Apr 1, 2013 at 2:27 PM, Rong Xu wrote:
>
>
>
> On Fri, Mar 29, 2013 at 1:06 PM, Teresa Johnson
> wrote:
>>
>> On Fri, Mar 29, 2013 at 11:16 AM, Jan Hubicka wrote:
>> > Hi,
>> > currently we use Theresa's code to determine hot/cold decisions based on
>> > counter.
>> > Histogram of gcov c
This is a minor nit on the C++ reference qualifiers.
Obviously, ref quals are not a sequence.
Adding multiple ref quals did error out but this patch cleans up the
error from a few unexpected tokens to one root cause.
Also _seq is removed from te cp_parser function name.
builds and passes all te
On Thu, Apr 4, 2013 at 12:53 PM, Bernhard Reutner-Fischer
wrote:
>
> 2013-03-24 Bernhard Reutner-Fischer
>
> * configure.ac (libgcc_cv_dfp): Extend check to probe fenv.h
> availability.
> * configure: Regenerate
This is OK.
Thanks.
Ian
Except as noted below, fine by me.
On 04/04/13 12:56, Bernhard Reutner-Fischer wrote:
> Bootstrapped and regtested on x86_64-unknown-linux-gnu and
> x86_64-mine-linux-uclibc without regressions, ok for trunk?
>
> fixincludes/ChangeLog:
>
> 2013-04-04 Bernhard Reutner-Fischer
>
> Makefi
On Thu, Apr 4, 2013 at 2:53 PM, Bernhard Reutner-Fischer
wrote:
> POSIX.1-2008 (SUSv4) marks tmpnam() as obsolescent. As such it is not
> available in uClibc unless SUSv4 legacy stuff is enabled.
>
> libstdc++-v3/ChangeLog
>
> 2013-03-24 Bernhard Reutner-Fischer
>
> * include/c_global/c
On 04/04/2013 01:49 PM, Steven Bosscher wrote:
Hello,
Just some things I've had in my tree for a while now, ChangeLog says it all:
* bb-reorder.c (fix_crossing_unconditional_branches): Remove a
set-but-unused variable.
* cgraph.c (cgraph_release_function_body): Clear
Bootstrapped and regtested on x86_64-unknown-linux-gnu and
x86_64-mine-linux-uclibc without regressions, ok for trunk?
fixincludes/ChangeLog:
2013-04-04 Bernhard Reutner-Fischer
Makefile.in: Use $(FI) instead of fixincl@EXEEXT@.
Cleanup whitespace while at it.
Signed-off-by:
uClibc can be built without Largefile support, add the corresponding
guards. uClibc does not have __libc_malloc()/__libc_free(), add guard.
libsanitizer/ChangeLog
2013-03-24 Bernhard Reutner-Fischer
* sanitizer_common/sanitizer_allocator.cc (libc_malloc,
libc_free): Guard with
POSIX.1-2008 (SUSv4) marks tmpnam() as obsolescent. As such it is not
available in uClibc unless SUSv4 legacy stuff is enabled.
libstdc++-v3/ChangeLog
2013-03-24 Bernhard Reutner-Fischer
* include/c_global/cstdio: On uClibc guard ::tmpnam with SUSv4
legacy availability.
Signe
uClibc can be built without fenv support, extend the configure check for
decimal floating point to probe the existance of fenv.h, too.
libgcc/ChangeLog:
2013-03-24 Bernhard Reutner-Fischer
* configure.ac (libgcc_cv_dfp): Extend check to probe fenv.h
availability.
* con
Hi,
The following patches were bootstrapped and regtested on
x86_64-unknown-linux-gnu without new regressions.
They fix a few problems i faced when building against uClibc.
Ok for trunk and, in a week or two, the 4.8 branch?
PS:
I would like to ask the libstdc++ folks to advise on the tmpnam pa
Hello,
Just some things I've had in my tree for a while now, ChangeLog says it all:
* bb-reorder.c (fix_crossing_unconditional_branches): Remove a
set-but-unused variable.
* cgraph.c (cgraph_release_function_body): Clear cfun->cfg to make
basic blocks of released
On Thu, Apr 04, 2013 at 08:37:47PM +0200, Richard Biener wrote:
> Can you factor out a function that returns
> A proper qimode value if possible or null and
> Use it in both places?
Like this?
2013-04-04 Jakub Jelinek
* tree-loop-distribution.c (const_with_all_bytes_same): New functio
On Apr 4, 2013, at 10:26 AM, Robert Dewar wrote:
> I must say though that Apple choosing to use CR only was simply
> perverse :-)
Apple uses the posix standard for line endings, just like unix. :-P
Jakub Jelinek wrote:
>Hi!
>
>As discussed on IRC, this patch allows as to recognize more patterns as
>memset, see the testcase for what it can do.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Can you factor out a function that returns
A proper qimode value if possible
Hi!
As discussed on IRC, this patch allows as to recognize more patterns as
memset, see the testcase for what it can do.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-04-04 Jakub Jelinek
* tree-loop-distribution.c (generate_memset_builtin): Only handle
Hi!
The vt3.C testcase (from PR34949) ICEd, because sink_clobbers sunk a
MEM_REF[SSA_NAME] clobber from a landing pad which that SSA_NAME definition
dominated to an outer one which wasn't dominated by the definition.
As the ehcleanup nor ehdisp passes keep dominance info current and perform
change
On 2013-04-04 13:47 , Jing Yu wrote:
I found that google/gcc-4_8 has the same problem. OK for google/gcc-4_8?
Yes. Thanks.
Diego.
On 4/4/2013 1:14 PM, Janus Weil wrote:
As my editor shows, that file uses DOS line endings (\r\n) in some lines and
UNIX ones (\n) in others. In principle, I am for keeping such files to test the
parser.
If one keeps them, please put them into a file that tests for that feature
exclusively,
>> As my editor shows, that file uses DOS line endings (\r\n) in some lines and
>> UNIX ones (\n) in others. In principle, I am for keeping such files to test
>> the parser.
>
> If one keeps them, please put them into a file that tests for that feature
> exclusively, as we often find turds, oops
Hello,
This patch removes a dbr_schedule() call from the sparc back end, and
plugs in a sparc-specific pass that needs the insn chain in
delayed-branch scheduled form after pass_delay_slots. This is
essentially the same patch as the one I posted yesterday
(http://gcc.gnu.org/ml/gcc-patches/2013-04
On Apr 4, 2013, at 1:07 AM, Tobias Burnus wrote:
> As my editor shows, that file uses DOS line endings (\r\n) in some lines and
> UNIX ones (\n) in others. In principle, I am for keeping such files to test
> the parser.
If one keeps them, please put them into a file that tests for that feature
On 04/04/13 14:16, Jakub Jelinek wrote:
On Thu, Apr 04, 2013 at 02:11:39PM +0100, Ramana Radhakrishnan wrote:
This backports the fix for PR48308 something that's slipped through
the cracks. I wrote the backport and then noticed that Mikael had a
similar solution - the only difference being arou
On Apr 2, 2013, at 1:55 AM, Eric Botcazou wrote:
> The question is: do we really need to canonicalize everything?
> The fear (at least mine) is that, by canonicalizing everything, you will make
> changes behind the back of back-ends that could disable some of their
> patterns
> silently.
My t
On Thu, Apr 04, 2013 at 10:42:47AM +0200, Richard Biener wrote:
> I originally thought of using namespaces to fend off pass-specific globals,
> but eventually moving it all to a pass specific class would work, too.
>
> Note that there are some passes that have global data that is allocated
> and i
On Thu, 4 Apr 2013, Jack Howarth wrote:
> On Wed, Apr 03, 2013 at 03:23:36PM +0200, Richard Biener wrote:
> >
> > Status
> > ==
> >
> > The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
> > which I will do tomorrow if no serious issue shows up until then.
> > The branch is fro
On Wed, Apr 03, 2013 at 03:23:36PM +0200, Richard Biener wrote:
>
> Status
> ==
>
> The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
> which I will do tomorrow if no serious issue shows up until then.
> The branch is frozen now, all changes require release manager approval
> u
On Thu, 2013-04-04 at 10:42 +0200, Richard Biener wrote:
Thanks for looking at this; comments inline throughout.
> On Wed, Apr 3, 2013 at 6:13 PM, David Malcolm wrote:
> > I'm working on my first gcc contribution, but it's a large patch, and I
> > wanted to sound things out on this list.
> >
> >
On Thu, Apr 04, 2013 at 04:29:34PM +0200, Marek Polacek wrote:
> On Thu, Apr 04, 2013 at 04:20:36PM +0200, Marek Polacek wrote:
> > On Thu, Apr 04, 2013 at 04:06:35PM +0200, Jakub Jelinek wrote:
> > > In this second hunk the division is done only for flag_guess_branch_prob,
> > > so shouldn't it be
On Thu, Apr 04, 2013 at 04:20:36PM +0200, Marek Polacek wrote:
> On Thu, Apr 04, 2013 at 04:06:35PM +0200, Jakub Jelinek wrote:
> > In this second hunk the division is done only for flag_guess_branch_prob,
> > so shouldn't it be
> > if (flag_guess_branch_prob)
> > {
> > if (PARAM_VALUE
On Thu, 4 Apr 2013, Richard Biener wrote:
>
> This fixes the testcase in PR56826, the underlying issue being
> that a SLP group load with a gap is detected as supported while
> it is not because we compute ncopies incorrectly. The following
> patch makes us compute ncopies more correctly.
Which
On Thu, Apr 04, 2013 at 04:06:35PM +0200, Jakub Jelinek wrote:
> In this second hunk the division is done only for flag_guess_branch_prob,
> so shouldn't it be
> if (flag_guess_branch_prob)
> {
> if (PARAM_VALUE (HOT_BB_FREQUENCY_FRACTION) == 0
> || edge->frequency <= (CGRAPH_FR
On Thu, Apr 4, 2013 at 3:33 PM, Yuri Rumyantsev wrote:
> Hi Richard,
>
> You slightly change behavior of find_base_term, namely before your fix we
> have the following code:
>
> if (REG_P (tmp1) && REG_POINTER (tmp1))
> {
>rtx base = find_base_term (tmp1);
>if (base)
> return base;
>
Hi Richard,
You slightly change behavior of find_base_term, namely before your fix
we have the following code:
if (REG_P (tmp1) && REG_POINTER (tmp1))
{
rtx base = find_base_term (tmp1);
if (base)
return base;
}
but in your fix you added the following checks on base:
tmp1 = find_ba
On Thu, Apr 04, 2013 at 04:00:48PM +0200, Marek Polacek wrote:
> --- gcc/predict.c.mp 2013-04-04 15:04:29.925685185 +0200
> +++ gcc/predict.c 2013-04-04 15:04:33.123696281 +0200
> @@ -122,6 +122,8 @@ maybe_hot_frequency_p (struct function *
>if (node->frequency == NODE_FREQUENCY_EXECUTED_O
This fixes an ICE in case we use weirdo --param value for
PARAM_ALIGN_THRESHOLD. The patch is by Andrew; I added CL, testcase
and tested.
Bootstrapped/regtested on x86_64-linux, ok for trunk? And what about other
branches?
2013-04-04 Marek Polacek
Andrew Pinski
PR tre
Another case where we got a SIGFPE if HOT_BB_FREQUENCY_FRACTION
is 0 - in that case we divide by zero.
Regtested/bootstrapped on x86_64-linux, ok for trunk/4.8?
2013-04-04 Marek Polacek
PR tree-optimization/48186
* predict.c (maybe_hot_frequency_p): Return false if
HOT
On Thu, Apr 04, 2013 at 02:11:39PM +0100, Ramana Radhakrishnan wrote:
>
> This backports the fix for PR48308 something that's slipped through
> the cracks. I wrote the backport and then noticed that Mikael had a
> similar solution - the only difference being around this guarded for
> HAVE_cc0 targ
Hi,
This backports the fix for PR48308 something that's slipped through the
cracks. I wrote the backport and then noticed that Mikael had a similar
solution - the only difference being around this guarded for HAVE_cc0
targets.
Tested cross arm-none-linux-gnueabi - no regressions.
Bootstrapp
~/src/qemu/qemu-git/arm-linux-user/qemu-arm -cpu cortex-a9 -R 0 -L
/home/lyon/src/GCC/builds/gcc-fsf-asan-arm-none-linux-gnueabihf/sysroot
./heap-overflow-1.arm
On 28 March 2013 15:33, Christophe Lyon wrote:
>>> - libsanitizer detects if its output is a tty, and when GCC testsuite
>>> is execute
On 04/04/13 11:55, Kyrylo Tkachov wrote:
Hi all,
Can I backport the patch at
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00652.html
to 4.8?
It fixes PR 56720 on arm-*-* targets.
The trunk commits for this are r197040 and r197041.
It applies cleanly to 4.8 and regtests cleanly on arm-none-eab
OK /Marcus
On 3 April 2013 14:35, Tejas Belagod wrote:
> Hi,
>
> The attached patch fixes duplication in a test case for gcc.target/aarch64/.
>
> Tested on aarch64-none-elf. OK for trunk and branch?
>
> Thanks,
> Tejas Belagod
> ARM.
>
> 2013-04-03 Tejas Belagod
>
> testsuite/
> * gcc.
On Thu, Apr 4, 2013 at 12:11 PM, Marc Glisse wrote:
> On Thu, 4 Apr 2013, Richard Biener wrote:
>
>> On Thu, Apr 4, 2013 at 10:53 AM, Marc Glisse wrote:
>>>
>>> On Thu, 4 Apr 2013, Richard Biener wrote:
>>>
>>> + if ((handled_component_p (arg0) || TREE_CODE (arg0) ==
>>> MEM_REF)
>>>
This fixes the testcase in PR56826, the underlying issue being
that a SLP group load with a gap is detected as supported while
it is not because we compute ncopies incorrectly. The following
patch makes us compute ncopies more correctly.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
There is no longer a good reason to restrict the memory references
we perform strided loads on during vectorization. In particular
a bug(?) in the current restriction makes it not apply for
array loads from decls (as opposed to array loads from pointers
which happens for fortran or VLA pointer lo
Hi all,
Can I backport the patch at
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00652.html
to 4.8?
It fixes PR 56720 on arm-*-* targets.
The trunk commits for this are r197040 and r197041.
It applies cleanly to 4.8 and regtests cleanly on arm-none-eabi.
Thanks,
Kyrill
This fixes PR56837, memset recognition should verify that constants
really cover all of their representation. Esp. all-ones ones.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-04-04 Richard Biener
PR tree-optimization/56837
* tree-loop-distribu
On Thu, 4 Apr 2013, Ramana Radhakrishnan wrote:
> On 04/04/13 08:46, Richard Biener wrote:
> > On Wed, 3 Apr 2013, Matthew Gretton-Dann wrote:
> >
> > > Would it be possible for this patch and the others Kyrylo has recently
> > > done
> > > for the new ARMv8 AArch32 instructions to be backported
I'm about to backport one patch (a fix for PR48189) to 4.6 branch.
Bootstrapped/regtested on x86_64-linux, acked by Jakub on IRC.
Will commit soon.
ChangeLog:
2013-04-04 Marek Polacek
Backported from mainline
2013-01-09 Steven Bosscher
Jakub Jelinek
Le 04/04/2013 00:56, Tobias Burnus a écrit :
> Am 04.04.2013 00:27, schrieb Mikael Morin:
>> Le 02/04/2013 19:19, Tobias Burnus a écrit :
>>> {
>>> snprintf (message, MSGLEN,
>>> "Read kind %d %s where kind %d is required for item %d",
>>> - dtp->u.p.saved_length,
On Thu, 4 Apr 2013, Richard Biener wrote:
On Thu, Apr 4, 2013 at 10:53 AM, Marc Glisse wrote:
On Thu, 4 Apr 2013, Richard Biener wrote:
+ if ((handled_component_p (arg0) || TREE_CODE (arg0) == MEM_REF)
This check means the optimization is not performed for
BIT_FIELD_REF[a, *, CST] w
On 04/04/13 08:46, Richard Biener wrote:
On Wed, 3 Apr 2013, Matthew Gretton-Dann wrote:
Would it be possible for this patch and the others Kyrylo has recently done
for the new ARMv8 AArch32 instructions to be backported to 4.8?
In particular I'm refering to:
http://gcc.gnu.org/ml/gcc-patches
> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: 04 April 2013 08:46
> To: Matthew Gretton-Dann
> Cc: gcc-patches@gcc.gnu.org; Kyrylo Tkachov; Ramana Radhakrishnan;
> Richard Earnshaw
> Subject: Re: [PATCH][ARM] use vsel instruction for floating point
> conditi
On Thu, Apr 4, 2013 at 10:53 AM, Marc Glisse wrote:
> On Thu, 4 Apr 2013, Richard Biener wrote:
>
> + if ((handled_component_p (arg0) || TREE_CODE (arg0) == MEM_REF)
This check means the optimization is not performed for
BIT_FIELD_REF[a, *, CST] which I see no par
On Wed, Apr 3, 2013 at 6:16 PM, Kenneth Zadeck wrote:
> On 04/03/2013 09:53 AM, Richard Biener wrote:
>>
>> On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck
>> wrote:
>>>
>>> On 04/03/2013 05:17 AM, Richard Biener wrote:
>>>
In the end you will have a variable-size storage in TREE_INT_CST thus
Hi,
On 04/04/2013 10:56 AM, Jonathan Wakely wrote:
On 3 April 2013 12:59, Paolo Carlini wrote:
On 04/03/2013 01:53 PM, Jonathan Wakely wrote:
On 3 April 2013 12:45, Paolo Carlini wrote:
On 04/03/2013 02:09 AM, Jonathan Wakely wrote:
This patch implements
http://www.open-std.org/jtc1/sc22/wg2
On 3 April 2013 12:59, Paolo Carlini wrote:
> On 04/03/2013 01:53 PM, Jonathan Wakely wrote:
>>
>> On 3 April 2013 12:45, Paolo Carlini wrote:
>>>
>>> On 04/03/2013 02:09 AM, Jonathan Wakely wrote:
This patch implements
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.ht
On Thu, 4 Apr 2013, Richard Biener wrote:
+ if ((handled_component_p (arg0) || TREE_CODE (arg0) == MEM_REF)
This check means the optimization is not performed for
BIT_FIELD_REF[a, *, CST] which I see no particularly good reason for.
Er, are you trying to get rid of all BIT_FIELD_REFs?
On Wed, Apr 3, 2013 at 6:13 PM, David Malcolm wrote:
> I'm working on my first gcc contribution, but it's a large patch, and I
> wanted to sound things out on this list.
>
> I want to eliminate/minimize global state within gcc, since I think
> doing so is a key part of making gcc more modular.
>
>
On Thu, Apr 4, 2013 at 9:23 AM, Marc Glisse wrote:
> On Wed, 3 Apr 2013, Richard Biener wrote:
>
>> On Wed, Apr 3, 2013 at 4:15 PM, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> I am not 100% convinced that it is always better to fold to a MEM_REF,
>>> but
>>> that's what the PR asks for.
>>>
>>> boo
Janus Weil wrote:
Ok, here is the follow-up patch, which removes the warning on
(alternate) RETURN statements, in order to avoid double diagnostics.
(In altreturn_5.f90 there apparently were some superfluous control
characters, which were removed by my editor.)
As my editor shows, that file us
On Wed, 3 Apr 2013, Matthew Gretton-Dann wrote:
> Would it be possible for this patch and the others Kyrylo has recently done
> for the new ARMv8 AArch32 instructions to be backported to 4.8?
>
> In particular I'm refering to:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00994.html (trunk r1
On Wed, 3 Apr 2013, Richard Biener wrote:
On Wed, Apr 3, 2013 at 4:15 PM, Marc Glisse wrote:
Hello,
I am not 100% convinced that it is always better to fold to a MEM_REF, but
that's what the PR asks for.
bootstrap+testsuite on x86_64-linux-gnu.
2013-04-03 Marc Glisse
PR middle-e
75 matches
Mail list logo
