Re: rl78-elf: Compilation broken due to missing constraint
On Fri, 2013-07-12 04:42:26 +, Kaushik Phatak kaushik.pha...@kpitcummins.com wrote: I guess you forgot a small patch to constraints.md, because since this commit which uses a new U constraint, the rl78-elf target won't build: 2013-05-31 Kaushik Phatak kaushik.pha...@kpitcummins.com * config/rl78/rl78.md (mulqi3,mulhi3): New define_expands. (*mulqi3_rl78,*mulhi3_rl78,*mulhi3_g13): New define_insns. Yes, DJ did point out this missing constraint in my patch. I have posted this and committed this patch last month itself, http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00643.html It does seem to have got submitted to gcc-cvs and I am able to see this change when I do a svn update, http://gcc.gnu.org/ml/gcc-cvs/2013-06/msg00409.html Please correct me if I am wrong on this. I think that you simply missed to commit the constraints.md part of the patch. Looking at SVN commit 199976 (http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=199976), the changelog mentions the addition of the new U constraint, but the actual patch is missing it. And if you look at the gcc-...@gcc.gnu.org email that was caused by your commit, the constraints.md part is missing there, too. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Zensur im Internet? Nein danke! the second : signature.asc Description: Digital signature
RE: rl78-elf: Compilation broken due to missing constraint
the changelog mentions the addition of the new U constraint, but the actual patch is missing it. Yes, I think you got it right. I have resubmitted this part of the patch again and confirmed the commit in svn. Best Regards, Kaushik
Question on the fwprop pass
Hi,
I encountered below example,
bb x
79: r169:SI=r190:SI0x2
bb y
115: r180:SI=r180:SI+r169:SI
116: cc:CC=cmp(r181:SI,r190:SI)
117: pc={(cc:CC==0)?L125:pc}
The register r169 is only defined by insn79, so I was hoping the
reference in insn115 can be replaced by r1900x2, thus saving one
instruction and one live pseudo register.
Problem is fwprop pass doesn't do this now because function
propagate_rtx_1 only returns true if PR_CAN_APPEAR is set, which is
not in this case because of below code in propagate_rtx:
flags = 0;
if (REG_P (new_rtx)
|| CONSTANT_P (new_rtx)
|| (GET_CODE (new_rtx) == SUBREG
REG_P (SUBREG_REG (new_rtx))
(GET_MODE_SIZE (mode)
= GET_MODE_SIZE (GET_MODE (SUBREG_REG (new_rtx))
flags |= PR_CAN_APPEAR;
if (!for_each_rtx (new_rtx, varying_mem_p, NULL))
flags |= PR_HANDLE_MEM;
if (speed)
flags |= PR_OPTIMIZE_FOR_SPEED;
I did experiment by setting PR_CAN_APPEAR here but fwprop doesn't work
correctly any more.
So question is Why we don't do such transformation in fwprop pass and
how should this be handled?
Thanks very much.
--
Best Regards.
Re: Should -Wmaybe-uninitialized be included in -Wall?
On Wed, Jul 10, 2013 at 06:11:11PM +0200, Andi Kleen wrote: FWIW basically -Werror -Wall defines a compiler version specific variant of C. May be great for individual developers, but it's always a serious mistake in any distributed Makefile. Not always. Any project large enough (or serious enough about build reproducibility) to include its own toolchain can be written in that compiler-version-specific subset and nonetheless be worked on by more than one person. This is not uncommon in the BSDs, for example; see instances of WARNS=4. It's an uncommon use case (and, I think, not a justification for changing -Wall), but it does exist and it is useful. --Jed
$275+ CPA: Become a Binary Option Affiliate
Dear Affiliate, How are you? If you are interested in generous CPAs, please register now as affiliate on http://www.binaryaffiliates.com/?am=40 This month, we offer an additional $25 per trader, at the top of the regular $250, for one selected brand. Binary Options allow clients to profit, when they predict correctly if a stock/currency/commodity will go up or down. The time-frame for the prediction varies from 60 seconds to 60 minutes. That makes for a lot of fun and fast-paced action! I know your time is precious, so I'll keep it short. After you register on http://www.binaryaffiliates.com/?am=40 (it takes less than a minute!) please drop me an email, and we can start working on a fun, rewarding and PROFITABLE partnership! And I can activate the $15 additional reward for you. Thanks and best regards, Roger Binary Affiliates Recruitment Manager
GCC Re-architecture BOF
In case anyone is planning to attend the BOF on Sunday and missed the proposal document posted last month, it can be found here: http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFiledo=viewtarget=gccrestructureplan2.1.pdf Andrew
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored -Wundef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Fabio nomegenerico at email dot it changed: What|Removed |Added CC||nomegenerico at email dot it --- Comment #3 from Fabio nomegenerico at email dot it --- Same BUG in MinGW (version shipped with the Qt5.1 framework) gcc --version gcc (rev2, Built by MinGW-builds project) 4.8.0 Copyright (C) 2013 Free Software Foundation, Inc.
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 --- Comment #8 from David Binderman dcb314 at hotmail dot com --- Still fails on 20130710. Another test case that generates the same message is available on request.
[Bug middle-end/56417] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56417 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #3 from David Binderman dcb314 at hotmail dot com --- Still seems to be broken with 20130710. An additional test case is available on request.
[Bug middle-end/57886] New: Invalid folding of (float)-x to -(float)x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57886
Bug ID: 57886
Summary: Invalid folding of (float)-x to -(float)x
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: matz at gcc dot gnu.org
Came up in IRC, GCC invalidly moves a conversion innerwards:
% cat x.c
extern void abort (void);
float global;
int main()
{
unsigned long z = 1;
float x = -z;
global = x;
if (global 0)
abort ();
return 0;
}
% gcc x.c ./a.out
Aborted
This is because GCC transforms the initializer of x (float)-z, into
-(float)z, even though z is an unsigned int. -z is always positive, but
due to this x will be -1.
[Bug c++/57887] New: nested non-type template parameters not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57887
Bug ID: 57887
Summary: nested non-type template parameters not declared in
this scope
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
Hi, when trying to compile the following:
struct B
{
templateint N
struct A
{
int X = N;
};
};
I get the error:
g.cxx:6:11: error: 'N' was not declared in this scope
Things work fine when I make X a static const(expr), or when I move A outside
B. The above code however works fine within clang, and I could not find any
wording that would make N suddenly not being available within A, especially
since when you add teh following member function to A (but remove X), it
compiles fine:
void foo( ) { int x = N; }
so it /somehow/ is in scope.
[Bug libitm/57855] passing unsafe function as transaction_safe function pointer does not generate error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57855 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail dot com --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com --- There was a related discussion here: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00598.html Probably we can modify Dave's patch a bit.
[Bug c++/57888] New: using non-type template parameter in constexpr function for non static data member intializer segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57888
Bug ID: 57888
Summary: using non-type template parameter in constexpr
function for non static data member intializer
segfaults
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
While trying to find workaronuds for Bug #57887 I tried the following code:
struct B
{
templateint N
struct A
{
constexpr int get_N() { return N; }
// int X = N;
int X = get_N();
void foo( )
{
int x = N;
}
};
};
Which made gcc segfault. Whatever the validity of #57887 is, I don't think it
should segfault here...
[Bug middle-end/57886] Invalid folding of (float)-x to -(float)x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57886 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Dup of PR55771?
[Bug middle-end/57886] Invalid folding of (float)-x to -(float)x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57886 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Michael Matz matz at gcc dot gnu.org --- Indeed. *** This bug has been marked as a duplicate of bug 55771 ***
[Bug middle-end/55771] Negation and type conversion incorrectly exchanged
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55771 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #12 from Michael Matz matz at gcc dot gnu.org --- *** Bug 57886 has been marked as a duplicate of this bug. ***
[Bug c/57889] New: Improvement: builtin to return a string from a type (type to string builtin)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57889
Bug ID: 57889
Summary: Improvement: builtin to return a string from a type
(type to string builtin)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Hi,
It might be of interest to have a builtin to convert a type name to a string.
Given a type or a variable, the builtin would return the type of it as a
string.
It could be used to build debug messages:
#define ASSERT_NULL(p) do { \
if ((p) == NULL) \
printf(%s * %s == NULL\n, __builtin_typestringof(*p), #p); \
} while(0);
Regards.
[Bug target/57717] error: unrecognizable insn compiling ./strtod_l.c from glibc on powerpc-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717 Alexandru-Cezar Sărdan alexandru.sardan at freescale dot com changed: What|Removed |Added CC||alexandru.sardan@freescale. ||com --- Comment #5 from Alexandru-Cezar Sărdan alexandru.sardan at freescale dot com --- Created attachment 30500 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30500action=edit testcase The attached test case causes another ICE if gcc is compiled for gnuspe targets after the patch proposed in comment #4 is applied and -mfloat-gprs=double is used. Also -mfloat-gprs=single works fine. $ ./gcc/cc1 -m32 -mcpu=8548 -mabi=spe -mspe -mfloat-gprs=double ~/test.c __bswap_32 __bswap_64 create_Result_file main Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups *free_inline_summary whole-programAssembling functions: create_Result_file /home/alex/test.c: In function 'create_Result_file': /home/alex/test.c:43:1: internal compiler error: in change_address_1, at emit-rtl.c:2019 } ^
[Bug c++/57890] New: gcc 4.8.1 regression: loops become slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57890
Bug ID: 57890
Summary: gcc 4.8.1 regression: loops become slower
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dushistov at mail dot ru
$cat what_test.cpp
char c[100];
void f(void)
{
for(int i=0; i 100; ++i)
c[i] = '0';
}
I run this test with:
cat test.cpp
#include cstddef
extern void f();
int main()
{
for (size_t i = 0; i 1; ++i)
f();
}
compile with -march=native -O3 on (i7 64bit mode).
Here is result:
for test_loop47 we get average 0.348000
for test_loop481 we get average 0.40
If compare generated code then on 4.7 f function is transformed to:
push %rbp
vmovdqa 0x107(%rip),%ymm0
movb $0x30,0x200aa0(%rip)
movb $0x30,0x200a9a(%rip)
mov%rsp,%rbp
vmovdqa %ymm0,0x200a2e(%rip)
...
on gcc 4.8.1:
movabs $0x3030303030303030,%rax
movl $0x30303030,0x200a9c(%rip)
mov%rax,0x200a35(%rip)
mov%rax,0x200a36(%rip)
...
PS
I just checked may be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55953
fixed in gcc 4.8.1,
and yes it indeed fixed, instead of optimal for loops and
not optimal for builtin_memset it now produces not the same not optimal code
for both cases.
[Bug target/57890] gcc 4.8.1 regression: loops become slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57890 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Component|c++ |target Severity|major |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- That would mean the expansion for memset is not optimal for the target which means this is a target issue rather than a C++ front-end or a middle-end issue.
[Bug c/57889] Improvement: builtin to return a string from a type (type to string builtin)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57889 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- __builtin_typename would be a better name I suspect.
[Bug middle-end/56417] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56417 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.2 Known to fail||4.8.1, 4.9.0 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, confirmed.
[Bug rtl-optimization/57878] Incorrect code: live register clobbered in split2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57878
--- Comment #2 from Easwaran Raman eraman at google dot com ---
After IRA, we have:
(insn 116 115 117 6 (set (reg:DI 130 [ D.3288 ])
(mem:DI (plus:SI (reg/v/f:SI 172 [orig:109 __first ] [109])
(const_int 4 [0x4])) [10 MEM[base: _1, index: _44, offset: 0]+0
S8 A64])) r.ii:197 88 {*movdi_internal}
(expr_list:REG_EQUIV (mem:DI (plus:SI (reg/v/f:SI 172 [orig:109 __first ]
[109])
(const_int 4 [0x4])) [10 MEM[base: _1, index: _44, offset: 0]+0
S8 A64])
(nil)))
(insn 117 116 118 6 (parallel [
(set (reg/f:SI 138 [ D.3281 ])
(minus:SI (reg/v/f:SI 173 [orig:110 __cur ] [110])
(reg/v/f:SI 103 [ __cur ])))
(clobber (reg:CC 17 flags))
]) 309 {*subsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 118 117 119 6 (parallel [
(set (reg/f:SI 140 [ D.3282 ])
(plus:SI (reg/v/f:SI 103 [ __cur ])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) 273 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 119 118 120 6 (set (mem:DI (plus:SI (reg/v/f:SI 173 [orig:110 __cur ]
[110])
(const_int 4 [0x4])) [10 MEM[base: _75, index: _77, offset:
0B]+0 S8 A64])
(reg:DI 130 [ D.3288 ])) r.ii:197 88 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 130 [ D.3288 ])
(nil)))
(insn 120 119 121 6 (set (reg:DI 131 [ D.3287 ])
(mem:DI (plus:SI (plus:SI (reg/f:SI 99 [ D.3281 ])
(reg/f:SI 126 [ D.3282 ]))
(const_int 8 [0x8])) [10 MEM[base: _1, index: _44, offset: 8]+0
S8 A64])) r.ii:197 88 {*movdi_internal}
(expr_list:REG_EQUIV (mem:DI (plus:SI (plus:SI (reg/f:SI 99 [ D.3281 ])
(reg/f:SI 126 [ D.3282 ]))
(const_int 8 [0x8])) [10 MEM[base: _1, index: _44, offset: 8]+0
S8 A64])
(nil)))
(insn 121 120 122 6 (set (mem:DI (plus:SI (plus:SI (reg/f:SI 138 [ D.3281 ])
(reg/f:SI 140 [ D.3282 ]))
(const_int 8 [0x8])) [10 MEM[base: _75, index: _77, offset:
8B]+0 S8 A64])
(reg:DI 131 [ D.3287 ])) r.ii:197 88 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 131 [ D.3287 ])
(nil)))
After reload,
1. insn 116 is deleted
2. In insn 117, the pseudo 138 is replaced with dx
3. dx is spilled into stack at offset -0x36 from bp.
4. For insn 119, first a new pseudo 193 is created which is equivalent to 130
and is loaded from memory. This 193 is in DI mode and is replaced by ax. This
would clobber edx, but that is ok since dx is now stored into stack at offset
-0x36.
5. This is followed by the the store of 193 (ax) into memory location.
6. Then dx is loaded from bp-0x36.
7. insn 120 is deleted
8. For insn 121, the pseudo 131 is replaced by 196 which is assigned the hard
reg ax.
In the sequence above, shouldn't the fill of dx from bp-0x36 at step 6 above
happen after step 8?
[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333 --- Comment #22 from Marc Glisse glisse at gcc dot gnu.org --- Did someone try to bootstrap gcc using CC=suncc CXX='sunCC -library=stlport4' recently? Is this PR still relevant?
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834 --- Comment #13 from M.S. Babaei ace.of.zerosync at gmail dot com --- (In reply to James Kanze from comment #9) Re using the init list syntax: it won't work if you have to be compatible with other compilers (like Sun CC). Using something like (Doh (x)), ++x seems to be the most portable work-around. Sorry, I didn't get your answer at first sight. Actually your elegant workaround is the most portable way. And, works on all compilers, too. Even pre-C++11 era compilers. Thanks.
Re: [C++ Patch] for c++/54537
Hi, 2013/5/23 Jason Merrill ja...@redhat.com On 05/22/2013 04:53 PM, Fabien Chêne wrote: Ah, I see, it works. Then we end up with three solutions: 1) remove the pow(double,double) overload 2) add a specialization template pow(double,double) 3) add an extern C declaration to refer to the C library function I don't have a strong preference, I would say that all solutions are more or less equivalent. In the end, builtins are just reached in different ways I guess, depending on the optimisations enabled. Given that Paolo already OKed the solution 1), I would go for it. I guess #1 and #2 involve forwarding through a template, whereas #3 avoids that and might give cleaner code without optimization. But library design issues might be more important, so library folks should make the call here. Saying that discussions are encouraged -- or even better a decision --, is an understatement... My opinion is that if #3 is the best choice, then it should not be restricted to this case, and should be applied on all cases where functions are forwarded through templates to builtins. Then, It seems to me that such a change should ideally go in a separate patch. Thank you. -- Fabien
[Patch, AArch64] Support AdvSIMD MOVI / MVNI shifting ones variant.
Hi,
This patch adds support for AdvSIMD MOVI/MVNI Vd.T, #imm8, MSL, #amount.
OK?
Thanks,
Tejas Belagod
ARM.
Changelog:
2013-07-12 Tejas Belagod tejas.bela...@arm.com
gcc/
* config/aarch64/aarch64-protos.h
(aarch64_simd_immediate_valid_for_move): Remove.
* config/aarch64/aarch64.c (simd_immediate_info): New member.
(aarch64_simd_valid_immediate): Recognize idioms for shifting ones
cases.
(aarch64_output_simd_mov_immediate): Print the correct shift specifier.
testsuite/
* gcc.target/aarch64/vect-movi.c: New.diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index e5ae556..c4ea1fa 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -181,9 +181,6 @@ int aarch64_asm_preferred_eh_data_format (int, int);
int aarch64_hard_regno_mode_ok (unsigned, enum machine_mode);
int aarch64_hard_regno_nregs (unsigned, enum machine_mode);
int aarch64_simd_attr_length_move (rtx);
-int aarch64_simd_immediate_valid_for_move (rtx, enum machine_mode, rtx *,
- int *, unsigned char *, int *,
- int *);
int aarch64_uxt_size (int, HOST_WIDE_INT);
rtx aarch64_final_eh_return_addr (void);
rtx aarch64_legitimize_reload_address (rtx *, enum machine_mode, int, int,
int);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 94db053..9fa18b6 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -93,6 +93,7 @@ struct simd_immediate_info
int shift;
int element_width;
bool mvn;
+ bool msl;
};
/* The current code model. */
@@ -6319,16 +6320,16 @@ aarch64_simd_valid_immediate (rtx op, enum machine_mode
mode, bool inverse,
CHECK (2, 16, 11, bytes[i] == 0xff bytes[i + 1] == bytes[1], 8, 1);
CHECK (4, 32, 12, bytes[i] == 0xff bytes[i + 1] == bytes[1]
- bytes[i + 2] == 0 bytes[i + 3] == 0, 0, 0);
+ bytes[i + 2] == 0 bytes[i + 3] == 0, 8, 0);
CHECK (4, 32, 13, bytes[i] == 0 bytes[i + 1] == bytes[1]
- bytes[i + 2] == 0xff bytes[i + 3] == 0xff, 0, 1);
+ bytes[i + 2] == 0xff bytes[i + 3] == 0xff, 8, 1);
CHECK (4, 32, 14, bytes[i] == 0xff bytes[i + 1] == 0xff
- bytes[i + 2] == bytes[2] bytes[i + 3] == 0, 0, 0);
+ bytes[i + 2] == bytes[2] bytes[i + 3] == 0, 16, 0);
CHECK (4, 32, 15, bytes[i] == 0 bytes[i + 1] == 0
- bytes[i + 2] == bytes[2] bytes[i + 3] == 0xff, 0, 1);
+ bytes[i + 2] == bytes[2] bytes[i + 3] == 0xff, 16, 1);
CHECK (1, 8, 16, bytes[i] == bytes[0], 0, 0);
@@ -6337,12 +6338,7 @@ aarch64_simd_valid_immediate (rtx op, enum machine_mode
mode, bool inverse,
}
while (0);
- /* TODO: Currently the assembler cannot handle types 12 to 15.
- And there is no way to specify cmode through the compiler.
- Disable them till there is support in the assembler. */
- if (immtype == -1
- || (immtype = 12 immtype = 15)
- || immtype == 18)
+ if (immtype == -1)
return false;
if (info)
@@ -6353,6 +6349,9 @@ aarch64_simd_valid_immediate (rtx op, enum machine_mode
mode, bool inverse,
unsigned HOST_WIDE_INT imm = 0;
+ if (immtype = 12 immtype = 15)
+ info-msl = true;
+
/* Un-invert bytes of recognized vector, if necessary. */
if (invmask != 0)
for (i = 0; i idx; i++)
@@ -7285,10 +7284,11 @@ aarch64_output_simd_mov_immediate (rtx const_vector,
bool is_valid;
static char templ[40];
const char *mnemonic;
+ const char *shift_op;
unsigned int lane_count = 0;
char element_char;
- struct simd_immediate_info info;
+ struct simd_immediate_info info = { NULL_RTX, 0, 0, false, false };
/* This will return true to show const_vector is legal for use as either
a AdvSIMD MOVI instruction (or, implicitly, MVNI) immediate. It will
@@ -7324,14 +7324,15 @@ aarch64_output_simd_mov_immediate (rtx const_vector,
}
mnemonic = info.mvn ? mvni : movi;
+ shift_op = info.msl ? msl : lsl;
if (lane_count == 1)
snprintf (templ, sizeof (templ), %s\t%%d0, HOST_WIDE_INT_PRINT_HEX,
mnemonic, UINTVAL (info.value));
else if (info.shift)
snprintf (templ, sizeof (templ), %s\t%%0.%d%c, HOST_WIDE_INT_PRINT_HEX
- , lsl %d, mnemonic, lane_count, element_char,
- UINTVAL (info.value), info.shift);
+ , %s %d, mnemonic, lane_count, element_char,
+ UINTVAL (info.value), shift_op, info.shift);
else
snprintf (templ, sizeof (templ), %s\t%%0.%d%c, HOST_WIDE_INT_PRINT_HEX,
mnemonic, lane_count, element_char, UINTVAL (info.value));
diff --git a/gcc/testsuite/gcc.target/aarch64/vect-movi.c
b/gcc/testsuite/gcc.target/aarch64/vect-movi.c
new file mode 100644
index 000..59a0bd5
--- /dev/null
+++
Re: [Patch, AArch64] Support AdvSIMD MOVI / MVNI shifting ones variant.
On 12/07/13 11:25, Tejas Belagod wrote: Hi, This patch adds support for AdvSIMD MOVI/MVNI Vd.T, #imm8, MSL, #amount. OK? Thanks, Tejas Belagod ARM. Changelog: 2013-07-12 Tejas Belagod tejas.bela...@arm.com gcc/ * config/aarch64/aarch64-protos.h (aarch64_simd_immediate_valid_for_move): Remove. * config/aarch64/aarch64.c (simd_immediate_info): New member. (aarch64_simd_valid_immediate): Recognize idioms for shifting ones cases. (aarch64_output_simd_mov_immediate): Print the correct shift specifier. testsuite/ * gcc.target/aarch64/vect-movi.c: New. Looks OK to me. /Marcus
Re: [testsuite, android] Disabling thread_local4.C and thread_local4g.C for Android.
*ping*
Thank you,
Alexander
2013/6/20 Alexander Ivchenko aivch...@gmail.com:
Hi,
for Android:
FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 (test for excess errors)
Excess errors:
/gcc/testsuite/g++.dg/tls/thread_local4.C:31:26: error:
'pthread_testcancel' was not declared in this scope
/gcc/testsuite/g++.dg/tls/thread_local4.C:40:24: error:
'pthread_cancel' was not declared in this scope
the same for thread_local4g.C.
from http://www.kandroid.org/ndk/docs/system/libc/OVERVIEW.html
pthread_cancel() will not be supported in Bionic, because doing this
would involve making the C library significantly bigger for very
little benefit.
...
The following patch switches those tests off for Android.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index b8073d1..d217e4d 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2013-06-19 Alexander Ivchenko alexander.ivche...@intel.com
+
+ * g++.dg/tls/thread_local4.C: Disable test for Android.
+ * g++.dg/tls/thread_local4g.C: Ditto.
+
2013-06-11 Tobias Burnus bur...@net-b.de
PR fortran/57508
diff --git a/gcc/testsuite/g++.dg/tls/thread_local4.C
b/gcc/testsuite/g++.dg/tls/thread_local4.C
index acf1cae..cc1a35a 100644
--- a/gcc/testsuite/g++.dg/tls/thread_local4.C
+++ b/gcc/testsuite/g++.dg/tls/thread_local4.C
@@ -1,6 +1,7 @@
// Test for cleanups with pthread_cancel.
-// { dg-do run }
+// There is no support of pthread_cancel in Android.
+// { dg-do run { target { ! *-*-android* } } }
// { dg-require-effective-target c++11 }
// { dg-require-effective-target tls_runtime }
// { dg-require-effective-target pthread }
diff --git a/gcc/testsuite/g++.dg/tls/thread_local4g.C
b/gcc/testsuite/g++.dg/tls/thread_local4g.C
index f5bc3ff..756c6a2 100644
--- a/gcc/testsuite/g++.dg/tls/thread_local4g.C
+++ b/gcc/testsuite/g++.dg/tls/thread_local4g.C
@@ -1,6 +1,7 @@
// Test for cleanups with pthread_cancel.
-// { dg-do run }
+// There is no support of pthread_cancel in Android.
+// { dg-do run { target { ! *-*-android* } } }
// { dg-require-effective-target c++11 }
// { dg-require-effective-target tls_runtime }
// { dg-require-effective-target pthread }
is it ok for trunk?
--Alexander
Fix PR57886, invalid folding of conversion
Hi,
GCC happily transforms (float)-z into -(float)z, even when z is of
unsigned type (when it's larger than float). That's wrong (the result
should always be positive, because -z is). It seems to me that this bug
exists in all reasonably recent GCC versions. The checking in
convert_to_real is wrong, it compares type precisions of different
classed types. The change with the least impact is to reject only
TYPE_UNSIGNED inner types, but perhaps it would be better to only do the
transformation if the inner type is FLOAT_TYPE_P as well.
Regstrapping on x86-64 in progress. Okay for trunk?
Ciao,
Michael.
PR middle-end/57886
* convert.c (convert_to_real): Reject unsigned inner types.
testsuite/
* c-c++-common/pr57886.c: New test.
Index: convert.c
===
--- convert.c (revision 200240)
+++ convert.c (working copy)
@@ -213,10 +213,11 @@ convert_to_real (tree type, tree expr)
switch (TREE_CODE (expr))
{
/* Convert (float)-x into -(float)x. This is safe for
- round-to-nearest rounding mode. */
+ round-to-nearest rounding mode when the inner type is signed. */
case ABS_EXPR:
case NEGATE_EXPR:
if (!flag_rounding_math
+ !TYPE_UNSIGNED (itype)
TYPE_PRECISION (type) TYPE_PRECISION (TREE_TYPE (expr)))
return build1 (TREE_CODE (expr), type,
fold (convert_to_real (type,
Index: testsuite/c-c++-common/pr57886.c
===
--- testsuite/c-c++-common/pr57886.c(revision 0)
+++ testsuite/c-c++-common/pr57886.c(working copy)
@@ -0,0 +1,12 @@
+/* { dg-do run } */
+
+float global;
+int main()
+{
+ unsigned long z = 1;
+ float x = -z;
+ global = x;
+ if (global 0)
+__builtin_abort ();
+ return 0;
+}
Re: Fix PR57886, invalid folding of conversion
Hi,
On Fri, 12 Jul 2013, Michael Matz wrote:
Hi,
GCC happily transforms (float)-z into -(float)z, even when z is of
unsigned type (when it's larger than float). That's wrong (the result
should always be positive, because -z is). It seems to me that this bug
exists in all reasonably recent GCC versions. The checking in
convert_to_real is wrong, it compares type precisions of different
classed types. The change with the least impact is to reject only
TYPE_UNSIGNED inner types, but perhaps it would be better to only do the
transformation if the inner type is FLOAT_TYPE_P as well.
So, this is a dup of PR55771, I'm now proposing to add a test for
FLOAT_TYPE_P, not TYPE_UNSIGNED. Restarted the regstrap.
Ciao,
Michael.
--
PR middle-end/55771
* convert.c (convert_to_real): Reject non-float inner types.
testsuite/
* c-c++-common/pr55771.c: New test.
Index: convert.c
===
--- convert.c (revision 200240)
+++ convert.c (working copy)
@@ -213,10 +213,11 @@ convert_to_real (tree type, tree expr)
switch (TREE_CODE (expr))
{
/* Convert (float)-x into -(float)x. This is safe for
- round-to-nearest rounding mode. */
+ round-to-nearest rounding mode when the inner type is float. */
case ABS_EXPR:
case NEGATE_EXPR:
if (!flag_rounding_math
+ FLOAT_TYPE_P (itype)
TYPE_PRECISION (type) TYPE_PRECISION (TREE_TYPE (expr)))
return build1 (TREE_CODE (expr), type,
fold (convert_to_real (type,
Index: testsuite/c-c++-common/pr55771.c
===
--- testsuite/c-c++-common/pr55771.c(revision 0)
+++ testsuite/c-c++-common/pr55771.c(working copy)
@@ -0,0 +1,12 @@
+/* { dg-do run } */
+
+float global;
+int main()
+{
+ unsigned long z = 1;
+ float x = -z;
+ global = x;
+ if (global 0)
+__builtin_abort ();
+ return 0;
+}
Re: Fix PR57886, invalid folding of conversion
On Fri, Jul 12, 2013 at 03:37:44PM +0200, Michael Matz wrote: So, this is a dup of PR55771, I'm now proposing to add a test for FLOAT_TYPE_P, not TYPE_UNSIGNED. Restarted the regstrap. Ok if it passes bootstrap/regtest. I'd say we should apply it to 4.8 too, while it might not be a regression (or at least not a recent one), it is a silent wrong-code issue. Sorry for forgetting about this PR. PR middle-end/55771 * convert.c (convert_to_real): Reject non-float inner types. testsuite/ * c-c++-common/pr55771.c: New test. Jakub
Re: Fix PR57886, invalid folding of conversion
On Fri, 12 Jul 2013, Michael Matz wrote: GCC happily transforms (float)-z into -(float)z, even when z is of unsigned type (when it's larger than float). That's wrong (the result should always be positive, because -z is). It seems to me that this bug exists in all reasonably recent GCC versions. The checking in convert_to_real is wrong, it compares type precisions of different classed types. The change with the least impact is to reject only TYPE_UNSIGNED inner types, but perhaps it would be better to only do the transformation if the inner type is FLOAT_TYPE_P as well. If you want to handle integers, shouldn't you test TYPE_OVERFLOW_UNDEFINED (for LONG_MIN)? FLOAT_TYPE_P does seem safer indeed. I'd replace TREE_TYPE (expr) with itype on the next line, it is confusing to refer to it under 2 different names on 2 consecutive lines. -- Marc Glisse
Call GNU ld with -O*
Hello,
this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3
(or more), -Ofast or -Os. Is there a cleaner way to test (optimize 2 ||
optimize_size) in the driver?
I did a bootstrap on x86_64-unknown-linux-gnu and then manually tested by
looking at the -v output.
I tried a -O3 bootstrap, but even setting CFLAGS, BOOT_CFLAGS,
CFLAGS_FOT_TARGET, and the same 3 versions with CXXFLAGS and LDFLAGS, most
stuff still used the default -O2 -g. And most libraries that are part of
gcc explicitly use -Wl,-O1 for linking already.
2013-07-12 Marc Glisse marc.gli...@inria.fr
PR driver/44080
* gcc.c (LINK_OPT_SPEC): New macro.
(LINK_COMMAND_SPEC): Use it.
--
Marc GlisseIndex: gcc.c
===
--- gcc.c (revision 200921)
+++ gcc.c (working copy)
@@ -715,36 +715,45 @@ proper position among the other output f
/* Linker command line options for -fsanitize= late on the command line. */
#ifndef SANITIZER_SPEC
#define SANITIZER_SPEC \
%{!nostdlib:%{!nodefaultlibs:%{fsanitize=address: LIBASAN_SPEC \
%{static:%ecannot specify -static with -fsanitize=address}\
%{fsanitize=thread:%e-fsanitize=address is incompatible with
-fsanitize=thread}}\
%{fsanitize=thread: LIBTSAN_SPEC \
%{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or
-shared}
#endif
+/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or -Ofast. */
+#ifndef LINK_OPT_SPEC
+#if HAVE_GNU_LD
+#define LINK_OPT_SPEC %{O*:%{!O0:%{!O1:%{!O2:%{!Og:%{!O:-O2}}
+#else
+#define LINK_OPT_SPEC
+#endif
+#endif
+
/* -u* was put back because both BSD and SysV seem to support it. */
/* %{static:} simply prevents an error message if the target machine
doesn't handle -static. */
/* We want %{T*} after %{L*} and %D so that it can be used to specify linker
scripts which exist in user specified directories, or in standard
directories. */
/* We pass any -flto flags on to the linker, which is expected
to understand them. In practice, this means it had better be collect2. */
/* %{e*} includes -export-dynamic; see comment in common.opt. */
#ifndef LINK_COMMAND_SPEC
#define LINK_COMMAND_SPEC \
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) \
LINK_PLUGIN_SPEC \
%{flto|flto=*:%fcompare-debug*} \
-%{flto} %{flto=*} %l LINK_PIE_SPEC \
+%{flto} %{flto=*} %l LINK_PIE_SPEC LINK_OPT_SPEC \
%{fuse-ld=*:-fuse-ld=%*}\
%X %{o*} %{e*} %{N} %{n} %{r}\
%{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}}\
%{static:} %{L*} %(mfwrap) %(link_libgcc) SANITIZER_EARLY_SPEC %o\
%{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}\
%{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
%(mflib) STACK_SPLIT_SPEC \
%{fprofile-arcs|fprofile-generate*|coverage:-lgcov} SANITIZER_SPEC \
%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
%{!nostdlib:%{!nostartfiles:%E}} %{T*} }}
Re: Fix PR middle-end/57370
Ping.
On Thu, Jun 27, 2013 at 10:15 AM, Easwaran Raman era...@google.com wrote:
A newly generated statement in build_and_add_sum function of
tree-ssa-reassoc.c has to be assigned the UID of its adjacent
statement. In one instance, it was assigned the wrong uid (of an
earlier phi statement) which messed up the IR and caused the test
program to hang. Bootstraps and no test regressions on x86_64/linux.
Ok for trunk?
Thanks,
Easwaran
2013-06-27 Easwaran Raman era...@google.com
PR middle-end/57370
* tree-ssa-reassoc.c (build_and_add_sum): Do not use the UID of a phi
node for a non-phi gimple statement.
testsuite/ChangeLog:
2013-06-27 Easwaran Raman era...@google.com
PR middle-end/57370
* gfortran.dg/reassoc_12.f90: New testcase.
Index: gcc/testsuite/gfortran.dg/reassoc_12.f90
===
--- gcc/testsuite/gfortran.dg/reassoc_12.f90 (revision 0)
+++ gcc/testsuite/gfortran.dg/reassoc_12.f90 (revision 0)
@@ -0,0 +1,74 @@
+! { dg-do compile }
+! { dg-options -O2 -ffast-math }
+! PR middle-end/57370
+
+ SUBROUTINE xb88_lr_adiabatic_lda_calc(e_ndrho_ndrho_ndrho,
+ grad_deriv,npoints, sx)
+IMPLICIT REAL*8 (t)
+INTEGER, PARAMETER :: dp=8
+REAL(kind=dp), DIMENSION(1:npoints) :: e_ndrho_ndrho_ndrho,
+ e_ndrho_ndrho_rho
+ DO ii=1,npoints
+ IF( grad_deriv = 2 .OR. grad_deriv == -2 ) THEN
+t1425 = t233 * t557
+t1429 = beta * t225
+t1622 = t327 * t1621
+t1626 = t327 * t1625
+t1632 = t327 * t1631
+t1685 = t105 * t1684
+t2057 = t1636 + t8 * (t2635 + t3288)
+ END IF
+ IF( grad_deriv = 3 .OR. grad_deriv == -3 ) THEN
+t5469 = t5440 - t5443 - t5446 - t5449 -
+t5451 - t5454 - t5456 + t5459 -
+t5462 + t5466 - t5468
+t5478 = 0.240e2_dp * t1616 * t973 * t645 * t1425
+t5489 = 0.16e2_dp * t1429 * t1658
+t5531 = 0.160e2_dp * t112 * t1626
+t5533 = 0.160e2_dp * t112 * t1632
+t5537 = 0.160e2_dp * t112 * t1622
+t5541 = t5472 - t5478 - t5523 + t5525 +
+t5531 + t5533 + t5535 + t5537 +
+t5540
+t5565 = t112 * t1685
+t5575 = t5545 - t5548 + t5551 + t5553 -
+t5558 + t5560 - t5562 + t5564 -
+0.80e1_dp * t5565 + t5568 + t5572 +
+t5574
+t5611 = t5579 - t5585 + t5590 - t5595 +
+t5597 - t5602 + t5604 + t5607 +
+t5610
+t5613 = t5469 + t5541 + t5575 + t5611
+t6223 = t6189 -
+0.36e0_dp * t83 * t84 * t5613 +
+t6222
+t6227 = - t8 * (t5305 + t6223)
+e_ndrho_ndrho_rho(ii) = e_ndrho_ndrho_rho(ii) +
+ t6227 * sx
+t6352 = t5440 - t5443 - t5446 - t5449 -
+t5451 - t5454 +
+0.40e1_dp * t102 * t327 * t2057 * t557 -
+t5456 + t5459 - t5462 + t5466 -
+t5468
+t6363 = t5480 - t5489 +
+0.96e2_dp * t1054 * t640 * t3679
+t6367 = t5472 - t5474 - t5478 - t5523 +
+t5525 + t5531 + t5533 + t5535 +
+t5537 - 0.20e1_dp * t102 * t105 * t6363 +
+t5540
+t6370 = t5545 - t5548 + t5551 + t5553 -
+t5558 + t5560 - t5562 + t5564 -
+0.40e1_dp * t5565 +
+t5568 + t5572 + t5574
+t6373 = t5579 - t5585 + t5590 - t5595 +
+t5597 - t5602 + t5604 + t5607 +
+t5610
+t6375 = t6352 + t6367 + t6370 + t6373
+t6380 = - 0.36e0_dp * t83 * t84 * t6375 + t5701
+t6669 = -t4704 - t8 * (t6344 + t6380 + t6665)
+e_ndrho_ndrho_ndrho(ii) = e_ndrho_ndrho_ndrho(ii) +
+ t6669 * sx
+ END IF
+ END DO
+ END SUBROUTINE xb88_lr_adiabatic_lda_calc
+
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c(revision 200429)
+++ gcc/tree-ssa-reassoc.c(working copy)
@@ -1207,7 +1207,7 @@ build_and_add_sum (tree type, tree op1, tree op2,
if (gimple_code (op1def) == GIMPLE_PHI)
{
gsi = gsi_after_labels (gimple_bb (op1def));
- gimple_set_uid (sum, gimple_uid (op1def));
+ gimple_set_uid (sum, gimple_uid (gsi_stmt (gsi)));
gsi_insert_before (gsi, sum, GSI_NEW_STMT);
}
else
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 04:54:21PM +0200, Marc Glisse wrote:
+/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or -Ofast.
*/
+#ifndef LINK_OPT_SPEC
+#if HAVE_GNU_LD
+#define LINK_OPT_SPEC %{O*:%{!O0:%{!O1:%{!O2:%{!Og:%{!O:-O2}}
Wouldn't something like %{O*:%{O|O0|O1|O2|Og:;:-O2}} work?
Jakub
Re: FW: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
2013-07-12 Bin Cheng bin.ch...@arm.com * ifcvt.c (ifcvt_after_combine): New static variable. (cheap_bb_rtx_cost_p): Set scale to REG_BR_PROB_BASE when optimizing for size. (if_convert): New parameter after_combine. Set ifcvt_after_combine. (rest_of_handle_if_conversion, rest_of_handle_if_after_combine, rest_of_handle_if_after_reload): Pass new argument for if_convert. OK for mainline modulo the missing 'e' at the end of interfere. -- Eric Botcazou
Re: Fix PR57886, invalid folding of conversion
Hi, On Fri, 12 Jul 2013, Marc Glisse wrote: If you want to handle integers, shouldn't you test TYPE_OVERFLOW_UNDEFINED (for LONG_MIN)? Right, ... FLOAT_TYPE_P does seem safer indeed. ... hence this is it now. I'd replace TREE_TYPE (expr) with itype on the next line, it is confusing to refer to it under 2 different names on 2 consecutive lines. True, I made that change. r200926. Ciao, Michael.
Re: Call GNU ld with -O*
On Fri, 12 Jul 2013, Jakub Jelinek wrote:
On Fri, Jul 12, 2013 at 04:54:21PM +0200, Marc Glisse wrote:
+/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or -Ofast. */
+#ifndef LINK_OPT_SPEC
+#if HAVE_GNU_LD
+#define LINK_OPT_SPEC %{O*:%{!O0:%{!O1:%{!O2:%{!Og:%{!O:-O2}}
Wouldn't something like %{O*:%{O|O0|O1|O2|Og:;:-O2}} work?
It does (I only did a non-bootstrap c,c++ build and some manual tests with
-v). Thanks, I didn't know this syntax.
Is the new version ok? Any tests I should do that would be more useful
than running the testsuite? (I tried with several -O options in various
orders and made sure that a -Wl,-On ended up later in the command line)
--
Marc GlisseIndex: gcc.c
===
--- gcc.c (revision 200921)
+++ gcc.c (working copy)
@@ -715,36 +715,45 @@ proper position among the other output f
/* Linker command line options for -fsanitize= late on the command line. */
#ifndef SANITIZER_SPEC
#define SANITIZER_SPEC \
%{!nostdlib:%{!nodefaultlibs:%{fsanitize=address: LIBASAN_SPEC \
%{static:%ecannot specify -static with -fsanitize=address}\
%{fsanitize=thread:%e-fsanitize=address is incompatible with
-fsanitize=thread}}\
%{fsanitize=thread: LIBTSAN_SPEC \
%{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or
-shared}
#endif
+/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or -Ofast. */
+#ifndef LINK_OPT_SPEC
+#if HAVE_GNU_LD
+#define LINK_OPT_SPEC %{O*:%{O|O0|O1|O2|Og:;:-O2}}
+#else
+#define LINK_OPT_SPEC
+#endif
+#endif
+
/* -u* was put back because both BSD and SysV seem to support it. */
/* %{static:} simply prevents an error message if the target machine
doesn't handle -static. */
/* We want %{T*} after %{L*} and %D so that it can be used to specify linker
scripts which exist in user specified directories, or in standard
directories. */
/* We pass any -flto flags on to the linker, which is expected
to understand them. In practice, this means it had better be collect2. */
/* %{e*} includes -export-dynamic; see comment in common.opt. */
#ifndef LINK_COMMAND_SPEC
#define LINK_COMMAND_SPEC \
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) \
LINK_PLUGIN_SPEC \
%{flto|flto=*:%fcompare-debug*} \
-%{flto} %{flto=*} %l LINK_PIE_SPEC \
+%{flto} %{flto=*} %l LINK_PIE_SPEC LINK_OPT_SPEC \
%{fuse-ld=*:-fuse-ld=%*}\
%X %{o*} %{e*} %{N} %{n} %{r}\
%{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}}\
%{static:} %{L*} %(mfwrap) %(link_libgcc) SANITIZER_EARLY_SPEC %o\
%{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}\
%{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
%(mflib) STACK_SPLIT_SPEC \
%{fprofile-arcs|fprofile-generate*|coverage:-lgcov} SANITIZER_SPEC \
%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
%{!nostdlib:%{!nostartfiles:%E}} %{T*} }}
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 06:12:26PM +0200, Marc Glisse wrote:
On Fri, 12 Jul 2013, Jakub Jelinek wrote:
On Fri, Jul 12, 2013 at 04:54:21PM +0200, Marc Glisse wrote:
+/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or
-Ofast. */
+#ifndef LINK_OPT_SPEC
+#if HAVE_GNU_LD
+#define LINK_OPT_SPEC %{O*:%{!O0:%{!O1:%{!O2:%{!Og:%{!O:-O2}}
Wouldn't something like %{O*:%{O|O0|O1|O2|Og:;:-O2}} work?
It does (I only did a non-bootstrap c,c++ build and some manual
tests with -v). Thanks, I didn't know this syntax.
gcc.c has a huge comment that describes the syntax.
Is the new version ok? Any tests I should do that would be more
useful than running the testsuite? (I tried with several -O options
in various orders and made sure that a -Wl,-On ended up later in the
command line)
I'd say it is important to try say -O17 -O0, -O -O5 etc. and see whether
it works as desired. If that works, the patch is ok, with proper ChangeLog
entry.
Jakub
Re: Call GNU ld with -O*
Hi! On Fri, 12 Jul 2013 16:54:21 +0200 (CEST), Marc Glisse marc.gli...@inria.fr wrote: this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 (or more), -Ofast or -Os. I wondered about this before: why are no -O flags are passed to the (GNU) linker. What's the rationale for the mapping you propose of GCC and linker optimization flags? Why not a one-to-one mapping? Grüße, Thomas pgp2XQnZnIt4F.pgp Description: PGP signature
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 09:49:28AM -0700, Thomas Schwinge wrote: Hi! On Fri, 12 Jul 2013 16:54:21 +0200 (CEST), Marc Glisse marc.gli...@inria.fr wrote: this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 (or more), -Ofast or -Os. I wondered about this before: why are no -O flags are passed to the (GNU) linker. What's the rationale for the mapping you propose of GCC and linker optimization flags? Why not a one-to-one mapping? Because there is no 1:1 mapping. I bet ld doesn't grok -Os or -Ofast or -Og, and what -O* does in the linker doesn't have direct correspondence to what -O* does in the compiler. Last time I've looked, -O* in the linker just enabled some link time expensive computation of the hash table, so enabling -O in the linker for -O1 in the compiler is definitely not a good idea, similarly for -Og, those definitely want speed rather than better hash table. Jakub
Re: Call GNU ld with -O*
On Fri, 12 Jul 2013, Jakub Jelinek wrote: gcc.c has a huge comment that describes the syntax. I know, my first reflex after reading your email was to re-read that comment to understand what you had written ;-) Is the new version ok? Any tests I should do that would be more useful than running the testsuite? (I tried with several -O options in various orders and made sure that a -Wl,-On ended up later in the command line) I'd say it is important to try say -O17 -O0, -O -O5 etc. and see whether it works as desired. Yes, that's what I had checked. If that works, the patch is ok, with proper ChangeLog entry. Oups, it was in the first email and I forgot to copy it in the second version. Thanks, -- Marc Glisse
Re: Call GNU ld with -O*
Hi! On Fri, 12 Jul 2013 18:53:58 +0200, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jul 12, 2013 at 09:49:28AM -0700, Thomas Schwinge wrote: On Fri, 12 Jul 2013 16:54:21 +0200 (CEST), Marc Glisse marc.gli...@inria.fr wrote: this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 (or more), -Ofast or -Os. I wondered about this before: why are no -O flags are passed to the (GNU) linker. What's the rationale for the mapping you propose of GCC and linker optimization flags? Why not a one-to-one mapping? Because there is no 1:1 mapping. I bet ld doesn't grok -Os or -Ofast or -Og, and what -O* does in the linker doesn't have direct correspondence to what -O* does in the compiler. Last time I've looked, -O* in the linker just enabled some link time expensive computation of the hash table, so enabling -O in the linker for -O1 in the compiler is definitely not a good idea, similarly for -Og, those definitely want speed rather than better hash table. OK, there currently is no one-to-one mapping -- but why not establish one? Then the linker would enable the expensive optimizations only for -O2 and higher -- which would break backwards compatibility, bummer... (Though, I could see potential uses in the linker for -Ofast and -Og, too.) Grüße, Thomas pgp4qvJatWdvY.pgp Description: PGP signature
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 7:54 AM, Marc Glisse marc.gli...@inria.fr wrote: this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 (or more), -Ofast or -Os. I don't understand why that is a good idea. The linker -O option is only distantly related to the compiler -O option. It was probably a mistake to have a linker -O option at all. Ian
Re: Call GNU ld with -O*
On Fri, 12 Jul 2013, Ian Lance Taylor wrote: On Fri, Jul 12, 2013 at 7:54 AM, Marc Glisse marc.gli...@inria.fr wrote: this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 (or more), -Ofast or -Os. I don't understand why that is a good idea. Well, you thought it was 3 years ago ;-) http://gcc.gnu.org/ml/gcc/2010-05/msg00193.html The linker -O option is only distantly related to the compiler -O option. It was probably a mistake to have a linker -O option at all. Doesn't the linker produce something that is faster to link and/or smaller, with this flag? -- Marc Glisse
[PATCH, AArch64] Add vabs_s64 intrinsic
This patch implements the following intrinsic:
int64x1_t vabs_s64 (int64x1 a)
It uses __builtin_llabs(), which will lead to abs Dn, Dm being generated
for
this now that my other patch has been committed.
Test case added to scalar_intrinsics.c.
OK for trunk?
Cheers,
Ian
2013-07-12 Ian Bolton ian.bol...@arm.com
gcc/
* config/aarch64/arm_neon.h (vabs_s64): New function.
testsuite/
* gcc.target/aarch64/scalar_intrinsics.c (test_vabs_s64): Added new
test.Index: gcc/config/aarch64/arm_neon.h
===
--- gcc/config/aarch64/arm_neon.h (revision 200594)
+++ gcc/config/aarch64/arm_neon.h (working copy)
@@ -17886,6 +17886,12 @@ vabsq_f64 (float64x2_t __a)
return __builtin_aarch64_absv2df (__a);
}
+__extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
+vabs_s64 (int64x1_t a)
+{
+ return __builtin_llabs (a);
+}
+
/* vadd */
__extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
Index: gcc/testsuite/gcc.target/aarch64/scalar_intrinsics.c
===
--- gcc/testsuite/gcc.target/aarch64/scalar_intrinsics.c(revision
200594)
+++ gcc/testsuite/gcc.target/aarch64/scalar_intrinsics.c(working copy)
@@ -32,6 +32,18 @@ test_vaddd_s64_2 (int64x1_t a, int64x1_t
vqaddd_s64 (a, d));
}
+/* { dg-final { scan-assembler-times \\tabs\\td\[0-9\]+, d\[0-9\]+ 1 } } */
+
+int64x1_t
+test_vabs_s64 (int64x1_t a)
+{
+ uint64x1_t res;
+ force_simd (a);
+ res = vabs_s64 (a);
+ force_simd (res);
+ return res;
+}
+
/* { dg-final { scan-assembler-times \\tcmeq\\td\[0-9\]+, d\[0-9\]+,
d\[0-9\]+ 1 } } */
uint64x1_t
Re: RFC: Add of type-demotion pass
On Tue, 9 Jul 2013, Kai Tietz wrote: I would be glad if you could give me a couple hints. I try. Thanks :-) I wonder why you implemented this as a separate pass instead of adding it to tree-ssa-forwprop. demote_cast is (or should be) a special case of combine_conversions, so it would be nice to avoid the code duplication (there is also a version in fold-const.c). demote_into could be called from roughly the same place as simplify_conversion_from_bitmask. And you could reuse get_prop_source_stmt, can_propagate_from, remove_prop_source_from_use, etc. Initial patch (from last year) actual implemented that in forwprop. Ah, reading the conversation from last year helped me understand a bit better. I was then kindly asked to put this into a separate pass. There are some good reason why forward-propagation isn't the right place for it. Eg, forwprop does type-raising by default. Even in cases where that increases the size of the operation? I see a hoist_conversion_for_bitop_p that seems to try and prevent it. So by implementing type-demotion there too, would lead to raise-condition. So there would be required additionally that within forwprop a straight line-depth conversion is done for statement-lists. All this doesn't fit pretty well into current concept of forward-propagation ... The cast demotion is of course something of interest for folding and might be fitting into forward-propagation-pass too. The main cause why it is implemented within demotion pass is, that this pass introduces such cast-demotion-folding opportunities due its unsigned-type expansion. So we want to fold that within pass and not waiting until a later pass optimizes such redundant sequences away. I hope we can at least find a way to share code between the passes. If I understand, the main reason is because you want to go through the statements in reverse order, since this is the way the casts are being propagated (would forwprop also work, just more slowly, or would it miss opportunities across basic blocks?). It would miss some opportunities, Could you explain in what case? I guess my trouble understanding this is the same as in the next question, and I am missing a fundamental point... and causes penalty on speed due concept of forwprop. I have some trouble understanding why something as complicated as build_and_add_sum (which isn't restricted to additions by the way) is needed. Could you add a comment to the code explaining why you need to insert the statements precisely there and not for instance just before their use? Is that to try and help CSE? Yes, this function is a bit more complex as actual required for now in general. Nevertheless required. And I expect that demotion-pass will improve and so even the right now unlikely cases might be required more frequent. I had in front lighter version of statement addition, but it failed in some cases.In some (rare) cases we would otherwise choose wrong basic-block to add the new cast-statements. Well, there is another place (reassoc) where you can find nearly the same function, and its needs are exactly the same as within demote-pass. I had a look at the reassoc pass and failed to understand the logic there as well :-( I don't really understand how the basic block can be wrong. If we only handle the single use case with no side effects and no weird jump in between, nothing but the user should notice if you move the definition next to the use. So is this a way to handle weirder jumps than you could otherwise? I have added an additional early pass typedemote1 to this patch for simple cases types can be easily sunken into statement without special unsigned-cast for overflow-case. Jakub asked for it. Tests have shown that this pass does optimizations in pretty few cases. As example in testsuite see for example pr46867.c testcase. The second pass (I put it behind first vrp pass to avoid testcase-conflicts) uses 'unsigned'-type casts to avoid undefined overflow behavior. This pass has much more hits in standard code, My little understanding from the old conversation and Jeff's post in this thread is that there are 2 ways to think about this optimization: 1) the canonical representation is with the smallest type possible. Using forwprop could make sense there (even if it may need help from another pass for some complicated cases, and it isn't the most efficient way). There is possibly a late pass to change all the types too small for the hardware into int. 2) we compute for each operation what minimal size it needs. Then, we may do some optimizations (truncate constants), possibly convert the operations to some smaller type (many at once), but not necessarily. This requires a separate pass but doesn't look like what you are doing. On Tue, 9 Jul 2013, Jeff Law wrote: On 07/08/2013 02:52 PM, Marc Glisse wrote: I wonder why you implemented this as a separate pass instead of adding it to tree-ssa-forwprop.
Re: [c++-concepts] requires expressions
On 07/11/2013 02:59 PM, Andrew Sutton wrote: pp_cxx_requirement_parameter_list (cxx_pretty_printer *pp, tree t) This should be merged with pp_cxx_parameter_declaration_clause. +reqparms_to_string (tree p) And this should have a more generic name. + // requries clause. requires + if (check_requirements (t, args)) +return; + + ++processing_template_decl; + tree subst = instantiate_requirements (t, args); + --processing_template_decl; Surely you need to instantiate before checking, here and elsewhere. + inform (loc, %qE is not valid syntax, TREE_OPERAND (t, 0)); I don't think I would mention syntax here, since a syntax error would have been diagnosed at parse time rather than constraint checking time. +// In an unevaluated context, the substitution of parm decls are not +// properly chained during substitution. Do that here. +static tree +fix_local_parms (tree sparms) A lot of the new code in pt.c doesn't seem like it needs to be there; let's put as much in constraint.cc as we can. Let's move some of the bits out of semantics.c as well. Incidentally, I notice a funny thing about the headers of the new files: /* Process declarations and variables for C++ compiler. ... // Components for processing constraints and evaluating constraints. The second line should move to the top of the file, replacing the first line. Jason
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 11:21 AM, Marc Glisse marc.gli...@inria.fr wrote: On Fri, 12 Jul 2013, Ian Lance Taylor wrote: On Fri, Jul 12, 2013 at 7:54 AM, Marc Glisse marc.gli...@inria.fr wrote: this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 (or more), -Ofast or -Os. I don't understand why that is a good idea. Well, you thought it was 3 years ago ;-) http://gcc.gnu.org/ml/gcc/2010-05/msg00193.html Ah well, coming to it fresh I'm not sure it is. The linker -O option is only distantly related to the compiler -O option. It was probably a mistake to have a linker -O option at all. Doesn't the linker produce something that is faster to link and/or smaller, with this flag? For gold I think it has two effects. If you use compressed debug sections, it will compress them with zlib level 9 rather than 1. If you use -O2 or greater it will optimize string tables (e.g., the table holding the names of symbols) such that if the table stores two strings S1 and S2, and S2 is a suffix of S1, it will store only S1, and change pointers to S2 to point to the suffix of S1. So you are correct that the result will be smaller, but not faster to link. People routinely compile with -O or -O2. It's not clear to me that they should routinely link with -O or -O2. These decisions are not the default in the linker because they aren't good tradeoffs for most people. Ian
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 12:25:16PM -0700, Ian Lance Taylor wrote: For gold I think it has two effects. If you use compressed debug sections, it will compress them with zlib level 9 rather than 1. If Marc's patch enabled it only for -O3/-Ofast (which are already compile time expensive options, thus it perhaps it doesn't hurt that much to spend extra time in the linker too) and -Os (then you are really looking for small, and if ld -O2 provides that, then perhaps it is desirable too). you use -O2 or greater it will optimize string tables (e.g., the table holding the names of symbols) such that if the table stores two strings S1 and S2, and S2 is a suffix of S1, it will store only S1, and change pointers to S2 to point to the suffix of S1. So you are correct that the result will be smaller, but not faster to link. Oh, gold doesn't do this by default? ld.bfd does (unless it changed since I've implemented many years ago). Jakub
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 12:30 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jul 12, 2013 at 12:25:16PM -0700, Ian Lance Taylor wrote: For gold I think it has two effects. If you use compressed debug sections, it will compress them with zlib level 9 rather than 1. If Marc's patch enabled it only for -O3/-Ofast (which are already compile time expensive options, thus it perhaps it doesn't hurt that much to spend extra time in the linker too) and -Os (then you are really looking for small, and if ld -O2 provides that, then perhaps it is desirable too). OK, let me put it this way: perhaps there is some set of linker options that we should enable by default when linking with -O. But I don't see any particular reason that they are specifically the linker options that are selected by -O. you use -O2 or greater it will optimize string tables (e.g., the table holding the names of symbols) such that if the table stores two strings S1 and S2, and S2 is a suffix of S1, it will store only S1, and change pointers to S2 to point to the suffix of S1. So you are correct that the result will be smaller, but not faster to link. Oh, gold doesn't do this by default? ld.bfd does (unless it changed since I've implemented many years ago). Correct: gold does not do it by default. For us link time matters most for large C++ programs. For those programs, the optimization only fired a tiny percentage of the time, but it took something like 4% of total link time. It wasn't worth it by default. Ian
Re: [C++ Patch] for c++/54537
Hi, Fabien Chêne fabien.ch...@gmail.com ha scritto: Then, It seems to me that such a change should ideally go in a separate patch. Yes. Frankly I thought it was already clear that for the purpose of fixing this c++ issue we weren't inventing anything new in the library. Just in case isn't fully clear to everybody, we are talking about a very special case in the *tr1* code, which by now is barely maintained. If we want to be super safe and we want the c++ improvement for 4.9, we have to commit the whole package now. Paolo
Re: Call GNU ld with -O*
On Fri, 12 Jul 2013, Ian Lance Taylor wrote: On Fri, Jul 12, 2013 at 12:30 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jul 12, 2013 at 12:25:16PM -0700, Ian Lance Taylor wrote: For gold I think it has two effects. If you use compressed debug sections, it will compress them with zlib level 9 rather than 1. If Marc's patch enabled it only for -O3/-Ofast (which are already compile time expensive options, thus it perhaps it doesn't hurt that much to spend extra time in the linker too) and -Os (then you are really looking for small, and if ld -O2 provides that, then perhaps it is desirable too). OK, let me put it this way: perhaps there is some set of linker options that we should enable by default when linking with -O. But I don't see any particular reason that they are specifically the linker options that are selected by -O. I completely agree with this. We could pass --compress-level=9 --merge-string-suffix --optimize-hashtables and a number of others (names invented). -O2 just happens to include things (both for bfd and gold, but the original motivation was bfd) that to me make sense to enable when linking with gcc -O3 (highest level, not the day-to-day fast compilation). If you think they don't, then let's reject this patch. Do you have any suggestions for linker flags that we could pass for high optimization levels where we don't mind if the linker takes a bit longer? (I guess that if an option was suitable for gcc -O2, you might have made it the default in the linker, hence my focus on -O3) -- Marc Glisse
[patch, fortran] PR 52669, warn about unused PRIVATE module variables
Hello world,
here is a rather self-evident patch for PR 52669.
Regression-tested. OK for trunk?
Thomas
2013-07-12 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/52669
* trans-decl.c (gfc_create_module_variable): Optionally
warn about private module variable which is not used.
2013-07-12 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/52669
* fortran.dg/module_variable_1.f90: New test.
Index: trans-decl.c
===
--- trans-decl.c (Revision 200743)
+++ trans-decl.c (Arbeitskopie)
@@ -4212,6 +4212,11 @@ gfc_create_module_variable (gfc_symbol * sym)
internal_error (backend decl for module variable %s already exists,
sym-name);
+ if (warn_unused_variable !sym-attr.referenced
+ sym-attr.access == ACCESS_PRIVATE)
+gfc_warning (Unused PRIVATE module variable '%s' declared at %L,
+ sym-name, sym-declared_at);
+
/* We always want module variables to be created. */
sym-attr.referenced = 1;
/* Create the decl. */
! { dg-do compile }
! { dg-options -Wall }
module foo
integer, private :: i ! { dg-warning Unused PRIVATE }
integer, private :: j = 0
contains
subroutine bar
j = j + 1
end subroutine bar
end module foo
[committed] mips_expand_call: Remove empty statement
Hi,
Committed as obvious.
2013-07-12 Maciej W. Rozycki ma...@codesourcery.com
gcc/
* config/mips/mips.c (mips_expand_call): Remove empty statement.
Maciej
gcc-mips-expand-call-syntax.patch
Index: gcc-fsf-trunk-quilt/gcc/config/mips/mips.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/config/mips/mips.c 2013-07-12
21:10:19.890906148 +0100
+++ gcc-fsf-trunk-quilt/gcc/config/mips/mips.c 2013-07-12 21:13:00.400592186
+0100
@@ -6902,7 +6902,7 @@ mips_expand_call (enum mips_call_type ty
gcc_assert (!lazy_p type == MIPS_CALL_NORMAL);
return insn;
}
-;
+
orig_addr = addr;
if (!call_insn_operand (addr, VOIDmode))
{
[sso] Merge from trunk @200927
Bootstrapped/regtested on x86_64-suse-linux, applied on the branch. -- Eric Botcazou
Fix GCC bug causing bootstrap failure with vectorizer turned on
GCC bootstrap failed with loop vectorizer turned on by default at O2.
The symptom is that the comparison between stage23 compilers fails.
The root cause is a bug in the file tree-vect-data-refs.c, where a
qsort() function call is used to sort a group of data references using
a comparison function called dr_group_sort_cmp(). In this function,
the iterative hash values of tree nodes are used for comparisons. For
a declaration tree node, its UID participates in the calculation of
the hash value. However, a specific declaration may have different
UIDs whether the debug information is switched on/off (-gtoggle). In
consequence, the results of comparisons may vary in stage 23 during
bootstrapping.
The following patch fixed the bug. Compiler bootstraps and there is no
regressions in regression test. Compiler also bootstraps fine when
turning on vectorizer by default. Since this patch may produce
difference result (but still correct) than before due to the
modification to the comparison function, four test cases are adjusted
accordingly. OK for trunk?
Cong
Index: gcc/testsuite/gcc.target/i386/l_fma_double_1.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_double_1.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_double_1.c (working copy)
@@ -10,9 +10,9 @@
#include l_fma_1.h
/* { dg-final { scan-assembler-times vfmadd132pd 4 } } */
-/* { dg-final { scan-assembler-times vfmadd213pd 4 } } */
+/* { dg-final { scan-assembler-times vfmadd231pd 4 } } */
/* { dg-final { scan-assembler-times vfmsub132pd 4 } } */
-/* { dg-final { scan-assembler-times vfmsub213pd 4 } } */
+/* { dg-final { scan-assembler-times vfmsub231pd 4 } } */
/* { dg-final { scan-assembler-times vfnmadd132pd 4 } } */
/* { dg-final { scan-assembler-times vfnmadd231pd 4 } } */
/* { dg-final { scan-assembler-times vfnmsub132pd 4 } } */
Index: gcc/testsuite/gcc.target/i386/l_fma_float_1.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_float_1.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_float_1.c (working copy)
@@ -9,9 +9,9 @@
#include l_fma_1.h
/* { dg-final { scan-assembler-times vfmadd132ps 4 } } */
-/* { dg-final { scan-assembler-times vfmadd213ps 4 } } */
+/* { dg-final { scan-assembler-times vfmadd231ps 4 } } */
/* { dg-final { scan-assembler-times vfmsub132ps 4 } } */
-/* { dg-final { scan-assembler-times vfmsub213ps 4 } } */
+/* { dg-final { scan-assembler-times vfmsub231ps 4 } } */
/* { dg-final { scan-assembler-times vfnmadd132ps 4 } } */
/* { dg-final { scan-assembler-times vfnmadd231ps 4 } } */
/* { dg-final { scan-assembler-times vfnmsub132ps 4 } } */
Index: gcc/testsuite/gcc.target/i386/l_fma_double_3.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_double_3.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_double_3.c (working copy)
@@ -10,9 +10,9 @@
#include l_fma_3.h
/* { dg-final { scan-assembler-times vfmadd132pd 4 } } */
-/* { dg-final { scan-assembler-times vfmadd213pd 4 } } */
+/* { dg-final { scan-assembler-times vfmadd231pd 4 } } */
/* { dg-final { scan-assembler-times vfmsub132pd 4 } } */
-/* { dg-final { scan-assembler-times vfmsub213pd 4 } } */
+/* { dg-final { scan-assembler-times vfmsub231pd 4 } } */
/* { dg-final { scan-assembler-times vfnmadd132pd 4 } } */
/* { dg-final { scan-assembler-times vfnmadd231pd 4 } } */
/* { dg-final { scan-assembler-times vfnmsub132pd 4 } } */
Index: gcc/testsuite/gcc.target/i386/l_fma_float_3.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_float_3.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_float_3.c (working copy)
@@ -9,9 +9,9 @@
#include l_fma_3.h
/* { dg-final { scan-assembler-times vfmadd132ps 4 } } */
-/* { dg-final { scan-assembler-times vfmadd213ps 4 } } */
+/* { dg-final { scan-assembler-times vfmadd231ps 4 } } */
/* { dg-final { scan-assembler-times vfmsub132ps 4 } } */
-/* { dg-final { scan-assembler-times vfmsub213ps 4 } } */
+/* { dg-final { scan-assembler-times vfmsub231ps 4 } } */
/* { dg-final { scan-assembler-times vfnmadd132ps 4 } } */
/* { dg-final { scan-assembler-times vfnmadd231ps 4 } } */
/* { dg-final { scan-assembler-times vfnmsub132ps 4 } } */
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c (revision 200893)
+++ gcc/tree-vect-data-refs.c (working copy)
@@ -2311,6 +2311,80 @@
return vect_analyze_group_access (dr);
}
+
+
+/* Compare two tree nodes. This function is used to compare two
+ data-references as below. */
+
+static int
+compare_tree (tree t1, tree t2)
+{
+ int i, cmp;
+ enum tree_code code;
+ char tclass;
+
+ if (t1 == t2)
+return 0;
+ if (t1 == NULL)
+return -1;
+ if (t2 == NULL)
+return 1;
+
+
+
[PATCH] Fix for PR57698
Patch attached to fix this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
Here is what is going on. In rev. 200179, this change to tree-inline.c
Index: tree-inline.c
===
--- tree-inline.c (revision 200178)
+++ tree-inline.c (revision 200179)
@@ -3905,8 +3905,6 @@
for inlining, but we can't do that because frontends overwrite
the body. */
!cg_edge-callee-local.redefined_extern_inline
- /* Avoid warnings during early inline pass. */
- cgraph_global_info_ready
/* PR 20090218-1_0.c. Body can be provided by another module. */
(reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
made inline failure errors during early inlining reportable. Now,
this function is called when the early_inliner calls
optimize_inline_calls. The reason for the failure,
CIF_INDIRECT_UNKNOWN_CALL, should not be reported because it is not a
valid reason,(see can_inline_edge_p in ipa-inline.c for the list of
reasons we intend to report) but it gets reported because of the above
change.
The reported bug happens only when optimization is turned on as the
early inliner pass invokes incremental inlining which calls
optimize_inline_calls and triggers the above failure.
So, the fix is then as simple as:
Index: tree-inline.c
===
--- tree-inline.c (revision 200912)
+++ tree-inline.c (working copy)
@@ -3905,6 +3905,10 @@ expand_call_inline (basic_block bb, gimple stmt, c
for inlining, but we can't do that because frontends overwrite
the body. */
!cg_edge-callee-local.redefined_extern_inline
+ /* During early inline pass, report only when optimization is
+not turned on. */
+ (cgraph_global_info_ready
+ || !optimize)
/* PR 20090218-1_0.c. Body can be provided by another module. */
(reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
Seems like the right fix to me. Ok? The whole patch with test case
included is attached.
Thanks
Sri
* tree-inline.c (expand_call_inline): Emit errors during
early_inlining only if optimization is not turned on.
* gcc.c-torture/compile/pr57698.c: New test.
* gcc.c-torture/compile/pr43791.c: Remove prune output
directive.
* gcc.c-torture/compile/pr44043.c: Ditto.
Index: testsuite/gcc.c-torture/compile/pr57698.c
===
--- testsuite/gcc.c-torture/compile/pr57698.c (revision 0)
+++ testsuite/gcc.c-torture/compile/pr57698.c (revision 0)
@@ -0,0 +1,19 @@
+typedef int (*IsAcceptableThis) (const int );
+inline int
+fn1 (IsAcceptableThis p1)
+{
+p1 (0);
+return 0;
+}
+
+__attribute__ ((always_inline))
+inline int fn2 (const int a)
+{
+return 0;
+}
+
+void
+fn3 ()
+{
+fn1 (fn2);
+}
Index: testsuite/gcc.c-torture/compile/pr44043.c
===
--- testsuite/gcc.c-torture/compile/pr44043.c (revision 200912)
+++ testsuite/gcc.c-torture/compile/pr44043.c (working copy)
@@ -85,5 +85,3 @@ int raw_sendmsg(struct sock *sk, struct msghdr *ms
{
raw_send_hdrinc(sk, msg-msg_iov, len, (void *)0, msg-msg_flags);
}
-
-/* { dg-prune-output (inlining failed in call to always_inline.*indirect
function call with a yet undetermined callee|called from here) } */
Index: testsuite/gcc.c-torture/compile/pr43791.c
===
--- testsuite/gcc.c-torture/compile/pr43791.c (revision 200912)
+++ testsuite/gcc.c-torture/compile/pr43791.c (working copy)
@@ -18,5 +18,3 @@ void fasttrylock(void (*slowfn)()) {
void trylock(void) {
fasttrylock(slowtrylock);
}
-
-/* { dg-prune-output (inlining failed in call to always_inline.*indirect
function call with a yet undetermined callee|called from here) } */
Index: tree-inline.c
===
--- tree-inline.c (revision 200912)
+++ tree-inline.c (working copy)
@@ -3905,6 +3905,10 @@ expand_call_inline (basic_block bb, gimple stmt, c
for inlining, but we can't do that because frontends overwrite
the body. */
!cg_edge-callee-local.redefined_extern_inline
+ /* During early inline pass, report only when optimization is
+not turned on. */
+ (cgraph_global_info_ready
+ || !optimize)
/* PR 20090218-1_0.c. Body can be provided by another module. */
(reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
Re: RFA: Fix rtl-optimization/57425 (SPEC perl problem on MIPS)
Joern,
Has anyone reported any problems to you about this patch? I am running into
a problem running the perl benchmark from SPEC2006 and I have tracked it down
to this June 16 patch (SVN 200133,
GIT ddba76b84c757d93b4247713d558724776149b62). I am building a GCC cross
compiler running on x86 linux and targeting mips-mti-linux-gnu.
I haven't been able to cut down perl into a smaller test case yet but starting
with this version of GCC, if I build perl with -O2 or -O3 and then run it with
this perl input:
% cat x.pl
#!./perl
{
eval {
use Math::BigInt;
$y = pack('w*', Math::BigInt::-new(50));
};
}
1;
I get:
% ./perlbench_base.sellcey_reload x.pl
*** Error in `./perlbench_base.sellcey_reload': malloc(): memory corruption
(fast): 0x00642390 ***
and perl seems to go into an infinite loop. Before your change perl
ran and exited cleanly. I will try to create a smaller example but I wanted
to see if you (or someone else on gcc-patches) was seeing anything like
this on any other targets.
Steve Ellcey
sell...@mips.com
Re: [testsuite, android] Disabling thread_local4.C and thread_local4g.C for Android.
On Jun 20, 2013, at 4:30 AM, Alexander Ivchenko aivch...@gmail.com wrote: for Android: +2013-06-19 Alexander Ivchenko alexander.ivche...@intel.com + + * g++.dg/tls/thread_local4.C: Disable test for Android. + * g++.dg/tls/thread_local4g.C: Ditto. is it ok for trunk? Ok.
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove david.holsgr...@xilinx.com * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK Sorry it has taken so long to review this patch. The gcc microblaze-xilinx-elf build with this patch fails here: +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, + tree function) ... + emit_insn (gen_jump (funexp)); (actually, in output_operand() downstream from this statement) while compiling c++98/strstream.cc, with an error that the %l operand was not a label. This is the first occasion when this routine is called. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [patch, fortran] PR 52669, warn about unused PRIVATE module variables
Am 12.07.2013 23:07, Thomas Koenig wrote: here is a rather self-evident patch for PR 52669. Regression-tested. OK for trunk? I think you should also handle: module m private integer :: k end module m and module m2 integer :: ll end module m2 when compiled with -fmodule-private. I think that's not yet handled by your code. It is probably sufficient to move the following code (in the same function) up before your check: if (sym-attr.access == ACCESS_UNKNOWN (sym-ns-default_access == ACCESS_PRIVATE || (sym-ns-default_access == ACCESS_UNKNOWN gfc_option.flag_module_private))) sym-attr.access = ACCESS_PRIVATE; Otherwise, it looks okay to me. Tobias PS: We will have to change the check when submodules are supported. But it is detectable in a module whether it is used as submodule; one can even handle as additional special case that there is a submodule, but it is in the same file. 2013-07-12 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/52669 * trans-decl.c (gfc_create_module_variable): Optionally warn about private module variable which is not used. 2013-07-12 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/52669 * fortran.dg/module_variable_1.f90: New test.
