On Thu, Aug 14, 2008 at 11:52 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
>> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
> I'd like to see carets on by default as part of a major release -- say
> GCC 5.0. (First mention!!)
100% agreed.
-- Gaby
On Thu, Aug 14, 2008 at 12:14 PM, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
>> * In the near future, make -fdiagnostics-show-caret the default at
>> least while in experimental mode or at least during stages1 and 2.
>> When making a release -fno-diagnostics-show-caret would be the
>> default. Do th
On Thu, Aug 14, 2008 at 7:39 AM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
>
> I don't think the option should necessarily just be boolean; once choice
> that may make sense would be caret diagnostics for the first diagnostic
> from an input file o
On Wed, Aug 13, 2008 at 2:16 PM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Wed, 13 Aug 2008, Aldy Hernandez wrote:
>
> I think it would certainly be reasonable to print for
> anything unsupported instead of broken diagnostics, and to reclassify all
> such bugs as wishlist requests for certai
On Wed, Aug 13, 2008 at 12:52 PM, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
>
> It seems to me that the only approach here would be to provide caret
> diagnostics, because reconstructing the original sources from GENERIC
> seems like a loosing proposition.
Hi Aldy,
I agree with your analysis.
Snapshot gcc-4.4-20080815 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080815/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, 15 Aug 2008, Ian Lance Taylor wrote:
> Perhaps I misunderstand what you mean by recording the location in the
> preprocessed token stream. You evidently do not mean getting column
> numbers for the preprocessed code. You mean that when a preprocessor
> macro is expanded, we should record
2008/8/15 Ian Lance Taylor <[EMAIL PROTECTED]>:
>>
>> BTW, Clang takes into account both locations when printing diagnostics.
>
> Perhaps I misunderstand what you mean by recording the location in the
> preprocessed token stream. You evidently do not mean getting column
> numbers for the preproces
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> 2008/8/15 Ian Lance Taylor <[EMAIL PROTECTED]>:
>> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>>
>>> A) Printing the input expression instead of re-constructing it. As
>>>Joseph explained, this will fix the problems that Aldy mentioned
On Thu, 2008-08-14 at 14:41 -0700, H.J. Lu wrote:
> It should be fixed now.
Thanks a lot for the quick fix.
My problem is that I don't have access to a machine with GFC_REAL_16 and
working autoconf2.59, so possible problems in cut&paste code tend to be
hidden from me.
I'll make special mention
On Fri, Aug 15, 2008 at 7:00 PM, Martin Schindewolf <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I currently introduce a temporary variable on SSA form but it
> does not survive the SSA optimisation passes. (Not even the
> simple ones triggered with -O1). Since the temporary variable
> is considered to
Hi all,
I currently introduce a temporary variable on SSA form but it
does not survive the SSA optimisation passes. (Not even the
simple ones triggered with -O1). Since the temporary variable
is considered to be a gimple register it is not possible to
set a VUSE or VDEF for it. (I tried and it br
On Fri, Aug 15, 2008 at 11:31 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/8/15 Daniel Berlin <[EMAIL PROTECTED]>:
>> On Fri, Aug 15, 2008 at 10:58 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>>> On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-Ibáñez
>>> <[EMAIL PROTECTED]> wrote:
On Fri, 15 Aug 2008, Manuel López-Ibáñez wrote:
> 5) Handle locations during folding or avoid aggressive folding in
> the front-ends.
I plan to delay folding for C (beyond some folding for expressions of
constants) for 4.5, probably in October. (I do not plan to do anything
for C++, and
2008/8/15 Chris Lattner <[EMAIL PROTECTED]>:
>> D) Printing Ranges. This requires:
>>
>> *) Printing accurate column information. Similar to (B) above.
>>
>> *) A location(s) -> source strings interface and machinery. Similar
>> to (A.3) above.
>
> Ranges also require some way to get the end
D) Printing Ranges. This requires:
*) Printing accurate column information. Similar to (B) above.
*) A location(s) -> source strings interface and machinery. Similar
to (A.3) above.
Ranges also require some way to get the end of a token (in addition to
its beginning). For example,
2008/8/15 Daniel Berlin <[EMAIL PROTECTED]>:
> On Fri, Aug 15, 2008 at 10:58 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>> On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-Ibáñez
>> <[EMAIL PROTECTED]> wrote:
>>> 2008/8/14 Daniel Berlin <[EMAIL PROTECTED]>:
1. You can't assume VUSE's are must-a
2008/8/15 Ian Lance Taylor <[EMAIL PROTECTED]>:
> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>
>> A) Printing the input expression instead of re-constructing it. As
>>Joseph explained, this will fix the problems that Aldy mentioned
>>(PR3544[123] and PR35742) and this requires:
>>
>>
On Fri, Aug 15, 2008 at 10:58 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-Ibáñez
> <[EMAIL PROTECTED]> wrote:
>> 2008/8/14 Daniel Berlin <[EMAIL PROTECTED]>:
>>> 1. You can't assume VUSE's are must-aliases. The fact that there is a
>>> vuse for some
On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/8/14 Daniel Berlin <[EMAIL PROTECTED]>:
>> 1. You can't assume VUSE's are must-aliases. The fact that there is a
>> vuse for something does not imply it is must-used, it implies it is
>> may-used.
>>
>> We do no
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> Let's try to focus on what needs to be done looking for specific
> features (or fixes) and how we could do it:
Thanks for writing this up.
> A) Printing the input expression instead of re-constructing it. As
>Joseph explained, this will fix
Let's try to focus on what needs to be done looking for specific
features (or fixes) and how we could do it:
A) Printing the input expression instead of re-constructing it. As
Joseph explained, this will fix the problems that Aldy mentioned
(PR3544[123] and PR35742) and this requires:
1)
2008/8/14 Daniel Berlin <[EMAIL PROTECTED]>:
> 1. You can't assume VUSE's are must-aliases. The fact that there is a
> vuse for something does not imply it is must-used, it implies it is
> may-used.
>
> We do not differentiate may-use from must-use in our alias system. You
> can do some trivial mu
23 matches
Mail list logo
