[Apologies if you receive multiple copies of this CFP]
==
5th WORLDS4 2021| 29 - 30 July 2021 | London, United Kingdom
http://www.worlds4.co.uk/
[http://xptjw.mjt.lu/lnk/AM8AAGw7iVkAdrA2DtQAYRUAABCaAA_fAgBeg2HQxXclNLepQquYI17k
* David Brown:
> On 18/02/2021 13:31, Florian Weimer via Gcc wrote:
>> * Jonathan Wakely via Gcc:
>>
>>> Declare your functions. Don't ignore warnings.
>>
>> It's actually a GCC bug that this isn't an error. However, too many
>> configure scripts would still break if we changed the default.
>>
On Fri, 19 Feb 2021 at 10:31, Shuai Wang via Gcc wrote:
>
> Hello,
>
> I noticed that tree_node is implemented as a union (
> https://code.woboq.org/gcc/gcc/tree-core.h.html#tree_node). However, I
> cannot find a way of checking whether the current tree_node is really a
> base or type.
>
> For ins
On 19/02/2021 09:45, Florian Weimer wrote:
* David Brown:
On 18/02/2021 13:31, Florian Weimer via Gcc wrote:
* Jonathan Wakely via Gcc:
Declare your functions. Don't ignore warnings.
It's actually a GCC bug that this isn't an error. However, too many
configure scripts would still break
On Fri, 19 Feb 2021 at 09:42, David Brown wrote:
> Just to be clear - I am not in any way suggesting that this situation is
> the fault of any gcc developers. If configure scripts are failing
> because they rely on poor C code or inappropriate use of gcc (code that
> requires a particular C standa
On Fri, 19 Feb 2021 at 11:18, Jonathan Wakely wrote:
>
> On Fri, 19 Feb 2021 at 09:42, David Brown wrote:
> > Just to be clear - I am not in any way suggesting that this situation is
> > the fault of any gcc developers. If configure scripts are failing
> > because they rely on poor C code or inap
Hello!
Thank you for the information. I am also quite confused with this issue. I
note that it seems that given the following statement:
m_pstSwtmrCBArray.27_1 = m_pstSwtmrCBArray;
where m_pstSwtmrCBArray is a global variable (a pointer). When passing a
tree pointer `v` referring to m_pstSwtmrCB
On Fri, 19 Feb 2021, Project Revolution via Gcc wrote:
> Gentlemen: this was fixed, although it's a bit of an odd solution. We
> had to combine both -mno-explicit-relocs and -mno-split-addresses, even
> though per the MIPS compiler documentation explicit relocs supersedes
> the split addresses
Snapshot gcc-9-20210219 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210219/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
