Re: [PATCH] Objective-C: fix protocol list count type (pertinent to non-LP64)

[Matt Jacobson via Gcc-patches]

> On Oct 25, 2021, at 5:43 AM, Iain Sandoe  wrote:
> 
> Did you test objective-c++ on Darwin?
> 
> I see a lot of fails of the form:
> Excess errors:
> : error: initialization of a flexible array member [-Wpedantic]

Looked into this.  It’s happening because obj-c++.dg/dg.exp has:

set DEFAULT_OBJCXXFLAGS " -ansi -pedantic-errors -Wno-long-long"

Specifically, the `-pedantic-errors` argument prohibits initialization of a 
flexible array member.  Notably, this flag does *not* appear in objc/dg.exp.

Admittedly I didn’t know that initialization of a FAM was prohibited by the 
standard.  It’s allowed by GCC, though, as documented here:



Is it OK to use a GCC extension this way in the Objective-C frontend?

> For a patch that changes code-gen we should have a test that it produces 
> what’s
> expected (in general, a ‘torture' test would be preferrable so that we can be 
> sure the
> output is as expected for different optimisation levels). 

The output is different only for targets where 
sizeof (long) != sizeof (void *).  Do we have the ability to run “cross” 
torture tests?  Could such a test verify the emitted assembly (like LLVM’s 
FileCheck tests do)?  Or would it need to execute something?

Thanks for your help!

Matt

Re: [PATCH] Objective-C: fix protocol list count type (pertinent to non-LP64)

[Matt Jacobson via Gcc-patches]

> On Sep 26, 2021, at 11:45 PM, Matt Jacobson  wrote:
> 
> Fix protocol list layout for non-LP64.  clang and objc4 both give the `count` 
> field as `long`, not `intptr_t`.  Those are the same on LP64, but not 
> everywhere.  For non-LP64, this fixes binary compatibility with clang-built 
> classes.
> 
> This was more complicated than I anticipated, because the relevant frontend 
> code in fact had no AST type for `protocol_list_t`, instead emitting protocol 
> lists as `protocol_t[]`, with the zeroth element actually being the integer 
> count.  That made it nontrivial to change the count to `long`.  With this 
> change, there is now a true `protocol_list_t` type in the AST.
> 
> Tested multiple ways.  On x86_64/Darwin, I confirmed with a test program that 
> protocol conformances by classes, categories, and protocols works.  On AVR, I 
> manually inspected the generated assembly to confirm that protocol lists gain 
> an extra two bytes of `count`, matching clang.
> 
> Thank you for your time.
> 
> 

Friendly ping.  Please let me know if there’s anything I can clarify.

Original mail:


Thanks.

[PATCH] Objective-C: fix protocol list count type (pertinent to non-LP64)

[Matt Jacobson via Gcc-patches]

Fix protocol list layout for non-LP64.  clang and objc4 both give the `count` 
field as `long`, not `intptr_t`.  Those are the same on LP64, but not 
everywhere.  For non-LP64, this fixes binary compatibility with clang-built 
classes.

This was more complicated than I anticipated, because the relevant frontend 
code in fact had no AST type for `protocol_list_t`, instead emitting protocol 
lists as `protocol_t[]`, with the zeroth element actually being the integer 
count.  That made it nontrivial to change the count to `long`.  With this 
change, there is now a true `protocol_list_t` type in the AST.

Tested multiple ways.  On x86_64/Darwin, I confirmed with a test program that 
protocol conformances by classes, categories, and protocols works.  On AVR, I 
manually inspected the generated assembly to confirm that protocol lists gain 
an extra two bytes of `count`, matching clang.

Thank you for your time.




gcc/objc/ChangeLog:

2021-09-26  Matt Jacobson  

* objc-next-runtime-abi-02.c (enum objc_v2_tree_index): Add new global 
tree.
(static void next_runtime_02_initialize): Initialize protocol list type 
tree.
(struct class_ro_t): Fix type misspelling.
(build_v2_class_templates): Correct type in field declaration.
(build_v2_protocol_templates): Create actual protocol list type tree.
(build_v2_category_template): Correct type in field declaration.
(generate_v2_protocol_list): Emit protocol list count as `long`.
(generate_v2_protocols): Use correct type.
(build_v2_category_initializer): Use correct type.
(build_v2_class_ro_t_initializer): Use correct type.


diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
b/gcc/objc/objc-next-runtime-abi-02.c
index c3af369ff0d..aadf1741676 100644
--- a/gcc/objc/objc-next-runtime-abi-02.c
+++ b/gcc/objc/objc-next-runtime-abi-02.c
@@ -92,6 +92,7 @@ enum objc_v2_tree_index
   OCTI_V2_CAT_TEMPL,
   OCTI_V2_CLS_RO_TEMPL,
   OCTI_V2_PROTO_TEMPL,
+  OCTI_V2_PROTO_LIST_TEMPL,
   OCTI_V2_IVAR_TEMPL,
   OCTI_V2_IVAR_LIST_TEMPL,
   OCTI_V2_MESSAGE_REF_TEMPL,
@@ -130,6 +131,8 @@ enum objc_v2_tree_index
objc_v2_global_trees[OCTI_V2_CAT_TEMPL]
 #define objc_v2_protocol_template \
objc_v2_global_trees[OCTI_V2_PROTO_TEMPL]
+#define objc_v2_protocol_list_template \
+   objc_v2_global_trees[OCTI_V2_PROTO_LIST_TEMPL]
 
 /* struct message_ref_t */
 #define objc_v2_message_ref_template \
@@ -196,7 +199,7 @@ static void build_v2_message_ref_templates (void);
 static void build_v2_class_templates (void);
 static void build_v2_super_template (void);
 static void build_v2_category_template (void);
-static void build_v2_protocol_template (void);
+static void build_v2_protocol_templates (void);
 
 static tree next_runtime_abi_02_super_superclassfield_id (void);
 
@@ -394,9 +397,9 @@ static void next_runtime_02_initialize (void)
build_pointer_type (xref_tag (RECORD_TYPE,
get_identifier ("_prop_list_t")));
 
+  build_v2_protocol_templates ();
   build_v2_class_templates ();
   build_v2_super_template ();
-  build_v2_protocol_template ();
   build_v2_category_template ();
 
   bool fixup_p = flag_next_runtime < USE_FIXUP_BEFORE;
@@ -636,7 +639,7 @@ struct class_ro_t
 const uint8_t * const ivarLayout;
 const char *const name;
 const struct method_list_t * const baseMethods;
-const struct objc_protocol_list *const baseProtocols;
+const struct protocol_list_t *const baseProtocols;
 const struct ivar_list_t *const ivars;
 const uint8_t * const weakIvarLayout;
 const struct _prop_list_t * const properties;
@@ -685,11 +688,9 @@ build_v2_class_templates (void)
   /* const struct method_list_t * const baseMethods; */
   add_field_decl (objc_method_list_ptr, "baseMethods", );
 
-  /* const struct objc_protocol_list *const baseProtocols; */
-  add_field_decl (build_pointer_type
-   (xref_tag (RECORD_TYPE,
-  get_identifier (UTAG_V2_PROTOCOL_LIST))),
- "baseProtocols", );
+  /* const struct protocol_list_t *const baseProtocols; */
+  add_field_decl (build_pointer_type (objc_v2_protocol_list_template),
+ "baseProtocols", );
 
   /* const struct ivar_list_t *const ivars; */
   add_field_decl (objc_v2_ivar_list_ptr, "ivars", );
@@ -763,25 +764,33 @@ build_v2_super_template (void)
  const char ** extended_method_types;
  const char * demangled_name;
  const struct _prop_list_t * class_properties;
-   }
+  };
+
+  struct protocol_list_t
+  {
+long count;
+struct protocol_t protocols[];
+  };
 */
 static void
-build_v2_protocol_template (void)
+build_v2_protocol_templates (void)
 {
-  tree decls, *chain = NULL;
+  tree decls, protolist_pointer_type, 

Re: [PATCH] Objective-C: fix class_ro layout for non-LP64

[Matt Jacobson via Gcc-patches]

Hi Iain,

Thanks for reviewing.  I’m happy to make the suggested changes.  One comment 
inline.

> On Sep 22, 2021, at 2:49 PM, Iain Sandoe  wrote:
> 
> However, the behaviour is changed - the existing implementation is explicit 
> about the fields and
> clears the reserved ones (and, ISTR, that was based on what the gcc-4.2.1 
> compiler did).

My original change does in fact clear the reserved bytes on LP64 platforms.  
The padding space compiles down to a `.space` assembler directive, and GNU as 
is documented to fill that space with zeros.  So the reserved bits are indeed 
cleared.

However, I understand the argument that this is too implicit, in that the C 
standard makes no guarantee about the contents of padding bytes.  So future 
standard-conforming changes to GCC *could* cause that space to be filled with 
other values (however unlikely that may actually be).

(Of course, clang -- which also does not explicitly declare this field --
essentially faces this same theoretical peril...)

One problem with the proposed diff: `__LP64__` there refers to the host, not 
the target.  What's the right way to refer to the LP64-ness of the target?  I 
see `TARGET_LP64`, but it's only defined for Intel.  I'm using it below (and 
backstopping it to zero), but I'm not sure if that's correct.  Note that it's a 
run-time-of-compiler (not build-time-of-compiler) check.

===

Here's v2.




gcc/objc/ChangeLog:

2021-09-26  Matt Jacobson  

* objc-next-runtime-abi-02.c (build_v2_class_templates): Remove explicit
padding on non-LP64.
(build_v2_class_ro_t_initializer): Remove initialization of explicit 
padding on
non-LP64.


diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
b/gcc/objc/objc-next-runtime-abi-02.c
index 42645e22316..22d5232614d 100644
--- a/gcc/objc/objc-next-runtime-abi-02.c
+++ b/gcc/objc/objc-next-runtime-abi-02.c
@@ -85,6 +85,10 @@ along with GCC; see the file COPYING3.  If not see
 
 #define OBJC2_CLS_HAS_CXX_STRUCTORS0x0004L
 
+#ifndef TARGET_LP64
+#define TARGET_LP64 0
+#endif
+
 enum objc_v2_tree_index
 {
   /* Templates.  */
@@ -677,10 +681,12 @@ build_v2_class_templates (void)
   /* uint32_t const instanceSize; */
   add_field_decl (integer_type_node, "instanceSize", );
 
-  /* This ABI is currently only used on m64 NeXT.  We always
- explicitly declare the alignment padding.  */
+  /* For compatibility with existing implementations of the 64-bit NeXT v2
+ ABI, explicitly declare reserved fields that otherwise would be filled
+ with alignment padding. */
   /* uint32_t const reserved; */
-  add_field_decl (integer_type_node, "reserved", );
+  if (TARGET_LP64)
+add_field_decl (integer_type_node, "reserved", );
 
   /* const uint8_t * const ivarLayout; */
   cnst_strg_type = build_pointer_type (unsigned_char_type_node);
@@ -3225,10 +3231,12 @@ build_v2_class_ro_t_initializer (tree type, tree name,
   CONSTRUCTOR_APPEND_ELT (initlist, NULL_TREE,
  build_int_cst (integer_type_node, instanceSize));
 
-  /* This ABI is currently only used on m64 NeXT.  We always
- explicitly declare the alignment padding.  */
-  /* reserved, pads alignment.  */
-  CONSTRUCTOR_APPEND_ELT (initlist, NULL_TREE,
+  /* For compatibility with existing implementations of the 64-bit NeXT v2
+ ABI, explicitly zero-fill reserved fields that otherwise would be filled
+ with alignment padding. */
+  /* reserved */
+  if (TARGET_LP64)
+CONSTRUCTOR_APPEND_ELT (initlist, NULL_TREE,
build_int_cst (integer_type_node, 0));
 
   /* ivarLayout */

[PATCH] Objective-C: fix class_ro layout for non-LP64

[Matt Jacobson via Gcc-patches]

Fix class_ro layout for non-LP64.  On LP64, the requisite padding is added at a
lower level.  For non-LP64, this fixes binary compatibility with clang-built
classes/runtimes.

Tested by examining the generated assembly for a class_ro in both cases (and in 
the case of clang), for both x86_64 (64-bit pointers) and AVR (16-bit pointers).
Tested by running a program on AVR with a GCC-built class using a clang-built 
Objective-C runtime.  Tested by running a program on x86_64/Darwin with a GCC-
built class and the clang-built system Objective-C runtime.

Patch also available at:


I don't have commit access, so if this patch is suitable, I'd need someone else 
to commit it for me.  Thanks.


gcc/objc/ChangeLog:

2021-09-21  Matt Jacobson  

* objc-next-runtime-abi-02.c (struct class_ro_t): Remove explicit 
alignment 
padding.
(build_v2_class_templates): Remove explicit alignment padding.
(build_v2_class_ro_t_initializer): Adjust initializer.


diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
b/gcc/objc/objc-next-runtime-abi-02.c
index 42645e22316..c3af369ff0d 100644
--- a/gcc/objc/objc-next-runtime-abi-02.c
+++ b/gcc/objc/objc-next-runtime-abi-02.c
@@ -632,9 +632,7 @@ struct class_ro_t
 uint32_t const flags;
 uint32_t const instanceStart;
 uint32_t const instanceSize;
-#ifdef __LP64__
-uint32_t const reserved;
-#endif
+// [32 bits of reserved space here on LP64 platforms]
 const uint8_t * const ivarLayout;
 const char *const name;
 const struct method_list_t * const baseMethods;
@@ -677,11 +675,6 @@ build_v2_class_templates (void)
   /* uint32_t const instanceSize; */
   add_field_decl (integer_type_node, "instanceSize", );
 
-  /* This ABI is currently only used on m64 NeXT.  We always
- explicitly declare the alignment padding.  */
-  /* uint32_t const reserved; */
-  add_field_decl (integer_type_node, "reserved", );
-
   /* const uint8_t * const ivarLayout; */
   cnst_strg_type = build_pointer_type (unsigned_char_type_node);
   add_field_decl (cnst_strg_type, "ivarLayout", );
@@ -3225,12 +3218,6 @@ build_v2_class_ro_t_initializer (tree type, tree name,
   CONSTRUCTOR_APPEND_ELT (initlist, NULL_TREE,
  build_int_cst (integer_type_node, instanceSize));
 
-  /* This ABI is currently only used on m64 NeXT.  We always
- explicitly declare the alignment padding.  */
-  /* reserved, pads alignment.  */
-  CONSTRUCTOR_APPEND_ELT (initlist, NULL_TREE,
-   build_int_cst (integer_type_node, 0));
-
   /* ivarLayout */
   unsigned_char_star = build_pointer_type (unsigned_char_type_node);
   if (ivarLayout)

Re: [PATCH] Objective-C: fix crash with -fobjc-nilcheck

[Matt Jacobson via Gcc-patches]

> On Aug 14, 2021, at 5:25 AM, Iain Sandoe  wrote:
> 
> 1/ please can you either post using a mailer that doesn’t mangle patches or 
> put the patch as a plain text attachment
>  (pushing to a git branch somewhere public also works for me, but maybe not 
> for all reviewers)
>   - for small patches like this I can obviously fix things up by hand, but 
> for anything larger not a good idea.
> 
> 2/ since this is fixing a crashing case, we should add a test to the test 
> suite for it (and also check the corresponding objective-c++).

Sorry for the broken patch.  I *think* this one should apply cleanly.  If not, 
I’ve also pushed the change to branch "objc-fix-struct-nil-check-10.3.0” of 
, viewable at:



I’ve also added a test specifically for this bug and in the process added 
-fobjc-nilcheck to the compiler invocation in objc-torture.exp.  Let me know 
what you think.

I’m not sure what you mean w.r.t. Objective-C++ -- can you explain?


gcc/testsuite/ChangeLog:

2021-08-14  Matt Jacobson  

PR objc/101666
* lib/objc-torture.exp: Test -fobjc-nilcheck when supported by target.
* objc/compile/pr101666.m: New test.


gcc/objc/ChangeLog:

2021-08-14  Matt Jacobson  

PR objc/101666
* objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call): Fix 
crash.
(build_v2_build_objc_method_call): Fix crash.


diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
b/gcc/objc/objc-next-runtime-abi-02.c
index 66c13ad0db2..192731ff954 100644
--- a/gcc/objc/objc-next-runtime-abi-02.c
+++ b/gcc/objc/objc-next-runtime-abi-02.c
@@ -1676,11 +1676,7 @@ build_v2_objc_method_fixup_call (int super_flag, tree 
method_prototype,
   if (TREE_CODE (ret_type) == RECORD_TYPE
  || TREE_CODE (ret_type) == UNION_TYPE)
{
- vec *rtt = NULL;
- /* ??? CHECKME. hmmm. think we need something more
-here.  */
- CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
- ftree = objc_build_constructor (ret_type, rtt);
+ ftree = objc_build_constructor (ret_type, NULL);
}
   else
ftree = fold_convert (ret_type, integer_zero_node);
@@ -1790,11 +1786,7 @@ build_v2_build_objc_method_call (int super, tree 
method_prototype,
   if (TREE_CODE (ret_type) == RECORD_TYPE
  || TREE_CODE (ret_type) == UNION_TYPE)
{
- vec *rtt = NULL;
- /* ??? CHECKME. hmmm. think we need something more
-here.  */
- CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
- ftree = objc_build_constructor (ret_type, rtt);
+ ftree = objc_build_constructor (ret_type, NULL);
}
   else
ftree = fold_convert (ret_type, integer_zero_node);
diff --git a/gcc/testsuite/lib/objc-torture.exp 
b/gcc/testsuite/lib/objc-torture.exp
index 9aa5792f656..58c4b86f840 100644
--- a/gcc/testsuite/lib/objc-torture.exp
+++ b/gcc/testsuite/lib/objc-torture.exp
@@ -30,7 +30,11 @@ proc objc-set-runtime-options { dowhat args } {
 # that Darwin uses.  If NeXT is ported to another target, then it should
 # be listed here.
 if [istarget *-*-darwin*] {
-  lappend rtlist "-fnext-runtime" 
+  if { [istarget *64-*-*] || [istarget arm-*-*] } {
+   lappend rtlist "-fnext-runtime -fobjc-abi-version=2 -fobjc-nilcheck"
+  } else {
+   lappend rtlist "-fnext-runtime -fobjc-abi-version=1"
+  }
 }
 if [info exists OBJC_RUNTIME_OPTIONS] {
   foreach other $OBJC_RUNTIME_OPTIONS {
diff --git a/gcc/testsuite/objc/compile/pr101666.m 
b/gcc/testsuite/objc/compile/pr101666.m
new file mode 100644
index 000..bfde52d3b35
--- /dev/null
+++ b/gcc/testsuite/objc/compile/pr101666.m
@@ -0,0 +1,15 @@
+struct point { double x, y, z; };
+
+@interface Foo
+
+- (struct point)bar;
+
+@end
+
+Foo *f;
+
+int
+main(void)
+{
+  struct point p = [f bar];
+}

[PATCH] Objective-C: fix crash with -fobjc-nilcheck

[Matt Jacobson via Gcc-patches]

When -fobjc-nilcheck is enabled, messages that result in a struct type should 
yield a zero-initialized struct when sent to nil.  Currently, the frontend 
crashes when it encounters this situation.  This patch fixes the crash by 
generating the tree for the `{}` initializer.

Tested by running the frontend against the example in PR101666 and inspecting 
the generated code.

I don't have commit access, so if this patch is suitable, I'd need someone else 
to commit it for me.  Thanks.


gcc/objc/ChangeLog:

2021-08-14  Matt Jacobson  

PR objc/101666
* objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call): Fix 
crash.
(build_v2_build_objc_method_call): Fix crash.


diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
b/gcc/objc/objc-next-runtime-abi-02.c
index e391ee527ce..42645e22316 100644
--- a/gcc/objc/objc-next-runtime-abi-02.c
+++ b/gcc/objc/objc-next-runtime-abi-02.c
@@ -1676,11 +1676,7 @@ build_v2_objc_method_fixup_call (int super_flag, tree 
method_prototype,
   if (TREE_CODE (ret_type) == RECORD_TYPE
  || TREE_CODE (ret_type) == UNION_TYPE)
{
- vec *rtt = NULL;
- /* ??? CHECKME. hmmm. think we need something more
-here.  */
- CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
- ftree = objc_build_constructor (ret_type, rtt);
+ ftree = objc_build_constructor (ret_type, NULL);
}
   else
ftree = fold_convert (ret_type, integer_zero_node);
@@ -1790,11 +1786,7 @@ build_v2_build_objc_method_call (int super, tree 
method_prototype,
   if (TREE_CODE (ret_type) == RECORD_TYPE
  || TREE_CODE (ret_type) == UNION_TYPE)
{
- vec *rtt = NULL;
- /* ??? CHECKME. hmmm. think we need something more
-here.  */
- CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
- ftree = objc_build_constructor (ret_type, rtt);
+ ftree = objc_build_constructor (ret_type, NULL);
}
   else
ftree = fold_convert (ret_type, integer_zero_node);

Re: [PATCH] Objective-C: don't require redundant -fno-objc-sjlj-exceptions for the NeXT v2 ABI

[Matt Jacobson via Gcc-patches]

> On Aug 3, 2021, at 2:39 PM, Iain Sandoe  wrote:
> 
> 
> 
>> On 2 Aug 2021, at 22:37, Matt Jacobson via Gcc-patches 
>>  wrote:
>> 
>>> On Aug 2, 2021, at 5:09 PM, Eric Gallager  wrote:
>>> 
>>> On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
>>>  wrote:
>>>> 
>>>> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 
>>>> crashes,
>>>> unless target-specific code adds an implicit -fno-objc-sjlj-exceptions 
>>>> (which
>>>> Darwin does).
>>>> 
>>>> This patch makes the general case not crash.
>>>> 
>>>> I don't have commit access, so if this patch is suitable, I'd need someone 
>>>> else
>>>> to commit it for me.  Thanks.
>>> 
>>> Is there a bug open for the issue that this fixes? Just wondering for
>>> cross-referencing purposes...
>> 
>> No, I didn’t file a bug for this one, just sent the patch directly.  Hope 
>> that’s OK.  If not, happy to file one.
> 
> I have this on my TODO (and in my “to apply” patch queue - IMO it’s OK as an 
> interim
> solution - but I think in the longer term it would be better to make 
> fobjc-sjlj-exceptions
> into a NOP, since the exception models are fixed for NeXT runtime (unless you 
> have
> some intent to update the 32bit one to use DWARF unwinding ;-) ).

Thanks.

It certainly isn’t crystal clear just from the diff in the mail, but with this 
patch, -fobjc-sjlj-exceptions *is* essentially a no-op (modulo a small warning) 
under NeXT v2.

Prior to this patch, it’s also a no-op, but (a) it’s initially on by default 
for NeXT v2, which (b) causes a crash unless `-fobjc-exceptions` is also 
specified.

Matt

Re: [PATCH] Objective-C: don't require redundant -fno-objc-sjlj-exceptions for the NeXT v2 ABI

[Matt Jacobson via Gcc-patches]

> On Aug 2, 2021, at 5:09 PM, Eric Gallager  wrote:
> 
> On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
>  wrote:
>> 
>> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 crashes,
>> unless target-specific code adds an implicit -fno-objc-sjlj-exceptions (which
>> Darwin does).
>> 
>> This patch makes the general case not crash.
>> 
>> I don't have commit access, so if this patch is suitable, I'd need someone 
>> else
>> to commit it for me.  Thanks.
> 
> Is there a bug open for the issue that this fixes? Just wondering for
> cross-referencing purposes...

No, I didn’t file a bug for this one, just sent the patch directly.  Hope 
that’s OK.  If not, happy to file one.

Matt

[PATCH] Objective-C: don't require redundant -fno-objc-sjlj-exceptions for the NeXT v2 ABI

[Matt Jacobson via Gcc-patches]

As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 crashes, 
unless target-specific code adds an implicit -fno-objc-sjlj-exceptions (which 
Darwin does).

This patch makes the general case not crash.

I don't have commit access, so if this patch is suitable, I'd need someone else
to commit it for me.  Thanks.

gcc/objc/ChangeLog:

2021-07-28  Matt Jacobson  

* objc-next-runtime-abi-02.c (objc_next_runtime_abi_02_init): Warn
about and reset flag_objc_sjlj_exceptions regardless of
flag_objc_exceptions.


gcc/c-family/ChangeLog:

2021-07-28  Matt Jacobson  

* c-opts.c (c_common_post_options): Default to
flag_objc_sjlj_exceptions = 1 only when flag_objc_abi < 2.

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index c51d6d34726..2568df67972 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -840,9 +840,9 @@ c_common_post_options (const char **pfilename)
   else if (!flag_gnu89_inline && !flag_isoc99)
 error ("%<-fno-gnu89-inline%> is only supported in GNU99 or C99 mode");
 
-  /* Default to ObjC sjlj exception handling if NeXT runtime.  */
+  /* Default to ObjC sjlj exception handling if NeXT  (SIZEHASHTABLE);
 
-  if (flag_objc_exceptions && flag_objc_sjlj_exceptions)
+  if (flag_objc_sjlj_exceptions)
 {
   inform (UNKNOWN_LOCATION,
  "%<-fobjc-sjlj-exceptions%> is ignored for "

Re: [PATCH] build: Implement --with-multilib-list for avr target

[Matt Jacobson via Gcc-patches]

> On Jul 5, 2021, at 7:09 PM, Matt Jacobson  wrote:
> 
>> On Jun 7, 2021, at 3:30 AM, Matt Jacobson  wrote:
>> 
>> The AVR target builds a lot of multilib variants of target libraries by 
>> default,
>> and I found myself wanting to use the --with-multilib-list argument to limit
>> what I was building, to shorten build times.  This patch implements that 
>> option
>> for the AVR target.
>> 
>> Tested by configuring and building an AVR compiler and target libs on macOS.
>> 
>> I don't have commit access, so if this patch is suitable, I'd need someone 
>> else
>> to commit it for me.  Thanks.
> 
> Ping.  (Please let me know if I’ve made some process error here; this is my 
> first change to GCC.)

Ping again.  Thanks!

Original mail:


Matt

Re: [PATCH] build: Implement --with-multilib-list for avr target

[Matt Jacobson via Gcc-patches]

> On Jun 7, 2021, at 3:30 AM, Matt Jacobson  wrote:
> 
> The AVR target builds a lot of multilib variants of target libraries by 
> default,
> and I found myself wanting to use the --with-multilib-list argument to limit
> what I was building, to shorten build times.  This patch implements that 
> option
> for the AVR target.
> 
> Tested by configuring and building an AVR compiler and target libs on macOS.
> 
> I don't have commit access, so if this patch is suitable, I'd need someone 
> else
> to commit it for me.  Thanks.

Ping.  (Please let me know if I’ve made some process error here; this is my 
first change to GCC.)

Original mail:


Thanks.

[PATCH] build: Implement --with-multilib-list for avr target

[Matt Jacobson via Gcc-patches]

The AVR target builds a lot of multilib variants of target libraries by default,
and I found myself wanting to use the --with-multilib-list argument to limit
what I was building, to shorten build times.  This patch implements that option
for the AVR target.

Tested by configuring and building an AVR compiler and target libs on macOS.

I don't have commit access, so if this patch is suitable, I'd need someone else
to commit it for me.  Thanks.

gcc/ChangeLog:

2020-06-07  Matt Jacobson  

* config.gcc: For the AVR target, populate TM_MULTILIB_CONFIG.
* config/avr/genmultilib.awk: Add ability to filter generated multilib
list.
* config/avr/t-avr: Pass TM_MULTILIB_CONFIG to genmultilib.awk.
* configure.ac: Update help string for --with-multilib-list.
* configure: Regenerate.


diff --git a/gcc/config.gcc b/gcc/config.gcc
index 6a349965c..fd83996a4 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4201,6 +4201,13 @@ case "${target}" in
fi
;;
 
+   avr-*-*)
+   # Handle --with-multilib-list.
+   if test "x${with_multilib_list}" != xdefault; then
+   TM_MULTILIB_CONFIG="${with_multilib_list}"
+   fi
+   ;;
+
 csky-*-*)
supported_defaults="cpu endian float"
;;
diff --git a/gcc/config/avr/genmultilib.awk b/gcc/config/avr/genmultilib.awk
index 2d07c0e53..ad8814602 100644
--- a/gcc/config/avr/genmultilib.awk
+++ b/gcc/config/avr/genmultilib.awk
@@ -67,6 +67,16 @@ BEGIN {
 
 dir_long_double = "long-double"   (96 - with_long_double)
 opt_long_double = "mlong-double=" (96 - with_long_double)
+
+if (with_multilib_list != "")
+{
+   split(with_multilib_list, multilib_list, ",")
+
+   for (i in multilib_list)
+   {
+   multilibs[multilib_list[i]] = 1
+   }
+}
 }
 
 ##
@@ -137,6 +147,9 @@ BEGIN {
if (core == "avr1")
next
 
+   if (with_multilib_list != "" && !(core in multilibs))
+   next
+
option[core] = "mmcu=" core
 
m_options  = m_options m_sep option[core]
@@ -150,6 +163,9 @@ BEGIN {
 if (core == "avr1")
next
 
+if (with_multilib_list != "" && !(core in multilibs))
+   next
+
 opts = option[core]
 
 # split device specific feature list
diff --git a/gcc/config/avr/t-avr b/gcc/config/avr/t-avr
index 3e1a1ba68..7d20c6107 100644
--- a/gcc/config/avr/t-avr
+++ b/gcc/config/avr/t-avr
@@ -127,6 +127,7 @@ t-multilib-avr: $(srcdir)/config/avr/genmultilib.awk \
-v HAVE_LONG_DOUBLE64=$(HAVE_LONG_DOUBLE64) \
-v with_double=$(WITH_DOUBLE)   \
-v with_long_double=$(WITH_LONG_DOUBLE) \
+   -v with_multilib_list=$(TM_MULTILIB_CONFIG) \
-f $< $< $(AVR_MCUS) > $@
 
 include t-multilib-avr
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 715fcba04..c3ed65df7 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1106,7 +1106,7 @@ if test x"$enable_hsa" = x1 ; then
 fi
 
 AC_ARG_WITH(multilib-list,
-[AS_HELP_STRING([--with-multilib-list], [select multilibs (AArch64, SH and 
x86-64 only)])],
+[AS_HELP_STRING([--with-multilib-list], [select multilibs (AArch64, AVR, i386, 
or1k, RISC-V, SH, and x86-64 only)])],
 :,
 with_multilib_list=default)