Re: [pushed] c++: rodata and defaulted ctor [PR104142]

[Andreas Schwab]

On Apr 11 2022, Jason Merrill via Gcc-patches wrote:

> diff --git a/gcc/testsuite/g++.dg/opt/const7.C 
> b/gcc/testsuite/g++.dg/opt/const7.C
> new file mode 100644
> index 000..5bcf94897a8
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/opt/const7.C
> @@ -0,0 +1,7 @@
> +// PR c++/104142
> +// { dg-do compile { target c++11 } }
> +// { dg-additional-options -Wunused-variable }
> +
> +struct B { B()=default; };
> +static const B b_var;//  { dg-bogus "" }
> +// { dg-final { scan-assembler-symbol-section {b_var} 
> {^\.(const|rodata)|\[RO\]} } }

That fails to handle .srodata.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] Add condition coverage profiling

[Jørgen Kvalsvik via Gcc-patches]

On 06/04/2022 09:35, Sebastian Huber wrote:
> Ok, for the default output this is good. The output can be explained in the
> documentation. I will try to help here.

Splendid, thanks! I would be perfectly happy with better and/or more intuitive
messages too, but I figured it shouldn't delay the rest of the algorithm.

> In theory, would it be possible to print the state of the truth table with the
> information available in the gcda and gcno files? For example:
> 
> Truth table for: a && (b || c)) && d
> 
> 0 | 1 | 2 | 3 || covered
> --+---+---+---++
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 1 | 0 | 0 | X || N
> 1 | 0 | 0 | X || N
> 1 | 0 | 1 | 0 || N
> 1 | 0 | 1 | 1 || N
> 1 | 1 | X | 0 || Y
> 1 | 1 | X | 0 || Y
> 1 | 1 | X | 1 || Y
> 1 | 1 | X | 1 || Y

Maybe? We would at least need to store the masking tables too, which right now
are implicitly stored as in the instrumentation. It's not too bad, but it
probably means the two functions should return some richer structure, which in
turn means a little bit of redesign. Computing the truth table itself shouldn't
be difficult.

> Would it be possible to map the condition index to a source code snippet? For
> example condition 1 to "b"?

Not sure - I didn't find an obvious way from location, but gcc is already able
to point to bad names in complex expressions so I'm sure it is doable. If it can
warn about possibly-uninitialized there's no reason it shouldn't be able to
figure this out. It has the basic block for the condition.

-

I think I have figured out the correct approach for computing masking vectors,
which means I should be able to submit the updated patch next week. I have a
little bit more testing to do before that, including trying out the nested-for
error Sebastian found.

I also went back on a decision:

if (a) if (b) if (c) { ... }; // no else

should be treated as if (a && b && c) {}. It is to be expected that a compiler
makes some minor transformations, and it is more correct that masking works for
(a && b && c) than for the (equivalent) nested-if being different expressions.
The same kind of "reinterpretation" happens with branch coverage, so there is
some precedence. This also means updating a few tests and figuring out how to
handle the conditions inserted by destructors. Do they have some special basic
block flag or property?

--
Thanks,
Jørgen

[PATCH] ipa-visibility: Optimize TLS access [PR99619]

[Artem Klimov via Gcc-patches]

Fix issue PR99619, which asks to optimize TLS access based on
visibility. The fix is implemented as an IPA optimization, which allows
to take optimized visibility status into account (as well as avoid
modifying all language frontends).

2022-04-17  Artem Klimov  

gcc/ChangeLog:
PR middle-end/99619
* ipa-visibility.cc (function_and_variable_visibility): Add an
explicit TLS model update after visibility optimisation loops.

gcc/testsuite/ChangeLog:
PR middle-end/99619
* gcc.dg/tls/vis-attr-gd.c: New test.
* gcc.dg/tls/vis-attr-hidden-gd.c: New test.
* gcc.dg/tls/vis-attr-hidden.c: New test.
* gcc.dg/tls/vis-flag-hidden-gd.c: New test.
* gcc.dg/tls/vis-flag-hidden.c: New test.
* gcc.dg/tls/vis-pragma-hidden-gd.c: New test.
* gcc.dg/tls/vis-pragma-hidden.c: New test.

Co-Authored-By:  Alexander Monakov  
Signed-off-by: Artem Klimov 
---
 gcc/ipa-visibility.cc   | 16 
 gcc/testsuite/gcc.dg/tls/vis-attr-gd.c  | 10 ++
 gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c   | 11 +++
 gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c  | 10 ++
 gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c   | 11 +++
 gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c  | 10 ++
 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden-gd.c | 15 +++
 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c| 14 ++
 8 files changed, 97 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c

diff --git a/gcc/ipa-visibility.cc b/gcc/ipa-visibility.cc
index e95a0dd252f..ca5b9a95f5e 100644
--- a/gcc/ipa-visibility.cc
+++ b/gcc/ipa-visibility.cc
@@ -872,6 +872,22 @@ function_and_variable_visibility (bool whole_program)
}
}
 }
+  FOR_EACH_VARIABLE (vnode)
+{
+  tree decl = vnode->decl;
+  
+  /* Optimize TLS model based on visibility (taking into account
+ optimizations done in the preceding loop), unless it was
+ specified explicitly.  */
+  
+  if (DECL_THREAD_LOCAL_P (decl)
+  && !lookup_attribute ("tls_model", DECL_ATTRIBUTES (decl)))
+{
+  enum tls_model new_model = decl_default_tls_model (decl);
+  gcc_checking_assert (new_model >= decl_tls_model (decl));
+  set_decl_tls_model (decl, new_model);
+}
+}
 
   if (dump_file)
 {
diff --git a/gcc/testsuite/gcc.dg/tls/vis-attr-gd.c 
b/gcc/testsuite/gcc.dg/tls/vis-attr-gd.c
new file mode 100644
index 000..473c7846f74
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tls/vis-attr-gd.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-require-effective-target tls } */
+/* { dg-options "-O2 -fPIC -fdump-ipa-visibility" } */
+
+// tls_model should be global-dynamic due to explicitly specified attribute
+__attribute__((tls_model("global-dynamic")))
+__thread int x;
+
+/* { dg-final { scan-ipa-dump "Varpool flags: tls-global-dynamic" "visibility" 
} } */
diff --git a/gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c 
b/gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c
new file mode 100644
index 000..8f592052361
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-require-effective-target tls } */
+/* { dg-options "-O2 -fPIC -fdump-ipa-visibility" } */
+
+// tls_model should be global-dynamic due to explicitly specified attribute
+__attribute__((visibility("hidden")))
+__attribute__((tls_model("global-dynamic")))
+__thread int x;
+
+/* { dg-final { scan-ipa-dump "Varpool flags: tls-global-dynamic" "visibility" 
} } */
diff --git a/gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c 
b/gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c
new file mode 100644
index 000..2da1bc3fa42
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-require-effective-target tls } */
+/* { dg-options "-O2 -fPIC -fdump-ipa-visibility" } */
+
+//tls_model should be local-dynamic due to visibility("hidden")
+__attribute__((visibility("hidden")))
+__thread int x;
+
+/* { dg-final { scan-ipa-dump "Varpool flags: tls-local-dynamic" "visibility" 
} } */
diff --git a/gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c 
b/gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c
new file mode 100644
index 000..de01ef31776
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c
@@ -0,0 +1,11 @@
+/* { dg-do c

Re: [PATCH] libgompd: add OMPD support, libgompd initialization and global ICVs functions

[Mohamed Atef via Gcc-patches]

Hi,
This is the second time i ping this patch.
I just remind you of it.

Mohamed

في الأحد، ٣ أبريل، ٢٠٢٢ ٤:٤١ م Mohamed Atef  كتب:

> Hi,
>   I'd like to ping this patch.
> Thanks
>
> Mohamed
>
> On Sun, Mar 20, 2022 at 11:33 AM Mohamed Atef 
> wrote:
>
>> hello,
>>I know it's too much.
>> we fixed the functions' names that are not part of the standard form
>> ompd_ * prefix to gompd_
>> Thanks
>>
>>
>> On Wed, Mar 16, 2022 at 5:48 AM Mohamed Atef 
>> wrote:
>>
>>> Hi,
>>>we found some typos in the ChangeLog and some wrong spaces
>>> (nightmare) in the files.
>>> So here's the best we can do.
>>> and please don't be disappointed and trust us we're doing our best.
>>> I hope you could review it by Sunday night.
>>>
>>> Thanks.
>>>
>>>
>>> libgomp/ChangeLog
>>>
>>> 2022-03-15  Mohamed Atef  
>>>
>>> *config/darwin/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
>>> *config/hpux/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
>>> *config/posix/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
>>> *configure: Regenerate.
>>> * Makefile.am (toolexeclib_LTLIBRARIES): Add libgompd.la.
>>> 
>>> (libgompd_la_LDFLAGS, libgompd_la_DEPENDENCIES, libgompd_la_LINK,
>>> libgompd_la_SOURCES, libgompd_version_dep, libgompd_version_script,
>>> libgompd.ver-sun, libgompd.ver, libgompd_version_info): New.
>>> *Makefile.in: Regenerate.
>>> *aclocal.m4: Regenerate.
>>> *env.c: Include ompd-support.h.
>>> (initialize_env): Call gompd_load.
>>> *team.c: Include ompd-support.h.
>>> (gomp_team_start): Call ompd_bp_parallel_begin.
>>> (gomp_team_end): Call ompd_bp_parallel_end.
>>> *libgomp.map: Add OMP_5.0.3 symbol versions.
>>> *libgompd.map: New.
>>> *omp-tools.h.in: New.
>>> *ompd-types.h.in: New.
>>> *ompd-support.h: New.
>>> *ompd-support.c: New.
>>> *ompd-helper.h: New.
>>> *ompd-helper.c: New.
>>> *ompd-init.c: New.
>>> *ompd-icv.c: New.
>>> *configure.ac (AC_CONFIG_FILES): Add omp-tools.h and ompd-types.h.
>>>
>>>
>>> On Tue, Mar 15, 2022 at 11:32 PM Mohamed Atef 
>>> wrote:
>>>


 On Tue, Mar 15, 2022 at 11:32 PM Mohamed Atef <
 mohamedatef1...@gmail.com> wrote:

> This patch added OMPD support to libgomp, api version funcitos and
> global ICVs functions.
> I hope you review it as soon as possible, to fix the problems.
> I tried as much as I could to follow GNU standards.
> We have a seminar at the college next week, so we need this to be
> reviewed.
> Thanks
>
>
> libgomp/ChangeLog
>
> 2022-03-15  Mohamed Atef  
>
> *config/darwin/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
> *config/hpux/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
> *config/posix/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
> *configure: Regenerate.
> * Makefile.am (toolexeclib_LTLIBRARIES): Add libgompd.la
> (libgompd_la_LDFLAGS, libgompd_la_DEPENDENCIES, libgompd_la_LINK,
> libgompd_la_SOURCES, libgompd_version_dep, libgompd_version_script,
> libgompd.ver-sun, libgompd.ver, libgompd_version_info): New.
> *Makefile.in: Regenerate.
> *aclocal.m4: Regenerate.
> *env.c: Include ompd-support.h.
> (initialize_env): Call gompd_load.
> *team.c: Include ompd-support.h.
> (gomp_team_start): Call ompd_bp_parallel_begin.
> (gomp_team_end): Call ompd_bp_parallel_end.
> *libgomp.map: Add OMP_5.0.3 symbol versions.
> *libgompd.map: New.
> *omp-tools.h.in: New.
> *ompd-types.h.in: New.
> *ompd-support.h: New.
> *ompd-support.c: New.
> *ompd-helper.h: New.
> *ompd-helper.c: New.
> *ompd-init.c: New.
> *ompd-icv.c: New.
> *configure.ac (AC_CONFIG_FILES): Add omp-tools.h and ompd-types.h.
>

Re: [PATCH] c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

[Jason Merrill via Gcc-patches]

On 4/15/22 07:22, Jakub Jelinek wrote:

Hi!

The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
(variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or subobjects.
The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
though, we don't replace the placeholders in there at all, because
CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
run on the whole TARGET_EXPR slot.

So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY
bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
if it is closely nested, if there is some other tree sandwiched in between,
it doesn't do it).


Hmm, Patrick made a similar change and then reverted it for PR90996. 
But it makes sense to me; when we replace placeholders, it's appropriate 
to look at the whole aggregate initialization rather than the innermost 
CONSTRUCTOR that has DMIs.  Patrick, was there a reason that change 
seemed wrong to you, or was it just unnecessary for the bug you were 
working on?



Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-04-15  Jakub Jelinek  

PR c++/105256
* typeck2.cc (process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union): Move
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the
containing CONSTRUCTOR.

* g++.dg/cpp0x/pr105256.C: New test.

--- gcc/cp/typeck2.cc.jj2022-04-07 09:09:54.432995137 +0200
+++ gcc/cp/typeck2.cc   2022-04-14 16:02:12.438432494 +0200
@@ -1515,6 +1515,14 @@ process_init_constructor_array (tree typ
  strip_array_types (TREE_TYPE (ce->value);
  
picflags |= picflag_from_initializer (ce->value);

+  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer
+CONSTRUCTOR.  */
+  if (TREE_CODE (ce->value) == CONSTRUCTOR
+ && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value))
+   {
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value) = 0;
+   }
  }
  
/* No more initializers. If the array is unbounded, we are done. Otherwise,

@@ -1560,6 +1568,14 @@ process_init_constructor_array (tree typ
  }
  
  	picflags |= picflag_from_initializer (next);

+   /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer
+  CONSTRUCTOR.  */
+   if (TREE_CODE (next) == CONSTRUCTOR
+   && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next))
+ {
+   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0;
+ }
if (len > i+1)
  {
tree range = build2 (RANGE_EXPR, size_type_node,
@@ -1754,6 +1770,13 @@ process_init_constructor_record (tree ty
if (fldtype != TREE_TYPE (field))
next = cp_convert_and_check (TREE_TYPE (field), next, complain);
picflags |= picflag_from_initializer (next);
+  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer CONSTRUCTOR.  */
+  if (TREE_CODE (next) == CONSTRUCTOR
+ && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next))
+   {
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0;
+   }
CONSTRUCTOR_APPEND_ELT (v, field, next);
  }
  
@@ -1894,6 +1917,14 @@ process_init_constructor_union (tree typ

  ce->value = massage_init_elt (TREE_TYPE (ce->index), ce->value, nested,
  flags, complain);
  
+  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer CONSTRUCTOR.  */

+  if (ce->value
+  && TREE_CODE (ce->value) == CONSTRUCTOR
+  && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value))
+{
+  CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+  CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value) = 0;
+}
return picflag_from_initializer (ce->value);
  }
  
--- gcc/testsuite/g++.dg/cpp0x/pr105256.C.jj	2022-04-14 16:04:30.518518875 +0200

+++ gcc/testsuite/g++.dg/cpp0x/pr105256.C   2022-04-14 16:03:53.264035175 
+0200
@@ -0,0 +1,18 @@
+// PR c++/105256
+// { dg-do compile { target c++11 } }
+
+int bar (int &);
+
+struct S {
+  struct T {
+struct U {
+  int i = bar (i);
+} u;
+  };
+};
+
+void
+foo (S::T *p)
+{
+  *p = {};
+};

Jakub

Options for re-adding gcj

[Zopolis0 via Gcc-patches]

Over the past few months I have been working on re-adding gcj back into
gcc, as the fundamental issue holding it back (the need to create an
open-source implementation of java from the ground up) has since been
solved by the opening of the JDK.

Unfortunately, as the old gcj code is several years old, it does not work
nicely with the current code and is largely incomplete. I have gotten it
into a state where gcc will compile with default options, unless you
forcibly enable java.

The issues I am now encountering are far beyond my skill level, and would
require someone with much more familiarity with the gcc tree than me and
general coding experience.

This leaves a few options for creating a functional Java compiler using the
OpenJDK.

1. Add the code in its current state to the current gcc tree, and have it
gradually get repaired to a state of feature parity with when it was
removed, then replace the Classpath with the OpenJDK. (There are a variety
of options for this as well, but I aim to implement it in a way similar to
C/C++ standards.)

2. Try and identify the breaking changes, speak to the people who made them
(or other people familiar with the relevant areas of the gcc tree) and get
their assistance in extending those changes to the gcj source files.

3. Replace Classpath with OpenJDK in GCC 6, (following the same C/C++
standards idea as above), as this would not require any changes to source
files and would work seamlessly. However, this is obviously not optimal,
and I would prefer to avoid it.

Which option do people think is the best?