Invalid code emitted

2014-01-21 Thread Umesh Kalappa
Hi All , The following C code snippet unsigned char c ; int d ; int test () { d = c; return d; } below is the RTL without optimisation enabled (insn 6 5 0 (set (reg:QI 18 [ c.0 ]) (mem/c:QI (symbol_ref:HI ("c") ) [0 c+0 S1 A8])) cnv.c:5 -1 (nil)) (insn 7 6 8 (set (reg:QI 19

Re: [RFC, LRA] Repeated looping over subreg reloads.

2014-01-21 Thread Tejas Belagod
Vladimir Makarov wrote: On 12/5/2013, 9:35 AM, Tejas Belagod wrote: Vladimir Makarov wrote: On 12/4/2013, 6:15 AM, Tejas Belagod wrote: Hi, I'm trying to relax CANNOT_CHANGE_MODE_CLASS for aarch64 to allow all mode changes on FP_REGS as aarch64 does not have register-packing, but I'm running

Re: Invalid code emitted

2014-01-21 Thread Ian Lance Taylor
On Tue, Jan 21, 2014 at 12:52 AM, Umesh Kalappa wrote: > > The following C code snippet > > unsigned char c ; > int d ; > > int test () > { > d = c; > return d; > } > > below is the RTL without optimisation enabled > > (insn 6 5 0 (set (reg:QI 18 [ c.0 ]) > > (mem/c:QI (symbol_ref:HI ("c

-Wformat-security warnings generated in gcc build

2014-01-21 Thread Prathamesh Kulkarni
There are about 35 warnings of type "format not a string literal and no formal arguments [-Wformat-security]" generated during gcc-4.9.0 build (revision 206867) I have attached them in orig-warnings.txt. Souce of these warnings are typically calls to error() and friends. In C and C++ front ends t

Re: Invalid code emitted

2014-01-21 Thread Umesh Kalappa
My bad Ian, Thanks for the input and the target was private and gcc 4.8.1 version used and your are on same page on reg pairing . Let me have a look on the port . Thanks Again ~Umesh On Tue, Jan 21, 2014 at 8:12 PM, Ian Lance Taylor wrote: > On Tue, Jan 21, 2014 at 12:52 AM, Umesh Kalappa >

Re: -Wformat-security warnings generated in gcc build

2014-01-21 Thread Jakub Jelinek
On Tue, Jan 21, 2014 at 09:09:25PM +0530, Prathamesh Kulkarni wrote: > --- gcc/c/c-convert.c (revision 206867) > +++ gcc/c/c-convert.c (working copy) > @@ -79,7 +79,7 @@ convert (tree type, tree expr) >if ((invalid_conv_diag > = targetm.invalid_conversion (TREE_TYPE (expr), type))) >

Re: -Wformat-security warnings generated in gcc build

2014-01-21 Thread Joseph S. Myers
On Tue, 21 Jan 2014, Prathamesh Kulkarni wrote: > Souce of these warnings are typically calls to error() and friends. > In C and C++ front ends there are many calls of error (errmsg). > errmsg is in many cases, assigned the return value of targetm hooks > (tagetm.invalid_return_type(), etc.) Is

Re: -Wformat-security warnings generated in gcc build

2014-01-21 Thread Florian Weimer
On 01/21/2014 06:50 PM, Joseph S. Myers wrote: On Tue, 21 Jan 2014, Prathamesh Kulkarni wrote: Souce of these warnings are typically calls to error() and friends. In C and C++ front ends there are many calls of error (errmsg). errmsg is in many cases, assigned the return value of targetm hooks

clang and FSF's strategy

2014-01-21 Thread Eric S. Raymond
David Kastrup's recent question on emacs-devel motivates me to bring up a larger related question I've been meaning to open for a while: Are the FSF's goals best served by continuing to technically restrict GCC? This is a question in which I have some positive stake. Yes, I continue to be opposed

RE: Automatic dependency file generation bug/question

2014-01-21 Thread ANDY KENNEDY
Ping (with one correction). > -Original Message- > From: ANDY KENNEDY > Sent: Wednesday, January 15, 2014 3:16 PM > To: 'gcc@gcc.gnu.org' > Subject: Automatic dependency file generation bug/question > > Reading , I find that > dependency files sh

Re: clang and FSF's strategy

2014-01-21 Thread David Kastrup
e...@thyrsus.com (Eric S. Raymond) writes: > David Kastrup's recent question on emacs-devel motivates me to bring > up a larger related question I've been meaning to open for a while: > Are the FSF's goals best served by continuing to technically restrict > GCC? I don't think that's even a sensib

Re: clang and FSF's strategy

2014-01-21 Thread Alexandre Oliva
On Jan 21, 2014, e...@thyrsus.com (Eric S. Raymond) wrote: > I think it is time to question whether the anti-plugins policy is > still the best way to accomplish this. Err... Excuse me, but what anti-plugins policy are you talking about? The runtime license exception designed to make room for G

Re: clang and FSF's strategy

2014-01-21 Thread Stefan Monnier
> up a larger related question I've been meaning to open for a while: Are the > FSF's goals best served by continuing to technically restrict GCC? Let me repeat: please stop discussing such things on this list. There are things like gnu.misc.discuss for that. Stefan

Re: clang and FSF's strategy

2014-01-21 Thread Ian Lance Taylor
On Tue, Jan 21, 2014 at 12:19 PM, Eric S. Raymond wrote: > > Wouldn't it make sense, then, to entirely drop the factoring > restrictions from GCC so it can compete for developer attention more > effectively with clang? > > Before clang existed, back when GCC had a near monopoly in its > competitiv

Re: clang and FSF's strategy

2014-01-21 Thread Eric S. Raymond
Ian Lance Taylor : > I'm sympathetic to our comments regarding GCC vs. clang. But I'm not > sure I grasp your proposed solution. GCC does support plugins, and > has supported them for a few releases now. Then I don't understand why David Kastrup's question was even controversial. If I have fail