Design Gipfel-2020 Visitors Info List

2020-10-06 Thread Sarah Michelle
Hello
Hope you and your family are safe !!

Myself Sarah Michelle, Business Analyst of Inside data view.
We would like to follow-up with you for the below mentioned exhibition 
attendees' s database.


Expo details

Design Gipfel
28 - 29 Nov 2020
Mensa am Ring, Münster, Germany
Visitors=4287

Data base contains:

  *   Contact Name
  *   Email Address
  *   Phone No
  *   Title, Company Name
  *   URL/Website
  *   City
  *   Country



We await your interest to obtain the above-mentioned database. Please feel free 
to write us and we can come up with an attractive price for you.

Kindly let us know your thoughts, so we can send you more information on same.

Best Regards,
Sarah Michelle
Business Analyst





[gnu.org #1622724] Antoni Boucher GCC

2020-10-06 Thread Craig Topham via RT via Gcc
Antoni,

Thank you so much for contributing. Please find the attached PDF(s) of your 
assignment(s) in the email after this one. Please print out the form, sign it, 
and then email a scanned copy in PDF format to  or fax it to us 
at +1-617-542-2652. You can also send it to us via the postal mail if you 
prefer:


Copyright & Licensing Associate
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110


Once the FSF has signed it, we will send you a digital copy in PDF format for 
your records.

Remember, we can protect your work as long as we hold copyright on it. Do keep 
us informed as you change employers, or as your disclaimers run their course.

In addition, would it be acceptable for us to publicize your contribution by 
microblogging that you are contributing, and listing your name in our monthly 
newsletter?

Thank you for your contribution!

All the best,

Craig Topham
Copyright & Licensing Associate
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652



modified_between_p does not check for volatile memory

2020-10-06 Thread Tucker Kern via Gcc
TL;DR

In GCC 9.3, I believe modified_between_p should return 1 if the memory
reference is volatile. My layman's understanding of volatile memory is that
it could change at any time, and thus could be modified between any two
instructions.

Possible patch:
diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c
index 01af063a222..a395df0627b 100644
--- a/gcc/rtlanal.c
+++ b/gcc/rtlanal.c
@@ -1308,6 +1308,8 @@ modified_between_p (const_rtx x, const rtx_insn
*start, const rtx_insn *end)
   return 1;

 case MEM:
+  if (MEM_VOLATILE_P(x))
+return 1;
   if (modified_between_p (XEXP (x, 0), start, end))
  return 1;
   if (MEM_READONLY_P (x))

Details
I'm writing a splitter to optimize bit field conditionals (e.g. testing a
bit of memory mapped I/O). The non-optimized pattern consists of a SET,
AND,  LSHIFTRT + CMP, JMP pattern which I know can be simplified to an
AND + JMP as the AND operation will set the necessary CC bits. To achieve
this optimization in the combine pass a custom general_operand has been
defined which allows volatile memory.

However in certain situations I've found the combine pass is generating
invalid patterns when it merges a SET and IF_THEN_ELSE (CMP + JMP)
patterns. One such situation is when GCC decides to reuse the result of the
comparison for the return value.

This issue seems intertwined with the combine + volatile_ok issue that has
been discussed a number of times in the past. The backend is question is
highly embedded and significant performance gains are made by enabling
volatile references during combine.

Optimized tree of the test program. In this program the bit field value is
saved in _1 to be reused in the return value. Why it makes this choice is
beyond me.
   _1;
  _Bool _3;

   [local count: 1044213930]:
  _1 ={v} MEM[(volatile struct register_t *)5B].done;
  if (_1 != 0)
goto ; [11.00%]
  else
goto ; [89.00%]

   [local count: 1073741824]:
  // Additional code trimmed for brevity...

   [local count: 114863532]:
  # _3 = PHI <0(4), _1(5)>
  return _3;

This produces the following pre-combine RTL.
(insn 9 6 10 3 (parallel [
(set (reg:QI 17 [  ])
(lshiftrt:QI (mem/v:QI (const_int 5 [0x5]) [1 MEM[(volatile
struct register_t *)5B]+0 S1 A16])
(const_int 3 [0x3])))
(clobber (reg:CC 7 FLAG))
]) "fail.c":22:26 19 {*lshrqi3_im}
 (expr_list:REG_DEAD (reg/f:QI 18)
(expr_list:REG_UNUSED (reg:CC 7 FLAG)
(nil
(insn 10 9 12 3 (parallel [
(set (reg:QI 17 [  ])
(and:QI (reg:QI 17 [  ])
(const_int 1 [0x1])))
(clobber (reg:CC 7 FLAG))
]) "fail.c":22:26 10 {andqi3}
 (expr_list:REG_UNUSED (reg:CC 7 FLAG)
(nil)))
(jump_insn 12 10 20 3 (parallel [
(set (pc)
(if_then_else (eq (reg:QI 17 [  ])
(const_int 0 [0]))
(label_ref:QI 11)
(pc)))
(clobber (scratch:QI))
]) "fail.c":22:9 41 {*cbranchqi4_im}
 (int_list:REG_BR_PROB 955630228 (nil))
 -> 11)

Which when combined generates patterns that will produce invalid code. GCC
has assumed the memory value will not change between insn 10 & 12.
(insn 10 9 12 3 (parallel [
(set (reg:QI 17 [  ])
(and:QI (lshiftrt:QI (mem/v:QI (const_int 5 [0x5]) [1
MEM[(volatile struct register_t *)5B]+0 S1 A16])
(const_int 3 [0x3]))
(const_int 1 [0x1])))
(clobber (reg:CC 7 FLAG))
]) "fail.c":22:18 10 {andqi3}
 (expr_list:REG_UNUSED (reg:CC 7 FLAG)
(nil)))
(jump_insn 12 10 20 3 (parallel [
(set (pc)
(if_then_else (eq (zero_extract:QI (mem/v:QI (const_int 5
[0x5]) [1 MEM[(volatile struct register_t *)5B]+0 S1 A16])
(const_int 1 [0x1])
(const_int 3 [0x3]))
(const_int 0 [0]))
(label_ref:QI 11)
(pc)))
(clobber (scratch:QI))
]) "fail.c":22:9 43 {*cbranchqi4_zero_extract}
 (int_list:REG_BR_PROB 955630228 (nil))
 -> 11)

With the above patch, the combination of insn 10 & 12 is rejected and the
if_then_else switches on retval.
(insn 10 9 12 3 (parallel [
(set (reg:QI 17 [  ])
(and:QI (lshiftrt:QI (mem/v:QI (const_int 5 [0x5]) [1
MEM[(volatile struct register_t *)5B]+0 S1 A16])
(const_int 3 [0x3]))
(const_int 1 [0x1])))
(clobber (reg:CC 7 FLAG))
]) "fail.c":22:18 10 {andqi3}
 (expr_list:REG_UNUSED (reg:CC 7 FLAG)
(nil)))
(jump_insn 12 10 20 3 (parallel [
(set (pc)
(if_then_else (eq (reg:QI 17 [  ])
(const_int 0 [0]))
(label_ref:QI 11)
(pc)))
(clobber (scratch:QI))
]) "fail.c":22:9 41 {*cbranc

Missing commit in gcc-cvs mailing list

2020-10-06 Thread Martin Liška

My commit 190c04ba36d9c6c3dce41f12012aa97c6d7f22f5 is missing in the
mailing list (and so was not propagated to the corresponding PR):
https://gcc.gnu.org/pipermail/gcc-cvs/2020-October/date.html

There's previous and next commit:
[gcc r11-3678] [PATCH][GCC] arm: Move iterators from mve.md to iterators.md to 
maintain consistency.   SRINATH PARVATHANENI
... should be here ...
[gcc r11-3680] [openacc] Fix acc declare for VLAs   Tom de Vries

Can please anybody check that?
Thanks,
Martin


Re: Navigational corrections

2020-10-06 Thread Michael Kerrisk (man-pages) via Gcc
On 10/6/20 12:08 AM, Alejandro Colomar wrote:
> Hi Michael,
> 
> On 2020-10-03 13:39, Michael Kerrisk (man-pages) wrote:
>> Hi Alex,
> [...]
>>
>> off_t would be great.
>>
>> In case you are looking for some other candidates, some others
>> that I would be interested to see go into the page would be
>>
>> fd_set
>> clock_t
>> clockid_t
>> and probably dev_t
> 
> Great!
> 
> off_t is almost done.  I think I have too many references in "See also".
> 
> I'll send you the patch, and trim as you want :)

Thanks, Alex. I'm teaching a course this week, so less active, 
I'm sorry.

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/