Richard Guenther wrote:
These changes improve tramp3d runtime performance
by up to 280%(!) (72s to 25s).
Great! Can you check the impact on PR33604?
Paolo
Snapshot gcc-4.3-20080814 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080814/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Aug 14, 2008 at 1:32 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> Failure:
>
> ../../../libgfortran/intrinsics/cshift0.c: In function 'cshift0':
> ../../../libgfortran/intrinsics/cshift0.c:124: warning: passing
> argument 1 of 'cshift0_i16' from incompatible pointer type
> ../../../libgfo
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 must-use analysis if you like (by computing
cardinality of
Failure:
../../../libgfortran/intrinsics/cshift0.c: In function 'cshift0':
../../../libgfortran/intrinsics/cshift0.c:124: warning: passing
argument 1 of 'cshift0_i16' from incompatible pointer type
../../../libgfortran/intrinsics/cshift0.c:236: error: 'GFC_INTGER_16'
undeclared (first use in this
Manuel López-Ibáñez wrote:
The locations are as wrong now as they will be after enabling caret
diagnostics. The only difference is that no one pays attention right
now because that would require to enable -fshow-column and count
column numbers. So I am certainly not "breaking the compiler and
ho
2008/8/14 Mark Mitchell <[EMAIL PROTECTED]>:
> Manuel López-Ibáñez wrote:
>
>> My proposal is to enable this while not in release mode (like we
>> enable checks and dump statistics and output from the optimizers), so
>> developers notice wrong locations and open a PR and maybe even fix
>> them.
>
>
Ralf Wildenhues wrote:
* Tom Tromey wrote on Thu, Aug 14, 2008 at 07:39:57PM CEST:
FWIW -- the gcc-output-parsing tools I care most about are actually
usually parsing the output of 'make', which is already full of random
undigestible text that must be ignored. Caret diagnostics are
extremely un
Joseph S. Myers wrote:
On Thu, 14 Aug 2008, Tom Tromey wrote:
Yes, I agree, we need multiple things: accurate locations from the
front ends (ideally macro-expansion-aware), start- and end-locations,
better diagnostic output of various kinds, perhaps smarter location
handling in the optimization
Manuel López-Ibáñez wrote:
My proposal is to enable this while not in release mode (like we
enable checks and dump statistics and output from the optimizers), so
developers notice wrong locations and open a PR and maybe even fix
them.
Manuel --
I think it's great that you're working on caret
* Tom Tromey wrote on Thu, Aug 14, 2008 at 07:39:57PM CEST:
>
> FWIW -- the gcc-output-parsing tools I care most about are actually
> usually parsing the output of 'make', which is already full of random
> undigestible text that must be ignored. Caret diagnostics are
> extremely unlike to break t
Dear all,
In order to fix PR 179, I need help either understanding why exactly
the warning is triggered or obtaining a small self-contained testcase
to reproduce it.
Thanks in advance,
Manuel.
The attached patch triggers the warnings:
/home/manuel/src/trunk/gcc/builtins.c: In function 'fold_bu
> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
Ralf> If the GCS-style is not powerful enough to meet GCC's needs, then please
Ralf> let's not only improve GCC, but the GCS document also, so that other
Ralf> programs improve compatibly.
Yeah, good idea.
FWIW -- the gcc-output-parsing
On Thu, 14 Aug 2008, Tom Tromey wrote:
> Yes, I agree, we need multiple things: accurate locations from the
> front ends (ideally macro-expansion-aware), start- and end-locations,
> better diagnostic output of various kinds, perhaps smarter location
> handling in the optimizations, and of course f
On Thu, 14 Aug 2008, Ralf Wildenhues wrote:
> * Tom Tromey wrote on Thu, Aug 14, 2008 at 06:52:24PM CEST:
> > I'm sympathetic to the idea that switching to caret output by default
> > will break things. However, I don't think that GCS-style ranges are
> > necessarily any more reality-proof, becau
On Thu, 14 Aug 2008, Tom Tromey wrote:
> Manuel's idea that we should enable column- or caret-output in the
> development (but not release) GCC is worthy of consideration. We
> certainly aren't seeing much progress on this front as-is, maybe this
> change would inspire GCC developers a bit. It w
> * 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 this through a configure option that sets the default.
>
> * In the far away futu
On Aug 14, 2008, at 8:47 AM, Joseph S. Myers wrote:
On Thu, 14 Aug 2008, Robert Dewar wrote:
BTW, I am all in favor of caret output, it's not the default in
gnat, the default is more like the C default, but -gnatv gives
output like:
And I'd hope we could keep things that way for both C and
* Tom Tromey wrote on Thu, Aug 14, 2008 at 06:52:24PM CEST:
> I'm sympathetic to the idea that switching to caret output by default
> will break things. However, I don't think that GCS-style ranges are
> necessarily any more reality-proof, because I am skeptical that most
> tool developers read th
On Thu, Aug 14, 2008 at 6:52 PM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> I'd like to see carets on by default as part of a major release -- say
> GCC 5.0. (First mention!!)
Whoa, you wish :-)
Honors go to Marc Espie here:
http://gcc.gnu.org/ml/gcc/2000-12/msg00636.html
But there've been several
> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
Joseph> (b) to print GCS-compliant ranges in text that IDEs can parse
Joseph> to highlight the relevant text in their editors
Joseph> Caret diagnostics are only one of the styles in which the
Joseph> accurate location information can be
On Thu, 14 Aug 2008, Robert Dewar wrote:
> BTW, I am all in favor of caret output, it's not the default in
> gnat, the default is more like the C default, but -gnatv gives
> output like:
And I'd hope we could keep things that way for both C and Ada, but make
similar modes to the Ada ones availab
2008/8/14 Robert Dewar <[EMAIL PROTECTED]>:
> Manuel López-Ibáñez wrote:
>
>> My proposal is to enable this while not in release mode (like we
>> enable checks and dump statistics and output from the optimizers), so
>> developers notice wrong locations and open a PR and maybe even fix
>> them. Then
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
>
> The solution is producing accurate location ranges, which can be used (a)
> to print more accurate expressions within the text of diagnostics in the
> existing style, (b) to print GCS-compliant ranges in text that IDEs can
> parse to highlight the
Manuel López-Ibáñez wrote:
My proposal is to enable this while not in release mode (like we
enable checks and dump statistics and output from the optimizers), so
developers notice wrong locations and open a PR and maybe even fix
them. Then maybe let users or distributions configure the default a
2008/8/14 Robert Dewar <[EMAIL PROTECTED]>:
> Manuel López-Ibáñez wrote:
>>
>> 2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
>>>
>>> But in any case the default should be the default with no configure
>>> option, users liking it should find their makefiles work the same
>>> everywhere and users no
Joseph S. Myers wrote:
We certainly do change the *text* of messages to improve them (this
includes putting in more information that can fit within the existing
single-line format), and add new messages following the standard formats,
but I believe we should leave consumers able to rely on cer
2008/8/14 Aldy Hernandez <[EMAIL PROTECTED]>:
>
> I envision the caret diagnostics being disabled for only a short while--
> while we beat some sense into the column information. There's no point
> in attacking everything at once.
Then, I think we are talking past each other. To be crystal clear,
On Thu, 14 Aug 2008, Robert Dewar wrote:
> Manuel López-Ibáñez wrote:
> > 2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
> > > But in any case the default should be the default with no configure
> > > option, users liking it should find their makefiles work the same
> > > everywhere and users not
> Then we are not going to get correct locations ever. New users do not
> read the manual. Neither old users do. New functionality disabled by
> default will be lost for both. I am fairly sure that a significant
> percentage of GCC developers (not just users) do not know about
> -fdiagnostics-show-
On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
> 2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
> >
> > But in any case the default should be the default with no configure
> > option, users liking it should find their makefiles work the same
> > everywhere and users not liking it can add the oppo
Manuel López-Ibáñez wrote:
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
But in any case the default should be the default with no configure
option, users liking it should find their makefiles work the same
everywhere and users not liking it can add the opposite option.
Then we are not going
2008/8/14 Aldy Hernandez <[EMAIL PROTECTED]>:
>> There are various issues that would need to be addressed to have
>> decent caret diagnostics:
>
> Agreed. I think having caret diagnostics in place is a good first step,
> if only because it'll make debugging of column diagnostics easier.
> After th
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
>
> But in any case the default should be the default with no configure
> option, users liking it should find their makefiles work the same
> everywhere and users not liking it can add the opposite option.
Then we are not going to get correct location
> There are various issues that would need to be addressed to have
> decent caret diagnostics:
Agreed. I think having caret diagnostics in place is a good first step,
if only because it'll make debugging of column diagnostics easier.
After this, we can modify the testsuite machinery to test colum
(cross-posting because of the request for testing below)
This is a first step towards getting rid of some passes and re-ordering
passes to be more effective and less compile-time consuming. The
following measurements have been done on top of some more statistics
instrumentation (which I will pos
On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
> Even if the configure options do not control the compilation of the
> code, they should at least control the default. I think that, at least
No, whatever the default is there should definitely be no configure option
to control it. Configure opti
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
> On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
>
>> It is controlled by -fdiagnostics-show-caret. See the diff for gcc/opts.c.
>>
>> The configure options are meant to enable/disable all code related to
>> caret printing in a similar way as it was d
On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
> It is controlled by -fdiagnostics-show-caret. See the diff for gcc/opts.c.
>
> The configure options are meant to enable/disable all code related to
> caret printing in a similar way as it was done with mapped locations.
> This was requested the f
On Wed, 13 Aug 2008, Aldy Hernandez wrote:
> 1. beginning/ending locations functionality as Joseph suggests.
Note that the GNU Coding Standards specify formats for diagnostics giving
a range of locations; when GCC tracks such a range, it should use those
formats (by default).
source-file-
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
> On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
>
>> You can see many examples of the caret output by configuring with
>> --enable-caret-diagnostics, then reverting the changes to
>> gcc/testsuite/lib/gcc.exp and running the testsuite. Check the outp
2008/8/13 Tom Tromey <[EMAIL PROTECTED]>:
>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>
> Tom> As far as I know nobody is actively working on any of this, though
> Tom> Mañuel and I talk about it sporadically.
>
> Crap, I misspelled his name while trying extra to get it right.
> Sorry ab
2008/8/14 Aldy Hernandez <[EMAIL PROTECTED]>:
>> Aldy> 1. beginning/ending locations functionality as Joseph suggests.
>> Aldy> 2. make sure the parsers pick the proper token/location.
>> Aldy> 3. error reporting machinery
>>
>> Aldy> How does this sound?
>>
>> It sounds good to me. #1 might be ha
2008/8/13 Aldy Hernandez <[EMAIL PROTECTED]>:
>
> 1. beginning/ending locations functionality as Joseph suggests.
> 2. make sure the parsers pick the proper token/location.
> 3. error reporting machinery
There are various issues that would need to be addressed to have
decent caret diagnostics:
1)
> Aldy> 1. beginning/ending locations functionality as Joseph suggests.
> Aldy> 2. make sure the parsers pick the proper token/location.
> Aldy> 3. error reporting machinery
>
> Aldy> How does this sound?
>
> It sounds good to me. #1 might be hard, I have not looked into it.
Well, we can alwa
2008/8/14 Tom Tromey <[EMAIL PROTECTED]>:
>
> ISTR Manuel having a patch for caret diagnostic output... ?
>
I was planning to submit it this week to consider it for GCC 4.4
(disabled by default). I am still testing it. Bootstrap and regression
testing with --enable-languages=all,ada,obj-c++ is ver
46 matches
Mail list logo
