On Wed, 6 Mar 2013, Jan Hubicka wrote:
This removes all encouragement to use -fwhole-program with -flto
from the documentation. As can be seen in PR56533 it can be
most confusing ... instead advise to rely on a linker plugin.
Ok?
Seems resomable thing to do. However I guess a
We would like to get the 4.7 patch applied so arm-rtems is not obsolete.
If there are any hints of a plan to release another 4.6 version, we would
like to apply a patch to that branch to switch from arm-elf to arm-eabi
as our foundation.
Please adjust the ChangeLog entry on the branches,
On Thu, Mar 7, 2013 at 12:04 AM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
This patch fixes a bunch of smaller issues with GATHER_STATISTICS for
bitmaps: overflows in counters and ugly output format.
Bootstrapped (with and without GATHER_STATISTICS) and regtested on
Committed.
Andreas.
* gcc.dg/pr31490.c: Fix last change.
diff --git a/gcc/testsuite/gcc.dg/pr31490.c b/gcc/testsuite/gcc.dg/pr31490.c
index 396ec26..37731b3 100644
--- a/gcc/testsuite/gcc.dg/pr31490.c
+++ b/gcc/testsuite/gcc.dg/pr31490.c
@@ -7,4 +7,4 @@ __extension__ typedef
Hi,
this patch fixes PR 48618.
Built and regtested on Linux 3.2.0-4-686-pae.
Thanks for input and corrections to Tobias Burnus.
Regards,
Tilodiff --git a/gcc/testsuite/gfortran.dg/open_negative_unit_1.f90 b/gcc/testsuite/gfortran.dg/open_negative_unit_1.f90
new file mode 100644
Hi!
AFAIK aarch64 libraries are supposed to go into /usr/lib64 etc.
directories similarly to x86-64 etc., but as aarch64 isn't a true
multilib target (having two different backends for 32-bit vs. 64-bit code),
currently gcc -print-multi-os-directory prints . instead of ../lib64.
The following
Hi,
Tilo Schwarz wrote:
this patch fixes PR 48618.
Built and regtested on Linux 3.2.0-4-686-pae.
Thanks for the patch, which mostly looks okay.
A few remarks:
* Do not create a diff of the ChangeLog but include it separately at the
top of the patch. Reason: It's easier to read and if
This hacky patch tracks per-pass heap usage with -fmem-report
using glibc malloc hooks (which are deprecated!? eh ... I can
see no replacement?)
Still somewhat broken accounting for the overall numbers
(and peak memory use, that is).
But it's a start. And it uses internal glibc allocator
On Thu, Mar 07, 2013 at 01:59:31PM +0100, Richard Biener wrote:
This hacky patch tracks per-pass heap usage with -fmem-report
using glibc malloc hooks (which are deprecated!? eh ... I can
see no replacement?)
The replacement is that we should intercept the malloc calls
instead (as those
On Thu, 7 Mar 2013, Marek Polacek wrote:
On Thu, Mar 07, 2013 at 01:59:31PM +0100, Richard Biener wrote:
This hacky patch tracks per-pass heap usage with -fmem-report
using glibc malloc hooks (which are deprecated!? eh ... I can
see no replacement?)
The replacement is that we
Hi!
During zero_one_operation I believe we can count in the chain having single
uses if we go through rhs1s, but the change from last year also added
looking through rhs2, and there I don't see anything that would guarantee
a single use, and the following testcase shows where it has two uses.
If
On Tue, Mar 05, 2013 at 10:07:50AM +0100, Marek Polacek wrote:
+ if (compare_count.scmp (double_int_zero) == -1)
+compare_count = double_int_zero;
+ if (loop_count.scmp (double_int_zero) == -1)
+loop_count = double_int_zero;
Use if (compare_count.is_negative ()) etc.
On Thu, 7 Mar 2013, Jakub Jelinek wrote:
Hi!
During zero_one_operation I believe we can count in the chain having single
uses if we go through rhs1s, but the change from last year also added
looking through rhs2, and there I don't see anything that would guarantee
a single use, and the
On Wed, Nov 14, 2012 at 02:22:33PM -0800, Andrew Pinski wrote:
commit 8ca1e58de404bbe82b93bc240ef28c68c681243d
Author: Andrew Pinski apin...@cavium.com
Date: Thu Jul 26 18:09:34 2012 -0700
2012-07-26 Andrew Pinski apin...@cavium.com
Bug #3261
* config/mips/mips.md
Hi!
It is again roughly the season of the year where baselines should be
updated. These are for the architectures I built gcc on recently.
Ok for trunk?
2013-03-07 Jakub Jelinek ja...@redhat.com
* config/abi/post/i386-linux-gnu/baseline_symbols.txt: Update.
*
On 3/7/2013 3:50 AM, Eric Botcazou wrote:
We would like to get the 4.7 patch applied so arm-rtems is not obsolete.
If there are any hints of a plan to release another 4.6 version, we would
like to apply a patch to that branch to switch from arm-elf to arm-eabi
as our foundation.
Please adjust
On 7 March 2013 15:17, Jakub Jelinek wrote:
Hi!
It is again roughly the season of the year where baselines should be
updated. These are for the architectures I built gcc on recently.
Ok for trunk?
Looks correct to me, thanks for doing this. OK for trunk.
We need to avoid line-jumps due to TER, like we do for -O0.
This also adjust things to match the 4.8 changes for location
encodings (and the older PHI argument locations).
Bootstrap regtest pending on x86_64-unknown-linux-gnu.
Does this look ok?
Thanks,
Richard.
2013-03-07 Richard Biener
On Thu, Mar 7, 2013 at 7:12 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Nov 14, 2012 at 02:22:33PM -0800, Andrew Pinski wrote:
commit 8ca1e58de404bbe82b93bc240ef28c68c681243d
Author: Andrew Pinski apin...@cavium.com
Date: Thu Jul 26 18:09:34 2012 -0700
2012-07-26 Andrew Pinski
On Thu, Mar 07, 2013 at 04:52:15PM +0100, Richard Biener wrote:
2013-03-07 Richard Biener rguent...@suse.de
* tree-ssa-ter.c (is_replaceable_p): Do not TER across location
or block changes with -Og. Fix for location / block encoding
changes and PHI arguments with
On Thu, Mar 7, 2013 at 3:15 AM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
AFAIK aarch64 libraries are supposed to go into /usr/lib64 etc.
directories similarly to x86-64 etc., but as aarch64 isn't a true
multilib target (having two different backends for 32-bit vs. 64-bit code),
currently
On Thu, 07 Mar 2013 12:46:10 +0100, Tobias Burnus bur...@net-b.de wrote:
Hi,
Tilo Schwarz wrote:
this patch fixes PR 48618.
Built and regtested on Linux 3.2.0-4-686-pae.
Thanks for the patch, which mostly looks okay.
A few remarks:
Thank you for the feedback.
I incorporated all remarks
On 03/06/2013 04:28 PM, Jakub Jelinek wrote:
On Wed, Mar 06, 2013 at 03:00:49PM -0700, Jeff Law wrote:
Doesn't the code in update_accumulator_with_ops need the same
change?
No, the difference is that it uses false as the next to last argument,
i.e. inserts after gsi, in which case
On Thu, Mar 07, 2013 at 08:29:06AM -0800, Andrew Pinski wrote:
On Thu, Mar 7, 2013 at 3:15 AM, Jakub Jelinek ja...@redhat.com wrote:
AFAIK aarch64 libraries are supposed to go into /usr/lib64 etc.
directories similarly to x86-64 etc., but as aarch64 isn't a true
multilib target (having two
PING this, or any of my other revisions :)
On 02/27/13 10:43, Aldy Hernandez wrote:
On 02/26/13 12:24, Richard Henderson wrote:
On 02/25/2013 02:52 PM, Aldy Hernandez wrote:
I think it's best to do this here at tmmark time, instead of at IPA-tm.
Don't we have problems when ipa inlining
On Thu, Mar 7, 2013 at 1:59 PM, Richard Biener wrote:
Index: gcc/toplev.c
===
*** gcc/toplev.c(revision 196517)
--- gcc/toplev.c(working copy)
*** along with GCC; see the file COPYING3.
*** 74,79
Hi,
one small nit for mingw targets without gnu-style printf-formatter.
ChangeLog
2013-03-07 Kai Tietz kti...@redhat.com
* c-c++-common/pr54486.c: Skip test for mingw-targets.
Ok for apply?
Regards,
Kai
Index: c-c++-common/pr54486.c
On Wed, 6 Mar 2013, Jan Hubicka wrote:
This removes all encouragement to use -fwhole-program with -flto
from the documentation. As can be seen in PR56533 it can be
most confusing ... instead advise to rely on a linker plugin.
Ok?
Seems resomable thing to do. However I
Hi,
this patch fixes some testsuite-failures on mingw targets.
ChangeLog
2013-03-07 Kai Tietz kti...@redhat.com
* gcc.target/i386/movti.c: Adjust for x64 mingw.
* gcc.target/i386/pr20020-1.c: Skip for x64 mingw target.
* gcc.target/i386/pr20020-2.c: Likewise.
Hi,
this patch fixes some remaining issue for mingw-targets in gcc.dg's testsuite.
ChangeLog
2013-03-07 Kai Tietz kti...@redhat.com
* gcc.dg/pr14092-1.c: Mark intptr_t typedef to use extension.
* gcc.dg/pr24683.c: Avoid warning about casting constant string.
*
On 03/07/2013 11:16 AM, Kai Tietz wrote:
Hi,
one small nit for mingw targets without gnu-style printf-formatter.
ChangeLog
2013-03-07 Kai Tietz kti...@redhat.com
* c-c++-common/pr54486.c: Skip test for mingw-targets.
Ok for apply?
OK. Only because it's the testsuite and not a
On 03/07/2013 11:34 AM, Kai Tietz wrote:
Hi,
this patch fixes some remaining issue for mingw-targets in gcc.dg's testsuite.
ChangeLog
2013-03-07 Kai Tietz kti...@redhat.com
* gcc.dg/pr14092-1.c: Mark intptr_t typedef to use extension.
* gcc.dg/pr24683.c: Avoid warning about
Hi,
this patch fixes PR 51825.
Built and regtested on Linux 3.2.0-4-686-pae.
(Dear Jerry, this is my patch you wanted to look at, but improved with
test cases and Changelog. Please consider looking at this version instead
of the old version. Thank you!)
Regards,
Tilo2013-03-07
Hi
While working on unordered containers C++11 allocator integration I
used forward_list tests you have done Jon. It reported some problems
that should have been seen on forward_list or vector allocator tests too
if those tests were indeed manipulating memory. But there weren't
because
On 7 March 2013 21:28, François Dumont wrote:
Hi
While working on unordered containers C++11 allocator integration I used
forward_list tests you have done Jon. It reported some problems that should
have been seen on forward_list or vector allocator tests too if those tests
were indeed
On 21/02/2013 19:35, Anthony Green wrote:
This patch looks fine, thanks. I don't plan to merge back into GCC
for at least a week or two, so I think you should commit it to the GCC
tree independently.
Committed to GCC revision 196527. Thanks!
cheers,
DaveK
On 7 March 2013 22:21, Jonathan Wakely wrote:
On 7 March 2013 21:28, François Dumont wrote:
Hi
While working on unordered containers C++11 allocator integration I used
forward_list tests you have done Jon. It reported some problems that should
have been seen on forward_list or vector
This assert in save_optabs_if_changed triggered for gcc.dg/pr43564.c
on mips64-linux-gnu (-mabi=32/-mips16):
/* ?? If this fails, we should temporarily restore the default
target first (set_cfun (NULL) ??), do the rest of this function,
and then restore it. */
gcc_assert
On Thu, Mar 07, 2013 at 10:51:14PM +, Richard Sandiford wrote:
void
-save_optabs_if_changed (tree fndecl)
+init_tree_optimization_optabs (tree optnode)
{
- /* ?? If this fails, we should temporarily restore the default
- target first (set_cfun (NULL) ??), do the rest of this
Ping?
-- Caroline Tice
cmt...@google.com
On Mon, Feb 25, 2013 at 11:24 AM, Caroline Tice cmt...@google.com wrote:
Here are the latest changes to the vtable pointer verification patches
(again there are 3 patches: c++ front end, main gcc, and c++ runtime
library). I think these address all
Ping?
-- Caroline
cmt...@google.com
On Mon, Feb 25, 2013 at 11:27 AM, Caroline Tice cmt...@google.com wrote:
Here are the latest changes to the vtable pointer verification patches
(again there are 3 patches: c++ front end, main gcc, and c++ runtime
library). I think these address all the
On 7 March 2013 23:53, Caroline Tice wrote:
Hello,
I believe this patch addresses all of your comments; I modified the
configure.ac files to generate the configures, and I fixed the
spelling mistakes in the comments. I still get the warnings when
generating the Makefile.in files from the
Hi,
I committed this simple patch to check for sandybridge processors
when cpuid model number is 0x2d. This is the model for SandyBridge-E
processors :
http://software.intel.com/en-us/articles/intel-architecture-and-processor-identification-with-cpuid-model-and-family-numbers
Index:
This patch fixes the incorrect dependency in Makefile.in.
Bootstrapped and passed regression test.
Okay for google-4_7 branch?
Thanks,
DehaoIndex:
gcc/Makefile.in
===
--- gcc/Makefile.in (revision 196532)
+++ gcc/Makefile.in
On Wed, Jan 30, 2013 at 5:50 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
This patch like the previous 2 pages combines the decimal and binary floating
point moves, this time for 128-bit floating point.
In doing this patch, I discovered that I left out the code in the previous
45 matches
Mail list logo
