Additional BOFs for the GNU Cauldron?
There seems to be plenty of slots available on the 2nd track to schedule additional BOFs. So I'd gather if there is interest in discussing A) Unit testing (GIMPLE FE, RTL FE, the existing unit-testing), basically how people feel about moving forward here and how this would affect the current testsuite structure B) GIMPLE evolution. With LTO early debug we could finally remove some tree slack at some point in the compilation. There is also increasing need to somehow represent multiple outputs from a GIMPLE stmt (we've used complex types as a workaround in some cases) -- esp. if we would consider moving GIMPLE further into the backend area by lowering it and for example performing instruction selection on GIMPLE (we'd need to represent flag registers, etc.) C) Vectorizer. There's no vectorizer specific talk yet, the usual suspects would be an update from the we-rewrite-the-vectorizer folks and ideas about how to improve cost modeling. If there's no strong interest in any of the above we can schedule stuf as needed at the Cauldron itself as well. Thanks, Richard. -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
Re: Additional BOFs for the GNU Cauldron?
On Fri, Sep 02, 2016 at 11:19:54AM +0200, Richard Biener wrote: > > There seems to be plenty of slots available on the 2nd track to > schedule additional BOFs. So I'd gather if there is interest > in discussing > > A) Unit testing (GIMPLE FE, RTL FE, the existing unit-testing), > basically how people feel about moving forward here and how > this would affect the current testsuite structure > > B) GIMPLE evolution. With LTO early debug we could finally remove > some tree slack at some point in the compilation. There is > also increasing need to somehow represent multiple outputs > from a GIMPLE stmt (we've used complex types as a workaround > in some cases) -- esp. if we would consider moving GIMPLE further > into the backend area by lowering it and for example performing > instruction selection on GIMPLE (we'd need to represent flag > registers, etc.) > > C) Vectorizer. There's no vectorizer specific talk yet, the usual > suspects would be an update from the we-rewrite-the-vectorizer > folks and ideas about how to improve cost modeling. > > If there's no strong interest in any of the above we can schedule > stuf as needed at the Cauldron itself as well. I'd be interested in all of them. Marek
cfg.c: redundant second assignment of bb_copy = NULL in free_original_copy_tables()
Hi, There appears to be a redundant second assignmeent bb_copy = NULL in free_copy_original_tables(). I suppose it should be bb_original = NULL instead ? I found this mentioned on a blog "Bugs found in gcc with help of PVS studio": http://www.viva64.com/en/b/0425/#ID0EHCCK Thanks, Prathamesh diff --git a/gcc/cfg.c b/gcc/cfg.c index 0e31780..cab66c6 100644 --- a/gcc/cfg.c +++ b/gcc/cfg.c @@ -1075,7 +1075,7 @@ free_original_copy_tables (void) delete bb_copy; bb_copy = NULL; delete bb_original; - bb_copy = NULL; + bb_original = NULL; delete loop_copy; loop_copy = NULL; delete original_copy_bb_pool;
Re: cfg.c: redundant second assignment of bb_copy = NULL in free_original_copy_tables()
On Fri, 2 Sep 2016, Prathamesh Kulkarni wrote: > Hi, > There appears to be a redundant second assignmeent bb_copy = NULL in > free_copy_original_tables(). I suppose it should be > bb_original = NULL instead ? > I found this mentioned on a blog "Bugs found in gcc with help of PVS studio": > http://www.viva64.com/en/b/0425/#ID0EHCCK Ok. Thanks, Richard.
Re: Additional BOFs for the GNU Cauldron?
On Fri, 2016-09-02 at 11:19 +0200, Richard Biener wrote: > There seems to be plenty of slots available on the 2nd track to > schedule additional BOFs. So I'd gather if there is interest > in discussing > > A) Unit testing (GIMPLE FE, RTL FE, the existing unit-testing), > basically how people feel about moving forward here and how > this would affect the current testsuite structure I'm very interested in such a BoF, but unfortunately I can't attend Cauldron this year (my daughter is starting school that week...) Jeremy has created a testing BoF on the schedule for the Friday afternoon: https://gcc.gnu.org/wiki/cauldron2016#TestingBoF which I plan to attend remotely, depending on available technology (hopefully Google Hangout/FaceTime/BlueJeans/whatever if the acoustics in the room can manage it, otherwise IRC as a fallback). I'm 5 hours behind the UK (near Boston, MA USA) so the Friday afternoon works well for me. Dave
cxx_fundamental_alignment vs. __float128
Hi Joseph,
I've just stumbled over this function in gcc/c-family/c-common.c,
which might need adjustment for __float128:
/* Return true iff ALIGN is an integral constant that is a fundamental
alignment, as defined by [basic.align] in the c++-11
specifications.
That is:
[A fundamental alignment is represented by an alignment less than or
equal to the greatest alignment supported by the implementation
in all contexts, which is equal to
alignof(max_align_t)]. */
bool
cxx_fundamental_alignment_p (unsigned align)
{
return (align <= MAX (TYPE_ALIGN (long_long_integer_type_node),
TYPE_ALIGN (long_double_type_node)));
}
Which might need adjustment, if you want to change alignof(max_align_t).
Bernd.
Re: cfg.c: redundant second assignment of bb_copy = NULL in free_original_copy_tables()
On 2 September 2016 at 15:49, Richard Biener wrote: > On Fri, 2 Sep 2016, Prathamesh Kulkarni wrote: > >> Hi, >> There appears to be a redundant second assignmeent bb_copy = NULL in >> free_copy_original_tables(). I suppose it should be >> bb_original = NULL instead ? >> I found this mentioned on a blog "Bugs found in gcc with help of PVS studio": >> http://www.viva64.com/en/b/0425/#ID0EHCCK > > Ok. Thanks, committed as r239960 after bootstrap+test on x86_64-unknown-linux-gnu. Regards, Prathamesh > > Thanks, > Richard. 2016-09-02 Prathamesh Kulkarni * cfg.c (free_original_copy_tables): Replace second assignment of bb_copy = NULL by bb_original = NULL. diff --git a/gcc/cfg.c b/gcc/cfg.c index 0e31780..cab66c6 100644 --- a/gcc/cfg.c +++ b/gcc/cfg.c @@ -1075,7 +1075,7 @@ free_original_copy_tables (void) delete bb_copy; bb_copy = NULL; delete bb_original; - bb_copy = NULL; + bb_original = NULL; delete loop_copy; loop_copy = NULL; delete original_copy_bb_pool;
Re: Additional BOFs for the GNU Cauldron?
On 2 September 2016 at 14:49, Richard Biener wrote: > > There seems to be plenty of slots available on the 2nd track to > schedule additional BOFs. So I'd gather if there is interest > in discussing > > A) Unit testing (GIMPLE FE, RTL FE, the existing unit-testing), > basically how people feel about moving forward here and how > this would affect the current testsuite structure I'd be looking forward to this BOF, in particular GIMPLE FE. There are a couple of issues which I would like to discuss: a) Extending to IPA passes: Currently the desired passes to run are specified per function which restricts it to tree-ssa passes. At the simplest level we could specify ipa passes by command line option, -fgimple -fipa-passes=" but that would be admittedly ugly -;) In the longer term it would be nice if we can have sth similar to llvm opt tool (http://llvm.org/docs/CommandGuide/opt.html) for GIMPLE b) Handling PHI's - AFAIK, phi's are handled currently by emitting an internal function from FE, and then lowering it to a real phi node in cfg pass ? It would be interesting to experiment if we could emit a lowered CFG directly from FE, but not sure if this would be of high priority. Thanks, Prathamesh > > B) GIMPLE evolution. With LTO early debug we could finally remove > some tree slack at some point in the compilation. There is > also increasing need to somehow represent multiple outputs > from a GIMPLE stmt (we've used complex types as a workaround > in some cases) -- esp. if we would consider moving GIMPLE further > into the backend area by lowering it and for example performing > instruction selection on GIMPLE (we'd need to represent flag > registers, etc.) > > C) Vectorizer. There's no vectorizer specific talk yet, the usual > suspects would be an update from the we-rewrite-the-vectorizer > folks and ideas about how to improve cost modeling. > > If there's no strong interest in any of the above we can schedule > stuf as needed at the Cauldron itself as well. > > Thanks, > Richard. > > -- > Richard Biener > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB > 21284 (AG Nuernberg)
Re: Proposal: readable and writable attributes on variables
Hi Martin (and all other list members).
On Thu, 1 Sep 2016 09:04:10 -0600, Martin Sebor wrote:
> On 08/31/2016 04:56 AM, Jens Bauer wrote:
>>>__attribute__ ((not_readable)) int write_only;
>>>int *preadwrite = &write_only;
>>
>> Would it not be possible to bring a warning in such cases ?
>> -or would that actually require a kludge ?
>
> I would expect it to be easier to issue a warning than to add support
> for a whole new type qualifier to the two GCC front ends (C and C++).
> The latter, of course, has the advantage of a more robust solution.
A new type qualifier would be great, but I think it would be more correct to
propose that as an extension of the C-language (and I don't even know who's in
charge of those standards).
Somehow 'const' and 'not_writable' is the exact same thing, but naming a
keyword for 'not_readable', which can be combined with 'const' is kinda ...
difficult, I think. ;)
>> #define __NA __attribute__((not_readable,not_writable)) /* not
>> available or no access */
>>
>> typedef struct {
>>__NA uint32_t reserved[2];/* */
>
> This could be implemented via unnamed bit-fields:
>
> uint32_t: 32;
> uint32_t: 32;
That is actually awesome. I did not know that this was possible.
(I've been programming since the 80's and it seems I'm in need of a C-course).
Is it possible to make unnamed arrays too ?
>> USART3->ODR = byteToSend;
>> receivedByte = USART3->IDR;
>
> I'm not sure I understand the purpose of using the union here but
> that's probably not important for your proposal.
The example might look a bit silly, but the idea is that input data and output
data are two different registers placed on the same address (!)
Writing a 0x41 to ODR and reading IDR immediately after may give you a result
like 0x0D.
-Eg. IDR is the Receive Data Register, ODR is the Transmit Data Register.
Thus they differ.
On some microcontrollers in a family, DR registers may share the same address
on one implementation, but a different implementation, they could be two
different addresses.
(On the Atari ST's floppy disk controller, you wrote one register, and at the
register's address offset two bytes, you would read the data you just wrote).
>> Normally, __I, __O and __IO are defined as follows in the CMSIS
>> include files:
>> #ifdef __cplusplus
>>#define __I volatile /*!< Defines 'read only' permissions */
>> #else
>>#define __I volatile const/*!< Defines 'read only' permissions */
>> #endif
>> #define __O volatile /*!< Defines 'write only' permissions */
>> #define __IOvolatile /*!< Defines 'read / write'
>> permissions */
>>
>> -That means for C++, __I does not work entirely as intended; it was
>> probably done this way due to RTTI.
>> I believe that in this case an attribute would not have this problem ?
>
> I can't imagine what impact RTTI might have on this. I'd expect
> "__attribute__((not_writable))" to map to "const" with no need for
> the attribute.
I believe it's due to that people mix C and C++; they use C headers for C++
projects (they kinda have to).
As #define macros are unaffected by extern "C" { ... }, a macro that defines
__IO as being const will still generate a C++ symbol when the file is compiled
by the C++ compiler. Linking the file with a C file will probably result in an
undefined symbol, because the linker looks for the C++ symbol.
-But it's definitely not impossible to use const in this case, and the above
might be a solution to quickly fix some build-errors that occurs in certain
combinations. I've not thought about all the possible aspects of why it is only
declared const for C, though.
>> __O can not prohibit reading.
>> Some hardware registers react upon 'access'; eg. if read, it becomes
>> zero, if written, only the set bits are changed.
>> __O currently cannot prevent reading such registers.
>
> Understood. I think a write-only attribute or type qualifier would
> make sense. Until/unless it's implemented I would recommend to work
> around its absence by hiding access to the registers behind a read-
> only and write-only functional API.
I'll begin writing an official proposal/enhancement request, with as concise
information as I can.
I very much appreciate the kindness and aspects from both you and Florian, and
I hope that many will benefit from the changes. :)
I'd also like to thank every developer who has been part of developing GCC. As
it had an impact on the entire World, the World would look completely different
without these tools; thank you all for making such an awesome and robust
platform independent tool of such high quality!
Love
Jens
