Sorry, Rietveld didn't send out the updated patch along with my mail.
Here it is.
Sharad
2011-06-14 Sharad Singhai
Google Ref 3
* doc/gcov.texi: Document gcov intermediate format.
* gcov.c (get_gcov_file_intermediate_name): New function.
(output_intermedi
On 06/06/2011 07:26 AM, Bernd Schmidt wrote:
Ping^3 for the C6X port. Now with extra patches:
Additional preliminary scheduler tweaks:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02408.html
It is ok for me. Thanks, Bernd.
Allow alternatives in attr "predicable":
http://gcc.gnu.org/ml/gcc-pa
Denis Chertykov schrieb:
2011/6/14 Georg-Johann Lay :
Denis Chertykov schrieb:
2011/6/13 Georg-Johann Lay :
So you think is is pointless/discouraged to give a more realistic
description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead
of BASE_REG_CLASS) resp. REGNO_MODE_CODE_
Hello,
HFS+, the FS on Darwin, is case insensitive. So this patch adjusts
filename_cmp.c to ignore the casing when comparing filenames on Darwin.
This is visible in GDB when trying to break on a file whose name
is, say 'Mixed_Case.adb', but was compiled using 'mixed_case.adb'
as the filename. In
Looks OK to me.
On Tue, Jun 14, 2011 at 2:33 PM, Joel Brobecker wrote:
> Hello,
>
> HFS+, the FS on Darwin, is case insensitive. So this patch adjusts
> filename_cmp.c to ignore the casing when comparing filenames on Darwin.
This is wrong as not all FSs are case insensitive. In fact HFS+ can
be case sensitive t
> This is wrong as not all FSs are case insensitive. In fact HFS+ can
> be case sensitive too. I think you need better check than just
> saying all Darwin is case insensitive. This is just like using
> FAT32 on Linux. In fact I think HAVE_DOS_BASED_FILE_SYSTEM is
> incorrect also for NTFS as i
On Wed, Jun 8, 2011 at 9:49 AM, H.J. Lu wrote:
> Hi,
>
> Target HAVE_INITFINI_ARRAY support was added by:
>
> http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00387.html
>
> Unfortunately, it checks if host supports init_array/fini_array
> sections, not target. It will generate wrong result for cross
I missed the "noexcept" qualifier off this function when I added it recently.
2011-06-14 Jonathan Wakely
* include/bits/ptr_traits.h (pointer_traits::pointer_to): Use
noexcept.
Tested x86_64-linux and committed to trunk
Index: include/bits/ptr_traits.h
> Hi,
>
> the patch below fixes PR 48613 which is an ICE with -O0
> -findirect-inlining. Rather than adding "&& optimize" here and there,
> at this place we can easily see whether there is something to do or
> not by testing ipa_node_params_vector for NULL. And the
> flag-triggering combinations
>It probably should go to the 4.6 branch as well.
H.J. Lu's original patch that splits unaligned load and store was checked in
gcc 4.7
trunk. We found that, splitting unaligned store is beneficial to bdver1,
splitting unaligned
load degrades cfp2006 by 1.3% in geomean on Bulldozer. As a result,
On 06/14/2011 02:29 PM, Georg-Johann Lay wrote:
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01029.html
It does look like a step in the right direction.
> I tested on some handcrafted examples and on the code attached to
> PR46278. The generated code looked very good and so I started
> regressi
On Tue, Jun 14, 2011 at 3:41 PM, Fang, Changpeng wrote:
>>It probably should go to the 4.6 branch as well.
>
> H.J. Lu's original patch that splits unaligned load and store was checked in
> gcc 4.7
> trunk. We found that, splitting unaligned store is beneficial to bdver1,
> splitting unaligned
A similar argument is for software prefetching, which we observed a ~2% benefit
on greyhound (not that much
for Bulldozer). We would also prefer turning on software prefetching at -O3 for
-mtune=generic.
--Changprng
From: H.J. Lu [hjl.to...@gmail.co
Here is one the of follow up patches: support of -before_preparation,
-before, -after, -after_cleanup dump flags.
The default dumping behavior does not change at all, but if any one of
the above flags is specified, the function IR will be dumped into a
file with the corresponding suffix. The enh
This is the second (hopefully the last in the series of dumper
changes) follow-up patch.
It adds a control so that verbosity of the dump can be greatly reduced
(and hopefully simplify gcc developer's life a little). For instance:
-fdump-tree-dce="foo[0-9]$"
to dump IR (and debug trace) only for
Attached the patch.
David
On Tue, Jun 14, 2011 at 4:21 PM, Xinliang David Li wrote:
> This is the second (hopefully the last in the series of dumper
> changes) follow-up patch.
>
> It adds a control so that verbosity of the dump can be greatly reduced
> (and hopefully simplify gcc developer's li
On Tue, Jun 14, 2011 at 4:01 PM, Fang, Changpeng wrote:
> A similar argument is for software prefetching, which we observed a ~2%
> benefit on greyhound (not that much
> for Bulldozer). We would also prefer turning on software prefetching at -O3
> for -mtune=generic.
Sure, we can put everything
>
> So, is it OK to commit this patch to trunk, and H.J's original patch + this
> to 4.6 branch?
>I have no problems on -mtune=Bulldozer. But I object -mtune=generic
>change and did suggest a different approach for -mtune=generic.
What's your suggested approach for -mtune=generic?
My underst
Save the DECL_STRUCT_FUNCTION(...) field of FUNCTION_DECL. This change
factors common functionality with the LTO streamer.
Index: gcc/testsuite/ChangeLog.pph
2011-06-14 Lawrence Crowl
* g++.dg/pph/x1tmplfunc.cc: Replace ICE xfail with an assembly diff
xfail.
Index: gcc/cp/Ch
On Tue, Jun 14, 2011 at 4:59 PM, Fang, Changpeng wrote:
>
>
>>
>> So, is it OK to commit this patch to trunk, and H.J's original patch + this
>> to 4.6 branch?
>
>>I have no problems on -mtune=Bulldozer. But I object -mtune=generic
>>change and did suggest a different approach for -mtune=generic
On Tue, May 10, 2011 at 12:18 PM, Easwaran Raman wrote:
> On Tue, May 3, 2011 at 9:40 AM, Easwaran Raman wrote:
>> On Mon, May 2, 2011 at 8:37 PM, Jeff Law wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 04/26/11 16:06, Easwaran Raman wrote:
>>>
> You're right. T
On Jun 15, 2011, at 12:01 AM, DJ Delorie wrote:
>
>> This is wrong as not all FSs are case insensitive. In fact HFS+ can
>> be case sensitive too. I think you need better check than just
>> saying all Darwin is case insensitive. This is just like using
>> FAT32 on Linux. In fact I think HAVE
Another testcase attached to 49107 shows that we can't force noexcept
instantiation as part of implicitly declaring special member functions;
we need to defer their noexcept-specifications as well.
While I was working on this I noticed that it's not necessary to save
and restore input_location
> There's a difference between case preserving and case sensitive,
> though, and we really don't have a portable way to detect
> case-sensitivity on a per-directory basis, sow how can we do better?
That's roughly my thoughts on this issue. It's true that this property
is not an OS property, and we
101 - 125 of 125 matches
Mail list logo
