[patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
Hello,
this patch fixes some remaining issues with pointer-sizes for llp64
abi in libstdc++.
ChangeLog
2012-12-21 Kai Tietz
* config/os/mingw32/os_defines.h (_GLIBCXX_LLP64): Define if llp64
abi is used.
* config/os/mingw32-w64/os_defines.h: Likewise.
* libsupc++/cxxabi.h (__base_class_type_info): Change
type __offset_flags to intptr_t.
* libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define proper
for llp64 abi.
(EMERGENCY_OBJ_COUNT): Likewise.
(bitmask_type): Likewise.
* ibsupc++/hash_bytes.cc (_Hash_bytes): Handle llp64.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
Index: config/os/mingw32/os_defines.h
===
--- config/os/mingw32/os_defines.h (Revision 194655)
+++ config/os/mingw32/os_defines.h (Arbeitskopie)
@@ -72,4 +72,8 @@
#define _GLIBCXX_CDTOR_CALLABI __thiscall
#endif
+#ifdef __x86_64__
+#define _GLIBCXX_LLP64 1
#endif
+
+#endif
Index: config/os/mingw32-w64/os_defines.h
===
--- config/os/mingw32-w64/os_defines.h (Revision 194655)
+++ config/os/mingw32-w64/os_defines.h (Arbeitskopie)
@@ -74,4 +74,8 @@
#define _GLIBCXX_CDTOR_CALLABI __thiscall
#endif
+#ifdef __x86_64__
+#define _GLIBCXX_LLP64 1
#endif
+
+#endif
Index: libsupc++/cxxabi.h
===
--- libsupc++/cxxabi.h (Revision 194655)
+++ libsupc++/cxxabi.h (Arbeitskopie)
@@ -356,7 +356,7 @@ namespace __cxxabiv1
{
public:
const __class_type_info* __base_type; // Base class type.
-long __offset_flags; // Offset and info.
+intptr_t __offset_flags; // Offset and info.
enum __offset_flags_masks
{
Index: libsupc++/eh_alloc.cc
===
--- libsupc++/eh_alloc.cc (Revision 194655)
+++ libsupc++/eh_alloc.cc (Arbeitskopie)
@@ -60,7 +60,7 @@ using namespace __cxxabiv1;
#if INT_MAX == 32767
# define EMERGENCY_OBJ_SIZE128
# define EMERGENCY_OBJ_COUNT 16
-#elif LONG_MAX == 2147483647
+#elif !defined (_GLIBCXX_LLP64) && LONG_MAX == 2147483647
# define EMERGENCY_OBJ_SIZE512
# define EMERGENCY_OBJ_COUNT 32
#else
@@ -76,8 +76,12 @@ using namespace __cxxabiv1;
#if INT_MAX == 32767 || EMERGENCY_OBJ_COUNT <= 32
typedef unsigned int bitmask_type;
#else
+#if defined (_GLIBCXX_LLP64)
+typedef unsigned long long bitmask_type;
+#else
typedef unsigned long bitmask_type;
#endif
+#endif
typedef char one_buffer[EMERGENCY_OBJ_SIZE] __attribute__((aligned));
Index: libsupc++/hash_bytes.cc
===
--- libsupc++/hash_bytes.cc (Revision 194655)
+++ libsupc++/hash_bytes.cc (Arbeitskopie)
@@ -128,7 +128,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
size_t
_Hash_bytes(const void* ptr, size_t len, size_t seed)
{
-static const size_t mul = (0xc6a4a793UL << 32UL) + 0x5bd1e995UL;
+static const size_t mul = (((size_t) 0xc6a4a793UL) << 32UL)
+ + (size_t) 0x5bd1e995UL;
const char* const buf = static_cast(ptr);
// Remove the bytes not divisible by the sizeof(size_t). This
RE: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs
We checked also spec2000 and eembc_2_0 on Atom - no visible regressions and
gains
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Xinliang David Li
Sent: Friday, December 21, 2012 11:26 AM
To: Jan Hubicka
Cc: GCC Patches; Ahmad Sharif
Subject: Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs
Ahmad has helped doing some atom performance testing (ChromeOS
benchmarks) with this patch. In summary, there is no statistically significant
regression seen. There is one improvement of about +1.9%
(v8 benchmark) which looks real.
David
On Wed, Dec 12, 2012 at 9:24 AM, Xinliang David Li wrote:
> On Wed, Dec 12, 2012 at 8:37 AM, Jan Hubicka wrote:
>>> I noticed in prologue/epilogue, GCC prefers to use MOVs followed by
>>> a SP adjustment instead of a sequence of pushes/pops. The preference
>>> to the MOVs are good for old CPU micro-architectures (before
>>> pentium-4, K10), because it breaks the data dependency. In modern
>>> micro-architecture, push/pop is implemented using a mechanism called
>>> stack engine. The data dependency is removed by the hardware, and
>>> push/pop becomes very cheap (1 uOp, 1 cycle latency), and they are
>>> smaller. There is no longer the need to avoid using them. This is
>>> also what ICC does.
>>>
>>> The following patch fixed the problem. It passes
>>> bootstrap/regression test. OK to install?
>>>
>>> thanks,
>>>
>>> David
>>>
>>> Index: config/i386/i386.c
>>> ===
>>> --- config/i386/i386.c (revision 194324)
>>> +++ config/i386/i386.c (working copy)
>>> @@ -1919,10 +1919,10 @@ static unsigned int initial_ix86_tune_fe
>>>m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_AMD_MULTIPLE | m_GENERIC,
>>>
>>>/* X86_TUNE_PROLOGUE_USING_MOVE */
>>> - m_PPRO | m_CORE2I7 | m_ATOM | m_ATHLON_K8 | m_GENERIC,
>>> + m_PPRO | m_ATHLON_K8,
>>>
>>>/* X86_TUNE_EPILOGUE_USING_MOVE */
>>> - m_PPRO | m_CORE2I7 | m_ATOM | m_ATHLON_K8 | m_GENERIC,
>>> + m_PPRO | m_ATHLON_K8,
>>
>> Push/pops wrt moves was always difficult to tune on old CPUs, so I am
>> happy it is gone from generic (in fact I had similar patch pending).
>> Are you sure about Atom having stack engine, too?
>>
>
> Good question. The instruction latency table
> (http://www.agner.org/optimize/instruction_tables.pdf) shows that for
> Atom: push r has one 1uop, 1 cycle latency. However the instruction is
> not pairable which will affect ILP. The guide here
> http://www.agner.org/optimize/microarchitecture.pdf does not mention
> Atom has stack engine either.
>
> I will help collect some performance data on Atom.
>
>
> thanks,
>
> David
>
>
>> Related thing is accumulate_outgoing_args. Igor is testing it on Core
>> and I will give it a try on K10.
>>
>> Honza
>>
>> I am attaching the changes for core costs I made if someone is
>> interested in testing them. If we can declare P4/PPRo and maybe K8
>> chips obsolette for generic, there is room for improvement in
>> generic, too. Like using inc/dec again.
>>
>> Honza
>>
>> Index: config/i386/i386.c
>> ===
>> --- config/i386/i386.c (revision 194452)
>> +++ config/i386/i386.c (working copy)
>> @@ -1620,14 +1620,14 @@ struct processor_costs core_cost = {
>>COSTS_N_INSNS (8), /* cost of FABS instruction. */
>>COSTS_N_INSNS (8), /* cost of FCHS instruction. */
>>COSTS_N_INSNS (40), /* cost of FSQRT instruction. */
>> - {{libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
>> - {libcall, {{24, loop, true}, {128, rep_prefix_8_byte, true},
>> + {{libcall, {{8192, rep_prefix_4_byte, true}, {-1, libcall, false}}},
>> + {libcall, {{24, loop, true}, {8192, rep_prefix_8_byte, true},
>>{-1, libcall, false,
>>{{libcall, {{6, loop_1_byte, true},
>>{24, loop, true},
>>{8192, rep_prefix_4_byte, true},
>>{-1, libcall, false}}},
>> - {libcall, {{24, loop, true}, {512, rep_prefix_8_byte, true},
>> + {libcall, {{24, loop, true}, {8192, rep_prefix_8_byte, true},
>>{-1, libcall, false,
>>1, /* scalar_stmt_cost. */
>>1, /* scalar load_cost. */
>> @@ -1806,7 +1806,7 @@ static unsigned int initial_ix86_tune_fe
>>m_PPRO,
>>
>>/* X86_TUNE_PARTIAL_FLAG_REG_STALL */
>> - m_CORE2I7 | m_GENERIC,
>> + m_GENERIC | m_CORE2,
>>
>>/* X86_TUNE_LCP_STALL: Avoid an expensive length-changing prefix stall
>> * on 16-bit immediate moves into memory on Core2 and Corei7. */
>> @@ -1822,7 +1822,7 @@ static unsigned int initial_ix86_tune_fe
>>m_K6,
>>
>>/* X86_TUNE_USE_CLTD */
>> - ~(m_PENT | m_ATOM | m_K6),
>> + ~(m_PENT | m_ATOM | m_K6 | m_GENERIC),
>>
>>/* X86_TUNE_USE_XCHGB: Use xchgb %rh,%rl instead of rolw/rorw $8,r
RE: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs
So far we see a regression on one of eembc_1_1 test because of following change:
/* X86_TUNE_USE_VECTOR_FP_CONVERTS: Prefer vector packed SSE conversion
from FP to FP. */
- m_CORE2I7 | m_AMDFAM10 | m_GENERIC,
+ m_AMDFAM10 | m_GENERIC,
Probably we should keep it as is while there is nothing about it in docs
indeed...
Thanks,
Igor
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Jan Hubicka
Sent: Wednesday, December 12, 2012 8:37 PM
To: Xinliang David Li
Cc: GCC Patches
Subject: Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs
> I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
> SP adjustment instead of a sequence of pushes/pops. The preference to
> the MOVs are good for old CPU micro-architectures (before pentium-4,
> K10), because it breaks the data dependency. In modern
> micro-architecture, push/pop is implemented using a mechanism called
> stack engine. The data dependency is removed by the hardware, and
> push/pop becomes very cheap (1 uOp, 1 cycle latency), and they are
> smaller. There is no longer the need to avoid using them. This is
> also what ICC does.
>
> The following patch fixed the problem. It passes bootstrap/regression
> test. OK to install?
>
> thanks,
>
> David
>
> Index: config/i386/i386.c
> ===
> --- config/i386/i386.c (revision 194324)
> +++ config/i386/i386.c (working copy)
> @@ -1919,10 +1919,10 @@ static unsigned int initial_ix86_tune_fe
>m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_AMD_MULTIPLE | m_GENERIC,
>
>/* X86_TUNE_PROLOGUE_USING_MOVE */
> - m_PPRO | m_CORE2I7 | m_ATOM | m_ATHLON_K8 | m_GENERIC,
> + m_PPRO | m_ATHLON_K8,
>
>/* X86_TUNE_EPILOGUE_USING_MOVE */
> - m_PPRO | m_CORE2I7 | m_ATOM | m_ATHLON_K8 | m_GENERIC,
> + m_PPRO | m_ATHLON_K8,
Push/pops wrt moves was always difficult to tune on old CPUs, so I am happy it
is gone from generic (in fact I had similar patch pending).
Are you sure about Atom having stack engine, too?
Related thing is accumulate_outgoing_args. Igor is testing it on Core and I
will give it a try on K10.
Honza
I am attaching the changes for core costs I made if someone is interested in
testing them. If we can declare P4/PPRo and maybe K8 chips obsolette for
generic, there is room for improvement in generic, too. Like using inc/dec
again.
Honza
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 194452)
+++ config/i386/i386.c (working copy)
@@ -1620,14 +1620,14 @@ struct processor_costs core_cost = {
COSTS_N_INSNS (8), /* cost of FABS instruction. */
COSTS_N_INSNS (8), /* cost of FCHS instruction. */
COSTS_N_INSNS (40), /* cost of FSQRT instruction. */
- {{libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
- {libcall, {{24, loop, true}, {128, rep_prefix_8_byte, true},
+ {{libcall, {{8192, rep_prefix_4_byte, true}, {-1, libcall, false}}},
+ {libcall, {{24, loop, true}, {8192, rep_prefix_8_byte, true},
{-1, libcall, false,
{{libcall, {{6, loop_1_byte, true},
{24, loop, true},
{8192, rep_prefix_4_byte, true},
{-1, libcall, false}}},
- {libcall, {{24, loop, true}, {512, rep_prefix_8_byte, true},
+ {libcall, {{24, loop, true}, {8192, rep_prefix_8_byte, true},
{-1, libcall, false,
1, /* scalar_stmt_cost. */
1, /* scalar load_cost. */
@@ -1806,7 +1806,7 @@ static unsigned int initial_ix86_tune_fe
m_PPRO,
/* X86_TUNE_PARTIAL_FLAG_REG_STALL */
- m_CORE2I7 | m_GENERIC,
+ m_GENERIC | m_CORE2,
/* X86_TUNE_LCP_STALL: Avoid an expensive length-changing prefix stall
* on 16-bit immediate moves into memory on Core2 and Corei7. */ @@ -1822,7
+1822,7 @@ static unsigned int initial_ix86_tune_fe
m_K6,
/* X86_TUNE_USE_CLTD */
- ~(m_PENT | m_ATOM | m_K6),
+ ~(m_PENT | m_ATOM | m_K6 | m_GENERIC),
/* X86_TUNE_USE_XCHGB: Use xchgb %rh,%rl instead of rolw/rorw $8,rx. */
m_PENT4,
@@ -1901,7 +1901,7 @@ static unsigned int initial_ix86_tune_fe
m_COREI7 | m_BDVER,
/* X86_TUNE_SSE_PACKED_SINGLE_INSN_OPTIMAL */
- m_BDVER ,
+ m_BDVER,
/* X86_TUNE_SSE_SPLIT_REGS: Set for machines where the type and dependencies
are resolved on SSE register parts instead of whole registers, so we may
@@ -1910,10 +1910,10 @@ static unsigned int initial_ix86_tune_fe
m_ATHLON_K8,
/* X86_TUNE_SSE_TYPELESS_STORES */
- m_AMD_MULTIPLE,
+ m_AMD_MULTIPLE | m_CORE2I7, /**/
/* X86_TUNE_SSE_LOAD0_BY_PXOR */
- m_PPRO | m_P4_NOCONA,
+ m_PPRO | m_P4_NOCONA | m_CORE2I7, /**/
/* X86_TUNE_MEMORY_MISMATCH_STALL */
m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_AMD_MULTIPLE | m_GENERIC, @@ -1938
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
On Fri, 21 Dec 2012, Kai Tietz wrote: 2012-12-21 Kai Tietz * config/os/mingw32/os_defines.h (_GLIBCXX_LLP64): Define if llp64 abi is used. * config/os/mingw32-w64/os_defines.h: Likewise. * libsupc++/cxxabi.h (__base_class_type_info): Change type __offset_flags to intptr_t. Don't you want to make it a ptrdiff_t directly and remove the later cast? * libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define proper for llp64 abi. (EMERGENCY_OBJ_COUNT): Likewise. (bitmask_type): Likewise. * ibsupc++/hash_bytes.cc (_Hash_bytes): Handle llp64.
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
Hi,
On 12/21/2012 08:59 AM, Kai Tietz wrote:
Index: libsupc++/cxxabi.h
===
--- libsupc++/cxxabi.h (Revision 194655)
+++ libsupc++/cxxabi.h (Arbeitskopie)
@@ -356,7 +356,7 @@ namespace __cxxabiv1
{
public:
const __class_type_info* __base_type; // Base class type.
-long __offset_flags; // Offset and info.
+intptr_t __offset_flags; // Offset and info.
I don't think this is a safe change, in the sense that intptr_t is in
general only available on targets providing the C99 stdint.h.
Paolo.
Re: [google 4.7] atomic update of profile counters (issue6965050)
> On Thu, Dec 20, 2012 at 8:20 AM, Jan Hubicka wrote: > >> On Wed, Dec 19, 2012 at 4:29 PM, Andrew Pinski wrote: > >> > > >> > On Wed, Dec 19, 2012 at 12:08 PM, Rong Xu wrote: > >> > > Hi, > >> > > > >> > > This patch adds the supprot of atomic update the profile counters. > >> > > Tested with google internal benchmarks and fdo kernel build. > >> > > >> > I think you should use the __atomic_ functions instead of __sync_ > >> > functions as they allow better performance for simple counters as you > >> > can use __ATOMIC_RELAXED. > >> > >> You are right. I think __ATOMIC_RELAXED should be OK here. > >> Thanks for the suggestion. > >> > >> > > >> > And this would be useful for the trunk also. I was going to implement > >> > this exact thing this week but some other important stuff came up. > >> > >> I'll post trunk patch later. > > > > Yes, I like that patch, too. Even if the costs are quite high (and this is > > why > > atomic updates was sort of voted down in the past) the alternative of using > > TLS > > has problems with too-much per-thread memory. > > Actually sometimes (on some processors) atomic increments are cheaper > than doing a regular incremental. Mainly because there is an > instruction which can handle it in the L2 cache rather than populating > the L1. Octeon is one such processor where this is true. One reason for large divergence may be the fact that we optimize the counter update code. Perhaps declaring counters volatile will prevent load/store motion and reduce the racing, too. Honza > > Thanks, > Andrew Pinski > > > > > While there are even more alternatives, like recording the changes and > > commmiting them in blocks (say at function return), I guess some solution is > > better than no solution. > > > > Thanks, > > Honza
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
2012/12/21 Paolo Carlini :
> Hi,
>
>
> On 12/21/2012 08:59 AM, Kai Tietz wrote:
>>
>> Index: libsupc++/cxxabi.h
>> ===
>> --- libsupc++/cxxabi.h (Revision 194655)
>> +++ libsupc++/cxxabi.h (Arbeitskopie)
>> @@ -356,7 +356,7 @@ namespace __cxxabiv1
>> {
>> public:
>> const __class_type_info* __base_type; // Base class type.
>> -long __offset_flags; // Offset and info.
>> +intptr_t __offset_flags; // Offset and info.
>
> I don't think this is a safe change, in the sense that intptr_t is in
> general only available on targets providing the C99 stdint.h.
>
> Paolo.
Well, I thought it is always present for gcc due gstdint.h header, but
well, using ptrdiff_t here instead would be ok too IMHO, and later is
compatible to none C99-systems.
Ok, with that change (and remove of later cast to ptrdiff_t for it)?
Kai
Re: atomic update of profile counters (issue7000044)
> Hi, > > This patch adds support of atomic update of profiles counters. The goal is to > improve > the poor counter values for highly thread programs. > > The atomic update is under a new option -fprofile-gen-atomic= > N=0: default, no atomic update > N=1: atomic update edge counters. > N=2: atomic update some of value profile counters (currently indirect-call > and one value profile). > N=3: both edge counter and the above value profile counters. > Other value: fall back to the default. > > This patch is a simple porting of the version in google-4_7 branch. It uses > __atomic_fetch_add > based on Andrew Pinski's suggestion. Note I did not apply to all the value > profiles as > the indirect-call profile is the most relevant one here. > > Test with bootstrap. > > Comments and suggestions are welcomed. > > Thanks, > > -Rong > > > 2012-12-20 Rong Xu > > * libgcc/libgcov.c (__gcov_one_value_profiler_body_atomic): New > function. Atomic update profile counters. > (__gcov_one_value_profiler_atomic): Ditto. > (__gcov_indirect_call_profiler_atomic): Ditto. > * gcc/gcov-io.h: Macros for atomic update. > * gcc/common.opt: New option. > * gcc/tree-profile.c (gimple_init_edge_profiler): Atomic > update profile counters. > (gimple_gen_edge_profiler): Ditto. The patch looks resonable. Eventually we probably should provide rest of the value counters in thread safe manner. What happens on targets not having atomic operations? Honza
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
Hi, On 12/21/2012 10:16 AM, Kai Tietz wrote: Well, I thought it is always present for gcc due gstdint.h header, As far as I know, that project isn't finished yet, there are still targets which neither provide the header, neither GCC synthetizes it. See also "dg-require-effective-target stdint_types". but well, using ptrdiff_t here instead would be ok too IMHO, and later is compatible to none C99-systems. Ok, with that change (and remove of later cast to ptrdiff_t for it)? Are we 100% sure that, besides the targets we know well and love, elsewhere long is always == ptrdiff_t? Paolo.
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
2012/12/21 Paolo Carlini : > Hi, > > > On 12/21/2012 10:16 AM, Kai Tietz wrote: >> >> Well, I thought it is always present for gcc due gstdint.h header, > > As far as I know, that project isn't finished yet, there are still targets > which neither provide the header, neither GCC synthetizes it. See also > "dg-require-effective-target stdint_types". > >> but well, using ptrdiff_t here instead would be ok too IMHO, and later is >> compatible to none C99-systems. Ok, with that change (and remove of later >> cast to ptrdiff_t for it)? > > Are we 100% sure that, besides the targets we know well and love, elsewhere > long is always == ptrdiff_t? > > Paolo. well, issue isn't that 'long' is always 'ptrdiff_t'. As this is indeed the wrong assumption here. As we treat here pointers later-one as pointer-diff, it doesn't make any difference, even if pointer-size might exceed 'ptrdiff_t' (well size_t would have here the same issue, and all in all we lack a longptr_t type-definition in standard), then we still don't change behavior AFAICS. Kai
Re: [PATCH, ARM] Initial pipeline description for Cortex-A7
On 20/12/12 18:06, Greta Yorsh wrote: Currently, GCC uses generic ARMv7-A tuning for Cortex-A7. This patch adds an initial pipeline description for Cortex-A7. Details: * integer/vfp is based on the pipeline description for Cortex-A5, * models dual issue in limited circumstances using simple_alu_imm and simple_alu_shift type attribute (introduced by a previous patch), * basic neon timings. No regression on qemu for arm-none-eabi target with cpu cortex-a7. Bootstrap successful on Cortex-A15 (gcc configured with cpu cortex-a7). Performance evaluation on Cortex-A7 hardware: Coremark: * No change compared to generic tuning even though the generated assembly is significantly different due to instruction scheduling. * Improvement compared to tuning for Cortex-A5: 4% improvement in arm mode and 9% improvement in thumb mode. CINT2000: * compared to generic tuning, overall improvement of 1.9%. * compared to tuning for Cortex-A5, overall improvement of 1.5%. * in both cases, all benchmarks improved except 254.gap. CFP2000: * compared to generic tuning (which doesn't do much for FP), overall improvement of 5.5%, all benchmarks improved. * compared to Cortex-A5 tuning (as pipeline descriptions are nearly identical) overall no change, but individual benchmarks mixed results. Ok for trunk? Thanks, Greta gcc/ChangeLog 2012-12-20 Greta Yorsh * config/arm/cortex-a7.md: New file. * config/arm/arm.md: Include cortex-a7.md. (generic_sched): Don't use generic scheduler for Cortex-A7. (generic_vfp): Likewise. * config/arm/t-arm (arm_cpu_table): Likewise. This entry is wrong. Please fix when you commit. * config/arm/arm.c: (TARGET_SCHED_REORDER): Use arm_sched_reorder. (arm_sched_reorder): New function. (cortexa7_older_only,cortexa7_younger): Likewise. Ok once the above has been fixed. R.
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
On 12/21/2012 10:36 AM, Kai Tietz wrote: well, issue isn't that 'long' is always 'ptrdiff_t'. But then, if we just change the type without paying attention to size (and alignment) aren't we looking for BIG ABI trouble?!? Paolo.
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
2012/12/21 Paolo Carlini : > On 12/21/2012 10:36 AM, Kai Tietz wrote: >> >> well, issue isn't that 'long' is always 'ptrdiff_t'. > > But then, if we just change the type without paying attention to size (and > alignment) aren't we looking for BIG ABI trouble?!? Huh? We have ABI-trouble due long is too small to hold a pointer-diff for llp64. Intended is here 'pointer-size' AFAICS in code, but with wrong assumption that a 'long' is always long enough. Btw I just checked all targets we have right now in gcc. The type ptrdiff_t is always either 'long', or 'int' (ilp32, lp64), and 'long long' for LLP64. Means ptrdiff_t gets always equal (or bigger) to biggest pointer-size for target (AFAICS). Kai
Re: [PR libmudflap/53359] don't register symbols not emitted
On Fri, Dec 21, 2012 at 6:33 AM, Alexandre Oliva wrote: > libmudflap emits a global initializer that registers memory ranges for > global data symbols. However, even if IPA decides not to emit a symbol > because it's unused, we'd still emit registration sequences for them in > some cases, which, in the PR testcase, would result in TOC references to > the undefined symbols. > > This patch fixes the problem, avoiding registration for symbols that are > not present in the varpool. > > Regstrapped on x86_64-linux-gnu and i686-linux-gnu; I've also verified > that it removes the TOC references on a ppc64-linux-gnu cross. > > Ok to install? Hmm, I think that at this point of the compilation you are looking for TREE_ASM_WRITTEN instead. I'm not sure we will never end up having a symtab node that not ends up being emitted. Honza? Thanks, Richard. > > > > -- > Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ > You must be the change you wish to see in the world. -- Gandhi > Be Free! -- http://FSFLA.org/ FSF Latin America board member > Free Software Evangelist Red Hat Brazil Compiler Engineer >
Re: [wwwdocs,Java] Obsolete GCJ FAQ entry for Solaris?
On 12/21/2012 04:02 AM, Gerald Pfeifer wrote: > PING. > > On Fri, 2 Nov 2012, Gerald Pfeifer wrote: >> Rainer (or others), >> >> the FAQ entry below seems obsolete to me (dates back more than a >> decade). Shall we remove it, or is there something else we still >> should document (in addition to gcc/doc/install.texi)? OK, thanks. Andrew.
Re: [PR libmudflap/53359] don't register symbols not emitted
On Fri, Dec 21, 2012 at 10:50:58AM +0100, Richard Biener wrote: > On Fri, Dec 21, 2012 at 6:33 AM, Alexandre Oliva wrote: > > libmudflap emits a global initializer that registers memory ranges for > > global data symbols. However, even if IPA decides not to emit a symbol > > because it's unused, we'd still emit registration sequences for them in > > some cases, which, in the PR testcase, would result in TOC references to > > the undefined symbols. > > > > This patch fixes the problem, avoiding registration for symbols that are > > not present in the varpool. > > > > Regstrapped on x86_64-linux-gnu and i686-linux-gnu; I've also verified > > that it removes the TOC references on a ppc64-linux-gnu cross. > > > > Ok to install? > > Hmm, I think that at this point of the compilation you are looking for > TREE_ASM_WRITTEN instead. I'm not sure we will never end up > having a symtab node that not ends up being emitted. Yeah, asan.c also tests TREE_ASM_WRITTEN and doesn't register !TREE_ASM_WRITTEN decls for instrumentation. Jakub
Re: [google 4.7] atomic update of profile counters (issue6965050)
On Fri, Dec 21, 2012 at 10:13 AM, Jan Hubicka wrote: >> On Thu, Dec 20, 2012 at 8:20 AM, Jan Hubicka wrote: >> >> On Wed, Dec 19, 2012 at 4:29 PM, Andrew Pinski wrote: >> >> > >> >> > On Wed, Dec 19, 2012 at 12:08 PM, Rong Xu wrote: >> >> > > Hi, >> >> > > >> >> > > This patch adds the supprot of atomic update the profile counters. >> >> > > Tested with google internal benchmarks and fdo kernel build. >> >> > >> >> > I think you should use the __atomic_ functions instead of __sync_ >> >> > functions as they allow better performance for simple counters as you >> >> > can use __ATOMIC_RELAXED. >> >> >> >> You are right. I think __ATOMIC_RELAXED should be OK here. >> >> Thanks for the suggestion. >> >> >> >> > >> >> > And this would be useful for the trunk also. I was going to implement >> >> > this exact thing this week but some other important stuff came up. >> >> >> >> I'll post trunk patch later. >> > >> > Yes, I like that patch, too. Even if the costs are quite high (and this is >> > why >> > atomic updates was sort of voted down in the past) the alternative of >> > using TLS >> > has problems with too-much per-thread memory. >> >> Actually sometimes (on some processors) atomic increments are cheaper >> than doing a regular incremental. Mainly because there is an >> instruction which can handle it in the L2 cache rather than populating >> the L1. Octeon is one such processor where this is true. > > One reason for large divergence may be the fact that we optimize the counter > update code. Perhaps declaring counters volatile will prevent load/store > motion > and reduce the racing, too. Well, that will make it slower, too. The best benchmark to check is tramp3d for all this stuff. I remember that ICC when it had a function call for each counter update was about 10x slower instrumented than w/o instrumentation (that is, I never waited long enough to make it finish even one iteration ...) Thus, it's very important that counter updates are subject to loop invariant / store motion (and SCEV const-prop)! GCC does a wonderful job here at the moment, please do not regress here. Richard. > Honza >> >> Thanks, >> Andrew Pinski >> >> > >> > While there are even more alternatives, like recording the changes and >> > commmiting them in blocks (say at function return), I guess some solution >> > is >> > better than no solution. >> > >> > Thanks, >> > Honza
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
Hello,
I changed type in __base_class_type_info to wide-enough type only for
llp64 target.
By this we have no (new) side-effects to other targets.
ChangeLog
2012-12-21 Kai Tietz
* config/os/mingw32/os_defines.h (_GLIBCXX_LLP64): Define if llp64
abi is used.
* config/os/mingw32-w64/os_defines.h: Likewise.
* libsupc++/cxxabi.h (__base_class_type_info): Adjust
type of __offset_flags for llp64.
* libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define proper
for llp64 abi.
(EMERGENCY_OBJ_COUNT): Likewise.
(bitmask_type): Likewise.
* ibsupc++/hash_bytes.cc (_Hash_bytes): Handle llp64.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
Index: config/os/mingw32/os_defines.h
===
--- config/os/mingw32/os_defines.h (Revision 194655)
+++ config/os/mingw32/os_defines.h (Arbeitskopie)
@@ -72,4 +72,8 @@
#define _GLIBCXX_CDTOR_CALLABI __thiscall
#endif
+#ifdef __x86_64__
+#define _GLIBCXX_LLP64 1
#endif
+
+#endif
Index: config/os/mingw32-w64/os_defines.h
===
--- config/os/mingw32-w64/os_defines.h (Revision 194655)
+++ config/os/mingw32-w64/os_defines.h (Arbeitskopie)
@@ -74,4 +74,8 @@
#define _GLIBCXX_CDTOR_CALLABI __thiscall
#endif
+#ifdef __x86_64__
+#define _GLIBCXX_LLP64 1
#endif
+
+#endif
Index: libsupc++/cxxabi.h
===
--- libsupc++/cxxabi.h (Revision 194655)
+++ libsupc++/cxxabi.h (Arbeitskopie)
@@ -356,7 +356,11 @@ namespace __cxxabiv1
{
public:
const __class_type_info* __base_type; // Base class type.
+#ifdef _GLIBCXX_LLP64
+long long __offset_flags; // Offset and info.
+#else
long __offset_flags; // Offset and info.
+#endif
enum __offset_flags_masks
{
Index: libsupc++/eh_alloc.cc
===
--- libsupc++/eh_alloc.cc (Revision 194655)
+++ libsupc++/eh_alloc.cc (Arbeitskopie)
@@ -60,7 +60,7 @@ using namespace __cxxabiv1;
#if INT_MAX == 32767
# define EMERGENCY_OBJ_SIZE128
# define EMERGENCY_OBJ_COUNT 16
-#elif LONG_MAX == 2147483647
+#elif !defined (_GLIBCXX_LLP64) && LONG_MAX == 2147483647
# define EMERGENCY_OBJ_SIZE512
# define EMERGENCY_OBJ_COUNT 32
#else
@@ -76,8 +76,12 @@ using namespace __cxxabiv1;
#if INT_MAX == 32767 || EMERGENCY_OBJ_COUNT <= 32
typedef unsigned int bitmask_type;
#else
+#if defined (_GLIBCXX_LLP64)
+typedef unsigned long long bitmask_type;
+#else
typedef unsigned long bitmask_type;
#endif
+#endif
typedef char one_buffer[EMERGENCY_OBJ_SIZE] __attribute__((aligned));
Index: libsupc++/hash_bytes.cc
===
--- libsupc++/hash_bytes.cc (Revision 194655)
+++ libsupc++/hash_bytes.cc (Arbeitskopie)
@@ -128,7 +128,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
size_t
_Hash_bytes(const void* ptr, size_t len, size_t seed)
{
-static const size_t mul = (0xc6a4a793UL << 32UL) + 0x5bd1e995UL;
+static const size_t mul = (((size_t) 0xc6a4a793UL) << 32UL)
+ + (size_t) 0x5bd1e995UL;
const char* const buf = static_cast(ptr);
// Remove the bytes not divisible by the sizeof(size_t). This
Index: testsuite/18_support/50594.cc
===
--- testsuite/18_support/50594.cc (Revision 194655)
+++ testsuite/18_support/50594.cc (Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options "-fwhole-program" }
+// { dg-options "-fwhole-program -static-libstdc++" { target *-*-mingw* } }
// Copyright (C) 2011 Free Software Foundation
//
Index: testsuite/19_diagnostics/error_code/cons/1.cc
===
--- testsuite/19_diagnostics/error_code/cons/1.cc (Revision 194655)
+++ testsuite/19_diagnostics/error_code/cons/1.cc (Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options "-std=gnu++0x" }
+// { dg-options "-std=gnu++0x -static-libstdc++" { target *-*-mingw* } }
// 2007-08-22 Benjamin Kosnik
// Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
Index: testsuite/19_diagnostics/error_code/operators/bool.cc
===
--- testsuite/19_diagnostics/error_code/operators/bool.cc (Revision
194655)
+++ testsuite/19_diagnostics/error_code/operators/bool.cc (Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-options "-std=gnu++0x" }
+// { dg-options "-std=gnu++0x -static-libstdc++" { target *-*-mingw* } }
// 2007-08-22 Benjamin Kosnik
// Copyright (C) 2007, 2009 Free Software Foundation, Inc.
Index: testsuite/19_diagnostics/error_code/operators/equal.cc
===
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
On 12/21/2012 10:59 AM, Kai Tietz wrote: Hello, I changed type in __base_class_type_info to wide-enough type only for llp64 target. By this we have no (new) side-effects to other targets. Thanks. This is something I can approve at once. Paolo.
Re: [RFA/4.7/ARM] Backport arm-*-linux-gnueabihf triplet support to 4.7
On 17 December 2012 14:28, Richard Earnshaw wrote:
> On 21/11/12 11:48, Matthew Gretton-Dann wrote:
>>
>> On 21 November 2012 00:05, Matthias Klose wrote:
>>>
>>>
>>> looks fine, except one missing chunk from my original patch. maybe left
>>> out
>>> intentionally.
>>>
>>>Matthias
>>>
>>> Index: b/src/gcc/config.gcc
>>> ===
>>> --- a/src/gcc/config.gcc
>>> +++ b/src/gcc/config.gcc
>>> @@ -934,7 +934,7 @@
>>> tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h
>>> arm/linux-gas.h
>>> arm/uclinux-elf.h glibc-stdint.h"
>>> tmake_file="arm/t-arm arm/t-arm-elf"
>>> case ${target} in
>>> - arm*-*-uclinux*eabi)
>>> + arm*-*-uclinux*eabi*)
>>> tm_file="$tm_file arm/bpabi.h arm/uclinux-eabi.h"
>>> tmake_file="$tmake_file arm/t-bpabi"
>>> # The BPABI long long divmod functions return a 128-bit
>>> value in
>>
>>
>> This change isn't in your commit to trunk of 2012-10-15 which is what
>> I backported. This is because Richard Earnshaw effectively made this
>> change when he removed FPA support (SVN rev 188510).
>>
>> I'm happy to do a patch that makes this change - but I think it should
>> be a separate patch to this backport one.
>>
>
> I would have thought this ought to be done for consistency.
Committed above as obvious (after discussions off-list with Richard
Earnshaw). Attached patch shows what was actually committed.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 194655)
+++ gcc/config.gcc (working copy)
@@ -882,7 +882,7 @@
tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h
arm/uclinux-elf.h glibc-stdint.h"
tmake_file="arm/t-arm arm/t-arm-elf"
case ${target} in
- arm*-*-uclinux*eabi)
+ arm*-*-uclinux*eabi*)
tm_file="$tm_file arm/bpabi.h arm/uclinux-eabi.h"
tmake_file="$tmake_file arm/t-bpabi"
# The BPABI long long divmod functions return a 128-bit value in
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 194655)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2012-12-21 Matthew Gretton-Dann
+
+ * config.gcc: Match arm*-*-uclinux*eabi* for EABI uCLinux.
+
2012-12-18 Matthew Gretton-Dann
Backport from mainline
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
Hello!
> 2012-12-21 Kai Tietz
>
> * config/os/mingw32/os_defines.h (_GLIBCXX_LLP64): Define if llp64
> abi is used.
> * config/os/mingw32-w64/os_defines.h: Likewise.
> * libsupc++/cxxabi.h (__base_class_type_info): Adjust
> type of __offset_flags for llp64.
> * libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define proper
> for llp64 abi.
> (EMERGENCY_OBJ_COUNT): Likewise.
> (bitmask_type): Likewise.
> * ibsupc++/hash_bytes.cc (_Hash_bytes): Handle llp64.
// { dg-options "-fwhole-program" }
+// { dg-options "-fwhole-program -static-libstdc++" { target *-*-mingw* } }
Please use dg-additional-options in these cases.
Uros.
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
2012/12/21 Uros Bizjak :
> Hello!
>
>> 2012-12-21 Kai Tietz
>>
>> * config/os/mingw32/os_defines.h (_GLIBCXX_LLP64): Define if llp64
>> abi is used.
>> * config/os/mingw32-w64/os_defines.h: Likewise.
>> * libsupc++/cxxabi.h (__base_class_type_info): Adjust
>> type of __offset_flags for llp64.
>> * libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define proper
>> for llp64 abi.
>> (EMERGENCY_OBJ_COUNT): Likewise.
>> (bitmask_type): Likewise.
>> * ibsupc++/hash_bytes.cc (_Hash_bytes): Handle llp64.
>
> // { dg-options "-fwhole-program" }
> +// { dg-options "-fwhole-program -static-libstdc++" { target *-*-mingw* } }
>
> Please use dg-additional-options in these cases.
I tried, but it doesn't seems to be supported by libstdc++'s testsuite.
Kai
PS: Sorry, testsuite cases I wanted sent separately, as I am still
going through it to adjust static-linking.
[PATCH] Testcase for PR52996
The testcase in the PR no longer reproduces its issue.
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-12-21 Richard Biener
PR tree-optimization/52996
* gcc.dg/torture/pr52996.c: New testcase.
Index: testsuite/gcc.dg/torture/pr52996.c
===
--- testsuite/gcc.dg/torture/pr52996.c (revision 0)
+++ testsuite/gcc.dg/torture/pr52996.c (working copy)
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-funswitch-loops" } */
+
+int a, b, c, d, e, f;
+void
+fn1 ()
+{
+int g, h;
+lbl_173:
+if (a)
+c++;
+lbl_158:
+e = 0;
+h = 0;
+for (; h > -8; h--)
+{
+g = 0;
+for (; g <= 0; g += 1)
+{
+d = 1;
+for (; d >= 0; d -= 1)
+a = 1;
+if (b)
+break;
+if (f)
+return;
+if (h)
+goto lbl_158;
+}
+}
+goto lbl_173;
+}
+
Re: fix libquadmath build regression
Alexandre Oliva wrote:
Revision 193063 brought in calls to fraiseexcept() into libquadmath,
which caused a build regression on Fedora 16 (BLAG 160k actually) x86_64
while building an i686-linux-gnu native toolchain.
The problem is that glibc has an extern inline definition of
fraiseexcept that is introduced by including fenv.h (it's in
bits/fenv.h), and this definition requires SSE support regardless of
target arch of word width, so it doesn't work for an i686 native that
doesn't assume SSE registers and instructions are available.
This bug is fixed in newer versions of glibc, but I figured it wouldn't
hurt to have a work-around in place for libquadmath to build, detecting
that the extern inline in the header is broken and introducing a wrapper
that bypasses the header so as to use the out-of-line definition in the
math library.
Is this ok to install?
+ AC_CACHE_CHECK([whether feraiseexcept is broken in fenv.h],
[quadmath_cv_feraiseexcept_fenv_broken],
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]],
[feraiseexcept (FE_INVALID);])],
[quadmath_cv_feraiseexcept_fenv_broken=no],
[quadmath_cv_feraiseexcept_fenv_broken=yes])])
The line is too long; there is no reason that it is longer than 80
characters.
-# generated automatically by aclocal 1.11.1 -*- Autoconf -*-
+# generated automatically by aclocal 1.11.6 -*- Autoconf -*-
I think you should use automake 1.11.1; at least that's what is stated
in http://gcc.gnu.org/install/prerequisites.html
(Side note: I wouldn't mind if GCC would update to a newer required
autoconf/automake version.)
+/* Optional replacement for compile-time broken feraiseexcept. */
+#undef QUADMATH_FERAISEEXCEPT
That comment doesn't reflect the use (cf. below). Shouldn't that be
something like "Function to call for raising an exception; allows for
replacing a compile-time broken feraiseexcept."?
-#ifdef USE_FENV_H
- feraiseexcept (FE_INVALID);
+#ifdef QUADMATH_FERAISEEXCEPT
+ QUADMATH_FERAISEEXCEPT (FE_INVALID);
#endif
+/* Wrapper for feraiseexcept. This file is in the public domain.
+ Contributed by Alexandre Oliva
+ See QUADMATH_FERAISEEXCEPT in configure.ac for more information. */
+
+int
+__quadmath_feraiseexcept (int xcpt)
+{
+ feraiseexcept (xcpt);
+}
I personally would like to see a tiny bit longer comment, additionally
explaining quickly the purpose. For instance: "Avoid calling an inline
function." or something like that. Additionally, GCC warns by default
that you do not return an int and that feraiseexcept is implicitly
declared. Can you fix both?
Otherwise, it looks okay to me.
Tobias
Re: [google 4.7] atomic update of profile counters (issue6965050)
> On Fri, Dec 21, 2012 at 10:13 AM, Jan Hubicka wrote: > >> On Thu, Dec 20, 2012 at 8:20 AM, Jan Hubicka wrote: > >> >> On Wed, Dec 19, 2012 at 4:29 PM, Andrew Pinski > >> >> wrote: > >> >> > > >> >> > On Wed, Dec 19, 2012 at 12:08 PM, Rong Xu wrote: > >> >> > > Hi, > >> >> > > > >> >> > > This patch adds the supprot of atomic update the profile counters. > >> >> > > Tested with google internal benchmarks and fdo kernel build. > >> >> > > >> >> > I think you should use the __atomic_ functions instead of __sync_ > >> >> > functions as they allow better performance for simple counters as you > >> >> > can use __ATOMIC_RELAXED. > >> >> > >> >> You are right. I think __ATOMIC_RELAXED should be OK here. > >> >> Thanks for the suggestion. > >> >> > >> >> > > >> >> > And this would be useful for the trunk also. I was going to implement > >> >> > this exact thing this week but some other important stuff came up. > >> >> > >> >> I'll post trunk patch later. > >> > > >> > Yes, I like that patch, too. Even if the costs are quite high (and this > >> > is why > >> > atomic updates was sort of voted down in the past) the alternative of > >> > using TLS > >> > has problems with too-much per-thread memory. > >> > >> Actually sometimes (on some processors) atomic increments are cheaper > >> than doing a regular incremental. Mainly because there is an > >> instruction which can handle it in the L2 cache rather than populating > >> the L1. Octeon is one such processor where this is true. > > > > One reason for large divergence may be the fact that we optimize the counter > > update code. Perhaps declaring counters volatile will prevent load/store > > motion > > and reduce the racing, too. > > Well, that will make it slower, too. The best benchmark to check is tramp3d > for all this stuff. I remember that ICC when it had a function call for each > counter update was about 10x slower instrumented than w/o instrumentation > (that is, I never waited long enough to make it finish even one iteration ...) > > Thus, it's very important that counter updates are subject to loop > invariant / store > motion (and SCEV const-prop)! GCC does a wonderful job here at the moment, > please do not regress here. Well, this feature is enabled by user switch. I do not thing we should change the default behaviour... Which makes me to ask, the patch is very isolated (i.e. enabled by command line only) and has obvious value for end user. Would it be fine for stage3? Honza
Re: [PR libmudflap/53359] don't register symbols not emitted
> On Fri, Dec 21, 2012 at 10:50:58AM +0100, Richard Biener wrote: > > On Fri, Dec 21, 2012 at 6:33 AM, Alexandre Oliva wrote: > > > libmudflap emits a global initializer that registers memory ranges for > > > global data symbols. However, even if IPA decides not to emit a symbol > > > because it's unused, we'd still emit registration sequences for them in > > > some cases, which, in the PR testcase, would result in TOC references to > > > the undefined symbols. > > > > > > This patch fixes the problem, avoiding registration for symbols that are > > > not present in the varpool. > > > > > > Regstrapped on x86_64-linux-gnu and i686-linux-gnu; I've also verified > > > that it removes the TOC references on a ppc64-linux-gnu cross. > > > > > > Ok to install? > > > > Hmm, I think that at this point of the compilation you are looking for > > TREE_ASM_WRITTEN instead. I'm not sure we will never end up > > having a symtab node that not ends up being emitted. Ones representing external vars, but that probably doesn't count. Also for constant pool the decision whether to emit or not is still done behind symtab's back. All other nodes should be removed. > > Yeah, asan.c also tests TREE_ASM_WRITTEN and doesn't register > !TREE_ASM_WRITTEN decls for instrumentation. Note that FEs sometimes play dirty games setting TREE_ASM_WRITTEN to true to avoid fake symbols being output. Probably none of these matters at this point. Just to point it out. Honza > > Jakub
Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)
Hi,
On 12/07/2012 06:05 AM, Jason Merrill wrote:
It's perfectly OK to initialize a base class of abstract type; it's
only an error to create a full object of such a type. So this patch
moves the check from more generic initialization code out into a
function that's definitely creating a new object.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
I was looking a bit more into this Bug, and something seems still weird
about the testcase in Comment #1 of the audit trail, which we also
didn't reject with 4.6.x:
class base
{
protected:
base()
{}
};
class derived : public base
{
public:
derived()
: base{} // <-- Note the c++11 curly brace syntax
{}
};
int main()
{
derived d1;
return 0;
}
???
Thanks,
Paolo.
[PATCH] Include gmp.h from system.h to fix PR54659
The following patch includes gmp.h from system.h (where it belongs,
as a system header). This makes sure the libintl kludge we put in
place with --disable-nls doesn't wreck the gmp header (well, hopefully,
earlier fix to be reverted?).
This runs into issues with Ada which basically does (ugh)
#ifdef __cplusplus
extern "C" {
#endif
#include "system.h"
#endif __cplusplus
}
#endif
which of course wrecks any system header doing __cplusplus
conditional stuff (such as gmp.h including iosfwd). The patch
un-kludges this by wrapping system.h inside extern "C++" when
compiling with the C++ frontend.
But - really - Ada people - can you fix that on your side please?
(CCed people doing r176210)
Go frontend is left untouched (it also includes gmp.h)
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Comments? Ok?(!?)
Thanks,
Richard.
2012-12-21 Richard Biener
PR bootstrap/54659
* system.h: Wrap inside extern "C++" when __cplusplus. Include gmp.h.
* tree-ssa-loop-niter.c: Do not include gmp.h here.
* double-int.h: Likewise.
* realmpfr.h: Likewise.
fortran/
* gfortran.h: Do not include gmp.h here.
Index: gcc/system.h
===
*** gcc/system.h(revision 194659)
--- gcc/system.h(working copy)
*** along with GCC; see the file COPYING3.
*** 24,29
--- 24,34
#ifndef GCC_SYSTEM_H
#define GCC_SYSTEM_H
+ /* Undo extern "C" wrappings done by including files (Ada). */
+ #ifdef __cplusplus
+ extern "C++" {
+ #endif
+
/* We must include stdarg.h before stdio.h. */
#include
*** extern int vsnprintf(char *, size_t, con
*** 638,643
--- 643,650
#include
#endif
+ #include
+
/* Get libiberty declarations. */
#include "libiberty.h"
*** helper_const_non_const_cast (const char
*** 1051,1054
--- 1058,1065
#define DEBUG_VARIABLE
#endif
+ #ifdef __cplusplus
+ }
+ #endif
+
#endif /* ! GCC_SYSTEM_H */
Index: gcc/tree-ssa-loop-niter.c
===
*** gcc/tree-ssa-loop-niter.c (revision 194659)
--- gcc/tree-ssa-loop-niter.c (working copy)
*** along with GCC; see the file COPYING3.
*** 38,44
#include "flags.h"
#include "diagnostic-core.h"
#include "tree-inline.h"
- #include "gmp.h"
#define SWAP(X, Y) do { affine_iv *tmp = (X); (X) = (Y); (Y) = tmp; } while
(0)
--- 38,43
Index: gcc/double-int.h
===
*** gcc/double-int.h(revision 194659)
--- gcc/double-int.h(working copy)
*** along with GCC; see the file COPYING3.
*** 20,29
#ifndef DOUBLE_INT_H
#define DOUBLE_INT_H
- #ifndef GENERATOR_FILE
- #include
- #endif
-
/* A large integer is currently represented as a pair of HOST_WIDE_INTs.
It therefore represents a number with precision of
2 * HOST_BITS_PER_WIDE_INT bits (it is however possible that the
--- 20,25
Index: gcc/fortran/gfortran.h
===
*** gcc/fortran/gfortran.h (revision 194659)
--- gcc/fortran/gfortran.h (working copy)
*** gfc_intrinsic_sym;
*** 1699,1705
EXPR_COMPCALL Function (or subroutine) call of a procedure pointer
component or type-bound procedure. */
- #include
#include
#include
#define GFC_RND_MODE GMP_RNDN
--- 1699,1704
Index: gcc/realmpfr.h
===
*** gcc/realmpfr.h (revision 194659)
--- gcc/realmpfr.h (working copy)
***
*** 22,28
#ifndef GCC_REALGMP_H
#define GCC_REALGMP_H
- #include
#include
#include
#include "real.h"
--- 22,27
Re: [PATCH] Include gmp.h from system.h to fix PR54659
> This runs into issues with Ada which basically does (ugh)
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> #include "system.h"
>
> #endif __cplusplus
> }
> #endif
>
> which of course wrecks any system header doing __cplusplus
> conditional stuff (such as gmp.h including iosfwd). The patch
> un-kludges this by wrapping system.h inside extern "C++" when
> compiling with the C++ frontend.
>
> But - really - Ada people - can you fix that on your side please?
> (CCed people doing r176210)
Like so? I cannot believe that all this fuss was about moving 3 lines within
less than a dozen of files...
--
Eric BotcazouIndex: targext.c
===
--- targext.c (revision 194632)
+++ targext.c (working copy)
@@ -35,10 +35,6 @@
Note that, in order to have access to the TARGET_* macros used below,
the file must be compiled with IN_GCC defined, even for the library. */
-#ifdef __cplusplus
-extern "C" {
-#endif
-
#ifdef IN_RTS
#include "tconfig.h"
#include "tsystem.h"
@@ -57,6 +53,10 @@ extern "C" {
#define TARGET_EXECUTABLE_SUFFIX ""
#endif
+#ifdef __cplusplus
+extern "C" {
+#endif
+
const char *__gnat_target_object_extension = TARGET_OBJECT_SUFFIX;
const char *__gnat_target_executable_extension = TARGET_EXECUTABLE_SUFFIX;
const char *__gnat_target_debuggable_extension = TARGET_EXECUTABLE_SUFFIX;
Index: raise.c
===
--- raise.c (revision 194632)
+++ raise.c (working copy)
@@ -32,10 +32,6 @@
/* Shared routines to support exception handling. __gnat_unhandled_terminate
is shared between all exception handling mechanisms. */
-#ifdef __cplusplus
-extern "C" {
-#endif
-
#ifdef IN_RTS
#include "tconfig.h"
#include "tsystem.h"
@@ -47,6 +43,10 @@ extern "C" {
#include "adaint.h"
#include "raise.h"
+#ifdef __cplusplus
+extern "C" {
+#endif
+
/* Wrapper to builtin_longjmp. This is for the compiler eh only, as the sjlj
runtime library interfaces directly to the intrinsic. We can't yet do
this for the compiler itself, because this capability relies on changes
Index: argv.c
===
--- argv.c (revision 194632)
+++ argv.c (working copy)
@@ -42,10 +42,6 @@
main program, and these routines are accessed from the
Ada.Command_Line.Environment package. */
-#ifdef __cplusplus
-extern "C" {
-#endif
-
#ifdef IN_RTS
#include "tconfig.h"
#include "tsystem.h"
@@ -57,6 +53,10 @@ extern "C" {
#include "adaint.h"
+#ifdef __cplusplus
+extern "C" {
+#endif
+
/* argc and argv of the main program are saved under gnat_argc and gnat_argv,
envp of the main program is saved under gnat_envp. */
Index: seh_init.c
===
--- seh_init.c (revision 194632)
+++ seh_init.c (working copy)
@@ -32,10 +32,6 @@
/* This unit contains support for SEH (Structured Exception Handling).
Right now the only implementation is for Win32. */
-#ifdef __cplusplus
-extern "C" {
-#endif
-
#ifdef IN_RTS
#include "tconfig.h"
#include "tsystem.h"
@@ -50,6 +46,10 @@ extern "C" {
#include "raise.h"
+#ifdef __cplusplus
+extern "C" {
+#endif
+
/* Addresses of exception data blocks for predefined exceptions. */
extern struct Exception_Data constraint_error;
extern struct Exception_Data numeric_error;
Index: env.c
===
--- env.c (revision 194632)
+++ env.c (working copy)
@@ -29,10 +29,6 @@
* *
/
-#ifdef __cplusplus
-extern "C" {
-#endif
-
#ifdef IN_RTS
#include "tconfig.h"
#include "tsystem.h"
@@ -76,6 +72,10 @@ extern "C" {
#include "system.h"
#endif /* IN_RTS */
+#ifdef __cplusplus
+extern "C" {
+#endif
+
#if defined (__APPLE__)
#include
#endif
Index: init.c
===
--- init.c (revision 194632)
+++ init.c (working copy)
@@ -38,10 +38,6 @@
installed by this file are used to catch the resulting signals that come
from these probes failing (i.e. touching protected pages). */
-#ifdef __cplusplus
-extern "C" {
-#endif
-
/* This file should be kept synchronized with 2sinit.ads, 2sinit.adb,
s-init-ae653-cert.adb and s-init-xi-sparc.adb. All these files implement
the required functionality for different targets. */
@@ -71,6 +67,10 @@ extern "C" {
#include "adaint.h"
#include "raise.h"
+#ifdef __cplusplus
+extern "C" {
+#endif
+
extern void __gnat_raise_program_error (const char *, int);
/* Addresses of exception data blocks for predefined exceptions. Tasking_Error
Index: initialize.c
===
--- initialize.c (revision 194632)
+++ initialize.c (working copy)
@@ -34,10 +34,6 @@
Re: [PATCH] Include gmp.h from system.h to fix PR54659
On Fri, 21 Dec 2012, Eric Botcazou wrote:
> > This runs into issues with Ada which basically does (ugh)
> >
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> >
> > #include "system.h"
> >
> > #endif __cplusplus
> > }
> > #endif
> >
> > which of course wrecks any system header doing __cplusplus
> > conditional stuff (such as gmp.h including iosfwd). The patch
> > un-kludges this by wrapping system.h inside extern "C++" when
> > compiling with the C++ frontend.
> >
> > But - really - Ada people - can you fix that on your side please?
> > (CCed people doing r176210)
>
> Like so? I cannot believe that all this fuss was about moving 3 lines within
> less than a dozen of files...
The patch looks fine to me (though it's not 100% obvious to me as not only
system headers are now no longer in extern "C" - which is why I simply
tried the un-wrapping). So, if you think that's ok please commit it.
It certainly helps not to rely on compilers handling nested extern "foo"
correctly ...
Thanks,
Richard.
Re: [PATCH] Include gmp.h from system.h to fix PR54659
> The patch looks fine to me (though it's not 100% obvious to me as not only > system headers are now no longer in extern "C" - which is why I simply > tried the un-wrapping). So, if you think that's ok please commit it. Done. -- Eric Botcazou
[PATCH] PR c++/52343 - error with alias template as template template argument
Hello,
In the example accompanying this patch, check_instantiated_arg tries
to ensure that a non-type template argument should be a constant if it
has integral or enumeration type.
The problem is that an alias template which type-id is, e.g, an
integer, looks like an argument that has integral/enumeration type:
its TREE_TYPE is an integer type. So check_instantiated_arg
mistenkaly barks that this integral non-type argument is not a
constant.
I am proposing to tighten the test in check_instantiated_arg to allow
type template (and thus aliast template) arguments.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
PR c++/52343
* pt.c (check_instantiated_arg): Allow type template arguments.
gcc/testsuite/
PR c++/52343
* g++.dg/cpp0x/alias-decl-29.C: New test.
---
gcc/cp/pt.c| 4 +++-
gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C | 10 ++
2 files changed, 13 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1b3f039..e2e8311 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14425,7 +14425,9 @@ check_instantiated_arg (tree tmpl, tree t,
tsubst_flags_t complain)
constant. */
else if (TREE_TYPE (t)
&& INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))
- && !TREE_CONSTANT (t))
+ && !TREE_CONSTANT (t)
+ /* Class template and alias template arguments should be OK. */
+ && !DECL_TYPE_TEMPLATE_P (t))
{
if (complain & tf_error)
error ("integral expression %qE is not constant", t);
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C
new file mode 100644
index 000..f6cc695
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C
@@ -0,0 +1,10 @@
+// Origin: PR c++/52343
+// { dg-do compile { target c++11 } }
+
+template
+using A = int;
+
+template class>
+struct B {};
+
+B b;
--
Dodji
Re: [PATCH] Include gmp.h from system.h to fix PR54659
On Fri, 21 Dec 2012, Eric Botcazou wrote: > > The patch looks fine to me (though it's not 100% obvious to me as not only > > system headers are now no longer in extern "C" - which is why I simply > > tried the un-wrapping). So, if you think that's ok please commit it. > > Done. Thanks. Richard.
[patch c++]: Fix type_info struct for llp64 targets
Hello,
this patch fixes the layout of the info_type-s for llp64 target. We
used here 'long' type instead
of pointer-scalar-witdth type. That's an issue for llp64 targets.
I introduced for that the LONGPTR_T helper-macro, which has either
scalar-size of 'long' type, or
of 'long long' type's size, if pointer is larger then scalar-size of
'long' type.
ChangeLog
2012-12-21 Kai Tietz
* rtti.c (LONGPTR_T): New helper-macro.
(get_pseudo_ti_init): Initialize offset_type by LONGPTR_T
type instead of 'long' type.
(create_tinfo_types): Use for offset/flags field LONGPTR_T
type instead of 'long' type.
Tested for x86_64-w64-mingw32, i686-w64-mingw32, and
x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
Index: rtti.c
===
--- rtti.c (Revision 194660)
+++ rtti.c (Arbeitskopie)
@@ -89,6 +89,12 @@ typedef enum tinfo_kind
/* ... abi::__vmi_type_info */
} tinfo_kind;
+/* Helper macro to get maximum scalar-width of pointer or of the 'long'-type.
+ This of interest for llp64 targets. */
+#define LONGPTR_T \
+ integer_types[(POINTER_SIZE <= TYPE_PRECISION (integer_types[itk_long]) \
+? itk_long : itk_long_long)]
+
/* A vector of all tinfo decls that haven't yet been emitted. */
vec *unemitted_tinfo_decls;
@@ -1116,7 +1122,7 @@ get_pseudo_ti_init (tree type, unsigned tk_index)
tree binfo = TYPE_BINFO (type);
int nbases = BINFO_N_BASE_BINFOS (binfo);
vec *base_accesses = BINFO_BASE_ACCESSES (binfo);
- tree offset_type = integer_types[itk_long];
+ tree offset_type = LONGPTR_T;
tree base_inits = NULL_TREE;
int ix;
vec *init_vec = NULL;
@@ -1413,14 +1419,15 @@ create_tinfo_types (void)
/* Base class internal helper. Pointer to base type, offset to base,
flags. */
{
-tree field, fields;
+tree field, fields, offset_flags_type;
field = build_decl (BUILTINS_LOCATION,
FIELD_DECL, NULL_TREE, type_info_ptr_type);
fields = field;
+offset_flags_type = LONGPTR_T;
field = build_decl (BUILTINS_LOCATION,
- FIELD_DECL, NULL_TREE, integer_types[itk_long]);
+ FIELD_DECL, NULL_TREE, offset_flags_type);
DECL_CHAIN (field) = fields;
fields = field;
[PATCH] Fix PR52966 - do not bypass loop headers
This patch widens the scope of the PR54838 fix (and reverts one
of my earlier kludges). Like on the GIMPLE level threading
an edge through a loop header is seldomly a good idea as it may
create multiple-entry loops (not handled at all), create
irreducible regions (not handled at all).
In theory threading the latch is possible (see the hoops
tree-ssa-threadupdate.c jumps through). But instead of
replicating all this on RTL the easiest thing is to simply
not thread through loop headers when loops are to be preserved.
It again unleashes the full powers before earlier patches
when loops are not preserved (there is at least one rtl-cprop
pass after rtl loop opts).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
I've committed the testcase already as I wasn't able to reproduce
the issue (had a local patch to fix it ...).
Thanks,
Richard.
2012-12-21 Richard Biener
PR rtl-optimization/52996
* cprop.c (bypass_block): When loops are to be preserved
do not bypass loop headers. Revert earlier kludge to remove
loops when doing that.
Index: gcc/cprop.c
===
*** gcc/cprop.c (revision 194658)
--- gcc/cprop.c (working copy)
*** bypass_block (basic_block bb, rtx setcc,
*** 1496,1502
rtx insn, note;
edge e, edest;
int change;
! int may_be_loop_header;
unsigned removed_p;
unsigned i;
edge_iterator ei;
--- 1496,1502
rtx insn, note;
edge e, edest;
int change;
! int may_be_loop_header = false;
unsigned removed_p;
unsigned i;
edge_iterator ei;
*** bypass_block (basic_block bb, rtx setcc,
*** 1510,1536
if (note)
find_used_regs (&XEXP (note, 0), NULL);
- /* Determine whether there are more latch edges. Threading through
- a loop header with more than one latch is delicate, see e.g.
- tree-ssa-threadupdate.c:thread_through_loop_header. */
if (current_loops)
{
! may_be_loop_header = bb == bb->loop_father->header;
! if (may_be_loop_header
! && bb->loop_father->latch == NULL)
return 0;
}
else
{
- unsigned n_back_edges = 0;
FOR_EACH_EDGE (e, ei, bb->preds)
if (e->flags & EDGE_DFS_BACK)
! n_back_edges++;
!
! may_be_loop_header = n_back_edges > 0;
!
! if (n_back_edges > 1)
! return 0;
}
change = 0;
--- 1510,1531
if (note)
find_used_regs (&XEXP (note, 0), NULL);
if (current_loops)
{
! /* If we are to preserve loop structure then do not bypass
! a loop header. This will either rotate the loop, create
!multiple entry loops or even irreducible regions. */
! if (bb == bb->loop_father->header)
return 0;
}
else
{
FOR_EACH_EDGE (e, ei, bb->preds)
if (e->flags & EDGE_DFS_BACK)
! {
! may_be_loop_header = true;
! break;
! }
}
change = 0;
*** bypass_block (basic_block bb, rtx setcc,
*** 1619,1635
&& dest != old_dest
&& dest != EXIT_BLOCK_PTR)
{
- if (current_loops != NULL
- && e->src->loop_father->latch == e->src)
- {
- /* ??? Now we are creating (or may create) a loop
-with multiple entries. Simply mark it for
-removal. Alternatively we could not do this
-threading. */
- e->src->loop_father->header = NULL;
- e->src->loop_father->latch = NULL;
- }
-
redirect_edge_and_branch_force (e, dest);
/* Copy the register setter to the redirected edge.
--- 1614,1619
[PATCH] Fix PR54659, include gmp.h from system.h
After the Ada fix including gmp.h from system.h is trivial
(by means of double-int.h it was included from almost everywhere
already)
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Ok for trunk? (Go frontend "unfixed")
Thanks,
Richard.
2012-12-21 Richard Biener
PR bootstrap/54659
* system.h: Include gmp.h.
* tree-ssa-loop-niter.c: Do not include gmp.h here.
* double-int.h: Likewise.
* realmpfr.h: Likewise.
fortran/
* gfortran.h: Do not include gmp.h here.
Index: gcc/tree-ssa-loop-niter.c
===
*** gcc/tree-ssa-loop-niter.c (revision 194659)
--- gcc/tree-ssa-loop-niter.c (working copy)
*** along with GCC; see the file COPYING3.
*** 38,44
#include "flags.h"
#include "diagnostic-core.h"
#include "tree-inline.h"
- #include "gmp.h"
#define SWAP(X, Y) do { affine_iv *tmp = (X); (X) = (Y); (Y) = tmp; } while
(0)
--- 38,43
Index: gcc/double-int.h
===
*** gcc/double-int.h(revision 194659)
--- gcc/double-int.h(working copy)
*** along with GCC; see the file COPYING3.
*** 20,29
#ifndef DOUBLE_INT_H
#define DOUBLE_INT_H
- #ifndef GENERATOR_FILE
- #include
- #endif
-
/* A large integer is currently represented as a pair of HOST_WIDE_INTs.
It therefore represents a number with precision of
2 * HOST_BITS_PER_WIDE_INT bits (it is however possible that the
--- 20,25
Index: gcc/fortran/gfortran.h
===
*** gcc/fortran/gfortran.h (revision 194659)
--- gcc/fortran/gfortran.h (working copy)
*** gfc_intrinsic_sym;
*** 1699,1705
EXPR_COMPCALL Function (or subroutine) call of a procedure pointer
component or type-bound procedure. */
- #include
#include
#include
#define GFC_RND_MODE GMP_RNDN
--- 1699,1704
Index: gcc/realmpfr.h
===
*** gcc/realmpfr.h (revision 194659)
--- gcc/realmpfr.h (working copy)
***
*** 22,28
#ifndef GCC_REALGMP_H
#define GCC_REALGMP_H
- #include
#include
#include
#include "real.h"
--- 22,27
Index: gcc/system.h
===
*** gcc/system.h(revision 194660)
--- gcc/system.h(working copy)
*** extern int vsnprintf(char *, size_t, con
*** 638,643
--- 638,645
#include
#endif
+ #include
+
/* Get libiberty declarations. */
#include "libiberty.h"
Re: [PATCH] Fix PR54659, include gmp.h from system.h
On Fri, Dec 21, 2012 at 02:14:37PM +0100, Richard Biener wrote: > After the Ada fix including gmp.h from system.h is trivial > (by means of double-int.h it was included from almost everywhere > already) > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > Ok for trunk? (Go frontend "unfixed") Yes, thanks. Jakub
[asan] Fix asan -fsection-anchors handling
Hi!
Peter reported on IRC that many asan tests are failing on ppc, apparently
lots of that is related to -fsection-anchors decls and STRING_CSTs, which
weren't considered before.
This patch attempts to fix all the issues I saw on the few testcases.
Bootstrapped/regtested on x86_64-linux and i686-linux and eyeballed
global-overflow-1.c and some other small testcase with a -> powerpc64-linux
cross-compiler. Ok for trunk?
2012-12-21 Jakub Jelinek
* varasm.c (output_constant_def_contents): For asan_protect_global
protected strings, adjust DECL_ALIGN if needed, before testing for
anchored symbols.
(place_block_symbol): Adjust size for asan protected STRING_CSTs if
TREE_CONSTANT_POOL_ADDRESS_P. Increase alignment for asan protected
normal decls.
(output_object_block): For asan protected decls, emit asan padding
after their contents.
(asan_protect_global): Don't check TREE_ASM_WRITTEN here.
(asan_finish_file): Test it here instead.
--- gcc/varasm.c.jj 2012-12-20 19:10:19.856526720 +0100
+++ gcc/varasm.c2012-12-21 10:37:44.481999545 +0100
@@ -3252,6 +3252,7 @@ output_constant_def_contents (rtx symbol
tree decl = SYMBOL_REF_DECL (symbol);
tree exp = DECL_INITIAL (decl);
unsigned int align;
+ bool asan_protected = false;
/* Make sure any other constants whose addresses appear in EXP
are assigned label numbers. */
@@ -3260,6 +3261,14 @@ output_constant_def_contents (rtx symbol
/* We are no longer deferring this constant. */
TREE_ASM_WRITTEN (decl) = TREE_ASM_WRITTEN (exp) = 1;
+ if (flag_asan && TREE_CODE (exp) == STRING_CST
+ && asan_protect_global (exp))
+{
+ asan_protected = true;
+ DECL_ALIGN (decl) = MAX (DECL_ALIGN (decl),
+ ASAN_RED_ZONE_SIZE * BITS_PER_UNIT);
+}
+
/* If the constant is part of an object block, make sure that the
decl has been positioned within its block, but do not write out
its definition yet. output_object_blocks will do that later. */
@@ -3267,15 +3276,8 @@ output_constant_def_contents (rtx symbol
place_block_symbol (symbol);
else
{
- bool asan_protected = false;
align = DECL_ALIGN (decl);
switch_to_section (get_constant_section (exp, align));
- if (flag_asan && TREE_CODE (exp) == STRING_CST
- && asan_protect_global (exp))
- {
- asan_protected = true;
- align = MAX (align, ASAN_RED_ZONE_SIZE * BITS_PER_UNIT);
- }
if (align > BITS_PER_UNIT)
ASM_OUTPUT_ALIGN (asm_out_file, floor_log2 (align / BITS_PER_UNIT));
assemble_constant_contents (exp, XSTR (symbol, 0), align);
@@ -6968,6 +6970,10 @@ place_block_symbol (rtx symbol)
decl = SYMBOL_REF_DECL (symbol);
alignment = DECL_ALIGN (decl);
size = get_constant_size (DECL_INITIAL (decl));
+ if (flag_asan
+ && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST
+ && asan_protect_global (DECL_INITIAL (decl)))
+ size += asan_red_zone_size (size);
}
else
{
@@ -6975,7 +6981,11 @@ place_block_symbol (rtx symbol)
alignment = DECL_ALIGN (decl);
size = tree_low_cst (DECL_SIZE_UNIT (decl), 1);
if (flag_asan && asan_protect_global (decl))
- size += asan_red_zone_size (size);
+ {
+ size += asan_red_zone_size (size);
+ alignment = MAX (alignment,
+ ASAN_RED_ZONE_SIZE * BITS_PER_UNIT);
+ }
}
/* Calculate the object's offset from the start of the block. */
@@ -7114,16 +7124,34 @@ output_object_block (struct object_block
}
else if (TREE_CONSTANT_POOL_ADDRESS_P (symbol))
{
+ HOST_WIDE_INT size;
decl = SYMBOL_REF_DECL (symbol);
assemble_constant_contents (DECL_INITIAL (decl), XSTR (symbol, 0),
DECL_ALIGN (decl));
- offset += get_constant_size (DECL_INITIAL (decl));
+ size = get_constant_size (DECL_INITIAL (decl));
+ offset += size;
+ if (flag_asan
+ && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST
+ && asan_protect_global (DECL_INITIAL (decl)))
+ {
+ size = asan_red_zone_size (size);
+ assemble_zeros (size);
+ offset += size;
+ }
}
else
{
+ HOST_WIDE_INT size;
decl = SYMBOL_REF_DECL (symbol);
assemble_variable_contents (decl, XSTR (symbol, 0), false);
- offset += tree_low_cst (DECL_SIZE_UNIT (decl), 1);
+ size = tree_low_cst (DECL_SIZE_UNIT (decl), 1);
+ offset += size;
+ if (flag_asan && asan_protect_global (decl))
+ {
+ size = asan_red_zone_size (size);
+ assemble_zeros (size);
+ offset += size;
+ }
}
}
}
--- gcc/asan.c.jj 2012-12-20 11:38:14.0 +0100
+++ gcc/asan.c 20
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
On Fri, Dec 21, 2012 at 1:59 AM, Kai Tietz wrote:
> Hello,
>
> this patch fixes some remaining issues with pointer-sizes for llp64
> abi in libstdc++.
See comments below.
>
> ChangeLog
>
> 2012-12-21 Kai Tietz
>
> * config/os/mingw32/os_defines.h (_GLIBCXX_LLP64): Define if llp64
> abi is used.
> * config/os/mingw32-w64/os_defines.h: Likewise.
> * libsupc++/cxxabi.h (__base_class_type_info): Change
> type __offset_flags to intptr_t.
> * libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define proper
> for llp64 abi.
> (EMERGENCY_OBJ_COUNT): Likewise.
> (bitmask_type): Likewise.
> * ibsupc++/hash_bytes.cc (_Hash_bytes): Handle llp64.
>
> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-linux-gnu. Ok for apply?
>
> Regards,
> Kai
>
> Index: config/os/mingw32/os_defines.h
> ===
> --- config/os/mingw32/os_defines.h (Revision 194655)
> +++ config/os/mingw32/os_defines.h (Arbeitskopie)
> @@ -72,4 +72,8 @@
> #define _GLIBCXX_CDTOR_CALLABI __thiscall
> #endif
>
> +#ifdef __x86_64__
> +#define _GLIBCXX_LLP64 1
> #endif
> +
> +#endif
> Index: config/os/mingw32-w64/os_defines.h
> ===
> --- config/os/mingw32-w64/os_defines.h (Revision 194655)
> +++ config/os/mingw32-w64/os_defines.h (Arbeitskopie)
> @@ -74,4 +74,8 @@
> #define _GLIBCXX_CDTOR_CALLABI __thiscall
> #endif
>
> +#ifdef __x86_64__
> +#define _GLIBCXX_LLP64 1
> #endif
> +
> +#endif
> Index: libsupc++/cxxabi.h
> ===
> --- libsupc++/cxxabi.h (Revision 194655)
> +++ libsupc++/cxxabi.h (Arbeitskopie)
> @@ -356,7 +356,7 @@ namespace __cxxabiv1
>{
>public:
> const __class_type_info* __base_type; // Base class type.
> -long __offset_flags; // Offset and info.
> +intptr_t __offset_flags; // Offset and info.
this should use ptrdiff_t.
>
> enum __offset_flags_masks
>{
> Index: libsupc++/eh_alloc.cc
> ===
> --- libsupc++/eh_alloc.cc (Revision 194655)
> +++ libsupc++/eh_alloc.cc (Arbeitskopie)
> @@ -60,7 +60,7 @@ using namespace __cxxabiv1;
> #if INT_MAX == 32767
> # define EMERGENCY_OBJ_SIZE128
> # define EMERGENCY_OBJ_COUNT 16
> -#elif LONG_MAX == 2147483647
> +#elif !defined (_GLIBCXX_LLP64) && LONG_MAX == 2147483647
> # define EMERGENCY_OBJ_SIZE512
> # define EMERGENCY_OBJ_COUNT 32
> #else
> @@ -76,8 +76,12 @@ using namespace __cxxabiv1;
> #if INT_MAX == 32767 || EMERGENCY_OBJ_COUNT <= 32
> typedef unsigned int bitmask_type;
> #else
> +#if defined (_GLIBCXX_LLP64)
> +typedef unsigned long long bitmask_type;
> +#else
> typedef unsigned long bitmask_type;
> #endif
> +#endif
Use size_t here
>
>
> typedef char one_buffer[EMERGENCY_OBJ_SIZE] __attribute__((aligned));
> Index: libsupc++/hash_bytes.cc
> ===
> --- libsupc++/hash_bytes.cc (Revision 194655)
> +++ libsupc++/hash_bytes.cc (Arbeitskopie)
> @@ -128,7 +128,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>size_t
>_Hash_bytes(const void* ptr, size_t len, size_t seed)
>{
> -static const size_t mul = (0xc6a4a793UL << 32UL) + 0x5bd1e995UL;
> +static const size_t mul = (((size_t) 0xc6a4a793UL) << 32UL)
> + + (size_t) 0x5bd1e995UL;
> const char* const buf = static_cast(ptr);
>
> // Remove the bytes not divisible by the sizeof(size_t). This
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
On Fri, Dec 21, 2012 at 3:48 AM, Kai Tietz wrote: > 2012/12/21 Paolo Carlini : >> On 12/21/2012 10:36 AM, Kai Tietz wrote: >>> >>> well, issue isn't that 'long' is always 'ptrdiff_t'. >> >> But then, if we just change the type without paying attention to size (and >> alignment) aren't we looking for BIG ABI trouble?!? > > Huh? We have ABI-trouble due long is too small to hold a > pointer-diff for llp64. Intended is here 'pointer-size' AFAICS in > code, but with wrong assumption that a 'long' is always long enough. > > Btw I just checked all targets we have right now in gcc. The type > ptrdiff_t is always either 'long', or 'int' (ilp32, lp64), and 'long > long' for LLP64. Means ptrdiff_t gets always equal (or bigger) to > biggest pointer-size for target (AFAICS). > > Kai We must write the codes so that their intents are clear, without requiring lot of reverse engineering every time one looks at them. If we intend offset, then clearly ptrdiff_t is the first choice. Solid reasons must be provided why it can't be ptrdiff_t and such reasons must be part of the code as comments explaining why the obvious thing should be discounted. - Gaby
Re: [PATCH] PR c++/52343 - error with alias template as template template argument
The example is valid, but I am not sure I understand your explanation... -- Gaby
Re: [Patch, libgomp] libgomp.fortran/fortran.exp - add -fintrinsic-modules-path ${blddir}
This change introduced a large number of failures on AIX of the form: cannot specify -o with -c, -S or -E with multiple files during the execution of collect2-ld Note that all of the tests are run with the "gcc" driver, not the "gfortran" driver. If I use gfortran, every thing is okay. I still am unsure about the cause in gcc.c, but lang_n_infiles is being incremented to 2. I think it is related to the difference between the invoked compiler and the language compiler. Thanks, David
Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
2012/12/21 Gabriel Dos Reis : > On Fri, Dec 21, 2012 at 3:48 AM, Kai Tietz wrote: >> 2012/12/21 Paolo Carlini : >>> On 12/21/2012 10:36 AM, Kai Tietz wrote: well, issue isn't that 'long' is always 'ptrdiff_t'. >>> >>> But then, if we just change the type without paying attention to size (and >>> alignment) aren't we looking for BIG ABI trouble?!? >> >> Huh? We have ABI-trouble due long is too small to hold a >> pointer-diff for llp64. Intended is here 'pointer-size' AFAICS in >> code, but with wrong assumption that a 'long' is always long enough. >> >> Btw I just checked all targets we have right now in gcc. The type >> ptrdiff_t is always either 'long', or 'int' (ilp32, lp64), and 'long >> long' for LLP64. Means ptrdiff_t gets always equal (or bigger) to >> biggest pointer-size for target (AFAICS). >> >> Kai > > We must write the codes so that their intents are clear, without > requiring lot of reverse engineering every time one looks at them. If we > intend offset, then clearly ptrdiff_t is the first choice. Solid > reasons must be provided why it can't be ptrdiff_t and such > reasons must be part of the code as comments explaining why > the obvious thing should be discounted. > > - Gaby Agreed that we are using at some place too complex logic to avoid standard-types we already have ... We need to modify for cxxabi.h header-change also cp/rtti.c, as here the 'long' type-assumption is done, too. instead of using integer_type[itk_long/itk_long_long] there we then have to use instead ptrdiff_type_node. And this is for some targets a possible ABI-change due type_info-record might change size ... for 4.9 this change looks suitable to me, but for 4.8 we should simply check for now for itk_long/itk_long_long here (as done by other patch I've sent). Kai
Re: [PATCH] Fix PR54659, include gmp.h from system.h
On Fri, Dec 21, 2012 at 5:14 AM, Richard Biener wrote: > > After the Ada fix including gmp.h from system.h is trivial > (by means of double-int.h it was included from almost everywhere > already) > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > Ok for trunk? (Go frontend "unfixed") Fixed like so. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2012-12-21 Ian Lance Taylor PR bootstrap/54659 * go-system.h: Don't include . foo.patch Description: Binary data
Re: [Patch, libgomp] libgomp.fortran/fortran.exp - add -fintrinsic-modules-path ${blddir}
On Fri, Dec 21, 2012 at 10:50:26AM -0500, David Edelsohn wrote: > This change introduced a large number of failures on AIX of the form: > > cannot specify -o with -c, -S or -E with multiple files > > during the execution of collect2-ld > > Note that all of the tests are run with the "gcc" driver, not the > "gfortran" driver. If I use gfortran, every thing is okay. > > I still am unsure about the cause in gcc.c, but lang_n_infiles is > being incremented to 2. I think it is related to the difference > between the invoked compiler and the language compiler. Do you happen to use spaces or similar problematic characters in the build directory path? Can you paste some command line from libgomp.log? Jakub
Re: [PATCH] PR c++/52343 - error with alias template as template template argument
Gabriel Dos Reis writes:
> The example is valid, but I am not sure I understand your
> explanation...
Ah, sorry. I realize just now that I haven't mentioned the initial
erratic behaviour. Maybe that could have made my message easier to
understand.
So consider the test case of the message:
1 template
2 using A = int;
3
4 template class>
5 struct B {};
6
7 B b;
test.cc:7:4: error: integral expression ‘A’ is not constant
B b;
^
Followed by some irrelevant other error messages.
As I was saying my earlier message, here, the TREE_TYPE of the
template_decl A is an integer; so check_instantiated_arg takes it as
if A is an integer value (a decl with integer type), and thus, should
be a constant.
The fix I am proposing is just to allow check_instantiated_arg to make
the difference between a classical integer decl, and an alias template
which type-id is an integer.
--
Dodji
Re: [PATCH] Fix PR54659, include gmp.h from system.h
I think revision 194665 breaks bootstrap on at least x86_64-apple-darwin10: g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../_clean/gcc -I../../_clean/gcc/build -I../../_clean/gcc/../include -I./../intl -I../../_clean/gcc/../libcpp/include -I/opt/mp/include -I../../_clean/gcc/../libdecnumber -I../../_clean/gcc/../libdecnumber/dpd -I../libdecnumber -I../../_clean/gcc/../libbacktrace -DCLOOG_INT_GMP -I/opt/mp/include \ -o build/genconstants.o ../../_clean/gcc/genconstants.c In file included from ./bconfig.h:3:0, from ../../_clean/gcc/genconstants.c:28: ./auto-host.h:1994:16: error: declaration does not declare anything [-fpermissive] #define rlim_t long ^ In file included from ../../_clean/gcc/genconstants.c:29:0: ../../_clean/gcc/system.h:502:34: error: declaration of C function 'const char* strsignal(int)' conflicts with extern const char *strsignal (int); ^ In file included from /opt/gcc/gcc4.8a/include/c++/4.8.0/cstring:44:0, from ../../_clean/gcc/system.h:207, from ../../_clean/gcc/genconstants.c:29: /usr/include/string.h:136:7: error: previous declaration 'char* strsignal(int)' here char *strsignal(int sig); ^ TIA Dominique
Re: [google 4.7] fdo build for linux kernel (issue6968046)
On Wed, Dec 19, 2012 at 12:11 PM, Rong Xu wrote:
> Hi,
>
> This patch updates the support for FDO build in linux kernel for gcc 4.7.
> Tested with 2.6.34 kernel and google internal benchmarks.
>
> Thanks,
>
> -Rong
>
> 2012-12-19 Rong Xu
>
> * libgcc/libgcov.c
> (gcov_counter_active): v4.7 kernel fdo support.
> (crc32_unsigned): Include in GCOV_KERNEL build.
> (gcov_alloc_filename): Remove from GCOV_KERNEL build.
> (gcov_sort_icall_topn_counter): Ditto.
> (gcov_dump_module_info): Ditto.
> (gcov_compute_histogram): v4.7 kernel fdo support.
> (gcov_merge_gcda_file): Ditto.
> (gcov_gcda_file_size): Ditto.
> (gcov_write_gcda_file): Ditto.
> (__gcov_topn_value_profiler_body): Ditto.
> (gcov_set_vfile): Ditto.
> (gcov_kernel_dump_gcov_init): Ditto.
> (gcov_kernel_dump_one_gcov): Ditto.
> * gcc/gcov-io.c (gcov_read_string): Ditto.
> (static int k_popcountll): Ditto.
> (gcov_read_summary): Ditto.
> (kernel_file_fclose): Ditto.
> (kernel_file_ftell): Ditto.
> (kernel_file_fwrite): Ditto.
> * gcc/gcov-io.h (struct gcov_info): remove const keyword.
>
> Index: libgcc/libgcov.c
> ===
> --- libgcc/libgcov.c(revision 194562)
> +++ libgcc/libgcov.c(working copy)
> @@ -46,11 +46,11 @@ see the files COPYING3 and COPYING.RUNTIME respect
> #include "tsystem.h"
> #include "coretypes.h"
> #include "tm.h"
> -#endif /* __KERNEL__ */
> #include "libgcc_tm.h"
> #include "gthr.h"
> +#endif /* __KERNEL__ */
>
> -#if 1
> +#ifndef __KERNEL__
> #define THREAD_PREFIX __thread
> #else
> #define THREAD_PREFIX
> @@ -120,6 +120,7 @@ extern int gcov_dump_complete ATTRIBUTE_HIDDEN;
> #ifdef L_gcov
> #include "gcov-io.c"
>
> +#ifndef __GCOV_KERNEL__
> /* Create a strong reference to these symbols so that they are
> unconditionally pulled into the instrumented binary, even when
> the only reference is a weak reference. This is necessary because
> @@ -134,6 +135,7 @@ extern int gcov_dump_complete ATTRIBUTE_HIDDEN;
> these symbols will always need to be resolved. */
> void (*__gcov_dummy_ref1)() = &__gcov_reset;
> void (*__gcov_dummy_ref2)() = &__gcov_dump;
> +#endif /* __GCOV_KERNEL__ */
>
> /* Utility function for outputing errors. */
> static int
> @@ -151,6 +153,10 @@ gcov_error (const char *fmt, ...)
>return ret;
> }
>
> +/* A program checksum allows us to distinguish program data for an
> + object file included in multiple programs. */
> +static gcov_unsigned_t gcov_crc32;
> +
> #ifndef __GCOV_KERNEL__
> /* Emitted in coverage.c. */
> extern char * __gcov_pmu_profile_filename;
> @@ -183,10 +189,6 @@ THREAD_PREFIX gcov_unsigned_t __gcov_sample_counte
> /* Chain of per-object gcov structures. */
> extern struct gcov_info *__gcov_list;
>
> -/* A program checksum allows us to distinguish program data for an
> - object file included in multiple programs. */
> -static gcov_unsigned_t gcov_crc32;
> -
> /* Size of the longest file name. */
> static size_t gcov_max_filename = 0;
>
> @@ -323,8 +325,6 @@ gcov_counter_active (const struct gcov_info *info,
>return (info->merge[type] != 0);
> }
>
> -#ifndef __GCOV_KERNEL__
> -
> /* Add an unsigned value to the current crc */
>
> static gcov_unsigned_t
> @@ -344,6 +344,8 @@ crc32_unsigned (gcov_unsigned_t crc32, gcov_unsign
>return crc32;
> }
>
> +#ifndef __GCOV_KERNEL__
> +
> /* Check if VERSION of the info block PTR matches libgcov one.
> Return 1 on success, or zero in case of versions mismatch.
> If FILENAME is not NULL, its value used for reporting purposes
> @@ -464,6 +466,8 @@ gcov_alloc_filename (void)
>gi_filename_up = gi_filename + prefix_length;
> }
>
> +#endif /* __GCOV_KERNEL__ */
> +
> /* Sort N entries in VALUE_ARRAY in descending order.
> Each entry in VALUE_ARRAY has two values. The sorting
> is based on the second value. */
> @@ -509,6 +513,8 @@ gcov_sort_icall_topn_counter (const struct gcov_ct
> }
> }
>
> +#ifndef __GCOV_KERNEL__
> +
> /* Write imported files (auxiliary modules) for primary module GI_PTR
> into file GI_FILENAME. */
>
> @@ -586,6 +592,8 @@ gcov_dump_module_info (void)
>__gcov_finalize_dyn_callgraph ();
> }
>
> +#endif /* __GCOV_KERNEL__ */
> +
> /* Insert counter VALUE into HISTOGRAM. */
>
> static void
> @@ -656,6 +664,8 @@ gcov_compute_histogram (struct gcov_summary *sum)
> }
> }
>
> +#ifndef __GCOV_KERNEL__
> +
> /* Dump the coverage counts. We merge with existing counts when
> possible, to avoid growing the .da files ad infinitum. We use this
> program's checksum to make sure we only accumulate whole program
> @@ -1013,12 +1023,7 @@ gcov_merge_gcda_file (struct gcov_info *gi_ptr)
> goto read_error;
> }
> if (tag && tag != GCOV_TAG_MODULE_INFO)
> - {
> - read_mismatch:;
Re: [Patch, libgomp] libgomp.fortran/fortran.exp - add -fintrinsic-modules-path ${blddir}
Jakub, I deleted the directory that failed and commented out that option for last nights bootstrap. I can't reproduce the failure today when I restore the option. I wonder if there is a race condition with parallel check. I will continue to monitor it. Thanks, David On Fri, Dec 21, 2012 at 11:07 AM, Jakub Jelinek wrote: > On Fri, Dec 21, 2012 at 10:50:26AM -0500, David Edelsohn wrote: >> This change introduced a large number of failures on AIX of the form: >> >> cannot specify -o with -c, -S or -E with multiple files >> >> during the execution of collect2-ld >> >> Note that all of the tests are run with the "gcc" driver, not the >> "gfortran" driver. If I use gfortran, every thing is okay. >> >> I still am unsure about the cause in gcc.c, but lang_n_infiles is >> being incremented to 2. I think it is related to the difference >> between the invoked compiler and the language compiler. > > Do you happen to use spaces or similar problematic characters in the build > directory path? > Can you paste some command line from libgomp.log? > > Jakub
[Patch, Fortran] PR 54884 - Fix TREE_PUBLIC() issue with PRIVATE module procedures
General background: Private module variables and module procedures can
be marked as TREE_PUBLIC()= 0, unless they are used in the specification
expression of the dummy argument or result variable of public module
procedures (or private module procedures in public generic interfaces).
That gives a lot of optimization possibilities. However, it is not
trivial to get it right. The current version has resolve_function:
3128 if (sym && specification_expr && sym->attr.function
3129 && gfc_current_ns->proc_name
3130 && gfc_current_ns->proc_name->attr.flavor == FL_MODULE)
3131sym->attr.public_used = 1;
That fails if one does not operate on a result variable but on a dummy
argument, which might be not at ns->proc_name but at ns->parent->proc_name.
The attached patch tried to fix the 4.8 regression without breaking the
existing test cases.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
PS: I start to understand why other compilers don't do it.
2012-12-21 Tobias Burnus
PR fortran/54884
* resolve.c (spec_expr_mod_proc): New static variable.
(resolve_formal_arglist, resolve_function, resolve_variable,
resolve_charlen, resolve_fl_variable, resolve_symbol): Use
it to decide when to mark a symbol as public_use.
2012-12-21 Tobias Burnus
PR fortran/54884
* gfortran.dg/public_private_module_8.f90: New.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index fce6f73..95cc4de 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -83,6 +83,10 @@ static int formal_arg_flag = 0;
/* True if we are resolving a specification expression. */
static bool specification_expr = false;
+/* True if we are resolving the specification expression of a module
+ procedure's result or dummy variable; used for the public_use setting. */
+static bool spec_expr_mod_proc = false;
+
/* The id of the last entry seen. */
static int current_entry_id;
@@ -278,7 +282,7 @@ resolve_formal_arglist (gfc_symbol *proc)
{
gfc_formal_arglist *f;
gfc_symbol *sym;
- bool saved_specification_expr;
+ bool saved_specification_expr, saved_spec_expr_mod_proc;
int i;
if (proc->result != NULL)
@@ -339,8 +343,19 @@ resolve_formal_arglist (gfc_symbol *proc)
saved_specification_expr = specification_expr;
specification_expr = true;
+ saved_spec_expr_mod_proc = spec_expr_mod_proc;
+ if ((sym->attr.dummy || sym->attr.result || sym->attr.function)
+ && ((sym == sym->result && sym->ns->proc_name
+ && sym->ns->proc_name->attr.flavor == FL_MODULE)
+ || (sym != sym->result && sym->ns->parent
+ && sym->ns->parent->proc_name
+ && sym->ns->parent->proc_name->attr.flavor == FL_MODULE)))
+ spec_expr_mod_proc = true;
+
gfc_resolve_array_spec (as, 0);
+
specification_expr = saved_specification_expr;
+ spec_expr_mod_proc = saved_spec_expr_mod_proc;
/* We can't tell if an array with dimension (:) is assumed or deferred
shape until we know if it has the pointer or allocatable attributes.
@@ -3129,12 +3144,13 @@ resolve_function (gfc_expr *expr)
return FAILURE;
}
- if (sym && specification_expr && sym->attr.function
- && gfc_current_ns->proc_name
- && gfc_current_ns->proc_name->attr.flavor == FL_MODULE)
+ if (sym && spec_expr_mod_proc && sym->attr.function
+ && ((gfc_current_ns->proc_name
+ && gfc_current_ns->proc_name->attr.flavor == FL_MODULE)
+ || (gfc_current_ns->parent && gfc_current_ns->parent->proc_name
+ && gfc_current_ns->parent->proc_name->attr.flavor == FL_MODULE)))
sym->attr.public_used = 1;
-
/* Switch off assumed size checking and do this again for certain kinds
of procedure, once the procedure itself is resolved. */
need_full_assumed_size++;
@@ -5363,14 +5379,15 @@ resolve_variable (gfc_expr *e)
/* If a PRIVATE variable is used in the specification expression of the
result variable, it might be accessed from outside the module and can
thus not be TREE_PUBLIC() = 0.
- TODO: sym->attr.public_used only has to be set for the result variable's
- type-parameter expression and not for dummies or automatic variables.
- Additionally, it only has to be set if the function is either PUBLIC or
- used in a generic interface or TBP; unfortunately,
+ TODO: sym->attr.public_used only has to be set if the function is
+ either PUBLIC or used in a generic interface or TBP; unfortunately,
proc_name->attr.public_used can get set at a later stage. */
- if (specification_expr && sym->attr.access == ACCESS_PRIVATE
+ if (spec_expr_mod_proc
&& !sym->attr.function && !sym->attr.use_assoc
- && gfc_current_ns->proc_name && gfc_current_ns->proc_name->attr.function)
+ && ((gfc_current_ns->proc_name
+ && gfc_current_ns->proc_name->attr.flavor == FL_MODULE)
+ || (gfc_current_ns->parent && gfc_current_ns->parent->proc_name
+ && gfc_current_ns->parent->proc_name->attr.
Re: [google 4.7] fdo build for linux kernel (issue6968046)
Kernel build does not link in libgcc, which defines the function. David On Fri, Dec 21, 2012 at 8:31 AM, Teresa Johnson wrote: > On Wed, Dec 19, 2012 at 12:11 PM, Rong Xu wrote: >> Hi, >> >> This patch updates the support for FDO build in linux kernel for gcc 4.7. >> Tested with 2.6.34 kernel and google internal benchmarks. >> >> Thanks, >> >> -Rong >> >> 2012-12-19 Rong Xu >> >> * libgcc/libgcov.c >> (gcov_counter_active): v4.7 kernel fdo support. >> (crc32_unsigned): Include in GCOV_KERNEL build. >> (gcov_alloc_filename): Remove from GCOV_KERNEL build. >> (gcov_sort_icall_topn_counter): Ditto. >> (gcov_dump_module_info): Ditto. >> (gcov_compute_histogram): v4.7 kernel fdo support. >> (gcov_merge_gcda_file): Ditto. >> (gcov_gcda_file_size): Ditto. >> (gcov_write_gcda_file): Ditto. >> (__gcov_topn_value_profiler_body): Ditto. >> (gcov_set_vfile): Ditto. >> (gcov_kernel_dump_gcov_init): Ditto. >> (gcov_kernel_dump_one_gcov): Ditto. >> * gcc/gcov-io.c (gcov_read_string): Ditto. >> (static int k_popcountll): Ditto. >> (gcov_read_summary): Ditto. >> (kernel_file_fclose): Ditto. >> (kernel_file_ftell): Ditto. >> (kernel_file_fwrite): Ditto. >> * gcc/gcov-io.h (struct gcov_info): remove const keyword. >> >> Index: libgcc/libgcov.c >> === >> --- libgcc/libgcov.c(revision 194562) >> +++ libgcc/libgcov.c(working copy) >> @@ -46,11 +46,11 @@ see the files COPYING3 and COPYING.RUNTIME respect >> #include "tsystem.h" >> #include "coretypes.h" >> #include "tm.h" >> -#endif /* __KERNEL__ */ >> #include "libgcc_tm.h" >> #include "gthr.h" >> +#endif /* __KERNEL__ */ >> >> -#if 1 >> +#ifndef __KERNEL__ >> #define THREAD_PREFIX __thread >> #else >> #define THREAD_PREFIX >> @@ -120,6 +120,7 @@ extern int gcov_dump_complete ATTRIBUTE_HIDDEN; >> #ifdef L_gcov >> #include "gcov-io.c" >> >> +#ifndef __GCOV_KERNEL__ >> /* Create a strong reference to these symbols so that they are >> unconditionally pulled into the instrumented binary, even when >> the only reference is a weak reference. This is necessary because >> @@ -134,6 +135,7 @@ extern int gcov_dump_complete ATTRIBUTE_HIDDEN; >> these symbols will always need to be resolved. */ >> void (*__gcov_dummy_ref1)() = &__gcov_reset; >> void (*__gcov_dummy_ref2)() = &__gcov_dump; >> +#endif /* __GCOV_KERNEL__ */ >> >> /* Utility function for outputing errors. */ >> static int >> @@ -151,6 +153,10 @@ gcov_error (const char *fmt, ...) >>return ret; >> } >> >> +/* A program checksum allows us to distinguish program data for an >> + object file included in multiple programs. */ >> +static gcov_unsigned_t gcov_crc32; >> + >> #ifndef __GCOV_KERNEL__ >> /* Emitted in coverage.c. */ >> extern char * __gcov_pmu_profile_filename; >> @@ -183,10 +189,6 @@ THREAD_PREFIX gcov_unsigned_t __gcov_sample_counte >> /* Chain of per-object gcov structures. */ >> extern struct gcov_info *__gcov_list; >> >> -/* A program checksum allows us to distinguish program data for an >> - object file included in multiple programs. */ >> -static gcov_unsigned_t gcov_crc32; >> - >> /* Size of the longest file name. */ >> static size_t gcov_max_filename = 0; >> >> @@ -323,8 +325,6 @@ gcov_counter_active (const struct gcov_info *info, >>return (info->merge[type] != 0); >> } >> >> -#ifndef __GCOV_KERNEL__ >> - >> /* Add an unsigned value to the current crc */ >> >> static gcov_unsigned_t >> @@ -344,6 +344,8 @@ crc32_unsigned (gcov_unsigned_t crc32, gcov_unsign >>return crc32; >> } >> >> +#ifndef __GCOV_KERNEL__ >> + >> /* Check if VERSION of the info block PTR matches libgcov one. >> Return 1 on success, or zero in case of versions mismatch. >> If FILENAME is not NULL, its value used for reporting purposes >> @@ -464,6 +466,8 @@ gcov_alloc_filename (void) >>gi_filename_up = gi_filename + prefix_length; >> } >> >> +#endif /* __GCOV_KERNEL__ */ >> + >> /* Sort N entries in VALUE_ARRAY in descending order. >> Each entry in VALUE_ARRAY has two values. The sorting >> is based on the second value. */ >> @@ -509,6 +513,8 @@ gcov_sort_icall_topn_counter (const struct gcov_ct >> } >> } >> >> +#ifndef __GCOV_KERNEL__ >> + >> /* Write imported files (auxiliary modules) for primary module GI_PTR >> into file GI_FILENAME. */ >> >> @@ -586,6 +592,8 @@ gcov_dump_module_info (void) >>__gcov_finalize_dyn_callgraph (); >> } >> >> +#endif /* __GCOV_KERNEL__ */ >> + >> /* Insert counter VALUE into HISTOGRAM. */ >> >> static void >> @@ -656,6 +664,8 @@ gcov_compute_histogram (struct gcov_summary *sum) >> } >> } >> >> +#ifndef __GCOV_KERNEL__ >> + >> /* Dump the coverage counts. We merge with existing counts when >> possible, to avoid growing the .da files ad infinitum. We use this >>
Re: [google 4.7] fdo build for linux kernel (issue6968046)
On Fri, Dec 21, 2012 at 9:52 AM, Xinliang David Li wrote: > Kernel build does not link in libgcc, which defines the function. Then will the same issue occur with the reference to __builtin_clzll in gcov_histo_index in gcov-io.c? Teresa > > David > > On Fri, Dec 21, 2012 at 8:31 AM, Teresa Johnson wrote: >> On Wed, Dec 19, 2012 at 12:11 PM, Rong Xu wrote: >>> Hi, >>> >>> This patch updates the support for FDO build in linux kernel for gcc 4.7. >>> Tested with 2.6.34 kernel and google internal benchmarks. >>> >>> Thanks, >>> >>> -Rong >>> >>> 2012-12-19 Rong Xu >>> >>> * libgcc/libgcov.c >>> (gcov_counter_active): v4.7 kernel fdo support. >>> (crc32_unsigned): Include in GCOV_KERNEL build. >>> (gcov_alloc_filename): Remove from GCOV_KERNEL build. >>> (gcov_sort_icall_topn_counter): Ditto. >>> (gcov_dump_module_info): Ditto. >>> (gcov_compute_histogram): v4.7 kernel fdo support. >>> (gcov_merge_gcda_file): Ditto. >>> (gcov_gcda_file_size): Ditto. >>> (gcov_write_gcda_file): Ditto. >>> (__gcov_topn_value_profiler_body): Ditto. >>> (gcov_set_vfile): Ditto. >>> (gcov_kernel_dump_gcov_init): Ditto. >>> (gcov_kernel_dump_one_gcov): Ditto. >>> * gcc/gcov-io.c (gcov_read_string): Ditto. >>> (static int k_popcountll): Ditto. >>> (gcov_read_summary): Ditto. >>> (kernel_file_fclose): Ditto. >>> (kernel_file_ftell): Ditto. >>> (kernel_file_fwrite): Ditto. >>> * gcc/gcov-io.h (struct gcov_info): remove const keyword. >>> >>> Index: libgcc/libgcov.c >>> === >>> --- libgcc/libgcov.c(revision 194562) >>> +++ libgcc/libgcov.c(working copy) >>> @@ -46,11 +46,11 @@ see the files COPYING3 and COPYING.RUNTIME respect >>> #include "tsystem.h" >>> #include "coretypes.h" >>> #include "tm.h" >>> -#endif /* __KERNEL__ */ >>> #include "libgcc_tm.h" >>> #include "gthr.h" >>> +#endif /* __KERNEL__ */ >>> >>> -#if 1 >>> +#ifndef __KERNEL__ >>> #define THREAD_PREFIX __thread >>> #else >>> #define THREAD_PREFIX >>> @@ -120,6 +120,7 @@ extern int gcov_dump_complete ATTRIBUTE_HIDDEN; >>> #ifdef L_gcov >>> #include "gcov-io.c" >>> >>> +#ifndef __GCOV_KERNEL__ >>> /* Create a strong reference to these symbols so that they are >>> unconditionally pulled into the instrumented binary, even when >>> the only reference is a weak reference. This is necessary because >>> @@ -134,6 +135,7 @@ extern int gcov_dump_complete ATTRIBUTE_HIDDEN; >>> these symbols will always need to be resolved. */ >>> void (*__gcov_dummy_ref1)() = &__gcov_reset; >>> void (*__gcov_dummy_ref2)() = &__gcov_dump; >>> +#endif /* __GCOV_KERNEL__ */ >>> >>> /* Utility function for outputing errors. */ >>> static int >>> @@ -151,6 +153,10 @@ gcov_error (const char *fmt, ...) >>>return ret; >>> } >>> >>> +/* A program checksum allows us to distinguish program data for an >>> + object file included in multiple programs. */ >>> +static gcov_unsigned_t gcov_crc32; >>> + >>> #ifndef __GCOV_KERNEL__ >>> /* Emitted in coverage.c. */ >>> extern char * __gcov_pmu_profile_filename; >>> @@ -183,10 +189,6 @@ THREAD_PREFIX gcov_unsigned_t __gcov_sample_counte >>> /* Chain of per-object gcov structures. */ >>> extern struct gcov_info *__gcov_list; >>> >>> -/* A program checksum allows us to distinguish program data for an >>> - object file included in multiple programs. */ >>> -static gcov_unsigned_t gcov_crc32; >>> - >>> /* Size of the longest file name. */ >>> static size_t gcov_max_filename = 0; >>> >>> @@ -323,8 +325,6 @@ gcov_counter_active (const struct gcov_info *info, >>>return (info->merge[type] != 0); >>> } >>> >>> -#ifndef __GCOV_KERNEL__ >>> - >>> /* Add an unsigned value to the current crc */ >>> >>> static gcov_unsigned_t >>> @@ -344,6 +344,8 @@ crc32_unsigned (gcov_unsigned_t crc32, gcov_unsign >>>return crc32; >>> } >>> >>> +#ifndef __GCOV_KERNEL__ >>> + >>> /* Check if VERSION of the info block PTR matches libgcov one. >>> Return 1 on success, or zero in case of versions mismatch. >>> If FILENAME is not NULL, its value used for reporting purposes >>> @@ -464,6 +466,8 @@ gcov_alloc_filename (void) >>>gi_filename_up = gi_filename + prefix_length; >>> } >>> >>> +#endif /* __GCOV_KERNEL__ */ >>> + >>> /* Sort N entries in VALUE_ARRAY in descending order. >>> Each entry in VALUE_ARRAY has two values. The sorting >>> is based on the second value. */ >>> @@ -509,6 +513,8 @@ gcov_sort_icall_topn_counter (const struct gcov_ct >>> } >>> } >>> >>> +#ifndef __GCOV_KERNEL__ >>> + >>> /* Write imported files (auxiliary modules) for primary module GI_PTR >>> into file GI_FILENAME. */ >>> >>> @@ -586,6 +592,8 @@ gcov_dump_module_info (void) >>>__gcov_finalize_dyn_callgraph (); >>> } >>> >>> +#endif /* __GCOV_KERNEL__ */ >>> + >>> /* Insert counter V
Re: [asan] Fix asan -fsection-anchors handling
On Fri, 2012-12-21 at 15:15 +0100, Jakub Jelinek wrote: > Hi! > > Peter reported on IRC that many asan tests are failing on ppc, apparently > lots of that is related to -fsection-anchors decls and STRING_CSTs, which > weren't considered before. > > This patch attempts to fix all the issues I saw on the few testcases. > Bootstrapped/regtested on x86_64-linux and i686-linux and eyeballed > global-overflow-1.c and some other small testcase with a -> powerpc64-linux > cross-compiler. Ok for trunk? > > 2012-12-21 Jakub Jelinek > > * varasm.c (output_constant_def_contents): For asan_protect_global > protected strings, adjust DECL_ALIGN if needed, before testing for > anchored symbols. > (place_block_symbol): Adjust size for asan protected STRING_CSTs if > TREE_CONSTANT_POOL_ADDRESS_P. Increase alignment for asan protected > normal decls. > (output_object_block): For asan protected decls, emit asan padding > after their contents. > (asan_protect_global): Don't check TREE_ASM_WRITTEN here. > (asan_finish_file): Test it here instead. FYI, this bootstrapped/regtested with no errors on powerpc64-linux and fixes many of failures with the new asan test cases on powerpc*-linux. Thanks Jakub! Peter
Re: atomic update of profile counters (issue7000044)
On Fri, Dec 21, 2012 at 1:25 AM, Jan Hubicka wrote: >> Hi, >> >> This patch adds support of atomic update of profiles counters. The goal is >> to improve >> the poor counter values for highly thread programs. >> >> The atomic update is under a new option -fprofile-gen-atomic= >> N=0: default, no atomic update >> N=1: atomic update edge counters. >> N=2: atomic update some of value profile counters (currently indirect-call >> and one value profile). >> N=3: both edge counter and the above value profile counters. >> Other value: fall back to the default. >> >> This patch is a simple porting of the version in google-4_7 branch. It uses >> __atomic_fetch_add >> based on Andrew Pinski's suggestion. Note I did not apply to all the value >> profiles as >> the indirect-call profile is the most relevant one here. >> >> Test with bootstrap. >> >> Comments and suggestions are welcomed. >> >> Thanks, >> >> -Rong >> >> >> 2012-12-20 Rong Xu >> >> * libgcc/libgcov.c (__gcov_one_value_profiler_body_atomic): New >> function. Atomic update profile counters. >> (__gcov_one_value_profiler_atomic): Ditto. >> (__gcov_indirect_call_profiler_atomic): Ditto. >> * gcc/gcov-io.h: Macros for atomic update. >> * gcc/common.opt: New option. >> * gcc/tree-profile.c (gimple_init_edge_profiler): Atomic >> update profile counters. >> (gimple_gen_edge_profiler): Ditto. > > The patch looks resonable. Eventually we probably should provide rest of the > value counters > in thread safe manner. What happens on targets not having atomic operations? >From >http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins, it says: "If a particular operation cannot be implemented on the target processor, a warning is generated and a call an external function is generated. " So I think there will be a warning and eventually a link error of unsat. Thanks, -Rong > > Honza
[Patch, Fortran] PR55763 - Fix MOVE_ALLOC with CLASS(*)
Fix one of the remaining issues of PR 55763: MOVE_ALLOC with CLASS(*)
either for both arguments or only for TO=.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2012-12-21 Tobias Burnus
PR fortran/55763
* check.c (gfc_check_move_alloc): Handle unlimited polymorphic.
* trans-intrinsic.c (conv_intrinsic_move_alloc): Ditto.
2012-12-21 Tobias Burnus
PR fortran/55763
* gfortran.dg/unlimited_polymorphic_5.f90
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 793ad75..0923f12 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -2791,18 +2791,15 @@ gfc_check_move_alloc (gfc_expr *from, gfc_expr *to)
return FAILURE;
}
- if (to->ts.kind != from->ts.kind)
+ /* CLASS arguments: Make sure the vtab of from is present. */
+ if (to->ts.type == BT_CLASS && !UNLIMITED_POLY (from))
{
- gfc_error ("The FROM and TO arguments of the MOVE_ALLOC intrinsic at %L"
- " must be of the same kind %d/%d", &to->where, from->ts.kind,
- to->ts.kind);
- return FAILURE;
+ if (from->ts.type == BT_CLASS || from->ts.type == BT_DERIVED)
+ gfc_find_derived_vtab (from->ts.u.derived);
+ else
+ gfc_find_intrinsic_vtab (&from->ts);
}
- /* CLASS arguments: Make sure the vtab of from is present. */
- if (to->ts.type == BT_CLASS)
-gfc_find_derived_vtab (from->ts.u.derived);
-
return SUCCESS;
}
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index b9d13cc..5a89be1 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -7373,8 +7373,13 @@ conv_intrinsic_move_alloc (gfc_code *code)
if (from_expr->ts.type == BT_CLASS)
{
- vtab = gfc_find_derived_vtab (from_expr->ts.u.derived);
- gcc_assert (vtab);
+ if (UNLIMITED_POLY (from_expr))
+ vtab = NULL;
+ else
+ {
+ vtab = gfc_find_derived_vtab (from_expr->ts.u.derived);
+ gcc_assert (vtab);
+ }
gfc_free_expr (from_expr2);
gfc_init_se (&from_se, NULL);
@@ -7386,13 +7391,23 @@ conv_intrinsic_move_alloc (gfc_code *code)
from_se.expr));
/* Reset _vptr component to declared type. */
- tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
- gfc_add_modify_loc (input_location, &block, from_se.expr,
- fold_convert (TREE_TYPE (from_se.expr), tmp));
+ if (UNLIMITED_POLY (from_expr))
+ gfc_add_modify_loc (input_location, &block, from_se.expr,
+fold_convert (TREE_TYPE (from_se.expr),
+ null_pointer_node));
+ else
+ {
+ tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
+ gfc_add_modify_loc (input_location, &block, from_se.expr,
+ fold_convert (TREE_TYPE (from_se.expr), tmp));
+ }
}
else
{
- vtab = gfc_find_derived_vtab (from_expr->ts.u.derived);
+ if (from_expr->ts.type != BT_DERIVED)
+ vtab = gfc_find_intrinsic_vtab (&from_expr->ts);
+ else
+ vtab = gfc_find_derived_vtab (from_expr->ts.u.derived);
gcc_assert (vtab);
tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
gfc_add_modify_loc (input_location, &block, to_se.expr,
@@ -7415,8 +7430,13 @@ conv_intrinsic_move_alloc (gfc_code *code)
if (from_expr->ts.type == BT_CLASS)
{
- vtab = gfc_find_derived_vtab (from_expr->ts.u.derived);
- gcc_assert (vtab);
+ if (UNLIMITED_POLY (from_expr))
+ vtab = NULL;
+ else
+ {
+ vtab = gfc_find_derived_vtab (from_expr->ts.u.derived);
+ gcc_assert (vtab);
+ }
from_se.want_pointer = 1;
from_expr2 = gfc_copy_expr (from_expr);
@@ -7427,13 +7447,23 @@ conv_intrinsic_move_alloc (gfc_code *code)
from_se.expr));
/* Reset _vptr component to declared type. */
- tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
- gfc_add_modify_loc (input_location, &block, from_se.expr,
- fold_convert (TREE_TYPE (from_se.expr), tmp));
+ if (UNLIMITED_POLY (from_expr))
+ gfc_add_modify_loc (input_location, &block, from_se.expr,
+fold_convert (TREE_TYPE (from_se.expr),
+ null_pointer_node));
+ else
+ {
+ tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
+ gfc_add_modify_loc (input_location, &block, from_se.expr,
+ fold_convert (TREE_TYPE (from_se.expr), tmp));
+ }
}
else
{
- vtab = gfc_find_derived_vtab (from_expr->ts.u.derived);
+ if (from_expr->ts.type != BT_DERIVED)
+ vtab = gfc_find_intrinsic_vtab (&from_expr->ts);
+ else
+ vtab = gfc_find_derived_vtab (from_expr->ts.u.derived);
gcc_assert (vtab);
tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
gfc_add_modify_loc (input_location, &block, to_se.expr,
diff --git a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_5.f90 b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_5.f90
new file mode 100644
index 000..12a3c4a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unlimited_polymorph
Re: [Patch, PR 54128] ira.c change to fix mips bootstrap
On Fri, 2012-12-21 at 08:46 +0100, Jakub Jelinek wrote: > Given Alex' comments in the PR, the second hunk is definitely ok for trunk, > the first one can be applied too (but you can skip it too if you want, it > shouldn't make a difference). Thanks, I checked in both chunks. Steve Ellcey sell...@mips.com
Re: [PATCH] Fix PR54659, include gmp.h from system.h
On Fri, Dec 21, 2012 at 8:26 AM, Dominique Dhumieres wrote: > I think revision 194665 breaks bootstrap on at least x86_64-apple-darwin10: > > g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables > -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual > -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild > -I../../_clean/gcc -I../../_clean/gcc/build -I../../_clean/gcc/../include > -I./../intl -I../../_clean/gcc/../libcpp/include -I/opt/mp/include > -I../../_clean/gcc/../libdecnumber -I../../_clean/gcc/../libdecnumber/dpd > -I../libdecnumber -I../../_clean/gcc/../libbacktrace -DCLOOG_INT_GMP > -I/opt/mp/include \ > -o build/genconstants.o ../../_clean/gcc/genconstants.c > In file included from ./bconfig.h:3:0, > from ../../_clean/gcc/genconstants.c:28: > ./auto-host.h:1994:16: error: declaration does not declare anything > [-fpermissive] > #define rlim_t long That doesn't make much sense. What do the lines around this look like? > In file included from ../../_clean/gcc/genconstants.c:29:0: > ../../_clean/gcc/system.h:502:34: error: declaration of C function 'const > char* strsignal(int)' conflicts with > extern const char *strsignal (int); > ^ > In file included from /opt/gcc/gcc4.8a/include/c++/4.8.0/cstring:44:0, > from ../../_clean/gcc/system.h:207, > from ../../_clean/gcc/genconstants.c:29: > /usr/include/string.h:136:7: error: previous declaration 'char* > strsignal(int)' here > char *strsignal(int sig); >^ In auto-host.h, what are the values of HAVE_STRSIGNAL and HAVE_DECL_STRSIGNAL? Ian
[testsuite] replace gcc.target/arm/ftest-*.c with compile-only tests
The gcc.target/arm/ftest-*.c tests check various macros that are set for
ARM targets by setting flags based on preprocessor directives that check
those macros. The tests are skipped if the current test platform
doesn't support executing programs for the architecture for which flags
are being checked. There are several problems with these tests:
o There are problems with the arm_arch_v*_multilib effective target
checks as described in PR testsuite/55780.
o Tests for arm mode are skipped if the currently multilib generates
THUMB mode by default, but they only need to be skipped if the
multilib flags include -mthumb that would override the -marm
specified in test options.
o The tests are not skipped if multilib flags use -march=* that would
override the test options.
When checking preprocessor builtins there is no need to execute a test;
the checking can all be done during preprocessing. This patch replaces
the gcc.target/arm/ftest-*.c tests with compile-only tests that fail to
compile if macros are defined when they should not be, or have the
wrong values. All tests can now be run without depending on the target
hardware.
Tested with several sets of multilib options for arm-none-eabi and
arm-none-linux-gnueabi. OK?
Janis
P.S. I don't know why, but the original thumb tests require arm_eabi
and the arm tests don't; I kept that restraint.
2012-12-21 Janis Johnson
* gcc.target/arm/ftest-support.h: Replace for compile-only tests.
* gcc.target/arm/ftest-support-arm.h: Delete.
* gcc.target/arm/ftest-support-thumb.h: Delete.
* gcc.target/arm/ftest-armv4-arm.c: Replace with compile-only test.
* gcc.target/arm/ftest-armv4t-arm.c: Likewise.
* gcc.target/arm/ftest-armv4t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5t-arm.c: Likewise.
* gcc.target/arm/ftest-armv5t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5te-arm.c: Likewise.
* gcc.target/arm/ftest-armv5te-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6-arm.c: Likewise.
* gcc.target/arm/ftest-armv6-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6k-arm.c: Likewise.
* gcc.target/arm/ftest-armv6k-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6m-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6t2-arm.c: Likewise.
* gcc.target/arm/ftest-armv6t2-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6z-arm.c: Likewise.
* gcc.target/arm/ftest-armv6z-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7a-arm.c: Likewise.
* gcc.target/arm/ftest-armv7a-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7em-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7m-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7r-arm.c: Likewise.
* gcc.target/arm/ftest-armv7r-thumb.c: Likewise.
* gcc.target/arm/ftest-armv8a-arm.c: Likewise.
* gcc.target/arm/ftest-armv8a-thumb.c: Likewise.
Index: gcc.target/arm/ftest-support.h
===
--- gcc.target/arm/ftest-support.h (revision 194619)
+++ gcc.target/arm/ftest-support.h (working copy)
@@ -1,84 +1,156 @@
-#if 0
-#define INTERNAL_DEBUG 1
+/* For each of several ARM architecture features, check that relevant
+ macros are defined or not, and that they have the expected values. */
+
+#ifdef NEED_ARM_ARCH
+# ifdef __ARM_ARCH
+# if __ARM_ARCH != VALUE_ARM_ARCH
+# error __ARM_ARCH has unexpected value
+# endif
+# else
+# error __ARM_ARCH is not defined but should be
+# endif
+#else
+# ifdef __ARM_ARCH
+# error __ARM_ARCH is defined but should not be
+# endif
#endif
-#ifdef INTERNAL_DEBUG
-#include
+#ifdef NEED_ARM_ARCH_ISA_ARM
+# ifdef __ARM_ARCH_ISA_ARM
+# if __ARM_ARCH_ISA_ARM != VALUE_ARM_ARCH_ISA_ARM
+# error __ARM_ARCH_ISA_ARM has unexpected value
+# endif
+# else
+# error __ARM_ARCH_ISA_ARM is not defined but should be
+# endif
+#else
+# ifdef __ARM_ARCH_ISA_ARM
+# error __ARM_ARCH_ISA_ARM is defined but should not be
+# endif
#endif
-extern void abort (void);
+#ifdef NEED_ARM_ARCH_ISA_THUMB
+# ifdef __ARM_ARCH_ISA_THUMB
+# if __ARM_ARCH_ISA_THUMB != VALUE_ARM_ARCH_ISA_THUMB
+# error __ARM_ARCH_ISA_THUMB has unexpected value
+# endif
+# else
+# error __ARM_ARCH_ISA_THUMB is not defined but should be
+# endif
+#else
+# ifdef __ARM_ARCH_ISA_THUMB
+# error __ARM_ARCH_ISA_THUMB is defined but should not be
+# endif
+#endif
-enum architecture {
- ARCH_V4 = 0,
- ARCH_V4T,
- ARCH_V5T,
- ARCH_V5TE,
- ARCH_V6,
- ARCH_V6K,
- ARCH_V6T2,
- ARCH_V6Z,
- ARCH_V6M,
- ARCH_V7A,
- ARCH_V7R,
- ARCH_V7M,
- ARCH_V7EM,
- ARCH_V8A,
- ARCH_COUNT
-};
+#ifdef NEED_ARM_ARCH_PROFILE
+# ifdef __ARM_ARCH_PROFILE
+# if __ARM_ARCH_PROFILE != VALUE_ARM_ARCH_PROFILE
+# error __ARM_ARCH_PROFILE has unexpected value
+# endif
+# else
+# error __ARM_ARCH_PROFILE is not defined but should be
+# endif
+#else
+# ifdef __ARM_ARCH_PROFILE
Re: [google 4.7] fdo build for linux kernel (issue6968046)
that's in the histrogram merge. we disable the merge in kernel fdo (instead, we do offline merge). -Rong On Fri, Dec 21, 2012 at 9:55 AM, Teresa Johnson wrote: > clzll
Re: [PATCH] Fix PR54659, include gmp.h from system.h
> That doesn't make much sense. What do the lines around this look like? I am currently bootstrapping r194675 with revision 194665 reverted. The diff between gcc/auto-host.h with(-)/without(+) r194665 reverted and --enable-checking=release for (+) looks like: --- ../build_w/gcc/auto-host.h 2012-12-21 20:16:59.0 +0100 +++ gcc/auto-host.h 2012-12-21 20:54:49.0 +0100 @@ -49,7 +49,7 @@ /* Define if you want more run-time sanity checks. This one gets a grab bag of miscellaneous but relatively cheap checks. */ #ifndef USED_FOR_TARGET -#define ENABLE_CHECKING 1 +/* #undef ENABLE_CHECKING */ #endif @@ -96,7 +96,7 @@ /* Define if you want the garbage collector to do object poisoning and other memory allocation checks. This is quite expensive. */ #ifndef USED_FOR_TARGET -#define ENABLE_GC_CHECKING 1 +/* #undef ENABLE_GC_CHECKING */ #endif ... /* Define to 1 if we found a declaration for 'strsignal', otherwise define to 0. */ #ifndef USED_FOR_TARGET -#define HAVE_DECL_STRSIGNAL 1 +#define HAVE_DECL_STRSIGNAL 0 #endif ... @@ -1991,7 +1991,7 @@ /* Define to `long' if doesn't define. */ #ifndef USED_FOR_TARGET -/* #undef rlim_t */ +#define rlim_t long #endif I see #define HAVE_STRSIGNAL 1 in both files. Dominique
Re: *ping* [patch, libfortran] Fix PR 30162, write with pipes
On 12/20/2012 03:23 AM, Thomas Koenig wrote: Ping? Thomas Hi Janus, Oops, right. Here is the correct one. Yes, OK Regards, Jerry
Re: [PATCH] Fix PR54659, include gmp.h from system.h
I think I understand at least part of the problem: (1) I configure gcc with ../work/configure --prefix=/opt/gcc/gcc4.8w --enable-languages=c,c++,fortran,objc,obj-c++,java,ada,lto --with-gmp=/opt/mp --with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin --enable-build-with-cxx i.e., the files for gmp, mpfr, mpc, isl, ... are found in /opt/mp (2) before r194665 the files including gcc/system.h did not need gmp.h and the tests using it in configure were happy with gcc -c -g -I../../work/gcc -I../../work/gcc/../include conftest.c >&5 (3) starting with r194665 all these tests fails as configure:10333: checking whether getenv is declared configure:10356: gcc -c -g -I../../p_work/gcc -I../../p_work/gcc/../include conftest.c >&5 In file included from conftest.c:108:0: ../../p_work/gcc/system.h:641:17: fatal error: gmp.h: No such file or directory #include ^ compilation terminated. configure:10356: $? = 1 I think the fix requires to use gmpinc='-I/opt/mp/include ' Dominique
patch to fix PR55775
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55775
The bug is related to PR55330.
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 194680.
2012-12-21 Vladimir Makarov
PR middle-end/55775
* lra-assigns.c (improve_inheritance): Do nothing after
LRA_MAX_INHERITANCE_PASSES pass.
* lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to
LRA_MAX_CONSTRAINT_ITERATION_NUMBER. Move to lra-int.h.
(MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES.
Move to lra-int.h.
* lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from
lra-constraints.c.
(LRA_MAX_INHERITANCE_PASSES): Ditto.
2012-12-21 Vladimir Makarov
PR middle-end/55775
* gcc.target/i386/pr55775.c: New test.
Index: lra-assigns.c
===
--- lra-assigns.c (revision 194677)
+++ lra-assigns.c (working copy)
@@ -1084,6 +1084,8 @@ improve_inheritance (bitmap changed_pseu
lra_copy_t cp, next_cp;
bitmap_iterator bi;
+ if (lra_inheritance_iter > LRA_MAX_INHERITANCE_PASSES)
+return;
n = 0;
EXECUTE_IF_SET_IN_BITMAP (&lra_inheritance_pseudos, 0, k, bi)
if (reg_renumber[k] >= 0 && lra_reg_info[k].nrefs != 0)
Index: lra-constraints.c
===
--- lra-constraints.c (revision 194677)
+++ lra-constraints.c (working copy)
@@ -3201,10 +3201,6 @@ loc_equivalence_callback (rtx loc, const
return NULL_RTX;
}
-/* Maximum allowed number of constraint pass iterations after the last
- spill pass. It is for preventing LRA cycling in a bug case. */
-#define MAX_CONSTRAINT_ITERATION_NUMBER 30
-
/* Maximum number of generated reload insns per an insn. It is for
preventing this pass cycling in a bug case. */
#define MAX_RELOAD_INSNS_NUMBER LRA_MAX_INSN_RELOADS
@@ -3328,10 +3324,10 @@ lra_constraints (bool first_p)
fprintf (lra_dump_file, "\n** Local #%d: **\n\n",
lra_constraint_iter);
lra_constraint_iter_after_spill++;
- if (lra_constraint_iter_after_spill > MAX_CONSTRAINT_ITERATION_NUMBER)
+ if (lra_constraint_iter_after_spill > LRA_MAX_CONSTRAINT_ITERATION_NUMBER)
internal_error
("Maximum number of LRA constraint passes is achieved (%d)\n",
- MAX_CONSTRAINT_ITERATION_NUMBER);
+ LRA_MAX_CONSTRAINT_ITERATION_NUMBER);
changed_p = false;
lra_risky_transformations_p = false;
new_insn_uid_start = get_max_uid ();
@@ -4698,21 +4694,6 @@ inherit_in_ebb (rtx head, rtx tail)
return change_p;
}
-/* The maximal number of inheritance/split passes in LRA. It should
- be more 1 in order to perform caller saves transformations and much
- less MAX_CONSTRAINT_ITERATION_NUMBER to prevent LRA to do as many
- as permitted constraint passes in some complicated cases. The
- first inheritance/split pass has a biggest impact on generated code
- quality. Each subsequent affects generated code in less degree.
- For example, the 3rd pass does not change generated SPEC2000 code
- at all on x86-64. */
-#define MAX_INHERITANCE_PASSES 2
-
-#if MAX_INHERITANCE_PASSES <= 0 \
-|| MAX_INHERITANCE_PASSES >= MAX_CONSTRAINT_ITERATION_NUMBER - 8
-#error wrong MAX_INHERITANCE_PASSES value
-#endif
-
/* This value affects EBB forming. If probability of edge from EBB to
a BB is not greater than the following value, we don't add the BB
to EBB. */
@@ -4730,7 +4711,7 @@ lra_inheritance (void)
edge e;
lra_inheritance_iter++;
- if (lra_inheritance_iter > MAX_INHERITANCE_PASSES)
+ if (lra_inheritance_iter > LRA_MAX_INHERITANCE_PASSES)
return;
timevar_push (TV_LRA_INHERITANCE);
if (lra_dump_file != NULL)
@@ -5000,7 +4981,7 @@ lra_undo_inheritance (void)
bool change_p;
lra_undo_inheritance_iter++;
- if (lra_undo_inheritance_iter > MAX_INHERITANCE_PASSES)
+ if (lra_undo_inheritance_iter > LRA_MAX_INHERITANCE_PASSES)
return false;
if (lra_dump_file != NULL)
fprintf (lra_dump_file,
Index: lra-int.h
===
--- lra-int.h (revision 194677)
+++ lra-int.h (working copy)
@@ -249,6 +249,25 @@ typedef struct lra_insn_recog_data *lra_
#define LRA_LOSER_COST_FACTOR 6
#define LRA_MAX_REJECT 600
+/* Maximum allowed number of constraint pass iterations after the last
+ spill pass. It is for preventing LRA cycling in a bug case. */
+#define LRA_MAX_CONSTRAINT_ITERATION_NUMBER 30
+
+/* The maximal number of inheritance/split passes in LRA. It should
+ be more 1 in order to perform caller saves transformations and much
+ less MAX_CONSTRAINT_ITERATION_NUMBER to prevent LRA to do as many
+ as permitted constraint passes in some complicated cases. The
+ first inheritance/split pass has a biggest impact on generated code
+ quality. Each subsequent affects generated
Re: patch to fix PR55775
From: Vladimir Makarov Date: Fri, 21 Dec 2012 16:22:15 -0500 > 2012-12-21 Vladimir Makarov > > PR middle-end/55775 > * lra-assigns.c (improve_inheritance): Do nothing after > LRA_MAX_INHERITANCE_PASSES pass. > * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to > LRA_MAX_CONSTRAINT_ITERATION_NUMBER. Move to lra-int.h. > (MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES. > Move to lra-int.h. > * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from > lra-constraints.c. > (LRA_MAX_INHERITANCE_PASSES): Ditto. The changes to lra_inheritabnce() and lra_undo_inheritance() are not listed. Also, why is it OK to simply ignore the fact that a relaxation algorithm is still making changes? Shouldn't we be instead fixing whatever prevents proper convergence?
Minor fix for UNSPEC_VOLATILE
The more you dig into the UNSPEC_VOLATILE/asm volatile business, the more you
find that the manual, the code and the comments entirely disagree about them.
At least something is consistent: as documented in rtl.def, UNSPEC_VOLATILE
can trap. That's why it was wrong for the unspec_may_trap_p hook to handle
them in addition to regular UNSPECs. Fortunately, only IA-64 defines the hook
and it doesn't do anything for UNSPEC_VOLATILEs.
Tested on x86-64/Linux and IA-64/Linux, applied on the mainline.
2012-12-21 Eric Botcazou
* rtlanal.c (volatile_insn_p): Delete commented out code.
(side_effects_p): Likewise.
(may_trap_p_1) : Return 1 again.
* target.def (unspec_may_trap_p): Adjust comment.
* targhooks.c (default_unspec_may_trap_p): Don't handle UNSPEC_VOLATILE.
* config/ia64/ia64.c (ia64_unspec_may_trap_p): Adjust to above change.
--
Eric BotcazouIndex: targhooks.c
===
--- targhooks.c (revision 194669)
+++ targhooks.c (working copy)
@@ -102,10 +102,8 @@ default_unspec_may_trap_p (const_rtx x,
{
int i;
- if (GET_CODE (x) == UNSPEC_VOLATILE
- /* Any floating arithmetic may trap. */
- || (SCALAR_FLOAT_MODE_P (GET_MODE (x))
- && flag_trapping_math))
+ /* Any floating arithmetic may trap. */
+ if ((SCALAR_FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math))
return 1;
for (i = 0; i < XVECLEN (x, 0); ++i)
Index: target.def
===
--- target.def (revision 194669)
+++ target.def (working copy)
@@ -1816,7 +1816,7 @@ DEFHOOK
"",
rtx, (rtx hard_reg), NULL)
-/* Return nonzero if evaluating UNSPEC[_VOLATILE] X might cause a trap.
+/* Return nonzero if evaluating UNSPEC X might cause a trap.
FLAGS has the same meaning as in rtlanal.c: may_trap_p_1. */
DEFHOOK
(unspec_may_trap_p,
Index: rtlanal.c
===
--- rtlanal.c (revision 194669)
+++ rtlanal.c (working copy)
@@ -2107,7 +2107,6 @@ volatile_insn_p (const_rtx x)
return 0;
case UNSPEC_VOLATILE:
- /* case TRAP_IF: This isn't clear yet. */
return 1;
case ASM_INPUT:
@@ -2240,7 +2239,6 @@ side_effects_p (const_rtx x)
case POST_MODIFY:
case CALL:
case UNSPEC_VOLATILE:
- /* case TRAP_IF: This isn't clear yet. */
return 1;
case MEM:
@@ -2312,9 +2310,9 @@ may_trap_p_1 (const_rtx x, unsigned flag
return 0;
case UNSPEC:
-case UNSPEC_VOLATILE:
return targetm.unspec_may_trap_p (x, flags);
+case UNSPEC_VOLATILE:
case ASM_INPUT:
case TRAP_IF:
return 1;
@@ -2406,8 +2404,7 @@ may_trap_p_1 (const_rtx x, unsigned flag
default:
/* Any floating arithmetic may trap. */
- if (SCALAR_FLOAT_MODE_P (GET_MODE (x))
- && flag_trapping_math)
+ if (SCALAR_FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math)
return 1;
}
Index: config/ia64/ia64.c
===
--- config/ia64/ia64.c (revision 194669)
+++ config/ia64/ia64.c (working copy)
@@ -5845,19 +5845,16 @@ ia64_secondary_reload_class (enum reg_cl
static int
ia64_unspec_may_trap_p (const_rtx x, unsigned flags)
{
- if (GET_CODE (x) == UNSPEC)
+ switch (XINT (x, 1))
{
- switch (XINT (x, 1))
- {
- case UNSPEC_LDA:
- case UNSPEC_LDS:
- case UNSPEC_LDSA:
- case UNSPEC_LDCCLR:
- case UNSPEC_CHKACLR:
- case UNSPEC_CHKS:
- /* These unspecs are just wrappers. */
- return may_trap_p_1 (XVECEXP (x, 0, 0), flags);
- }
+case UNSPEC_LDA:
+case UNSPEC_LDS:
+case UNSPEC_LDSA:
+case UNSPEC_LDCCLR:
+case UNSPEC_CHKACLR:
+case UNSPEC_CHKS:
+ /* These unspecs are just wrappers. */
+ return may_trap_p_1 (XVECEXP (x, 0, 0), flags);
}
return default_unspec_may_trap_p (x, flags);
[Patch, Fortran] PR55763 fix .mod reading plus CALL with CLASS(*)
Another two fixes for CLASS(*). (We really should audit all calls to
gfc_find_derived_vtab for possible issues with CLASS(*).)
If I haven't miscounted, there is still one other failure in the PR.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2012-12-21 Tobias Burnus
PR fortran/55763
* module.c (mio_component): Don't skip _hash's initializer.
* resolve.c (resolve_select_type): Add an assert.
* trans-expr.c (gfc_conv_procedure_call): Handle
INTENT(OUT) for UNLIMIT_POLY.
2012-12-21 Tobias Burnus
PR fortran/55763
* gfortran.dg/unlimited_polymorphic_6.f90: New.
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 168f933..a797f24 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -2603,7 +2603,8 @@ mio_component (gfc_component *c, int vtype)
c->attr.class_ok = 1;
c->attr.access = MIO_NAME (gfc_access) (c->attr.access, access_types);
- if (!vtype || strcmp (c->name, "_final") == 0)
+ if (!vtype || strcmp (c->name, "_final") == 0
+ || strcmp (c->name, "_hash") == 0)
mio_expr (&c->initializer);
if (c->attr.proc_pointer)
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index fce6f73..cf130a3 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8484,7 +8511,7 @@ resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
gfc_expr *e;
ivtab = gfc_find_intrinsic_vtab (&c->ts);
- gcc_assert (ivtab);
+ gcc_assert (ivtab && CLASS_DATA (ivtab)->initializer);
e = CLASS_DATA (ivtab)->initializer;
c->low = c->high = gfc_copy_expr (e);
}
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index ad26684..452f2bc 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -4302,7 +4302,14 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
null_pointer_node);
gfc_add_expr_to_block (&block, tmp);
- if (fsym->ts.type == BT_CLASS)
+ if (fsym->ts.type == BT_CLASS && UNLIMITED_POLY (fsym))
+ {
+ gfc_add_modify (&block, ptr,
+ fold_convert (TREE_TYPE (ptr),
+ null_pointer_node));
+ gfc_add_expr_to_block (&block, tmp);
+ }
+ else if (fsym->ts.type == BT_CLASS)
{
gfc_symbol *vtab;
vtab = gfc_find_derived_vtab (fsym->ts.u.derived);
diff --git a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_6.f90 b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_6.f90
new file mode 100644
index 000..a64f4e3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_6.f90
@@ -0,0 +1,37 @@
+! { dg-do run }
+!
+! PR fortran/55763
+!
+! Contributed by Reinhold Bader
+!
+module mod_alloc_scalar_01
+contains
+ subroutine construct(this)
+class(*), allocatable, intent(out) :: this
+integer :: this_i
+this_i = 4
+allocate(this, source=this_i)
+ end subroutine
+end module
+
+program alloc_scalar_01
+ use mod_alloc_scalar_01
+ implicit none
+ class(*), allocatable :: mystuff
+
+ call construct(mystuff)
+ call construct(mystuff)
+
+ select type(mystuff)
+ type is (integer)
+if (mystuff == 4) then
+! write(*,*) 'OK'
+else
+ call abort()
+! write(*,*) 'FAIL 1'
+end if
+ class default
+call abort()
+!write(*,*) 'FAIL 2'
+ end select
+end program
Re: patch to fix PR55775
On 12-12-21 4:29 PM, David Miller wrote: From: Vladimir Makarov Date: Fri, 21 Dec 2012 16:22:15 -0500 2012-12-21 Vladimir Makarov PR middle-end/55775 * lra-assigns.c (improve_inheritance): Do nothing after LRA_MAX_INHERITANCE_PASSES pass. * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to LRA_MAX_CONSTRAINT_ITERATION_NUMBER. Move to lra-int.h. (MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES. Move to lra-int.h. * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from lra-constraints.c. (LRA_MAX_INHERITANCE_PASSES): Ditto. The changes to lra_inheritabnce() and lra_undo_inheritance() are not listed. It is assumed, David. I should have written "rename everywhere". Also, why is it OK to simply ignore the fact that a relaxation algorithm is still making changes? Shouldn't we be instead fixing whatever prevents proper convergence? It is very hard to fix according to your proposals. It would require to insert most of code from lra-constraints.c because code for improving inheritance should take a lot of details about insn constraints into account to fix it. If I go this way, it will be another reload which is trying to do everything at once. Also after 2 passes the inheritance improve code (as inheritance code itself) usually does nothing for big majority of programs. It has no sense to run them all the time. So for stability, LRA after a few iterations is trying to do only most important and necessary code for generation of the correct code.
Go patch committed:
In Go it is an error if the same name is defined in both the package
block (names defined anywhere in the package) and the file block (names
defined only in a single file, which can only happen via import
statements). The gccgo frontend was not diagnosing this error. This
patch fixes the problem. This required a tweak to one of the tests.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 9a016fbfe7b3 go/gogo.cc
--- a/go/gogo.cc Fri Dec 21 06:59:06 2012 -0800
+++ b/go/gogo.cc Fri Dec 21 14:19:44 2012 -0800
@@ -29,6 +29,7 @@
package_(NULL),
functions_(),
globals_(new Bindings(NULL)),
+file_block_names_(),
imports_(),
imported_unsafe_(false),
packages_(),
@@ -1243,6 +1244,33 @@
else if (no->is_unknown())
no->unknown_value()->set_real_named_object(global_no);
}
+
+ // Give an error if any name is defined in both the package block
+ // and the file block. For example, this can happen if one file
+ // imports "fmt" and another file defines a global variable fmt.
+ for (Bindings::const_declarations_iterator p =
+ this->package_->bindings()->begin_declarations();
+ p != this->package_->bindings()->end_declarations();
+ ++p)
+{
+ if (p->second->is_unknown()
+ && p->second->unknown_value()->real_named_object() == NULL)
+ {
+ // No point in warning about an undefined name, as we will
+ // get other errors later anyhow.
+ continue;
+ }
+ File_block_names::const_iterator pf =
+ this->file_block_names_.find(p->second->name());
+ if (pf != this->file_block_names_.end())
+ {
+ std::string n = p->second->message_name();
+ error_at(p->second->location(),
+ "%qs defined as both imported name and global name",
+ n.c_str());
+ inform(pf->second, "%qs imported here", n.c_str());
+ }
+}
}
// Clear out names in file scope.
@@ -1250,7 +1278,7 @@
void
Gogo::clear_file_scope()
{
- this->package_->bindings()->clear_file_scope();
+ this->package_->bindings()->clear_file_scope(this);
// Warn about packages which were imported but not used.
bool quiet = saw_errors();
@@ -4855,7 +4883,7 @@
// Clear imports.
void
-Bindings::clear_file_scope()
+Bindings::clear_file_scope(Gogo* gogo)
{
Contour::iterator p = this->bindings_.begin();
while (p != this->bindings_.end())
@@ -4875,7 +4903,10 @@
if (keep)
++p;
else
- p = this->bindings_.erase(p);
+ {
+ gogo->add_file_block_name(p->second->name(), p->second->location());
+ p = this->bindings_.erase(p);
+ }
}
}
diff -r 9a016fbfe7b3 go/gogo.h
--- a/go/gogo.h Fri Dec 21 06:59:06 2012 -0800
+++ b/go/gogo.h Fri Dec 21 14:19:44 2012 -0800
@@ -377,6 +377,11 @@
void
add_named_object(Named_object*);
+ // Add an identifier to the list of names seen in the file block.
+ void
+ add_file_block_name(const std::string& name, Location location)
+ { this->file_block_names_[name] = location; }
+
// Mark all local variables in current bindings as used. This is
// used when there is a parse error to avoid useless errors.
void
@@ -678,6 +683,10 @@
// This is used for initialization dependency analysis.
typedef std::map Var_deps;
+ // Type used to map identifiers in the file block to the location
+ // where they were defined.
+ typedef Unordered_map(std::string, Location) File_block_names;
+
// Type used to queue writing a type specific function.
struct Specific_type_function
{
@@ -710,6 +719,8 @@
// The global binding contour. This includes the builtin functions
// and the package we are compiling.
Bindings* globals_;
+ // The list of names we have seen in the file block.
+ File_block_names file_block_names_;
// Mapping from import file names to packages.
Imports imports_;
// Whether the magic unsafe package was imported.
@@ -2265,7 +2276,7 @@
// Clear all names in file scope from the bindings.
void
- clear_file_scope();
+ clear_file_scope(Gogo*);
// Look up a name in this binding contour and in any enclosing
// binding contours. This returns NULL if the name is not found.
diff -r 9a016fbfe7b3 libgo/go/image/image_test.go
--- a/libgo/go/image/image_test.go Fri Dec 21 06:59:06 2012 -0800
+++ b/libgo/go/image/image_test.go Fri Dec 21 14:19:44 2012 -0800
@@ -10,7 +10,7 @@
"testing"
)
-type image interface {
+type timage interface {
Image
Opaque() bool
Set(int, int, color.Color)
@@ -24,7 +24,7 @@
}
func TestImage(t *testing.T) {
- testImage := []image{
+ testImage := []timage{
NewRGBA(Rect(0, 0, 10, 10)),
NewRGBA64(Rect(0, 0, 10, 10)),
NewNRGBA(Rect(0, 0, 10, 10)),
@@ -52,11 +52,11 @@
t.Errorf("%T: at (6, 3), want a non-zero color, got %v", m, m.At(6, 3))
continue
}
- if !m.SubImage(Rect(6, 3, 7, 4)).(image).Opaque() {
+ if !m.SubImage(Rect(6, 3, 7, 4)).(timage).Opaque() {
t.Errorf("%T: at (6, 3) was not opaque", m)
continue
}
- m = m.SubImage(Rect(3, 2, 9, 8)).(image)
+ m = m.
Fix PR ada/53737
This is a regression present on mainline and 4.7 branch, in the form of an assertion failure. The check that an RACW type is acceptable an actual for a formal type to which a pragma Remote_Access applies need not be performed on a defaulted formal type appearing in the internal instantiation of a formal package. Tested on x86-64/Linux, applied on the mainline and 4.7 branch. 2012-12-21 Ed Schonberg PR ada/53737 * sem_ch12.adb (Analyze_Associations): Do not check the legality of actuals for RACW types if this is an internal instantiation for a formal package with defaulted parameters. -- Eric BotcazouIndex: sem_ch12.adb === --- sem_ch12.adb (revision 194669) +++ sem_ch12.adb (working copy) @@ -1448,10 +1448,15 @@ package body Sem_Ch12 is -- defined aspect/pragma Remote_Access_Type. In that case -- the actual must be remote as well. + -- If the current instantiation is the construction of a + -- local copy for a formal package the actuals may be + -- defaulted, and there is no matching actual to check. + if Nkind (Analyzed_Formal) = N_Formal_Type_Declaration and then Nkind (Formal_Type_Definition (Analyzed_Formal)) = N_Access_To_Object_Definition + and then Present (Match) then declare Formal_Ent : constant Entity_Id :=
Re: [PATCH] PR c++/52343 - error with alias template as template template argument
On Fri, Dec 21, 2012 at 10:25 AM, Dodji Seketeli wrote:
> Gabriel Dos Reis writes:
>
>> The example is valid, but I am not sure I understand your
>> explanation...
>
> Ah, sorry. I realize just now that I haven't mentioned the initial
> erratic behaviour. Maybe that could have made my message easier to
> understand.
>
> So consider the test case of the message:
>
> 1 template
> 2 using A = int;
> 3
> 4 template class>
> 5 struct B {};
> 6
> 7 B b;
>
> test.cc:7:4: error: integral expression ‘A’ is not constant
> B b;
> ^
> Followed by some irrelevant other error messages.
>
> As I was saying my earlier message, here, the TREE_TYPE of the
> template_decl A is an integer; so check_instantiated_arg takes it as
> if A is an integer value (a decl with integer type), and thus, should
> be a constant.
>
> The fix I am proposing is just to allow check_instantiated_arg to make
> the difference between a classical integer decl, and an alias template
> which type-id is an integer.
>
> --
> Dodji
Hi Dodji,
Thank you very much for the explanation; your previous message
makes sense to me now. The question I have is why are we
using TREE_TYPE of a TEMPLATE_DECL to represent the
current instantiation of a template alias? Should not we use
TEMPLATE_RESULT instead?
-- Gaby
Re: [PATCH] Fix PR54659, include gmp.h from system.h
On Fri, 21 Dec 2012, Dominique Dhumieres wrote: > I think revision 194665 breaks bootstrap on at least x86_64-apple-darwin10: Same on everything FreeBSD. PR 55784 - [4.8 regression] declaration of C function 'const char* strsignal(int)' conflicts with /usr/include/string.h:112: error: previous declaration Gerald
Re: patch to fix PR55775
From: Vladimir Makarov Date: Fri, 21 Dec 2012 17:04:34 -0500 > If I go this way, it will be another reload which is trying to do > everything at once. Also after 2 passes the inheritance improve code > (as inheritance code itself) usually does nothing for big majority of > programs. It has no sense to run them all the time. So for > stability, LRA after a few iterations is trying to do only most > important and necessary code for generation of the correct code. Thanks for explaining.
