[Bug c++/84080] New: the compiler crashes when compiling the following sample file

[fabio at cannizzo dot net]

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

Bug ID: 84080
   Summary: the compiler crashes when compiling the following
sample file
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fabio at cannizzo dot net
  Target Milestone: ---

The command

# g++ -c prova.cpp -o prova.o

prova.cpp:9:42: internal compiler error: Segmentation fault
template <> auto foo() { return a1; }
^

cause a g++ crash with the following input file:

// prova.cpp
enum aa {a1};
enum bb {b1};

enum cc {ca1, cb1};

template  T foo();

template <> auto foo() { return a1; }
template <> auto foo() { return b1; }

Tested on Linux Arch

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
I think this bug is invalid and gfortran is correct.

If you do this:


 ta(1:8)%c = 'bogus'
/

You get what you expect.  The way you have it, you can not put 8 strings called
'bogus' into one strng element of ta.

Anyine else have any thoughts on this?

[Bug c++/82541] Wduplicated-branches triggers in template context

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/84079] missing -Warray-bounds taking the address of a multidimensional array element

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||56456
  Known to fail||4.1.0, 4.5.4, 4.8.3, 4.9.4,
   ||5.4.0, 6.3.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
This was never diagnosed so it's not a regression.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug c/55422] gcc does not diagnose change of linkage for a function.

[cookevillain at yahoo dot com]

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

--- Comment #7 from cookevillain at yahoo dot com ---
(In reply to Andrew Pinski from comment #5)
> The first example is invalid C90 anyways:
> t4.c:10:3: error: ISO C90 forbids mixed declarations and code [-Wpedantic]

I forgot to mention it in my previous comment: this remark has also been
addressed byt the newer example. The only reason ff(0); was there to begin with
was to avoid a warning that ff is not used (which is irrelevant to the case at
hand but I wanted 'gcc is quiet' mean just that)

[Bug c++/83924] ICE: Error reporting routines re-entered with -Wduplicated-branches

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #3 from Paolo Carlini  ---
Thanks Marek, I added the testcase.

[Bug c++/83924] ICE: Error reporting routines re-entered with -Wduplicated-branches

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sun Jan 28 01:28:05 2018
New Revision: 257131

URL: https://gcc.gnu.org/viewcvs?rev=257131=gcc=rev
Log:
2018-01-27  Paolo Carlini  

PR c++/83924
* g++.dg/warn/Wduplicated-branches5.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches5.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/84079] New: missing -Warray-bounds taking the address of a multidimensional array element

[msebor at gcc dot gnu.org]

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

Bug ID: 84079
   Summary: missing -Warray-bounds taking the address of a
multidimensional array element
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Warray-bounds checker correctly diagnoses the out-of-bounds references in
the first two functions in the test case below but misses the third, even
though the referenced (nonexistent) element is at the same offset from the end
of the array in both g() and h().  (It's valid to take address of a[2] when a
has just two elements, but it is invalid to take the address of an element of
the subarray a[2].)

$ cat t.c && gcc -O2 -S -Warray-bounds=2 t.c
int a[2][3];

int f (void)
{
  return a[2][0];   // -Warray-bounds (good)
}

int* g (void)
{
  return [3][2];   // -Warray-bounds (good)
}

int* h (void)
{
  return [2][3];   // missing -Warray-bounds
}
t.c: In function ‘f’:
t.c:5:11: warning: array subscript 2 is above array bounds of ‘int[2][3]’
[-Warray-bounds]
   return a[2][0];   // -Warray-bounds (good)
  ~^~~
t.c: In function ‘g’:
t.c:10:10: warning: array subscript 3 is above array bounds of ‘int[2][3]’
[-Warray-bounds]
   return [3][2];   // -Warray-bounds (good)
  ^~~~

[Bug c/55422] gcc does not diagnose change of linkage for a function.

[cookevillain at yahoo dot com]

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

cookevillain at yahoo dot com changed:

   What|Removed |Added

Version|4.4.3   |5.4.0

--- Comment #6 from cookevillain at yahoo dot com ---
I still believe (although it has been almost six years since the original
report) that gcc's diagnostics are inconsistent in this case. Here is a
slightly different version of the input above:

static void ff(int a) {

  return;

}

int f(void) {

  {
int ff = 0;

{

  extern void ff(int);

}

return ff;
  }

  ff(0);
}

gcc is silent about this file in every mode (c89, c11, etc.) although the only
difference between this code and the other example above is that ff is declared
as a function. I understand that gcc does not have to produce a diagnostic for
every undefined behavior (such as ff having both external and internal linkage
as above) but since it already diagnoses it for ordinary variables, why not
functions?

[Bug fortran/83152] Possible run time error in derived type i/o

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jerry DeLisle  ---
No further comment, not a bug as far as I can see.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #15 from Jonathan Wakely  ---
I'd like to add a workaround so it works with older GDB versions. There's more
to life than ensuring our testsuite has no FAILs :-)

[Bug middle-end/84078] New: false positive for -Wmaybe-uninitialized

[samuel.thiba...@ens-lyon.org]

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

Bug ID: 84078
   Summary: false positive for -Wmaybe-uninitialized
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: samuel.thiba...@ens-lyon.org
  Target Milestone: ---

Created attachment 43265
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43265=edit
testcase

Hello,

The attached testcase compiled with -O2 -Wall produces

test.c:30:2: warning: 'c' may be used uninitialized in this function
[-Wmaybe-uninitialized]
  printf("%d %d %d\n", a, b, c);
  ^
test.c:30:2: warning: 'b' may be used uninitialized in this function
[-Wmaybe-uninitialized]
test.c:30:2: warning: 'a' may be used uninitialized in this function
[-Wmaybe-uninitialized]

while they are only used when `err' is equal to zero, and in the only case
where that happens, they do get initialized.

This is the minimal testcase I could reduce to, it seems both the asm snippet
and testing its result does make a difference, as well as the two ifs and the
three variables.

I could verify this with gcc snapshot 20180124 (Debian buster x86_64)

Samuel

[Bug target/84077] Likely wrong code with `__builtin_expect()` on i686-linux-gnu

[floessie.mail at gmail dot com]

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

--- Comment #1 from Flössie  ---
Created attachment 43264
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43264=edit
Preprocessed file

[Bug target/84077] New: Likely wrong code with `__builtin_expect()` on i686-linux-gnu

[floessie.mail at gmail dot com]

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

Bug ID: 84077
   Summary: Likely wrong code with `__builtin_expect()` on
i686-linux-gnu
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: floessie.mail at gmail dot com
  Target Milestone: ---

Created attachment 43263
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43263=edit
CMake generated compile command line

Hi,

We're having some strange behavior with `__builtin_expect()` on
i686-linux-gnu in RawTherapee, probably due to wrong code generation.
The `__builtin_expect()` is used as

#define LIKELY(x)   __builtin_expect (!!(x), 1)

in our code and employed in an `if` within an OpenMP for loop:

https://github.com/Beep6581/RawTherapee/blob/f5bd232cd2a1d709a25c3b3feda88ebf86dd6092/rtengine/dcp.cc#L1077

When compiling RawTherapee on i686 with a vanilla GCC 7.3 a RAW with
a supplied DCP base table will show obviously wrong colors. This is
neither the case with (the Debian) GCC 6.4 on i686 nor with GCC 7.2
on x86_64, but also with GCC 7.2 on i686.

We've worked around that problem by disabling the use of `__builtin_expect()`
on 32 bit platforms with GCC >= 7 for now. See

https://github.com/Beep6581/RawTherapee/pull/4324#issuecomment-360110007

for the original issue.

Reproducing the problem requires building RawTherapee. You can find
instructions for various distributions here:

http://rawpedia.rawtherapee.com/Linux

After cloning, please checkout the commit right before we worked around
the bug:

git checkout f5bd232cd2a1d709a25c3b3feda88ebf86dd6092

You can find an image to test here:

http://rawtherapee.com/shared/test_images/amsterdam.pef

As soon as you open it, the wrong colors will be apparent, as the DCP
base table should be active, otherwise you can find it on the "Color"
tab.

If I forgot anything, just let me know. I can also test patches against
vanilla GCC 7.3.

On behalf of the RawTherapee team,
Flössie

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[emsr at gcc dot gnu.org]

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

--- Comment #5 from emsr at gcc dot gnu.org ---
In a way, I *am* treating this as a char array n the C side and it would
probably be most correct to have

character(kind=c_char)  thing(42).

and get

char thing[42];

honestly.

Is there a way in Fortran to convert, or alias such an array to a character
string?

Ed

This is probably WONTFIX PEBKAC.

[Bug preprocessor/66505] -Wno-error=pedantic does not reverse -Werror -Wpedantic

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=53075

--- Comment #2 from Eric Gallager  ---
Related to bug 53075

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
The real error is that lengths unequal to one are not
C interoperable, and should be rejected.

From the F2003 standard, 15.2.1:

"if the type is character, inter-
operability also requires that the length type parameter be omitted or be
specified by an initialization
expression whose value is one."

[Bug c/23087] Misleading warning, "... differ in signedness"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #18 from Eric Gallager  ---
(In reply to Bernd Schmidt from comment #15)
> Joseph, based on gcc-patches discussion, should we close this as invalid, or
> do you think there is a beneficial change that could be made?

(In reply to Keith Thompson from comment #17)
> I just took a quick look at the discussion on the gcc-patches mailing
> list.
> 

Link to the gcc-patches archives where this discussion took place?

[Bug preprocessor/49973] Column numbers count special characters as multiple columns

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69664

--- Comment #12 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #11)
> This should be fixed in libcpp, probably in lex.c, but maybe other places
> also. A good testcase to start with would be:
> 
> /* ñ /* */
> /* a /* */
> 
> cc1 -Wcomment
> 
> prog.cc:1:7: warning: "/*" within comment [-Wcomment]
>  /* ñ /* */
>^
> prog.cc:2:6: warning: "/*" within comment [-Wcomment]
>  /* a /* */
>   ^
> 
> Both locations should point to column 6. Look for places where column info
> is converted to source_location (linemap_position_for_column or
> linemap_position_for_line_and_colum). Figure out where the column info got
> the wrong value. Use something like wcwidth() to measure the width of
> non-ASCII characters and get the right width of 'ñ'.
> 
> Unfortunately, GCC 6 seems to be broken for the above testcase
> (https://gcc.gnu.org/PR69664). Revision 229665 seems fine.

Bug 69664 is fixed now.

[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug c/53129] Wself-assign

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #0)
> 
> An implementation was submitted to GCC but never approved here:
> 
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02390.html

Adding the "patch" keyword

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
On AVX512 machine, r257121 gave:

FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c (test for excess errors)
FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c (test for excess errors)
FAIL: gcc.target/i386/avx512bitalgvl-vpopcntw-1.c execution test
FAIL: gcc.target/i386/avx512bitalgvl-vpopcntw-1.c execution test
FAIL: gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c execution test
FAIL: gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c execution test

[Bug target/83905] ix86_expand_epilogue modifies the copy of cfun->machine->frame

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 8 and GCC 7.4.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #14 from H.J. Lu  ---
Fixed by gdb.

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[emsr at gcc dot gnu.org]

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

--- Comment #3 from emsr at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> Withe the following change
> 
> --- pr84073.f90   2018-01-26 22:48:32.0 +0100
> +++ pr84073_db.f902018-01-27 00:03:06.0 +0100
> @@ -13,10 +13,10 @@ module utderror
>  integer(c_int):: nerrorloc
>  real(c_double):: errorstartloc(3)
>  real(c_double):: errorendloc(3)
> -character(kind=c_char, len=41) :: errorsubsystem
> -character(kind=c_char, len=9) :: errorseverity
> +character(kind=c_char) :: errorsubsystem(41)
> +character(kind=c_char) :: errorseverity(9)
>  integer(c_int):: errorid
> -character(kind=c_char, len=1001) :: errormessage
> +character(kind=c_char) :: errormessage(1001)
>end type
>  
>type(utderror_t), bind(c), save :: utderror_v
> 
> I get
> 
> ...
> char errorsubsystem[41];
> char errorseverity[9];
> int errorid;
> char errormessage[1001];
> } utderror_t;
> void add_utd_error (int *ierror);
> extern utderror_t utderror_v;
> 
> Possibly related to PR38506.

Yes, I tries this.
On the Fortran side, the arrays of character are not recognized as strings. 
You can't use // and len and such.
I'll just do this one by hand until the new array descriptors are in.
Thanks for the feature and the look anyway.

I wonder if a -ffortran-interfaces from C/C++ would be of use to anyone.

[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

[vladimir.fuka at gmail dot com]

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

--- Comment #3 from Vladimir Fuka  ---
The bug has been around for so long that I already forgot I saw these problems
before.

[Bug rtl-optimization/81443] [8 regression] build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #21 from Wilco  ---
See also PR84071 which has bad codegen from r242326.

[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #2 from Wilco  ---
(In reply to Andrew Pinski from comment #1)
> I think this is related to PR 81443.  Can you see if the 7.3 release has it
> fixed?

It's related indeed, in both cases it incorrectly uses load_extend_op on
registers rather than MEM. The first primarily fails on targets that return
ZERO_EXTEND, the 2nd on targets that use SIGN_EXTEND.

[Bug objc/77428] incorrect 'set but not used' warning with @throw

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Tom de Vries from comment #1)
> Created attachment 39528 [details]
> tentative patch

Have you sent this patch to the gcc-patches mailing list yet?

[Bug c/51088] undefined label with statement expression and cond expression

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Marek Polacek from comment #5)
> Patch to give an error if taking an address of a label defined in ({}):
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00381.html

Does this patch still apply against more recent GCC?

[Bug other/35511] release scripts added release note to zlib/ChangeLog, not zlib/ChangeLog.gcj

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-27
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> (In reply to Debian GCC Maintainers from comment #0)
> > the release scripts added the release note for 4.3.0 to zlib/ChangeLog
> > (upstream), not zlib/ChangeLog.gcj
> 
> IMO zlib/ChangeLog.gcj should be renamed since gcj has been removed from gcc.

Putting this in WAITING for someone else's opinion

[Bug objc++/66504] ICE using C++ exceptions in Objective-C++

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

  Known to work||4.7.4, 4.8.5, 5.5.0, 6.4.0,
   ||7.2.0

--- Comment #2 from Eric Gallager  ---
Huh, I tested this testcase with more versions of gcc, and it works with all
the versions I have installed from MacPorts, but still fails with the latest
version I built myself... maybe it's a difference in configure options?
Although I try to keep mine pretty similar to those that MacPorts uses...

[Bug objc++/49070] [6/7/8 regression] ObjC++ compiler fails to compile ObjC method invocations without keyword arguments

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Priority|P3  |P4
   Target Milestone|--- |6.4
Summary|ObjC++ compiler fails to|[6/7/8 regression] ObjC++
   |compile ObjC method |compiler fails to compile
   |invocations without keyword |ObjC method invocations
   |arguments   |without keyword arguments

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> 
> I also checked with an older version of g++ (Apple's 4.0.1) and can confirm
> that the older version compiled it successfully.

...therefore, I'm adding the regression marker

[Bug plugins/83442] FAIL: gcc.dg/plugin/expensive-selftests-1.c -- timeout

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from John David Anglin  ---
Test no longer fails.

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[wbx at openadk dot org]

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

--- Comment #21 from Waldemar Brodkorb  ---
I can confirm that this fixes the problem even for gcc 7.x.
Any chance to get it included into gcc 7 branch?

No regression found while running the uClibc-ng testsuite inside
qemu-system-m68k.

Thanks a lot!

[Bug bootstrap/38743] libgcc multilib fails if not able to exec "non" native programs

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > a patch like http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00474.html is
> > needed for libgcc.
> 
> Confirming that libgcc/configure.ac is still missing something like that.

(the linked patch is for libiberty, not libgcc, so I can't add the "patch"
keyword yet)

[Bug bootstrap/43301] top-level configure script ignores ---with-build-time-tools

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> (In reply to Ryan Johnson from comment #0)
> > ./configure ... --with-build-time-tools=$MY_TOOLS ignores $MY_TOOLS (though
> > it correctly warns when $MY_TOOLS is not an absolute path).
> > 
> > Let's just say this led to extremely frustrating behavior until I decided to
> > start digging...
> > 
> > Suggested patch to correct the problem:
> > 
> > Index: /home/Ryan/apps/gcc-4.5-src/configure.ac
> > ===
> > --- /home/Ryan/apps/gcc-4.5-src/configure.ac(revision 157227)
> > +++ /home/Ryan/apps/gcc-4.5-src/configure.ac(working copy)
> > @@ -3221,7 +3221,9 @@
> >[  --with-build-time-tools=PATH
> >use given path to find target tools during the
> > build],
> >[case x"$withval" in
> > - x/*) ;;
> > + x/*)
> > +   with_build_time_tools=$withval
> > +   ;;
> >   *)
> > with_build_time_tools=
> > AC_MSG_WARN([argument to --with-build-time-tools must be an absolute
> > path])
> 
> Confirming that GCC's configure.ac is still unpatched.

Patches go to the gcc-patches mailing list if you still want to see this fixed

[Bug c++/84076] New: [5/6/7/8 Regression] Warning about objects through POD mistakenly claims the object is a pointer

[sgunderson at bigfoot dot com]

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

Bug ID: 84076
   Summary: [5/6/7/8 Regression] Warning about objects through POD
mistakenly claims the object is a pointer
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com
  Target Milestone: ---

Test program:

#include 
#include 

int main(void)
{
std::string str;
printf("%s\n", str);
}

GCC 4.9 and older gives:

test.cpp: In function ‘int main()’:
test.cpp:7:20: error: cannot pass objects of non-trivially-copyable type
‘std::string {aka class std::basic_string}’ through ‘...’
  printf("%s\n", str);
^

GCC 5.0 and newer (including 7.3.0) prints:

test.cpp: In function ‘int main()’:
test.cpp:7:20: warning: format ‘%s’ expects argument of type ‘char*’, but
argument 2 has type ‘std::__cxx11::string* {aka
std::__cxx11::basic_string*}’ [-Wformat=]
  printf("%s\n", str);
^

This is a confusing warning, since it claims I'm sending a std::string * when
I'm sending a std::string. In particular, in the program I was trying to fix
this by adding ->c_str(), but .c_str() was the correct choice.

[Bug target/83905] ix86_expand_epilogue modifies the copy of cfun->machine->frame

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sat Jan 27 13:10:24 2018
New Revision: 257123

URL: https://gcc.gnu.org/viewcvs?rev=257123=gcc=rev
Log:
i386: Use const reference of struct ix86_frame to avoid copy

We can use const reference of struct ix86_frame to avoid making a local
copy of ix86_frame.  ix86_expand_epilogue makes a local copy of struct
ix86_frame and uses the reg_save_offset field as a local variable.  This
patch uses a separate local variable for reg_save_offset.

Tested on x86-64 with ada.

Backport from mainline
PR target/83905
* config/i386/i386.c (ix86_expand_prologue): Use cost reference
of struct ix86_frame.
(ix86_expand_epilogue): Likewise.  Add a local variable for
the reg_save_offset field in struct ix86_frame.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386.c

[Bug plugins/83442] FAIL: gcc.dg/plugin/expensive-selftests-1.c -- timeout

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
Do the other plugins in plugin.exp work, or is it just this one?

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[koh...@t-online.de]

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

--- Comment #13 from Heinz Kohl  ---
O.k., but following your arguments I'd expect 0xb as result for my second
example 0xb.3590da0e2a06736p-3 (attachment 41578), but it's giving 0, also
stopping at 'x' and not at '.', just as in the first case.

It might be just another case of the same problem, but I'm not sure.

An actual test run:

./a.out
Parsing 0x1P-1022 as hex gives 0
Parsing '0xb.3590da0e2a06736p-3 xyz' as hex gives 0 xb.

(The source code for the second example is:
  std::istringstream("0xb.3590da0e2a06736p-3 xyz") >> std::hexfloat >> g >> a
>> b >> c ;
  std::cout << "Parsing '0xb.3590da0e2a06736p-3 xyz' as hex gives " << g << ' '
<< a << b << c << std::endl; 
)

[Bug middle-end/67220] GCC fails to properly handle libcall symbol visibility of builtin functions

[edlinger at gcc dot gnu.org]

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

--- Comment #5 from Bernd Edlinger  ---
FYI the C++ FE behaves differently:

cat x.cc
typedef __SIZE_TYPE__ size_t;
extern "C" void *memset(void *s, int c, size_t n)
  __attribute__ ((visibility ("hidden")));

void
foo1 (void *s, size_t n)
{
  memset (s, '\0', n);
}

void
foo2 (void *s, int c, size_t n)
{
  memset (s, c, n);
}

gcc -Wall -O2 -fPIC -S x.cc
x.cc:2:18: warning: 'void* memset(void*, int, size_t)': visibility attribute
ignored because it conflicts with previous declaration [-Wattributes]
 extern "C" void *memset(void *s, int c, size_t n)
  ^~
: note: previous declaration of 'void* memset(void*, int, size_t)'

[Bug fortran/84065] [8 regression] string_1.f90 fails since r256944

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jan 27 10:28:20 2018
New Revision: 257121

URL: https://gcc.gnu.org/viewcvs?rev=257121=gcc=rev
Log:
PR fortran/84065
* decl.c (add_init_expr_to_sym): Ignore initializers for too large
lengths.

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

[Bug fortran/41137] inefficient zeroing of an array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #20 from Dominique d'Humieres  ---
For the test in comment 0, I get

  0.107776999
  0.108125009

with gcc6, 7, and trunk (8.0) if I use -O3 or -Ofast, -O2 gives

  0.107547000
  0.569643974

Could this PR be considered FIXED?

[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Zero sized object occupies zero bytes, if you have an array of them,
necessarily all the elements of the array need to have the same address.  While
individual variables could be in theory padded, it would be a waste of address
space for something that doesn't need to occupy any address space. 
Furthermore, in your testcase the objects are common variables, so it is the
linker that allocates them.  If you need unique addresses, just don't use zero
sized objects, if you don't mind them, forcing everyone to have unique
addresses might be a misoptimization for them.

[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address

[uecker at eecs dot berkeley.edu]

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

--- Comment #5 from Martin Uecker  ---
(In reply to Jakub Jelinek from comment #4)
> If you want aggregate with size 1 and isn't used to store information, use
> typedef struct { char : 1; } zero;
> instead.

Yes, thank you.

But for my understanding: Is there a reason why it is important that zero-sized
objects should sometimes have the same address? I am wondering because I think
zero-sized arrays would make sense to allow in C (it sometimes makes
programming edge cases simpler in numerical code) and at the same time I think
it might be a nice principle to require that all unique objects existing at the
same time should also have a unique address.

[Bug c++/84075] New: Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’

[matteo-ml at member dot fsf.org]

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

Bug ID: 84075
   Summary: Template parameter not resolved: invalid application
of ‘sizeof’ to incomplete type
‘boost::serialization::U’
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matteo-ml at member dot fsf.org
  Target Milestone: ---

Created attachment 43262
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43262=edit
Preprocessed file

I encounter the following error when building a C++ source file doing some
moderately deep template instantiation due to Eigen + Boost.Serialization. 
I cannot reproduce the same error on a minimal example, although I tried. Clang
builds the same sources fine (and the resulting linked binary runs correctly).
I can reproduce the same problem also with older g++ versions.

// -

$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-1'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-1) 

// -

FAILED: CMakeFiles/gadv-backend.dir/gadv-backend/logic/petri-net.cc.o 
/usr/bin/g++  -Dgadv_EXPORTS -Dgadv_backend_EXPORTS
-I/home/matteo/Progetti/gadv/include -Iinclude
-I/home/matteo/Progetti/gadv/src/gadv-backend -isystem /usr/include/eigen3
-isystem /usr/include/pangomm-1.4 -isystem
/usr/lib/x86_64-linux-gnu/pangomm-1.4/include -isystem /usr/include/glibmm-2.4
-isystem /usr/lib/x86_64-linux-gnu/glibmm-2.4/include -isystem
/usr/include/cairomm-1.0 -isystem /usr/lib/x86_64-linux-gnu/cairomm-1.0/include
-isystem /usr/include/sigc++-2.0 -isystem
/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -isystem /usr/include/pango-1.0
-isystem /usr/include/harfbuzz -isystem /usr/include/cairo -isystem
/usr/include/glib-2.0 -isystem /usr/lib/x86_64-linux-gnu/glib-2.0/include
-isystem /usr/include/pixman-1 -isystem /usr/include/freetype2 -isystem
/usr/include/libpng16 -ftemplate-backtrace-limit=0 -fdiagnostics-color=always
-O3 -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden   -Wall
-pedantic -fstack-protector-strong -std=gnu++1z -MD -MT
CMakeFiles/gadv-backend.dir/gadv-backend/logic/petri-net.cc.o -MF
CMakeFiles/gadv-backend.dir/gadv-backend/logic/petri-net.cc.o.d -o
CMakeFiles/gadv-backend.dir/gadv-backend/logic/petri-net.cc.o -c
/home/matteo/Progetti/gadv/gadv-backend/logic/petri-net.cc
In file included from /usr/include/eigen3/Eigen/Core:351:0,
 from /usr/include/eigen3/Eigen/SparseCore:11,
 from
/home/matteo/Progetti/gadv/include/gadv/logic/petri-net.hh:24,
 from
/home/matteo/Progetti/gadv/gadv-backend/logic/petri-net.cc:18:
/usr/include/eigen3/Eigen/src/Core/NumTraits.h: In instantiation of ‘struct
Eigen::GenericNumTraits’:
/usr/include/eigen3/Eigen/src/Core/NumTraits.h:150:29:   required from ‘struct
Eigen::NumTraits’
/usr/include/eigen3/Eigen/src/SparseCore/SparseMatrixBase.h:109:30:   required
from ‘class
Eigen::SparseMatrixBase >’
/usr/include/eigen3/Eigen/src/SparseCore/SparseCompressedBase.h:36:7:  
required from ‘class
Eigen::SparseCompressedBase >’
/usr/include/boost/serialization/split_free.hpp:58:13:   recursively required
by substitution of ‘template class SPT> void
boost::serialization::load(Archive&, SPT&, unsigned
int) [with Archive = boost::archive::xml_iarchive; SPT = ]’
/usr/include/boost/serialization/split_free.hpp:58:13:   required from ‘static
void boost::serialization::free_loader::invoke(Archive&, T&,
unsigned int) [with Archive = boost::archive::xml_iarchive; T =