Please fix --disable-hosted-libstdcxx asap

[unlvsur unlvsur via Gcc]

Thank you.

I have submitted the patch before. Please just apply it or do that by yourself.

Sent from Mail for Windows 10

Re: Please fix --disable-hosted-libstdcxx asap

[Jonathan Wakely via Gcc]

On 21/04/21 10:41 +, unlvsur unlvsur via Libstdc++ wrote:

Thank you.

I have submitted the patch before. Please just apply it or do that by yourself.


Your patch was completely unacceptable, removing lots of things that
should not be removed.

Just because a piece of code isn't useful for *you* doesn't mean it
should be removed.

[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (April 22, 201)

[Wei Wu via Gcc]

Hi all,

There is the agenda for tomorrow's meeting. If you have topics to
discuss or share, please let me know and I can add them to the agenda.

## Agenda:

1. Updates from the initial psABI meeting
2. Status update of B, K, P extension implementations.
3. discuss https://github.com/riscv/riscv-elf-psabi-doc/pull/185
4. AOB


https://calendar.google.com/calendar/ical/lm5bddk2krcmtv5iputjgqvoio%40group.calendar.google.com/public/basic.ics

BEIJING, China
11:00p Thu, Apr 22 2021

PDT/PST, Pacific Daylight Time (US)
8:00a Thu, Apr 22 2021

LONDON, United Kingdom, England
4:00p Thu, Apr 22 2021

Join Zoom Meeting
https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09

Meeting ID: 893 9360 0951
Passcode: 899662

Find your local number: https://zoom.com.cn/u/kWo4yMmVQ

--
Best wishes,
Wei Wu (吴伟)

Request Quotation - Heavy Machinery

[Marika Saonari via Gcc]

Dear Supplier,

Please advise us if you can ship to Europe to enable us to send our
purchase list for a newly approved extensive project of one of our
Customers.

Anticipating your immediate reply.­­

Many thanks,

Regards,­­



*Marika Saonari *I Buyer

–

THE *CONRAN* SHOP I 22 Shad Thames I London

I SE1
2YU

t: +44 (0)207 403 88991 I d: +44 (0)207 827 44641 I m: +44 (0)7860 9466761

– email:  msaonari.con...@gmail.com 

conranshop.com


–

Follow us on

Instagram

 – Pinterest

 – Facebook

 – Twitter


–

CONRAN is a group of design led entities founded by Sir Terence Conran,
including
THE CONRAN SHOP | CONRAN & PARTNERS | CONRAN CONTRACTS | CONRAN HOLDINGS

Re: help debug hash_map garbage collection issue

[Martin Sebor via Gcc]

On 4/20/21 8:26 PM, Jason Merrill wrote:

On Tue, Apr 20, 2021 at 8:31 PM Martin Sebor via Gcc  wrote:


On 4/20/21 5:03 PM, Martin Sebor wrote:

On 4/20/21 4:15 PM, Martin Sebor wrote:

On 4/20/21 2:36 PM, Martin Sebor wrote:

On 4/20/21 2:13 PM, Marek Polacek wrote:

On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote:

I have a static hash_map object that needs to persist across passes:

static GTY(()) hash_map *map;

I initialize the map like so:

map = hash_map::create_ggc (4);

But I see crashes when accessing the map after adding and removing
some number of entries in a few passes.  The crashes are due to
the map having been garbage-collected and the memory allocated to
it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see
in GDD being written into the map by poison_pages()).

I assumed marking the map pointer GTY(()) would keep the garbage
collector from touching the map.  Is there something else I need
to do to keep it from doing that?

Thanks
Martin

PS Just in case it matters, the bitmap in the table is allocated
via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside
the map.


My sense is that this is the problem.  What happens if you use
BITMAP_GGC_ALLOC?


Same thing :(


I reduced the problem to the following patch/test case no involving
a bitmap or other pointers.  With it applied, GCC reliably crashes.
An example of a stack trace is below the patch.  What am I missing?


It seems that assigning the address of an object allocated by
ggc_alloc() (which presumably includes BITMAP_GGC_ALLOC()) to
a GTY-marked pointer "defeats" the purpose of the marker and
allows it to be garbage collected.


But this is not true.  There are plenty of counterexamples, including
in tree.c which defines several GTY hash_tables (but no maps).  I tried
moving the test case below from gimple.c to tree.c but there it doesn't
even compile.  I get this error (and a couple of others):

In file included from /src/gcc/master/gcc/tree.c:16179:
./gt-tree.h: In function ‘void gt_ggc_mx(int_hash&)’:
./gt-tree.h:156:21: error: no matching function for call to
‘gt_ggc_mx(int_hash*)’
 gt_ggc_mx (&((*x)));
   ^
So as another experiment I moved it builtins.c where it does compile
(go figure) but then it crashes when I call it the same way from
c_strlen().


This is because tree.c is in GTFILES, while gimple.c and tree.c are
not, so gengtype never sees the GTY decoration in the latter files.

I don't know why when it does see the GTY, it ends up trying to mark
an int_hash*.


Thanks for the hint.  I didn't notice this in the manual before
so here are the steps to use GTY in file.c for reference:

1) add file.c to GTFILES in Makefile.in
2) add #include "gt-file.h" to the end of file.c
3) reconfigure + rebuild

I think I also finally figured out the compilation errors and ICEs,
after over two days of wrestling with it.  It's seems like hash_map
support for GTY is incomplete, as is ggc.h.  I suspect the same
problems as in hash_map are going to be in other hash-based containers.

(A gotcha that leads to cryptic errors that can add to the confusion
here is removing the GTY type from the source file as the gt-file.c
still refers to it.  I dealt with it by reconfiguring again.  Maybe
there's a better way.)

The reason for the error above (and others like it) is simply that
there's no gt_ggc_mx() defined for int_hash.  The only gt_ function
documented in the manual that is defined (in the generated gt-foo.h)
is the three-argument overload of gt_pcx_nx().

But that's not the only missing piece or problem.

The gt_*() function templates in hash-map.h are defined static so
(IIRC from my early C++ days) they're not considered by ADL.  That
leads to more compilation errors.

Also, ggc.h defines a few gt_*() overloads for a subset of integer
types but not nearly for all, so that leads to even more errors for
instantiations of int_hash on different integer types (e.g.,
uintptr_t).

Adding the full set of overloads (including, for instance, short)
leads to still more problems for int_hash specializations on types
like short.

/src/gcc/master/gcc/hash-map.h:107:14: error: no matching function for 
call to ‘gt_pch_nx(short int*, void (*&)(void*, void*), void*&)’

gt_pch_nx (&x, op, cookie);
~~^~~~

Similar to ggc.h, there is a small subset of no-op overloads like
this in hash_map but not for types like short.

The attached POC patch fixes this (foo can be called from anywhere).
I haven't done a full bootstrap with it yet or looked at hash_set or
but please let me know if you see any issues with it.  I'll submit
a complete patch once I'm done with it.

Martin

PS For the overloads I resisted introducing SFINAE to keep things
simple and avoid pulling in  (among other things).
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 8a5fb3fd99c..9ff8d1596f2 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1373,6 +1373,7 @@ OBJS = \
 	fixed-value.o