On Fri, Jun 18, 2021 at 2:34 PM Fangrui Song wrote:
>
> On 2021-06-18, H.J. Lu via llvm-dev wrote:
> >Add GNU_PROPERTY_1_NEEDED:
> >
> > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO
> >
> >to indicate the needed properties by the object file.
> >
>
> I am fine with this logical OR
Snapshot gcc-10-20210618 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20210618/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 2021-06-18, H.J. Lu via llvm-dev wrote:
Add GNU_PROPERTY_1_NEEDED:
#define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO
to indicate the needed properties by the object file.
I am fine with this logical OR style usage. But see below, do we need it
for ld.so runtime check?
(As I me
> On 18 Jun 2021, at 17:47, Martin Sebor via Gcc wrote:
>
> On 6/18/21 8:41 AM, Jason Merrill via Gcc wrote:
>> On Fri, Jun 18, 2021 at 7:06 AM Tobias Burnus
>> wrote:
>>> On 18.06.21 11:32, Richard Earnshaw via Gcc wrote:
On 17/06/2021 18:21, Jakub Jelinek wrote:
> mklog as is doesn
On 6/18/21 8:41 AM, Jason Merrill via Gcc wrote:
On Fri, Jun 18, 2021 at 7:06 AM Tobias Burnus
wrote:
On 18.06.21 11:32, Richard Earnshaw via Gcc wrote:
On 17/06/2021 18:21, Jakub Jelinek wrote:
mklog as is doesn't fill in the details (descriptions of the changes
to each function etc.), nor
On 6/18/21 5:25 AM, Tobias Burnus wrote:
On 18.06.21 13:10, Jonathan Wakely wrote:
On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote:
PR c++/12394 - internal compiler error: in write_type, at
cp/mangle.c:1517
PR fortran/100123 - -ftree-fre gives incorrect result in subroutine
with array decla
Add GNU_PROPERTY_1_NEEDED:
#define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO
to indicate the needed properties by the object file.
Add GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION:
#define GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION (1U << 0)
to indicate that the object file
On Fri, Jun 18, 2021 at 7:06 AM Tobias Burnus
wrote:
> On 18.06.21 11:32, Richard Earnshaw via Gcc wrote:
> > On 17/06/2021 18:21, Jakub Jelinek wrote:
> >> mklog as is doesn't fill in the details (descriptions of the changes
> >> to each function etc.), nor is realiable in many cases, and with J
On Fri, Jun 18, 2021 at 3:03 PM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> I am having some trouble understanding the semantics of OBJ_TYPE_REF.
> I understand that it is made of three operands:
>
> 1. OBJ_TYPE_REF_EXPR: An expression that evaluates the value to use.
> 2. OBJ_TYPE_REF_OBJECT: Is the o
Hi,
I am having some trouble understanding the semantics of OBJ_TYPE_REF.
I understand that it is made of three operands:
1. OBJ_TYPE_REF_EXPR: An expression that evaluates the value to use.
2. OBJ_TYPE_REF_OBJECT: Is the object on whose behalf the lookup is
being performed
3. OBJ_TYPE_REF_TOKEN:
On Fri, 18 Jun 2021 at 12:26, Tobias Burnus wrote:
>
> On 18.06.21 13:10, Jonathan Wakely wrote:
>
> > On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote:
> >> PR c++/12394 - internal compiler error: in write_type, at cp/mangle.c:1517
> >> PR fortran/100123 - -ftree-fre gives incorrect result in su
On 18.06.21 13:10, Jonathan Wakely wrote:
On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote:
PR c++/12394 - internal compiler error: in write_type, at cp/mangle.c:1517
PR fortran/100123 - -ftree-fre gives incorrect result in subroutine with array
declared as length 1
PR c++/12394
On Fri, Jun 18, 2021 at 12:10:33PM +0100, Jonathan Wakely wrote:
> On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote:
> > But with -p added, it becomes rather nice. For instance:
> >
> >git diff |./contrib/mklog.py -b foo/12394 -b 100123 -p
> >
> > nows prints:
> >
> > PR c++/12394 - internal c
On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote:
> But with -p added, it becomes rather nice. For instance:
>
>git diff |./contrib/mklog.py -b foo/12394 -b 100123 -p
>
> nows prints:
>
> PR c++/12394 - internal compiler error: in write_type, at cp/mangle.c:1517
> PR fortran/100123 - -ftree-fr
On 18.06.21 11:32, Richard Earnshaw via Gcc wrote:
On 17/06/2021 18:21, Jakub Jelinek wrote:
mklog as is doesn't fill in the details (descriptions of the changes
to each function etc.), nor is realiable in many cases, and with Jason's
recent change just fills in the first and last part of the fi
On 17/06/2021 18:21, Jakub Jelinek wrote:
> On Thu, Jun 17, 2021 at 05:12:52PM +, Joseph Myers wrote:
>> On Thu, 17 Jun 2021, Richard Earnshaw via Gcc wrote:
>>
>>> It seems a bit dangerous to me to rely on just extracting PR numbers from
>>> tests. What if the patch is just adjusting a test t
16 matches
Mail list logo
