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
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
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
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
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
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 <
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
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
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:
> 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,
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.
...
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
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
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.
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
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 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
17 matches
Mail list logo
