On Fri, 27 Apr 2012, Paolo Bonzini wrote:
> > What about cost considerations? We only seem to have the general
> > "branches are expensive" metric - but ctz/clz may be prohibitely expensive
> > themselves, no?
>
> Yeah, that's a general problem with this kind of tricks. In general
> however clz
On Thu, May 3, 2012 at 11:15 AM, Richard Sandiford
wrote:
> Ping for this patch to always supply a mode to plus_constant:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00892.html
>
> I've done a diff of the changes since the original test revision
> (which was r186448 FWIW) and there's only
On Sat, May 5, 2012 at 1:12 PM, Georg-Johann Lay wrote:
> The following patch needs approval:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00961.html
>
> The target-specific part is already approved:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00976.html
>
> Thanks.
The documentation par
The following patch needs approval:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00961.html
The target-specific part is already approved:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00976.html
Thanks.
Thanks for the hints. This is what I am currently
bootstrapping+regtesting. It builds and works on a few manual tests.
OK if it passes?
2012-05-05 Manuel López-Ibáñez
PR c/53063
gcc/
* doc/options.texi (EnabledBy): Document.
* opts.c (finish_options): Call finish_optio
On Sat, 5 May 2012, Manuel L?pez-Ib??ez wrote:
> Comments? My knowledge of awk is basically zero, so suggestions on
> how to improve the code are very welcome.
>
> Should I cleanup the patch and submit it with a Changelog?
Yes please. Some observations:
* finish_options_generated should take
Andreas Schwab wrote:
Janne Blomqvist writes:
On Sat, May 5, 2012 at 2:31 PM, Andreas Schwab wrote:
mpfr 2.3.1 doesn't have mpfr_fmod.
I know, but since GCC requires at least mpfr 2.4.2 we're ok.
No, it doesn't.
From 4.8's ./configure:
# If we have GMP, check the MPFR version.
...
Janne Blomqvist writes:
> On Sat, May 5, 2012 at 2:31 PM, Andreas Schwab wrote:
>> Janne Blomqvist writes:
>>
>>> - When the arguments are constant, use mpfr_fmod instead of the naive
>>
>> mpfr 2.3.1 doesn't have mpfr_fmod.
>
> I know, but since GCC requires at least mpfr 2.4.2 we're ok.
No,
On Sat, May 5, 2012 at 2:31 PM, Andreas Schwab wrote:
> Janne Blomqvist writes:
>
>> - When the arguments are constant, use mpfr_fmod instead of the naive
>
> mpfr 2.3.1 doesn't have mpfr_fmod.
I know, but since GCC requires at least mpfr 2.4.2 we're ok.
--
Janne Blomqvist
Janne Blomqvist writes:
> - When the arguments are constant, use mpfr_fmod instead of the naive
mpfr 2.3.1 doesn't have mpfr_fmod.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely diffe
The NOP_EXPR are changing the "visible" types without changing
the representation; sometimes it is about lvalueness being thrown
away (which I suspect is the case here). I've always grumbled about not
having a uniform way of saying "convert this expression to type T
to an expression of type U".
O
On Sat, May 5, 2012 at 3:52 AM, Manuel López-Ibáñez
wrote:
> This patch fixes almost all false positives in PR43772. The case not fixed is:
>
> intmax_t i = (whatever);
> if (INT_MAX < i && i <= LONG_MAX)
> print ("i is in 'long' but not 'int' ran")
>
> where we warn if INT_MAX = LONG_MAX <
Hi,
I'm analyzing this PR and the various testcases which come with it. It
looks like we have indeed two separate issues: one, which looks simpler,
with decltype, leading to ICEs; a more complex one with constexpr. The
former is about ADDR_EXPR unhandled in the finish_decltype_type switch
for
This patch adds the ability to see in shorten_compare that a constant
comes from an enumeral type. It does so by using in both C/C++ the
existing infrastructure from the C FE (c_expr). Currently, only the C
FE carries down the correct information to avoid warning, so C++ still
warns. However, this
This patch fixes almost all false positives in PR43772. The case not fixed is:
intmax_t i = (whatever);
if (INT_MAX < i && i <= LONG_MAX)
print ("i is in 'long' but not 'int' ran")
where we warn if INT_MAX = LONG_MAX < INTMAX_MAX. Perhaps with the
macro location code, we could now tell
Hi,
This patch is a first step towards encoding the fact that some flags
enable other flags in the .opt files. As a proof-of-concept, I have
only implemented the check for a group option not overriding the value
of the suboption if the suboption was set. In the future, we should
handle more stuff
On Fri, May 4, 2012 at 6:11 PM, Mikael Morin wrote:
> On 02/05/2012 21:22, Janne Blomqvist wrote:
>> PING #2
>>
>> On Thu, Apr 26, 2012 at 12:20 AM, Janne Blomqvist
>> wrote:
>>> PING!
>>>
>>> On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist
>>> wrote:
Hi,
the attached patch impleme
17 matches
Mail list logo
