RE: GCC version bikeshedding
-Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Andi Kleen Sent: 20 July 2014 22:29 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: GCC version bikeshedding Paulo Matos pa...@matos-sorge.com writes: That's what I understood as well. Someone mentioned to leave the patch level number to the distros to use which sounded like a good idea. Sounds like a bad idea, as then there would be non unique gcc versions. redhat gcc 5.0.2 potentially being completely different from suse gcc 5.0.2 I understand your concern but I am not convinced it's bad. The main reason for this is that we wouldn't distribute GCCs x.y.z with z != 0 so if you would see 5.0.3 in the wild then you could only conclude it's 5.0 with a few patches from some vendor. As I type this I am starting to think how frustrating this might become. However, isn't it the case that nowadays you can have different gcc 4.9.1-2 distributed from different distros? The default gcc in my linode shows: gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) So, I can't see why in the future you couldn't have: Gcc version 5.1 (Ubuntu/Linaro 5.1.3) This is only if the release managers want to assign the patch level number to distros. I don't think there was a decision on this. Paulo Matos
[GSoC] Question about the implementation of vec.h
Dear gcc contributors, could you please answer a few questions about the implementation of vec.h? Should we always use “create” to initialize, for example, vectree_node* or is it possible to do it using “safe_grow_cleared” or a similar function? There is vec_safe_grow_cleared, which works with vecT, A, vl_embed. Is there a way to use it with vectree_node*? I would be very grateful for your comments. -- Cheers, Roman Gareev.
Re: GCC version bikeshedding
Andi Kleen a...@firstfloor.org writes: Sounds like a bad idea, as then there would be non unique gcc versions. redhat gcc 5.0.2 potentially being completely different from suse gcc 5.0.2 How is that different from now? Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 And now for something completely different.
[GSoC] generation of Gimple code from isl_ast_node_block
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_block.
However, I've found out a problem. The following example:
int k = 50;
static int __attribute__((noinline))
foo ()
{
int i, res;
for (i = 0, res = 0; i k; i++)
res += i;
return res;
}
extern void abort ();
int
main (void)
{
int res = foo ();
if (res != 1225)
abort ();
return 0;
}.
produces the following code, which executes without error:
ISL AST generated by ISL:
{
for (int c1 = 0; c1 k.0; c1 += 1)
S_4(c1);
S_6();
}
Gimple code:
loop_0 (header = 0, latch = 1, niter = )
{
bb_2 (preds = {bb_0 }, succs = {bb_3 bb_8 })
{
bb 2:
# VUSE .MEM_3(D)
k.0_9 = k;
if (k.0_9 0)
goto bb 3;
else
goto bb 8;
}
bb_3 (preds = {bb_2 }, succs = {bb_4 bb_7 })
{
bb 3:
# .MEM_8 = VDEF .MEM_3(D)
phi_out_of_ssa.5[0] = 0;
_20 = k.0_9 0;
if (_20 != 0)
goto bb 4;
else
goto bb 7;
}
bb_4 (preds = {bb_3 }, succs = {bb_5 })
{
bb 4:
_21 = (signed long) k.0_9;
_22 = _21 + -1;
}
bb_7 (preds = {bb_5 bb_3 }, succs = {bb_8 })
{
bb 7:
# .MEM_30 = PHI .MEM_29(5), .MEM_8(3)
# VUSE .MEM_30
res_32 = Close_Phi.6[0];
# .MEM_33 = VDEF .MEM_30
Cross_BB_scalar_dependence.7[0] = res_32;
# VUSE .MEM_33
res_17 = Cross_BB_scalar_dependence.7[0];
_16 = res_17;
}
bb_8 (preds = {bb_7 bb_2 }, succs = {bb_1 })
{
bb 8:
# res_12 = PHI _16(7), 0(2)
# .MEM_2 = PHI .MEM_33(7), .MEM_3(D)(2)
# VUSE .MEM_2
return res_12;
}
loop_2 (header = 5, latch = 6, niter = (unsigned long) ((signed
long) k.0_9 + -1), upper_bound = 9223372036854775806)
{
bb_5 (preds = {bb_4 bb_6 }, succs = {bb_6 bb_7 })
{
bb 5:
# graphite_IV.8_23 = PHI 0(4), graphite_IV.8_24(6)
# .MEM_31 = PHI .MEM_8(4), .MEM_29(6)
# VUSE .MEM_31
res_25 = phi_out_of_ssa.5[0];
_27 = (int) graphite_IV.8_23;
res_26 = res_25 + _27;
# .MEM_28 = VDEF .MEM_31
Close_Phi.6[0] = res_26;
# .MEM_29 = VDEF .MEM_28
phi_out_of_ssa.5[0] = res_26;
graphite_IV.8_24 = graphite_IV.8_23 + 1;
if (graphite_IV.8_23 _22)
goto bb 6;
else
goto bb 7;
}
bb_6 (preds = {bb_5 }, succs = {bb_5 })
{
bb 6:
goto bb 5;
}
}
}
It is similar to the original code:
loop_0 (header = 0, latch = 1, niter = )
{
bb_2 (preds = {bb_0 }, succs = {bb_3 bb_8 })
{
bb 2:
# VUSE .MEM_3(D)
k.0_9 = k;
if (k.0_9 0)
goto bb 3;
else
goto bb 8;
}
bb_3 (preds = {bb_2 }, succs = {bb_5 })
{
bb 3:
# .MEM_8 = VDEF .MEM_3(D)
phi_out_of_ssa.5[0] = 0;
goto bb 5;
}
bb_4 (preds = {bb_7 }, succs = {bb_8 })
{
bb 4:
# .MEM_19 = PHI .MEM_18(7)
# VUSE .MEM_19
res_17 = Cross_BB_scalar_dependence.7[0];
_16 = res_17;
goto bb 8;
}
bb_7 (preds = {bb_5 }, succs = {bb_4 })
{
bb 7:
# VUSE .MEM_13
res_4 = Close_Phi.6[0];
# .MEM_18 = VDEF .MEM_13
Cross_BB_scalar_dependence.7[0] = res_4;
goto bb 4;
}
bb_8 (preds = {bb_4 bb_2 }, succs = {bb_1 })
{
bb 8:
# res_12 = PHI _16(4), 0(2)
# .MEM_2 = PHI .MEM_19(4), .MEM_3(D)(2)
# VUSE .MEM_2
return res_12;
}
loop_1 (header = 5, latch = 6, niter = , upper_bound = 2147483646)
{
bb_5 (preds = {bb_3 bb_6 }, succs = {bb_6 bb_7 })
{
bb 5:
# i_10 = PHI 0(3), i_6(6)
# .MEM_1 = PHI .MEM_8(3), .MEM_13(6)
# VUSE .MEM_1
res_11 = phi_out_of_ssa.5[0];
res_5 = res_11 + i_10;
# .MEM_7 = VDEF .MEM_1
Close_Phi.6[0] = res_5;
# .MEM_13 = VDEF .MEM_7
phi_out_of_ssa.5[0] = res_5;
i_6 = i_10 + 1;
if (i_6 k.0_9)
goto bb 6;
else
goto bb 7;
}
bb_6 (preds = {bb_5 }, succs = {bb_5 })
{
bb 6:
goto bb 5;
}
}
}
If we change the name of variable k to n:
int n = 50;
static int __attribute__((noinline))
foo ()
{
int i, res;
for (i = 0, res = 0; i n; i++)
res += i;
return res;
}
extern void abort ();
int
main (void)
{
int res = foo ();
if (res != 1225)
abort ();
return 0;
}
the following code will be produced, which gives wrong result
ISL AST generated by ISL:
{
S_6();
for (int c1 = 0; c1 n.0; c1 += 1)
S_4(c1);
}
Gimple code:
loop_0 (header = 0, latch = 1, niter = )
{
bb_2 (preds = {bb_0 }, succs = {bb_3 bb_8 })
{
bb 2:
# VUSE .MEM_3(D)
n.0_9 = n;
if (n.0_9 0)
goto bb 3;
else
goto bb 8;
}
bb_3 (preds = {bb_2 }, succs = {bb_4 bb_7 })
{
bb 3:
# .MEM_8 = VDEF .MEM_3(D)
phi_out_of_ssa.5[0] = 0;
# VUSE .MEM_8
res_20 = Close_Phi.6[0];
# .MEM_21 = VDEF .MEM_8
Cross_BB_scalar_dependence.7[0] = res_20;
_22 = n.0_9 0;
if (_22 != 0)
goto bb 4;
else
goto bb 7;
}
bb_4 (preds = {bb_3 }, succs = {bb_5 })
{
bb 4:
_23 = (signed long)
Re: [GSoC] generation of Gimple code from isl_ast_node_block
On 21/07/2014 14:23, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_block.
However, I've found out a problem. The following example:
int k = 50;
static int __attribute__((noinline))
foo ()
{
int i, res;
for (i = 0, res = 0; i k; i++)
res += i;
return res;
}
extern void abort ();
int
main (void)
{
int res = foo ();
if (res != 1225)
abort ();
return 0;
}.
produces the following code, which executes without error:
ISL AST generated by ISL:
{
for (int c1 = 0; c1 k.0; c1 += 1)
S_4(c1);
S_6();
}
Gimple code:
loop_0 (header = 0, latch = 1, niter = )
{
bb_2 (preds = {bb_0 }, succs = {bb_3 bb_8 })
{
bb 2:
# VUSE .MEM_3(D)
k.0_9 = k;
if (k.0_9 0)
goto bb 3;
else
goto bb 8;
}
bb_3 (preds = {bb_2 }, succs = {bb_4 bb_7 })
{
bb 3:
# .MEM_8 = VDEF .MEM_3(D)
phi_out_of_ssa.5[0] = 0;
_20 = k.0_9 0;
if (_20 != 0)
goto bb 4;
else
goto bb 7;
}
bb_4 (preds = {bb_3 }, succs = {bb_5 })
{
bb 4:
_21 = (signed long) k.0_9;
_22 = _21 + -1;
}
bb_7 (preds = {bb_5 bb_3 }, succs = {bb_8 })
{
bb 7:
# .MEM_30 = PHI .MEM_29(5), .MEM_8(3)
# VUSE .MEM_30
res_32 = Close_Phi.6[0];
# .MEM_33 = VDEF .MEM_30
Cross_BB_scalar_dependence.7[0] = res_32;
# VUSE .MEM_33
res_17 = Cross_BB_scalar_dependence.7[0];
_16 = res_17;
}
bb_8 (preds = {bb_7 bb_2 }, succs = {bb_1 })
{
bb 8:
# res_12 = PHI _16(7), 0(2)
# .MEM_2 = PHI .MEM_33(7), .MEM_3(D)(2)
# VUSE .MEM_2
return res_12;
}
loop_2 (header = 5, latch = 6, niter = (unsigned long) ((signed
long) k.0_9 + -1), upper_bound = 9223372036854775806)
{
bb_5 (preds = {bb_4 bb_6 }, succs = {bb_6 bb_7 })
{
bb 5:
# graphite_IV.8_23 = PHI 0(4), graphite_IV.8_24(6)
# .MEM_31 = PHI .MEM_8(4), .MEM_29(6)
# VUSE .MEM_31
res_25 = phi_out_of_ssa.5[0];
_27 = (int) graphite_IV.8_23;
res_26 = res_25 + _27;
# .MEM_28 = VDEF .MEM_31
Close_Phi.6[0] = res_26;
# .MEM_29 = VDEF .MEM_28
phi_out_of_ssa.5[0] = res_26;
graphite_IV.8_24 = graphite_IV.8_23 + 1;
if (graphite_IV.8_23 _22)
goto bb 6;
else
goto bb 7;
}
bb_6 (preds = {bb_5 }, succs = {bb_5 })
{
bb 6:
goto bb 5;
}
}
}
It is similar to the original code:
loop_0 (header = 0, latch = 1, niter = )
{
bb_2 (preds = {bb_0 }, succs = {bb_3 bb_8 })
{
bb 2:
# VUSE .MEM_3(D)
k.0_9 = k;
if (k.0_9 0)
goto bb 3;
else
goto bb 8;
}
bb_3 (preds = {bb_2 }, succs = {bb_5 })
{
bb 3:
# .MEM_8 = VDEF .MEM_3(D)
phi_out_of_ssa.5[0] = 0;
goto bb 5;
}
bb_4 (preds = {bb_7 }, succs = {bb_8 })
{
bb 4:
# .MEM_19 = PHI .MEM_18(7)
# VUSE .MEM_19
res_17 = Cross_BB_scalar_dependence.7[0];
_16 = res_17;
goto bb 8;
}
bb_7 (preds = {bb_5 }, succs = {bb_4 })
{
bb 7:
# VUSE .MEM_13
res_4 = Close_Phi.6[0];
# .MEM_18 = VDEF .MEM_13
Cross_BB_scalar_dependence.7[0] = res_4;
goto bb 4;
}
bb_8 (preds = {bb_4 bb_2 }, succs = {bb_1 })
{
bb 8:
# res_12 = PHI _16(4), 0(2)
# .MEM_2 = PHI .MEM_19(4), .MEM_3(D)(2)
# VUSE .MEM_2
return res_12;
}
loop_1 (header = 5, latch = 6, niter = , upper_bound = 2147483646)
{
bb_5 (preds = {bb_3 bb_6 }, succs = {bb_6 bb_7 })
{
bb 5:
# i_10 = PHI 0(3), i_6(6)
# .MEM_1 = PHI .MEM_8(3), .MEM_13(6)
# VUSE .MEM_1
res_11 = phi_out_of_ssa.5[0];
res_5 = res_11 + i_10;
# .MEM_7 = VDEF .MEM_1
Close_Phi.6[0] = res_5;
# .MEM_13 = VDEF .MEM_7
phi_out_of_ssa.5[0] = res_5;
i_6 = i_10 + 1;
if (i_6 k.0_9)
goto bb 6;
else
goto bb 7;
}
bb_6 (preds = {bb_5 }, succs = {bb_5 })
{
bb 6:
goto bb 5;
}
}
}
If we change the name of variable k to n:
int n = 50;
static int __attribute__((noinline))
foo ()
{
int i, res;
for (i = 0, res = 0; i n; i++)
res += i;
return res;
}
extern void abort ();
int
main (void)
{
int res = foo ();
if (res != 1225)
abort ();
return 0;
}
the following code will be produced, which gives wrong result
ISL AST generated by ISL:
{
S_6();
for (int c1 = 0; c1 n.0; c1 += 1)
S_4(c1);
}
It seems S_6 is now scheduled before S_4 which is surprising, as
dependences from S_4 to S_6 should prevent us from generating a schedule
that yields such a result. What is the schedule that you give to the isl
ast generator?
Cheers,
Tobias
P.S.: The patch looks good by itself, but needs some test cases. As you
have them in this email, we can just add them after we understood this bug.
Re: [GSoC] generation of Gimple code from isl_ast_node_block
It seems S_6 is now scheduled before S_4 which is surprising, as
dependences from S_4 to S_6 should prevent us from generating a schedule
that yields such a result. What is the schedule that you give to the isl ast
generator?
The schedule generated by the code, which uses variable k (It executes
without errors):
[k.0] - { S_6[] - [1] : exists (e0 = [(-1 + k.0)/4294967296]:
4294967296e0 = -1 + k.0 and 4294967296e0 = -2147483647 + k.0);
S_4[i0] - [0, i0, 0] : exists (e0 = [(-1 + k.0)/4294967296]: i0 = 0
and 4294967296e0 = -1 + k.0 and 4294967296e0 = -4294967296 + k.0 and
4294967296e0 = -1 + k.0 - i0 and i0 = 2147483646) }
The schedule generated by the code, which uses variable n:
[n.0] - { S_6[] - [1] : exists (e0 = [(-1 + n.0)/4294967296]:
4294967296e0 = -1 + n.0 and 4294967296e0 = -2147483647 + n.0);
S_4[i0] - [0, i0, 0] : exists (e0 = [(-1 + n.0)/4294967296]: i0 = 0
and 4294967296e0 = -1 + n.0 and 4294967296e0 = -4294967296 + n.0 and
4294967296e0 = -1 + n.0 - i0 and i0 = 2147483646) }
--
Cheers, Roman Gareev.
Re: [GSoC] Question about the implementation of vec.h
On Mon, Jul 21, 2014 at 5:22 AM, Roman Gareev gareevro...@gmail.com wrote: Dear gcc contributors, could you please answer a few questions about the implementation of vec.h? Should we always use “create” to initialize, for example, vectree_node* or is it possible to do it using “safe_grow_cleared” or a similar function? There is vec_safe_grow_cleared, which works with vecT, A, vl_embed. Is there a way to use it with vectree_node*? Yes, you need to use .create() to initialize vec instances. Diego.
Re: [GSoC] generation of Gimple code from isl_ast_node_block
On 21/07/2014 14:55, Roman Gareev wrote:
It seems S_6 is now scheduled before S_4 which is surprising, as
dependences from S_4 to S_6 should prevent us from generating a schedule
that yields such a result. What is the schedule that you give to the isl ast
generator?
The schedule generated by the code, which uses variable k (It executes
without errors):
[k.0] - { S_6[] - [1] : exists (e0 = [(-1 + k.0)/4294967296]:
4294967296e0 = -1 + k.0 and 4294967296e0 = -2147483647 + k.0);
S_4[i0] - [0, i0, 0] : exists (e0 = [(-1 + k.0)/4294967296]: i0 = 0
and 4294967296e0 = -1 + k.0 and 4294967296e0 = -4294967296 + k.0 and
4294967296e0 = -1 + k.0 - i0 and i0 = 2147483646) }
The schedule generated by the code, which uses variable n:
[n.0] - { S_6[] - [1] : exists (e0 = [(-1 + n.0)/4294967296]:
4294967296e0 = -1 + n.0 and 4294967296e0 = -2147483647 + n.0);
S_4[i0] - [0, i0, 0] : exists (e0 = [(-1 + n.0)/4294967296]: i0 = 0
and 4294967296e0 = -1 + n.0 and 4294967296e0 = -4294967296 + n.0 and
4294967296e0 = -1 + n.0 - i0 and i0 = 2147483646) }
Perfect. The problem is that S_6 has a one-dimensional schedule [1] and
S_4 has a three dimensional schedule [0,i0,0]. For schedules with
different dimensionality, the isl AST generator can not define an order
and just randomly chooses an order. The solution to this problem is to
extend all schedules to the maximal number of schedule dimensions (using
'0's for the remaining values).
Search for the function extend_scattering() (its implementation is
unnecessarily verbose and could possibly simplified by using
isl_*_equate or isl_*fix*).
Cheers,
Tobias
Re: GCC version bikeshedding
On 20/07/14 22:28, Andi Kleen wrote: Paulo Matospa...@matos-sorge.com writes: That's what I understood as well. Someone mentioned to leave the patch level number to the distros to use which sounded like a good idea. Sounds like a bad idea, as then there would be non unique gcc versions. redhat gcc 5.0.2 potentially being completely different from suse gcc 5.0.2 Agreed (no experience, but I wouldn't want to live in a world where what Andi describes is the case!) -Andi What is Bikeshedding? I've not heard this term before and a quick search showed some weird things, and this very thread! Alec
Re: GCC version bikeshedding
On Mon, Jul 21, 2014 at 10:30 AM, Alec Teal a.t...@warwick.ac.uk wrote: Agreed (no experience, but I wouldn't want to live in a world where what Andi describes is the case!) We already live in that world. This would not change that. I quite like the proposal. What is Bikeshedding? I've not heard this term before and a quick search showed some weird things, and this very thread! Derived from Parkinson's Law of Triviality (http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality). Boils down to giving more weight to trivial aspects of a discussion. Diego.
[Copyright transfer] What to do for copyright transfer to FSF for contracted changes?
Hi, I am a freelancer contracted to fix some bugs in the fortran compiler. I understand that I need to transfer the copyright of that effort to the FSF. My client and me are willing to sign any paperwork needed for that. Unfortunately my client will be on holiday from Thursday on. What do I need to do transfer the copyright of the changes I am contracted to - which partially are already done and in discussion (see for example PR 60414: Patch proposal on the fortran and gcc-patches list) and for some to come - to FSF? Sorry, for the bother. I did not find anything on the web besides https://gcc.gnu.org/contribute.html#legal which is somewhat unclear to me being none-native English speaker. Regards, Andre -- Andre Vehreschild
Re: Some __builtin_round and cast subtleties
On Fri, 4 Jul 2014, Kyrill Tkachov wrote: These end up taking different codepaths through the compiler () because __builtin_lround has to take -fmath-errno into account and does not end up getting inlined (generating a call to the library lround). That suggests this transformation is buggy unless -fno-math-errno is used (given the existence of cases where round + cast must not set errno, but lround may). A bug should be filed in Bugzilla for this. -- Joseph S. Myers jos...@codesourcery.com
[gomp4] Offloading wiki page
Hi, I've created a wiki page about offloading. Any improvements are welcome. https://gcc.gnu.org/wiki/Offloading Thanks, -- Ilya
Re: GCC version bikeshedding
Was this a Cauldron thing? Could you summarise it for the people who weren't there? I don't strongly object, but it seems like unnecessary churn (especially in terms of user expectations). Yeah, bumping the major version number every year is a bit ridiculous. Not as ridiculous as Firefox, but still. -- Eric Botcazou
gcc 4.9 Very slow
Hi list When I compare gcc 4.8 in gcc 4.9 gcc 4.9 Very slow When I use g++
Question for ARM person re asm_fprintf
I have been looking at asm_fprintf in final.c, and I think there's a
design flaw. But since the change affects ARM and since I have no
access to an ARM system, I need a second opinion.
asm_fprintf allows platforms to add support for new format specifiers by
using the ASM_FPRINTF_EXTENSIONS macro. ARM uses this to add support
for %@ and %r specifiers. Pretty straight-forward.
However, it isn't enough to add these two items to the case statement in
asm_fprintf. Over in c-format.c, there is compile-time checking that is
done against calls to asm_fprintf to validate the format string. %@ and
%r have been added to this checking (see asm_fprintf_char_table), but
NOT in a platform-specific way.
This means that using %r or %@ will successfully pass the format
checking on all platforms, but will ICE on non-ARM platforms since there
are no case statements in asm_fprintf to support them.
Compiling the code in asm_fprintf-1.c (see the patch) with this patch
correctly reports unknown conversion type character for both 'r' and
'@' in x86_64-pc-cygwin. It would be helpful if someone could confirm
that it still compiles without error under ARM after applying this
patch. I'm reluctant to post this to gcc-patches when it has never been
run.
dw
Index: gcc/c-family/c-format.c
===
--- gcc/c-family/c-format.c (revision 212900)
+++ gcc/c-family/c-format.c (working copy)
@@ -637,8 +637,9 @@
{ I, 0, STD_C89, NOARGUMENTS, , , NULL },
{ L, 0, STD_C89, NOARGUMENTS, , , NULL },
{ U, 0, STD_C89, NOARGUMENTS, , , NULL },
- { r, 0, STD_C89, { T89_I, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, , , NULL },
- { @, 0, STD_C89, NOARGUMENTS, , , NULL },
+#ifdef ASM_FPRINTF_TABLE
+ ASM_FPRINTF_TABLE
+#endif
{ NULL, 0, STD_C89, NOLENGTHS, NULL, NULL, NULL }
};
Index: gcc/config/arm/arm.h
===
--- gcc/config/arm/arm.h (revision 212900)
+++ gcc/config/arm/arm.h (working copy)
@@ -888,6 +888,12 @@
fputs (reg_names [va_arg (ARGS, int)], FILE); \
break;
+/* Used in c-format.c to add entries to the table used to validate calls
+ to asm_fprintf. */
+#define ASM_FPRINTF_TABLE \
+ { r, 0, STD_C89, { T89_I, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, , , NULL }, \
+ { @, 0, STD_C89, NOARGUMENTS, , , NULL },
+
/* Round X up to the nearest word. */
#define ROUND_UP_WORD(X) (((X) + 3) ~3)
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 212900)
+++ gcc/doc/tm.texi (working copy)
@@ -8611,8 +8611,39 @@
The varargs input pointer is @var{argptr} and the rest of the format
string, starting the character after the one that is being switched
upon, is pointed to by @var{format}.
+See also ASM_FPRINTF_TABLE.
+
+Example:
+@smallexample
+#define ASM_FPRINTF_EXTENSIONS(FILE, ARGS, P) \
+ case '@': \
+fputs (ASM_COMMENT_START, FILE); \
+break; \
+ \
+ case 'r': \
+fputs (REGISTER_PREFIX, FILE); \
+fputs (reg_names [va_arg (ARGS, int)], FILE); \
+break;
+@end smallexample
@end defmac
+@defmac ASM_FPRINTF_TABLE
+When using ASM_FPRINTF_EXTENSIONS, you must also use this macro to define
+table entries for the printf format checking performed in c-format.c.
+This macro must contain format_char_info entries for each printf format
+being added.
+
+Example:
+@smallexample
+#define ASM_FPRINTF_TABLE \
+ @{ r, 0, STD_C89, \
+ @{ T89_I, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, \
+ BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN @}, \
+ , , NULL @}, \
+ @{ @, 0, STD_C89, NOARGUMENTS, , , NULL @},
+@end smallexample
+@end defmac
+
@defmac ASSEMBLER_DIALECT
If your target supports multiple dialects of assembler language (such as
different opcodes), define this macro as a C expression that gives the
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in (revision 212900)
+++ gcc/doc/tm.texi.in (working copy)
@@ -6370,8 +6370,39 @@
The varargs input pointer is @var{argptr} and the rest of the format
string, starting the character after the one that is being switched
upon, is pointed to by @var{format}.
+See also ASM_FPRINTF_TABLE.
+
+Example:
+@smallexample
+#define ASM_FPRINTF_EXTENSIONS(FILE, ARGS, P) \
+ case '@': \
+fputs (ASM_COMMENT_START, FILE); \
+break; \
+ \
+ case 'r': \
+fputs (REGISTER_PREFIX, FILE); \
+fputs (reg_names [va_arg (ARGS, int)], FILE); \
+break;
+@end smallexample
@end defmac
+@defmac ASM_FPRINTF_TABLE
+When using ASM_FPRINTF_EXTENSIONS, you must also use this macro to define
+table entries for the printf format checking performed in
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #17 from Joshua Kinard kumba at gentoo dot org --- (In reply to Joshua Kinard from comment #16) In 'all-stage2-gcc'. That's right around the commit you're referencing, so I went ahead and reversed these four commits: 1. 39a8c5eaded1e5771a941c56a49ca0a5e9c5eca0 * config/mips/mips.c (mips_emit_pre_atomic_barrier_p,) 2. 974f0a74e2116143b88d8cea8e1dd5a9c18ef96c * config/mips/constraints.md (ZR): New constraint. 3. 0f8e46b16a53c02d7255dcd6b6e9b5bc7f8ec953 * config/mips/mips.c (mips_process_sync_loop): Emit cmp result only if 4. 30c3c4427521f96fb58b6e1debb86da4f113f06f * emit-rtl.c (need_atomic_barrier_p): New function. Already mentioned to Andrew on IRC, but reversing these four commits solves the problem, but I am still not sure why it affects R1x000 CPUs. I can upload the static binaries of 'sln' for someone to look at if they'd like.
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 Joshua Kinard kumba at gentoo dot org changed: What|Removed |Added Component|c++ |regression Version|4.9.0 |4.8.0 See Also||https://bugs.gentoo.org/sho ||w_bug.cgi?id=516548 Summary|g++ compiled binary, linked |gcc after commit 39a8c5ea |to glibc libpthread, hangs |produces bad code for MIPS |on SGI MIPS R1x000 systems |R1x000 CPUs |on Linux| --- Comment #18 from Joshua Kinard kumba at gentoo dot org --- Known to work: Prior to commit 39a8c5ea (2012-06-19) Known to fail: Anything after commits 39a8c5ea, 974f0a74, 0f8e46b1, and 30c3c442 (2012-06-20)
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||mikael at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #30 from Dominique d'Humieres dominiq at lps dot ens.fr --- A trivial workaround is to replace call process_configuration (new_prt_spec ([prt_in])) by call process_configuration ([new_prt_spec (prt_in)]) Confirmed. However, nevertheless you would want to understand why the elemental function causes a malloc crash for dim 1 arrays and works for scalars and dim 1 arrays as input. Indeed, but I'll need some help!
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-21 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 33164 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33164action=edit Patch that moves defines out of #ifdef __OPTIMIZE__ Somehow obvious patch.
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Target Milestone|--- |4.9.2
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #19 from Joshua Kinard kumba at gentoo dot org --- Created attachment 33165 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33165action=edit Disassembly of the ASM from 'sln' compiled by a known working gcc-4.8.0. This is the objdump disassembly of the '__lll_lock_wait_private()' function from the sln binary from glibc, statically compiled, by a GOOD gcc-4.8.0 checkout (7882e02e) with commits 39a8c5ea, 974f0a74, 0f8e46b1, and 30c3c442 reversed.
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #20 from Joshua Kinard kumba at gentoo dot org --- Created attachment 33166 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33166action=edit Disassembly of the ASM from 'sln' compiled by a non-working gcc-4.8.0. This is the objdump disassembly of the '__lll_lock_wait_private()' function from the sln binary from glibc, statically compiled, by a BAD gcc-4.8.0 checkout (7882e02e) no previous commits reversed. This sln copy will hang trying to print usage instructions.
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Author: uros Date: Mon Jul 21 08:47:48 2014 New Revision: 212886 URL: https://gcc.gnu.org/viewcvs?rev=212886root=gccview=rev Log: PR target/61855 * config/i386/avx512fintrin.h: Move constants for mantissa extraction out of #ifdef __OPTIMIZE__. testsuite/ChangeLog: PR target/61855 * gcc.target/i386/pr61855.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr61855.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 --- Comment #2 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jul 21 09:11:04 2014 New Revision: 212888 URL: https://gcc.gnu.org/viewcvs?rev=212888root=gccview=rev Log: Fix fuse-caller-save-xmm.c test-case 2014-07-21 Tom de Vries t...@codesourcery.com PR target/61827 * gcc.target/i386/fuse-caller-save-xmm.c: Add -fomit-frame-pointer to dg-options. Add checks for insns with xmm registers. Remove cfi_def_cfa_offset checks. Generalize checks containing %rsp. (main): Remove. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from vries at gcc dot gnu.org --- patch committed, fixed.
[Bug go/61865] New: FAIL: go.test/test/fixedbugs/bug272.go execution, -O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61865 Bug ID: 61865 Summary: FAIL: go.test/test/fixedbugs/bug272.go execution, -O2 -g Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ubizjak at gmail dot com CC: cmang at google dot com The go.test/test/fixedbugs/bug272.go fails execution on 32bit x86 targets (Fedora 20): ./bug272.x BUG2 The testcase works OK in 64bit x86_64.
[Bug go/61866] New: FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61866 Bug ID: 61866 Summary: FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ubizjak at gmail dot com CC: cmang at google dot com index0-out.go fails execution with -O0 -g -fno-var-tracking-assignments on 32bit x86 target (Fedora 20) with: BUG ./index0-out.go:113: ai[i64bigger] did not panic ./index0-out.go:113: ai[i64bigger:] did not panic ./index0-out.go:113: ai[ni64bigger] did not panic ./index0-out.go:113: ai[ni64bigger:] did not panic ./index0-out.go:113: ai[nhuge] did not panic ./index0-out.go:113: ai[nhuge:] did not panic ./index0-out.go:113: aib[i64bigger] did not panic ./index0-out.go:113: aib[i64bigger:] did not panic ./index0-out.go:113: aib[ni64bigger] did not panic ./index0-out.go:113: aib[ni64bigger:] did not panic ./index0-out.go:113: aib[nhuge] did not panic ./index0-out.go:113: aib[nhuge:] did not panic ./index0-out.go:113: aq[i64bigger] did not panic ./index0-out.go:113: aq[i64bigger:] did not panic ./index0-out.go:113: aq[ni64bigger] did not panic ./index0-out.go:113: aq[ni64bigger:] did not panic ./index0-out.go:113: aq[nhuge] did not panic ./index0-out.go:113: aq[nhuge:] did not panic ./index0-out.go:113: aqb[i64bigger] did not panic ./index0-out.go:113: aqb[i64bigger:] did not panic ./index0-out.go:113: aqb[ni64bigger] did not panic ./index0-out.go:113: aqb[ni64bigger:] did not panic ./index0-out.go:113: aqb[nhuge] did not panic ./index0-out.go:113: aqb[nhuge:] did not panic ./index0-out.go:113: pai[i64bigger] did not panic ./index0-out.go:113: pai[i64bigger:] did not panic ./index0-out.go:113: pai[ni64bigger] did not panic ./index0-out.go:113: pai[ni64bigger:] did not panic ./index0-out.go:113: pai[nhuge] did not panic ./index0-out.go:113: pai[nhuge:] did not panic ./index0-out.go:113: paib[i64bigger] did not panic ./index0-out.go:113: paib[i64bigger:] did not panic ./index0-out.go:113: paib[ni64bigger] did not panic ./index0-out.go:113: paib[ni64bigger:] did not panic ./index0-out.go:113: paib[nhuge] did not panic ./index0-out.go:113: paib[nhuge:] did not panic ./index0-out.go:113: paq[i64bigger] did not panic ./index0-out.go:113: paq[i64bigger:] did not panic ./index0-out.go:113: paq[ni64bigger] did not panic ./index0-out.go:113: paq[ni64bigger:] did not panic ./index0-out.go:113: paq[nhuge] did not panic ./index0-out.go:113: paq[nhuge:] did not panic ./index0-out.go:113: paqb[i64bigger] did not panic ./index0-out.go:113: paqb[i64bigger:] did not panic ./index0-out.go:113: paqb[ni64bigger] did not panic ./index0-out.go:113: paqb[ni64bigger:] did not panic ./index0-out.go:113: paqb[nhuge] did not panic ./index0-out.go:113: paqb[nhuge:] did not panic ./index0-out.go:113: si[i64bigger] did not panic ./index0-out.go:113: si[i64bigger:] did not panic ./index0-out.go:113: si[ni64bigger] did not panic ./index0-out.go:113: si[ni64bigger:] did not panic ./index0-out.go:113: si[nhuge] did not panic ./index0-out.go:113: si[nhuge:] did not panic ./index0-out.go:113: sib[i64bigger] did not panic ./index0-out.go:113: sib[i64bigger:] did not panic ./index0-out.go:113: sib[ni64bigger] did not panic ./index0-out.go:113: sib[ni64bigger:] did not panic ./index0-out.go:113: sib[nhuge] did not panic ./index0-out.go:113: sib[nhuge:] did not panic ./index0-out.go:113: sq[i64bigger] did not panic ./index0-out.go:113: sq[i64bigger:] did not panic ./index0-out.go:113: sq[ni64bigger] did not panic ./index0-out.go:113: sq[ni64bigger:] did not panic ./index0-out.go:113: sq[nhuge] did not panic ./index0-out.go:113: sq[nhuge:] did not panic ./index0-out.go:113: sqb[i64bigger] did not panic ./index0-out.go:113: sqb[i64bigger:] did not panic ./index0-out.go:113: sqb[ni64bigger] did not panic ./index0-out.go:113: sqb[ni64bigger:] did not panic ./index0-out.go:113: sqb[nhuge] did not panic ./index0-out.go:113: sqb[nhuge:] did not panic ./index0-out.go:113: t.ai[i64bigger] did not panic ./index0-out.go:113: t.ai[i64bigger:] did not panic ./index0-out.go:113: t.ai[ni64bigger] did not panic ./index0-out.go:113: t.ai[ni64bigger:] did not panic ./index0-out.go:113: t.ai[nhuge] did not panic ./index0-out.go:113: t.ai[nhuge:] did not panic ./index0-out.go:113: t.aib[i64bigger] did not panic ./index0-out.go:113: t.aib[i64bigger:] did not panic ./index0-out.go:113: t.aib[ni64bigger] did not panic ./index0-out.go:113: t.aib[ni64bigger:] did not panic ./index0-out.go:113: t.aib[nhuge] did not panic ./index0-out.go:113: t.aib[nhuge:] did not panic ./index0-out.go:113: t.aq[i64bigger] did not panic ./index0-out.go:113: t.aq[i64bigger:] did not panic ./index0-out.go:113: t.aq[ni64bigger] did not panic ./index0-out.go:113: t.aq[ni64bigger:] did not panic ./index0-out.go:113: t.aq[nhuge] did
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The following patch
--- ../_clean/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
2014-07-21 11:21:30.0 +0200
+++ gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c2014-07-21
11:44:24.0 +0200
@@ -17,7 +17,7 @@ foo (v2df y)
/* Check presence of all insns on xmm registers. These checks are expected to
pass with both -fuse-caller-save and -fno-use-caller-save. */
-/* { dg-final { scan-assembler-times addpd\t\\.LC0.*, %xmm0 1 } } */
+/* { dg-final { scan-assembler-times addpd\t\\.?LC0.*, %xmm0 1 } } */
/* { dg-final { scan-assembler-times addpd\t%xmm1, %xmm0 1 } } */
/* { dg-final { scan-assembler-times movapd\t%xmm0, %xmm1 1 } } */
is needed for darwin (addpdLC0(%rip), %xmm0).
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Mon Jul 21 10:09:04 2014 New Revision: 212889 URL: https://gcc.gnu.org/viewcvs?rev=212889root=gccview=rev Log: Backport from mainline 2014-07-21 Uros Bizjak ubiz...@gmail.com PR target/61855 * config/i386/avx512fintrin.h: Move constants for mantissa extraction out of #ifdef __OPTIMIZE__. testsuite/ChangeLog: Backport from mainline 2014-07-21 Uros Bizjak ubiz...@gmail.com PR target/61855 * gcc.target/i386/pr61855.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61855.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/avx512fintrin.h branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- Fixed.
[Bug c++/61863] Data corruption when creating temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61863 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- When compiled with g++ 4.9.1 or 4.7.4 I see Length in printLen= 8 when running the executable, but with g++ 4.8.3 I see Length in printLen= 0
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827
--- Comment #5 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Dominique d'Humieres from comment #4)
The following patch
--- ../_clean/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
2014-07-21 11:21:30.0 +0200
+++ gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c 2014-07-21
11:44:24.0 +0200
@@ -17,7 +17,7 @@ foo (v2df y)
/* Check presence of all insns on xmm registers. These checks are expected
to
pass with both -fuse-caller-save and -fno-use-caller-save. */
-/* { dg-final { scan-assembler-times addpd\t\\.LC0.*, %xmm0 1 } } */
+/* { dg-final { scan-assembler-times addpd\t\\.?LC0.*, %xmm0 1 } } */
/* { dg-final { scan-assembler-times addpd\t%xmm1, %xmm0 1 } } */
/* { dg-final { scan-assembler-times movapd\t%xmm0, %xmm1 1 } } */
is needed for darwin (addpd LC0(%rip), %xmm0).
Looks OK, please commit.
[Bug c++/61867] New: gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867
Bug ID: 61867
Summary: gcc can't detect obviously false test
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
I just tried the following code on trunk 20140720
extern int g(int);
void f( int n)
{
int i;
i = g( n) 0x02;
if (i == 1)
g( 2);
}
$ ~/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -pedantic -ansi jul21a.cc
$
so gcc has nothing to say about it. Here is cppcheck, a static analyser,
finding the problem
$ ~/cppcheck/trunk/cppcheck --enable=all jul21a.cc
Checking jul21a.cc...
[jul21a.cc:8] - [jul21a.cc:10]: (style) Mismatching assignment and comparison,
comparison 'i==1' is always false.
$
I note that about six bugs in the linux kernel and about 40 bugs in
Fedora Linux would be detected by implementing this fix.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #31 from Dominique d'Humieres dominiq at lps dot ens.fr --- Further reduced test program main implicit none type :: string_t character(LEN=1), dimension(:), allocatable :: chars end type string_t type(string_t) :: prt_in, tmp(1) integer :: i prt_in = string_t([W]) do i = 1, 16 print *, i tmp = new_prt_spec ([prt_in]) end do contains elemental function new_prt_spec (name) result (prt_spec) type(string_t), intent(in) :: name type(string_t) :: prt_spec end function new_prt_spec end program main However, nevertheless you would want to understand why the elemental function causes a malloc crash for dim 1 arrays and works for scalars and dim 1 arrays as input. The faulty block is not used for scalars.
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 --- Comment #6 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jul 21 10:54:47 2014 New Revision: 212890 URL: https://gcc.gnu.org/viewcvs?rev=212890root=gccview=rev Log: Fix fuse-caller-save test-cases 2014-07-21 Tom de Vries t...@codesourcery.com PR target/61827 * gcc.target/i386/fuse-caller-save-xmm.c: Allow LC0 without dot prefix for darwin in scan-assembler-times check. * gcc.target/i386/fuse-caller-save.c: Remove cfi-related scan-assembler-not checks. Add checks for insns. (main): Remove. * gcc.target/i386/fuse-caller-save-rec.c: Remove cfi-related scan-assembler-not checks. Copy checks from i386/fuse-caller-save.c. (main): Remove. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Sorry, another patch for darwin (call_bar)
--- ../_clean/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
2014-07-21 13:09:41.0 +0200
+++ gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c2014-07-21
13:11:54.0 +0200
@@ -26,5 +26,5 @@ foo (int y)
/* { dg-final { scan-assembler-times addl\t%\[re\]?dx, %\[re\]?ax 1 } } */
/* Verify that bar is self-recursive. */
-/* { dg-final { scan-assembler-times call\tbar 2 } } */
+/* { dg-final { scan-assembler-times call\t_?bar 2 } } */
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 --- Comment #8 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jul 21 11:29:10 2014 New Revision: 212891 URL: https://gcc.gnu.org/viewcvs?rev=212891root=gccview=rev Log: Fix fuse-caller-save-rec.c 2014-07-21 Tom de Vries t...@codesourcery.com PR target/61827 * gcc.target/i386/fuse-caller-save-rec.c: Allow underscore prefix to bar symbol in scan-assembler-times call check. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- New Revision: 212891 ... Thanks!
[Bug target/55701] Inline some instances of memset for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701 --- Comment #3 from amker at gcc dot gnu.org --- Author: amker Date: Mon Jul 21 12:24:06 2014 New Revision: 212893 URL: https://gcc.gnu.org/viewcvs?rev=212893root=gccview=rev Log: PR target/55701 * config/arm/arm.md (setmem): New pattern. * config/arm/arm-protos.h (struct tune_params): New fields. (arm_gen_setmem): New prototype. * config/arm/arm.c (arm_slowmul_tune): Initialize new fields. (arm_fastmul_tune, arm_strongarm_tune, arm_xscale_tune): Ditto. (arm_9e_tune, arm_v6t2_tune, arm_cortex_tune): Ditto. (arm_cortex_a8_tune, arm_cortex_a7_tune): Ditto. (arm_cortex_a15_tune, arm_cortex_a53_tune): Ditto. (arm_cortex_a57_tune, arm_cortex_a5_tune): Ditto. (arm_cortex_a9_tune, arm_cortex_a12_tune): Ditto. (arm_v7m_tune, arm_v6m_tune, arm_fa726te_tune): Ditto. (arm_const_inline_cost): New function. (arm_block_set_max_insns): New function. (arm_block_set_non_vect_profit_p): New function. (arm_block_set_vect_profit_p): New function. (arm_block_set_unaligned_vect): New function. (arm_block_set_aligned_vect): New function. (arm_block_set_unaligned_non_vect): New function. (arm_block_set_aligned_non_vect): New function. (arm_block_set_vect, arm_gen_setmem): New functions. * gcc.target/arm/memset-inline-1.c: New test. * gcc.target/arm/memset-inline-2.c: New test. * gcc.target/arm/memset-inline-3.c: New test. * gcc.target/arm/memset-inline-4.c: New test. * gcc.target/arm/memset-inline-5.c: New test. * gcc.target/arm/memset-inline-6.c: New test. * gcc.target/arm/memset-inline-7.c: New test. * gcc.target/arm/memset-inline-8.c: New test. * gcc.target/arm/memset-inline-9.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/memset-inline-1.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-2.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-3.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-4.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-5.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-6.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-7.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-8.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Ian Lance Taylor from comment #2) The patch is committed so this bug may be fixed. I haven't tested it on Alpha, though. The testcase recover.go doesn't fail outright with not-implemented error. However, tests test11reflect2, test13reflect2 and test14reflect2 currently fail.
[Bug c++/61867] gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I'm pretty sure gcc does detect it and optimizes appropriately, it just doesn't warn (because it's not a static analyzer)
[Bug driver/61868] New: -frandom-seed always results in random_seed of 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61868
Bug ID: 61868
Summary: -frandom-seed always results in random_seed of 0
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: bmei at broadcom dot com
Compile any simple file with -frandom-seed and -flto option.
#include stdio.h
extern int foo (int);
int bar (int a)
{
return a * 5;
}
int main ()
{
printf(%d\n, foo (100));
return 0;
}
~/scratch/install-x86/bin/gcc tst2.c -flto -c -frandom-seed=12345
objdump -D tst2.o|less
You can see all the lto section has suffix of 0 instead of the random_seed
specified.
.gnu.lto_.inline.0
This is because of the following code in toplev.c. If flag_random_seed is true,
then init_random_seed is not called in get_random_seed despite the piece of
code trying to generate random_seed if flag_random_seed is true.
static void
init_random_seed (void)
{
if (flag_random_seed)
{
char *endp;
/* When the driver passed in a hex number don't crc it again */
random_seed = strtoul (flag_random_seed, endp, 0);
if (!(endp flag_random_seed *endp == 0))
random_seed = crc32_string (0, flag_random_seed);
}
else if (!random_seed)
random_seed = local_tick ^ getpid (); /* Old racey fallback method */
}
/* Obtain the random_seed. Unless NOINIT, initialize it if
it's not provided in the command line. */
HOST_WIDE_INT
get_random_seed (bool noinit)
{
if (!flag_random_seed !noinit)
init_random_seed ();
return random_seed;
}
[Bug tree-optimization/61869] New: Spurious uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61869 Bug ID: 61869 Summary: Spurious uninitialized warning Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: y.gribov at samsung dot com CC: jakub at gcc dot gnu.org Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Created attachment 33167 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33167action=edit Reprocase Current gcc reports spurious warning on attached code (based upon gcc/asan.c with some local changes): $ g++ repro.i -c -Wmaybe-uninitialized -O2 /home/ygribov/repro.i: In function ‘void f(list*)’: /home/ygribov/repro.i:30:12: warning: ‘i’ may be used uninitialized in this function [-Wmaybe-uninitialized] iterator i; ^ /home/ygribov/repro.i:30:12: warning: ‘*((void*) i +8)’ may be used uninitialized in this function [-Wmaybe-uninitialized] It looks like lim1 pass exploits conditional NULL dereference in start() and introduces read of uninitialized variable.
[Bug c++/61870] New: internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61870
Bug ID: 61870
Summary: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dzidzitop at vfemail dot net
When I compile source code I see the following error.
src/lastfm_scrobbler.cpp: In lambda function:
src/lastfm_scrobbler.cpp:193:1: internal compiler error: in get_expr_operands,
at tree-ssa-operands.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/cc6F4c5e.out file, please attach this to
your bugreport.
The line that does not compile is:
m_scrobblingThread = std::thread([this]() { backgroundScrobbling(); });
The following change fixes this:
m_scrobblingThread = std::thread([this]() { this-backgroundScrobbling(); });
[Bug c++/61870] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61870 --- Comment #1 from dzidzitop at vfemail dot net --- Created attachment 33168 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33168action=edit The preprocessed file.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #3)
(In reply to Ian Lance Taylor from comment #2)
The patch is committed so this bug may be fixed. I haven't tested it on
Alpha, though.
The testcase recover.go doesn't fail outright with not-implemented error.
However, tests test11reflect2, test13reflect2 and test14reflect2 currently
fail.
The problem with test11reflect2 was due to unhandled FFI_TYPE_VOID case in
ffi_closure_osf_inner, fixed by following patch:
--cut here-
Index: src/alpha/ffi.c
===
--- src/alpha/ffi.c (revision 212882)
+++ src/alpha/ffi.c (working copy)
@@ -237,6 +237,7 @@ ffi_closure_osf_inner(ffi_closure *closure, void *
switch (arg_types[i]-type)
{
+ case FFI_TYPE_VOID:
case FFI_TYPE_SINT8:
case FFI_TYPE_UINT8:
case FFI_TYPE_SINT16:
--cut here--
It looks that test13reflect2 and test14reflect2 tests fail on non-split stack
targets, since everything works OK with slightly modified testcase:
--cut here--
Index: testsuite/go.test/test/recover.go
===
--- testsuite/go.test/test/recover.go (revision 212882)
+++ testsuite/go.test/test/recover.go (working copy)
@@ -432,7 +432,7 @@
}
// enormous receiver, so wrapper splits stack to call M
-type T5 [8192]byte
+type T5 [2048]byte
func (T5) M() {
mustRecoverBody(doubleRecover(), recover(), recover(), 13)
@@ -459,12 +459,12 @@
// enormous receiver + enormous method frame, so wrapper splits stack to call
M,
// and then M splits stack to allocate its frame.
// recover must look back two frames to find the panic.
-type T6 [8192]byte
+type T6 [2048]byte
var global byte
func (T6) M() {
- var x [8192]byte
+ var x [2048]byte
x[0] = 1
x[1] = 2
for i := range x {
--cut here--
It looks that the later problem points to a generic problem with non
split-stack targets.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- I forgot to tell that reflect test from libgo testsuite now passes: PASS: reflect
[Bug go/61871] New: FAIL: regexp from libgo testsuite on non-split stack targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61871
Bug ID: 61871
Summary: FAIL: regexp from libgo testsuite on non-split stack
targets
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ubizjak at gmail dot com
CC: cmang at google dot com
regexp test from libgo testsuite FAILs on alpha (non-split stack target) due to
too demanding testcase, even with 8G of RAM.
Applying the following testsuite patch, test passes without problems.
--cut here--
Index: go/regexp/all_test.go
===
--- go/regexp/all_test.go (revision 212885)
+++ go/regexp/all_test.go (working copy)
@@ -475,7 +475,7 @@
// This ran out of stack before issue 7608 was fixed.
func TestOnePassCutoff(t *testing.T) {
- MustCompile(`^(?:x{1,1000}){1,1000}$`)
+// MustCompile(`^(?:x{1,1000}){1,1000}$`)
}
func BenchmarkLiteral(b *testing.B) {
--cut here--
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #3 from e2cd58e1 at opayq dot com --- but what I want to do is read in values with point as decimal separator. Using open(unit=1,file='bug.dat', decimal=point) doesn't seem to change anything.
[Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61526 Sandra Loosemore sandra at codesourcery dot com changed: What|Removed |Added CC||sandra at codesourcery dot com --- Comment #3 from Sandra Loosemore sandra at codesourcery dot com --- The testcase added for this bug in GCC 4.9.1 is failing with a link error on an arm-none-eabi target that doesn't support -shared. Should it be restricted to linux targets?
[Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61526 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Sandra Loosemore from comment #3) The testcase added for this bug in GCC 4.9.1 is failing with a link error on an arm-none-eabi target that doesn't support -shared. Should it be restricted to linux targets? Probably the best way is to add check_effective_target_shared to lib/target-supports.exp (similar to existing c_e_t_static) procedure and use it through the testsuite.
[Bug c++/61872] New: Assigning to long double causes memset to be improperly elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61872
Bug ID: 61872
Summary: Assigning to long double causes memset to be
improperly elided
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: coleb at eyesopen dot com
Created attachment 33169
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33169action=edit
Intermediate file generated by the compiler for the above test case
The following code zeros out memory being used as a long double in order to
be able to memcmp the memory later. However, assigning to the long double later
causes the optimizer to omit the preceding memset of zero.
The following code boils this down to a simple test case:
#include assert.h
#include string.h
#include iomanip
#include iostream
void Dump( const void * mem, size_t n )
{
const unsigned char * p = reinterpret_cast const unsigned char *( mem );
for ( size_t i = 0; i n; i++ )
{
std::cout std::hex std::setw(2) std::setfill( std::cout.widen('0')
) int(p[i]) ;
}
std::cout std::endl;
}
int main()
{
long double a;
memset(a, '\0', sizeof(long double));
//Dump(a, sizeof(long double)); // Uncomment me to make the test pass
a = 1.0;
long double b;
memset(b, '\0', sizeof(long double));
//Dump(b, sizeof(long double)); // Uncomment me to make the test pass
b = 1.0;
std::cout memcmp(a, b, sizeof(long double)) std::endl;
Dump(a, sizeof(long double));
Dump(b, sizeof(long double));
assert(memcmp(a, b, sizeof(long double)) == 0);
}
Uncommenting the Dump function calls causing the test to pass, presumably
because the optimizer notices the zero'd out memory is now being used by Dump
before the assignment.
Note, this only occurs with -O1 or higher.
I've attached the associated .ii files from the following command:
coleb@rhel7:~ g++ -v -save-temps -O1 ./LongDoubleMemSetElided.cpp ./a.out
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.2-20131106/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131106/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131106 (Red Hat 4.8.2-3) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -E -quiet -v -D_GNU_SOURCE
./LongDoubleMemSetElided.cpp -mtune=generic -march=x86-64 -O1 -fpch-preprocess
-o LongDoubleMemSetElided.ii
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include-fixed
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/backward
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -fpreprocessed
LongDoubleMemSetElided.ii -quiet -dumpbase LongDoubleMemSetElided.cpp
-mtune=generic -march=x86-64 -auxbase LongDoubleMemSetElided -O1 -version -o
LongDoubleMemSetElided.s
GNU C++ (GCC) version 4.8.2 20131106 (Red Hat 4.8.2-3) (x86_64-redhat-linux)
compiled by GNU C version 4.8.2 20131106 (Red Hat 4.8.2-3), GMP version
5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.2 20131106 (Red Hat 4.8.2-3) (x86_64-redhat-linux)
compiled by GNU C version 4.8.2 20131106 (Red Hat 4.8.2-3), GMP version
5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 854a658c8d093bd199c43bf0150da7d8
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
as -v --64 -o
[Bug c++/61873] New: with -openmp, -E does not produce preprocessed output on stdout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61873 Bug ID: 61873 Summary: with -openmp, -E does not produce preprocessed output on stdout Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com % g++ -c -E omp1.cpp # 1 omp1.cpp # 1 built-in # 1 command-line # 1 /usr/include/stdc-predef.h 1 3 4 # 1 command-line 2 # 1 omp1.cpp int i; % g++ -c -openmp -E omp1.cpp %
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to e2cd58e1 from comment #3) but what I want to do is read in values with point as decimal separator. Using open(unit=1,file='bug.dat', decimal=point) doesn't seem to change anything. gfortran's IO for floating point numbers using the operating systems strtof, strtod, and strtold. Are you sure that these functions on yuor OS actual have working locale support?
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #5 from e2cd58e1 at opayq dot com --- I actually don't know - how can I test this? But either way, shouldn't open(unit=1,file='bug.dat', decimal=point) read 1.234 in as 1.234 no matter what the locale settings are?
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #4) (In reply to e2cd58e1 from comment #3) but what I want to do is read in values with point as decimal separator. Using open(unit=1,file='bug.dat', decimal=point) doesn't seem to change anything. gfortran's IO for floating point numbers using the operating systems strtof, strtod, and strtold. Are you sure that these functions on yuor OS actual have working locale support? Yeah, replying to myself. What happens if you give strtod 1.2345' and 1,2345 in your locale? I missed a section of code in io/read.c: case ',': if (dtp-u.p.current_unit-decimal_status != DECIMAL_COMMA) goto bad_float; /* Fall through. */ case '.': if (seen_dp) goto bad_float; if (!seen_int_digit) *(out++) = '0'; *(out++) = '.'; seen_dp = 1; break; This implicitly changes a comma into a decimal point prior to the call to strtod.
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #7 from e2cd58e1 at opayq dot com --- For printf(Test 1 = %.4f\n,strtod(1.2345,NULL)); printf(Test 2 = %.4f\n,strtod(1,2345,NULL)); I get Test 1 = 1, Test 2 = 1,2345
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #8 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Mon, Jul 21, 2014 at 06:18:14PM +, e2cd58e1 at opayq dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #7 from e2cd58e1 at opayq dot com ---
For
printf(Test 1 = %.4f\n,strtod(1.2345,NULL));
printf(Test 2 = %.4f\n,strtod(1,2345,NULL));
I get
Test 1 = 1,
Test 2 = 1,2345
That's what I would expect. Here's another test;
#include locale.h
#include stdio.h
#include stdlib.h
int
main(void)
{
char *s1 = 1.2345, *s2 = 5,4321;
double d1, d2;
setlocale(LC_ALL, en_US.ISO8859-1);
d1 = strtod(s1, NULL);
d2 = strtod(s2, NULL);
printf(%s = %.4lf and %s = %.4lf\n, s1, d1, s2, d2);
setlocale(LC_ALL, de_DE.UTF-8);
d1 = strtod(s1, NULL);
d2 = strtod(s2, NULL);
printf(%s = %.4lf and %s = %.4lf\n, s1, d1, s2, d2);
return 0;
}
I get
troutmask:sgk[204] ./z
1.2345 = 1.2345 and 5,4321 = 5.
1.2345 = 1, and 5,4321 = 5,4321
So, the section of code that I posted in comment 6 is
ensuring that the fraction separator is always a decimal
point, and your locale and strtod are expecting a comma.
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #9 from e2cd58e1 at opayq dot com --- Just what I get: 1.2345 = 1.2345 and 5,4321 = 5. 1.2345 = 1, and 5,4321 = 5,4321
[Bug tree-optimization/61869] Spurious uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61869 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-21 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Yury Gribov from comment #0) Created attachment 33167 [details] /home/ygribov/repro.i:30:12: warning: ‘*((void*) i +8)’ may be used uninitialized in this function [-Wmaybe-uninitialized] Sad we are still printing this to the user (even if the warning were valid)
[Bug middle-end/61396] [4.10 regression] ICE in simplify_immed_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61396 --- Comment #4 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #3) Revision r209530 is OK, r210534 is not, likely a wide-int fallout. The problem first appeared in trunk revision 210113.
[Bug c++/61867] gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org Severity|normal |enhancement --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- There are many cases where this may trigger false positives. The mask used in the assignment or the value used in the comparison may come from a macro expansion, and be compile-time dependent. Or the comparison may be some kind of debug/assert check to ensure people don't mess up the assignment. Does cppcheck document what is actually warned and what is not and how to work-around the warning in case the code is actually valid? I am sure cppcheck warns about a lot of things that GCC does not, but the difficulty lies in getting the corner-cases right and the right level of warning versus annoying users.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #32 from paul.richard.thomas at gmail dot com paul.richard.thomas
at gmail dot com ---
Dear Dominique,
The problem is due to:
atmp.10.offset = 0;
{
integer(kind=8) S.12;
S.12 = 0;
while (1)
{
if (S.12 0) goto L.4;
{
struct string_t D.2386;
struct string_t D.2385;
D.2385 = (*(struct string_t[1] * restrict)
atmp.7.data)[S.12];
D.2386 = new_prt_spec (D.2385);
if (D.2385.chars.data != 0B)
/* between here */
{
__builtin_free ((void *) D.2385.chars.data);
}
D.2385.chars.data = 0B;
/* and here */
(*(struct string_t[1] * restrict)
atmp.10.data)[S.12] = D.2386;
}
S.12 = S.12 + 1;
}
L.4:;
}
process_configuration (atmp.10);
if ((struct string_t[1] * restrict) atmp.10.data != 0B)
I cannot see yet, where it comes in nor when it was introduced.
Paul
On 21 July 2014 12:51, dominiq at lps dot ens.fr
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #31 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Further reduced test
program main
implicit none
type :: string_t
character(LEN=1), dimension(:), allocatable :: chars
end type string_t
type(string_t) :: prt_in, tmp(1)
integer :: i
prt_in = string_t([W])
do i = 1, 16
print *, i
tmp = new_prt_spec ([prt_in])
end do
contains
elemental function new_prt_spec (name) result (prt_spec)
type(string_t), intent(in) :: name
type(string_t) :: prt_spec
end function new_prt_spec
end program main
However, nevertheless you would want to understand why the elemental
function causes a malloc crash for dim 1 arrays and works for scalars
and dim 1 arrays as input.
The faulty block is not used for scalars.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|bug in gfortran runtime on |bug in gfortran runtime: |OSX: digits cut off when|digits cut off when reading |reading floating point |floating point number |number | --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- I can reproduce this PR on a linux box with gcc version 4.6.3 20120306 (Red Hat 4.6.3-2), so the bug is not darwin specific. I have noticed that the file generated by running the test is 1.2345 and does not change if I put the line setlocale(LC_ALL, de_DE.UTF-8); before the line f = fopen(bug.dat, w); Now if I change the content of bug.dat to 1,2345 suppress the file generation in bug.c and use open(unit=1,file='bug.dat', decimal='comma') in bugf.f90, running the executable does not give any output (success). So apparently strtod uses the locale to read 1.2345, giving 1.0 as a result for de_DE.UTF-8 (or fr_FR.UTF-8), using en_US.ISO8859-1 gives 1.2345. The only solution I see is to save the current locale, set it to C before using strtod, and restore it upon completion.
[Bug c++/61867] gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867 --- Comment #3 from David Binderman dcb314 at hotmail dot com --- (In reply to Jonathan Wakely from comment #1) I'm pretty sure gcc does detect it and optimizes appropriately, it just doesn't warn. I've checked the output from using -S and I agree. All the code to do the detection reduction seems to be in place. I think that all that needs to happen is a warning is produced where either the detection or reduction takes place. As ever, users are free to ignore warnings. egrep -v is useful, I find.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #33 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Dear Paul,
I cannot see yet, where it comes in nor when it was introduced.
Unfortunately I has been introduced by me, see comment 5. The code is
+ if (expr-ts.type == BT_DERIVED expr-rank
+ !gfc_is_finalizable (expr-ts.u.derived, NULL)
+ expr-ts.u.derived-attr.alloc_comp
+ expr-expr_type != EXPR_VARIABLE)
+{
+ tree tmp;
+
+ tmp = build_fold_indirect_ref_loc (input_location, se-expr);
+ tmp = gfc_deallocate_alloc_comp (expr-ts.u.derived, tmp, expr-rank);
+
+ /* The components shall be deallocated before
+ their containing entity. */
+ gfc_prepend_expr_to_block (se-post, tmp);
+}
Question: what condition should be added to the 'if' to get a false for
'expr-expr_type == EXPR_ARRAY' and an elemental function?
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 James Clarke jrtc27 at jrtc27 dot com changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #14 from James Clarke jrtc27 at jrtc27 dot com --- The issue with Availability.h has been fixed as of Developer Preview 4, however `all-stage1-target-libsanitizer` still fails with Error 2.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #15 from James Clarke jrtc27 at jrtc27 dot com --- (In reply to James Clarke from comment #14) The issue with Availability.h has been fixed as of Developer Preview 4, however `all-stage1-target-libsanitizer` still fails with Error 2. I should note that I am building 4.8.3 with Homebrew.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- After all that has been said here, I am almost afraid to add any more. This is not a bug. Fortran and GFortran are not locale aware. The ',' or '.' are read from the file or device literally as is. From this read, a numeric string is constructed. If the unit was opened with decimal='comma' and a comma was seen, the comma is converted to '.'. If decimal='point' and a comma is read, an error occurs. After the above described numeric string is constructed it is passed to the glibc library strtod (sring to double). The glibc library is locale aware and if the locale has defined the decimal token to be a ',' (comma), it see the decimal 'point' and interprets it as end of string conversion. We do not want to take a performance it by checking the locale setting on every I/O operation, so the only logical place to do that is in main.c. However, in the example, the original poster is only compiling a gfortran subroutine. There is no gfortran program, so there is no gfortran main.c So the responsibility for addressing the locale has to fall on the C program side or within the users subroutine using maybe system calls that are extensions and not Fortran standard code. This users code would query the current runtime environment for current decimal setting and then do the I/O with the appropriate decimal= specifier. To avoid confusion, remember that gfortran is reading the characters in the file literally. So if there is a 1,2345 it sees the comma. If there is a 1.234 it sees the point. The conversion to internal floating point representation occurs after the character data is read. The easiest solution is to do what I said in in Comment #2 on the C side. The equivalent can be done on the fortran side as well, just not as easily. One possible enhancement we could consider is providing some set and get locale intrinsics. This would be helpful for some folks. But, thats a lot more work.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #12 from e2cd58e1 at opayq dot com ---
Sorry but I still have a problem with this, maybe I didn't get what you are
saying or I wasn't clear enough.
Suppose I cannot change the C-wrapper and the locale might be set to whatever.
The file bug.dat already exists and uses point decimals. So I want a fortran
routine that always reads in a file in the usual point separated format.
If in the fortran routine I call
open(unit=1,file='bug.dat', decimal=point)
I expect the keyword to be more important than the locale setting: I explicitly
specify to read point separated values, but in the example below, it still
returns 1.0 instead of 1.2345. Is that really expected behavior?
- bug.c --
#include stdlib.h /* strtod */
#include locale.h
#include stdio.h
int badcall_();
int main()
{
setlocale(LC_ALL, de_DE.UTF-8);
badcall_();
return 0;
}
- bug.dat --
1.2345
- bugf.f90 --
subroutine badcall()
implicit none
double precision :: res
open(unit=1,file='bug.dat',decimal=point)
read(1,*) res
write(*,*) 'res =', res
end subroutine badcall
[Bug debug/61874] New: Missing DW_AT_location for this parameter when using always_inline attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61874
Bug ID: 61874
Summary: Missing DW_AT_location for this parameter when using
always_inline attribute
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: apepper at blueshiftinc dot com
Dwarf output for formal parameter “this”, includes no DW_AT_location, for a
member function that is decorated with “__attribute__ ((always_inline))”.
Test case:
---
class A
{
public:
void accessMemberInline(int a) __attribute__ ((always_inline))
{
m_a = a;
}
int m_a;
};
int main()
{
A my_a;
my_a.accessMemberInline(5);
}
g++ -g -O0
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #13 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Jul 22, 2014 at 01:39:30AM +, jvdelisle at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- After all that has been said here, I am almost afraid to add any more. This is not a bug. Fortran and GFortran are not locale aware. The ',' or '.' are read from the file or device literally as is. From this read, a numeric string is constructed. If the unit was opened with decimal='comma' and a comma was seen, the comma is converted to '.'. If decimal='point' and a comma is read, an error occurs. I never claimed it to be bug. You've simply restated what I was trying to convey in much more coherent manner in a single post. After the above described numeric string is constructed it is passed to the glibc library strtod (sring to double). The glibc library is locale aware and if the locale has defined the decimal token to be a ',' (comma), it see the decimal 'point' and interprets it as end of string conversion. I do however note that OP is using MacOS and I use FreeBSD. Neither uses glibc. strtod is a C99/POSIX specified function, so correctly implmented strtod function should give the same results (up to whether C99/POSIX requires adherence to locale).
[Bug c++/53361] Could not convert ‘{0, 0, 0}’ from ‘brace-enclosed initializer list’ to ‘std::arrayunsigned int, 3ul’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53361 nightstrike nightstrike at gmail dot com changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #8 from nightstrike nightstrike at gmail dot com --- This SO post claims that GCC is in error: http://stackoverflow.com/questions/8192185/using-stdarray-with-initialization-lists
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #14 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to e2cd58e1 from comment #12) --- snip --- Suppose I cannot change the C-wrapper and the locale might be set to whatever. The file bug.dat already exists and uses point decimals. So I want a fortran routine that always reads in a file in the usual point separated format. If in the fortran routine I call open(unit=1,file='bug.dat', decimal=point) I expect the keyword to be more important than the locale setting: I explicitly specify to read point separated values, but in the example below, it still returns 1.0 instead of 1.2345. Is that really expected behavior? My first bad assumption was that for some reason you wanted the current locale, whatever it is, to remain active. My second bad assumption was that you could easily change your C-wrapper. :) In reading up on the locale business, setting locale to POSIX is suppose to be fully portable. So, we could easily force the locale to POSIX in the open statement. I need to think about whether this will mess up something else.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #15 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Maybe something like this: Index: open.c === --- open.c(revision 212498) +++ open.c(working copy) @@ -26,6 +26,7 @@ see the files COPYING3 and COPYING.RUNTIME respect #include io.h #include fbuf.h #include unix.h +#include locale.h #ifdef HAVE_UNISTD_H #include unistd.h @@ -725,6 +726,10 @@ st_open (st_parameter_open *opp) library_start (opp-common); + /* For portability, set locale to POSIX. */ + + setlocale(LC_ALL, POSIX); + /* Decode options. */ flags.access = !(cf IOPARM_OPEN_HAS_ACCESS) ? ACCESS_UNSPECIFIED :
[Bug target/61396] [4.10 regression] ICE in simplify_immed_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61396 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||segher at gcc dot gnu.org Component|middle-end |target Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #5 from Segher Boessenkool segher at gcc dot gnu.org --- It's a target problem. I have a patch.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #16 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Jul 22, 2014 at 04:27:58AM +, jvdelisle at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #15 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Maybe something like this: I think that you'll need to use configure to check for locale.h. Index: open.c === --- open.c(revision 212498) +++ open.c(working copy) @@ -26,6 +26,7 @@ see the files COPYING3 and COPYING.RUNTIME respect #include io.h #include fbuf.h #include unix.h +#include locale.h #ifdef HAVE_LOCALE_H #include locale.h #endif #ifdef HAVE_UNISTD_H #include unistd.h @@ -725,6 +726,10 @@ st_open (st_parameter_open *opp) library_start (opp-common); #ifdef HAVE_LOCALE_H + /* For portability, set locale to POSIX. */ + + setlocale(LC_ALL, POSIX); + #endif
[Bug c++/53361] Could not convert ‘{0, 0, 0}’ from ‘brace-enclosed initializer list’ to ‘std::arrayunsigned int, 3ul’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53361 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to nightstrike from comment #8) This SO post claims that GCC is in error: Yes and it was fixed in 4.8.
[Bug c++/53361] Could not convert ‘{0, 0, 0}’ from ‘brace-enclosed initializer list’ to ‘std::arrayunsigned int, 3ul’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53361 --- Comment #10 from nightstrike nightstrike at gmail dot com --- Oh, strange. I thought I was still experiencing this on 4.8.2. I'll check again. Sorry for the noise.
Re: a new libgcov interface: __gcov_dump_all
On 07/20/14 21:38, Xinliang David Li wrote: The gcov_info chain is not duplicated -- there is already one chain (linking only modules of the library) per shared library in current implementation. My change does not affect underlying behavior at all -- it merely introduces a new interface to access private dumper methods associated with shared libs. ah, got it. thanks for clarifying. Can't help thinking gcov_init should be doing this, and wondering about dlload/dlclose. Let me think nathan
RE: Re: [MIPS r5900] libgcc floating point fixes
Jürgen Urban juergenur...@gmx.dewrites: Jürgen Urban juergenur...@gmx.de writes: Hello Richard, Jürgen Urban juergenur...@gmx.de writes: Is this something you have recently developed outside of the mainline kernel or does it already exist. I'm not aware of such logic in the MIPS kernel yet. Yes, this is developed in my kernel which currently is still based on Linux 2.6.35.4. I added a TIF_R5900FPU flag to thread_info.h. I plan that this will get part of the mainline kernel. As the patch is too large to get accepted, I need to change the binutils, so that sync.p will be added after or before the right instruction automatically. Is the TIF_R5900FPU flag to do something more than just change the register model used by the FPU emulator or does it do something more/less? I'm afraid I don’t know the significance of the sync.p. double the FPU emulator gets activated. Currently it only checks whether the architecture is mips r5900 or not. For non r5900 the FPU emulator is activated. It seems that we also need to add something to the ELF file to specify the 32 bit or 64 bit for float. It would be good when it is not at a so complicated position as the soft vs hard float flag, because it needs to be read by the kernel when starting a ELF file. This way it would also be I have a series of patches that will add this kind of support to the MIPS ABI in the coming weeks for similar reasons but relating to O32 and double-float ABI extensions. You will be able to directly hang off the changes once I commit (testing is taking some time). There should be no need for extra changes to gcc or binutils to get the information you need. Kernel changes to respond to new ABI information are also in progress and will be easily extendable. possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same as r5900, but the FPU is 64 bit and compliant to IEEE 754. Note that this won't really be correct for r5900 anyway because of its non-IEEE FPU. E.g. the soft-float routines will treat 0x7f80 as infinity and 0x7fff as a NaN, whereas for r5900 they should be treated as normal numbers. The code looked like it uses the configured floating point configuration for hard float, but you are right the conversion is not working in these cases. I think there is no problem with the second part of the patch which disables t-mips16 for r5900. So could you commit the last part of the patch? Are you looking to add support for a single-float FPU to a number of packages as part of this? One thing that comes to mind would be libffi but the double-precision ABIs are assumed to be the only ones used in Linux in a number of places. Just trying to get a feel for your end goal out of curiosity. The libffi doesn't look like that there is a change needed for floating point. Libffi and most other hand crafted code for linux are written to follow the standard double-precision O32/N32 ABI. The single-precision variants are link-incompatible as they change the calling convention. I.e. when you pass a double-precision value using a single-precision calling-convention then it gets passed in GPRs instead of FPRs. It is possible that it needs a change for TImode or for 2 or 3 of the other co-processors which are currently not under discussion. The long term plan is to have 32 bit floating point operations compliant to IEEE 754 with ABI o32 and n32. Everything should stay inside gcc, libgcc and the kernel (i.e. Linux or PS2SDK). I want to fix it at the lowest level and not in any high level library. Due to the calling convention change you won't be able to restrict the work to just the toolchain and kernel. MIPS linux theoretically supports two ABI extensions 'hard-float (double-precision)' and soft-float. I have a feeling that the soft-float extension is not supported everywhere but may be a better start point for what you want to achieve, i.e. use a soft-float calling convention but add support for using FPU instructions at the same time. This would be akin to arm's softfp float-abi. Fixes for high level libraries should also be high level (dmult vs __FLT_MAX_EXP__); i.e. there should be no change in a different package which is specific for MIPS. The type double should stay double and is handled without a problem when the FPU is 32 bit in ABI o32. The problem is only with the single/double conversion functions and the ABI n32. I didn't quite follow why you specifically say n32 in the last sentence... What is harder to fix about n32 than o32? Thanks, Matthew
[PATCH] New check and updates in check_GNU_style script
Hi all,
Attached patch adds new check (all blocks of 8 spaces are replaced with
tabs) to contrib/check_GNU_style.sh. It also changes the script to allow
reading patches from stdin and improves the Dot, space, space, new
sentence. check.
-Y
commit 4bc624dcd778e8317a4de620b266c05b55577aad
Author: Yury Gribov y.gri...@samsung.com
Date: Mon Jul 21 10:12:24 2014 +0400
2014-07-21 Yury Gribov y.gri...@samsung.com
check_GNU_style.sh: Support patches coming from stdin,
check that spaces are converted to tabs and make double-space
check more precice.
diff --git a/contrib/check_GNU_style.sh b/contrib/check_GNU_style.sh
index ef8fdda..d61dc96 100755
--- a/contrib/check_GNU_style.sh
+++ b/contrib/check_GNU_style.sh
@@ -23,6 +23,8 @@ usage() {
check_GNU_style.sh [patch]...
Checks the patches for some of the GNU style formatting problems.
+When FILE is -, read standard input.
+
Please note that these checks are not always accurate, and
complete. The reference documentation of the GNU Coding Standards
can be found here: http://www.gnu.org/prep/standards_toc.html
@@ -35,19 +37,22 @@ EOF
test $# -eq 0 usage
+inp=check_GNU_style.inp
tmp=check_GNU_style.tmp
# Remove $tmp on exit and various signals.
-trap rm -f $tmp 0
-trap rm -f $tmp ; exit 1 1 2 3 5 9 13 15
+trap rm -f $inp $tmp 0
+trap rm -f $inp $tmp ; exit 1 1 2 3 5 9 13 15
+
+grep -nH '^+' $* \
+ | grep -v ':+++' \
+ $inp
# Grep
g (){
msg=$1
arg=$2
-shift 2
-grep -nH '^+' $* \
- | grep -v ':+++' \
+cat $inp \
| egrep --color=always -- $arg \
$tmp printf \n$msg\n
cat $tmp
@@ -58,9 +63,7 @@ ag (){
msg=$1
arg1=$2
arg2=$3
-shift 3
-grep -nH '^+' $* \
- | grep -v ':+++' \
+cat $inp \
| egrep --color=always -- $arg1 \
| egrep --color=always -- $arg2 \
$tmp printf \n$msg\n
@@ -72,9 +75,7 @@ vg (){
msg=$1
varg=$2
arg=$3
-shift 3
-grep -nH '^+' $* \
- | grep -v ':+++' \
+cat $inp \
| egrep -v -- $varg \
| egrep --color=always -- $arg \
$tmp printf \n$msg\n
@@ -83,9 +84,7 @@ vg (){
col (){
msg=$1
-shift 1
-grep -nH '^+' $* \
- | grep -v ':+++' \
+cat $inp \
| cut -f 2 -d '+' \
| awk '{ if (length ($0) 80) print $0 }' \
$tmp
@@ -95,30 +94,32 @@ col (){
fi
}
-col 'Lines should not exceed 80 characters.' $*
+col 'Lines should not exceed 80 characters.'
+
+g 'Blocks of 8 spaces should be replaced with tabs.' \
+' {8}'
g 'Trailing whitespace.' \
-'[[:space:]]$' $*
+'[[:space:]]$'
g 'Space before dot.' \
-'[[:alnum:]][[:blank:]]+\.' $*
+'[[:alnum:]][[:blank:]]+\.'
g 'Dot, space, space, new sentence.' \
-'[[:alnum:]]\.([[:blank:]]|[[:blank:]]{3,})[[:alnum:]]' $*
+'[[:alnum:]]\.([[:blank:]]|[[:blank:]]{3,})[A-Z0-9]'
g 'Dot, space, space, end of comment.' \
-'[[:alnum:]]\.([[:blank:]]{0,1}|[[:blank:]]{3,})\*/' $*
+'[[:alnum:]]\.([[:blank:]]{0,1}|[[:blank:]]{3,})\*/'
g 'Sentences should end with a dot. Dot, space, space, end of the comment.' \
-'[[:alnum:]][[:blank:]]*\*/' $*
+'[[:alnum:]][[:blank:]]*\*/'
vg 'There should be exactly one space between function name and parentheses.' \
-'\#define' '[[:alnum:]]([^[:blank:]]|[[:blank:]]{2,})\(' $*
+'\#define' '[[:alnum:]]([^[:blank:]]|[[:blank:]]{2,})\('
g 'There should be no space before closing parentheses.' \
-'[[:graph:]][[:blank:]]+\)' $*
+'[[:graph:]][[:blank:]]+\)'
ag 'Braces should be on a separate line.' \
-'\{' 'if[[:blank:]]\(|while[[:blank:]]\(|switch[[:blank:]]\(' $*
-
+'\{' 'if[[:blank:]]\(|while[[:blank:]]\(|switch[[:blank:]]\('
Re: [PATCH, i386, PR61827] Fix fuse-caller-save-xmm.c test-case
On Sun, Jul 20, 2014 at 12:25 PM, Tom de Vries tom_devr...@mentor.com wrote: this patch fixes the problems in test-case gcc.target/i386/fuse-caller-save-xmm.c reported in PR 61827. I've removed the checks for cfi_def_cfa_offset, which were not robust enough for the different configurations. Furthermore, I've: - added checks for all insns that handle the xmm registers, to make sure we're actually using the xmm1 register. - fixed the scan-assembler-not lines to allow both %esp and %rsp. You can use %\[re\]?sp here. We know that only r and e are valid. - removed main, which was really only intended for the fuse-caller-save-xmm-run.c test-case. Tested with -m32 and -m64. Probably you should also add -fomit-frame-pointer, otherwise the test (that checks for SP based address) will fail on Darwin and Solaris that default to frame pointers. OK for trunk? OK with the above changes. Thanks, Uros.
Re: [PATCH 2/2] allow running mklog as a filter
On 05/09/2014 07:09 PM, Diego Novillo wrote: I slightly prefer the semantics that gets me just the ChangeLog. The workflow I'm envisioning is: I've commited both patches in r212883 and r12884. Mklog now runs as a filter and prints generated ChangeLog to stdout instead of modifying the patchfile. OK with Yuri's suggestion of assuming '-' when ARGV is empty. I didn't change this because currently empty ARGV is used for printing help message (similar to some other scripts in contrib/ folder). -Y
Re: [GSoC] generation of Gimple code from isl_ast_node_user
Maybe we should temporary postpone this and add a FIXME that says: “We should remove iv_map.create (loop-num + 1), if it is possible.” What do you think about this? -- Cheers, Roman Gareev.
[PATCH] Fix mklog to support running from arbitrary folder
Hi all,
Current mklog works only if run from GCC top-level folder. The patch
allows running from arbitrary directory.
I've used Linux directory separators which is probably ok because script
already expects Linux environment (dirname, basename, etc.).
Ok to commit?
-Y
commit aa8d7cd3db1f1eba8ee77b902cff1b2ab2a3f83a
Author: Yury Gribov y.gri...@samsung.com
Date: Mon Jul 21 12:05:10 2014 +0400
2014-07-21 Yury Gribov y.gri...@samsung.com
* mklog: Allow running from arbitrary folder.
diff --git a/contrib/mklog b/contrib/mklog
index cdc6455..3d17dc5 100755
--- a/contrib/mklog
+++ b/contrib/mklog
@@ -30,16 +30,15 @@
$username = $ENV{'USER'};
$name = `finger $username | grep -o 'Name: .*'`;
@n = split(/: /, $name);
-$name = @n[1]; chop($name);
+$name = $n[1]; chop($name);
$addr = $username . \@my.domain.org;
$date = `date +%Y-%m-%d`; chop ($date);
$gcc_root = $0;
$gcc_root =~ s/[^\\\/]+$/../;
-chdir $gcc_root;
# if this is a git tree then take name and email from the git configuration
-if (-d .git) {
+if (-d $gcc_root/.git) {
$gitname = `git config user.name`;
chomp($gitname);
if ($gitname) {
@@ -80,7 +79,7 @@ sub get_clname ($) {
my $dirname = $_[0];
while ($dirname) {
my $clname = $dirname/ChangeLog;
- if (-f $clname) {
+ if (-f $gcc_root/$clname) {
my $relname = substr ($_[0], length ($dirname) + 1);
return ($clname, $relname);
} else {
[PATCH, i386]: Fix PR 61855, _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
Hello!
2014-07-21 Uros Bizjak ubiz...@gmail.com
PR target/61855
* config/i386/avx512fintrin.h: Move constants for mantissa extraction
out of #ifdef __OPTIMIZE__.
testsuite/ChangeLog:
2014-07-21 Uros Bizjak ubiz...@gmail.com
PR target/61855
* gcc.target/i386/pr61855.c: New test.
Tested on x86_64-linux-gnu and committed to mainline SVN and 4.9 branch.
Uros.
Index: config/i386/avx512fintrin.h
===
--- config/i386/avx512fintrin.h (revision 212882)
+++ config/i386/avx512fintrin.h (working copy)
@@ -8103,6 +8103,22 @@
return __builtin_ia32_movntdqa512 ((__v8di *)__P);
}
+/* Constants for mantissa extraction */
+typedef enum
+{
+ _MM_MANT_NORM_1_2, /* interval [1, 2) */
+ _MM_MANT_NORM_p5_2, /* interval [0.5, 2)*/
+ _MM_MANT_NORM_p5_1, /* interval [0.5, 1)*/
+ _MM_MANT_NORM_p75_1p5/* interval [0.75, 1.5) */
+} _MM_MANTISSA_NORM_ENUM;
+
+typedef enum
+{
+ _MM_MANT_SIGN_src, /* sign = sign(SRC) */
+ _MM_MANT_SIGN_zero, /* sign = 0 */
+ _MM_MANT_SIGN_nan/* DEST = NaN if sign(SRC) = 1 */
+} _MM_MANTISSA_SIGN_ENUM;
+
#ifdef __OPTIMIZE__
extern __inline __m128
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
@@ -8182,22 +8198,6 @@
(__mmask8) __U, __R);
}
-/* Constants for mantissa extraction */
-typedef enum
-{
- _MM_MANT_NORM_1_2, /* interval [1, 2) */
- _MM_MANT_NORM_p5_2, /* interval [0.5, 2)*/
- _MM_MANT_NORM_p5_1, /* interval [0.5, 1)*/
- _MM_MANT_NORM_p75_1p5/* interval [0.75, 1.5) */
-} _MM_MANTISSA_NORM_ENUM;
-
-typedef enum
-{
- _MM_MANT_SIGN_src, /* sign = sign(SRC) */
- _MM_MANT_SIGN_zero, /* sign = 0 */
- _MM_MANT_SIGN_nan/* DEST = NaN if sign(SRC) = 1 */
-} _MM_MANTISSA_SIGN_ENUM;
-
extern __inline __m512d
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_getmant_round_pd (__m512d __A, _MM_MANTISSA_NORM_ENUM __B,
Index: testsuite/gcc.target/i386/pr61855.c
===
--- testsuite/gcc.target/i386/pr61855.c (revision 0)
+++ testsuite/gcc.target/i386/pr61855.c (working copy)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options -mavx512f } */
+
+#include x86intrin.h
+
+__m512 test (__m512 x)
+{
+ return _mm512_getmant_ps(x, _MM_MANT_NORM_1_2, _MM_MANT_SIGN_zero);
+}
+
Re: [GSoC] generation of Gimple code from isl_ast_node_user
On 21/07/2014 10:25, Roman Gareev wrote: Maybe we should temporary postpone this and add a FIXME that says: “We should remove iv_map.create (loop-num + 1), if it is possible.” What do you think about this? Fine with me. Please post a question on gcc devel to see if someone can explain us the vec.h implementation. Cheers, Tobias
Re: [PATCH 2/2] allow running mklog as a filter
On Mon, Jul 21, 2014 at 11:49:05AM +0400, Yury Gribov wrote: On 05/09/2014 07:09 PM, Diego Novillo wrote: I slightly prefer the semantics that gets me just the ChangeLog. The workflow I'm envisioning is: I've commited both patches in r212883 and r12884. Mklog now runs as a filter and prints generated ChangeLog to stdout instead of modifying the patchfile. thanks for taking care of it! OK with Yuri's suggestion of assuming '-' when ARGV is empty. I didn't change this because currently empty ARGV is used for printing help message (similar to some other scripts in contrib/ folder). I'm not really sure which is the better UI, but I'd rather time be spent on better automatic change log generation. I may or may not hope we'll eventually have a mklog that can autogenerate most ChangeLogs and then people will have a hard time arguing they're useful. Trev -Y
Re: [PATH] Intel offload library
Ping. On Wed, Jul 2, 2014 at 3:13 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: * Don't duplicate the logic for what's a hosted POSIX system; refactor it to a common fragment in config/ (I guess it needs to be a shell script fragment there rather than an actual autoconf macro, since you're using that logic in configure.tgt which is itself such a fragment). I've attached the patch with changes related to the point. Do you mean something like this? -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy
Fwd: [PATCH 1/3]Improve induction variable elimination
Hi, forward to Zdenek for the review.
Thanks,
bin
-- Forwarded message --
From: Bin Cheng bin.ch...@arm.com
Date: Thu, Jul 17, 2014 at 10:07 AM
Subject: [PATCH 1/3]Improve induction variable elimination
To: gcc-patches@gcc.gnu.org
Hi,
This is a series of three patches improving induction variable elimination.
Currently GCC only eliminates iv for very specific case when the loop's
latch could run zero times, i.e., when may_be_zero field of loop niter
information evaluates to true. In fact, it's so specific that
iv_elimination_compare_lt rarely succeeds during either GCC bootstrap or
spec2000/spec2006 compilation. Though intrusive data shows these patches
don't help iv elimination that much for GCC bootstrap, they do capture
5%~15% more eliminations for compiling spec2000/2006. Detailed numbers are
like:
2k/int 2k/fp 2k6/int 2k6/fp
improve ~9.6% ~4.8% ~5.5%~14.4%
All patches pass bootstrap and regression test on x86_64/x86. I will
bootstrap and test them on aarch64/arm platforms too.
The first patch turns to tree operand_equal_p to check the number of
iterations in iv_elimination_lt. Though I think this change isn't necessary
for current code, it's needed if we further relax iv elimination for cases
in which sign/unsigned conversion is involved.
Thanks,
bin
2014-07-17 Bin Cheng bin.ch...@arm.com
* tree-ssa-loop-ivopts.c (iv_elimination_compare_lt): Check number
of iteration using tree comparison.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 212387)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -4605,7 +4605,7 @@ iv_elimination_compare_lt (struct ivopts_data *dat
struct tree_niter_desc *niter)
{
tree cand_type, a, b, mbz, nit_type = TREE_TYPE (niter-niter), offset;
- struct aff_tree nit, tmpa, tmpb;
+ struct aff_tree nit, tmp1, tmpa, tmpb;
enum tree_code comp;
HOST_WIDE_INT step;
@@ -4661,15 +4661,19 @@ iv_elimination_compare_lt (struct ivopts_data *dat
return false;
/* Expected number of iterations is B - A - 1. Check that it matches
- the actual number, i.e., that B - A - NITER = 1. */
+ the actual number, i.e., that B - A = NITER + 1. */
tree_to_aff_combination (niter-niter, nit_type, nit);
- tree_to_aff_combination (fold_convert (nit_type, a), nit_type, tmpa);
- tree_to_aff_combination (fold_convert (nit_type, b), nit_type, tmpb);
- aff_combination_scale (nit, -1);
- aff_combination_scale (tmpa, -1);
- aff_combination_add (tmpb, tmpa);
- aff_combination_add (tmpb, nit);
- if (tmpb.n != 0 || tmpb.offset != 1)
+ aff_combination_const (tmp1, nit_type, 1);
+ tree_to_aff_combination (b, TREE_TYPE (b), tmpb);
+ aff_combination_add (nit, tmp1);
+ if (a != integer_zero_node)
+{
+ tree_to_aff_combination (a, TREE_TYPE (b), tmpa);
+ aff_combination_scale (tmpa, -1);
+ aff_combination_add (tmpb, tmpa);
+}
+ if (!operand_equal_p (aff_combination_to_tree (nit),
+ aff_combination_to_tree (tmpb), 0))
return false;
/* Finally, check that CAND-IV-BASE - CAND-IV-STEP * A does not
Fwd: [PATCH 3/3]Improve induction variable elimination
Forward to Zdenek for the review.
Thanks,
bin
-- Forwarded message --
From: Bin Cheng bin.ch...@arm.com
Date: Thu, Jul 17, 2014 at 10:09 AM
Subject: [PATCH 3/3]Improve induction variable elimination
To: gcc-patches@gcc.gnu.org
Hi,
Function iv_elimination_compare_lt is used to eliminate induction variable
when the loop's latch could run for zero time (i.e., may_be_zero in loop
niter information evaluates to true). As stated in the first message, it
only handles very specific case that rarely happens for either GCC bootstrap
or spec2k/spec2k6 compilation. The function has two restrictions which
could be improved:
a) When checking that candidate iv doesn't overflow, it only handles
candidates that are computed in a type that guarantees no overflows. More
complex analysis can be used to prove the non-overflow ness, as in this
patch.
b) The function only handles the original form of may_be_zero like a + 1
b, but that expression could have been folded into other forms. This
patch handles three folded forms and does iv elimination as well. I think
this isn't a very corner case, because for many loops iterating from 0
(i.e., we have a == 0), the expression will be folded.
I also refactored period check from may_eliminate_iv into a single function
so that it can be reused.
Thanks,
bin
2014-07-17 Bin Cheng bin.ch...@arm.com
* tree-ssa-loop-ivopts.c (iv_nowrap_period)
(nowrap_cand_for_loop_niter_p): New functions.
(period_greater_niter_exit): New function refactored from
may_eliminate_iv.
(iv_elimination_compare_lt): New parameter. Check wrapping
behavior for candidate of wrapping type. Handle folded forms
of may_be_zero expression.
(may_eliminate_iv): Call period_greater_niter_exit. Pass new
argument for iv_elimination_compare_lt.
gcc/testsuite/ChangeLog
2014-07-17 Bin Cheng bin.ch...@arm.com
* gcc.dg/tree-ssa/ivopts-lt-3.c: New test.
* gcc.dg/tree-ssa/ivopts-lt-4.c: New test.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 212387)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -4432,6 +4432,44 @@ iv_period (struct iv *iv)
return period;
}
+/* Returns no wrapping period of induction variable IV. For now
+ only unsigned type IV is handled, we could extend it in case
+ of non-overflow for signed ones. Return zero if it can't be
+ decided. */
+
+static tree
+iv_nowrap_period (struct iv *iv)
+{
+ bool overflow;
+ tree type;
+ tree base = iv-base, step = iv-step;
+ widest_int base_val, step_val, max_val, span, period;
+
+ gcc_assert (step TREE_CODE (step) == INTEGER_CST);
+
+ type = TREE_TYPE (base);
+ if (!TYPE_UNSIGNED (type) || TREE_CODE (base) != INTEGER_CST)
+return integer_zero_node;
+
+ base_val = wi::to_widest (base);
+ step_val = wi::to_widest (step);
+ if (!POINTER_TYPE_P (type) TYPE_MAX_VALUE (type)
+ TREE_CODE (TYPE_MAX_VALUE (type)) == INTEGER_CST)
+max_val = wi::to_widest (TYPE_MAX_VALUE (type));
+ else
+{
+ wide_int max_wi = wi::max_value (TYPE_PRECISION (type), UNSIGNED);
+ max_val = wi::to_widest (wide_int_to_tree (type, max_wi));
+}
+
+ span = max_val - base_val + step_val - 1;
+ period = wi::div_trunc (span, step_val, UNSIGNED, overflow);
+ if (overflow)
+return integer_zero_node;
+
+ return wide_int_to_tree (type, period);
+}
+
/* Returns the comparison operator used when eliminating the iv USE. */
static enum tree_code
@@ -4560,7 +4598,84 @@ difference_cannot_overflow_p (tree base, tree offs
}
}
-/* Tries to replace loop exit by one formulated in terms of a LT_EXPR
+/* Check whether PERIOD of CAND is greater than the number of iterations
+ described by DESC for which the exit condition is true. The exit
+ condition is comparison against USE. */
+
+static bool
+period_greater_niter_exit (struct ivopts_data *data,
+ struct iv_use *use, struct iv_cand *cand,
+ tree period, struct tree_niter_desc *desc)
+{
+ struct loop *loop = data-current_loop;
+
+ /* If the number of iterations is constant, compare against it directly. */
+ if (TREE_CODE (desc-niter) == INTEGER_CST)
+{
+ /* See cand_value_at. */
+ if (stmt_after_increment (loop, cand, use-stmt))
+{
+ if (!tree_int_cst_lt (desc-niter, period))
+return false;
+}
+ else
+{
+ if (tree_int_cst_lt (period, desc-niter))
+return false;
+}
+}
+
+ /* If not, and if this is the only possible exit of the loop, see whether
+ we can get a conservative estimate on the number of iterations of the
+ entire loop and compare against that instead. */
+ else
+{
+ widest_int period_value, max_niter;
+
+ max_niter = desc-max;
+ if (stmt_after_increment (loop, cand, use-stmt))
+
Fwd: [PATCH 3/3]Improve induction variable elimination
Hi, forward to Zdenek for the review.
Thanks,
bin
-- Forwarded message --
From: Bin Cheng bin.ch...@arm.com
Date: Thu, Jul 17, 2014 at 10:09 AM
Subject: [PATCH 3/3]Improve induction variable elimination
To: gcc-patches@gcc.gnu.org
Hi,
Function iv_elimination_compare_lt is used to eliminate induction variable
when the loop's latch could run for zero time (i.e., may_be_zero in loop
niter information evaluates to true). As stated in the first message, it
only handles very specific case that rarely happens for either GCC bootstrap
or spec2k/spec2k6 compilation. The function has two restrictions which
could be improved:
a) When checking that candidate iv doesn't overflow, it only handles
candidates that are computed in a type that guarantees no overflows. More
complex analysis can be used to prove the non-overflow ness, as in this
patch.
b) The function only handles the original form of may_be_zero like a + 1
b, but that expression could have been folded into other forms. This
patch handles three folded forms and does iv elimination as well. I think
this isn't a very corner case, because for many loops iterating from 0
(i.e., we have a == 0), the expression will be folded.
I also refactored period check from may_eliminate_iv into a single function
so that it can be reused.
Thanks,
bin
2014-07-17 Bin Cheng bin.ch...@arm.com
* tree-ssa-loop-ivopts.c (iv_nowrap_period)
(nowrap_cand_for_loop_niter_p): New functions.
(period_greater_niter_exit): New function refactored from
may_eliminate_iv.
(iv_elimination_compare_lt): New parameter. Check wrapping
behavior for candidate of wrapping type. Handle folded forms
of may_be_zero expression.
(may_eliminate_iv): Call period_greater_niter_exit. Pass new
argument for iv_elimination_compare_lt.
gcc/testsuite/ChangeLog
2014-07-17 Bin Cheng bin.ch...@arm.com
* gcc.dg/tree-ssa/ivopts-lt-3.c: New test.
* gcc.dg/tree-ssa/ivopts-lt-4.c: New test.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 212387)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -4432,6 +4432,44 @@ iv_period (struct iv *iv)
return period;
}
+/* Returns no wrapping period of induction variable IV. For now
+ only unsigned type IV is handled, we could extend it in case
+ of non-overflow for signed ones. Return zero if it can't be
+ decided. */
+
+static tree
+iv_nowrap_period (struct iv *iv)
+{
+ bool overflow;
+ tree type;
+ tree base = iv-base, step = iv-step;
+ widest_int base_val, step_val, max_val, span, period;
+
+ gcc_assert (step TREE_CODE (step) == INTEGER_CST);
+
+ type = TREE_TYPE (base);
+ if (!TYPE_UNSIGNED (type) || TREE_CODE (base) != INTEGER_CST)
+return integer_zero_node;
+
+ base_val = wi::to_widest (base);
+ step_val = wi::to_widest (step);
+ if (!POINTER_TYPE_P (type) TYPE_MAX_VALUE (type)
+ TREE_CODE (TYPE_MAX_VALUE (type)) == INTEGER_CST)
+max_val = wi::to_widest (TYPE_MAX_VALUE (type));
+ else
+{
+ wide_int max_wi = wi::max_value (TYPE_PRECISION (type), UNSIGNED);
+ max_val = wi::to_widest (wide_int_to_tree (type, max_wi));
+}
+
+ span = max_val - base_val + step_val - 1;
+ period = wi::div_trunc (span, step_val, UNSIGNED, overflow);
+ if (overflow)
+return integer_zero_node;
+
+ return wide_int_to_tree (type, period);
+}
+
/* Returns the comparison operator used when eliminating the iv USE. */
static enum tree_code
@@ -4560,7 +4598,84 @@ difference_cannot_overflow_p (tree base, tree offs
}
}
-/* Tries to replace loop exit by one formulated in terms of a LT_EXPR
+/* Check whether PERIOD of CAND is greater than the number of iterations
+ described by DESC for which the exit condition is true. The exit
+ condition is comparison against USE. */
+
+static bool
+period_greater_niter_exit (struct ivopts_data *data,
+ struct iv_use *use, struct iv_cand *cand,
+ tree period, struct tree_niter_desc *desc)
+{
+ struct loop *loop = data-current_loop;
+
+ /* If the number of iterations is constant, compare against it directly. */
+ if (TREE_CODE (desc-niter) == INTEGER_CST)
+{
+ /* See cand_value_at. */
+ if (stmt_after_increment (loop, cand, use-stmt))
+{
+ if (!tree_int_cst_lt (desc-niter, period))
+return false;
+}
+ else
+{
+ if (tree_int_cst_lt (period, desc-niter))
+return false;
+}
+}
+
+ /* If not, and if this is the only possible exit of the loop, see whether
+ we can get a conservative estimate on the number of iterations of the
+ entire loop and compare against that instead. */
+ else
+{
+ widest_int period_value, max_niter;
+
+ max_niter = desc-max;
+ if (stmt_after_increment (loop, cand, use-stmt))
Re: [GSoC] generation of Gimple code from isl_ast_node_user
I've asked the community about this.
The patch below contains the FIXME.
--
Cheers, Roman Gareev.
2014-07-12 Roman Gareev gareevro...@gmail.com
gcc/
* graphite-isl-ast-to-gimple.c:
Add inclusion of gimple-ssa.h, tree-into-ssa.h.
(ivs_params_clear):
(build_iv_mapping): New function.
(translate_isl_ast_node_user): Likewise.
(translate_isl_ast): Add calling of translate_isl_ast_node_user.
gcc/testsuite/gcc.dg/graphite/
* isl-ast-gen-single-loop-1.c: New testcase.
* isl-ast-gen-single-loop-2.c: New testcase.
* isl-ast-gen-single-loop-3.c: New testcase.
Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 212888)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -51,6 +51,8 @@
#include sese.h
#include tree-ssa-loop-manip.h
#include tree-scalar-evolution.h
+#include gimple-ssa.h
+#include tree-into-ssa.h
#include map
#ifdef HAVE_cloog
@@ -547,6 +549,73 @@
return last_e;
}
+/* Inserts in iv_map a tuple (OLD_LOOP-num, NEW_NAME) for the induction
+ variables of the loops around GBB in SESE.
+
+ FIXME: Instead of using a vectree that maps each loop id to a possible
+ chrec, we could consider using a mapint, tree that maps loop ids to the
+ corresponding tree expressions. */
+
+static void
+build_iv_mapping (vectree iv_map, gimple_bb_p gbb,
+ __isl_keep isl_ast_expr *user_expr, ivs_params ip,
+ sese region)
+{
+ gcc_assert (isl_ast_expr_get_type (user_expr) == isl_ast_expr_op
+ isl_ast_expr_get_op_type (user_expr) == isl_ast_op_call);
+ int i;
+ isl_ast_expr *arg_expr;
+ for (i = 1; i isl_ast_expr_get_op_n_arg (user_expr); i++)
+{
+ arg_expr = isl_ast_expr_get_op_arg (user_expr, i);
+ tree type =
+build_nonstandard_integer_type (graphite_expression_type_precision, 0);
+ tree t = gcc_expression_from_isl_expression (type, arg_expr, ip);
+ loop_p old_loop = gbb_loop_at_index (gbb, region, i - 1);
+ iv_map[old_loop-num] = t;
+}
+
+}
+
+/* Translates an isl_ast_node_user to Gimple.
+
+ FIXME: We should remove iv_map.create (loop-num + 1), if it is possible.
*/
+
+static edge
+translate_isl_ast_node_user (__isl_keep isl_ast_node *node,
+edge next_e, ivs_params ip)
+{
+ gcc_assert (isl_ast_node_get_type (node) == isl_ast_node_user);
+ isl_ast_expr *user_expr = isl_ast_node_user_get_expr (node);
+ isl_ast_expr *name_expr = isl_ast_expr_get_op_arg (user_expr, 0);
+ gcc_assert (isl_ast_expr_get_type (name_expr) == isl_ast_expr_id);
+ isl_id *name_id = isl_ast_expr_get_id (name_expr);
+ poly_bb_p pbb = (poly_bb_p) isl_id_get_user (name_id);
+ gcc_assert (pbb);
+ gimple_bb_p gbb = PBB_BLACK_BOX (pbb);
+ vectree iv_map;
+ isl_ast_expr_free (name_expr);
+ isl_id_free (name_id);
+
+ gcc_assert (GBB_BB (gbb) != ENTRY_BLOCK_PTR_FOR_FN (cfun)
+ The entry block should not even appear within a scop);
+
+ loop_p loop = gbb_loop (gbb);
+ iv_map.create (loop-num + 1);
+ iv_map.safe_grow_cleared (loop-num + 1);
+
+ build_iv_mapping (iv_map, gbb, user_expr, ip, SCOP_REGION (pbb-scop));
+ isl_ast_expr_free (user_expr);
+ next_e = copy_bb_and_scalar_dependences (GBB_BB (gbb),
+ SCOP_REGION (pbb-scop), next_e,
+ iv_map,
+ graphite_regenerate_error);
+ iv_map.release ();
+ mark_virtual_operands_for_renaming (cfun);
+ update_ssa (TODO_update_ssa);
+ return next_e;
+}
+
/* Translates an ISL AST node NODE to GCC representation in the
context of a SESE. */
@@ -567,7 +636,7 @@
return next_e;
case isl_ast_node_user:
- return next_e;
+ return translate_isl_ast_node_user (node, next_e, ip);
case isl_ast_node_block:
return next_e;
Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-1.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-1.c (working copy)
@@ -0,0 +1,26 @@
+/* { dg-do run } */
+/* { dg-options -O2 -fgraphite-identity -fgraphite-code-generator=isl } */
+
+int
+foo ()
+{
+ int i, res;
+
+ for (i = 0, res = 0; i 50; i++)
+ res += i;
+
+ return res;
+}
+
+extern void abort ();
+
+int
+main (void)
+{
+ int res = foo ();
+
+ if (res != 1225)
+abort ();
+
+ return 0;
+}
Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-2.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-2.c (revision 0)
+++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-2.c (working copy)
@@ -0,0 +1,34 @@
+/* { dg-do run }
Re: [PATCH, i386, PR61827] Fix fuse-caller-save-xmm.c test-case
On 21-07-14 09:31, Uros Bizjak wrote:
On Sun, Jul 20, 2014 at 12:25 PM, Tom de Vries tom_devr...@mentor.com wrote:
this patch fixes the problems in test-case
gcc.target/i386/fuse-caller-save-xmm.c reported in PR 61827. I've removed
the checks for cfi_def_cfa_offset, which were not robust enough for the
different configurations.
Furthermore, I've:
- added checks for all insns that handle the xmm registers, to make sure
we're
actually using the xmm1 register.
- fixed the scan-assembler-not lines to allow both %esp and %rsp.
You can use %\[re\]?sp here. We know that only r and e are valid.
- removed main, which was really only intended for the
fuse-caller-save-xmm-run.c test-case.
Tested with -m32 and -m64.
Probably you should also add -fomit-frame-pointer, otherwise the test
(that checks for SP based address) will fail on Darwin and Solaris
that default to frame pointers.
OK for trunk?
OK with the above changes.
Uros,
Dominique noticed that the .LC0 check failed on darwin, since the label LC0 is
used. This follow-up patch fixes that (and I see now you already Ok-ed this change).
Furthermore, I've realized from the comments in the PR that for solaris/sun-as
and darwin no cfi directives are generated. There are two other i386
fuse-caller-save tests which test cfi directives. The reason these tests aren't
failing for solaris/sun-as and darwin like the fuse-caller-save-xmm test did, is
because they test for the absence of specific cfi directives, which will always
pass if no cfi directives are generated. So I've removed the cfi directive
checks (and removed superfluous mains) and added tests on instructions.
Tested with -m32 and -m64.
OK for trunk?
Thanks,
- Tom
2014-07-21 Tom de Vries t...@codesourcery.com
PR target/61827
* gcc.target/i386/fuse-caller-save-xmm.c: Allow LC0 without dot prefix
for darwin in scan-assembler-times check.
* gcc.target/i386/fuse-caller-save.c: Remove cfi-related
scan-assembler-not checks. Add checks for insns.
(main): Remove.
* gcc.target/i386/fuse-caller-save-rec.c: Remove cfi-related
scan-assembler-not checks. Copy checks from i386/fuse-caller-save.c.
(main): Remove.
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c b/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
index b30a0b4..d1441bc 100644
--- a/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
@@ -18,14 +18,12 @@ foo (int y)
return y + bar (y);
}
-int
-main (void)
-{
- return !(foo (5) == 13);
-}
+/* Check that no registers are saved/restored. */
+/* { dg-final { scan-assembler-not push } } */
+/* { dg-final { scan-assembler-not pop } } */
-/* Verify that no registers where saved on stack. */
-/* { dg-final { scan-assembler-not \.cfi_offset } } */
+/* Check that addition uses dx. */
+/* { dg-final { scan-assembler-times addl\t%\[re\]?dx, %\[re\]?ax 1 } } */
/* Verify that bar is self-recursive. */
/* { dg-final { scan-assembler-times call\tbar 2 } } */
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
index c639936..4211a89 100644
--- a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
@@ -17,7 +17,7 @@ foo (v2df y)
/* Check presence of all insns on xmm registers. These checks are expected to
pass with both -fuse-caller-save and -fno-use-caller-save. */
-/* { dg-final { scan-assembler-times addpd\t\\.LC0.*, %xmm0 1 } } */
+/* { dg-final { scan-assembler-times addpd\t\\.?LC0.*, %xmm0 1 } } */
/* { dg-final { scan-assembler-times addpd\t%xmm1, %xmm0 1 } } */
/* { dg-final { scan-assembler-times movapd\t%xmm0, %xmm1 1 } } */
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save.c b/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
index 4ec4995..7e2b11d 100644
--- a/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
@@ -16,12 +16,9 @@ foo (int y)
return y + bar (y);
}
-int
-main (void)
-{
- return !(foo (5) == 13);
-}
-
-/* { dg-final { scan-assembler-not \.cfi_def_cfa_offset } } */
-/* { dg-final { scan-assembler-not \.cfi_offset } } */
+/* Check that no registers are saved/restored. */
+/* { dg-final { scan-assembler-not push } } */
+/* { dg-final { scan-assembler-not pop } } */
+/* Check that addition uses dx. */
+/* { dg-final { scan-assembler-times addl\t%\[re\]?dx, %\[re\]?ax 1 } } */
Re: [PATCH, i386, PR61827] Fix fuse-caller-save-xmm.c test-case
On Mon, Jul 21, 2014 at 12:34 PM, Tom de Vries tom_devr...@mentor.com wrote: Dominique noticed that the .LC0 check failed on darwin, since the label LC0 is used. This follow-up patch fixes that (and I see now you already Ok-ed this change). Furthermore, I've realized from the comments in the PR that for solaris/sun-as and darwin no cfi directives are generated. There are two other i386 fuse-caller-save tests which test cfi directives. The reason these tests aren't failing for solaris/sun-as and darwin like the fuse-caller-save-xmm test did, is because they test for the absence of specific cfi directives, which will always pass if no cfi directives are generated. So I've removed the cfi directive checks (and removed superfluous mains) and added tests on instructions. Tested with -m32 and -m64. OK for trunk? This is OK. Thanks, Uros.
Re: [PATCH, i386, PR61827] Fix fuse-caller-save-xmm.c test-case
On 21-07-14 12:40, Uros Bizjak wrote:
On Mon, Jul 21, 2014 at 12:34 PM, Tom de Vries tom_devr...@mentor.com wrote:
Dominique noticed that the .LC0 check failed on darwin, since the label LC0
is used. This follow-up patch fixes that (and I see now you already Ok-ed
this change).
Furthermore, I've realized from the comments in the PR that for
solaris/sun-as and darwin no cfi directives are generated. There are two
other i386 fuse-caller-save tests which test cfi directives. The reason
these tests aren't failing for solaris/sun-as and darwin like the
fuse-caller-save-xmm test did, is because they test for the absence of
specific cfi directives, which will always pass if no cfi directives are
generated. So I've removed the cfi directive checks (and removed superfluous
mains) and added tests on instructions.
Tested with -m32 and -m64.
OK for trunk?
This is OK.
Dominique noticed a symbol matching problem on darwin for
fuse-caller-save-rec.c.
I've committed this followup patch that fixes that problem.
Thanks,
- Tom
2014-07-21 Tom de Vries t...@codesourcery.com
PR target/61827
* gcc.target/i386/fuse-caller-save-rec.c: Allow underscore prefix to bar
symbol in scan-assembler-times call check.
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c b/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
index d1441bc..a0fcf9c 100644
--- a/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
@@ -26,5 +26,4 @@ foo (int y)
/* { dg-final { scan-assembler-times addl\t%\[re\]?dx, %\[re\]?ax 1 } } */
/* Verify that bar is self-recursive. */
-/* { dg-final { scan-assembler-times call\tbar 2 } } */
-
+/* { dg-final { scan-assembler-times call\t_?bar 2 } } */
Re: Patch for constexpr variable templates
Braden, I've played with this and it seems to work nicely. Only one comment: Could you put the test cases in the C++14 subdirectory? g++.dg/template/cpp1y/var-templ1.C ^ We should CC Jason on all this. Also, do you have your FSF paperwork in place? Thanks, Ed
Re: [GSoC] generation of Gimple code from isl_ast_node_user
On 21/07/2014 12:25, Roman Gareev wrote: I've asked the community about this. The patch below contains the FIXME. LGTM. Feel free to commit. Thanks, Tobias
