[Baby Sasha] ti invita!

[Baby Sasha via Gcc]

Saludos!
[Baby Sasha]:Esto merece la pena https://1a9c2e06.page.link/1Crm







AdiósBaby Sasha

Unjustified optimization due to restricted struct members?

[Ties Klappe via Gcc]

When reading section 6.7.3.1 of the C standard (quoted below) about
the *restrict
*type qualifier, the first section talks about *ordinary identifiers*.
These are defined in section 6.2.3, and exclude members of structures.

Let D be a declaration of an ordinary identifier that provides a means of
> designating an object P as a restrict-qualified pointer to type T.


I would assume that this means that in the code excerpt below the function
*h* cannot be optimized by substituting the load of *b.p *for *10*, as the
standard does not specify what it means for a struct member to be restrict
qualified. However, the code is still optimized by gcc (but not Clang), as
can be seen here: https://godbolt.org/z/hEnKKoaae

struct bar {
int* restrict p;
int* restrict q;
};

int h(struct bar b) {
*b.p = 10;
*b.q = 11;
return *b.p;
}

Was this a deliberate choice, or does it simply follow from how restrict is
supported in gcc (and could this be considered a bug w.r.t. the standard)?

Re: Unjustified optimization due to restricted struct members?

[Richard Biener via Gcc]

On Thu, Nov 30, 2023 at 12:07 PM Ties Klappe via Gcc  wrote:
>
> When reading section 6.7.3.1 of the C standard (quoted below) about
> the *restrict
> *type qualifier, the first section talks about *ordinary identifiers*.
> These are defined in section 6.2.3, and exclude members of structures.
>
> Let D be a declaration of an ordinary identifier that provides a means of
> > designating an object P as a restrict-qualified pointer to type T.
>
>
> I would assume that this means that in the code excerpt below the function
> *h* cannot be optimized by substituting the load of *b.p *for *10*, as the
> standard does not specify what it means for a struct member to be restrict
> qualified. However, the code is still optimized by gcc (but not Clang), as
> can be seen here: https://godbolt.org/z/hEnKKoaae
>
> struct bar {
> int* restrict p;
> int* restrict q;
> };
>
> int h(struct bar b) {
> *b.p = 10;
> *b.q = 11;
> return *b.p;
> }
>
> Was this a deliberate choice, or does it simply follow from how restrict is
> supported in gcc (and could this be considered a bug w.r.t. the standard)?

Hmm, this was a deliberate choice (it also works for global 'b'), I didn't think
the standard would exclude that.  Note GCCs C++ standard library makes
use of restrict qualified pointers as structure members for example.

Richard.

Re: Unjustified optimization due to restricted struct members?

[Ties Klappe via Gcc]

Thank you Richard.

Similar to the struct example, I was also wondering about why the following
code does *not* get optimized (e.g. https://godbolt.org/z/9eGrjjK81):

int f(int* restrict a[restrict 2]) {
*(a[0]) = 10;
*(a[1]) = 11;
return *(a[0]);
}

Do you happen to know why a reload via a[0] is required? I would have
expected to see the same optimization as is performed for the struct
example.

Kind regards,
Ties

Op do 30 nov 2023 om 13:16 schreef Richard Biener <
richard.guent...@gmail.com>:

> On Thu, Nov 30, 2023 at 12:07 PM Ties Klappe via Gcc 
> wrote:
> >
> > When reading section 6.7.3.1 of the C standard (quoted below) about
> > the *restrict
> > *type qualifier, the first section talks about *ordinary identifiers*.
> > These are defined in section 6.2.3, and exclude members of structures.
> >
> > Let D be a declaration of an ordinary identifier that provides a means of
> > > designating an object P as a restrict-qualified pointer to type T.
> >
> >
> > I would assume that this means that in the code excerpt below the
> function
> > *h* cannot be optimized by substituting the load of *b.p *for *10*, as
> the
> > standard does not specify what it means for a struct member to be
> restrict
> > qualified. However, the code is still optimized by gcc (but not Clang),
> as
> > can be seen here: https://godbolt.org/z/hEnKKoaae
> >
> > struct bar {
> > int* restrict p;
> > int* restrict q;
> > };
> >
> > int h(struct bar b) {
> > *b.p = 10;
> > *b.q = 11;
> > return *b.p;
> > }
> >
> > Was this a deliberate choice, or does it simply follow from how restrict
> is
> > supported in gcc (and could this be considered a bug w.r.t. the
> standard)?
>
> Hmm, this was a deliberate choice (it also works for global 'b'), I didn't
> think
> the standard would exclude that.  Note GCCs C++ standard library makes
> use of restrict qualified pointers as structure members for example.
>
> Richard.
>

Re: Unjustified optimization due to restricted struct members?

[Richard Biener via Gcc]

On Thu, Nov 30, 2023 at 1:50 PM Ties Klappe  wrote:
>
> Thank you Richard.
>
> Similar to the struct example, I was also wondering about why the following 
> code does not get optimized (e.g. https://godbolt.org/z/9eGrjjK81):
>
> int f(int* restrict a[restrict 2]) {
> *(a[0]) = 10;
> *(a[1]) = 11;
> return *(a[0]);
> }
>
> Do you happen to know why a reload via a[0] is required? I would have 
> expected to see the same optimization as is performed for the struct example.

It's not implemented.  I think there's even a bugreport about this,
basically restrict
gets only "one layer deep".

Richard.

> Kind regards,
> Ties
>
> Op do 30 nov 2023 om 13:16 schreef Richard Biener 
> :
>>
>> On Thu, Nov 30, 2023 at 12:07 PM Ties Klappe via Gcc  wrote:
>> >
>> > When reading section 6.7.3.1 of the C standard (quoted below) about
>> > the *restrict
>> > *type qualifier, the first section talks about *ordinary identifiers*.
>> > These are defined in section 6.2.3, and exclude members of structures.
>> >
>> > Let D be a declaration of an ordinary identifier that provides a means of
>> > > designating an object P as a restrict-qualified pointer to type T.
>> >
>> >
>> > I would assume that this means that in the code excerpt below the function
>> > *h* cannot be optimized by substituting the load of *b.p *for *10*, as the
>> > standard does not specify what it means for a struct member to be restrict
>> > qualified. However, the code is still optimized by gcc (but not Clang), as
>> > can be seen here: https://godbolt.org/z/hEnKKoaae
>> >
>> > struct bar {
>> > int* restrict p;
>> > int* restrict q;
>> > };
>> >
>> > int h(struct bar b) {
>> > *b.p = 10;
>> > *b.q = 11;
>> > return *b.p;
>> > }
>> >
>> > Was this a deliberate choice, or does it simply follow from how restrict is
>> > supported in gcc (and could this be considered a bug w.r.t. the standard)?
>>
>> Hmm, this was a deliberate choice (it also works for global 'b'), I didn't 
>> think
>> the standard would exclude that.  Note GCCs C++ standard library makes
>> use of restrict qualified pointers as structure members for example.
>>
>> Richard.

Update on GCC 14 C type safety changes/warnings as errors

[Florian Weimer via Gcc]

The patch series is currently under review:

  [PATCH v3 00/11] : More warnings as errors by default
  


Jeff as a global reviewer has delegated review to Marek.

The current series is based on an earlier suggestion to do as much as
possible in one transition.  The full list of upgraded warnings is:

  -Wimplicit-function-declaration
  -Wimplicit-int
  -Wint-conversion
  -Wreturn-mismatch (new, previously part of -Wreturn-types)
  -Wdeclaration-missing-parameter-type (new, previously unnamed)
  -Wincompatible-pointer-types

Fedora has a set of about 15,000 source packages which are built with a
GCC compiler in the buildroot.  Until recently, we only had experience
with dealing with -Wimplicit-function-declaration and -Wimplicit-int
issues.  We have implemented fixes or workaround in about 860 packages
for those two warnings.  Where possible, these fixes have been sent
upstream, but of course in many cases, upstream has been dormant for a
while or not around at all anymore.

We now have Fedora test builds with an instrumented GCC that covers all
the warnings listed above.  The data is skewed somewhat because we
underwent an unscheduled libxml2 API transition at the same time, and
also had a glibc crypt declaration regression initially.  I'm going with
the numbers I have today.  They include cleanups for about 50 packages
for various issues (most prominent ones being bash and xterm).

  autoconf
  all only
  implicit-function-declaration53   21
  implicit-int  20
  int-conversion   99   33
  return-mismatch  132
  declaration-missing-parameter-type00
  incompatible-pointer-types  374   50
  497   89

Numbers do not tally up because one package can have multiple issues.
The autoconf column counts packages where file-name based heuristics
suggest the critical errors are in autoconf-style feature probes, where
they are ignored and could silently alter the results.  My focus will be
on fixing those packages.

These numbers include a certain amount of false positives, especially
for implicit-function-declaration and incompatible-pointer-types, but
the GCC instrumentation has improved somewhat and now uses unrelated
errors (e.g., about unknown types, or incorrect number of function
errors) to suppress logging of the critical errors.

Looking at the numbers, everything seems quite doable except
incompatible-pointer-types.  (Keep in mind that these numbers are based
on over 15,000 packages.)  Instead of the incompatible-pointer-types
error, Clang only went with a subset (not yet implemented by GCC) called
incompatible-function-pointer-types, but I'm not sure if it would result
in a substantial amount of work reduction.  The status as a warning for
non-function pointers definitely hides real bugs (for example, an
out-of-bounds write in PyTables on 32-bit architectures).

I suggest we put in the incompatible-pointer-types upgrade for now
(pending review), and see how it goes in Fedora.  I plan to backport
these changes to GCC 13 as used in our current development version, so
that we can gain some feedback from package maintainers before we import
GCC 14 (which is expected to happen well before the GCC upstream
release).  If feedback is overly negative, I'm going to suggest that GCC
disables it again for the GCC 14 release, although that would run
counter to the request for one transition only.

Thoughts?

Excluded above are systemic issues related to Vala, which does not
produce valid C in many cases.  I will probably have to look into
teaching Vala to emit diagnostic pragmata in the generated C sources
because they are not expected to be valid C (although again, this really
seems to be hiding application bugs in some cases).

Thanks,
Florian

Re: Unjustified optimization due to restricted struct members?

[Joseph Myers]

On Thu, 30 Nov 2023, Ties Klappe via Gcc wrote:

> When reading section 6.7.3.1 of the C standard (quoted below) about
> the *restrict
> *type qualifier, the first section talks about *ordinary identifiers*.
> These are defined in section 6.2.3, and exclude members of structures.
> 
> Let D be a declaration of an ordinary identifier that provides a means of
> > designating an object P as a restrict-qualified pointer to type T.
> 
> 
> I would assume that this means that in the code excerpt below the function
> *h* cannot be optimized by substituting the load of *b.p *for *10*, as the
> standard does not specify what it means for a struct member to be restrict
> qualified. However, the code is still optimized by gcc (but not Clang), as
> can be seen here: https://godbolt.org/z/hEnKKoaae
> 
> struct bar {
> int* restrict p;
> int* restrict q;
> };
> 
> int h(struct bar b) {

In this code, 'b' is the ordinary identifier; "struct bar b" is the 
declaration D.  The declaration does not itself need to have pointer type.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

[Ian Lance Taylor via Gcc]

On Mon, Nov 20, 2023 at 11:58 AM Björn Schäpers  wrote:
>
> An updated version, using neither A or W, but just the macro.

Thanks.  Committed as follows.

Ian
1017495bc91d40570f58c37e88ca013164782129
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 56af4828e27..f976a963bf3 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -39,6 +39,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include "backtrace.h"
 #include "internal.h"
 
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 /* Coff file header.  */
 
 typedef struct {
@@ -610,6 +622,7 @@ coff_add (struct backtrace_state *state, int descriptor,
   int debug_view_valid;
   int is_64;
   uintptr_t image_base;
+  uintptr_t base_address = 0;
   struct dwarf_sections dwarf_sections;
 
   *found_sym = 0;
@@ -856,7 +869,16 @@ coff_add (struct backtrace_state *state, int descriptor,
  + (sections[i].offset - min_offset));
 }
 
-  if (!backtrace_dwarf_add (state, /* base_address */ 0, &dwarf_sections,
+#ifdef HAVE_WINDOWS_H
+  {
+uintptr_t module_handle;
+
+module_handle = (uintptr_t) GetModuleHandle (NULL);
+base_address = module_handle - image_base;
+  }
+#endif
+
+  if (!backtrace_dwarf_add (state, base_address, &dwarf_sections,
0, /* FIXME: is_bigendian */
NULL, /* altlink */
error_callback, data, fileline_fn,

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

[Ian Lance Taylor via Gcc]

On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers  wrote:
>
> From: Björn Schäpers 
>
> Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
> that libraries loaded after the backtrace_initialize are not handled.
> But as far as I can see that's the same for elf.

Thanks, but I don't want a patch that loops using goto statements.
Please rewrite to avoid that.  It may be simpler to call a function.

Also starting with a module count of 1000 seems like a lot.  Do
typical Windows programs load that many modules?

Ian




> Tested on x86_64-linux and i686-w64-mingw32.
>
> -- >8 --
>
> * pecoff.c (coff_add): New argument for the module handle of the
> file, to get the base address.
> * pecoff.c (backtrace_initialize): Iterate over loaded libraries
> and call coff_add.
>
> Signed-off-by: Björn Schäpers 
> ---
>  libbacktrace/pecoff.c | 76 ---
>  1 file changed, 72 insertions(+), 4 deletions(-)
>
> diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
> index 296f1357b5f..40395109e51 100644
> --- a/libbacktrace/pecoff.c
> +++ b/libbacktrace/pecoff.c
> @@ -49,6 +49,7 @@ POSSIBILITY OF SUCH DAMAGE.  */
>  #endif
>
>  #include 
> +#include 
>  #endif
>
>  /* Coff file header.  */
> @@ -592,7 +593,8 @@ coff_syminfo (struct backtrace_state *state, uintptr_t 
> addr,
>  static int
>  coff_add (struct backtrace_state *state, int descriptor,
>   backtrace_error_callback error_callback, void *data,
> - fileline *fileline_fn, int *found_sym, int *found_dwarf)
> + fileline *fileline_fn, int *found_sym, int *found_dwarf,
> + uintptr_t module_handle ATTRIBUTE_UNUSED)
>  {
>struct backtrace_view fhdr_view;
>off_t fhdr_off;
> @@ -623,7 +625,6 @@ coff_add (struct backtrace_state *state, int descriptor,
>int is_64;
>uintptr_t image_base;
>uintptr_t base_address = 0;
> -  uintptr_t module_handle;
>struct dwarf_sections dwarf_sections;
>
>*found_sym = 0;
> @@ -871,7 +872,6 @@ coff_add (struct backtrace_state *state, int descriptor,
>  }
>
>  #ifdef HAVE_WINDOWS_H
> -module_handle = (uintptr_t) GetModuleHandleW (NULL);
>  base_address = module_handle - image_base;
>  #endif
>
> @@ -914,12 +914,80 @@ backtrace_initialize (struct backtrace_state *state,
>int found_sym;
>int found_dwarf;
>fileline coff_fileline_fn;
> +  uintptr_t module_handle = 0;
> +
> +#ifdef HAVE_WINDOWS_H
> +  DWORD i;
> +  DWORD module_count;
> +  DWORD bytes_needed_for_modules;
> +  HMODULE *modules;
> +  char module_name[MAX_PATH];
> +  int module_found_sym;
> +  fileline module_fileline_fn;
> +
> +  module_handle = (uintptr_t) GetModuleHandleW (NULL);
> +#endif
>
>ret = coff_add (state, descriptor, error_callback, data,
> - &coff_fileline_fn, &found_sym, &found_dwarf);
> + &coff_fileline_fn, &found_sym, &found_dwarf, module_handle);
>if (!ret)
>  return 0;
>
> +#ifdef HAVE_WINDOWS_H
> +  module_count = 1000;
> + alloc_modules:
> +  modules = backtrace_alloc (state, module_count * sizeof(HMODULE),
> +error_callback, data);
> +  if (modules == NULL)
> +goto skip_modules;
> +  if (!EnumProcessModules (GetCurrentProcess (), modules, module_count,
> +  &bytes_needed_for_modules))
> +{
> +  error_callback(data, "Could not enumerate process modules",
> +(int) GetLastError ());
> +  goto free_modules;
> +}
> +  if (bytes_needed_for_modules > module_count * sizeof(HMODULE))
> +{
> +  backtrace_free (state, modules, module_count * sizeof(HMODULE),
> + error_callback, data);
> +  // Add an extra of 2, if some module is loaded in another thread.
> +  module_count = bytes_needed_for_modules / sizeof(HMODULE) + 2;
> +  modules = NULL;
> +  goto alloc_modules;
> +}
> +
> +  for (i = 0; i < bytes_needed_for_modules / sizeof(HMODULE); ++i)
> +{
> +  if (GetModuleFileNameA (modules[i], module_name, MAX_PATH - 1))
> +   {
> + if (strcmp (filename, module_name) == 0)
> +   continue;
> +
> + module_handle = (uintptr_t) GetModuleHandleA (module_name);
> + if (module_handle == 0)
> +   continue;
> +
> + descriptor = backtrace_open (module_name, error_callback, data, 
> NULL);
> + if (descriptor < 0)
> +   continue;
> +
> + coff_add (state, descriptor, error_callback, data,
> +   &module_fileline_fn, &module_found_sym, &found_dwarf,
> +   module_handle);
> + if (module_found_sym)
> +   found_sym = 1;
> +   }
> +}
> +
> + free_modules:
> +  if (modules)
> +backtrace_free(state, modules, module_count * sizeof(HMODULE),
> +  error_callback, data);
> +  modules = NULL;
> + skip_modules:
> +#endif
> +
>if (!state->threaded)
>  {
>if (found_sym)
> --
> 2.38.1
>

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

[Eli Zaretskii via Gcc]

> Date: Thu, 30 Nov 2023 11:53:54 -0800
> Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Ian Lance Taylor via Gcc 
> 
> Also starting with a module count of 1000 seems like a lot.  Do
> typical Windows programs load that many modules?

Unlikely.  I'd start with 100.

gcc-11-20231130 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20231130 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20231130/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 09c5ce95ef90772734fa6b15fc6f12039ae66684

You'll find:

 gcc-11-20231130.tar.xz   Complete GCC

  SHA256=cf545426ebdc1dc76884498869420e694ef357b4b241aa2a460f733f11b04921
  SHA1=d7ab3b3e58e094d279b10c6432e5170748014878

Diffs from 11-20231123 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.