[Bug c++/81371] New: Too much C++ templates output in output

[jg at jguk dot org]

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

Bug ID: 81371
   Summary: Too much C++ templates output in output
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Hello
Could G++ store the function symbols in their form as per function declaration?

The symbol LD seems to be given the whole inheritance for template params, so
all the templates are output for a missing function void myfunc(string s1);

Expected something like:
$ g++ -Wall -o main main.cpp
/tmp/ccS79eZp.o: In function `main':
main.cpp:(.text+0x41): undefined reference to `myfunc(std::string)'
collect2: error: ld returned 1 exit status


What I actually got:

$ g++ -Wall -o main main.cpp
/tmp/ccS79eZp.o: In function `main':
main.cpp:(.text+0x41): undefined reference to
`myfunc(std::__cxx11::basic_string)'
collect2: error: ld returned 1 exit status

[Bug tree-optimization/81369] New: [8 Regression] ICE in generate_code_for_partition

[asolokha at gmx dot com]

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

Bug ID: 81369
   Summary: [8 Regression] ICE in generate_code_for_partition
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20170709 snapshot ICEs when compiling the following snippet w/
-O2 -ftree-loop-distribution:

int wo;

void
sy (long int *as)
{
  for (;;)
{
  *as = wo;
  while (as < 2)
{
  int *y9;

  if (wo != 0)
*y9 = 
  wo /= (wo != 0 && *y9 != 0);
  ++as;
}
}
}

% gcc-8.0.0-alpha20170709 -O2 -ftree-loop-distribution -c -w bghwqvet.c
during GIMPLE pass: ldist
bghwqvet.c: In function 'sy':
bghwqvet.c:4:1: internal compiler error: in generate_code_for_partition, at
tree-loop-distribution.c:1146
 sy (long int *as)
 ^~

[Bug target/79145] [5/6 Regression] iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

[petrcvekcz at gmail dot com]

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

Petr Cvek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Petr Cvek  ---
Compilation does not fail.

Thanks for the fix.

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #23 from Dominique d'Humieres  ---
> Fixed.

Nope! Revision r249926 has several fall out for which I have to file relevant
PRs. In addition Jan Hubicka asked me on IRC to back port the fix. Please let
me manage this PR without interfering.

[Bug c++/65775] Late-specified return type bypasses return type checks (qualified, function, array)

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

--- Comment #5 from Volker Reichelt  ---
*** Bug 38797 has been marked as a duplicate of this bug. ***

[Bug c++/38797] [c++0x] Missing warning about type qualifiers on late function return types

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #3 from Volker Reichelt  ---
The check now works for late-specified return types due to PR65775.
Therefore, marking as duplicate.

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

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
(In reply to Yuri Gribov from comment #5)
> Well, as we all know there are a lot of missing optimizations in GCC :) I
> think the real question is whether it's ever going to be fixed if there's no
> standard API for this code pattern which we can recognize as builtin.
> 
> I believe the answer is "No". ATM GCC does not vectorize even the simplest
> memcpy equivalent code:
>   // gcc tmp.c -O3 -mtune=native -ftree-vectorize -o- -S
>   void memcpy_(char * __restrict a, char * __restrict b, unsigned n) {
> unsigned i;
> for (i = 0; i < n; ++i)
>   a[i] = b[i];
>   }

Please look again. ldist turns this into a call to memcpy. And if you disable
ldist, it does get vectorized.

[Bug middle-end/81368] GCC reports bad option if -fdata-sections/-ffunction-sections is specified through #pragma or function attribute

[sebastian.schrader at ossmail dot de]

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

--- Comment #3 from sebastian.schrader at ossmail dot de ---
I see. Is it just a limitation of the current implementation of
-fdata-sections/-ffunction-sections in GCC that it can't be unset or is it
generally impossible?

[Bug middle-end/81368] GCC reports bad option if -fdata-sections/-ffunction-sections is specified through #pragma or function attribute

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
What I meant is once -fdata-sections/-ffunction-section is set, it cannot be
unset.  That meant in GCC 5.4, the option was not working correctly; just
working accidentally the way you wanted it to work.

[Bug middle-end/81368] GCC reports bad option if -fdata-sections/-ffunction-sections is specified through #pragma or function attribute

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
Most likely this should never have been accepted in previous versions of GCC in
that those versions had a bug.

[Bug c/81368] New: GCC reports bad option if -fdata-sections/-ffunction-sections is specified through #pragma or function attribute

[sebastian.schrader at ossmail dot de]

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

Bug ID: 81368
   Summary: GCC reports bad option if
-fdata-sections/-ffunction-sections is specified
through #pragma or function attribute
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.schrader at ossmail dot de
  Target Milestone: ---

GCC 7.1.1 reports a bad option if -fdata-sections or -ffunction-section is
specified through the #pragma GCC optimize directive or the optimize function
attribute.

Earlier versions of GCC, such as 5.4.0 don't report a bad option and also act
upon  it (verified with objdump -x).

Example with #pragma:
#pragma GCC optimize("-ffunction-sections")

int f(int x)
{
return x;
}

% gcc -o pragma.o -c pragma.c
pragma.c:1:9: warning: bad option ‘-ffunction-sections’ to pragma ‘optimize’
[-Wpragmas]
 #pragma GCC optimize("-ffunction-sections")
 ^~~
pragma.c:4:1: warning: bad option ‘-ffunction-sections’ to attribute ‘optimize’
[-Wattributes]
 {
 ^

Example with attribute:
__attribute__((optimize("-fdata-sections")))
int g(int x)
{
return x;
}

% gcc -o attribute.o -c attribute.c
attribute.c:3:1: warning: bad option ‘-fdata-sections’ to attribute ‘optimize’
[-Wattributes]
 {
 ^

[Bug libgomp/81336] OpenMP crash if -fno-underscoring is used in gfortran

[bburgerm at googlemail dot com]

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

--- Comment #3 from bburgerm at googlemail dot com ---
Yes, I'm using this option because the gfortran code should be included in a
larger project with a mixture of C, C++, gfortran and partially intel fortran
code with several libraries only available in binary form. Due to the lack of
gfortran function attributes to define the symbol explicitly, using
-fno-underscoring was the most successfull solution. Using bind(C) did not work
for all functions because gfortran is quite picky regarding variable types
(like it is not possible to pass a fortran user defined type with an
allocatable variable to a C function which only passes it to a fortran function
without reading or touching it. For example a dlopen-wrapper).

As mentioned above I have read the warnings about -fno-underscoring and only
filed a bug report because the bug is already visible for the small attached
program only using libraries that are also part of gcc.

If it would have happened for our large project only, then I would accept it as
the described incompatibilities.

Btw: The same problem appears for omp_set_num_threads using the pointer value
as number of threads if -fno-underscoring is used from fortran which usually
leads to a crash.

[Bug tree-optimization/81365] [7/8 Regression] GCC miscompiles swap

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.2

--- Comment #2 from Andrew Pinski  ---
  /* As we replicate the lhs on each incoming edge all
 used SSA names have to be available there.  */
  if (! for_each_index (gimple_assign_lhs_ptr (use_stmt),
chk_uses,
get_immediate_dominator (CDI_DOMINATORS,
 gimple_bb (phi
goto next;

This is supposed to check correctly but it does not ...

[Bug target/81313] Bad stack realignment code with -mno-accumulate-outgoing-args

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from H.J. Lu  ---
Fixed for 8.0.

[Bug target/81313] Bad stack realignment code with -mno-accumulate-outgoing-args

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jul  9 21:01:42 2017
New Revision: 250086

URL: https://gcc.gnu.org/viewcvs?rev=250086=gcc=rev
Log:
PR target/81313
* gcc.dg/stack-layout-dynamic-1.c (bar): Add 4 additional
integer argumets to bypass x86_64 outgoing args optimization.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/stack-layout-dynamic-1.c

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

[tetra2005 at gmail dot com]

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

--- Comment #5 from Yuri Gribov  ---
(In reply to Marc Glisse from comment #4)
> (In reply to Yuri Gribov from comment #3)
> > As noted in comments, this is more about adding new API to Glibc than GCC
> > (they have corresponding
> > https://sourceware.org/bugzilla/show_bug.cgi?id=19920 about this). So can
> > this be closed?
> 
> I don't think so (at least not for that reason). Whatever glibc does, this
> is still a missed optimization in gcc.

Well, as we all know there are a lot of missing optimizations in GCC :) I think
the real question is whether it's ever going to be fixed if there's no standard
API for this code pattern which we can recognize as builtin.

I believe the answer is "No". ATM GCC does not vectorize even the simplest
memcpy equivalent code:
  // gcc tmp.c -O3 -mtune=native -ftree-vectorize -o- -S
  void memcpy_(char * __restrict a, char * __restrict b, unsigned n) {
unsigned i;
for (i = 0; i < n; ++i)
  a[i] = b[i];
  }
so I don't think it'll be able to recognize memcchr in reasonable timeframe.

Adding a std. function in Glibc and then treating it as std. builtin in GCC
would be straightforward and cost-effective solution but the ball is on Glibc
side and they didn't sound very positive.

Thoughts?

[Bug target/81365] [7/8 Regression] GCC miscompiles swap

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-09
Summary|GCC miscompiles swap|[7/8 Regression] GCC
   ||miscompiles swap
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
phiprop seems responsible, it changes

+   [34.00%]:
+  x.head[0] = MEM[(const struct Lit &) + 12];
+
[99.97%]:
-  # it_16 = PHI <(2), [(void *) + 16B](3)>
+  # it_16 = PHI <(9), [(void *) + 16B](10)>
   t$rep_15 = MEM[(struct Foo *)];
-  x.head[0] = MEM[(const struct Lit &)it_16];
   MEM[(struct Lit *)it_16] = t$rep_15;

but x.head[0] and MEM[(struct Foo *)] are the same location...


extern "C" int puts(const char *);
struct Lit {
  unsigned rep;
};

struct Foo {
  Foo(const Lit* lits) {
__builtin_memcpy(head , lits, 3*sizeof(Lit));
__builtin_memcpy(tail , lits + 3, sizeof(Lit));
__builtin_memset(tail+1 , 0, sizeof(Lit));
  }
  bool swapToHead(unsigned what){
Lit* it = tail;
if (it->rep == what || (++it)->rep == what) {
  Lit t(head[0]);
  head[0]=*it;
  *it=t;
  return true;
}
return false;
  }
  Lit head[3];
  Lit tail[2];
};

int main() {
  Lit lits[] = {4,8,12,18};
  Foo x(lits);
  x.swapToHead(18) || (puts("1"),__builtin_abort(),false);
  x.swapToHead( 4) || (puts("2"),__builtin_abort(),false);
  return 0;
}

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #22 from Andrew Pinski  ---
Fixed.

[Bug fortran/81367] New: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1086

[s.j.clark at durham dot ac.uk]

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

Bug ID: 81367
   Summary: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1086
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s.j.clark at durham dot ac.uk
  Target Milestone: ---

Coding error causes internal compiler error. Narrowed down to this test code:

program test
  implicit none
contains
  subroutine thing()
character(len=f)::fname
  end subroutine thing
end program test


Note attempted declaration of character with unset variable, inheriting
"implicit none" from main.

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Yuri Gribov from comment #3)
> As noted in comments, this is more about adding new API to Glibc than GCC
> (they have corresponding
> https://sourceware.org/bugzilla/show_bug.cgi?id=19920 about this). So can
> this be closed?

I don't think so (at least not for that reason). Whatever glibc does, this is
still a missed optimization in gcc.

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

[tetra2005 at gmail dot com]

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

--- Comment #3 from Yuri Gribov  ---
As noted in comments, this is more about adding new API to Glibc than GCC (they
have corresponding https://sourceware.org/bugzilla/show_bug.cgi?id=19920 about
this). So can this be closed?

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[a...@cloudius-systems.com]

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

--- Comment #7 from Avi Kivity  ---
Hitting something similar-looking on Fedora 26's gcc 7.1.1.

[Bug target/81313] Bad stack realignment code with -mno-accumulate-outgoing-args

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sun Jul  9 18:25:49 2017
New Revision: 250084

URL: https://gcc.gnu.org/viewcvs?rev=250084=gcc=rev
Log:
x86: Use DRAP only if there are outgoing arguments on stack

Since DRAP is needed only if there are outgoing arguments on stack, we
should track outgoing arguments on stack and avoid setting need_drap to
true when there are no outgoing arguments on stack.

gcc/

PR target/81313
* config/i386/i386.c (ix86_function_arg_advance): Set
outgoing_args_on_stack to true if there are outgoing arguments
on stack.
(ix86_function_arg): Likewise.
(ix86_get_drap_rtx): Use DRAP only if there are outgoing
arguments on stack and ACCUMULATE_OUTGOING_ARGS is false.
* config/i386/i386.h (machine_function): Add
outgoing_args_on_stack.

gcc/testsuite/

PR target/81313
* gcc.target/i386/pr81313-1.c: New test.
* gcc.target/i386/pr81313-2.c: Likewise.
* gcc.target/i386/pr81313-3.c: Likewise.
* gcc.target/i386/pr81313-4.c: Likewise.
* gcc.target/i386/pr81313-5.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81313-1.c
trunk/gcc/testsuite/gcc.target/i386/pr81313-2.c
trunk/gcc/testsuite/gcc.target/i386/pr81313-3.c
trunk/gcc/testsuite/gcc.target/i386/pr81313-4.c
trunk/gcc/testsuite/gcc.target/i386/pr81313-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/81341] trunk/gcc/fortran/class.c:313: redundant condition ?

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Dominique d'Humieres  ---
Closing as FIXED.

[Bug fortran/81341] trunk/gcc/fortran/class.c:313: redundant condition ?

[dominiq at gcc dot gnu.org]

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

--- Comment #2 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Jul  9 17:41:45 2017
New Revision: 250083

URL: https://gcc.gnu.org/viewcvs?rev=250083=gcc=rev
Log:
2017-07-09  Dominique d'Humieres  

PR fortran/81341
* class.c (class_array_ref_detected): Remove a redundant
condition.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c

[Bug c++/81366] New: pragma omp simd reduce(max:m) not vectorizing

[ryan.burn at gmail dot com]

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

Bug ID: 81366
   Summary: pragma omp simd reduce(max:m) not vectorizing
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Compiling this code:

###
double max(double* x, int n) {
  double m = 0;
  int i;
#pragma omp simd linear (i) reduction(max:m)
  for (i=0; i

[Bug sanitizer/81066] sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined

[fw at gcc dot gnu.org]

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

--- Comment #8 from Florian Weimer  ---
(In reply to Khem Raj from comment #7)
> (In reply to Florian Weimer from comment #6)
> > (In reply to Khem Raj from comment #5)
> > > +#ifndef __stack_t_defined
> > > +struct stack_t;
> > > +#endif
> > 
> > Where does __stack_t_defined come from?  If this is the definition from the
> > glibc headers, that's really brittle because it's totally internal.
> 
> infact it is from bits/types/stack_t.h so you are right. sanitizers redefine
> a lot
> of stuff from libc. So we can not include signal.h without such quirks

I think you should change the signature of internal_sigaltstack.  Something
like

  void internal_sigaltstack(void *, size_t);

should work, due to the way the function is used.  Then you'll need to
reference the stack_t type only within its implementation (at which point, I
assume, it is safe to include glibc's ).

As far as I understand the interface, there is no need to keep the actual
stack_t object around while the alternative signal stack is in use.

[Bug target/81365] New: GCC miscompiles swap

[kaufmann at cs dot uni-potsdam.de]

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

Bug ID: 81365
   Summary: GCC miscompiles swap
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaufmann at cs dot uni-potsdam.de
  Target Milestone: ---

Created attachment 41700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41700=edit
Minimal test case

For the attached code, gcc miscompiles the call to swap in Foo::swapToHead()
with the result that the value of 'a' is lost.

gcc-7.1 miscompiles the code at -O2 and above (-O1 and above if std::swap is
used) at least with x86_64-pc-linux-gnu.

gcc-6.3 compiles the code correctly.

### Relevant sequence of instructions:
movedx,edx
learcx,[rdi+0x8]   ; tail[0]
movDWORD PTR [rdi+rdx*4+0x10],esi  ; store to head_[1] - This does not seem
to be right
moveax,DWORD PTR [rdi+rdx*4+0x10]
movDWORD PTR [rcx],eax ; now head_[1] and tail[0] are the same

### COMMAND:
g++ -O3  bug-min.ii
./a.out

### EXPECTED OUTPUT:
(rc=0)

### ACTUAL OUTPUT:
x.swapToHead(Lit::make( 2), 1) && "Lit 2 went missing"
Aborted

### g++ -v
Using built-in specs.
COLLECT_GCC=/home/wv/bin/linux/64/gcc-7.1/bin/g++
COLLECT_LTO_WRAPPER=/home/wv/bin/linux/64/gcc-7.1/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../../sources/gcc-7.1.0/configure
--prefix=/home/wv/bin/linux/64/gcc-7.1 --enable-languages=c,c++
Thread model: posix
gcc version 7.1.0 (GCC)

[Bug libfortran/80365] undefined memcpy while writing zero length array on unformatted stream in unix.c

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
Or you may add

assert(buf);

just before the memcpy library call.

If nbyte==0 then it should be harmless, but undefined.

assert(buf || !nbyte) should catch an error situation

[Bug libfortran/80365] undefined memcpy while writing zero length array on unformatted stream in unix.c

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> How do I actually obtain this error?

I see it with a build configured with

Configured with: ../work/configure --prefix=/opt/gcc/gcc8g
--enable-languages=c,c++,fortran --with-gmp=/opt/mp-new --with-system-zlib
--with-isl=/opt/mp-new --disable-bootstrap --disable-multilib
--disable-libstdcxx CFLAGS='-L/opt/gcc/gcc7a/lib -lasan -lubsan
-fsanitize=address,undefined,leak -Og -g -fno-omit-frame-pointer'
CXXFLAGS='-fsanitize=address,undefined,leak -Og -g -fno-omit-frame-pointer'
LDFLAGS='-L/opt/gcc/gcc7a/lib -lasan -lubsan -ldl -lpthread'

../../../work/libgfortran/io/unix.c:597:7: runtime error: null pointer passed
as argument 2, which is declared to never be null

at run time.

[Bug libfortran/80365] undefined memcpy while writing zero length array on unformatted stream in unix.c

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
How do I actually obtain this error?

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[simon at pushface dot org]

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

--- Comment #21 from simon at pushface dot org ---
Actually, r249930 was the last related revision (cleans up spaces).

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[simon at pushface dot org]

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

--- Comment #20 from simon at pushface dot org ---
r249926

See https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00121.html

Re: Is this a bug or... did I goof?

[Jonathan Wakely]

On 08/07/17 20:01 +, George R Goffe via gcc-bugs wrote:

Hį

I have experienced this bug for the past 2-3 days. I'm not sure if it's a bug 
or I have missed something important.

I have a complete build log available if needed. Here's the tail of the log.

Thanks ahead of time for your help.

George..

libtool: compile:  /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc -shared-libgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc -nostdinc++ 
-L/tools/gcc/obj-i686-pc-linux-gnu/x86_64-pc-linux-gnu/libstdc++-v3/src 
-L/tools/gcc/obj-i686-pc-linux-gnu/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
-L/tools/gcc/obj-i686-pc-linux-gnu/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -B/usr/lsd/Linux/x86_64-pc-linux-gnu/bin/ 
-B/usr/lsd/Linux/x86_64-pc-linux-gnu/lib/ -isystem 
/usr/lsd/Linux/x86_64-pc-linux-gnu/include -isystem 
/usr/lsd/Linux/x86_64-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-DHAVE_RPC_XDR_H=1 -DHAVE_TIRPC_RPC_XDR_H=0 -I. 
-I../../../../gcc/libsanitizer/sanitizer_common -I.. -I 
../../../../gcc/libsanitizer/include -isystem 
../../../../gcc/libsanitizer/include/system -Wall -W -Wno-unused-parameter 
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions 
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden 
-Wno-variadic-macros -I../../libstdc++-v3/include 
-I../../libstdc++-v3/include/x86_64-pc-linux-gnu 
-I../../../../gcc/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I 
../../../../gcc/libsanitizer/../libbacktrace -I ../libbacktrace -I 
../../../../gcc/libsanitizer/../include -include 
../../../../gcc/libsanitizer/libbacktrace/backtrace-rename.h -g -O2 
-D_GNU_SOURCE -MT sanitizer_stoptheworld_linux_libcdep.lo -MD -MP -MF 
.deps/sanitizer_stoptheworld_linux_libcdep.Tpo -c 
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
  -fPIC -DPIC -o .libs/sanitizer_stoptheworld_linux_libcdep.o
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:
 In function 'int __sanitizer::TracerThread(void*)':
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:276:22:
 error: aggregate 'sigaltstack handler_stack' has incomplete type and cannot be 
defined
  struct sigaltstack handler_stack;
 ^
make[4]: *** [Makefile:523: sanitizer_stoptheworld_linux_libcdep.lo] Error 1
make[4]: Leaving directory 
'/export/home/tools/gcc/obj-i686-pc-linux-gnu/x86_64-pc-linux-gnu/libsanitizer/sanitizer_common'
make[3]: *** [Makefile:467: all-recursive] Error 1
make[3]: Leaving directory 
'/export/home/tools/gcc/obj-i686-pc-linux-gnu/x86_64-pc-linux-gnu/libsanitizer'
make[2]: *** [Makefile:337: all] Error 2
make[2]: Leaving directory 
'/export/home/tools/gcc/obj-i686-pc-linux-gnu/x86_64-pc-linux-gnu/libsanitizer'
make[1]: *** [Makefile:16706: all-target-libsanitizer] Error 2
make[1]: Leaving directory '/export/home/tools/gcc/obj-i686-pc-linux-gnu'
make: *** [Makefile:950: all] Error 2


This mailing list is for automated email from GCC's bugzilla database,
and sending email directly to it might be missed or ignored.

Please use gcc-help for this kind of question, or just report it to
Bugzilla. There misght be a missing header or config problem in
libsanitizer.

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[d25fe0be at outlook dot com]

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

--- Comment #19 from d25fe0be@  ---
Bootstrap seems to work for me now.

Not sure which revision brings it back to normal though.

[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems

[simon at pushface dot org]

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

--- Comment #4 from simon at pushface dot org ---
(In reply to Eric Botcazou from comment #2)

When I said in comment 1 

>I have to say that, great as it would be to have this fixed, the changes 
>required would be extensive, and I can’t see that anyone would think it 
>worth the trouble.

I meant that coping with macOS’s HFS+ behaviour w.r.t. NFC vs NFD was 
something it’d be unreasonable to spend effort on fixing.

The main point of this PR is that you can’t use extended characters in 
unit names on case-insensitive filesystems, *which includes Windows*. 
Fixing that problem (I can see it might mean introducing a new adaint.c 
interface "is filesystem UTF8?") would be a good thing. Can the compiler 
use iconv? or Ada.Wide_Characters.Handling,
Ada.Strings.UTF_Encoding.[Wide_]Strings?

The awkwardness discussed in comment 1 isn’t really a problem except 
when compiling the offending unit from the command line; when compiled 
as part of the closure by gnatmake there’s no problem, I guess gnatmake 
reads the unit name in NFC and gets the file name in NFD from the file 
system.

I think there _is_ a problem in gprbuild but of course that’s nothing 
to do with GCC.

Please can this PR be reopened?

[Bug ada/62236] : error: aggregate value used where an integer was expected

[porton at narod dot ru]

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

Victor Porton  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.1.0
 Resolution|--- |FIXED
  Known to fail||6.1.1

--- Comment #8 from Victor Porton  ---
Found to be fixed in gcc version 7.1.0.

[Bug ada/81361] Exceptions mishandled (_Unwind_Resume() can't return)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-09
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
We have something like that on Linux too, probably one of Jan's changes.