Re: [testsuite] skip ARM tests if no thumb2 support
On 14 June 2011 21:35, Janis Johnson jani...@codesourcery.com wrote: These tests apparently require thumb2 support (I don't yet know much about ARM). OK for trunk, and later 4.6? OK - The -march=armv7-a is redundant in these tests. You should be able to lose them if arm_thumb2_ok returns true. cheers Ramana
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
On Jun 14 18:01, DJ Delorie wrote: This is wrong as not all FSs are case insensitive. In fact HFS+ can be case sensitive too. I think you need better check than just saying all Darwin is case insensitive. This is just like using FAT32 on Linux. In fact I think HAVE_DOS_BASED_FILE_SYSTEM is incorrect also for NTFS as it can also be case sensitive. There's a difference between case preserving and case sensitive, though, and we really don't have a portable way to detect case-sensitivity on a per-directory basis, sow how can we do better? As Andrew points out, NTFS can be case-sensitive as well, and on Windows the case-sensitivity vs. case-preserving behaviour can be chosen for each file or directory descriptor at the time the file is opened. IMHO it's actually a pity that the filename comparison behaves differently on different systems. I think it would make sense to behave identical on all systems. What about this: Always search case-sensitive. If file has been found, return. Otherwise, search case-insensitive. Talking about case-insensitive comparison, the filename_cmp and filename_ncmp functions don't work for multibyte codesets, only for singlebyte codesets. Given that UTF-8 is standard nowadays, shouldn't these functions be replaced with multibyte-aware versions? Along the same lines, the entire set of safe-ctype functions only work for ASCII and EBCDIC... Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))
On Tue, 14 Jun 2011, Mike Stump wrote:
On Jun 13, 2011, at 3:57 AM, Richard Guenther wrote:
That's not exactly an example - I can't think of how you want or need
to use VIEW_CONVERT_EXPRs to implement said divmod instruction or why
you would need anything special for the _argument_ of said instruction.
Oh, I completely misunderstood your question. In my case, as I previously
stated, was with a vector type that was identical, save the name of the type:
mod = a%b
where mod didn't have the type of the expression (a%b), so someone created
the VIEW_CONVERT_EXPR on the mod. The person creating it _thought_ it would
be a rvalue context, but ultimately, it was an lvalue context. We discover
the lvalue/rvalue state of the expression at target_fold_builtin time. The
actual code looks more like:
__builtin_divmod (div, mod, a, b);
In fold_builtin, we do all the processing to handle the semantics.
An
instruction or call with multiple outputs would simply be something
like
{ div_1, mod_2 } = __builtin_divmod (arg_3);
with two SSA defs. A nice representation for the tree for { div_1,
mod_2 } remains to be found (if it should be a single tree at all, or
possibly multiple ones).
At target_fold_builtin time we regenerate it as:
s = builtin_divmod_final (a, b);
div_1 = s.div
mod_2 = s.mod
and generate a type { div, mod } on the fly. We expect the optimizer to
handle extra moves reasonably, and we want to keep the one instruction as one
unit.
We already play tricks for sincos for example via
tem_1 = __builtin_cexpi (arg_2);
sin_3 = REALPART_EXPR tem_1;
cos_4 = IMAGPART_EXPR tem_1;
which avoids the two defs by using a single def which is then decomposed.
So, can you elaborate a bit more on what you want to do with special
argument kinds? Elaborate with an actual example, not words.
We support tagging any parameter to a builtin as define_outputs,
define_inputs or define_in_outs in a part of the .md file that describes the
builtins for the machine, the actual divmod builtin for example is:
(define_builtin divmodT_ALL_DI:sign_u divmodT_ALL_DI:sign_u_type
[
(define_outputs [(var_operand:T_ALL_DI 0);;dividend
(var_operand:T_ALL_DI 1)]) ;;mod
(define_inputs [(var_operand:T_ALL_DI 2)
(var_operand:T_ALL_DI 3)])
(define_rtl_pattern T_ALL_DI:sign_udivmodm_mode4 [0 1 2 3])
(attributes [pure])
]
)
that's the actual code. The testcase looks like:
t_v4udi_0 = divmodu_t_v4udi (t_v4udi_1, t_v4udi_2, t_v4udi_3);
I see. So it's the C side of the representation that needs the
special operands.
The VIEW_CONVERT_EXPR looks like:
view_convert_expr 0x75a872d0
type vector_type 0x77f4b930 __attribute__((vector_size(32)))
unsigned long
type integer_type 0x77e8c690 long unsigned int public unsigned DI
size integer_cst 0x77e76730 constant 64
unit size integer_cst 0x77e76758 constant 8
align 64 symtab 0 alias set -1 canonical type 0x77e8c690
precision 64 min integer_cst 0x77e76780 0 max\
integer_cst 0x77e76708 18446744073709551615
pointer_to_this pointer_type 0x77f50738 reference_to_this
reference_type 0x77f513f0
unsigned V4DI
size integer_cst 0x77f43de8 constant 256
unit size integer_cst 0x77e76348 constant 32
align 256 symtab 0 alias set -1 canonical type 0x77f4b930 nunits
4 reference_to_this reference_type 0x77f51\
540
arg 0 var_decl 0x759d9640 t_v4udi_1
type vector_type 0x75ac3888 type integer_type 0x77e8c690
long unsigned int
unsigned V4DI size integer_cst 0x77f43de8 256 unit size
integer_cst 0x77e76348 32
align 256 symtab 0 alias set -1 canonical type 0x75ac3888
nunits 4
used public static unsigned V4DI defer-output file t22.c line 262 col
48 size integer_cst 0x77f43de8 256 unit \
size integer_cst 0x77e76348 32
align 256
This VIEW_CONVERT_EXPR looks useless - in fact useless_type_conversion_p
will tell you that, so you can omit it.
Richard.
Re: RFA minor DF cleanup
On Tue, Jun 14, 2011 at 6:04 PM, Jeff Law l...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I've noted in prior messages; I'm looking to improve our path isolation to improve code generation and reduce false positives from warnings. The patch that's been in my queue for some time now (and I suspect it's the final patch to our current implementation of jump threading) is capable of isolating more paths, but is certainly not capable of fully isolating every optimizable path through the CFG and eliminating all unexecutable paths through the CFG (neither of which is actually desirable due to potential code bloat issues). As a result of this better, but not full isolation, we can end up exposing a constant propagation in a unexecutable path through the CFG that isn't detected as unexecutable. As a result of exposing the constant propagation we can trigger a bogus warning from -Warray-bounds. The problem is we might have something like this: # BLOCK 11 freq:4946 # PRED: 9 [50.0%] (false,exec) 10 [100.0%] (fallthru,exec) 8 [28.0%] (false,exec) Invalid sum of incoming frequencies 2819, should be 4946 # D.39048_1 = PHI 3(9), D.39048_19(10), 4294967295(8) # VUSE .MEM_38(D) D.39016_24 = default_target_hard_regs.x_fixed_regs[D.39048_1]; - -Warray-bounds won't warn for this as it only triggers when we propagate a constant for an array index and the constant is out of bounds of the array. In this case D.39048_1 is not a constant and thus - -Warray-bounds does not issues a warning. The patch I've got queued up will isolate the path 8-9 (to optimize elsewhere). This results in a new block which looks like: temp = PHI (4294967295); D.39016_xx = default_target_hard_regs.x_fixed_regs[temp]; We then propagate the constant into the use of temp triggering the - -Warray-bounds warning. This is caused by this code fragment: /* Any constant, or pseudo with constant equivalences, may require reloading from memory using the pic register. */ if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM fixed_regs[PIC_OFFSET_TABLE_REGNUM]) bitmap_set_bit (regular_block_artificial_uses, PIC_OFFSET_TABLE_REGNUM); combined with this code from the x86 backend: #define PIC_OFFSET_TABLE_REGNUM \ ((TARGET_64BIT ix86_cmodel == CM_SMALL_PIC) \ || !flag_pic ? INVALID_REGNUM \ : reload_completed ? REGNO (pic_offset_table_rtx) \ : REAL_PIC_OFFSET_TABLE_REGNUM) While the new code can significantly improve path isolation, it's unable to fully isolate the paths in this code, leading to the partial isolation and exposing the constant propagation in the dead path which triggers -Warray-bounds warning. I'm hoping the ideas I'm working on for revamping how we handle path isolation may fix this, but it's hard to be sure right now. In the mean time, this patch fixes the instances where the next improvements to jump threading expose the bogus -Warray-bounds warning. Bootstrapped and regression tested on x86_64-unknown-linux-gnu. OK for mainline? Ok. Thanks, Richard. Thanks, Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN94aoAAoJEBRtltQi2kC7DwkIAI2zu87P0mqwf+NzI3BAPQpU GQl9d2Lw4z7diUfn7k+q2OqZMaoof9L0CqvhqC07Pz+UGzpke28o2WoS2Jrwxbj9 eQzC/H5DcAXmazvkwpe0BphvtqD+2Puz3pilQG1Nyopi1xJB5aKhC55VLntQuAvy +yaw/ozJ/d0Gt9myR/NXLe0NPfRycDeuC6U+iYRolJ7I/PxP/gZZ5dW68xakstLp oaQOakKmTres7CMWqG6ZV+5KJyQU92rnkp4ympKZGkciK1yI7Bl8fA87SqY/QkzN eDoGP37hQnJZkh39QLQjOZCfU5ywVAP81BnYsjaeSAOEd/SdQA63nIzVhGXoDEA= =K4dB -END PGP SIGNATURE-
[PATCH] Fix ICEs with -mxop __builtin_ia32_vpermil2p[sd]{,256} and __builtin_ia32_vprot[bwdq]i intrinsics (PR target/49411)
Hi!
All of these _mm{,256}_permute2_p[sd] and _mm_roti_epi{8,16,32,64}
intrinsics ICE if the last argument is constant integer, but not in the
expected range.
I could only find MSFT documentation for these intrinsics, where for
*permute2* it says that the last argument must be 0, 1, 2 or 3,
for *roti* it says that the last argument is integer rotation count,
preferrably constant and that if count is negative, it performs right
rotation instead of left rotation.
This patch adjusts the builtins to match that, if we want to instead
e.g. always mandate _mm_roti_epi* last argument is constant integer,
or constant integer in the range -N+1 .. N-1 where N is the number
after _mm_roti_epi, or in the range 0 .. N-1, it can be easily adjusted.
Regtested on x86_64-linux {-m32,-m64}, unfortunately on a SandyBridge
box, so I couldn't verify if xop-rotate[12]-int.c actually succeeds
on xop capable HW.
2011-06-15 Jakub Jelinek ja...@redhat.com
PR target/49411
* config/i386/i386.c (ix86_expand_multi_arg_builtins): If
last_arg_constant and last argument doesn't match its predicate,
for xop_vpermil2mode3 error out and for xop_rotlmode3
if it is CONST_INT, mask it, otherwise expand using rotlmode3.
* gcc.target/i386/xop-vpermil2px-1.c: New test.
* gcc.target/i386/xop-vpermil2px-2.c: New test.
* gcc.target/i386/xop-rotate1-int.c: New test.
* gcc.target/i386/xop-rotate2-int.c: New test.
--- gcc/config/i386/i386.c.jj 2011-06-09 16:56:56.0 +0200
+++ gcc/config/i386/i386.c 2011-06-15 11:17:12.0 +0200
@@ -26149,16 +26149,66 @@ ix86_expand_multi_arg_builtin (enum insn
int adjust = (comparison_p) ? 1 : 0;
enum machine_mode mode = insn_data[icode].operand[i+adjust+1].mode;
- if (last_arg_constant i == nargs-1)
+ if (last_arg_constant i == nargs - 1)
{
- if (!CONST_INT_P (op))
+ if (!insn_data[icode].operand[i + 1].predicate (op, mode))
{
- error (last argument must be an immediate);
- return gen_reg_rtx (tmode);
+ enum insn_code new_icode = icode;
+ switch (icode)
+ {
+ case CODE_FOR_xop_vpermil2v2df3:
+ case CODE_FOR_xop_vpermil2v4sf3:
+ case CODE_FOR_xop_vpermil2v4df3:
+ case CODE_FOR_xop_vpermil2v8sf3:
+ if (!CONST_INT_P (op))
+ {
+ error (last argument must be an immediate);
+ return gen_reg_rtx (tmode);
+ }
+ error (last argument must be in the range 0 .. 3);
+ return gen_reg_rtx (tmode);
+ case CODE_FOR_xop_rotlv2di3:
+ new_icode = CODE_FOR_rotlv2di3;
+ goto xop_rotl;
+ case CODE_FOR_xop_rotlv4si3:
+ new_icode = CODE_FOR_rotlv4si3;
+ goto xop_rotl;
+ case CODE_FOR_xop_rotlv8hi3:
+ new_icode = CODE_FOR_rotlv8hi3;
+ goto xop_rotl;
+ case CODE_FOR_xop_rotlv16qi3:
+ new_icode = CODE_FOR_rotlv16qi3;
+ xop_rotl:
+ if (CONST_INT_P (op))
+ {
+ int mask = GET_MODE_BITSIZE (GET_MODE_INNER (tmode)) - 1;
+ op = GEN_INT (INTVAL (op) mask);
+ gcc_checking_assert
+ (insn_data[icode].operand[i + 1].predicate (op, mode));
+ }
+ else
+ {
+ gcc_checking_assert
+ (nargs == 2
+ insn_data[new_icode].operand[0].mode == tmode
+ insn_data[new_icode].operand[1].mode == tmode
+ insn_data[new_icode].operand[2].mode == mode
+ insn_data[new_icode].operand[0].predicate
+ == insn_data[icode].operand[0].predicate
+ insn_data[new_icode].operand[1].predicate
+ == insn_data[icode].operand[1].predicate);
+ icode = new_icode;
+ goto non_constant;
+ }
+ break;
+ default:
+ gcc_unreachable ();
+ }
}
}
else
{
+ non_constant:
if (VECTOR_MODE_P (mode))
op = safe_vector_operand (op, mode);
--- gcc/testsuite/gcc.target/i386/xop-vpermil2px-1.c.jj 2011-06-15
10:18:29.0 +0200
+++ gcc/testsuite/gcc.target/i386/xop-vpermil2px-1.c2011-06-15
10:41:13.0 +0200
@@ -0,0 +1,25 @@
+/* PR target/49411 */
+/* { dg-do compile } */
+/* { dg-options -O0 -mxop } */
+
+#include x86intrin.h
+
+__m128d a1, a2, a3;
+__m256d b1, b2, b3;
+__m128 c1, c2, c3;
+__m256 d1, d2, d3;
+__m128i s;
+__m256i t;
+
+void
+foo (int i)
+{
+ a1 =
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
Date: Wed, 15 Jun 2011 10:22:36 +0200 From: Corinna Vinschen vinsc...@redhat.com On Jun 14 18:01, DJ Delorie wrote: This is wrong as not all FSs are case insensitive. In fact HFS+ can be case sensitive too. I think you need better check than just saying all Darwin is case insensitive. This is just like using FAT32 on Linux. In fact I think HAVE_DOS_BASED_FILE_SYSTEM is incorrect also for NTFS as it can also be case sensitive. There's a difference between case preserving and case sensitive, though, and we really don't have a portable way to detect case-sensitivity on a per-directory basis, sow how can we do better? As Andrew points out, NTFS can be case-sensitive as well, and on Windows the case-sensitivity vs. case-preserving behaviour can be chosen for each file or directory descriptor at the time the file is opened. IMHO it's actually a pity that the filename comparison behaves differently on different systems. I think it would make sense to behave identical on all systems. What about this: Always search case-sensitive. If file has been found, return. Otherwise, search case-insensitive. Over my dead body. On a proper operating system filenames are case-sensitive. Your suggestion would create spurious matches. Even on case-preserving filesystems I'd argue that treating them as case-sensitive is still the right approach. If that creates problems, it means somebody was sloppy and didn't type the proper name of the file or some piece of code in the toolchain arbitrarily changed the case of a filename. I don't mind punishing people for that. They have to learn that on a proper operating system file names are case-sensitive! If you're still using an operating system with fully case-insensitive filesystems, I feel very, very sorry for you. Talking about case-insensitive comparison, the filename_cmp and filename_ncmp functions don't work for multibyte codesets, only for singlebyte codesets. Given that UTF-8 is standard nowadays, shouldn't these functions be replaced with multibyte-aware versions? For UTF-8, that isn't necessary. Normal string manipulation functions work just fine on them, since UTF-8 strings don't contain any embedded NUL characters. It's only when you try to be too clever about case-insensitivity that you run into problems. Along the same lines, the entire set of safe-ctype functions only work for ASCII and EBCDIC... That really should only matter for displaying filenames. Anyway. I really don't care how deep a hole people have dug for themselves in trying to support Windows in all its various broken configurations. But on a native debugger for a UNIX-like system, or a cross debugger between such systems, filename_cmp() should simply do a strcmp().
Re: [Patch, AVR]: PR49313, fix PR29524
2011/6/15 Georg-Johann Lay a...@gjlay.de: This is a patch that implements some libgcc functions in assembler. The functions are used only very seldom but if, they lead to an unpleasant waste of resource. For example, some SF functions eventually lead to __clz_tab being dragged in (PR29524). This patch avoids that by straight forward assembler implementation of functions that are easy to implement. Tested without regression. Moreover, I tested functions in some self-written code against the old C-implementation. HI/QI functions tested for all possible inputs. Approved for AVR. May be you need another approval for longlong.h Denis.
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
On Jun 15 11:58, Mark Kettenis wrote: Date: Wed, 15 Jun 2011 10:22:36 +0200 From: Corinna Vinschen ... Please do not quote my email address in the body of your message. Thank you. IMHO it's actually a pity that the filename comparison behaves differently on different systems. I think it would make sense to behave identical on all systems. What about this: Always search case-sensitive. If file has been found, return. Otherwise, search case-insensitive. Over my dead body. On a proper operating system filenames are case-sensitive. Your suggestion would create spurious matches. Indeed. Probably the case sensitivity should not be hardcoded in a low-level function at all. The application should decide if it wants case-sensitive or case-insensitive filename comparison. This way, the comparison could be based on OS, filesystem, or user choice. Even on case-preserving filesystems I'd argue that treating them as case-sensitive is still the right approach. If that creates problems, it means somebody was sloppy and didn't type the proper name of the file or some piece of code in the toolchain arbitrarily changed the case of a filename. I don't mind punishing people for that. They have to learn that on a proper operating system file names are case-sensitive! I wasn't aware that gcc, gdb, and other tools using libiberty are supposed to punish people for the features of the OS they are working on. At one point I actually thought they were supposed to *help* developers. I seem to be wrong. Talking about case-insensitive comparison, the filename_cmp and filename_ncmp functions don't work for multibyte codesets, only for singlebyte codesets. Given that UTF-8 is standard nowadays, shouldn't these functions be replaced with multibyte-aware versions? For UTF-8, that isn't necessary. Normal string manipulation functions work just fine on them, since UTF-8 strings don't contain any embedded NUL characters. It's only when you try to be too clever about case-insensitivity that you run into problems. If you read the text you're replying to once more, you see that I'm explicitely talking about case-insensitive comparison. In that case, the functions won't work correctly, unless you use a singlebyte codeset. The tolower function on a single byte just doesn't make sense in multibyte charsets. The right thing to do would be something along the lines of mbstowcs (wide_a, a); mbstowcs (wide_b, b); return wcscasecmp (wide_a, wide_b); Along the same lines, the entire set of safe-ctype functions only work for ASCII and EBCDIC... That really should only matter for displaying filenames. It matters for case-insensitive filename comparison as well. Anyway. I really don't care how deep a hole people have dug for themselves in trying to support Windows in all its various broken configurations. I can't help but notice that you seem to have a strained relationship to Windows. However, if you read the OP again, you'll notice that the patch was supposed to help developers on MacOS, not Windows. For Windows the function already performs case-insensitive comparison, albeit wrong. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
On Wed, 15 Jun 2011, Corinna Vinschen wrote: these functions be replaced with multibyte-aware versions? Along the same lines, the entire set of safe-ctype functions only work for ASCII and EBCDIC... That's the whole point of safe-ctype: that code that is processing things such as C source code whose semantics do not depend on the host locale can examine character properties in a locale-independent way. Where C source code has multibyte characters, the correct handling depends in detail on the version of C and cannot be done by generic code. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
On Wednesday 15 June 2011 11:44:19, Corinna Vinschen wrote: Indeed. Probably the case sensitivity should not be hardcoded in a low-level function at all. The application should decide if it wants case-sensitive or case-insensitive filename comparison. This way, the comparison could be based on OS, filesystem, or user choice. http://sourceware.org/ml/gdb-patches/2010-12/msg00343.html (that only handles filename comparison, not file opening) -- Pedro Alves
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
On Jun 15 10:45, Joseph S. Myers wrote: On Wed, 15 Jun 2011, Corinna Vinschen wrote: these functions be replaced with multibyte-aware versions? Along the same lines, the entire set of safe-ctype functions only work for ASCII and EBCDIC... That's the whole point of safe-ctype: that code that is processing things such as C source code whose semantics do not depend on the host locale can examine character properties in a locale-independent way. Where C source code has multibyte characters, the correct handling depends in detail on the version of C and cannot be done by generic code. Ok, I see. Just in this specific case it's about filenames, not C source. I don't think it makes sense to restrict filenames to ASCII or EBCDIC chars. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
On 6/15/2011 5:58 AM, Mark Kettenis wrote: Over my dead body. On a proper operating system filenames are case-sensitive. Your suggestion would create spurious matches. Yes, we all know that Unix systems chose case sensitive, and are happy to have files differing only by case in the same directory. Obviously any proper software has to fully support such systems (if I was in the same mode as you and adding gratuitious flames to my comments, I would have preceded the word systems by brain-dead). Even on case-preserving filesystems I'd argue that treating them as case-sensitive is still the right approach. Absolutely not, please don't visit your unix-borne predjudices on non-unix systems. There is nothing worse for Windows users than having to put up with silly decisions like this that visit unix nonsense (and it is nonsense in a windows environment) on windows software. If that creates problems, it means somebody was sloppy and didn't type the proper name of the file The whole point in a system like Windows which is case preserving but not case sensitive is that you are NOT expected to type in the proper capitalization. In English, we recognize the words English and ENGLISH as equivalent, and windows users expect the same treatment. So the normal expectation in windows systems is that, yes, you can make nice capitalization like MyFile if you like, and it will be properly displayed. But any software that requires me to type MyFile rather than myfile is junk! If you're still using an operating system with fully case-insensitive filesystems, I feel very, very sorry for you. You are allowed to have this opinion, I feel the same about people who have to tolerate case-sensitive file systems, but I am quite happy with software for Unix systems fully behaving (I would agree that any software that EVER did case insensitive matching, as suggested earlier in this thread would be broken on Unix). But following your suggestion would be equally broken in Windows. or some piece of code in the toolchain arbitrarily changed the case of a filename. I don't mind punishing people for that. They have to learn that on a proper operating system file names are case-sensitive! This kind of unix arrogance leads to junk unusable software on windows. It's really important not to visit your unix predjudices on windows users. After all we feel the same way in return, I find Unix systems complete junk for many reasons, one of which is the very annoying case sensitive viewpoint, but I do not translate my feelings into silly suggestions for making software malfunction on Unix. You should not make this mistake in a reverse direction.
Re: [Patch, AVR]: PR49313, fix PR29524
Denis Chertykov schrieb: 2011/6/15 Georg-Johann Lay a...@gjlay.de: This is a patch that implements some libgcc functions in assembler. The functions are used only very seldom but if, they lead to an unpleasant waste of resource. For example, some SF functions eventually lead to __clz_tab being dragged in (PR29524). This patch avoids that by straight forward assembler implementation of functions that are easy to implement. Tested without regression. Moreover, I tested functions in some self-written code against the old C-implementation. HI/QI functions tested for all possible inputs. Approved for AVR. May be you need another approval for longlong.h Denis. CCed Ian Taylor as libgcc maintainer (assuming this is his preferred address). Unfortunately, the original mail could not yet be delivered to gcc-patches; I got a message reading something like (backtranslated to en): Subject: [Patch, AVR]: PR49313, fix PR29524 Sender: a...@gjlay.de Attention: Mail could not be delivered since 1 hour. Following receiver is affected: gcc-patches@gcc.gnu.org Error: 452 4.0.0 Insufficient system storage Explanation: host gcc.gnu.org [209.132.180.131] said: Message denied temporarily Last try: Wednesday, 15. Juni 2011 12:47:22 +0200 (MEST) I never got such message, and the patch is not really big. As I cannot backlink to the original message :-( copy-pasteing the relevant change inline: -- gcc/ PR target/49313 PR target/29524 * longlong.h: Add AVR support: (count_leading_zeros): New macro. (count_trailing_zeros): New macro. (COUNT_LEADING_ZEROS_0): New macro. Index: gcc/longlong.h === --- gcc/longlong.h (Revision 175036) +++ gcc/longlong.h (Arbeitskopie) @@ -250,6 +250,12 @@ UDItype __umulsidi3 (USItype, USItype); #define COUNT_LEADING_ZEROS_0 32 #endif +#if defined (__AVR__) W_TYPE_SIZE == 32 +#define count_leading_zeros(COUNT,X) ((COUNT) = __builtin_clzl (X)) +#define count_trailing_zeros(COUNT,X) ((COUNT) = __builtin_ctzl (X)) +#define COUNT_LEADING_ZEROS_0 32 +#endif /* defined (__AVR__) W_TYPE_SIZE == 32 */ + #if defined (__CRIS__) __CRIS_arch_version = 3 #define count_leading_zeros(COUNT, X) ((COUNT) = __builtin_clz (X)) #if __CRIS_arch_version = 8
[PATCH] Fix bitfield reduction during expansion
We handle integer types with bitfield precision but not other integral types which the middle-end considers equivalent. Noticed while working on bitfield reference lowering where this causes some miscompiles with boolean bitfields. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2011-06-15 Richard Guenther rguent...@suse.de * expr.c (expand_expr_real_2): Reduce all integral types to bitfield precision. (expand_expr_real_1): Likewise. Index: gcc/expr.c === --- gcc/expr.c (revision 175011) +++ gcc/expr.c (working copy) @@ -7264,7 +7264,7 @@ expand_expr_real_2 (sepops ops, rtx targ /* An operation in what may be a bit-field type needs the result to be reduced to the precision of the bit-field type, which is narrower than that of the type's mode. */ - reduce_bit_field = (TREE_CODE (type) == INTEGER_TYPE + reduce_bit_field = (INTEGRAL_TYPE_P (type) GET_MODE_PRECISION (mode) TYPE_PRECISION (type)); if (reduce_bit_field modifier == EXPAND_STACK_PARM) @@ -8333,7 +8333,7 @@ expand_expr_real_1 (tree exp, rtx target result to be reduced to the precision of the bit-field type, which is narrower than that of the type's mode. */ reduce_bit_field = (!ignore - TREE_CODE (type) == INTEGER_TYPE + INTEGRAL_TYPE_P (type) GET_MODE_PRECISION (mode) TYPE_PRECISION (type)); /* If we are going to ignore this result, we need only do something
Re: Cgraph alias reorg 22/14 (enable new infrastrucure for function-functoin aliases)
Jan Hubicka hubi...@ucw.cz writes: this patch switch regular function-function aliases to the new representation. I plan to followup with reorg of weakrefs and variable-variable aliases and then remove the infrastructure for aliases. It is however better to do these step by step so possible problems are easier to track. Please keep in mind that there are assemblers without weakref support (at least the Solaris and Tru64 UNIX assemblers). Index: cgraphunit.c === *** cgraphunit.c (revision 175078) --- cgraphunit.c (working copy) *** cgraph_analyze_functions (void) *** 1175,1180 --- 1175,1223 ggc_collect (); } + /* Translate the ugly representation of aliases as alias pairs into nice +representation in callgraph. We don't handle all cases yet, +unforutnately. */ ^ typo Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [testsuite] skip ARM neon-fp16 tests for other -mcpu values
On 10/06/11 00:43, Janis Johnson wrote: On 06/08/2011 03:17 AM, Joseph S. Myers wrote: On Tue, 7 Jun 2011, Janis Johnson wrote: These tests fail when multilib options use -mfpu= and override the -mfpu=neon-fp16 used for the test: g++.dg/ext/arm-fp16/arm-fp16-ops-5.C g++.dg/ext/arm-fp16/arm-fp16-ops-6.C gcc.dg/torture/arm-fp16-ops-5.c gcc.dg/torture/arm-fp16-ops-6.c gcc.target/arm/fp16-compile-vcvt.c The option -mfpu-neon-fp16 is added via dg-add-options arm_neon_fp16 after an earlier dg-require-effective-target arm_neon_fp16_ok. This patch modifies check_effective_target_arm_neon_fp16_ok_nocache to return 0 (causing the test to be skipped) if multilib flags include -mfpu= with a value other than neon-fp16. But I'd think they ought to work with any -mfpu= option supporting half-precision instructions - that is, vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd-fp16, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16, neon-vfpv4 (anything with true in the last field in arm-fpus.def; for the testsuite, you can probably suppose anything -mfpu=*fp16*, -mfpu=*fpv[4-9]*, -mfpu=*fpv[1-9][0-9]*). These tests look for specific instructions being generated and fail when the check is hacked up to allow other fp16 variants and not require neon. I'd like to use the original patch for this. OK? Janis That sounds like you might have uncovered a bug. Can you provide some more detail? Running (manually) gcc.target/arm/fp16-compile-vcvt.c with -O -mfpu=vfpv4 -mfp16-format=ieee gives the instructions required by the scanner. R.
Re: [PATCH][ARM] Add support for ADDW and SUBW instructions
On 06/06/11 15:31, Andrew Stubbs wrote: On 06/06/11 15:26, Dmitry Plotnikov wrote: On 06/06/2011 05:33 PM, Andrew Stubbs wrote: On 06/06/11 14:26, Dmitry Plotnikov wrote: if (const_ok_for_arm (INTVAL (x)) - || const_ok_for_arm (~INTVAL (x))) + || const_ok_for_arm (~INTVAL (x)) + || (TARGET_THUMB2 outer == PLUS + (const_ok_for_op (INTVAL (x), outer Sorry, I should have noticed before ... This whole condition should be covered by a single call to const_ok_for_op. It already calls const_ok_for_arm internally. This condition is not covered by const_ok_for_op, because outer can be equal to other rtx codes, which are not covered in const_ok_for_op like IF_THEN_ELSE or MULT (I have several ICEs with these codes). I don't know how to fix this correctly - should I add all codes to const_ok_for_op or maybe just replace default alternative from gcc_unreachable() to return 0; ? That sounds reasonable to me - I mean, the constant is indeed not ok for those operations. ... but I'm not a maintainer Andrew const_ok_for_op has grown beyond it's original intended use. A quick look at it shows that a change along the way you describe would first require fixing the assumption that if the constant matches const_ok_for_arm in an unmodified form that it is OK universally. That might be a good idea anyway, I'm not entirely sure that that's correct for all possible use cases these days. It's also likely that it needs extending to handle some of these cases you describe. Having an outer of IF_THEN_ELSE most likely means this is used in the case (set reg if_then_else(cond) (op_or_const) (const)) for which the rules would be the same as if const were used directly in a SET. But it's also equally likely that we don't calculate the costs of IF_THEN_ELSE very accurately anyway. R. R.
Re: [PATCH] Canonicalize compares in combine [3/3] ARM backend part
On 22/04/11 16:21, Chung-Lin Tang wrote: Hi Richard, this part's for you. The ARM backend changes needed are very little after the prior patches, basically just a case in arm_canonicalize_comparison() to detect (zero_extend:SI (subreg:QI (reg:SI ...) 0)), and swap it into (and:SI (reg:SI) #255). Had we not tried the combine modifications, this testcase probably could have also be solved by implementing another version of the corresponding *andsi3_compare0/_scratch patterns, with ZERO_EXTEND in the body, and ands in the output assembly. Maybe that's an acceptable solution too... About the (ab)use of CANONICALIZE_COMPARISON, if it really should be another macro/hook, then this ARM patch will need updating, but the code should be similar. Thanks, Chung-Lin 3-arm-parts.diff Index: config/arm/arm.c === --- config/arm/arm.c (revision 172860) +++ config/arm/arm.c (working copy) @@ -3276,6 +3276,19 @@ return code; } + /* If *op0 is (zero_extend:SI (subreg:QI (reg:SI) 0)) and comparing + with const0_rtx, change it to (and:SI (reg:SI) (const_int 255)), + to facilitate possible combining with a cmp into 'ands'. */ + if (mode == SImode + GET_CODE (*op0) == ZERO_EXTEND + GET_CODE (XEXP (*op0, 0)) == SUBREG + GET_MODE (XEXP (*op0, 0)) == QImode + GET_MODE (SUBREG_REG (XEXP (*op0, 0))) == SImode + SUBREG_BYTE (XEXP (*op0, 0)) == 0 + *op1 == const0_rtx) +*op0 = gen_rtx_AND (SImode, SUBREG_REG (XEXP (*op0, 0)), + GEN_INT (255)); + This is wrong for big-endian code. You should use subreg_lowpart_p to check the subreg expression (after you've checked that you do have a subreg, of course). R.
RE: [Patch, AVR]: Hack around PR34734
Hi Johann, I understand your reasoning, but I'm not particularly fond of this hack. Surely there's a way to fix this correctly without relying on this hack... Eric Weddington -Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Wednesday, June 15, 2011 3:26 PM To: gcc-patches@gcc.gnu.org Cc: Weddington, Eric; Anatoly Sokolov; Denis Chertykov Subject: [Patch, AVR]: Hack around PR34734 PR34734 is an annoying, false C++ warning for code like const int x __attribute__((progmem)) = 1; progmem.c:1:30: warning: only initialized variables can be placed into program memory area [enabled by default] The problem is that DECL_INITIAL is NULL at the specific point in space and time (avr_handle_progmem_attribute) even though tree.def promises otherwise. The patch hacks around by explicitly querying for C++ front end. Johann -- PR target/34734 * config/avr/avr.c (avr_handle_progmem_attribute): Hack around non-present DECL_INITIAL if front end is C++.
Re: [Patch, AVR]: Hack around PR34734
Weddington, Eric schrieb: Hi Johann, I understand your reasoning, but I'm not particularly fond of this hack. Yes, ACK. It's a hack to get rid of the PR. Surely there's a way to fix this correctly without relying on this hack... Surely, gcc is man-made ;-) Someone will have to dive into C++ FE/parser. Johann Eric Weddington -Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Wednesday, June 15, 2011 3:26 PM To: gcc-patches@gcc.gnu.org Cc: Weddington, Eric; Anatoly Sokolov; Denis Chertykov Subject: [Patch, AVR]: Hack around PR34734 PR34734 is an annoying, false C++ warning for code like const int x __attribute__((progmem)) = 1; progmem.c:1:30: warning: only initialized variables can be placed into program memory area [enabled by default] The problem is that DECL_INITIAL is NULL at the specific point in space and time (avr_handle_progmem_attribute) even though tree.def promises otherwise. The patch hacks around by explicitly querying for C++ front end. Johann -- PR target/34734 * config/avr/avr.c (avr_handle_progmem_attribute): Hack around non-present DECL_INITIAL if front end is C++.
Re: [ARM] fix C++ EH interoperability
On 05/23/11 16:52, Nathan Sidwell wrote: This patch fixes an interoperability issue with code generated by ARM's EABI compiler. ping? -- Nathan Sidwell
Re: PATCH [5/n]: Prepare x32: PR middle-end/48016: Inconsistency in non-local goto save area
Hi,
On Sat, 11 Jun 2011, H.J. Lu wrote:
We are very inconsistent when saving and restoring non-local goto save
area. See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48016
for detailed analysis. OK for trunk?
+ /* FIXME: update_nonlocal_goto_save_area may pass SA in the wrong mode. */
+ if (GET_MODE (sa) != mode)
+{
+ gcc_assert (ptr_mode != Pmode
+GET_MODE (sa) == ptr_mode
+mode == Pmode);
+ sa = adjust_address (sa, mode, 0);
+}
That may be appropriate for a branch, but trunk shouldn't contain FIXMEs
that explain how something should be fixed, instead that something should
be carried out. I.e. just fix update_nonlocal_goto_save_area.
Ciao,
Michael.
Re: PATCH: PR c++/49412: __dso_handle should be hidden
OK. Jason
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
Date: Wed, 15 Jun 2011 06:59:11 -0400 From: Robert Dewar de...@adacore.com CC: vinsc...@redhat.com, d...@redhat.com, pins...@gmail.com, brobec...@adacore.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org or some piece of code in the toolchain arbitrarily changed the case of a filename. I don't mind punishing people for that. They have to learn that on a proper operating system file names are case-sensitive! This kind of unix arrogance leads to junk unusable software on windows. It's really important not to visit your unix predjudices on windows users. After all we feel the same way in return, I find Unix systems complete junk for many reasons, one of which is the very annoying case sensitive viewpoint, but I do not translate my feelings into silly suggestions for making software malfunction on Unix. You should not make this mistake in a reverse direction. I cannot agree more.
Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))
On Jun 15, 2011, at 2:04 AM, Richard Guenther wrote:
This VIEW_CONVERT_EXPR looks useless - in fact useless_type_conversion_p
will tell you that, so you can omit it.
So, I tracked down who created it:
tree
convert_to_vector (tree type, tree expr)
{
switch (TREE_CODE (TREE_TYPE (expr)))
{
case INTEGER_TYPE:
case VECTOR_TYPE:
if (!tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (TREE_TYPE (expr
{
error (can%'t convert between vector values of different size);
return error_mark_node;
}
=return build1 (VIEW_CONVERT_EXPR, type, expr);
If people want to not create useless conversions in the first place, though, I
suspect there are lots of places that create useless conversions in the
compiler.
Re: [Patch] PR c++/26256
Hi,
After updating the patch, I now see a failure on c++0x forward enums.
Consider the below code:
template class T
struct S1
{
enum class E1;
enum class E1;
};
Currently, the second declaration of E1 relies on a successfull call
to supplement_binding_1.
With the patch I am working on, it no longer succeeds, because a new
check is needed, in order to fail if (target_)bval is a type (nearly
similar to the fix for c++/48010).
if (TREE_CODE (target_decl) == TYPE_DECL DECL_ARTIFICIAL (target_decl)
(TREE_CODE (target_bval) != TYPE_DECL
I don't really see a good solution to make it work.
As I already did for c++/48010, we can add the below check...
|| same_type_p (TREE_TYPE (target_decl), TREE_TYPE (target_bval)
But, same_type_p does not returns true, and it seems difficult to make
it return true because the underlying type of the DECL is not yet set
when calling pushtag1 in start_enum.
Otherwise, perhaps that it would be better if the second declaration
of E1 does not rely on supplement_binding_1.
What do you think ?
--
Fabien
[PATCH] Call estimate_numbers_of_iterations after insert_range_assertions (PR tree-optimization/49419)
Hi!
The following testcase is miscompiled e.g. on powerpc (not on x86_64/i686
due to different ivopts choices), because estimate_numbers_of_iterations
was called before assert_exprs are added to the IL and gets info cached
until adjust_range_with_scev, where using the original SSA_NAMEs leads
to problems where VR changes might not be propagated properly.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/4.6? I'll work on followup improvements for the trunk
afterwards.
2011-06-15 Jakub Jelinek ja...@redhat.com
PR tree-optimization/49419
* tree-vrp.c (execute_vrp): Call init_range_assertions
before estimate_numbers_of_iterations, call
free_number_of_iterations_estimates before calling
remove_range_assertions.
* gcc.c-torture/execute/pr49419.c: New test.
--- gcc/tree-vrp.c.jj 2011-05-31 08:03:10.0 +0200
+++ gcc/tree-vrp.c 2011-06-15 17:25:32.0 +0200
@@ -7730,14 +7730,14 @@ execute_vrp (void)
rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
scev_initialize ();
+ insert_range_assertions ();
+
/* Estimate number of iterations - but do not use undefined behavior
for this. We can't do this lazily as other functions may compute
this using undefined behavior. */
free_numbers_of_iterations_estimates ();
estimate_numbers_of_iterations (false);
- insert_range_assertions ();
-
to_remove_edges = VEC_alloc (edge, heap, 10);
to_update_switch_stmts = VEC_alloc (switch_update, heap, 5);
threadedge_initialize_values ();
@@ -7746,6 +7746,8 @@ execute_vrp (void)
ssa_propagate (vrp_visit_stmt, vrp_visit_phi_node);
vrp_finalize ();
+ free_numbers_of_iterations_estimates ();
+
/* ASSERT_EXPRs must be removed before finalizing jump threads
as finalizing jump threads calls the CFG cleanup code which
does not properly handle ASSERT_EXPRs. */
--- gcc/testsuite/gcc.c-torture/execute/pr49419.c.jj2011-06-15
18:06:43.0 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr49419.c 2011-06-15
18:05:18.0 +0200
@@ -0,0 +1,38 @@
+/* PR tree-optimization/49419 */
+
+extern void abort (void);
+
+struct S { int w, x, y; } *t;
+
+int
+foo (int n, int f, int *s, int m)
+{
+ int x, i, a;
+ if (n == -1)
+return 0;
+ for (x = n, i = 0; t[x].w == f i m; i++)
+x = t[x].x;
+ if (i == m)
+abort ();
+ a = i + 1;
+ for (x = n; i 0; i--)
+{
+ s[i] = t[x].y;
+ x = t[x].x;
+}
+ s[0] = x;
+ return a;
+}
+
+int
+main (void)
+{
+ int s[3], i;
+ struct S buf[3] = { { 1, 1, 2 }, { 0, 0, 0 }, { 0, 0, 0 } };
+ t = buf;
+ if (foo (0, 1, s, 3) != 2)
+abort ();
+ if (s[0] != 1 || s[1] != 2)
+abort ();
+ return 0;
+}
Jakub
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
On Jun 15 20:27, Eli Zaretskii wrote: Date: Wed, 15 Jun 2011 10:22:36 +0200 From: Corinna Vinschen ... Talking about case-insensitive comparison, the filename_cmp and filename_ncmp functions don't work for multibyte codesets, only for singlebyte codesets. Given that UTF-8 is standard nowadays, shouldn't these functions be replaced with multibyte-aware versions? I agree, but if we go that way, shouldn't we support UTF-16, which is used by the native Windows APIs? Windows does not use UTF-8 for file names. I don't think so. UTF-16 is Windows' wchar_t (or WCHAR) codeset, but the applications calling the libiberty functions are using the char datatype with single- or multibyte codesets. If the filename_cmp function converts the multibyte input strings to wchar_t and compares the wide char strings case insensitive(*), they would use UTF-16 under the hood on Windows anyway. (*) As proposed in http://sourceware.org/ml/gdb-patches/2011-06/msg00210.html, basically like this: #ifdef _WIN32 #define wcscasecmp _wcsicmp #endif mbstowcs (wide_a, a); mbstowcs (wide_b, b); return wcscasecmp (wide_a, wide_b); Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
RE: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on bdver1 and generic
I have no problems on -mtune=Bulldozer. But I object -mtune=generic change and did suggest a different approach for -mtune=generic. Something must have been broken for the unaligned load splitting in generic mode. While we lose 1.3% on CFP2006 in geomean by splitting unaligned loads for -mtune=bdver1, splitting unaligned loads in generic mode is KILLING us: For 459.GemsFDTD (ref) on Bulldozer, -Ofast -mavx -mno-avx256-split-unaligned-load: 480s -Ofast -mavx :2527s So, splitting unaligned loads results in the program to run 5~6 times slower! For 434.zeusmp train run -Ofast -mavx -mno-avx256-split-unaligned-load: 32.5s -Ofast -mavx :106s Other tests are on-going! Changpeng.
Re: [Patch, AVR]: Fix PR46779
On 06/15/2011 01:40 PM, Georg-Johann Lay wrote: But I still wonder what's the very problem. Any architecture has limited reg+const addressing and limited number of address registers. I definetely saw architectures run out of registers and reload manages to access stack beyond reg+maxoff without any hacks and clear and straight forward backend. Well, this is probably the only architecture that has *no* non-fixed, call-saved base registers. Indeed, I can work around this particular crash by either hacking Z to be call-saved, or hacking the frame pointer to not be required. The former of course changes the abi, and the second produces awful code due to too many copies from the stack pointer. So neither option is preferred. r~
Re: [testsuite] Run TLS torture tests with -fpic etc.
The patch isn't suitable as is. If -PIE requires -fPIC, then anything that adds it or tortures on it, should add both, or torture on both. The ABS relocs that I mentioned were from testglue.o which isn't built PIE or PIC and that's the reason for the failures to show up. Maybe the right solution is to rebuild tool*tg.o with anything that tortures on PIE or PIC ? Yes, I wasn't suggesting for a moment that this patch was suitable - I'm seeing a high number of failures in cross-testing . It was a big hammer 20 minutes before I left work to separate test failures from these and the other failures that I'm seeing. cheers Ramana
Re: [google] Add intermediate text format for gcov (issue4595053)
Ok for google/main.
David
On Tue, Jun 14, 2011 at 1:50 PM, Sharad Singhai (शरद सिंघई)
sing...@google.com wrote:
Sorry, Rietveld didn't send out the updated patch along with my mail.
Here it is.
Sharad
2011-06-14 Sharad Singhai sing...@google.com
Google Ref 3
* doc/gcov.texi: Document gcov intermediate format.
* gcov.c (get_gcov_file_intermediate_name): New function.
(output_intermediate_file): New function.
* testsuite/lib/gcov.exp: Handle intermediate format.
* testsuite/g++.dg/gcov/gcov-7.C: New test.
Index: doc/gcov.texi
===
--- doc/gcov.texi (revision 174926)
+++ doc/gcov.texi (working copy)
@@ -130,6 +130,7 @@
[@option{-f}|@option{--function-summaries}]
[@option{-o}|@option{--object-directory} @var{directory|file}]
@var{sourcefiles}
[@option{-u}|@option{--unconditional-branches}]
+ [@option{-i}|@option{--intermediate-format}]
[@option{-d}|@option{--display-progress}]
@c man end
@c man begin SEEALSO
@@ -216,6 +217,32 @@
@itemx --display-progress
Display the progress on the standard output.
+@item -i
+@itemx --intermediate-format
+Output gcov file in an intermediate text format that can be used by
+@command{lcov} or other applications. It will output a single *.gcov file per
+*.gcda file. No source code is required.
+
+The format of the intermediate @file{.gcov} file is plain text with
+one entry per line
+
+@smallexample
+SF:@var{source_file_name}
+FN:@var{line_number},@var{function_name}
+FNDA:@var{execution_count},@var{function_name}
+BA:@var{line_num},@var{branch_coverage_type}
+DA:@var{line number},@var{execution_count}
+
+Where the @var{branch_coverage_type} is
+ 0 (Branch not executed)
+ 1 (Branch executed, but not taken)
+ 2 (Branch executed and taken)
+
+There can be multiple SF entries in an intermediate gcov file. All
+entries following SF pertain to that source file until the next SF
+entry.
+@end smallexample
+
@end table
@command{gcov} should be run with the current directory the same as that
Index: gcov.c
===
--- gcov.c (revision 174926)
+++ gcov.c (working copy)
@@ -38,6 +38,7 @@
#include tm.h
#include intl.h
#include version.h
+#include demangle.h
#include getopt.h
@@ -310,6 +311,9 @@
static int flag_display_progress = 0;
+/* Output *.gcov file in intermediate format used by 'lcov'. */
+static int flag_intermediate_format = 0;
+
/* For included files, make the gcov output file name include the name
of the input source file. For example, if x.h is included in a.c,
then the output file name is a.c##x.h.gcov instead of x.h.gcov. */
@@ -436,6 +440,11 @@
fnotice (file, -o, --object-directory DIR|FILE Search for object
files in DIR or called FILE\n);
fnotice (file, -p, --preserve-paths Preserve all
pathname components\n);
fnotice (file, -u, --unconditional-branches Show
unconditional branch counts too\n);
+ fnotice (file, -i, --intermediate-format Output .gcov file
in an intermediate text\n\
+ format that can be used by 'lcov'
or other\n\
+ applications. It will output a single\n\
+ .gcov file per .gcda file. No
source file\n\
+ is required.\n);
fnotice (file, -d, --display-progress Display progress
information\n);
fnotice (file, \nFor bug reporting instructions, please see:\n%s.\n,
bug_report_url);
@@ -472,6 +481,7 @@
{ object-file, required_argument, NULL, 'o' },
{ unconditional-branches, no_argument, NULL, 'u' },
{ display-progress, no_argument, NULL, 'd' },
+ { intermediate-format, no_argument, NULL, 'i' },
{ 0, 0, 0, 0 }
};
@@ -482,7 +492,8 @@
{
int opt;
- while ((opt = getopt_long (argc, argv, abcdfhlno:puv, options,
NULL)) != -1)
+ while ((opt = getopt_long (argc, argv, abcdfhilno:puv, options, NULL)) !=
+ -1)
{
switch (opt)
{
@@ -516,6 +527,10 @@
case 'u':
flag_unconditional = 1;
break;
+ case 'i':
+ flag_intermediate_format = 1;
+ flag_gcov_file = 1;
+ break;
case 'd':
flag_display_progress = 1;
break;
@@ -531,6 +546,109 @@
return optind;
}
+/* Get the name of the gcov file. The return value must be free'd.
+
+ It appends the '.gcov' extension to the *basename* of the file.
+ The resulting file name will be in PWD.
+
+ e.g.,
+ input: foo.da, output: foo.da.gcov
+ input: a/b/foo.cc, output: foo.cc.gcov */
+
+static char *
+get_gcov_file_intermediate_name (const char *file_name)
+{
+ const char *gcov = .gcov;
+
Re: [Patch, AVR]: Fix PR46779
On 06/15/2011 02:58 PM, Richard Henderson wrote: Indeed, I can work around this particular crash by either hacking Z to be call-saved, or hacking the frame pointer to not be required. The former of course changes the abi, and the second produces awful code due to too many copies from the stack pointer. So neither option is preferred. Perhaps I spoke too soon re the frame pointer. The old code is even worse. textdata bss dec hex filename 10032 25 0 100572749 bld-avr-orig/gcc/z.o 5816 25 0584116d1 bld-avr-new/gcc/z.o That said, there's a crash building libgcc so there's still work to do. r~
Re: [PATCH, SMS] Fix violation of memory dependence
Hello, better do else if (!mem_read_insn_p (to-insn)) + create_ddg_dep_no_link (g, from, to, ANTI_DEP, MEM_DEP, 0); + } Done. Committed to -r175090. Thanks, Revital
Re: [PATCH, SMS 1/4] Fix calculation of row_rest_count
Revital Eres revital.e...@linaro.org wrote on 14/06/2011 09:27:32 AM: From: Revital Eres revital.e...@linaro.org To: Ayal Zaks/Haifa/IBM@IBMIL Cc: gcc-patches@gcc.gnu.org, Patch Tracking patc...@linaro.org Date: 14/06/2011 09:27 AM Subject: Re: [PATCH, SMS 1/4] Fix calculation of row_rest_count Hello, Please add the following: o A clarification that rows_length is used only (as an optimization) to back off quickly from trying to schedule a node in a full row; that is, to avoid running through futile DFA state transitions. o An assert that ps-rows_length[i] equals the number of nodes in ps- rows [i] (e.g., in verify_partial_schedule(); and then recheck...). Done. Besides the additions to address your comments I also added two more bits to update rows_length field into rotate_partial_schedule () and ps_insert_empty_row () that were missing in the previous implementation of the patch. Glad the additional assertion already proved useful ;-) The patch was re-tested on top of the patch to fix violation of memory dependence (http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00960.html) as follows: On ppc64-redhat-linux regtest as well as bootstrap with SMS flags, enabling SMS also on loops with stage count 1. Regtested on SPU. On arm-linux-gnueabi bootstrap c language with SMS flags enabling SMS also on loops with stage count 1 and currently regtseted on c,c++. OK for mainline with these changes once regtests on arm-linux-gnueabi completes? OK. Thanks, Ayal. Thanks, Revital * modulo-sched.c (struct ps_insn): Remove row_rest_count field. (struct partial_schedule): Add rows_length field. (verify_partial_schedule): Check rows_length. (ps_insert_empty_row): Handle rows_length. (create_partial_schedule): Likewise. (free_partial_schedule): Likewise. (reset_partial_schedule): Likewise. (create_ps_insn): Remove rest_count argument. (remove_node_from_ps): Update rows_length. (add_node_to_ps): Update rows_length and call create_ps_insn without passing row_rest_count. (rotate_partial_schedule): Update rows_length. [attachment patch_sms_5_6.txt deleted by Ayal Zaks/Haifa/IBM]
Turn on -pie on darwin11 and later
* mh-darwin: Turn off -pie on darwin11 and later.
2011-06-15 Mike Stump mikest...@comcast.net
* mh-darwin: Turn off -pie on darwin11 and later.
Index: mh-darwin
===
--- mh-darwin (revision 174625)
+++ mh-darwin (working copy)
@@ -1,5 +1,7 @@
# The -mdynamic-no-pic ensures that the compiler executable is built without
# position-independent-code -- the usual default on Darwin. This fix speeds
# compiles by 3-5%.
-
BOOT_CFLAGS += -mdynamic-no-pic
+
+# Ensure we don't try and use -pie, as it is incompatible with pch.
+BOOT_LDFLAGS=`case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; esac;`
Re: [patch, testsuite] Fix vectorizer testsuite failures on ARM
Steve Ellcey s...@cup.hp.com wrote on 15/06/2011 08:15:27 PM: testsuite/ChangeLog: * gcc.dg/vect/vect-16.c: Rename to ... * gcc.dg/vect/no-fast-math-vect16.c: ... this. * gcc.dg/vect/vect-peel-3.c: Adjust misalignment values for double-word vectors. * gcc.dg/vect/vect-peel-4.c: Likewise. * gcc.dg/vect/bb-slp-10.c: Replace vect_hw_misalign with vect_element_align. * gcc.dg/vect/vect.exp: Run no-fast-math-* tests with -fno-fast-math. Ira, This change broke vect-peel-3.c and vect-peel-4.c on IA64 HP-UX. I get these failures: FAIL: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-peel-4.c -flto scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-peel-4.c scan-tree-dump-times vect vectorized 1 loops 1 I think that changing i+6 and i+2 to i+5 and i+1 broke things on HP-UX because we are big-endian and the old values may not have worked on ARM because it is little-endian (just guessing). I am not sure what we want to do to make this test work on both platforms. Do you have any ideas? I don't think it is related to endianess. Could you please send me the dump files (created with -fdump-tree-vect-details)? Thanks, Ira Steve Ellcey s...@cup.hp.com
Updated^3: RFA: Fix middle-end/46500 (void * encapsulated)
Quoting Bernd Schmidt ber...@codesourcery.com:
Some of the formatting changes to avoid long lines are unfortunate (and
it's not done consistently); I think I'd prefer to add temporary
variables to hold the return value of pack_cumulative_args and
get_cumulative_args.
With the cumulative_args_t values available, it was more natural to also
convert emit_call_1 and initialize_argument_information, so I did that.
However, pass_by_reference and reference_callee_copied are called in a number
of places from target ports, so I've left this for a later round of
patches and/or discussion.
Likewise, it becomes a bit clearer what we need from a hook
replaceemnt of INIT_CUMULATIVE_ARGS, which we can discuss later.
I think it would be best just to minimize changes in backends as much as
possible by using the following pattern everywhere:
static void
-ix86_function_arg_advance (CUMULATIVE_ARGS *cum, enum machine_mode mode,
+ix86_function_arg_advance (cumulative_args_t cum_v, enum machine_mode mode,
const_tree type, bool named)
{
+ CUMULATIVE_ARGS *cum = get_cumulative_args (cum_v);
I.e., avoid changes such as the one in mn10300_function_arg_advance.
I've employed this pattern now in all the target hook implementation heads
except where there was a only a trivial single substitution that caused
little or no reformatting.
Also,
- if (iq2000_function_arg (temp, mode, type, named) != 0)
+ if (iq2000_function_arg (pack_cumulative_args (temp), mode,
type, named) != 0)
Extra tab character before !=.
Actually, it was a missing carriage return.
46500-patch-20110615.gz
Description: GNU Zip compressed data
