On 3/25/2014 4:20 AM, Richard Sandiford wrote:
dw writes:
asm ("" : "=m" (*x), "=r" (y));
you have to assume that the address in %0 might use the same register as %1
Ok, now I'm getting there. It helps that I've compiled some examples
and can see what is happening. This one is subtle.
dw writes:
> On 3/25/2014 4:20 AM, Richard Sandiford wrote:
>> dw writes:
asm ("" : "=m" (*x), "=r" (y));
you have to assume that the address in %0 might use the same register as %1
>>> Ok, now I'm getting there. It helps that I've compiled some examples
>>> and can see what i
Hi,
With the recent changes of not using automake for the build, only
auto{re}conf I have problems generating an updated Makefile.in from a
modified Makfile.am. Source is gcc-4.9-4.9-20140322
Some failing attempts:
automake 1.14.1: (same with automake-1.11)
(cd src/libgo; automake -if)
aclocal.m
I request that Bug 53001 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001) be mentioned in the
http://gcc.gnu.org/gcc-4.9/changes.html
This change adds a flag -Wfloat-conversion to C-family gcc.
Possible text for the changes page:
The -Wfloat-conversion option has been added for the C and C++
Am 03/25/2014 01:28 PM, schrieb Jeff Law:
On 03/25/14 06:23, Umesh Kalappa wrote:
Dear All,
The GCC source reference 4.8.1 will synthesized some of the double
word operations(SI mode) like add /sub in the below case from the word
size (HI) patterns,
(code snippet)
expand_binop_directly functi
Hi,
assigning a negative literal to an unsigned variable issues no warning:
unsigned int x;
x =- 4;
This is specially important in typos when -= was intended instead of =-
Would be acceptable if I add a new warning to handle this, i.e.
-Wnegative-to-unsigned
or alike?
Thanks,
Joseph Myers writes:
> On Tue, 25 Mar 2014, Matthew Fortune wrote:
>
> > Can you envisage any way of us raising a warning/error if INVALID
> > exceptions get enabled in this hybrid NaN world? I believe that is the
> > only major problem area with mixing NaNs. I.e. It should be possible
> > to int
On Wed, 2014-03-26 at 11:24 +0100, Svante Signell wrote:
> Hi,
>
> With the recent changes of gcc not using automake for the build, only
> auto{re}conf I have problems generating an updated Makefile.in from a
> modified Makfile.am. Source is gcc-4.9-4.9-20140322.
>
> Some failing attempts:
>
> a
Svante Signell writes:
> autoconf 2.69:
You must use autoconf 2.65, exactly.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 26 March 2014 15:20, Andreas Schwab wrote:
> Svante Signell writes:
>
>> autoconf 2.69:
>
> You must use autoconf 2.65, exactly.
And as it sounds like you're been messing the tree up, undo all your
local changes to the files that got touched by the wrong versions of
autoconf and automake, then
You must use autoconf 2.65, exactly.
Perhaps we could update
http://gcc.gnu.org/wiki/Regenerating_GCC_Configuration ?
-Y
On Wed, 2014-03-26 at 16:20 +0100, Andreas Schwab wrote:
> Svante Signell writes:
>
> > autoconf 2.69:
>
> You must use autoconf 2.65, exactly.
I thought autoconf versions were backwards compatible by now, obviously
not. Is this ever going to happen?
Yury Gribov writes:
> Perhaps we could update
> http://gcc.gnu.org/wiki/Regenerating_GCC_Configuration ?
$ autoconf
configure.ac:27: error: Please use exactly Autoconf 2.64 instead of 2.69.
../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:27: the top level
a
>> You must use autoconf 2.65, exactly.
> configure.ac:27: error: Please use exactly Autoconf 2.64 instead of 2.69.
Hm...
-Y
On Wed, 2014-03-26 at 16:30 +0100, Svante Signell wrote:
> On Wed, 2014-03-26 at 16:20 +0100, Andreas Schwab wrote:
> > Svante Signell writes:
> >
> > > autoconf 2.69:
> >
> > You must use autoconf 2.65, exactly.
>
> I thought autoconf versions were backwards compatible by now, obviously
> not.
On 03/26/2014 05:22 PM, Jonathan Wakely wrote:
On 26 March 2014 15:20, Andreas Schwab wrote:
Svante Signell writes:
autoconf 2.69:
You must use autoconf 2.65, exactly.
And as it sounds like you're been messing the tree up, undo all your
local changes to the files that got touched by the wro
I think it really is general though. In:
The same problem can occur if one output parameter (@var{a}) allows a
register constraint, is updating the parameter value, and references an
address while another output parameter (@var{b}) allows a memory
constraint.
Yep, you're right. I have trimme
2014-03-26 18:24 GMT+08:00 Svante Signell :
> Hi,
>
> With the recent changes of not using automake for the build, only
> auto{re}conf I have problems generating an updated Makefile.in from a
> modified Makfile.am. Source is gcc-4.9-4.9-20140322
>
For gcc-4.9, I always use automake-1.11.1 and auto
Sorry there is a typo on step 2 command...
2014-03-27 13:36 GMT+08:00 Chung-Ju Wu :
>
> 2. Build them by your own:
> (As usual, separating build folder and source folder is recommended.)
>
> $ /path/to/src/automake-1.11.1/configure --prefix=/path/to/local
> $ make
> $ make install
>
> $ /path/to/s
Georg,
Currently we implemented the expander ,where passing arguments and
handling return type had been taken care in the expander along the
emitting call insn.
Do you have any suggestion over here like other practical approach ?
Appreciate your reply here.
Thank you in advance
~Umesh
On W
20 matches
Mail list logo
