Re: [PATCH 2/2] sparc: Run SUBTARGET_INIT_BUILTINS if it exists

[coypu--- via Gcc-patches]

I hope that writing the detailed commit message will encourage someone
with better knowledge of GCC internals to point out a better place for
this logic. I can follow through with any suggestions :)

On Sat, Feb 13, 2021 at 12:20:30PM +, Maya Rashish wrote:
> Some subtargets don't provide the canonical function names as
> the symbol name in C libraries, and libcalls will only work if
> the builtins are patched to emit the correct library name.
> 
> For example, on NetBSD, cabsl has the symbol name __c99_cabsl,
> and the patching is done via netbsd_patch_builtin.
> 
> With this change, libgfortran.so is correctly built with a
> reference to __c99_cabsl, instead of "cabsl" which is not defined.

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[coypu--- via Gcc-patches]

On Tue, Nov 24, 2020 at 05:27:10AM +, Maciej W. Rozycki wrote:
> On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:
> 
> > > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > > does not support it, but if you get rid of that macro, that particular
> > > problem should be solved.
> > 
> >  Thanks for the hint; I didn't look into it any further not to distract 
> > myself from the scope of the project.  I have now, and the check you have 
> > quoted is obviously broken (as are all the remaining similar ones), given:
> > 
> > $ vax-netbsdelf-gcc -E -dM - < /dev/null | sort | grep _HAS_
> > #define __DBL_HAS_DENORM__ 0
> > #define __DBL_HAS_INFINITY__ 0
> > #define __DBL_HAS_QUIET_NAN__ 0
> > #define __FLT_HAS_DENORM__ 0
> > #define __FLT_HAS_INFINITY__ 0
> > #define __FLT_HAS_QUIET_NAN__ 0
> > #define __LDBL_HAS_DENORM__ 0
> > #define __LDBL_HAS_INFINITY__ 0
> > #define __LDBL_HAS_QUIET_NAN__ 0
> > $ 
> > 
> > which looks reasonable to me.  This seems straightforward to fix to me, so 
> > I'll include it along with verification I am about to schedule (assuming 
> > that this will be enough for libgfortran to actually build; obviously it 
> > hasn't been tried by anyone with such a setup for a while now, as these 
> > libgfortran checks date back to 2009).
> 
>  Well, it is still broken, owing to NetBSD failing to implement POSIX 2008 
> locale handling correctly, apparently deliberately[1], and missing 
> uselocale(3)[2] while still providing newlocale(3).  This confuses our 
> conditionals and consequently:
> 
> .../libgfortran/io/transfer.c: In function 'data_transfer_init_worker':
> .../libgfortran/io/transfer.c:3416:30: error:
> 'old_locale_lock' undeclared (first use in this function)
>  3416 |   __gthread_mutex_lock (_locale_lock);
>   |  ^~~
> 
> etc.
> 
>  We can probably work it around by downgrading to setlocale(3) for NetBSD 
> (i.e. whenever either function is missing) unless someone from the NetBSD 
> community contributes a better implementation (they seem to prefer their 
> own non-standard printf_l(3) library API).

Hi Maciej,

I've been building successfully with setting:
export ac_cv_func_freelocale=no
export ac_cv_func_newlocale=no
export ac_cv_func_uselocale=no

I think the code to avoid these functions already exists, but just the
configure tests need tuning.

Also, this is amazing work!

Re: [PR target/85401][v2] Add test-cases

[coypu]

On Thu, Oct 10, 2019 at 09:41:35AM +0100, Maciej W. Rozycki wrote:
> On Wed, 9 Oct 2019, co...@sdf.org wrote:
> 
> > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c 
> > b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
> > new file mode 100644
> > index 000..1d68d0b
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
> > @@ -0,0 +1,18 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2" } */
> > +
> > +int h(void);
> > +int i(int);
> > +
> > +struct a b;
> > +struct a {
> > +  unsigned c : 4;
> > +} d() {
> > +  int e, f = b.c << 2, g = h();
> > +  for (; g;)
> > +;
> > +  if (e == 0)
> > +if (f)
> > +  i(f);
> > +  return b;
> > +}
> 
>  Can you please run this (and the other test case) through `indent -gnu'?
> 
>   Maciej

OK.

2019-10-09  Maya Rashish  
* gcc.c-torture/compile/pr85401: New test.

diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401.c 
b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
new file mode 100644
index 000..fa8fa19be59
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int h (void);
+int i (int);
+
+struct a b;
+struct a
+{
+  unsigned c:4;
+} d ()
+{
+  int e, f = b.c << 2, g = h ();
+  for (; g;)
+;
+  if (e == 0)
+if (f)
+  i (f);
+  return b;
+}

[PR target/85401][v2] Add test-cases

[coypu]

On Fri, Oct 04, 2019 at 02:28:55PM -0600, Jeff Law wrote:
> On 10/4/19 1:43 PM, co...@sdf.org wrote:
> > On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote:
> >> On 9/30/19 2:45 PM, co...@sdf.org wrote:
> >>> On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
>  Yes, the patch is mostly ok.  You can commit it into the trunk after
>  applying changes mentioned below. If you do not have a write access, let 
>  me
>  know I'll commit the patch by myself.
> >>>
> >>> I don't have commit access. It would be nice if you committed it :)
> >> I took care of the nits and committed the patch.
> >>
> >>
> >>>
>  It would be nice to add a small test too.  But it is not obligatory for 
>  this
>  case as the patch is obvious and it might be hard to create a small test 
>  to
>  reproduce the bug.
> >>>
> >>> I have the C code that produces this failure. I can creduce it, but I'm
> >>> not sure there's a relationship between it and the bug.
> >>> Doing unrelated changes (adding instruction scheduling) to vax also hid 
> >>> it.
> >>>
> >>> Is this kind of test still valuable?
> >> Often they are.
> >>
> >> jeff
> > 
> > Here's the two tests I used. It might be too machine-made.
> > One is in the vax specific directory since it needed -fno-pic.
> > 
> > 
> > 2019-10-04  Maya Rashish  
> > * gcc.c-torture/compile/pr85401-2.c: New test.
> > * gcc.target/vax/pr85401-1.c: New test.
> ISTM that both should be in c-torture.  We can use dg-* things in there too.
> 
> jeff

Sorry. I didn't realize while sending that they both produce the same
crash.

I was trying to produce test cases that don't produce warnings, and
didn't notice the change. The original second test case has an
unintialized variable use, so I am omitting it.


2019-10-09  Maya Rashish  
* gcc.c-torture/compile/pr85401: New test.


diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c 
b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
new file mode 100644
index 000..1d68d0b
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int h(void);
+int i(int);
+
+struct a b;
+struct a {
+  unsigned c : 4;
+} d() {
+  int e, f = b.c << 2, g = h();
+  for (; g;)
+;
+  if (e == 0)
+if (f)
+  i(f);
+  return b;
+}

[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401

coypu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from coypu  ---
Fixed, also the very related second failure (that creduce managed to find, when
reducing this test case).
https://gcc.gnu.org/viewcvs/gcc?view=revision=276587

[PR target/85401] Add test-cases

[coypu]

On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote:
> On 9/30/19 2:45 PM, co...@sdf.org wrote:
> > On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
> >> Yes, the patch is mostly ok.  You can commit it into the trunk after
> >> applying changes mentioned below. If you do not have a write access, let me
> >> know I'll commit the patch by myself.
> > 
> > I don't have commit access. It would be nice if you committed it :)
> I took care of the nits and committed the patch.
> 
> 
> > 
> >> It would be nice to add a small test too.  But it is not obligatory for 
> >> this
> >> case as the patch is obvious and it might be hard to create a small test to
> >> reproduce the bug.
> > 
> > I have the C code that produces this failure. I can creduce it, but I'm
> > not sure there's a relationship between it and the bug.
> > Doing unrelated changes (adding instruction scheduling) to vax also hid it.
> > 
> > Is this kind of test still valuable?
> Often they are.
> 
> jeff

Here's the two tests I used. It might be too machine-made.
One is in the vax specific directory since it needed -fno-pic.


2019-10-04  Maya Rashish  
* gcc.c-torture/compile/pr85401-2.c: New test.
* gcc.target/vax/pr85401-1.c: New test.


diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c 
b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
new file mode 100644
index 000..1d68d0b
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int h(void);
+int i(int);
+
+struct a b;
+struct a {
+  unsigned c : 4;
+} d() {
+  int e, f = b.c << 2, g = h();
+  for (; g;)
+;
+  if (e == 0)
+if (f)
+  i(f);
+  return b;
+}
diff --git a/gcc/testsuite/gcc.target/vax/pr85401-1.c 
b/gcc/testsuite/gcc.target/vax/pr85401-1.c
new file mode 100644
index 000..3a06f45
--- /dev/null
+++ b/gcc/testsuite/gcc.target/vax/pr85401-1.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-pic" } */
+
+int f;
+struct ac g;
+void h();
+void j() {}
+struct c {
+  int d;
+} k() {
+  ((struct c *)j)->d ^= f;
+}
+int *l();
+struct ac {
+  unsigned i : 4;
+} m() {
+  int *a, *c;
+  int b = g.i << 2, d, e;
+  ((struct c *)j)->d & 8;
+  a = l();
+  c = a;
+  h();
+  if (c)
+goto aj;
+  h();
+  d = b;
+  for (; d; d -= e += e)
+h();
+aj:
+  k();
+}

[PR target/85401] initialize the move cost table before using it (in another place, too)

[coypu]

On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote:
> On 9/30/19 2:45 PM, co...@sdf.org wrote:
> > On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
> >> Yes, the patch is mostly ok.  You can commit it into the trunk after
> >> applying changes mentioned below. If you do not have a write access, let me
> >> know I'll commit the patch by myself.
> > 
> > I don't have commit access. It would be nice if you committed it :)
> I took care of the nits and committed the patch.
> 
> 
> > 
> >> It would be nice to add a small test too.  But it is not obligatory for 
> >> this
> >> case as the patch is obvious and it might be hard to create a small test to
> >> reproduce the bug.
> > 
> > I have the C code that produces this failure. I can creduce it, but I'm
> > not sure there's a relationship between it and the bug.
> > Doing unrelated changes (adding instruction scheduling) to vax also hid it.
> > 
> > Is this kind of test still valuable?
> Often they are.
> 
> jeff

So it was. Here's another missed initialization, that running creduce
accidentally reached.



The mode might have changed, let's make sure the new mode is initialized
too.

2019-10-04  Maya Rashish 
* ira-color.c (update_costs_from_allocno): Call
ira_init_register_move_cost_if_necessary.

diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index 505d5c8ffb3..fb8b4dbc652 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -1372,6 +1372,7 @@ update_costs_from_allocno (ira_allocno_t allocno, int 
hard_regno,
 e.g. DImode for AREG on x86.  For such cases the
 register move cost will be maximal.  */
  mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
+ ira_init_register_move_cost_if_necessary (mode);
  
  cost = (cp->second == allocno
  ? ira_register_move_cost[mode][rclass][aclass]

Re: [ping][PR target/85401] initialize the move cost table before using it

[coypu]

On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
> Yes, the patch is mostly ok.  You can commit it into the trunk after
> applying changes mentioned below. If you do not have a write access, let me
> know I'll commit the patch by myself.

I don't have commit access. It would be nice if you committed it :)

> It would be nice to add a small test too.  But it is not obligatory for this
> case as the patch is obvious and it might be hard to create a small test to
> reproduce the bug.

I have the C code that produces this failure. I can creduce it, but I'm
not sure there's a relationship between it and the bug.
Doing unrelated changes (adding instruction scheduling) to vax also hid it.

Is this kind of test still valuable?

Thanks.

[ping][PR target/85401] initialize the move cost table before using it

[coypu]

re-posting, now CC'ing vmakarov who might be the right person to ping
about issues in this file.  apologies for the noise if I'm wrong.

--
This seems to be the way the rest of ira-color.c does it.
I hope it's OK. It does fix the segfault.

2019-09-10  Maya Rashish 

PR target/85401
* ira-color.c: (allocno_copy_cost_saving) Call
ira_init_register_move_cost_if_necessary

diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index 99236994d64..5d721102e19 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -2828,6 +2828,7 @@ allocno_copy_cost_saving (ira_allocno_t allocno, int 
hard_regno)
}
   else
gcc_unreachable ();
+  ira_init_register_move_cost_if_necessary(allocno_mode);
   cost += cp->freq * ira_register_move_cost[allocno_mode][rclass][rclass];
 }
   return cost;

Re: Deprecating cc0 (and consequently cc0 targets)

[coypu]

On Fri, Sep 20, 2019 at 09:38:38AM -0600, Jeff Law wrote:
> this time -- removals would happen during the gcc-11 cycle.

Hi Jeff,

I'm concerned that if I don't reach this milestone for VAX, it'll mean
that future code review will require justifying some of the original
changes which is getting increasingly challenging.

My first attempt at a CCmode conversion crashes early, and I was
suggested to first address any known bugs. I'll take another shot at it.

Re: syncing the GCC vax port, atomic issue

[coypu]

On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote:
> Introducing the reversed jbb* patterns doesn't seem to help with the
> original issue. It crashes building libatomic.

My loose understanding of what is going on:
- GCC emits this atomic in expand.
- When cleaning up, it looks for optimizations.
- It decides this is a branch to another branch situation, so maybe
  can be improved.
- This fails to output an instruction for unrelated reasons.
- Hit an assert.

I don't think that we should be trying to combine regular branch +
atomic branch in very generic code.
My guess is that, if it didn't crash now, it might emit a different kind
of branch which loses the atomic qualities, and result in wrong code.


I tried to single-step GCC, and it might be trying entirely different
instruction patterns.
I'm not sure whether I should put a lot of trust in the line numbers
shown from .md files, but it's trying nonlocal_goto in vax.md.
In any case, nothing from builtins.md.

Re: syncing the GCC vax port, atomic issue

[coypu]

On Fri, Sep 20, 2019 at 03:45:46PM -0600, Jeff Law wrote:
> Conditional branching patterns must support the label_ref and pc
> operands in either position.  Everything else I've seen on this thread
> is just working around that broken aspect of the builtins.md file.
> 
> 
> (define_insn "jbbssiqi"
>   [(parallel
> [(set (pc)
> (if_then_else
>   (ne (zero_extract:SI (match_operand:QI 0 "memory_operand" "g")
>(const_int 1)
>(match_operand:SI 1 "general_operand" "nrm"))
>   (const_int 0))
>   (label_ref (match_operand 2 "" ""))
>   (pc)))
>  (set (zero_extract:SI (match_operand:QI 3 "memory_operand" "+0")
>  (const_int 1)
>  (match_dup 1))
> (const_int 1))])]
>   ""
>   "jbssi %1,%0,%l2")
> 
> Note the position of the (label_ref ...) and (pc) operand.  You have to
> have a pattern where they are reversed as well.
> 
> As an example look at the branch and branch_reversed patterns in vax.md
> 
> jeff

Hi Jeff,

Thanks for the advice.
Introducing the reversed jbb* patterns doesn't seem to help with the
original issue. It crashes building libatomic.
I've attempted the following diff, as suggested by Maciej W. Rozycki.

(This isn't failing in the latest GCC because it doesn't include
vax/builtins.md at all)

> Ouch, there are no reversed interlocked branch instructions in the VAX
> ISA, so these would have to branch around a jump.
... https://gcc.gnu.org/ml/gcc/2018-04/msg00073.html

Is it the intended diff? did I get something wrong?

diff --git a/gcc/config/vax/builtins.md b/gcc/config/vax/builtins.md
index 2261467..db8ddc40 100644
--- a/gcc/config/vax/builtins.md
+++ b/gcc/config/vax/builtins.md
@@ -90,6 +90,24 @@
   ""
   "jbssi %1,%0,%l2")
 
+(define_insn "jbbssiqi_reversed"
+  [(parallel
+[(set (pc)
+ (if_then_else
+   (ne (zero_extract:SI (match_operand:QI 0 "memory_operand" "g")
+(const_int 1)
+(match_operand:SI 1 "general_operand" "nrm"))
+   (const_int 0))
+   (pc)
+   (label_ref (match_operand 2 "" ""
+ (set (zero_extract:SI (match_operand:QI 3 "memory_operand" "+0")
+  (const_int 1)
+  (match_dup 1))
+ (const_int 1))])]
+  ""
+  "jbssi %1,%0,0f\;jbr %l2\;0:")
+
+
 (define_insn "jbbssihi"
   [(parallel
 [(set (pc)
@@ -107,6 +125,24 @@
   ""
   "jbssi %1,%0,%l2")
 
+(define_insn "jbbssihi_reversed"
+  [(parallel
+[(set (pc)
+  (if_then_else
+(ne (zero_extract:SI (match_operand:HI 0 "memory_operand" "Q")
+ (const_int 1)
+ (match_operand:SI 1 "general_operand" "nrm"))
+(const_int 0))
+(pc)
+(label_ref (match_operand 2 "" ""
+ (set (zero_extract:SI (match_operand:HI 3 "memory_operand" "+0")
+   (const_int 1)
+   (match_dup 1))
+  (const_int 1))])]
+  ""
+  "jbssi %1,%0,0f\;jbr %l2\;0:")
+
+
 (define_insn "jbbssisi"
   [(parallel
 [(set (pc)
@@ -125,6 +161,25 @@
   "jbssi %1,%0,%l2")
 
 
+(define_insn "*jbbssisi_reversed"
+  [(parallel
+[(set (pc)
+ (if_then_else
+   (ne (zero_extract:SI (match_operand:SI 0 "memory_operand" "Q")
+(const_int 1)
+(match_operand:SI 1 "general_operand" "nrm"))
+   (const_int 0))
+   (pc)
+   (label_ref (match_operand 2 "" ""
+ (set (zero_extract:SI (match_operand:SI 3 "memory_operand" "+0")
+  (const_int 1)
+  (match_dup 1))
+ (const_int 1))])]
+  ""
+  "jbssi %1,%0,0f\; jbr %l2\;0:")
+
+
+
 (define_expand "sync_lock_release"
   [(set (match_operand:VAXint 0 "memory_operand" "+m")
(unspec:VAXint [(match_operand:VAXint 1 "const_int_operand" "n")
@@ -162,6 +217,23 @@
   ""
   "jbcci %1,%0,%l2")
 
+(define_insn "jbbcciqi_reversed"
+  [(parallel
+[(set (pc)
+ (if_then_else
+   (eq (zero_extract:SI (match_operand:QI 0 "memory_operand" "g")
+(const_int 1)
+(match_operand:SI 1 "general_operand" "nrm"))
+   (const_int 0))
+   (pc)
+   (label_ref (match_operand 2 "" ""
+ (set (zero_extract:SI (match_operand:QI 3 "memory_operand" "+0")
+  (const_int 1)
+  (match_dup 1))
+ (const_int 0))])]
+  ""
+  "jbcci %1,%0,0f\; jbr %l2\;0:")
+
 (define_insn "jbbccihi"
   [(parallel
 [(set (pc)
@@ -179,6 +251,24 @@
   ""
   "jbcci %1,%0,%l2")
 
+
+(define_insn "jbbccihi_reversed"
+  [(parallel
+[(set (pc)
+ (if_then_else
+   (eq (zero_extract:SI (match_operand:HI 0 "memory_operand" "Q")

Re: syncing the GCC vax port, atomic issue

[coypu]

On Fri, Sep 20, 2019 at 11:15:32AM +, co...@sdf.org wrote:
> Removed from the diff. Unfortunately this introduces an ICE during the
> build of GCC...

I took another look at the VAX atomic pattern issue.
(http://gnats.netbsd.org/53039)
It is a compiler crash to do with the added atomic builtins.

The original suggestion was to introduce a reversed pattern, with
label / pc swapped. It did not work, unfortunately.

The crash backtrace is (gcc-trunk line numbers):
during RTL pass: expand
/home/fly/gcc/libatomic/flag.c: In function 'atomic_flag_test_and_set':
/home/fly/gcc/libatomic/flag.c:36:1: internal compiler error: in 
patch_jump_insn, at cfgrtl.c:1291
   36 | }
  | ^
0x718c22 patch_jump_insn
/home/fly/gcc/gcc/cfgrtl.c:1290
0x718d2f redirect_branch_edge
/home/fly/gcc/gcc/cfgrtl.c:1317
0x71b8c2 rtl_redirect_edge_and_branch
/home/fly/gcc/gcc/cfgrtl.c:1450
0x703909 redirect_edge_and_branch(edge_def*, basic_block_def*)
/home/fly/gcc/gcc/cfghooks.c:373
0x119ec6e try_forward_edges
/home/fly/gcc/gcc/cfgcleanup.c:558
0x11a26ca try_optimize_cfg
/home/fly/gcc/gcc/cfgcleanup.c:2961
0x11a26ca cleanup_cfg(int)
/home/fly/gcc/gcc/cfgcleanup.c:3175
0x700a41 execute
/home/fly/gcc/gcc/cfgexpand.c:6683


This seems to be where GCC has some logic specific to optimizing jumps.
Since this isn't a normal jump possible to eliminate by being clever,
but rather our only way of doing atomics, my gut feeling is that I
should avoid this jump optimizing code entirely.

Not telling GCC it's a jump worth optimizing seems to avoid the crash,
i.e.:

-  emit_jump_insn (gen_jbbssi (operands[1], const0_rtx, label, 
operands[1]));
+  emit_insn (gen_jbbssi (operands[1], const0_rtx, label, operands[1]));
+  LABEL_NUSES (label)++;

GCC builds, but when building netbsd I get an undefined reference in
libstdc++:
libstdc++.so: undefined reference to `.L72'
libstdc++.so: undefined reference to `.L75'

I wonder whether this is a right approach with a slightly off method.

Re: syncing the GCC vax port

[coypu]

Sorry for the delay...
Updated diff: http://coypu.sdf.org/vax-gcc10.diff

On Mon, Apr 29, 2019 at 02:08:32PM -0600, Jeff Law wrote:
> On 3/30/19 3:03 AM, co...@sdf.org wrote:
> > hi folks,
> > 
> > i was interesting in tackling some problems gcc netbsd/vax has.
> > it has some ICEs which are in reload phase. searching around, the answer
> > to that is "switch to LRA first". Now, I don't quite know what that is
> > yet, but I know I need to try to do it.
> > 
> > As an initial step, I need to sync the source code.
> > netbsd/vax has some outstanding work on GCC.
> > 
> > I've done this, and I can run programs built by this compiler:
> > http://coypu.sdf.org/gcc-9-vax.diff
> > 
> > (My tree has more detail on the changes done:
> > https://github.com/gcc-mirror/gcc/compare/master...coypoop:vax )
> > 
> > Matt Thomas (the GCC VAX maintainer) is the author of most of these
> > changes, I suspect he will not be very responsive by email.
> > Not being the author, I might not be able to answer all the questions,
> > but I can try my best.
> > 
> > How do I get this across? comments? straight to gcc-patches? :-)
> > 
> > I know Jeff Law did not like the change to builtins.md as being wrong. I
> > can omit them, I forgot about it until typing this email :)
> > 
> > caveat: had an ICE during reload in the build process, I hid it
> > under the rug with -O0.
> I don't recall what I objected to :-)  From looking at the changes I'd
> be concerned about the changes from memory_operand to
> volatile_mem_operand.  Without knowing more about the problem you're
> trying to solve it's hard to ACK something like this.

Removed from the diff. Unfortunately this introduces an ICE during the
build of GCC (but that will be the second kind)

> The new "condjump" expander seems a bit under-specified.  Is there some
> reason why you needed that expander and couldn't just add a name to a
> existing define_insn?

I didn't find an answer for this yet. What I got so far:

Apparently vax did not include builtins.md before, and so an adjustment
that should have happened when the cond-optab branch was merged didn't
happen.

> A nit.  In that expander you have "gen_rtx_NE(VOIDmode ..."  There
> should be a space between the NE and the open parenthesis.  That kind of
> nit is repeated several times.

Fixed.

> The changes in constraints.md do not seem to change functionality at
> all, just reordering the oprerands.  However our preferred style is
> what's in there right now.

Undid that.

> ival >= 0  is the right way   0 <= ival is the wrong way.

Fixed.

> I noticed the patch turns off flag_dwarf2_cfi_asm.  Is there a reason
> for that?  But yet you create DEF_CFA notes in the prologue.  Is it the
> case that the CFI bits just aren't ready for consumption yet?  If not,
> then it may be easier to just not include those changes right now.

This is due to a binutils issue. It looks similar to
https://github.com/riscv/riscv-binutils-gdb/issues/76
I have yet to find a fix for it.

> I can't really comment on the changes to how addreses are handled in
> print_operand_address.  I'd just have to assume they're correct.
> 
> I don't know if we generally allow debug_rtx calls like are added.
> Usually we gcc_assert or gcc_unreachable.

OK. I removed those and added a single gcc_unreachable.

> mkrtx needs a function comment and looks like its got some formatting
> problems (spaces vs tabs issues and missing space between function name
> an the open paren for arguments).  Similarly for vax_output_movmemsi and
> legitimate_pic_operand_p, vax_decomposed_dimode_operand_p,

Added comments.

> You've got undocumented #ifdefs in legitimate_pic_operand_p.

elf.h contains:

/* Don't allow *foo which foo is non-local */
#define NO_EXTERNAL_INDIRECT_ADDRESS

Is this sufficient? thanks.

> You've got incorrect operand ordering in the adjacent_operands_p changes.

Fixed.

> The netbsd specific changes to the zero_extract patterns looks strange.
>  Why why not just have the right operand.  And why change it in the
> first place?

Refers to same as first comment: I removed these changes. Back to the
drawing board with that crash.

> Those peepholes look strange.  Why is the first insn not just removed as
> dead?

I don't understand this comment (sorry). Can you clarify it?
I removed one peephole that was (0 &&...), if that helps.

> And if these changes were done by Matt Thomas, does he have a copyright
> assignment on file?  If not, then we can't really use them.  These are
> large enough that they'd require an assignment.

Yes, Matt Thomas has a copyright assignment on file.

[Bug target/86811] Vax port needs updating for CVE-2017-5753

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811

coypu  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #1 from coypu  ---
I sent a patch to gcc-patches.
vax does not need speculation barriers. it doesn't speculate.
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01031.html

[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401

--- Comment #7 from coypu  ---
I sent a patch to gcc-patches.
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00896.html

[PATCH target/86811] Mark VAX as not needing speculation barriers

[coypu]

According to Bob Supnik (who is a very authoritative source on VAX),

> Funny you should ask. The short answer is no. No VAX ever did
> speculative or out of order execution.

As such, marking VAX as not needing speculation barriers.


PR target/86811
* config/vax/vax.c (TARGET_HAVE_SPECULATION_SAFE_VALUE):
Define to speculation_safe_value_not_needed.

---
 gcc/config/vax/vax.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/vax/vax.c b/gcc/config/vax/vax.c
index 1c220ff..fe5f04e 100644
--- a/gcc/config/vax/vax.c
+++ b/gcc/config/vax/vax.c
@@ -121,6 +121,9 @@ static HOST_WIDE_INT vax_starting_frame_offset (void);
 #undef TARGET_STARTING_FRAME_OFFSET
 #define TARGET_STARTING_FRAME_OFFSET vax_starting_frame_offset
 
+#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
+#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 /* Set global variables as needed for the options enabled.  */
-- 

[Bug target/58442] bootstrapping vax crashes on NetBSD

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442

coypu  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #12 from coypu  ---
I think this ticket can be closed.
all the vax code with mode_dependent_address_p already checks that it's MEM_P
like suggested by matt thomas.


I can almost complete a build with the patch in #58901, with the other unfixed
bug being in binutils rather than GCC :-)

[Bug target/77800] Undefined ref to host_detect_local_cpu on netbsd/arm

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77800

coypu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from coypu  ---
driver-arm.o now included for netbsd, too, after
https://gcc.gnu.org/viewcvs/gcc?view=revision=272290

[Bug target/58901] vax bootstrap fails on subreg reload

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901

coypu  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #7 from coypu  ---
Created attachment 46884
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46884=edit
matt's changes, synced by other matt, against trunk.

Confirming as still occurring in gcc-trunk as of:
xgcc (GCC) 10.0.0 20190907 (experimental)

NetBSD has a local diff to avoid this crash.
I attached it (updated for trunk) for reference.

The commit message for it (by Matt Thomas):
https://github.com/NetBSD/src/commit/e437e96750193b86d0464965661f616e011056fa

"Fix a problem with reloading the inner reg of a subreg when it's a mode
dependent address."

[PR target/85401] initialize the move cost table before using it

[coypu]

This seems to be the way the rest of ira-color.c does it.
I hope it's OK. It does fix the segfault.

2019-09-10  Maya Rashish 

PR target/85401
* ira-color.c: (allocno_copy_cost_saving) Call
ira_init_register_move_cost_if_necessary
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index 99236994d64..5d721102e19 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -2828,6 +2828,7 @@ allocno_copy_cost_saving (ira_allocno_t allocno, int 
hard_regno)
}
   else
gcc_unreachable ();
+  ira_init_register_move_cost_if_necessary(allocno_mode);
   cost += cp->freq * ira_register_move_cost[allocno_mode][rclass][rclass];
 }
   return cost;

[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401

--- Comment #6 from coypu  ---
I imagine I didn't write scheduling for the broken instruction, so it doesn't
ever happen. something silly like that, rather than it being a valid fix.

[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401

--- Comment #5 from coypu  ---
Created attachment 46872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46872=edit
providing instruction scheduling avoids this crash

So, I am trying to beat gcc/vax into shape and incorporate changes from
netbsd's patches.
I noticed one of the changes I made for another reason avoids this crash. It is
providing a (trivial) instruction scheduling.

Re: Deprecate -traditional-cpp

[coypu]

Just chiming in.
My buddy wrote a traditional C pre-processor for use with Imake (and,
presumably, other old things).
https://www.netbsd.org/~dholland/tradcpp/

(It's standalone).

[Bug target/77952] c++11 and gcc: internal compiler error: in convert_move

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77952

coypu  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #2 from coypu  ---
hi, I tested some versions:

6.3.0: fail
7.4.0: OK
trunk (10.x): OK

I suspect this means the bug can be closed as already being fixed in supported
branches.

Re: [patch] Add NetBSD/hppa target

[coypu]

On Fri, Jun 14, 2019 at 01:32:11PM -0400, John David Anglin wrote:
> >> +hppa*-*-netbsd*)
> >> +  target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS"
> > Any reason to not use the PA 2.0 ISA?   I'm virtually certain we
> > supported the 32bit ABI running on PA 2.0 hardware in hpbsd (which is
> > where the netbsd PA code is ultimately derived from).   I'd be really
> > surprised if there's any PA1.1 hardware running anywhere, though there's
> > certainly some PA2.0 hardware out in the wild.
> You might also consider adding MASK_CALLER_COPIES as libgomp is broken for 
> callee
> copies.  This is an ABI choice so ideally you should do it now or not at all.


Hi Jeff, Dave,

I've spoken to the authority of NetBSD/hppa (that's Nick Hudson), and he
said he'd rather keep the ABI as it is for the purpose of upstreaming.
He might switch ABIs eventually, but would rather do it with the local
copy of GCC first.
(And he has several PA1.1 machines :))

Thanks.

[PATCH, netbsd] Give a name to the number 0 in sysarch(0, ...)

[coypu]

The definition originates in
https://nxr.netbsd.org/xref/src/sys/arch/arm/include/sysarch.h#58

I've added the prefix SYSARCH to avoid any naming conflict concerns.

It looked a bit like an error on a first impression :-)
* config/arm/netbsd-elf.h (SYSARCH_ARM_SYNC_ICACHE): New definition.
(CLEAR_INSN_CACHE) Use it.
---
 gcc/config/arm/netbsd-elf.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/config/arm/netbsd-elf.h b/gcc/config/arm/netbsd-elf.h
index ec68d3fd10f..e42a32f927c 100644
--- a/gcc/config/arm/netbsd-elf.h
+++ b/gcc/config/arm/netbsd-elf.h
@@ -138,6 +138,8 @@
 #undef DEFAULT_STRUCTURE_SIZE_BOUNDARY
 #define DEFAULT_STRUCTURE_SIZE_BOUNDARY 8
 
+#define SYSARCH_ARM_SYNC_ICACHE0
+
 /* Clear the instruction cache from `BEG' to `END'.  This makes a
call to the ARM_SYNC_ICACHE architecture specific syscall.  */
 #define CLEAR_INSN_CACHE(BEG, END) \
@@ -151,6 +153,6 @@ do  
\
   } s; \
 s.addr = (unsigned int)(BEG);  \
 s.len = (END) - (BEG); \
-(void) sysarch (0, );\
+(void) sysarch (SYSARCH_ARM_SYNC_ICACHE, );  \
   }\
 while (0)
-- 
2.11.0

[Bug libgcc/90929] libgcc MIPS __clear_cache shouldn't be a no-op

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90929

coypu  changed:

   What|Removed |Added

 Target|mips64-linux-gnuabi64   |mips64-linux-gnuabi64,

--- Comment #1 from coypu  ---
To clarify, the correct behaviour is implemented, it just doesn't get expanded
in libgcc for header reasons.

[Bug libgcc/90929] New: libgcc MIPS __clear_cache shouldn't be a no-op

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90929

Bug ID: 90929
   Summary: libgcc MIPS __clear_cache shouldn't be a no-op
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

MIPS needs cache synchronization.

libgcc's __clear_cache expands to:

000119b0 <__clear_cache>:
   119b0:   03e8jr  ra
   119b4:   nop
...

(a no-op)

Running compiler-rt's test[1] on real hardware running netbsd/mips64 (n32)
without optimizations fails.

If -O2 is used it succeeds, presumably because the call is inlined.

# gcc clear_cache_test.c -o clear_cache_test; nm clear_cache_test |grep
clear_cache; ./clear_cache_test; echo $?
 U __clear_cache@@GCC_3.0
1
# gcc -O2 clear_cache_test.c -o clear_cache_test; nm clear_cache_test |grep
clear_cache; ./clear_cache_test; echo $?
0


To confirm this isn't caused by local changes or build oddities, I built with
trunk for "mips64-linux-gnuabi64" on linux, and it still shows the no-op
function.

The correct behaviour is to emit a call to libc (it's a privileged instruction
on older MIPS, so the kernel must do it).

[1]
https://github.com/llvm-mirror/compiler-rt/blob/master/test/builtins/Unit/clear_cache_test.c

[patch] Add NetBSD/hppa target

[coypu]

This adds netbsd/hppa support. I tested it on the shiny new QEMU-git
which can now boot NetBSD too :-)

Files are very similar to the linux code.

Please let me know if any changes need to be made.

Matt Thomas 
Nick Hudson 
Matthew Green 
Maya Rashish 

gcc/ChangeLog:
config.gcc (hppa*-*-netbsd*): New target.
config/pa/pa-netbsd.h: New file.
config/pa/pa32-netbsd.h: New file.

libgcc/ChangeLog:
config.host (hppa*-*-netbsd*): New case.
config/pa/t-netbsd: New file.

---
 gcc/config.gcc  |   8 +++
 gcc/config/pa/pa-netbsd.h   | 137 
 gcc/config/pa/pa32-netbsd.h |  37 ++
 libgcc/config.host  |   3 +
 libgcc/config/pa/t-netbsd   |   9 +++
 5 files changed, 194 insertions(+)
 create mode 100644 gcc/config/pa/pa-netbsd.h
 create mode 100644 gcc/config/pa/pa32-netbsd.h
 create mode 100644 libgcc/config/pa/t-netbsd

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 76bb316942d..ba93bb41ec8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1481,6 +1481,14 @@ hppa*-*-openbsd*)
gas=yes
gnu_ld=yes
;;
+hppa*-*-netbsd*)
+   target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS"
+   tm_file="${tm_file} dbxelf.h elfos.h ${nbsd_tm_file} \
+pa/pa-netbsd.h pa/pa32-regs.h pa/pa32-netbsd.h"
+   tmake_file="${tmake_file}"
+   tm_defines="${tm_defines} CHAR_FAST8=1 SHORT_FAST16=1"
+   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
+   ;;
 hppa[12]*-*-hpux10*)
case ${target} in
hppa1.1-*-* | hppa2*-*-*)
diff --git a/gcc/config/pa/pa-netbsd.h b/gcc/config/pa/pa-netbsd.h
new file mode 100644
index 000..88790987561
--- /dev/null
+++ b/gcc/config/pa/pa-netbsd.h
@@ -0,0 +1,137 @@
+/* Definitions for PA_RISC with ELF format
+   Copyright (C) 1999-2019 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+   NETBSD_OS_CPP_BUILTINS_ELF();   \
+   builtin_assert ("machine=bigendian");   \
+}  \
+  while (0)
+
+#undef CPP_SPEC
+#define CPP_SPEC NETBSD_CPP_SPEC
+
+#undef ASM_SPEC
+#define ASM_SPEC \
+  "%{v:-V} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}"
+
+#undef EXTRA_SPECS
+#define EXTRA_SPECS NETBSD_SUBTARGET_EXTRA_SPECS
+#undef SUBTARGET_EXTRA_SPECS
+
+#define NETBSD_ENTRY_POINT "__start"
+
+#undef LINK_SPEC
+#define LINK_SPEC NETBSD_LINK_SPEC_ELF
+
+/* NetBSD profiling functions don't need gcc to allocate counters.  */
+#define NO_DEFERRED_PROFILE_COUNTERS 1
+
+/* Define the strings used for the special svr4 .type and .size directives.
+   These strings generally do not vary from one system running svr4 to
+   another, but if a given system (e.g. m88k running svr) needs to use
+   different pseudo-op names for these, they may be overridden in the
+   file which includes this one.  */
+
+#undef STRING_ASM_OP
+#define STRING_ASM_OP   "\t.stringz\t"
+
+#define TEXT_SECTION_ASM_OP "\t.text"
+#define DATA_SECTION_ASM_OP "\t.data"
+#define BSS_SECTION_ASM_OP "\t.section\t.bss"
+
+#define TARGET_ASM_FILE_START pa_linux_file_start
+
+/* We want local labels to start with period if made with asm_fprintf.  */
+#undef LOCAL_LABEL_PREFIX
+#define LOCAL_LABEL_PREFIX "."
+
+/* Define these to generate the Linux/ELF/SysV style of internal
+   labels all the time - i.e. to be compatible with
+   ASM_GENERATE_INTERNAL_LABEL in .  Compare these with the
+   ones in pa.h and note the lack of dollar signs in these.  FIXME:
+   shouldn't we fix pa.h to use ASM_GENERATE_INTERNAL_LABEL instead? */
+
+#undef ASM_OUTPUT_ADDR_VEC_ELT
+#define ASM_OUTPUT_ADDR_VEC_ELT(FILE, VALUE) \
+  fprintf (FILE, "\t.word .L%d\n", VALUE)
+
+#undef ASM_OUTPUT_ADDR_DIFF_ELT
+#define ASM_OUTPUT_ADDR_DIFF_ELT(FILE, BODY, VALUE, REL) \
+  fprintf (FILE, "\t.word .L%d-.L%d\n", VALUE, REL)
+
+/* Use the default.  */
+#undef ASM_OUTPUT_LABEL
+
+/* NOTE: (*targetm.asm_out.internal_label)() is defined for us by elfos.h, and
+   does what we want (i.e. uses colons).  It must be compatible with
+   ASM_GENERATE_INTERNAL_LABEL(), so do not define it here.  */
+
+/* Use the default.  */
+#undef ASM_OUTPUT_INTERNAL_LABEL
+
+/* Use the default.  */
+#undef 

[patch][aarch64] add netbsd/aarch64 target

[coypu]

Hi folks,

This patch adds support for netbsd/aarch64.
It would be nice to have it committed, please tell me if anything is
wrong.

Thanks.

Matthew Green 
Maya Rashish 

gcc:
* config.gcc (aarch64*-*-netbsd*): New target.
* config/aarch64/aarch64-netbsd.h: New file.
* config/aarch64/t-aarch64-netbsd: Likewise.

libgcc:
* config.host (aarch64*-*-netbsd*): New case.



---
 gcc/config.gcc  |  6 +++
 gcc/config/aarch64/aarch64-netbsd.h | 80 +
 gcc/config/aarch64/t-aarch64-netbsd | 21 
 libgcc/config.host  |  6 +++
 4 files changed, 113 insertions(+)
 create mode 100644 gcc/config/aarch64/aarch64-netbsd.h
 create mode 100644 gcc/config/aarch64/t-aarch64-netbsd

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 0f80e836f4e..678c4ec51a3 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1021,6 +1021,12 @@ aarch64*-*-freebsd*)
tmake_file="${tmake_file} aarch64/t-aarch64 aarch64/t-aarch64-freebsd"
tm_defines="${tm_defines}  TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
;;
+aarch64*-*-netbsd*)
+   tm_file="${tm_file} dbxelf.h elfos.h ${nbsd_tm_file}"
+   tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-netbsd.h"
+   tmake_file="${tmake_file} aarch64/t-aarch64 aarch64/t-aarch64-netbsd"
+   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
+   ;;
 aarch64*-*-linux*)
tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h"
tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-linux.h"
diff --git a/gcc/config/aarch64/aarch64-netbsd.h 
b/gcc/config/aarch64/aarch64-netbsd.h
new file mode 100644
index 000..72fe6a2bdb5
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-netbsd.h
@@ -0,0 +1,80 @@
+/* Definitions for AArch64 running NetBSD
+   Copyright (C) 2016-2019 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#ifndef GCC_AARCH64_NETBSD_H
+#define GCC_AARCH64_NETBSD_H
+
+#define TARGET_LINKER_BIG_EMULATION "aarch64nbsdb"
+#define TARGET_LINKER_LITTLE_EMULATION "aarch64nbsd"
+
+#if TARGET_BIG_ENDIAN_DEFAULT
+#define TARGET_LINKER_EMULATION  TARGET_LINKER_BIG_EMULATION
+#else
+#define TARGET_LINKER_EMULATION  TARGET_LINKER_LITTLE_EMULATION
+#endif
+
+#undef  SUBTARGET_EXTRA_LINK_SPEC
+#define SUBTARGET_EXTRA_LINK_SPEC " -m" TARGET_LINKER_EMULATION
+
+#define NETBSD_ENTRY_POINT "__start"
+
+#define NETBSD_TARGET_LINK_SPEC  "%{h*}\
+   -X %{mbig-endian:-EB -m " TARGET_LINKER_BIG_EMULATION "} \
+   %{mlittle-endian:-EL -m " TARGET_LINKER_LITTLE_EMULATION "} \
+   %(netbsd_link_spec)"
+
+#if TARGET_FIX_ERR_A53_835769_DEFAULT
+#define CA53_ERR_835769_SPEC \
+  " %{!mno-fix-cortex-a53-835769:--fix-cortex-a53-835769}"
+#else
+#define CA53_ERR_835769_SPEC \
+  " %{mfix-cortex-a53-835769:--fix-cortex-a53-835769}"
+#endif
+
+#ifdef TARGET_FIX_ERR_A53_843419_DEFAULT
+#define CA53_ERR_843419_SPEC \
+  " %{!mno-fix-cortex-a53-843419:--fix-cortex-a53-843419}"
+#else
+#define CA53_ERR_843419_SPEC \
+  " %{mfix-cortex-a53-843419:--fix-cortex-a53-843419}"
+#endif
+
+#undef  LINK_SPEC
+#define LINK_SPEC NETBSD_LINK_SPEC_ELF \
+ NETBSD_TARGET_LINK_SPEC   \
+  CA53_ERR_835769_SPEC \
+  CA53_ERR_843419_SPEC
+
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+  NETBSD_OS_CPP_BUILTINS_ELF();\
+}  \
+  while (0)
+
+#undef SUBTARGET_CPP_SPEC
+#define SUBTARGET_CPP_SPEC NETBSD_CPP_SPEC
+
+#undef EXTRA_SPECS
+#define EXTRA_SPECS \
+  { "asm_cpu_spec", ASM_CPU_SPEC }, \
+  NETBSD_SUBTARGET_EXTRA_SPECS
+
+#endif  /* GCC_AARCH64_NETBSD_H */
diff --git a/gcc/config/aarch64/t-aarch64-netbsd 
b/gcc/config/aarch64/t-aarch64-netbsd
new file mode 100644
index 000..aa447d0f6d4
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-netbsd
@@ -0,0 +1,21 @@
+# Machine description for AArch64 architecture.
+#  Copyright (C) 2016-2019 Free Software Foundation, Inc.
+#
+#  This file is part of GCC.
+#
+#  GCC is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU General Public 

[PATCH, wwwdocs] Update on existence of free emulators

[coypu]

pinging this with more changes:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01471.html

S   A Free simulator does not exist.

HPPA and alpha are supported by QEMU.
https://wiki.qemu.org/Features/HPPA
https://wiki.qemu.org/Documentation/Platforms/Alpha
VAX is supported by SIMH.
http://simh.trailing-edge.com/

Index: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.84
diff -u -r1.84 backends.html
--- backends.html   18 Jan 2019 11:52:12 -  1.84
+++ backends.html   13 Jun 2019 14:35:24 -
@@ -69,7 +69,7 @@
 Target | HMSLQNFICBD lqrcpbfmgiates
 ---+---
 aarch64| Qq   b  gia  s
-alpha  |  ?? Q   Cq mgi  e
+alpha  |  ?  Q   Cq mgi  e
 arc|  B   b  gia
 arm|  b   ia  s
 avr|L  FIl  cp   g
@@ -101,7 +101,7 @@
 nds32  |   F Cia  s
 nios2  | Cia
 nvptx  |   S Q   Cq mg   e
-pa |   ? Q   CBD  qr  b   i  e
+pa | Q   CBD  qr  b   i  e
 pdp11  |L   ICqr  b  e
 powerpcspe | Q   Cqr pb   ia
 riscv  | Q   Cqr gia
@@ -116,7 +116,7 @@
 tilegx |   S Q   Cq  gi  e
 tilepro|   S   F C   gi  e
 v850   | g a  s
-vax|  M?I   c b   i  e
+vax|  M I   c b   i  e
 visium |  B  g  t s
 xtensa | C
 

Re: [PATCH] netbsd EABI support

[coypu]

I think copyright assignment is done. Thanks for bearing with me.

I noticed the version I submitted in April is missing some changes we
discussed on October 2018.

I took the patch from then and removed -matpcs too, the unnecessary
change to libgcc t-netbsd (which is the OABI configuration anyway), and
some whitespace git warned about.

Added the change to libatomic ifunc usage, since we recently claim ifunc
support on netbsd.
(Got lost in https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00290.html -
that one is my fault for submitting patches badly)


Matt Thomas 
matthew green 
Nick Hudson 
Maya Rashish 

gcc/ChangeLog:

* config.gcc (arm*-*-netbsdelf*) Add support for EABI configuration
* config.host (arm*-*-netbsd*): Build driver-arm.o
* config/arm/netbsd-eabi.h: New file.
* config/arm/netbsd-elf.h: Don't pass -matpcs unconditionally.
* config/netbsd-elf.h: Define SUBTARGET_EXTRA_SPECS.

libgcc/ChangeLog:

* config.host (arm*-*-netbsdelf*): Add support for EABI configuration
* config/arm/t-netbsd: LIB1ASMFUNCS: Append to existing set.
 HOST_LIBGCC2_CFLAGS: workaround possible bug
* config/arm/t-netbsd-eabi: New file.

libatomic/ChangeLog:
* configure.tgt: Exclude arm*-*-netbsd* from try_ifunc.



---
 gcc/config.gcc  | 29 +-
 gcc/config.host |  2 +-
 gcc/config/arm/netbsd-eabi.h| 97 +
 gcc/config/arm/netbsd-elf.h |  3 +-
 gcc/config/netbsd-elf.h | 14 +
 libatomic/configure.tgt |  2 +-
 libgcc/config.host  | 11 +++-
 libgcc/config/arm/t-netbsd  |  8 +++
 libgcc/config/arm/t-netbsd-eabi | 18 ++
 9 files changed, 177 insertions(+), 7 deletions(-)
 create mode 100644 gcc/config/arm/netbsd-eabi.h
 create mode 100644 libgcc/config/arm/t-netbsd-eabi

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 6b00c387247..9fe57f4c7de 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1159,10 +1159,33 @@ arm*-*-freebsd*)# ARM FreeBSD EABI
with_tls=${with_tls:-gnu}
;;
 arm*-*-netbsdelf*)
-   tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h arm/aout.h 
${tm_file} arm/netbsd-elf.h"
-   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
-   tmake_file="${tmake_file} arm/t-arm"
target_cpu_cname="strongarm"
+   tmake_file="${tmake_file} arm/t-arm"
+   tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h"
+   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
+   case ${target} in
+   arm*eb-*) tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1" ;;
+   esac
+   case ${target} in
+   arm*-*-netbsdelf-*eabi*)
+   tm_file="$tm_file arm/bpabi.h arm/netbsd-elf.h arm/netbsd-eabi.h"
+   tmake_file="$tmake_file arm/t-bpabi arm/t-netbsdeabi"
+   ;;
+   *)
+   tm_file="$tm_file arm/netbsd-elf.h"
+   tmake_file="$tmake_file arm/t-netbsd"
+   ;;
+   esac
+   tm_file="${tm_file} arm/aout.h arm/arm.h"
+   case ${target} in
+   arm*-*-netbsdelf-*eabihf*)
+   tm_defines="${tm_defines} 
TARGET_DEFAULT_FLOAT_ABI=ARM_FLOAT_ABI_HARD"
+   ;;
+   esac
+   case ${target} in
+   armv6*) target_cpu_cname="arm1176jzf-s";;
+   armv7*) target_cpu_cname="generic-armv7-a";;
+   esac
;;
 arm*-*-linux-*)# ARM GNU/Linux with ELF
tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h 
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
diff --git a/gcc/config.host b/gcc/config.host
index 2213404dd0e..82409e32f96 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -107,7 +107,7 @@ case ${host} in
;;
 esac
 ;;
-  arm*-*-freebsd* | arm*-*-linux* | arm*-*-fuchsia*)
+  arm*-*-freebsd* | arm*-*-netbsd* | arm*-*-linux* | arm*-*-fuchsia*)
 case ${target} in
   arm*-*-*)
host_extra_gcc_objs="driver-arm.o"
diff --git a/gcc/config/arm/netbsd-eabi.h b/gcc/config/arm/netbsd-eabi.h
new file mode 100644
index 000..5cbfcc92a59
--- /dev/null
+++ b/gcc/config/arm/netbsd-eabi.h
@@ -0,0 +1,97 @@
+/* Definitions of target machine for GNU compiler, NetBSD/arm ELF version.
+   Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
+   Contributed by Wasabi Systems, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along 

Re: [PATCH] netbsd EABI support

[coypu]

On Thu, May 23, 2019 at 05:11:30PM +0100, Richard Earnshaw (lists) wrote:
> On 23/05/2019 17:01, Richard Earnshaw (lists) wrote:
> > On 23/05/2019 15:11, Richard Earnshaw (lists) wrote:
> >> On 23/05/2019 15:03, Richard Earnshaw (lists) wrote:
> >>> On 20/05/2019 20:24, Jeff Law wrote:
>  On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote:
> > On 09/04/2019 16:04, Jeff Law wrote:
> >> On 4/8/19 9:17 AM, co...@sdf.org wrote:
> >>> Pinging again in the hope of getting the patch in, I'd like to have
> >>> less outstanding patches :) (I have quite a few and new releases
> >>> can become painful!)
> >>>
> >>> gcc/ChangeLog
> >>>
> >>> config.gcc (arm*-*-netbsdelf*) Add support for EABI configuration
> >>> config.host (arm*-*-netbsd*): Build driver-arm.o
> >>> config/arm/netbsd-eabi.h: New file.
> >>> config/arm/netbsd-elf.h
> >>> config/netbsd-elf.h: Define SUBTARGET_EXTRA_SPECS.
> >>>
> >>> libgcc/ChangeLog
> >>>
> >>> config.host (arm*-*-netbsdelf*): Add support for EABI configuration
> >>> config/arm/t-netbsd: LIB1ASMFUNCS: Append to existing set.
> >>>HOST_LIBGCC2_CFLAGS: workaround possible bug
> >>> config/arm/t-netbsd-eabi: New file.
> >> So we're well into stage4 which means technically it's too late for
> >> something like this.  However, given it's limited scope I won't object
> >> if the ARM port maintainers want to go forward.  Otherwise I'll queue 
> >> it
> >> for gcc-10.
> >>
> >> jeff
> >>
> >
> > I was about to approve this (modulo removing the now obsolete
> > FPU_DEFAULT macro), until I noticed that it also modifies the generic
> > NetBSD code as well.  I'm certainly not willing to approve that myself
> > at this late stage, but if one of the NetBSD OS maintainers wants to
> > step up and do so, I'll happily take the Arm back-end code as that's not
> > a primary or secondary target.
>  So is removal of the FPUTYPE_DEFAULT stuff all that's needed for this to
>  go forward now that Jason T has chimed in?
> 
>  jeff
> 
> 
> >>>
> >>> Very close.  I was just doing a last pass through the patch to make that
> >>> small edit when I noticed this in config/arm/netbsd-eabi.h:
> >>>
> >>>
> >>> #define SUBTARGET_EXTRA_ASM_SPEC  \
> >>>   "-matpcs ..."
> >>>
> >>> Why is the assembler unconditionally passed -matpcs for an eabi
> >>> configuration?  That sounds broken.
> >>>
> >>> R.
> >>>
> >>
> >>
> >> Looking at what GAS does with this flag, it simply causes the assembler
> >> to create an empty .arm.atpcs debug section.  On that basis, I would
> >> expect that it's then safe (and correct) to remove this: the EABI is not
> >> the ATPCS.
> >>
> >> R.
> >>
> > 
> > 
> > Finally, I need the names of the authors and their email addresses in a
> > format suitable for the ChangeLog file.  As far as I can tell, that means:
> > 
> > Yourself
> > Matt Thomas
> > Matthew Green
> > Nick Hudson
> > 
> > R.
> > 
> 
> Argh, there's a final issue.  We can't find a copyright assignment
> against your email address.  Do you have one?
> 
> R.

Unfortunately no :-(
How do I do it?

Re: [PATCH] netbsd EABI support

[coypu]

On Fri, May 10, 2019 at 11:44:28AM +0100, Richard Earnshaw (lists) wrote:
> I was hoping to get a comment from one of the netbsd port maintainers on
> the changes to the common NetBSD code.  Are they no-longer active?

Jason Thorpe said he can't contribute to GCC because of where he works.
Krister Walfridsson is slow to respond but does eventually and knows a
lot about GCC.

Re: [PATCH] netbsd EABI support

[coypu]

On Tue, Apr 09, 2019 at 05:36:47PM +0100, Richard Earnshaw (lists) wrote:
> > So we're well into stage4 which means technically it's too late for
> > something like this.  However, given it's limited scope I won't object
> > if the ARM port maintainers want to go forward.  Otherwise I'll queue it
> > for gcc-10.
> > 
> > jeff
> > 
> 
> I was about to approve this (modulo removing the now obsolete
> FPU_DEFAULT macro), until I noticed that it also modifies the generic
> NetBSD code as well.  I'm certainly not willing to approve that myself
> at this late stage, but if one of the NetBSD OS maintainers wants to
> step up and do so, I'll happily take the Arm back-end code as that's not
> a primary or secondary target.
> 
> R.

Congrats on a new release :-)
ping

[Bug target/90360] New: Missed optimization: unnecessary use of callee-saved registers

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90360

Bug ID: 90360
   Summary: Missed optimization: unnecessary use of callee-saved
registers
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

if I compile this code with -O3


typedef struct once_t {
int val;
int pto_done;
} once_t;

int
once_stub(once_t *o, void (*r)(void))
{

if (o->pto_done == 0) {
(*r)();
o->pto_done = 1;
}

return (0);
}


The output is:

once_stub(once_t*, void (*)()):
movl4(%rdi), %eax
testl   %eax, %eax
jne .L4
pushq   %rbx
movq%rdi, %rbx
call*%rsi
movl$1, 4(%rbx)
xorl%eax, %eax
popq%rbx
ret
.L4:
xorl%eax, %eax
ret



I think push/pop instructions won't be necessary if
another register besides rbx is picked.

[Bug c/448] -related issues (C99 issues)

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448

--- Comment #44 from coypu  ---
(In reply to jos...@codesourcery.com from comment #31)
> GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64), 

Speaking for NetBSD only:
as of https://gcc.gnu.org/viewcvs/gcc?view=revision=253323 , we
include netbsd-stdint.h for all netbsd targets.

[PATCH] netbsd EABI support

[coypu]

Pinging again in the hope of getting the patch in, I'd like to have
less outstanding patches :) (I have quite a few and new releases
can become painful!)

gcc/ChangeLog

config.gcc (arm*-*-netbsdelf*) Add support for EABI configuration
config.host (arm*-*-netbsd*): Build driver-arm.o
config/arm/netbsd-eabi.h: New file.
config/arm/netbsd-elf.h
config/netbsd-elf.h: Define SUBTARGET_EXTRA_SPECS.

libgcc/ChangeLog

config.host (arm*-*-netbsdelf*): Add support for EABI configuration
config/arm/t-netbsd: LIB1ASMFUNCS: Append to existing set.
 HOST_LIBGCC2_CFLAGS: workaround possible bug
config/arm/t-netbsd-eabi: New file.

---
 gcc/config.gcc  | 29 +-
 gcc/config.host |  2 +-
 gcc/config/arm/netbsd-eabi.h| 97 +
 gcc/config/arm/netbsd-elf.h | 10 
 gcc/config/netbsd-elf.h | 15 +
 libgcc/config.host  | 10 +++-
 libgcc/config/arm/t-netbsd  | 10 +++-
 libgcc/config/arm/t-netbsd-eabi | 18 ++
 8 files changed, 184 insertions(+), 7 deletions(-)
 create mode 100644 gcc/config/arm/netbsd-eabi.h
 create mode 100644 libgcc/config/arm/t-netbsd-eabi

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3ee31c5993d..736b2163a24 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1161,10 +1161,33 @@ arm*-*-freebsd*)# ARM FreeBSD EABI
with_tls=${with_tls:-gnu}
;;
 arm*-*-netbsdelf*)
-   tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h arm/aout.h 
${tm_file} arm/netbsd-elf.h"
-   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
-   tmake_file="${tmake_file} arm/t-arm"
target_cpu_cname="strongarm"
+   tmake_file="${tmake_file} arm/t-arm"
+   tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h"
+   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
+   case ${target} in
+   arm*eb-*) tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1" ;;
+   esac
+   case ${target} in
+   arm*-*-netbsdelf-*eabi*)
+   tm_file="$tm_file arm/bpabi.h arm/netbsd-elf.h arm/netbsd-eabi.h"
+   tmake_file="$tmake_file arm/t-bpabi arm/t-netbsdeabi"
+   ;;
+   *)
+   tm_file="$tm_file arm/netbsd-elf.h"
+   tmake_file="$tmake_file arm/t-netbsd"
+   ;;
+   esac
+   tm_file="${tm_file} arm/aout.h arm/arm.h"
+   case ${target} in
+   arm*-*-netbsdelf-*eabihf*)
+   tm_defines="${tm_defines} 
TARGET_DEFAULT_FLOAT_ABI=ARM_FLOAT_ABI_HARD"
+   ;;
+   esac
+   case ${target} in
+   armv6*) target_cpu_cname="arm1176jzf-s";;
+   armv7*) target_cpu_cname="generic-armv7-a";;
+   esac
;;
 arm*-*-linux-*)# ARM GNU/Linux with ELF
tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h 
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
diff --git a/gcc/config.host b/gcc/config.host
index 816a0f06cb7..5077c0ee33a 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -107,7 +107,7 @@ case ${host} in
;;
 esac
 ;;
-  arm*-*-freebsd* | arm*-*-linux* | arm*-*-fuchsia*)
+  arm*-*-freebsd* | arm*-*-netbsd* | arm*-*-linux* | arm*-*-fuchsia*)
 case ${target} in
   arm*-*-*)
host_extra_gcc_objs="driver-arm.o"
diff --git a/gcc/config/arm/netbsd-eabi.h b/gcc/config/arm/netbsd-eabi.h
new file mode 100644
index 000..13bc274175d
--- /dev/null
+++ b/gcc/config/arm/netbsd-eabi.h
@@ -0,0 +1,97 @@
+/* Definitions of target machine for GNU compiler, NetBSD/arm ELF version.
+   Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
+   Contributed by Wasabi Systems, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+/* Run-time Target Specification.  */
+#undef MULTILIB_DEFAULTS
+#define MULTILIB_DEFAULTS { "mabi=aapcs-linux" }
+
+#define TARGET_LINKER_EABI_SUFFIX \
+(TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_SOFT \
+ ? "%{!mabi=apcs-gnu:%{!mabi=atpcs:%{mfloat-abi=hard:_eabihf;:_eabi}}}" \
+ : "%{!mabi=apcs-gnu:%{!mabi=atpcs:%{mfloat-abi=soft:_eabi;:_eabihf}}}")
+#define TARGET_LINKER_BIG_EMULATION "armelfb_nbsd%(linker_eabi_suffix)"
+#define TARGET_LINKER_LITTLE_EMULATION "armelf_nbsd%(linker_eabi_suffix)"
+
+/* TARGET_BIG_ENDIAN_DEFAULT is set in
+   config.gcc for big endian configurations.  */
+#undef  

Re: [PATCH] claim ifunc support on several NetBSD architectures

[coypu]

Small addition for ARM. Since it doesn't have a geneirc way to detect
CPU features the code in libatomic relies on a linux-specific behaviour,
the ifunc condition is only defined for linux.

To unbreak compilation, I'd like to exclude netbsd/arm from the
libatomic ifunc camp :)

libatomic/ChangeLog:
* configure.tgt: Exclude arm*-*-netbsd* from try_ifunc.

diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index ecbb7d33cc1..4a1294bc1ff 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -53,7 +53,7 @@ case "${target_cpu}" in
   arm*)
ARCH=arm
case "${target}" in
-arm*-*-freebsd*)
+arm*-*-freebsd* | arm*-*-netbsd*)
 ;;
 *)
 # ??? Detect when -march=armv7 is already enabled.

[PATCH] claim ifunc support on several NetBSD architectures

[coypu]

architecture list from netbsd src/tests/libexec/ld.elf_so/t_ifunc.c
(quick reference: 
https://github.com/NetBSD/src/blob/trunk/tests/libexec/ld.elf_so/t_ifunc.c#L38 )
tested on netbsd/amd64.

ifuncs worked anyway, but I can't use target_clones without this change.
that is one very cool feature I'd like to use :)

gcc/ChangeLog:
2019-04-07  Maya Rashish
* config.gcc (default_gnu_indirect_function): Default to yes
for arm*-*-netbsd*, i[34567]86-*-netbsd*, powerpc*-*-netbsd*,
sparc*-*-netbsd*, x86_64-*-netbsd*


diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3eb2e800fc5..73debdde10f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -849,6 +849,11 @@ case ${target} in
   nbsd_tm_file="netbsd.h netbsd-stdint.h netbsd-elf.h"
   default_use_cxa_atexit=yes
   target_has_targetdm=yes
+  case ${target} in
+arm*-* | i[34567]86-* | powerpc*-* | sparc*-* | x86_64-*)
+  default_gnu_indirect_function=yes
+  ;;
+  esac
   ;;
 *-*-openbsd*)
   tmake_file="t-openbsd"

Re: syncing the GCC vax port

[coypu]

On Sun, Mar 31, 2019 at 01:25:50PM -0400, Paul Koning wrote:
> 
> 
> > On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote:
> > 
> > hi folks,
> > 
> > i was interesting in tackling some problems gcc netbsd/vax has.
> > it has some ICEs which are in reload phase. searching around, the answer
> > to that is "switch to LRA first". Now, I don't quite know what that is
> > yet, but I know I need to try to do it.
> 
> That's not quite the whole story.
> 
> The answer is (1) switch from CC0 to CCmode condition code handling, which 
> enables (2) switch from Reload to LRA.
> 
> (1) requires actual work, not terribly hard but not entirely trivial.  (2) 
> may take as little as switching the "use LRA" flag to "yes".
> 
> I did (1) as well as a tentative (2) for pdp11 last year.  It was reasonably 
> straightforward thanks to a pile of help from Eric Botcazou and his gcc wiki 
> articles on the subject.  You might find the pdp11 deltas for CCmode helpful 
> as a source of ideas, since the two machines have a fair amount in common as 
> far as condition codes goes.  At least for the integer ops (pdp11 has 
> separate floating point conditions, vax doesn't).
> 
>   paul
> 

Hi paul!

I have been reading on this, so now I have a draft that compiles the
world's simplest C code (and nothing more, it will crash), but using
CCmode (I think).

I am being inspired by your port (which is a good thing since I know I
can ask questions about it :))

https://github.com/coypoop/gcc/commit/df135c019de33950c9997fdea3ce07c5c920384d

(I know that it's wrong!)

[PATCH, wwwdocs] Update on existence of free emulators for alpha, VAX

[coypu]

As far as I can tell, alpha can be emulated by QEMU.
VAX has SIMH. (Perhaps I should mention it somewhere? :))

Index: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.84
diff -u -r1.84 backends.html
--- backends.html   18 Jan 2019 11:52:12 -  1.84
+++ backends.html   31 Mar 2019 08:00:23 -
@@ -69,7 +69,7 @@
 Target | HMSLQNFICBD lqrcpbfmgiates
 ---+---
 aarch64| Qq   b  gia  s
-alpha  |  ?? Q   Cq mgi  e
+alpha  |  ?  Q   Cq mgi  e
 arc|  B   b  gia
 arm|  b   ia  s
 avr|L  FIl  cp   g
@@ -116,7 +116,7 @@
 tilegx |   S Q   Cq  gi  e
 tilepro|   S   F C   gi  e
 v850   | g a  s
-vax|  M?I   c b   i  e
+vax|  M I   c b   i  e
 visium |  B  g  t s
 xtensa | C
 

syncing the GCC vax port

[coypu]

hi folks,

i was interesting in tackling some problems gcc netbsd/vax has.
it has some ICEs which are in reload phase. searching around, the answer
to that is "switch to LRA first". Now, I don't quite know what that is
yet, but I know I need to try to do it.

As an initial step, I need to sync the source code.
netbsd/vax has some outstanding work on GCC.

I've done this, and I can run programs built by this compiler:
http://coypu.sdf.org/gcc-9-vax.diff

(My tree has more detail on the changes done:
https://github.com/gcc-mirror/gcc/compare/master...coypoop:vax )

Matt Thomas (the GCC VAX maintainer) is the author of most of these
changes, I suspect he will not be very responsive by email.
Not being the author, I might not be able to answer all the questions,
but I can try my best.

How do I get this across? comments? straight to gcc-patches? :-)

I know Jeff Law did not like the change to builtins.md as being wrong. I
can omit them, I forgot about it until typing this email :)

caveat: had an ICE during reload in the build process, I hid it
under the rug with -O0.

Re: [PATCH] bring netbsd/arm support up to speed. eabi, etc.

[coypu]

More pings!

On Fri, Mar 08, 2019 at 09:56:05AM +, co...@sdf.org wrote:
> Ping.
> 
> Link for possible convenience :-)
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01899.html

Re: [PATCH] bring netbsd/arm support up to speed. eabi, etc.

[coypu]

Ping.

Link for possible convenience :-)
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01899.html

Re: [PATCH] bring netbsd/arm support up to speed. eabi, etc.

[coypu]

Pinging with updated patch.
I removed a conflict with copyright year change. No longer using
unwind-arm (we use dwarf on eabi).

I re-tested cross compilation and resulting C and C++ works (caveat:
with text relocations, i tested small programs)
I believe matt #2 (green) has sent a copyright assignment.

Changelog:
gcc:

config.gcc (arm*-*-netbsdelf*) Add support for EABI configuration
config.host (arm*-*-netbsd*): Build driver-arm.o
config/arm/netbsd-eabi.h: New file.
config/arm/netbsd-elf.h
config/netbsd-elf.h: Define SUBTARGET_EXTRA_SPECS.

libgcc:

config.host (arm*-*-netbsdelf*): Add support for EABI configuration
config/arm/t-netbsd: LIB1ASMFUNCS: Append to existing set.
 HOST_LIBGCC2_CFLAGS: workaround possible bug
config/arm/t-netbsd-eabi: New file.

>From c138b94b036e1485ed71c57966894e80f84fea1a Mon Sep 17 00:00:00 2001
From: coypu 
Date: Wed, 31 Oct 2018 00:33:06 +0200
Subject: [PATCH 1/1] netbsd eabi

Now with:
armv4 isn't needed as a separate case, because strongarm is the
default for all netbsd. it makes no difference otherwise.

-mfpu=auto

cleaned up things as requested by richard earnshaw.

tested: armv6,7 hf.
---
 gcc/config.gcc  | 29 +-
 gcc/config.host |  2 +-
 gcc/config/arm/netbsd-eabi.h| 97 +
 gcc/config/arm/netbsd-elf.h | 10 
 gcc/config/netbsd-elf.h | 15 +
 libgcc/config.host  | 10 +++-
 libgcc/config/arm/t-netbsd  | 10 +++-
 libgcc/config/arm/t-netbsd-eabi | 18 ++
 8 files changed, 184 insertions(+), 7 deletions(-)
 create mode 100644 gcc/config/arm/netbsd-eabi.h
 create mode 100644 libgcc/config/arm/t-netbsd-eabi

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3ee31c5993d..736b2163a24 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1161,10 +1161,33 @@ arm*-*-freebsd*)# ARM FreeBSD EABI
with_tls=${with_tls:-gnu}
;;
 arm*-*-netbsdelf*)
-   tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h arm/aout.h 
${tm_file} arm/netbsd-elf.h"
-   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
-   tmake_file="${tmake_file} arm/t-arm"
target_cpu_cname="strongarm"
+   tmake_file="${tmake_file} arm/t-arm"
+   tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h"
+   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
+   case ${target} in
+   arm*eb-*) tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1" ;;
+   esac
+   case ${target} in
+   arm*-*-netbsdelf-*eabi*)
+   tm_file="$tm_file arm/bpabi.h arm/netbsd-elf.h arm/netbsd-eabi.h"
+   tmake_file="$tmake_file arm/t-bpabi arm/t-netbsdeabi"
+   ;;
+   *)
+   tm_file="$tm_file arm/netbsd-elf.h"
+   tmake_file="$tmake_file arm/t-netbsd"
+   ;;
+   esac
+   tm_file="${tm_file} arm/aout.h arm/arm.h"
+   case ${target} in
+   arm*-*-netbsdelf-*eabihf*)
+   tm_defines="${tm_defines} 
TARGET_DEFAULT_FLOAT_ABI=ARM_FLOAT_ABI_HARD"
+   ;;
+   esac
+   case ${target} in
+   armv6*) target_cpu_cname="arm1176jzf-s";;
+   armv7*) target_cpu_cname="generic-armv7-a";;
+   esac
;;
 arm*-*-linux-*)# ARM GNU/Linux with ELF
tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h 
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
diff --git a/gcc/config.host b/gcc/config.host
index 816a0f06cb7..5077c0ee33a 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -107,7 +107,7 @@ case ${host} in
;;
 esac
 ;;
-  arm*-*-freebsd* | arm*-*-linux* | arm*-*-fuchsia*)
+  arm*-*-freebsd* | arm*-*-netbsd* | arm*-*-linux* | arm*-*-fuchsia*)
 case ${target} in
   arm*-*-*)
host_extra_gcc_objs="driver-arm.o"
diff --git a/gcc/config/arm/netbsd-eabi.h b/gcc/config/arm/netbsd-eabi.h
new file mode 100644
index 000..13bc274175d
--- /dev/null
+++ b/gcc/config/arm/netbsd-eabi.h
@@ -0,0 +1,97 @@
+/* Definitions of target machine for GNU compiler, NetBSD/arm ELF version.
+   Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
+   Contributed by Wasabi Systems, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along wit

Re: [PATCH,GDC] Add netbsd support to GDC

[coypu]

On Wed, Jan 23, 2019 at 09:35:03AM +, co...@sdf.org wrote:
> > Is this necessary?  I'd prefer to not set this field if it can be
> > avoided.  The same goes for the others, I intend to remove them at
> > soonest convenience once the problematic parts of the front-end logic
> > has been abstracted away.
> > 
> > Other than that, looks reasonable to me.
> 
> It's not necessary. Here's an updated diff without it.
> I also forgot to add netbsd-d.c, which is referenced in the previous
> diff.

ping :-)
If it is good, can someone commit it? I don't have the ability to do so.

Re: [PATCH,GDC] Add netbsd support to GDC

[coypu]

(Oops, added the wrong email out of habit to the first reply :-))

On Tue, Jan 22, 2019 at 08:37:25PM +0100, Iain Buclaw wrote:
> > diff --git a/gcc/d/d-builtins.cc b/gcc/d/d-builtins.cc
> > index b0a315a3ed9..ca105c7635d 100644
> > --- a/gcc/d/d-builtins.cc
> > +++ b/gcc/d/d-builtins.cc
> > @@ -382,6 +382,8 @@ d_add_builtin_version (const char* ident)
> >  global.params.isWindows = true;
> >else if (strcmp (ident, "FreeBSD") == 0)
> >  global.params.isFreeBSD = true;
> > +  else if (strcmp (ident, "NetBSD") == 0)
> > +global.params.isNetBSD = true;
> >else if (strcmp (ident, "OpenBSD") == 0)
> >  global.params.isOpenBSD = true;
> >else if (strcmp (ident, "Solaris") == 0)
> 
> Is this necessary?  I'd prefer to not set this field if it can be
> avoided.  The same goes for the others, I intend to remove them at
> soonest convenience once the problematic parts of the front-end logic
> has been abstracted away.
> 
> Other than that, looks reasonable to me.

It's not necessary. Here's an updated diff without it.
I also forgot to add netbsd-d.c, which is referenced in the previous
diff.

libphobos/libdruntime changes were contributed upstream:
https://github.com/dlang/druntime/pull/2472
(caveat: pending a change to netbsd/execinfo.d)

gcc/config.gcc (*-*-netbsd*): add netbsd-d.o
gcc/config/t-netbsd: add netbsd-d.o
gcc/config/netbsd-d.c: New, define Posix and NetBSD builtins for NetBSD targets

gcc/d/d-system.h: NetBSD is POSIX
libphobos/configure.tgt: Mark netbsd/x86 as supported
---
 gcc/config.gcc  |  2 ++
 gcc/config/netbsd-d.c   | 41 +
 gcc/config/t-netbsd |  4 
 gcc/d/d-system.h|  3 ++-
 libphobos/configure.tgt |  2 ++
 5 files changed, 51 insertions(+), 1 deletion(-)
 create mode 100644 gcc/config/netbsd-d.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index a189cb19f63..c5d3044b017 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -839,6 +839,7 @@ case ${target} in
   tm_p_file="${tm_p_file} netbsd-protos.h"
   tmake_file="t-netbsd t-slibgcc"
   extra_objs="${extra_objs} netbsd.o"
+  d_target_objs="${d_target_objs} netbsd-d.o"
   gas=yes
   gnu_ld=yes
   use_gcc_stdint=wrap
@@ -847,6 +848,7 @@ case ${target} in
   esac
   nbsd_tm_file="netbsd.h netbsd-stdint.h netbsd-elf.h"
   default_use_cxa_atexit=yes
+  target_has_targetdm=yes
   ;;
 *-*-openbsd*)
   tmake_file="t-openbsd"
diff --git a/gcc/config/netbsd-d.c b/gcc/config/netbsd-d.c
new file mode 100644
index 000..8593f8bd430
--- /dev/null
+++ b/gcc/config/netbsd-d.c
@@ -0,0 +1,41 @@
+/* Functions for generic NetBSD as target machine for GNU D compiler.
+   Copyright (C) 2019 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "tree.h"
+#include "varasm.h"
+#include "netbsd-protos.h"
+#include "tm_p.h"
+#include "d/d-target.h"
+#include "d/d-target-def.h"
+
+static void
+netbsd_d_os_builtins (void)
+{
+  d_add_builtin_version ("Posix");
+  d_add_builtin_version ("NetBSD");
+}
+
+#undef TARGET_D_OS_VERSIONS
+#define TARGET_D_OS_VERSIONS netbsd_d_os_builtins
+
+struct gcc_targetdm targetdm = TARGETDM_INITIALIZER;
diff --git a/gcc/config/t-netbsd b/gcc/config/t-netbsd
index 4626e963ebf..716a94f86c6 100644
--- a/gcc/config/t-netbsd
+++ b/gcc/config/t-netbsd
@@ -19,3 +19,7 @@
 netbsd.o: $(srcdir)/config/netbsd.c
$(COMPILE) $<
$(POSTCOMPILE)
+
+netbsd-d.o: $(srcdir)/config/netbsd-d.c
+   $(COMPILE) $<
+   $(POSTCOMPILE)
diff --git a/gcc/d/d-system.h b/gcc/d/d-system.h
index cd59b827812..c32825d4ad1 100644
--- a/gcc/d/d-system.h
+++ b/gcc/d/d-system.h
@@ -24,7 +24,8 @@
 
 /* Used by the dmd front-end to determine if we have POSIX-style IO.  */
 #define POSIX (__linux__ || __GLIBC__ || __gnu_hurd__ || __APPLE__ \
-  || __FreeBSD__ || __OpenBSD__ || __DragonFly__ || __sun)
+  || __FreeBSD__ || __NetBSD__ || __OpenBSD__ || __DragonFly__ \
+  || __sun)
 
 /* Forward assert invariants to gcc_assert.  */
 #undef assert
diff --git a/libphobos/configure.tgt b/libphobos/configure.tgt
index 2b2a9746811..0471bfd816b 100644
--- a/libphobos/configure.tgt
+++ b/libphobos/configure.tgt
@@ -30,6 +30,8 @@ case "${target}" in
;;
   x86_64-*-linux* | i?86-*-linux*)
;;
+  x86_64-*-netbsd* | 

[Bug inline-asm/62144] "Frame pointer required, but reserved" error with -fomit-frame-pointer but only with -m32 -O2

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144

coypu  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #10 from coypu  ---
fyi, if you are considering this a bug, I can still reproduce it with trunk as
of gcc (GCC) 9.0.0 20181125

[Bug libstdc++/88421] compat C headers break building GCC with GCC

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421

--- Comment #5 from coypu  ---
(In reply to Jakub Jelinek from comment #4)
> That is one header, not two, so why should that fenv.h's #include_next
> include that same header or some copy of that header in a different path?

I am in the process of building libstdc++.

-I/tmp/build/shle--netbsdelf/libstdc++-v3/include

there's a libstdc++ fenv.h there

[Bug libstdc++/88421] compat C headers break building GCC with GCC

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421

--- Comment #3 from coypu  ---
include/c_compatibility/fenv.h

[Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794

--- Comment #4 from coypu  ---
Hi,

It's probably a setup/configuration issue for everyone reporting this issue.
It's hard to debug, my patch helps with figuring out the problem - but doesn't
fix it.

I didn't ping this bug report because I don't understand what the other patch
described here does.

[Bug libstdc++/88421] compat C headers break building GCC with GCC

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421

--- Comment #1 from coypu  ---
suggested change: put #include_next outside of include guards?

[Bug libstdc++/88421] New: compat C headers break building GCC with GCC

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421

Bug ID: 88421
   Summary: compat C headers break building GCC with GCC
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

I built GCC #1 (x86_64->sh3)
Now I'm trying to build GCC #2 (sh3->sh3) using GCC #1

during the build process,

libtool: compile:  shle--netbsdelf-c++ --sysroot=/home/fly/sh3/destdir.evbsh3/
-I/current/gcc/libstdc++-v3/../libgcc
-I/tmp/build/shle--netbsdelf/libstdc++-v3/include/shle--netbsdelf
-I/tmp/build/shle--netbsdelf/libstdc++-v3/include
-I/current/gcc/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=c++locale.lo -g -O2 -fimplicit-templates -c c++locale.cc  -fPIC
-DPIC -D_GLIBCXX_SHARED -o c++locale.o
mv -f .deps/list_read.Tpo .deps/list_read.Plo
In file included from
/home/fly/sh3/destdir.evbsh3/usr/include/evbsh3/ieeefp.h:3,
 from /home/fly/sh3/destdir.evbsh3/usr/include/ieeefp.h:12,
 from c++locale.cc:40:
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'fp_except
__FPE(int)':
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:62:13: error:
'FE_DIVBYZERO' was not declared in this scope
   62 |  if (__fe & FE_DIVBYZERO)
  | ^~~~
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:64:13: error:
'FE_INEXACT' was not declared in this scope
   64 |  if (__fe & FE_INEXACT)
  | ^~
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:66:13: error:
'FE_INVALID' was not declared in this scope; did you mean 'EINVAL'?
   66 |  if (__fe & FE_INVALID)
  | ^~
  | EINVAL
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:68:13: error:
'FE_OVERFLOW' was not declared in this scope; did you mean 'EOVERFLOW'?
   68 |  if (__fe & FE_OVERFLOW)
  | ^~~
  | EOVERFLOW
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:70:13: error:
'FE_UNDERFLOW' was not declared in this scope; did you mean 'UNDERFLOW'?
   70 |  if (__fe & FE_UNDERFLOW)
  | ^~~~
  | UNDERFLOW
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'int
__FEE(fp_except)':
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:81:11: error:
'FE_DIVBYZERO' was not declared in this scope
   81 |   __fe |= FE_DIVBYZERO;
  |   ^~~~
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:83:11: error:
'FE_INEXACT' was not declared in this scope
   83 |   __fe |= FE_INEXACT;
  |   ^~
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:85:11: error:
'FE_INVALID' was not declared in this scope; did you mean 'EINVAL'?
   85 |   __fe |= FE_INVALID;
  |   ^~
  |   EINVAL
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:87:11: error:
'FE_OVERFLOW' was not declared in this scope; did you mean 'EOVERFLOW'?
   87 |   __fe |= FE_OVERFLOW;
  |   ^~~
  |   EOVERFLOW
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:89:11: error:
'FE_UNDERFLOW' was not declared in this scope; did you mean 'UNDERFLOW'?
   89 |   __fe |= FE_UNDERFLOW;
  |   ^~~~
  |   UNDERFLOW
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'fp_rnd
__FPR(int)':
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:98:7: error:
'FE_TONEAREST' was not declared in this scope
   98 |  case FE_TONEAREST:
  |   ^~~~
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:100:7: error:
'FE_DOWNWARD' was not declared in this scope
  100 |  case FE_DOWNWARD:
  |   ^~~
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:102:7: error: 'FE_UPWARD'
was not declared in this scope
  102 |  case FE_UPWARD:
  |   ^
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:104:7: error:
'FE_TOWARDZERO' was not declared in this scope
  104 |  case FE_TOWARDZERO:
  |   ^
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'int
__FER(fp_rnd)':
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:117:10: error:
'FE_TONEAREST' was not declared in this scope
  117 |   return FE_TONEAREST;
  |  ^~~~
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:119:10: error:
'FE_DOWNWARD' was not declared in this scope
  119 |   return FE_DOWNWARD;
  |  ^~~
/home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:121:10: error:
'FE_UPWARD' was not declared in this scope
  121 |   return FE_UPWARD;
  |  ^
/home/

[PATCH] Provide early warning about configure failure

[coypu]

Hi folks,

I was bitten by this, and it seemed like a few people online had similar
issues (for example https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794).

We run a configure script from another configure script, to generate 
auto-build.h.
Secondary configure might fail.
This failure isn't fatal, and we continue running a configure script.
The output is obscured by a lot of configure messages.
We fail later auto-build.h not existing.

I added a test to see if making auto-build.h succeeded and fail & warn
otherwise. As an added bonus, it means the secondary configure
config.log stays around to inspect.

Let me know what you think.
configure.ac: Fail early if creating auto-build.h fails
configure: regen

---
 gcc/configure| 8 ++--
 gcc/configure.ac | 4 
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index dc4298097..5bf4b2954 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -11893,6 +11893,10 @@ else
--enable-languages=${enable_languages-all} \
--target=$target_alias --host=$build_alias --build=$build_alias
 
+   if test ! -f auto-host.h ; then
+   as_fn_error $? "Failed to generate build configuration" 
"$LINENO" 5
+   fi
+
# We just finished tests for the build machine, so rename
# the file auto-build.h in the gcc directory.
mv auto-host.h ../auto-build.h
@@ -18572,7 +18576,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18575 "configure"
+#line 18579 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -18678,7 +18682,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18681 "configure"
+#line 18685 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 2a1f3bb39..5f05ab8da 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1740,6 +1740,10 @@ else
--enable-languages=${enable_languages-all} \
--target=$target_alias --host=$build_alias --build=$build_alias
 
+   if test ! -f auto-host.h ; then
+   AC_MSG_ERROR([Failed to generate build configuration])
+   fi
+
# We just finished tests for the build machine, so rename
# the file auto-build.h in the gcc directory.
mv auto-host.h ../auto-build.h
-- 
2.19.1

[Bug c++/88194] can

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88194

coypu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from coypu  ---
sorry, clicked too many buttons:-)

[Bug c++/88194] New: can

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88194

Bug ID: 88194
   Summary: can
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570

coypu  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #16 from coypu  ---
well, the workaround only works for x86 and powerpc.
Other archs are not calling SUBTARGET_INIT_BUILTINS.
I'm not sure whether that should be grounds for keeping the ticket open,
though.

[PATCH] Fix PIE on netbsd (PR target/87221)

[coypu]

Re-sending because my patch doesn't seem to appear on the archive


This matches to what netbsd is doing with its own copy of GCC,
it can be simpler.

PR target/87221:
config/netbsd-elf.h (NETBSD_STARTFILE_SPEC): use crtbeginS.o for PIE
(NETBSD_ENDFILE_SPEC): use crtendS.o for PIE

---
 gcc/config/netbsd-elf.h | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/gcc/config/netbsd-elf.h b/gcc/config/netbsd-elf.h
index 4dc2aa757..26e5d996e 100644
--- a/gcc/config/netbsd-elf.h
+++ b/gcc/config/netbsd-elf.h
@@ -40,8 +40,11 @@ along with GCC; see the file COPYING3.  If not see
%{!p:crt0%O%s}}}\
%:if-exists(crti%O%s)   \
%{static:%:if-exists-else(crtbeginT%O%s crtbegin%O%s)} \
-   %{!static: \
- %{!shared:crtbegin%O%s} %{shared:crtbeginS%O%s}}"
+   %{!static:   \
+ %{!shared: \
+   %{!pie:crtbegin%O%s} \
+   %{pie:crtbeginS%O%s}}\
+ %{shared:crtbeginS%O%s}}"
 
 #undef STARTFILE_SPEC
 #define STARTFILE_SPEC NETBSD_STARTFILE_SPEC
@@ -52,7 +55,10 @@ along with GCC; see the file COPYING3.  If not see
C++ file-scope static objects deconstructed after exiting "main".  */
 
 #define NETBSD_ENDFILE_SPEC\
-  "%{!shared:crtend%O%s} %{shared:crtendS%O%s} \
+  "%{!shared:   \
+%{!pie:crtend%O%s}  \
+%{pie:crtendS%O%s}} \
+   %{shared:crtendS%O%s}\
%:if-exists(crtn%O%s)"
 
 #undef ENDFILE_SPEC
-- 
2.19.1

Re: [PATCH v2] bring netbsd/arm support up to speed. eabi, etc.

[coypu]

On Fri, Nov 02, 2018 at 11:04:06AM +, Richard Earnshaw (lists) wrote:
> Sorry about that.  You don't really expect me to remember every patch I
> committed 18 years ago!
> 
> And pedantically, that was a branch merge patch.  The original commit
> (back in the CVS days) was:
> 
> 
>   revision 1.9.2.1
>   date: 1999/10/25 17:47:02;  author: [redacted];  state: Exp;  lines:
> +34 -10
>   Initial check in of merged arm/thumb backend.
> 
> However, the age of this makes me suspect that it quite likely is not
> relevant any more and that we should investigate whether it is safe to
> remove.  We're running some tests here, but can you test the NetBSD port
> without that as well for another data point?

I thought it's funny, sorry :-)
netbsd seems to only do this for OABI (and defaults to EABI).
I tried it anyway on netbsd's mutant GCC 6.4 and ran a full userland with
it. It works really well!
I'm surprised I can run code that file identifies as "ARMv1" on a machine
that can run Aarch64.

Re: [PATCH v2] bring netbsd/arm support up to speed. eabi, etc.

[coypu]

On Wed, Oct 31, 2018 at 03:23:27PM +, Richard Earnshaw (lists) wrote:
> On 31/10/2018 14:10, co...@sdf.org wrote:
> > +
> > +# Currently there is a bug somewhere in GCC's alias analysis
> > +# or scheduling code that is breaking _fpmul_parts in fp-bit.c.
> > +# Disabling function inlining is a workaround for this problem.
> > +HOST_LIBGCC2_CFLAGS += -fno-inline
> 
> This needs to be investigated properly (and fixed if it's still a problem).
> 
> R.

After some VCS digging, it turns out you committed this change:
https://github.com/gcc-mirror/gcc/commit/cffb2a26c44c682185b6bb405d48fcbe1fbc0b37

NetBSD copied it over from existing GCC files, and it still exists in
GCC trunk, in libgcc/config/arm/t-elf.

[PATCH v2] bring netbsd/arm support up to speed. eabi, etc.

[coypu]

Thanks for the feedback. I made some improvements.
Changes from the first patch:

config.gcc:
need_64bit_hwint=yes No longer needed
resolve conflict from strongarm being default for netbsd.
switch default cpu for armv7--netbsdelf-eabi: cortex-a8 -> generic-armv7-a,
(make -mfpu=auto pick VFPv3-D16)
remove redundant extra configuration for armv4, all it did was pick
strongarm as the default CPU, and now it is the default CPU for all
arm*-*-netbsdelf*.
(This means there is no natural place to rule out armv4-eabihf configurations,
so I didn't add it - do we still want it?)


config/arm/netbsd-eabi.h:
remove BE8_LINK_SPEC, not needed any more
remove SUBTARGET_ASM_FLOAT_SPEC, handled by generic ARM code better,
with -mfpu=auto

config/arm/netbsd-elf.h:
don't define FPUTYPE_DEFAULT, it's unused.
remove CTOR_LISTS_DEFINED_EXTERNALLY definition, it's unused.



Some things that I am still conflicted about:
- I get the libgcc_s.so mismatch on native builds. This wasn't a problem
  in a previous attempt against gcc-7, I haven't pinned down why yet.
- there's duplicate logic for picking default CPU in
gcc/config/arm/netbsd-elf.h
- CTOR_LISTS_DEFINED_EXTERNALLY does nothing now, but I'm not sure
we actually didn't need it.
- I didn't add HOST_LIBGCC2_CFLAGS, I'll have to do some
investigation why it was put in place.


changelog entries (I assume that they need to be split out like
this)

gcc:

config.gcc (arm*-*-netbsdelf*) Add support for EABI configuration
config.host (arm*-*-netbsd*): Build driver-arm.o
config/arm/netbsd-eabi.h: New file.
config/arm/netbsd-elf.h
config/netbsd-elf.h: Define SUBTARGET_EXTRA_SPECS.

libgcc:

config.host (arm*-*-netbsdelf*): Add support for EABI configuration
config/arm/t-netbsd: LIB1ASMFUNCS: Append to existing set.
 HOST_LIBGCC2_CFLAGS: workaround possible bug
config/arm/t-netbsd-eabi: New file.

---
 gcc/config.gcc  | 29 +-
 gcc/config.host |  2 +-
 gcc/config/arm/netbsd-eabi.h| 97 +
 gcc/config/arm/netbsd-elf.h |  1 +
 gcc/config/netbsd-elf.h | 15 +
 libgcc/config.host  | 11 +++-
 libgcc/config/arm/t-netbsd  | 15 -
 libgcc/config/arm/t-netbsd-eabi | 18 ++
 8 files changed, 181 insertions(+), 7 deletions(-)
 create mode 100644 gcc/config/arm/netbsd-eabi.h
 create mode 100644 libgcc/config/arm/t-netbsd-eabi

diff --git a/gcc/config.gcc b/gcc/config.gcc
index b108697cf..10e2477c6 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1155,10 +1155,33 @@ arm*-*-freebsd*)# ARM FreeBSD EABI
with_tls=${with_tls:-gnu}
;;
 arm*-*-netbsdelf*)
-   tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h arm/aout.h 
${tm_file} arm/netbsd-elf.h"
-   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
-   tmake_file="${tmake_file} arm/t-arm"
target_cpu_cname="strongarm"
+   tmake_file="${tmake_file} arm/t-arm"
+   tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h"
+   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
+   case ${target} in
+   arm*eb-*) tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1" ;;
+   esac
+   case ${target} in
+   arm*-*-netbsdelf-*eabi*)
+   tm_file="$tm_file arm/bpabi.h arm/netbsd-elf.h arm/netbsd-eabi.h"
+   tmake_file="$tmake_file arm/t-bpabi arm/t-netbsdeabi"
+   ;;
+   *)
+   tm_file="$tm_file arm/netbsd-elf.h"
+   tmake_file="$tmake_file arm/t-netbsd"
+   ;;
+   esac
+   tm_file="${tm_file} arm/aout.h arm/arm.h"
+   case ${target} in
+   arm*-*-netbsdelf-*eabihf*)
+   tm_defines="${tm_defines} 
TARGET_DEFAULT_FLOAT_ABI=ARM_FLOAT_ABI_HARD"
+   ;;
+   esac
+   case ${target} in
+   armv6*) target_cpu_cname="arm1176jzf-s";;
+   armv7*) target_cpu_cname="generic-armv7-a";;
+   esac
;;
 arm*-*-linux-*)# ARM GNU/Linux with ELF
tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h 
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
diff --git a/gcc/config.host b/gcc/config.host
index c65569da2..59208d250 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -107,7 +107,7 @@ case ${host} in
;;
 esac
 ;;
-  arm*-*-freebsd* | arm*-*-linux* | arm*-*-fuchsia*)
+  arm*-*-freebsd* | arm*-*-netbsd* | arm*-*-linux* | arm*-*-fuchsia*)
 case ${target} in
   arm*-*-*)
host_extra_gcc_objs="driver-arm.o"
diff --git a/gcc/config/arm/netbsd-eabi.h b/gcc/config/arm/netbsd-eabi.h
new file mode 100644
index 0..13bc27417
--- /dev/null
+++ b/gcc/config/arm/netbsd-eabi.h
@@ -0,0 +1,97 @@
+/* Definitions of target machine for GNU compiler, NetBSD/arm ELF version.
+   Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
+   Contributed by Wasabi Systems, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it 

Re: [PATCH] bring netbsd/arm support up to speed. eabi, etc.

[coypu]

Thanks for the detailed response.
Sorry to give only a partial reply.

On Tue, Oct 23, 2018 at 02:36:57PM +0100, Richard Earnshaw (lists) wrote:
> Thanks for posting this.  Before we can commit it, however, we need to
> sort out the authorship and ensure that all the appropriate copyright
> assignments are in place.  Are you the sole author, or are other NetBSD
> developers involved?

The authors of these patches to netbsd are:
- matt thomas
- nick hudson
- matthew green

They are all listed in MAINTAINERS files in FSF projects so I think they
have a copyright assignment on file.
Matt Thomas is unresponsive lately but I can ask someone to bug him in
person.

> > +/* Default to full VFP if -mhard-float is specified.  */
> > +#undef SUBTARGET_ASM_FLOAT_SPEC
> > +#define SUBTARGET_ASM_FLOAT_SPEC   \
> > +  "%{mhard-float:%{!mfpu=*:-mfpu=vfp}}   \
> > +   %{mfloat-abi=hard:%{!mfpu=*:-mfpu=vfp}}"
> 
> Please rework this to use -mfpu=auto.  -mfpu=vfp is very rarely the
> right setting to use.

This change seems scary. Going over my default CPUs, I guess the
problematic one might cortex-a8.
I'm worried it might have negative repercussions for VFPv3-d16.
Is that a valid concern?
I see generic-armv7-a is a more popular default CPU, but I am not sure
from reading the code that it avoids this problem.

Thanks.

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383

--- Comment #14 from coypu  ---
Also, after these two patches, my own build of arm--netbsdelf is failing from
this:
configure: error: Pthreads are required to build libgomp

Looking at config.log, the error is actually:
configure:15118: /tmp/build/./gcc/xgcc -B/tmp/build/./gcc/
-B/usr/local/arm--netbsdelf/bin/ -B/usr/local/arm--netbsdelf/lib/ -isystem
/usr/local/arm--netbsdelf/include -isystem
/usr/local/arm--netbsdelf/sys-include --sysroot=/home/fly/shark/destdir.shark/ 
 -o conftest -g -O2   conftest.c -lpthread  >&5
/home/fly/shark/destdir.shark/usr/lib/libpthread.so: undefined reference to
`__modsi3@GCC_3.0'
collect2: error: ld returned 1 exit status

I'm not sure what is the cause of that.

Re: [PATCH] Default to an ARM cpu that exists

[coypu]

On Mon, Oct 22, 2018 at 03:56:24PM +0100, Richard Earnshaw (lists) wrote:
> I think strongarm would be a better choice.  I'm not aware of anyone
> running NetBSD on Arm8 cpus.
> 
> Otherwise, this is fine with a suitable ChangeLog entry.
> 
> R.

I hope this is OK. Thanks!

Maya Rashish  

PR target/86383
* config.gcc (arm*-*-*): Change default -mcpu to strongarm.


diff --git a/gcc/config.gcc b/gcc/config.gcc
index 720e6a737..23e2e85c8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3987,7 +3987,7 @@ case "${target}" in
TM_MULTILIB_CONFIG="$with_multilib_list"
fi
fi
-   target_cpu_cname=${target_cpu_cname:-arm6}
+   target_cpu_cname=${target_cpu_cname:-strongarm}
with_cpu=${with_cpu:-$target_cpu_cname}
;;
 

Re: [PATCH] Default to an ARM cpu that exists

[coypu]

On Mon, Oct 22, 2018 at 03:56:24PM +0100, Richard Earnshaw (lists) wrote:
> I think strongarm would be a better choice.  I'm not aware of anyone
> running NetBSD on Arm8 cpus.

Clarifying: this is the global default for all GCC ARM targets,
not just netbsd. Is strongarm still the preferred choice?

Thanks.

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383

--- Comment #13 from coypu  ---
I sent this to gcc-patches
for netbsd/eabi and stop picking arm6 -mcpu for oabi too:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01256.html
for all of arm to stop defaulting to non-existent -mcpu=arm6:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01262.html

[PATCH] Default to an ARM cpu that exists

[coypu]

Regarding target/86383, it wasn't sufficient to not just pick arm6 for
netbsd, as the default -mcpu is still arm6, which also fails to build.

I assume the default is expected to be the oldest support, and I think
now that's arm8, so maybe default to that.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 720e6a737..278c48287 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3987,7 +3987,7 @@ case "${target}" in
TM_MULTILIB_CONFIG="$with_multilib_list"
fi
fi
-   target_cpu_cname=${target_cpu_cname:-arm6}
+   target_cpu_cname=${target_cpu_cname:-arm8}
with_cpu=${with_cpu:-$target_cpu_cname}
;;
 

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383

--- Comment #12 from coypu  ---
to clarify, I still had trouble building oabi, but it fails elsewhere now.

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383

--- Comment #11 from coypu  ---
That cross builds with trunk.
For attempting to build oabi it wasn't enough to not specify
target_cpu_cname=arm6, because the default cpu is still arm6.
in gcc/config.gcc:3989 right now
target_cpu_cname=${target_cpu_cname:-arm6}

maybe that needs to be arm8 or something?

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383

--- Comment #10 from coypu  ---
Created attachment 44836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44836=edit
netbsd eabi support

Re: [PATCH] Fix extra parens in config/tls.m4

[coypu]

On Sun, Sep 16, 2018 at 01:00:21PM +0200, Andreas Schwab wrote:
> On Sep 03 2018, co...@sdf.org wrote:
> 
> > config/tls.m4: Remove extra parentheses
> 
> There are no extra parentheses.
> 

For the benefit of the discussion, I've added the more minimal version
of the patch.

This is a weird configure test because of the parens. It's not wrong
because its wrongness is compensated for later. So maybe it's a matter
of opinion.

But probably this is the intended generated autoconf output.
diff --git a/config/tls.m4 b/config/tls.m4
index 4e170c8d6ae..b9b363d8a80 100644
--- a/config/tls.m4
+++ b/config/tls.m4
@@ -104,7 +104,7 @@ AC_DEFUN([GCC_CHECK_CC_TLS], [
 gcc_cv_have_cc_tls, [
 AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
   [gcc_cv_have_cc_tls=yes], [gcc_cv_have_cc_tls=no])]
-)])
+)
   if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
 AC_DEFINE(HAVE_CC_TLS, 1,
  [Define to 1 if the target assembler supports thread-local 
storage.])
diff --git a/libgcc/configure b/libgcc/configure
index 79068536175..8ccb700da0f 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -5304,6 +5304,11 @@ rm -f core conftest.err conftest.$ac_objext 
conftest.$ac_ext
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_have_cc_tls" >&5
 $as_echo "$gcc_cv_have_cc_tls" >&6; }
+  if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
+
+$as_echo "#define HAVE_CC_TLS 1" >>confdefs.h
+
+  fi
 set_have_cc_tls=
 if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
   set_have_cc_tls="-DHAVE_CC_TLS"

Re: [PATCH] Fix extra parens in config/tls.m4

[coypu]

ping.
I can provide a less scary patch to correct the typo if people are
afraid of the cleanup changes.

[Bug target/87221] cannot build with -pie

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221

--- Comment #3 from coypu  ---
I think the change in bug 81523 to make -static imply no PIE might be wrong, as
static PIE is a thing.
It might be more right to limit that change only for configurations that don't
support static PIE.

[Bug target/87221] cannot build with -pie

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221

--- Comment #2 from coypu  ---
(In reply to Andrew Pinski from comment #1)
> This is related to bug 81523.  How did you configure GCC?

Configured with nothing related to default pie:

export ac_cv_func_freelocale=no
export ac_cv_func_newlocale=no
export ac_cv_func_uselocale=no
./configure --disable-nls --with-system-zlib MAKEINFO=/usr/pkg/bin/makeinfo

[Bug c/87221] New: cannot build with -pie

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221

Bug ID: 87221
   Summary: cannot build with -pie
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

With any example code,

> /usr/local/bin/gcc -pie -fpie test2.c
/usr/bin/ld: /usr/local/lib/gcc/x86_64-unknown-netbsd8.99/9.0.0/crtbegin.o:
relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when
making a shared object
/usr/bin/ld: /usr/local/lib/gcc/x86_64-unknown-netbsd8.99/9.0.0/crtend.o:
relocation R_X86_64_32 against `.ctors' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status




The following patch seems to help, but I don't know why the problem doesn't
affect more people:

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 84738e76eaa..4906034555f 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -297,7 +297,7 @@ INTERNAL_CFLAGS = $(CFLAGS) $(LIBGCC2_CFLAGS)
$(HOST_LIBGCC2_CFLAGS) \
 CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
   $(NO_PIE_CFLAGS) -finhibit-size-directive -fno-inline -fno-exceptions \
   -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \
-  -fbuilding-libgcc -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
+  -fbuilding-libgcc -fPIC -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
   $(INHIBIT_LIBC_CFLAGS)

 # Extra flags to use when compiling crt{begin,end}.o.

[PATCH] Fix extra parens in config/tls.m4

[coypu]

Hi folks,
This typo meant that HAVE_CC_TLS wasn't added to confdefs.h.

We run a potentially questionable setup where we save the results of
running configure for every architecture and then use it in subsequent
builds for reliability.

the addition of -DHAVE_CC_TLS wasn't saved to confdefs, so that's how
we got a bug: https://gnats.netbsd.org/53567

I don't know if anyone else runs a similar setup, but it is a cleanup
and an overall improvement to the code, nevertheless.

Maya Rashish 

config/tls.m4: Remove extra parentheses
libgcc/configure.ac: Remove unnecessary logic for set_have_cc_tls
set_use_emutls, provided in confdefs.h
libgcc/configure: Regen
libgcc/Makefile.in: Remove extra logic for @set_have_cc_tls@
@set_use_emutls@, now provided by confdefs.h
diff --git a/config/tls.m4 b/config/tls.m4
index 4e170c8d6ae..b9b363d8a80 100644
--- a/config/tls.m4
+++ b/config/tls.m4
@@ -104,7 +104,7 @@ AC_DEFUN([GCC_CHECK_CC_TLS], [
 gcc_cv_have_cc_tls, [
 AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
   [gcc_cv_have_cc_tls=yes], [gcc_cv_have_cc_tls=no])]
-)])
+)
   if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
 AC_DEFINE(HAVE_CC_TLS, 1,
  [Define to 1 if the target assembler supports thread-local 
storage.])
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 0c5b264f717..84738e76eaa 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -291,7 +291,7 @@ override CFLAGS := $(filter-out -fprofile-generate 
-fprofile-use,$(CFLAGS))
 # will usually contain -g, so for the moment CFLAGS goes first.  We must
 # include CFLAGS - that's where multilib options live.
 INTERNAL_CFLAGS = $(CFLAGS) $(LIBGCC2_CFLAGS) $(HOST_LIBGCC2_CFLAGS) \
- $(INCLUDES) @set_have_cc_tls@ @set_use_emutls@
+ $(INCLUDES)
 
 # Options to use when compiling crtbegin/end.
 CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
diff --git a/libgcc/configure b/libgcc/configure
index 090e5484131..f71afa3de01 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -567,8 +567,6 @@ tm_defines
 tm_file
 tmake_file
 sfp_machine_header
-set_use_emutls
-set_have_cc_tls
 vis_hide
 real_host_noncanonical
 accel_dir_suffix
@@ -5304,11 +5302,11 @@ rm -f core conftest.err conftest.$ac_objext 
conftest.$ac_ext
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_have_cc_tls" >&5
 $as_echo "$gcc_cv_have_cc_tls" >&6; }
-set_have_cc_tls=
-if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
-  set_have_cc_tls="-DHAVE_CC_TLS"
-fi
+  if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
+
+$as_echo "#define HAVE_CC_TLS 1" >>confdefs.h
 
+  fi
 
 # See if we have emulated thread-local storage.
 
@@ -5340,11 +5338,6 @@ $as_echo "$gcc_cv_use_emutls" >&6; }
 $as_echo "#define USE_EMUTLS 1" >>confdefs.h
 
   fi
-set_use_emutls=
-if test "$enable_tls $gcc_cv_use_emutls" = "yes yes"; then
-  set_use_emutls="-DUSE_EMUTLS"
-fi
-
 
 
 
diff --git a/libgcc/configure.ac b/libgcc/configure.ac
index 9d0bbcaba86..91fcb321010 100644
--- a/libgcc/configure.ac
+++ b/libgcc/configure.ac
@@ -519,19 +519,9 @@ fi
 # gcc, which can't be used to build executable due to that libgcc
 # is yet to be built here.
 GCC_CHECK_CC_TLS
-set_have_cc_tls=
-if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
-  set_have_cc_tls="-DHAVE_CC_TLS"
-fi
-AC_SUBST(set_have_cc_tls)
 
 # See if we have emulated thread-local storage.
 GCC_CHECK_EMUTLS
-set_use_emutls=
-if test "$enable_tls $gcc_cv_use_emutls" = "yes yes"; then
-  set_use_emutls="-DUSE_EMUTLS"
-fi
-AC_SUBST(set_use_emutls)
 
 dnl Check if as supports AVX instructions.
 AC_DEFUN([LIBGCC_CHECK_AS_AVX], [

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383

coypu  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #5 from coypu  ---
(In reply to Richard Earnshaw from comment #2)
> I'm not sure how relevant the netbsd-elf port is these days.  I believe
> they've now moved onto an EABI based ABI.  But no GCC port of that has been
> contributed.

hi,

I have a big working patch for netbsd/arm eabi.
I didn't test it against trunk/clean it up yet.
(https://v4.freshbsd.org/commit/netbsd/pkgsrc/yfUHHZvopo2aGFGA)

can I assign this to myself?

Re: [PATCH 1/2] Untangle stddef.h a little

[coypu]

On Tue, Jun 19, 2018 at 03:31:55PM +, Joseph Myers wrote:
> On Sun, 4 Feb 2018, Maya Rashish wrote:
> 
> > Of the currently supported BSDs:
> > - FreeBSD, doesn't have ansi.h or define _MACHINE_ANSI_H anywhere
> > in its other headers since the long-gone 5.x release.
> > - OpenBSD, DragonflyBSD don't have ansi.h either.
> > - NetBSD, sole remaining with ansi.h
> > 
> > Replace all the ifdef macros to be ifdef __NetBSD__ as it's the
> > sole remaining user.
> > 
> > Whether it is appropriate to make per-OS choices here is debatable,
> > but this change allows for further future cleanup.
> > 
> > This enables using the headers on netbsd archs that use different
> > include guards for ansi.h, like ARM.
> 
> These two patches are OK, please commit.
> 
> (GCC officially removed support for FreeBSD versions before FreeBSD 5 with
> 
> r260852 | gerald | 2018-05-28 23:20:15 + (Mon, 28 May 2018) | 5 lines
> 
> * config.gcc: Identify FreeBSD 3.x and 4.x as unsupported.
> 
> * config/freebsd-spec.h (FBSD_LIB_SPEC): Only consider FreeBSD 5
> and later.
> 
> .)
> 

Hi! I have no commit access. 
Can someone commit it?

Thanks :-)

[Bug target/85905] cannot build for netbsd/alpha (with patch)

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85905

coypu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from coypu  ---
Committed in revision 261707.

Re: [PATCH, alpha] PR target/85095

[coypu]

Ping.
Anything else to do for this?

Thanks.

Re: [PATCH, alpha] PR target/85095

[coypu]

On Thu, May 24, 2018 at 01:32:17PM -0600, Jeff Law wrote:
> On 05/24/2018 01:17 PM, co...@sdf.org wrote:
> > On Thu, May 24, 2018 at 12:48:22PM -0600, Jeff Law wrote:
> >> On 05/24/2018 07:54 AM, Maya Rashish wrote:
> >>> Move linux-specific specfile definitions to linux.h
> >>> gcc/config/alpha/linux.h (STARTFILE_SPEC, ENDFILE_SPEC) move from 
> >>> alpha/elf.h
> >>> ---
> >>>  gcc/config/alpha/elf.h   | 26 --
> >>>  gcc/config/alpha/linux.h | 26 ++
> >>>  2 files changed, 26 insertions(+), 26 deletions(-)
> >> So is there going to be some kind of follow-up to fix freebsd, netbsd
> >> and openbsd which currently get their STARTFILE/ENDFILE from elf.h?
> >>
> >> jeff
> > 
> > I can try to fix openbsd soon, but freebsd dropped alpha in 2009.
> > How does gcc feel about me picking up patches from openbsd ports, their
> > package manager, that weren't written by myself?
> So ISTM we should deprecate freebsd alpha.
> 
> WRT picking up bits from others.  It'd really depend on their size and
> complexity -- I'd have to see them to be able to judge.  I'll review if
> you extract the necessary bits and submit them.
> 
> Jeff

- With the original patch
- Attached patch to update the specfile for openbsd from openbsd ports
(It is here: 
https://github.com/openbsd/ports/blob/master/lang/gcc/6/patches/patch-gcc_config_alpha_openbsd_h
 )
- Attached patch to recognise cross compilation for openbsd (from me)
- A violent hack of "borrowing" stdatomic.h from a newer GCC
- Disabling libssp

I can build trunk for openbsd--alpha.
>From 1387836d5af4150ea08b888a202f72c08909a32f Mon Sep 17 00:00:00 2001
From: Maya Rashish 
Date: Fri, 25 May 2018 01:26:01 +0300
Subject: [PATCH 1/2] Recognise cross compilation for openbsd

---
 libstdc++-v3/configure  | 2 +-
 libstdc++-v3/crossconfig.m4 | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 79eb18727ea..cb51a01feeb 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -66148,7 +66148,7 @@ fi
 done
 
 ;;
-  *-netbsd*)
+  *-netbsd* | *-openbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
 
 
diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index 669d87f7602..0dbfe4057bd 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -201,7 +201,7 @@ case "${host}" in
 AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 AC_CHECK_FUNCS(_wfopen)
 ;;
-  *-netbsd*)
+  *-netbsd* | *-openbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
 AC_SUBST(SECTION_FLAGS) 
 GLIBCXX_CHECK_LINKER_FEATURES
-- 
2.17.0

>From 164a025328b007fb73ccd4491bc7d6fc70b88f0d Mon Sep 17 00:00:00 2001
From: Maya Rashish 
Date: Fri, 25 May 2018 01:26:16 +0300
Subject: [PATCH 2/2] Update openbsd/alpha specfile.

Taken from OpenBSD ports
---
 gcc/config/alpha/openbsd.h | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/gcc/config/alpha/openbsd.h b/gcc/config/alpha/openbsd.h
index aa369d7630a..9f035150d8b 100644
--- a/gcc/config/alpha/openbsd.h
+++ b/gcc/config/alpha/openbsd.h
@@ -19,6 +19,28 @@ along with GCC; see the file COPYING3.  If not see
 
 /* Controlling the compilation driver.  */
 
+#undef TARGET_DEFAULT
+#define TARGET_DEFAULT \
+   (MASK_FPREGS | MASK_IEEE | MASK_IEEE_CONFORMANT)
+
+ #define LINK_SPEC \
+  "%{!shared:%{!nostdlib:%{!r*:%{!e*:-e __start \
+   %{shared:-shared} %{R*} \
+   %{static:-Bstatic} \
+   %{!static:-Bdynamic} \
+   %{rdynamic:-export-dynamic} \
+   %{assert*} \
+   %{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}"
+
+/* As an elf system, we need crtbegin/crtend stuff.  */
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC "\
+   %{!shared: %{pg:gcrt0%O%s} %{!pg:%{p:gcrt0%O%s} \
+   %{!p:%{!static:crt0%O%s} %{static:%{nopie:crt0%O%s} \
+   %{!nopie:rcrt0%O%s crtbegin%O%s} %{shared:crtbeginS%O%s}"
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC "%{!shared:crtend%O%s} %{shared:crtendS%O%s}"
+
 /* run-time target specifications */
 #define TARGET_OS_CPP_BUILTINS()   \
 do {   \
@@ -28,18 +50,27 @@ along with GCC; see the file COPYING3.  If not see
 
 /* Layout of source language data types.  */
 
-/* This must agree with  */
+/* This must agree with  */
 #undef SIZE_TYPE
 #define SIZE_TYPE "long unsigned int"
 
 #undef PTRDIFF_TYPE
 #define PTRDIFF_TYPE "long int"
 
+#undef INTMAX_TYPE
+#define INTMAX_TYPE "long long int"
+
+#undef UINTMAX_TYPE
+#define UINTMAX_TYPE "long long unsigned int"
+
 #undef WCHAR_TYPE
 #define WCHAR_TYPE "int"
 
 #undef WCHAR_TYPE_SIZE
 #define WCHAR_TYPE_SIZE 32
 
+#undef WINT_TYPE
+#define WINT_TYPE "int"
+
 
 #define LOCAL_LABEL_PREFIX "."
-- 
2.17.0

Re: [PATCH, alpha] PR target/85095

[coypu]

On Thu, May 24, 2018 at 12:48:22PM -0600, Jeff Law wrote:
> On 05/24/2018 07:54 AM, Maya Rashish wrote:
> > Move linux-specific specfile definitions to linux.h
> > gcc/config/alpha/linux.h (STARTFILE_SPEC, ENDFILE_SPEC) move from 
> > alpha/elf.h
> > ---
> >  gcc/config/alpha/elf.h   | 26 --
> >  gcc/config/alpha/linux.h | 26 ++
> >  2 files changed, 26 insertions(+), 26 deletions(-)
> So is there going to be some kind of follow-up to fix freebsd, netbsd
> and openbsd which currently get their STARTFILE/ENDFILE from elf.h?
> 
> jeff

I can try to fix openbsd soon, but freebsd dropped alpha in 2009.
How does gcc feel about me picking up patches from openbsd ports, their
package manager, that weren't written by myself?

Re: [PATCH] PR target/85904: Fix configure when cross compiling for netbsd

[coypu]

On Thu, May 24, 2018 at 06:31:25PM +0100, Jonathan Wakely wrote:
> On 24/05/18 16:14 +0100, Jonathan Wakely wrote:
> > On 24/05/18 13:14 +, co...@sdf.org wrote:
> > > In the past I was asked to post bugzilla patches here. I am doing this.
> > > It fixes a build failure.
> > > 
> > > PR target/85904
> > > libstdc++-v3/crossconfig.m4: test for aligned_alloc on netbsd
> > > libstdc++-v3/configure: Regenerate
> > > 
> > > Attached is patch.
> > 
> > Thanks for the patch. We made a similar fix for FreeBSD recently, so
> > I'll commit this for you.
> 
> For consistency with freebsd and mingw what I committed to trunk has
> the AC_CHECK_FUNCS at the end of the netbsd section. Could you check
> it still works please? (I'm unable to build a netbsd cross-compiler
> for some reason).

It works, thank you!

[Bug target/85905] New: cannot build for netbsd/alpha (with patch)

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85905

Bug ID: 85905
   Summary: cannot build for netbsd/alpha (with patch)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

Created attachment 44176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44176=edit
move linux specfile stuff to linux file.

when I build trunk I get in libgomp/config.log cannot create executables:

configure:3725: checking for C compiler default output file name
configure:3747: /tmp/build/./gcc/xgcc -B/tmp/build/./gcc/
-B/usr/local/alpha--netbsd/bin/ -B/usr/local/alpha--netbsd/lib/ -isystem
/usr/local/alpha--netbsd/include -isystem /usr/local/alpha--netbsd/sys-include
--sysroot=/home/fly/alpha/destdir.alpha/   -g -O2 -mieee   conftest.c  >&5
/home/fly/alpha/tooldir.NetBSD-8.99.17-amd64/alpha--netbsd/bin/ld: cannot find
crt1.o: No such file or directory
collect2: error: ld returned 1 exit status


I include two tm files that have effect on STARTFILE_SPEC definition.


alpha/elf.h:
#undef  STARTFILE_SPEC
#ifdef HAVE_LD_PIE
#define STARTFILE_SPEC \
  "%{!shared: %{pg|p:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}\
   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"

This is good for linux probably but I don't have crt1.o on netbsd.

netbsd-elf.h

#define NETBSD_STARTFILE_SPEC   \
  "%{!shared:   \
 %{pg:gcrt0%O%s}\
 %{!pg: \
   %{p:gcrt0%O%s}   \
   %{!p:crt0%O%s}}} \
   %:if-exists(crti%O%s)\
   %{static:%:if-exists-else(crtbeginT%O%s crtbegin%O%s)} \
   %{!static: \
 %{!shared:crtbegin%O%s} %{shared:crtbeginS%O%s}}"

#undef STARTFILE_SPEC
#define STARTFILE_SPEC NETBSD_STARTFILE_SPEC

This should work for all netbsd targets.

Attached is a patch to move alpha/elf.h definitions to linux.
I've previously sent it to gcc-patches but it didn't work so well. I'll resend.
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00887.html

I'm not very good at cross building and relying on netbsd's existing cross
tools to do these checks (binutils etc.). I don't know how to set it up for
openbsd, and they don't provide a similar toolchain. I have no alpha hardware
of my own but I tested this on someone's machine then.

[PATCH] PR target/85904: Fix configure when cross compiling for netbsd

[coypu]

In the past I was asked to post bugzilla patches here. I am doing this.
It fixes a build failure.

PR target/85904
libstdc++-v3/crossconfig.m4: test for aligned_alloc on netbsd
libstdc++-v3/configure: Regenerate

Attached is patch.
>From ac7a1f364b0ca5e3a6a5a68a16266d1cb78ee5da Mon Sep 17 00:00:00 2001
From: Maya Rashish 
Date: Thu, 24 May 2018 16:05:27 +0300
Subject: [PATCH 1/1] check for aligned_alloc on netbsd crosscompilation.

Fixes build issue:
/home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:62:1: error: 'void* 
aligned_alloc(std::size_t, std::size_t)' was declared 'extern' and later 
'static' [-fpermissive]
 aligned_alloc (std::size_t al, std::size_t sz)
 ^
In file included from /tmp/build/alpha--netbsd/libstdc++-v3/include/cstdlib:75,
 from /tmp/build/alpha--netbsd/libstdc++-v3/include/stdlib.h:36,
 from /home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:27:
/tmp/build/gcc/include-fixed/stdlib.h:254:7: note: previous declaration of 
'void* aligned_alloc(size_t, size_t)'
 void *aligned_alloc(size_t, size_t);
   ^
---
 libstdc++-v3/configure  | 13 +
 libstdc++-v3/crossconfig.m4 |  1 +
 2 files changed, 14 insertions(+)

diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index f3522ee..9fd6197169a 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -66150,6 +66150,19 @@ done
 ;;
   *-netbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
+for ac_func in aligned_alloc posix_memalign memalign _aligned_malloc
+do :
+  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
+ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
+eval as_val=\$$as_ac_var
+   if test "x$as_val" = x""yes; then :
+  cat >>confdefs.h <<_ACEOF
+#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+done
+
 
 
   # If we're not using GNU ld, then there's no point in even trying these
diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index f0a55c68404..dcc807eb76a 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -203,6 +203,7 @@ case "${host}" in
 ;;
   *-netbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
+AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 AC_SUBST(SECTION_FLAGS) 
 GLIBCXX_CHECK_LINKER_FEATURES
 AC_DEFINE(HAVE_FINITEF)
-- 
2.17.0

[Bug libstdc++/85904] New: configure issue cross compiling on netbsd, with patch

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85904

Bug ID: 85904
   Summary: configure issue cross compiling on netbsd, with patch
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

Created attachment 44175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44175=edit
Fixes configure for me

Out of the box (+3 patches I would like to get merged) I got:

/home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:62:1: error: 'void*
aligned_alloc(std::size_t, std::size_t)' was declared 'extern' and later
'static' [-fpermissive]
 aligned_alloc (std::size_t al, std::size_t sz)
 ^
In file included from /tmp/build/alpha--netbsd/libstdc++-v3/include/cstdlib:75,
 from
/tmp/build/alpha--netbsd/libstdc++-v3/include/stdlib.h:36,
 from /home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:27:
/tmp/build/gcc/include-fixed/stdlib.h:254:7: note: previous declaration of
'void* aligned_alloc(size_t, size_t)'
 void *aligned_alloc(size_t, size_t);
   ^


I took the liberty to modify configure following similar platform examples.
with the patches I can build trunk.
Yes I will also email it to gcc-patches.

[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401

--- Comment #1 from coypu  ---
Threw computing resources at the problem, so now I have an "offending" commit.
Before this commit, it doesn't segfault.
After, it does.

commit bbb9b536dd58015b5712a867954d34aae9d9dae5 (HEAD, refs/bisect/bad)
Author: thopre01 <thopre01@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Tue Jan 6 11:51:16 2015 +

2015-01-06  Thomas Preud'homme  <thomas.preudho...@arm.com>

gcc/
PR tree-optimization/63259
* tree-ssa-math-opts.c (pass_optimize_bswap::execute): Stop checking
if optab exists for 16bit byteswap.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219256
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/85401] New: segfault building code for VAX

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401

Bug ID: 85401
   Summary: segfault building code for VAX
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

Created attachment 43929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43929=edit
Reproduce test

build with the following flags fails:
  -O2 -fno-pic -c ip_icmp.i



here is a backtrace, from trunk as of April 14 2018.

Starting program: /home/fly/gcc/build/gcc/cc1 -fpreprocessed ip_icmp.i -quiet
-dumpbase ip_icmp.i -auxbase ip_icmp -O2 -fno-pic -o /var/tmp//ccO5AxRb.s
In file included from ../../../../sys/timevar.h:66,
 from ../../../../sys/time.h:307,
 from ../../../../sys/param.h:145,
 from ../../../../netinet/ip_icmp.c:103:
../../../../sys/systm.h:225:6: warning: conflicting types for built-in function
'printf' [-Wbuiltin-declaration-mismatch]
../../../../sys/systm.h:229:6: warning: conflicting types for built-in function
'vprintf' [-Wbuiltin-declaration-mismatch]
In file included from ../../../../netinet/ip_icmp.c:112:
../../../../sys/syslog.h:233:6: warning: conflicting types for built-in
function 'log' [-Wbuiltin-declaration-mismatch]

Program received signal SIGSEGV, Segmentation fault.
0x00bfd868 in allocno_copy_cost_saving (allocno=0x7e3c3e791190,
hard_regno=11) at ../../gcc/ira-color.c:2832
2832  cost += cp->freq *
ira_register_move_cost[allocno_mode][rclass][rclass];
1: rclass = ALL_REGS
2: allocno_mode = E_QImode
3: ira_register_move_cost[allocno_mode][rclass][rclass] = 
4: cp->freq = 36
5: ira_register_move_cost = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7e3c3ed98850,
0x7e3c3ed98850, 0x0 }
(gdb) bt full
#0  0x00bfd868 in allocno_copy_cost_saving (allocno=0x7e3c3e791190,
hard_regno=11) at ../../gcc/ira-color.c:2832
cost = 0
allocno_mode = E_QImode
rclass = ALL_REGS
cp = 0x7e3c3e511380
next_cp = 0x0
__FUNCTION__ = "allocno_copy_cost_saving"
#1  0x00bfdbb9 in improve_allocation () at ../../gcc/ira-color.c:2905
i = 2
j = 11
k = 11
n = 5
hregno = 11
conflict_hregno = 1
base_cost = 2232
class_size = 12
word = 1
nwords = 1
check = 3
spill_cost = 4068
min_cost = -594
nregs = 1
conflict_nregs = 1
r = 2
best = 10
try_p = true
aclass = ALL_REGS
mode = E_SImode
allocno_costs = 0x7e3c3e7313c8
costs = {-1740536, 40443, 0, 484, 552, 0, -2232, -2232, -2232, -2232,
-2232, 0, 1050933376, 32316, -1741856, 32639}
conflicting_regs = {18446744073709547521, 140187730799504}
profitable_hard_regs = 4032
a = 0x7e3c3e791190
bi = {elt1 = 0x7e3c3e7b1a90, elt2 = 0x0, word_no = 0, bits =
4611686018427387903}
__FUNCTION__ = "improve_allocation"
#2  0x00bfea51 in color_allocnos () at ../../gcc/ira-color.c:3201
i = 256
n = 32316
bi = {elt1 = 0x0, elt2 = 0x0, word_no = 2, bits = 0}
a = 0x7e3c3e799050
__FUNCTION__ = "color_allocnos"
#3  0x00bff13f in color_pass (loop_tree_node=0x7e3c3ed2fc00) at
../../gcc/ira-color.c:3310
regno = 32316
hard_regno = -1741504
index = -1
n = 81
cost = 0
exit_freq = 1048255088
enter_freq = 0
j = 256
bi = {elt1 = 0x0, elt2 = 0x0, word_no = 2, bits = 0}
mode = 32639
rclass = NO_REGS
aclass = (unknown: 33152352)
pclass = (ALL_REGS | LIM_REG_CLASSES | unknown: 9049864)
a = 0x7e3c3e799050
subloop_allocno = 0xb8
subloop_node = 0x7f7fffe56d20
__FUNCTION__ = "color_pass"
#4  0x00be8146 in ira_traverse_loop_tree (bb_p=false,
loop_node=0x7e3c3ed2fc00, 
preorder_func=0xbfef25 <color_pass(ira_loop_tree_node_t)>,
postorder_func=0x0) at ../../gcc/ira-build.c:1781
subloop_node = 0xbd6ab8 <ira_allocate_bitmap()+14>
__FUNCTION__ = "ira_traverse_loop_tree"
#5  0x00bffa0d in do_coloring () at ../../gcc/ira-color.c:3461
No locals.
#6  0x00c03501 in color () at ../../gcc/ira-color.c:4838
No locals.
#7  0x00c039d3 in ira_color () at ../../gcc/ira-color.c:4953
a = 0x7e3c3e799050
ai = {n = 172}
#8  0x00be30ff in ira (f=0x0) at ../../gcc/ira.c:5308
loops_p = true
ira_max_point_before_emit = 524288
saved_flag_caller_saves = true
saved_flag_ira_region = IRA_REGION_MIXED
__FUNCTION__ = "ira"
#9  0x00be3887 in (anonymous namespace)::pass_ira::execute
(this=0x7e3c3ed86bc0) at ../../gcc/ira.c:5606
No loca

Re: Internal compiler error building libstdc++ for vax

[coypu]

It turns out (all from krister, I am still totally lost) that it is not
failing for this specific reason in this case.

Rather, the attached patch from krister fixes it, saying that gcc
wants to change the label and then doesn't recognise the new insn
thinking the memory_operand predicate is not satisfied.
The new predicate is from rs6000.

In retrospect the most important thing to provide was the 4 line shell
script to reproduce the problem, I felt uneasy sharing that because it
is with netbsd's copy of GCC (which I know how to cross-build).

For the purpose of changing it to support a reversed pc/label_ref, I can
probably cargo-cult make it look like branch and make the square peg fit
in a round hole by a lot experimenting, but I don't understand the code
I have to be changing to do that.

There is this construct in the code that I don't understand why I want
to do anything like it, even if I can parse what the individual parts of
it mean:

 (set (zero_extract:SI (match_operand:QI 3 "memory_operand" "+0")
   (const_int 1)
   (match_dup 1))
  (const_int 1))])]

diff --git a/external/gpl3/gcc/dist/gcc/config/vax/builtins.md 
b/external/gpl3/gcc/dist/gcc/config/vax/builtins.md
index 7be1179..5fb6da6 100644
--- a/external/gpl3/gcc/dist/gcc/config/vax/builtins.md
+++ b/external/gpl3/gcc/dist/gcc/config/vax/builtins.md
@@ -77,13 +77,13 @@
   [(parallel
 [(set (pc)
  (if_then_else
-   (ne (zero_extract:SI (match_operand:QI 0 "memory_operand" "g")
+   (ne (zero_extract:SI (match_operand:QI 0 "volatile_mem_operand" "g")
 (const_int 1)
 (match_operand:SI 1 "general_operand" "nrm"))
(const_int 0))
(label_ref (match_operand 2 "" ""))
(pc)))
- (set (zero_extract:SI (match_operand:QI 3 "memory_operand" "+0")
+ (set (zero_extract:SI (match_operand:QI 3 "volatile_mem_operand" "+0")
   (const_int 1)
   (match_dup 1))
  (const_int 1))])]
@@ -94,13 +94,13 @@
   [(parallel
 [(set (pc)
  (if_then_else
-   (ne (zero_extract:SI (match_operand:HI 0 "memory_operand" "Q")
+   (ne (zero_extract:SI (match_operand:HI 0 "volatile_mem_operand" "Q")
 (const_int 1)
 (match_operand:SI 1 "general_operand" "nrm"))
(const_int 0))
(label_ref (match_operand 2 "" ""))
(pc)))
- (set (zero_extract:SI (match_operand:HI 3 "memory_operand" "+0")
+ (set (zero_extract:SI (match_operand:HI 3 "volatile_mem_operand" "+0")
   (const_int 1)
   (match_dup 1))
  (const_int 1))])]
@@ -111,13 +111,13 @@
   [(parallel
 [(set (pc)
  (if_then_else
-   (ne (zero_extract:SI (match_operand:SI 0 "memory_operand" "Q")
+   (ne (zero_extract:SI (match_operand:SI 0 "volatile_mem_operand" "Q")
 (const_int 1)
 (match_operand:SI 1 "general_operand" "nrm"))
(const_int 0))
(label_ref (match_operand 2 "" ""))
(pc)))
- (set (zero_extract:SI (match_operand:SI 3 "memory_operand" "+0")
+ (set (zero_extract:SI (match_operand:SI 3 "volatile_mem_operand" "+0")
   (const_int 1)
   (match_dup 1))
  (const_int 1))])]
diff --git a/external/gpl3/gcc/dist/gcc/config/vax/predicates.md 
b/external/gpl3/gcc/dist/gcc/config/vax/predicates.md
index 7344192..f68c3f4 100644
--- a/external/gpl3/gcc/dist/gcc/config/vax/predicates.md
+++ b/external/gpl3/gcc/dist/gcc/config/vax/predicates.md
@@ -109,3 +109,16 @@
(and (match_code "const_int,const_double,subreg,reg,mem")
(and (match_operand:DI 0 "general_operand" "")
 (not (match_operand:DI 0 "illegal_addsub_di_memory_operand")
+
+;; Return 1 if the operand is in volatile memory.  Note that during the
+;; RTL generation phase, memory_operand does not return TRUE for volatile
+;; memory references.  So this function allows us to recognize volatile
+;; references where it's safe.
+(define_predicate "volatile_mem_operand"
+  (and (and (match_code "mem")
+   (match_test "MEM_VOLATILE_P (op)"))
+   (if_then_else (match_test "reload_completed")
+ (match_operand 0 "memory_operand")
+ (if_then_else (match_test "reload_in_progress")
+  (match_test "strict_memory_address_p (mode, XEXP (op, 0))")
+  (match_test "memory_address_p (mode, XEXP (op, 0))")

[Bug target/85152] VAX ICE with -O2

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85152

--- Comment #1 from coypu  ---
*** Bug 85151 has been marked as a duplicate of this bug. ***

[Bug target/85151] VAX ICE with -O2

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85151

coypu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from coypu  ---
Made a double bug report by mistake.

*** This bug has been marked as a duplicate of bug 85152 ***

[Bug target/85152] New: VAX ICE with -O2

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85152

Bug ID: 85152
   Summary: VAX ICE with -O2
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

Created attachment 43808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43808=edit
Test case.

ICE with -O2, no ICE with -O0.

~/gcc/build/gcc$ PATH=.:$PATH ./xgcc -x c small.c -c -O2
during RTL pass: final
small.c: In function 'fn1':
small.c:7:1: internal compiler error: in change_address_1, at emit-rtl.c:2286
 }
 ^
0x7d86ed change_address_1
../../gcc/emit-rtl.c:2286
0x7dc9d5 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
../../gcc/emit-rtl.c:2420
0x101b783 output_101
../../gcc/config/vax/vax.md:824
0x82ac0a final_scan_insn_1
../../gcc/final.c:3105
0x82c79b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:3218
0x82c935 final_1
../../gcc/final.c:2088
0x82d984 rest_of_handle_final
../../gcc/final.c:4671
0x82d984 execute
../../gcc/final.c:4745
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/85151] New: VAX ICE with -O2

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85151

Bug ID: 85151
   Summary: VAX ICE with -O2
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

Created attachment 43807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43807=edit
Test case.

ICE with -O2, no ICE with -O0.

~/gcc/build/gcc$ PATH=.:$PATH ./xgcc -x c ~/small.c -c -O2
during RTL pass: final
/home/fly/small.c: In function 'fn1':
/home/fly/small.c:7:1: internal compiler error: in change_address_1, at
emit-rtl.c:2286
 }
 ^
0x7d86ed change_address_1
../../gcc/emit-rtl.c:2286
0x7dc9d5 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
../../gcc/emit-rtl.c:2420
0x101b783 output_101
../../gcc/config/vax/vax.md:824
0x82ac0a final_scan_insn_1
../../gcc/final.c:3105
0x82c79b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:3218
0x82c935 final_1
../../gcc/final.c:2088
0x82d984 rest_of_handle_final
../../gcc/final.c:4671
0x82d984 execute
../../gcc/final.c:4745
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

Re: Internal compiler error building libstdc++ for vax

[coypu]

(updating)
krister found a better hack patch which explains what the problem is,
adding a useless move at the end of the instruction, so the label is
not the last instruction.

(And, in the problem code, the last instruction in the function.)

--- a/external/gpl3/gcc/dist/gcc/config/vax/builtins.md
+++ b/external/gpl3/gcc/dist/gcc/config/vax/builtins.md
@@ -70,6 +70,7 @@
   emit_jump_insn (gen_jbbssi (operands[1], const0_rtx, label,
operands[1]));
   emit_move_insn (operands[0], const0_rtx);
   emit_label (label);
+  emit_move_insn (operands[0], operands[0]);
   DONE;
 }")

Internal compiler error building libstdc++ for vax

[coypu]

Hi folks,

netbsd's copy of GCC differs enough that it fails elsewhere with
gcc-trunk, but the problematic code is upstream.

updating netbsd to gcc 6.4.0, I get an internal compiler error building
libstdc++. (Long version: http://gnats.netbsd.org/53039)

Short version:

test.cc: In function 'bool 
std::atomic_flag_test_and_set_explicit(std::__atomic_flag_base*, 
std::memory_order)':
test.cc:25:3: internal compiler error: in patch_jump_insn, at cfgrtl.c:1271

comment at cfgrtl.c:1271 suggests:
  /* If the substitution doesn't succeed, die.  This can happen
 if the back end emitted unrecognizable instructions or if
 target is exit block on some arches.  */
  if (!redirect_jump (as_a  (insn),
  block_label (new_bb), 0))
{
  gcc_assert (new_bb == EXIT_BLOCK_PTR_FOR_FN (cfun));

so it's saying the backend is generating garbage.

(gdb) call debug_insn_slim(insn)
   12: 
{pc={(zero_extract([r23:SI],0x1,0x1)!=0)?L14:pc};zero_extract([r23:SI],0x1,0x1)=0x1;}

I've found that if I modify vax/builtins.md:
@@ -61,7 +67,7 @@
   label = gen_label_rtx ();
   emit_move_insn (operands[0], const1_rtx);
-  emit_jump_insn (gen_jbbssi (operands[1], const0_rtx, label, 
operands[1]));
+  //emit_jump_insn (gen_jbbssi (operands[1], const0_rtx, label, 
operands[1]));
   emit_move_insn (operands[0], const0_rtx);
   emit_label (label);
   DONE;

it "fixes" my internal compiler error. However, I'm not sure what is
wrong with gen_jbbssi.

My current strategy of "just changing things and seeing if they help /
comparing to 50 examples of nearly identical code" doesn't appear
to be working despite many attempts :-)

Please help, thanks.

Re: [PATCH 1/2] Untangle stddef.h a little

[coypu]

hi gcc-patches,

as part of pinging, i'll explain the story of this patch.

I want to make sure all netbsd archs work with upstream gcc.
in this case, netbsd/arm's EABI support.
I try to break up my changes into digestible chunks that are rational,
which is why this change came first.

building netbsd/arm gcc-trunk, I had a build error in libstdc++, because
this stddef.h relies on include guards:

#if defined(_ANSI_H_) || defined(_MACHINE_ANSI_H_) || defined(_X86_64_ANSI_H_)  
|| defined(_I386_ANSI_H_)

In theory I could have just added:
 || _ARM_ANSI_H_

this felt gross, so I tried a better solution.
the file even comes with comments like:
  /* Why is this file so hard to maintain properly?
so I try my best to help.

Please let me upstream local changes. there are a lot of them. and I
feel unable to get them across.
I have so many changes that it feels inappropriate to ask for help with
hard problems like internal compiler errors because upstream GCC hit a
different problem. I'm not familiar with stuff so this is hard :-(

Re: [PATCH 1/2] Untangle stddef.h a little

[coypu]

ping
they're good patches. ask questions. I have more.

Re: [PATCH 1/2] Untangle stddef.h a little

[coypu]

ping, let me know if there is anything wrong with it.