[Bug preprocessor/66322] New: Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things

[t.artem at mailcity dot com]

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

Bug ID: 66322
   Summary: Linus Torvalds: -Wswitch-bool produces dubious
warnings, fails to notice really bad things
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

From: https://lkml.org/lkml/2015/5/27/941

Btw, I'd actually like to see (possibly optionally) a warning for enum
types there too. Exactly because *type* based warnings very much make
sense, regardless of number of cases.

For example, try this:

#include 
#include 

enum a { one, two };
int t(bool b, enum a e)
{
switch (b) {
case true:
printf("No arguments\n");
/* fallthrough */
case false:
printf("\n");
}
switch (e) {
case 0:
printf("one");
break;
case two:
printf("two");
break;
}
return 0;
}
and I'd argue that gcc-5.1 warns about TOTALLY THE WRONG THING.

It does that *stupid* warning:

warning: switch condition has boolean value [-Wswitch-bool]

which is just idiotic and wrong.

The case statements are clearly boolean, there is absolutely nothing
wrong with that switch, and a compiler that warns about it is just
being f*cking moronic.

In contrast, that second switch() statement with the "case 0:" is
actually something that might well be worth warning for. I'd argue
that the code would clearly be more legible if it used "case one:"
instead.

So the new warning in gcc-5 seems to be just stupid. In general,
warnings that encourage you to write bad code are stupid. The above

switch (boolean) {
case true:
is *good* code, while the gcc documentation suggests that you should
cast it to "int" in order to avoid the warning, but anybody who
actually thinks that

switch ((int)boolean) {
switch 1:
is better, clearly has absolutely zero taste and is just objectively wrong.

Really. A warning where the very *documentation* tells you to do
stupid things is stupid.

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[e29253 at jp dot ibm.com]

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

--- Comment #3 from Tatsushi Inagaki  ---
Created attachment 35641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35641&action=edit
gdb session of callback() called from runtime.Caller(skip==3)

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[e29253 at jp dot ibm.com]

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

--- Comment #2 from Tatsushi Inagaki  ---
The first invocation of runtime.Caller() with skip==2 successfully detects
kickoff() in callback(), and thus returns ok==true.

The problem is that the succeeding invocations of runtime.Caller() with
skip==3, 4, 5, ... still continue returning ok==true. This is because
callback() returns index==1 and a non-zero pc, which are recognized as valid
information by runtime.Caller() in runitme/go-caller.c. I attached a gdb
session of the second invocation of runtime.Caller() with skip==3.

[Bug c++/66316] Usage of wrong template function for classes in different modules but having the same name

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
As mentioned the names are actually exported, just the diagnostic is required
if they don't match.

[Bug c++/66316] Usage of wrong template function for classes in different modules but having the same name

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to Alexander Trufanov from comment #0)
> Application has two .cpp modules. Let's say 1.cpp and 2.cpp.
> In each module there is a definition of struct N. Name N is the same for
> both. So we have two different structure declarations with the same name N.
> Compiler gives ok for such naming as they are not exposed from their modules
> and used internally in them. No namespaces are used.
> 
> And structures have different number of fields. One has 1 field and another
> is 6 fields long.

You are violating the One Definition Rule, that's a bug in your program. If you
want names to be local, you can use an anonymous namespace.

Note that the word "module" in unclear. Those are two translation units. If you
compile them into separate shared libraries (for instance), using private
visibility could also help.

[Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
You're right that the text of diagnostics is outside the scope of the C
standard.  But as you note, even diagnostics are relied on by tools to
manipulate the referenced files, and changing the file names in the compiler
output would break such tools.

For example, in Emacs Compilation Mode
(http://www.gnu.org/software/emacs/manual/html_node/emacs/Compilation-Mode.html)
if diagnostics in a file named "beep\a.c" were introduced by the string
"beep.c:" instead, Emacs would no longer be able to open the file.

On the other hand, "beep\a.c" seems like a corner case not worth worrying
about, and since most multibyte encodings (with the exception of ISO 10646)
seem to take care to avoid using control characters for the second and
subsequent bytes, maybe the impact of such filtering wouldn't be as bad as
might at first seem, especially if an option were provided to disable the
filtering.  David Wheeler presents some good arguments in favor of restricting
the set of valid file name characters in his paper on Fixing Unix/Linux/POSIX
Filenames:
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html

[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm

[hong.gyu.kim at lge dot com]

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

--- Comment #26 from Honggyu Kim  ---
(In reply to ktkachov from comment #25)
> This should be fixed on trunk for GCC 6.
> I'll keep this open for a few days to make sure there are no glaring
> complaints about the patch as it gets through the auto-testers

I have checked that the patch has been merged.
I appreciate your work. Thank you.

Honggyu

[Bug fortran/66311] [5 Regression] Problems with some integer(16) values

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-28
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jerry DeLisle  ---
Confirmed.  Wow something broke here. I won't have tome until next week to
start a regression hunt.  Using -fdump-tree-original, one can see the different
resulting constants, so it is something in the front-end.

[Bug target/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[thopre01 at gcc dot gnu.org]

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

--- Comment #11 from Thomas Preud'homme  ---
(In reply to John David Anglin from comment #10)
> Thanks Thomas for your analysis.

You're welcome. I'm glad you fixed the issue so quickly.

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
I do not think this is a bug. First the function repeat is evaluated and the
result must allocate a large amount of memory to hold the constant "z".

Then when writing the constant out, a buffer is created which requires another
allocation, and finally since this is formatted output, though list directed,
the routines have to account for things like positioning of the formatted
result and thus we have another buffer to support all the unanticipated things
that may have to be done to the output.  The fbuf is dynamically sized as
needed and in this case gets large also.

So there is a practical limit you are hitting with this obscure case.  I would
lean toward a don't fix on this one.  Putting it another way, why should we
develop special code just to handle this case?  Yes we could turn it into a big
do loop rather than a large constant, it's just not worth the effort.

[Bug target/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #10 from John David Anglin  ---
Thanks Thomas for your analysis.

[Bug target/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[danglin at gcc dot gnu.org]

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

--- Comment #9 from John David Anglin  ---
Author: danglin
Date: Thu May 28 01:17:52 2015
New Revision: 223794

URL: https://gcc.gnu.org/viewcvs?rev=223794&root=gcc&view=rev
Log:
PR target/66148
* config/pa/pa.c (pa_emit_move_sequence): Correct placement of
REG_EQUAL note when doing insert.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/pa/pa.c

[Bug target/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[danglin at gcc dot gnu.org]

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

--- Comment #8 from John David Anglin  ---
Author: danglin
Date: Thu May 28 01:15:46 2015
New Revision: 223793

URL: https://gcc.gnu.org/viewcvs?rev=223793&root=gcc&view=rev
Log:
PR target/66148
* config/pa/pa.c (pa_emit_move_sequence): Correct placement of
REG_EQUAL note when doing insert.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/pa/pa.c

[Bug target/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[danglin at gcc dot gnu.org]

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

--- Comment #7 from John David Anglin  ---
Author: danglin
Date: Thu May 28 01:12:59 2015
New Revision: 223792

URL: https://gcc.gnu.org/viewcvs?rev=223792&root=gcc&view=rev
Log:
PR target/66148
* config/pa/pa.c (pa_emit_move_sequence): Correct placement of
REG_EQUAL note when doing insert.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/pa/pa.c

[Bug target/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[danglin at gcc dot gnu.org]

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

--- Comment #6 from John David Anglin  ---
Author: danglin
Date: Thu May 28 01:09:59 2015
New Revision: 223791

URL: https://gcc.gnu.org/viewcvs?rev=223791&root=gcc&view=rev
Log:
PR target/66148
* config/pa/pa.c (pa_emit_move_sequence): Correct placement of
REG_EQUAL note when doing insert.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c

[Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things

[Keith.S.Thompson at gmail dot com]

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

--- Comment #2 from Keith Thompson  ---
Martin:

Good point.  I don't suggest altering the string to which the __FILE__
macro expands, merely sanitizing file names to be displayed in error
messages.

I see my original description wasn't 100% clear.

If you execute

cpp red_green.c

or

gcc -E red_green.c

the preprocessed output goes to stdout. If it includes ugly garbage,
well, that's what you asked for. The error message goes to stderr;
I'm suggesting sanitizing that.

If you execute

gcc -c red_green.c

the preprocessed output is passed to the next phase of the compiler and
is not seen by the user.  I suggest that any diagnostic messages should
be sanitized. There's no requirement for a compiler's diagnostic output
to include any particular content.

I suppose some tools could parse that diagnostic output, and misbehave if
it includes something other than the literal file name.  But I suggest
that if either an actual file name or the value of __FILE__ contains
control characters, the risk of writing those control characters to the
user's terminal exceeds the cost of breaking such tools.

Perhaps an option could be added to print raw file names unconditionally
in diagnostic messages.  It should be turned off by default; otherwise
there's not much point in making a change from the current behavior.
The idea is to protect users who compile possibly malicious source files.

[Bug fortran/66321] New: [4.9.2/5.1.0/6.0.0] errors allocating allocatable array component of pointer object component

[damian at sourceryinstitute dot org]

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

Bug ID: 66321
   Summary: [4.9.2/5.1.0/6.0.0] errors allocating allocatable
array component of pointer object component
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

Possibly this bug is related to Bug 56471 (which is oustanding) and/or Bug
65841 (which has been fixed).  The code listing below demonstrates what appears
to be a rejection of valid code in gfortran versions 4.9.2, 5.1.0, and 6.0.0. 
After commenting the offending line, the resulting code generates a runtime
segmentation fault when the subsequent line attempts automatically allocate the
variable whose explicit source allocation was rejected in the original code.

Both versions of the code compile and execute cleanly with the Cray, Portland
Group, NAG, and Intel compilers.

Damian


localhost:seg-fault rouson$ cat compile-time-error.f90 
type Bar
   integer, allocatable :: a(:)
end type 
type Foo
  type (bar), pointer :: b
end type 
type(Foo) f
allocate(f%b)
allocate(f%b%a,source=[3]) ! Compile-time error
f%b%a = [3] ! Run-time seg fault
end 

localhost:seg-fault rouson$ gfortran compile-time-error.f90 
compile-time-error.f90:9:9:

 allocate(f%b%a,source=[3]) ! Compile-time error
 1
Error: Array specification required in ALLOCATE statement at (1)

localhost:seg-fault rouson$ sed 's/allocate(f%b%a/!allocate(f%b%a/' <
compile-time-error.f90 > run-time-error.f90
localhost:seg-fault rouson$ gfortran run-time-error.f90 

localhost:seg-fault rouson$ ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x10ad0ab26
#1  0x10ad0a0c3
#2  0x7fff8a317f19
#3  0x10ad03e5e
#4  0x10ad03ea0
Segmentation fault: 11
localhost:seg-fault rouson$ gfortran --version
GNU Fortran (MacPorts gcc6 6-20150510_0) 6.0.0 20150510 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.

[Bug c++/66320] New: internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.c:3524

[allan at archlinux dot org]

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

Bug ID: 66320
   Summary: internal compiler error: in
cxx_eval_constant_expression, at cp/constexpr.c:3524
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: allan at archlinux dot org
  Target Milestone: ---

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

An ICE seen in gcc-5-20150519.  gcc-4.8.2 works.

A reduced (but not minimal) testcase is attached.

g++ -std=c++14 testcase.ii

[Bug gcov-profile/66319] New: [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[danglin at gcc dot gnu.org]

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

Bug ID: 66319
   Summary: [6 Regression] gcov-tool.c:84:65: error: invalid
conversion from 'int (*)(const c har*, const stat*,
int, FTW*)' to 'int (*)(const char*, const stat*, int,
FTW)'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: tsaunders at mozilla dot com
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

g++ -std=c++98 -c   -g -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwi
nd-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-error
-DHAVE_CONFIG_H -I. -I. -
I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../l
ibcpp/include -I/opt/gnu/gcc/gmp/include  -I../../gcc/gcc/../libdecnumber
-I../.
./gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace 
  -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gmp/include 
-I../../gcc/gcc/../libdecnu
mber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/gcc/../li
bbacktrace  -o libgcov-util.o ../../gcc/gcc/../libgcc/libgcov-util.c
../../gcc/gcc/gcov-tool.c: In function 'int unlink_profile_dir(const char*)':
../../gcc/gcc/gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const
c
har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)' 
[-fpermissive]
 return nftw(path, unlink_gcda_file, 64, FTW_DEPTH | FTW_PHYS);
 ^
In file included from ../../gcc/gcc/gcov-tool.c:39:0:
/usr/include/ftw.h:240:13: note:   initializing argument 2 of 'int nftw(const
ch
ar*, int (*)(const char*, const stat*, int, FTW), int, int)'
  inline int nftw(const char *a,int (*b)(const char *, const struct
 ^
make[3]: *** [gcov-tool.o] Error 1

The problem is function declaration of unlink_gcda_file doesn't match
declaration in In file included from ../../gcc/gcc/gcov-tool.c:39:0:
/usr/include/ftw.h:240.  Whether the fourth argument is "struct FTW *"
or "struct FTW" depends on compilation defines:

#ifdef _INCLUDE_XOPEN_SOURCE_EXTENDED
/*
 * Do Mapping of nftw() */
#if (defined(_XPG4_EXTENDED) && !defined(_INCLUDE_HPUX_SOURCE)) ||
defined(_XOPE
N_SOURCE_EXTENDED)
inline int nftw(const char *a,int (*b)(const char *,
const struct stat *, int, struct FTW *), int c, int d)
{return __nftw64(a,b,c,d);}
#else /* (defined(_XPG4_EXTENDED) && !defined(_INCLUDE_HPUX_SOURCE)) ||
defined(
_XOPEN_SOURCE_EXTENDED) */
inline int nftw(const char *a,int (*b)(const char *, const struct
stat *, int, struct FTW), int c, int d)
{return __nftw64(a,b,c,d);}
#endif /* (defined(_XPG4_EXTENDED) && !defined(_INCLUDE_HPUX_SOURCE)) ||
defined
(_XOPEN_SOURCE_EXTENDED) */
#endif /* _INCLUDE_XOPEN_SOURCE_EXTENDED */

Sadly, unlink_gcda_file doesn't use this argument.

Probably introduced by

2015-02-09  Trevor Saunders  

PR gcov-profile/61889
* config.in: regenerate.
* configure.in: Likewise.
* configure.ac: Check for ftw.h.
* gcov-tool.c: Check for ftw.h before using nftw.

and my switch to building with gcc-5.  There were numerous successful builds
after the above change was applied.

[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #23 from Jan Hubicka  ---
OK, I got here from discussion at
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02577.html because I am trying to
get the canonical type calculation to the more standard compliant shape.

My reading of the standard is that the variable in question should be
interoperable with int, not struct {int}, because I do not see any derived type
in Fortran source.

In that case it would be nice to make gfortran to just drop the struct for
BIND(C) types if possible. Making this work on LTO level probably means to peel
off single element struct/aggregate. Other variant is to simply punt those
types to alias set 0.

So in this case I would agree with Tobias, Comment #22, but this is my first
even attempt to make sense of Fortran standard.

As for legacy code, perhaps gfortran can propagate BIND(C) to middle-end (i.e.
add type attribute "bind_c" to those types) and we could add a warning when
fortran declaration of type !bind_c gets merged with non-fortran declaration in
lto-symtab and hopefully help people to annotate their source codes.

[Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The set of valid characters in a #line directive includes escape sequences. 
Unconditionally filtering some of them out from the preprocessor output would
violate the requirements of the C standard and could cause it to break other
tools that depend on it when such sequences were present in the name of a
source file being preprocessed.

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||nathan at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED
 CC||nathan at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

[Bug preprocessor/66318] New: Error messages contain raw file name; malicious #line directives can do bad things

[Keith.S.Thompson at gmail dot com]

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

Bug ID: 66318
   Summary: Error messages contain raw file name; malicious #line
directives can do bad things
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Keith.S.Thompson at gmail dot com
  Target Milestone: ---

Error messages include the (presumed) name of the source file in which
the error was detected. The #line directive can set the presumed file name
to nearly any arbitrary string, possibly including control characters.

A directive like:

#line __LINE__ "beep\a.c"

can cause every printed error message to beep.  More malicious #line
directives can cause even more obnoxious behavior.

The sample file shown below, when fed through the preprocessor (either
directly or via the "gcc" command), will change the screen foreground
to green and the background to red if the command is run under xterm.

Depending on which terminal emulator is being used and how it's
configured, it might even be possible to trigger arbitrary code execution
just by compiling a source file.

System: Linux Mint 17.
gcc version 5.1.0, built from source with:
gcc-5.1.0/configure --prefix=/usr/local/apps/gcc-5.1.0 --disable-multilib

Test case (a 2 line source file named "red_green.c"):
#line __LINE__ "'\x1b]10;green\a\x1b]11;red\a'"
#error "Argh! My eyes!"

Output of "cpp red_green.c 2>&1 | cat -A":
'^[]10;green^G^[]11;red^G':1:2: error: #error "Argh! My eyes!"$
# 1 "red_green.c"$
# 1 ""$
# 1 ""$
# 1 "/usr/include/stdc-predef.h" 1 3 4$
# 1 "" 2$
# 1 "red_green.c"$
# 1 "'^[]10;green^G^[]11;red^G'"$

See the "xtermcontrol" command for other possibilities. Even if
arbitrary command execution isn't possible, maximizing the current
window and rapidly alternating between red and green would be at least
seriously annoying, and at worst potentially dangerous to epileptics
(the latter is speculation on my part).

Suggested fix: Sanitize the displayed file name for error messages so
only printable characters are displayed (presumably affected by the
current locale).

[Bug preprocessor/66317] New: Preprocessor chokes on __FILE__ containing a newline

[Keith.S.Thompson at gmail dot com]

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

Bug ID: 66317
   Summary: Preprocessor chokes on __FILE__ containing a newline
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Keith.S.Thompson at gmail dot com
  Target Milestone: ---

This is an obscure problem, unlikely to occur in the real world.
I do not suggest handling it "correctly", whatever that might mean,
just detecting it and terminating with a reasonable error message.

The problem can also occur if the actual file name contains a newline.

System: Linux Mint 17.
gcc version 5.1.0, built from source with:
gcc-5.1.0/configure --prefix=/usr/local/apps/gcc-5.1.0 --disable-multilib

Test case (a 2 line source file named "filename_bug.c"):
#line 1 "new\nline.c"
const char filename[] = __FILE__;

Output of "cpp filename_bug.c" (there is no newline on the last line of
output):
# 1 "filename_bug.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "filename_bug.c"
# 1 "new
line.c"
new
line.c:1:1: warning: missing terminating " character
new
line.c:1:25: internal compiler error: invalid built-in macro "__FILE__"
0x6449a8 c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char
const*, __va_list_tag (*) [1])
../gcc-5.1.0/gcc/c-family/c-common.c:10029
0xf6664a cpp_diagnostic
../gcc-5.1.0/libcpp/errors.c:60
0xf66776 cpp_error(cpp_reader*, int, char const*, ...)
../gcc-5.1.0/libcpp/errors.c:75
0xf74158 builtin_macro
../gcc-5.1.0/libcpp/macro.c:471
0xf748ed enter_macro_context
../gcc-5.1.0/libcpp/macro.c:1247
0xf7643d cpp_get_token_1
../gcc-5.1.0/libcpp/macro.c:2526
0x65830f scan_translation_unit
../gcc-5.1.0/gcc/c-family/c-ppoutput.c:192
0x65830f preprocess_file(cpp_reader*)
../gcc-5.1.0/gcc/c-family/c-ppoutput.c:113
0x656c80 c_common_init()
../gcc-5.1.0/gcc/c-family/c-opts.c:1033
0x5cb33e lang_dependent_init
../gcc-5.1.0/gcc/toplev.c:1845
0x5cb33e do_compile
../gcc-5.1.0/gcc/toplev.c:2062
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
const char filename[] =

[Bug c++/66316] New: Usage of wrong template function for classes in different modules but having the same name

[trufanovan at gmail dot com]

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

Bug ID: 66316
   Summary: Usage of wrong template function for classes in
different modules but having the same name
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trufanovan at gmail dot com
  Target Milestone: ---

gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) 
Full gcc -v output is here: http://pastebin.com/apZhYVUU

gcc is used via latest QtCreator. The problem is reproducible in debug build
mode only. Unfortunately, I don't know which gcc parameters Qt toolchain is
using with debug builds.

Additional parameters specified in my project file: -std=c++11 (may be
irrelevant - didn't check)

Original problem description:
https://github.com/JohnLangford/vowpal_wabbit/issues/655

Description:

Application has two .cpp modules. Let's say 1.cpp and 2.cpp.
In each module there is a definition of struct N. Name N is the same for both.
So we have two different structure declarations with the same name N. Compiler
gives ok for such naming as they are not exposed from their modules and used
internally in them. No namespaces are used.

And structures have different number of fields. One has 1 field and another is
6 fields long.

There is also a template function in a header file 3.h which is used in both (
1.cpp and 2.cpp) for objects allocation. It's:

template 
T* calloc_or_die()
{
  void* data = calloc(1, sizeof(T));
  if (data == nullptr) throw std::exception();
  return (T*)data;
}

Its usage:
 N& data& = *calloc_or_die(); // same usage for both modules

Both cpp files call this function each for its own structure N.

The problem is in following:

In debug builds compiler might use calloc_or_die implementation of one
struct to allocate memory for another. As they have different number of fields
the sizeof(T) will be different. So you might allocate 8 bites (1 field struct)
but access it via pointer to struct with size 48 bites (6 field struct). In
this case if you once write something to fields #2-#6 the app will eventually
randomly crashes with SEGFAULT at some free() function call. free() may be
called even not for these classes. It just some memory corruption flag that
raised after accessing unallocated memory block or something like that.

Valgrind used with -fmudflap flag is able to detect line where memory
corruption happens. Thus I was able to debug this.

I believe that compiler mistakenly links to a wrong implementation of
calloc_or_die. The problem was workarounded by simple renaming struct N
declaration in one of modules to M.

[Bug tree-optimization/66263] [4.8/4.9/5/6 Regression] Performance regression from gcc-4.8 and up (trivial sudoku program)

[bdeyal at gmail dot com]

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

--- Comment #4 from EyalBD  ---
Same results for -fwhole-program too.  gcc-4.6,4.7 around 0.5s, others 0.7-0.8s

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to vries from comment #10)
> Created attachment 35639 [details]
> tentative patch for GOACC_data_end

That is a bad idea, as void GOACC_data_end (void) is already exported out of
libgomp, so this is an ABI break.

If it is meant as a hack around not specifying the functions to aliasing oracle
properly, and not really needed after expansion to RTL, you could e.g. use an
internal function in GIMPLE and then lower it to normal function call that
doesn't take the argument.

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Created attachment 35639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35639&action=edit
tentative patch for GOACC_data_end

[Bug c++/66270] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Patch applied to trunk

[Bug target/39726] [4.8/4.9/5 Regression][cond-optab] ColdFire pessimizations on QImode/HImode tests

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[4.8/4.9/5/6|[4.8/4.9/5
   |Regression][cond-optab] |Regression][cond-optab]
   |ColdFire pessimizations on  |ColdFire pessimizations on
   |QImode/HImode tests |QImode/HImode tests

--- Comment #11 from Jeffrey A. Law  ---
Recently fixed on trunk by a patch to match.pd.  Not planning to backport to
the release branches.

[Bug target/39726] [4.8/4.9/5/6 Regression][cond-optab] ColdFire pessimizations on QImode/HImode tests

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Wed May 27 21:13:25 2015
New Revision: 223781

URL: https://gcc.gnu.org/viewcvs?rev=223781&root=gcc&view=rev
Log:
PR target/39726
* gcc.dg/target/m68k/pr39726-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/m68k/pr39726.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug c++/66270] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Wed May 27 20:36:14 2015
New Revision: 223773

URL: https://gcc.gnu.org/viewcvs?rev=223773&root=gcc&view=rev
Log:
PR c++/66270
* tree.c (build_pointer_type_for_mode): Canonical type does not
inherit can_alias_all.
(build_reference_type_for_mode): Likewise.

PR c++/66270
* g++.dg/ext/alias-canon3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/alias-canon3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c++/66315] New: internal compiler error (segfault) when assigning nested initializer list

[t_glaessle at gmx dot de]

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

Bug ID: 66315
   Summary: internal compiler error (segfault) when assigning
nested initializer list
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t_glaessle at gmx dot de
  Target Milestone: ---

Created attachment 35638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35638&action=edit
preprocessed source

Hey,

starting with g++ 5.1.0, I get the following error from the attached source
file:

$ /usr/bin/g++ -std=c++11 sample.cpp -save-temps

sample.cpp: In function ‘void parse()’:
sample.cpp:11:28: internal compiler error: Segmentation fault
 List l = {{get()}};
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:3: recipe for target 'all' failed

I'm running on up-to-day archlinux 64bit 

$ uname -a

Linux core-problem 4.0.4-2-ARCH #1 SMP PREEMPT Fri May 22 03:05:23 UTC 2015
x86_64 GNU/Linux

I'm not entirely sure this is valid c++ and removing the nested initializer
list solves the problem.

I hope this is the correct location to report the issue and I've included all
the necessary information. Sorry, if this is a duplicate, I did a quick search
but couldn't find anything.

Best regards,
Thomas

[Bug debug/58315] [4.8/4.9/5/6 Regression] Excessive memory use with -g

[jason at gcc dot gnu.org]

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

--- Comment #30 from Jason Merrill  ---
(In reply to Christopher Torres from comment #29)
> > URL: https://gcc.gnu.org/viewcvs?rev=220974&root=gcc&view=rev
> 
> Is there any status updates on this issue? Does this effectively do what
> Alexandre Oliva's patch does?

No, my patch was for a separate, smaller issue that was noticed while
investigating this bug report.

It looks like Alex's patch was being discussed on gcc-patches a couple of
months ago but fell by the wayside; seems a ping would be in order.

[Bug lto/66305] -ffat-lto-objects create unreproducible objects

[andi at firstfloor dot org]

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

--- Comment #4 from andi at firstfloor dot org ---
> --- Comment #3 from lunar at debian dot org ---
> Richard Biener:
> > I think they become deterministic with -frandom-seed=0 for example.
> > They are not deterministic to support partial linking of LTO objects as far
> > as I know.
> 
> They are indeed reproducible with `-frandom-seed=0`. But I guess there's a
> downside to that, right?

The downside is that incremential linking (ld -r) does not work.
But the random seed is used for other things in gcc too, so you may
have other problems too.

> > similar, which would be a bit more deterministic, but there are still
> > ways this could break (e.g. if someone copies object files around)
> 
> Would using a hash over the section content work? In any cases, in the context
> of Debian (this applies for FreeBSD as well), we have a canonical build path
> so it would probably be fine to use it as the source of the hash.
> 
> I guess one could already do this without further help by giving the
> build path to `-frandom-seed=`. This only would need some Makefile trickery.

Yes. It would probably be easier in gcc, e.g. with a new option.

[Bug c/66314] New: ice in verify_loop_structure

[dcb314 at hotmail dot com]

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

Bug ID: 66314
   Summary: ice in verify_loop_structure
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 35637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35637&action=edit
C source code

For trunk gcc dated 20150527

crypto/asymmetric_keys/pkcs7_trust.c: In function ‘pkcs7_validate_trust’:
crypto/asymmetric_keys/pkcs7_trust.c:168:5: error: size of loop 2 should be 36,
not 38
 int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
 ^
crypto/asymmetric_keys/pkcs7_trust.c:168:5: internal compiler error: in
verify_loop_structure, at cfgloop.c:1662
0x7166e3 verify_loop_structure()
../../src/trunk/gcc/cfgloop.c:1662
0xa13f47 loop_optimizer_init(unsigned int)
../../src/trunk/gcc/loop-init.c:124
0xe4a53a execute_vrp
../../src/trunk/gcc/tree-vrp.c:10377
0xe4a53a execute
../../src/trunk/gcc/tree-vrp.c:10474
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Flags -std=gnu89 -Os -fprofile-arcs -fsanitize=kernel-address
required. Code derived from Linux kernel, so probably quite important.

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> IMNSHO it is much better to accurately describe the builtins to the aliasing
> code etc. over adding ugly hacks like the tailcall one, or postponing
> expansion till later etc.

We're discussing two issues now in the PR: GOACC_data_start/end and
GOACC_parallel. The issues are related because in both cases we're trying to
deal with a GOACC builtin acting as an optimization barrier for the kernels
region. The issues are also different because for GOACC_parallel there's an
associated code block, and for GOACC_data_start/end there isn't.

I'm working on fixing the GOACC_data_start/end issue by adding the omp_dara_arr
argument of GOACC_data_start to GOACC_data_end and adding fnspec ".r" to
GOACC_data_end. AFAIU, you agree with that approach.

The GOACC_parallel is more tricky. I don't see what kind of fnspec for
GOACC_parallel could fix this. The only other potential solution I see besides
postponing expansion of the parallel region is ipa_pta. But that's apparently
not production ready yet (PR46032 comment 19). Any other ideas?

[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---



As Kaz mentioned in PR 65979 #c8, first revert all the SH specific patches. 
The SVN revisions are r221686, r221305, r221166, r220957, r220917, r219258. 
Thus you can pull the patches from the GCC SVN and reverse-apply them to your
source tree.

If bootstrap is OK without all the patches, but otherwise the latest 4.8/4.9
source, then obviously the problem must be one of those patches and it can be
narrowed down.  If it doesn't bootstrap even without all those patches, it
means the bugs have been around for a while.

[Bug middle-end/66313] New: Unsafe factorization of a*b+a*c

[glisse at gcc dot gnu.org]

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

Bug ID: 66313
   Summary: Unsafe factorization of a*b+a*c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

int f(int a, int b, int c){
  return a * b + a * c;
}
int main(){
  return f(0, __INT_MAX__, __INT_MAX__);
}

$ gcc -fsanitize=undefined e.c
$ ./a.out
e.c:2:16: runtime error: signed integer overflow: 2147483647 + 2147483647
cannot be represented in type 'int'

But I thought I was only computing 0+0?

f(-1, __INT_MAX__, 1) yields:
e.c:2:16: runtime error: signed integer overflow: 2147483647 + 1 cannot be
represented in type 'int'
e.c:2:10: runtime error: signed integer overflow: -2147483648 * -1 cannot be
represented in type 'int'

I am not very excited about restricting this transformation to
TYPE_OVERFLOW_WRAPS, but the alternative is to cast to unsigned (and back after
the operations), which isn't so nice either.

[Bug target/66312] New: [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 66312
   Summary: [SH] Regression: Bootstrap failure
gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Hello!

As previously stated in [1], filing a new bug report for the gcc-4.8/4.9
bootstrap failure which was introduced recently. As Kaz already pointed out,
the failing reason is most certainly:

> gcc/d/ctfeexpr.dmd.o differs

Build logs:

gcc-4.8:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.8&arch=sh4&ver=4.8.4-2&stamp=1432515052

gcc-4.9:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sh4&ver=4.9.2-18&stamp=1432566734

Unfortunately, Matthias Klose doesn't split the patches in his SVN snapshots,
so I'm not sure how to properly bisect the problem. Any suggestions welcome.

The regression must have come through any of these changes [2].

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979#c35
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979#c8

[Bug lto/66305] -ffat-lto-objects create unreproducible objects

[lunar at debian dot org]

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

--- Comment #3 from lunar at debian dot org ---
Richard Biener:
> I think they become deterministic with -frandom-seed=0 for example.
> They are not deterministic to support partial linking of LTO objects as far
> as I know.

They are indeed reproducible with `-frandom-seed=0`. But I guess there's a
downside to that, right?

Andi:
> In theory it would be possible to use the hash of the full output path name or
> similar, which would be a bit more deterministic, but there are still
> ways this could break (e.g. if someone copies object files around)

Would using a hash over the section content work? In any cases, in the context
of Debian (this applies for FreeBSD as well), we have a canonical build path
so it would probably be fine to use it as the source of the hash.

I guess one could already do this without further help by giving the
build path to `-frandom-seed=`. This only would need some Makefile trickery.

> How about your "deterministic build" tools just learn to ignore that
> suffix?

I am not sure I understand what you are talking about. We want to get
byte-for-byte identical packages on each build (provided the same software
versions are used), so we need a given version of GCC to always produce the
same output.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #35 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #34)
> If 4.8.something doesn't bootstrap, it would be a "4.8 Regression" type of
> bug.  I'd move it to a new PR.

Already. I'll open a new issue then. Just a second.

Adrian

[Bug middle-end/66276] [5/6 Regression] internal compiler error: in get_loop_body, at cfgloop.c:856

[martin.sjolund at liu dot se]

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

--- Comment #6 from Martin Sjölund  ---
Thank you. I can confirm our compiler again bootstraps using gcc 5 branch using
-O2. Sadly, -O2 gives different behaviour than -O1, so I will need to
investigate and possibly file another bug report.

[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed

[gary at intrepid dot com]

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

--- Comment #14 from Gary Funck  ---
*** Bug 66283 has been marked as a duplicate of this bug. ***

[Bug middle-end/66283] [ICE] [IA64] verify type mis-diagnosis: type variant differs by TYPE_NO_FORCE_BLK

[gary at intrepid dot com]

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

Gary Funck  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Gary Funck  ---
Duplicate

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

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
IMNSHO it is much better to accurately describe the builtins to the aliasing
code etc. over adding ugly hacks like the tailcall one, or postponing expansion
till later etc.

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 35636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35636&action=edit
gcc/testsuite/c-c++-common/goacc/kernels-parallel-loop-data-enter-exit-2.c

(In reply to cesar from comment #6)
> Isn't GOACC_parallel likely to have the same problem because hostaddrs may
> be written to?

GOACC_parallel is not declared with a fnspec, so there's no tailcall problem:
...
DEF_GOACC_BUILTIN (BUILT_IN_GOACC_PARALLEL, "GOACC_parallel",
  BT_FN_VOID_INT_OMPFN_SIZE_PTR_PTR_PTR_INT_INT_INT_SIZE_INT_INT_VAR,
  ATTR_NOTHROW_LIST)
...

OTOH, GOACC_parallel is an optimization barrier. So the attached testcase will
fail.  AFAICT, the only way this can be helped is by postponing expansion of
the parallel region until ompexpandssa, in other words do the same as for
kernels.

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[cesar at gcc dot gnu.org]

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

--- Comment #6 from cesar at gcc dot gnu.org ---
Isn't GOACC_parallel likely to have the same problem because hostaddrs may be
written to?

[Bug bootstrap/66304] [6 Regression] Can't bootstrap on x86_64-linux-gnu with gcc 4.3.4

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed May 27 16:09:18 2015
New Revision: 223763

URL: https://gcc.gnu.org/viewcvs?rev=223763&root=gcc&view=rev
Log:
PR bootstrap/66304
config/
* warnings.m4 (ACX_PROG_CXX_WARNING_OPTS)
(ACX_PROG_CXX_WARNINGS_ARE_ERRORS)
(ACX_PROG_CXX_WARNING_ALMOST_PEDANTIC): New.
(ACX_PROG_CC_WARNING_OPTS, ACX_PROG_CC_WARNING_ALMOST_PEDANTIC)
(ACX_PROG_CC_WARNINGS_ARE_ERRORS): Push into C language context.
gcc/
* configure.ac: Use ACX_PROG_CXX_WARNING_OPTS,
ACX_PROG_CXX_WARNING_ALMOST_PEDANTIC, and
ACX_PROG_CXX_WARNINGS_ARE_ERRORS.
* configure: Regenerate.

Modified:
trunk/config/ChangeLog
trunk/config/warnings.m4
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
This patch fixes it, but it's a bit of a hack:
...
diff --git a/gcc/tree-tailcall.c b/gcc/tree-tailcall.c
index 013972d..0cb73a7 100644
--- a/gcc/tree-tailcall.c
+++ b/gcc/tree-tailcall.c
@@ -499,6 +499,8 @@ find_tail_calls (basic_block bb, struct tailcall **ret)
 return;

   /* We found the call, check whether it is suitable.  */
+  if (gimple_call_builtin_p (stmt, BUILT_IN_GOACC_DATA_END))
+return;
   tail_recursion = false;
   func = gimple_call_fndecl (call);
   if (func
...

A better solution is to add the omp_data_arr of the corresponding
GOACC_data_start as an argument to GOACC_data_end (with '.r' fnspec).

[Bug other/66309] difference of 5.1.0 tarball and 4.9.2 tarball + 4.9.2-5.1.0 patch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
If you look carefully, you'll find out that isn't that surprising.
The _static, wdate-time.c and pr65316_1.C files were added post 4.9.2, but as
empty files or directories, so diff can't really represent them.  And
similarly, dso used to be an empty directory in 4.9.2, that has been removed
afterwards.

[Bug target/64159] [5 Regression] FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized "return 28;"

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #8 from ktkachov at gcc dot gnu.org ---
I see this test failing on arm too.
Should it be xfailed there as well?

[Bug fortran/66311] [5 Regression] Problems with some integer(16) values

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Of course, some computations are wrong, too.

For example :

   program p
  integer(8), parameter :: z = huge(1_8)
  print *, 2_16 * z
  print *, 2 * int(z, 16)
  print *, 2_16 * int(z, 16)
  print *, int(2, 16) * int(z, 16)
   end


Result with gfortran 5.1.1 :

 -2
 -2
 -2
 -2

Result with gfortran 4.9.0 and 4.8.3 :

 18446744073709551614
 18446744073709551614
 18446744073709551614
 18446744073709551614


---

Or this variation :

   program p
  integer(16), parameter :: z = huge(1_8)
  print *, 2_16 * z
  print *, 2 * int(z, 16)
  print *, 2_16 * int(z, 16)
  print *, int(2, 16) * int(z, 16)
   end

Result with gfortran 5.1.1 :

 -2
 -2
 -2
 -2

Result with gfortran 4.9.0 and 4.8.3 :

 18446744073709551614
 18446744073709551614
 18446744073709551614
 18446744073709551614

[Bug debug/58315] [4.8/4.9/5/6 Regression] Excessive memory use with -g

[redflames1003 at gmail dot com]

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

Christopher Torres  changed:

   What|Removed |Added

 CC||redflames1003 at gmail dot com

--- Comment #29 from Christopher Torres  ---
(In reply to Jason Merrill from comment #28)
> Author: jason
> Date: Wed Feb 25 15:49:34 2015
> New Revision: 220974
> 
> URL: https://gcc.gnu.org/viewcvs?rev=220974&root=gcc&view=rev
> Log:
>   PR debug/58315
>   * decl.c (start_preparsed_function): Use create_artificial_label
>   for cdtor_label.
> 
> Added:
> trunk/gcc/testsuite/g++.dg/tree-ssa/deleted-label1.C
> Modified:
> trunk/gcc/cp/ChangeLog
> trunk/gcc/cp/decl.c


I also am looking for a fix for this issue. Compile times are at least x2
longer then before when I updated from an older version (from 30-40 minutes to
over 1 1/2 hours).

Is there any status updates on this issue? Does this effectively do what
Alexandre Oliva's patch does?

[Bug fortran/66311] New: [5 Regression] Problems with some integer(16) values

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 66311
   Summary: [5 Regression] Problems with some integer(16) values
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

First of all, it's great to support integer(16).

But printing some numbers from range 2^63 to 2^64-1 with this snippet :

   program p
  print *, 900_16
  print *, huge(1_8)
  print *, 2_16**63
  print *, 1000_16
  print *, 18446744065119617024_16
  print *, 2_16**64 - 1
  print *, 2_16**64
  print *, 2000_16
   end


yields a wrong output for gfortran 5.1.1 (on SUSE Linux 13.2, 64 bit)

 900
  9223372036854775807
 -9223372036854775808
 -8446744073709551616
 -8589934592
 -1
 18446744073709551616
 2000


Whereas with gfortran 4.9.0 and 4.8.3 the printed numbers are correct:

 900
  9223372036854775807
 9223372036854775808
 1000
 18446744065119617024
 18446744073709551615
 18446744073709551616
 2000


---

Same issue for the corresponding negative range :

   program p
  print *, -900_16
  print *, -huge(1_8)
  print *, -(2_16**63)
  print *, -1000_16
  print *, -18446744065119617024_16
  print *, -(2_16**64 - 1)
  print *, -(2_16**64)
  print *, -2000_16
   end


Result with gfortran 5.1.1 :

 -900
 -9223372036854775807
 9223372036854775808
 8446744073709551616
 8589934592
 1
 -18446744073709551616
 -2000


Result with gfortran 4.9.0 and 4.8.3 :

 -900
 -9223372036854775807
 -9223372036854775808
 -1000
 -18446744065119617024
 -18446744073709551615
 -18446744073709551616
 -2000

[Bug fortran/66310] New: Problems with intrinsic repeat for large number of copies

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 66310
   Summary: Problems with intrinsic repeat for large number of
copies
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This small program compiles without any message (gfortran 5.1.1, 4.9.0, 4.8.3)

   program p
  character :: z = 'z'
  print *, repeat(z, huge(1_4))
   end

but running the binary ./a.out yields (e.g. with 5.1.1 on SUSE Linux 13.2, 64
bit) :
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.


Adding a parameter attribute to above source,

   program p
  character, parameter :: z = 'z'
  print *, repeat(z, huge(1_4))
   end

then compilation aborts with :
f951: out of memory allocating 18446744065119617024 bytes after a total of
425984 bytes


The requested memory is about 2^64 bytes and much too large.
huge(1_4) is 2147483647.

Remarks :
The relevant ulimits of the system were unlimited.
The amount of free RAM was much larger than 2 GB.

[Bug other/66309] New: difference of 5.1.0 tarball and 4.9.2 tarball + 4.9.2-5.1.0 patch

[kdevel at vogtner dot de]

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

Bug ID: 66309
   Summary: difference of 5.1.0 tarball and 4.9.2 tarball +
4.9.2-5.1.0 patch
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kdevel at vogtner dot de
  Target Milestone: ---

Downloaded the following files from ftp.gnu.org:

sha1sum   filename
79dbcb09f44232822460d80b033c962c0237c6d8  gcc-4.9.2.tar.bz2
6b80ed93fbacb6448c7ce6443e871c4f7646568d  gcc-4.9.2-5.1.0.diff.bz2
b6c947b09adf780fe02065d0c48bfd7b4bdddfa3  gcc-5.1.0.tar.bz2

$ mkdir a; cd a; tar xf ../gcc-5.1.0.tar.bz2; cd ..
$ mkdir b; cd b; tar xf ../gcc-4.9.2.tar.bz2
$ bzcat ../gcc-4.9.2-5.1.0.diff.bz2 | patch -p0
$ mv gcc-4.9.2 gcc-5.1.0; cd ..
$ diff -r a b

output:
Only in a/gcc-5.1.0/gcc/ada/doc/share: _static
Only in a/gcc-5.1.0/gcc/testsuite/c-c++-common: wdate-time.c
Only in b/gcc-5.1.0/gcc/testsuite/g++.dg: dso
Only in a/gcc-5.1.0/gcc/testsuite/g++.dg/lto: pr65316_1.C

[Bug sanitizer/66308] -fsanitize=alignment is missing "downcast of misaligned address" checks

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #2)
> Only the upcast is really a bug.  Downcasting is not a problem here.

The other way round, but I agree.

However, if the two casts happen in different translation units and only the
upcast is instrumented, it could be useful to get an error pointing out that
you were given a node* that cannot really point to an object of type node.

[Bug sanitizer/66308] -fsanitize=alignment is missing "downcast of misaligned address" checks

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
When accessing the member of the derived type (which is actually misaligned):

struct node_base {
  char c;
};

struct node : node_base {
  long long l;
};

int main()
{
  unsigned char* buf = new unsigned char[sizeof(node)+1];
  node_base* n = (node_base*)(buf+1);
  static_cast(n)->l = 0;
}

GCC complains when the object is in heap memory (but not on the stack):

ubc.cc:13:31: runtime error: member access within misaligned address
0x01c4ac21 for type 'struct node', which requires 8 byte alignment
0x01c4ac21: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
00 00  d1 03 02 00 00
  ^

But not as much as Clang does:


ubc.cc:13:3: runtime error: downcast of misaligned address 0x0269b011 for
type 'node', which requires 8 byte alignment
0x0269b011: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
00 00  e1 0f 02 00 00
  ^ 
ubc.cc:13:26: runtime error: member access within misaligned address
0x0269b011 for type 'node', which requires 8 byte alignment
0x0269b011: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
00 00  e1 0f 02 00 00
  ^ 
ubc.cc:13:26: runtime error: store to misaligned address 0x0269b019 for
type 'long long', which requires 8 byte alignment
0x0269b019: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  e1 0f 02 00 00 00
00 00  00 00 00 00 00
  ^ 


I don't know ow many of these extra errors from clang are useful here, but for
the previous two cases the cast is undefined behaviour (the misaligned address
means the node_base* cannot point to a subobject of a node) and so there should
be some ubsan error.

[Bug sanitizer/66308] -fsanitize=alignment is missing "downcast of misaligned address" checks

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Only the upcast is really a bug.  Downcasting is not a problem here.

[Bug sanitizer/66308] -fsanitize=alignment is missing "downcast of misaligned address" checks

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
When the char member is accessed:

struct node_base {
  char c;
};

struct node : node_base {
  long long l;
};

int main()
{
  unsigned char buf[sizeof(node_base)+1];
  node_base* n = (node_base*)(buf+1);
  (void) static_cast(n)->c;
}

GCC again doesn't complain, but Clang complains about the downcast again and
also an upcast (when accessing the member of the base):

ubb.cc:13:10: runtime error: downcast of misaligned address 0xffedafe3 for type
'node', which requires 4 byte alignment
0xffedafe3: note: pointer points here
 ff  f0 d5 06 08 00 00 00 00  00 00 00 00 73 3b 6f 4a  01 00 00 00 84 b0 ed ff 
8c b0 ed ff 20 69 61
  ^ 
ubb.cc:13:10: runtime error: upcast of misaligned address 0xffedafe3 for type
'node', which requires 4 byte alignment
0xffedafe3: note: pointer points here
 ff  f0 d5 06 08 00 00 00 00  00 00 00 00 73 3b 6f 4a  01 00 00 00 84 b0 ed ff 
8c b0 ed ff 20 69 61
  ^

[Bug sanitizer/66308] New: -fsanitize=alignment is missing "downcast of misaligned address" checks

[redi at gcc dot gnu.org]

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

Bug ID: 66308
   Summary: -fsanitize=alignment is missing "downcast of
misaligned address" checks
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

GCC doesn't give any runtime error for this testcase:

struct node_base {
  char c;
};

struct node : node_base {
  long long l;
};

int main()
{
  unsigned char buf[sizeof(node_base)+1];
  node_base* n = (node_base*)(buf+1);
  (void) static_cast(n);
}

Clang says:

uba.cc:13:10: runtime error: downcast of misaligned address 0x7ffdd521f2eb for
type 'node', which requires 8 byte alignment
0x7ffdd521f2eb: note: pointer points here
 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  65 1d e2 36 32 00 00 00 
00 00 00 00 00 00 00
  ^

[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-27
 Ever confirmed|0   |1

[Bug libstdc++/66302] Wrong output sequence of double precision uniform C++ RNG distribution

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I'll just note that the libc++ implementation has the same behaviour. The
precise numbers are different (probably due to a slightly different
implementation of uniform_real_distribution) but the pattern seen when
comparing float and double output is the same.

[Bug libstdc++/66302] Wrong output sequence of double precision uniform C++ RNG distribution

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
> Does it make sense?

So you expect the random generator for float to throw away half of the random
bits it is getting from the engine, just for this questionable benefit? And
actually 75%, so it matches with __float128? That seems wrong to me.

[Bug tree-optimization/66272] [4.9/5/6 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed May 27 14:20:48 2015
New Revision: 223759

URL: https://gcc.gnu.org/viewcvs?rev=223759&root=gcc&view=rev
Log:
2015-05-27  Richard Biener  

PR tree-optimization/66272
Revert parts of
2014-08-15  Richard Biener  

PR tree-optimization/62031
* tree-data-ref.c (dr_analyze_indices): Do not set
DR_UNCONSTRAINED_BASE.
(dr_may_alias_p): All indirect accesses have to go the
formerly DR_UNCONSTRAINED_BASE path.
* tree-data-ref.h (struct indices): Remove
unconstrained_base member.
(DR_UNCONSTRAINED_BASE): Remove.

* gcc.dg/torture/pr66272.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66272.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-data-ref.h

[Bug tree-optimization/66272] [4.9/5 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[4.9/5/6 Regression] wrong  |[4.9/5 Regression] wrong
   |code at -O3 on  |code at -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu
  Known to fail|6.0 |

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/62031] [4.8 Regression] Different results between O2 and O2 -fpredictive-commoning

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Author: rguenth
Date: Wed May 27 14:20:48 2015
New Revision: 223759

URL: https://gcc.gnu.org/viewcvs?rev=223759&root=gcc&view=rev
Log:
2015-05-27  Richard Biener  

PR tree-optimization/66272
Revert parts of
2014-08-15  Richard Biener  

PR tree-optimization/62031
* tree-data-ref.c (dr_analyze_indices): Do not set
DR_UNCONSTRAINED_BASE.
(dr_may_alias_p): All indirect accesses have to go the
formerly DR_UNCONSTRAINED_BASE path.
* tree-data-ref.h (struct indices): Remove
unconstrained_base member.
(DR_UNCONSTRAINED_BASE): Remove.

* gcc.dg/torture/pr66272.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66272.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-data-ref.h

[Bug lto/66305] -ffat-lto-objects create unreproducible objects

[andi at firstfloor dot org]

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

--- Comment #2 from andi at firstfloor dot org ---
On Wed, May 27, 2015 at 12:21:04PM +, rguenth at gcc dot gnu.org wrote:
> --- Comment #1 from Richard Biener  ---
> I think they become deterministic with -frandom-seed=0 for example.  They are
> not deterministic to support partial linking of LTO objects as far as I know.

Yes that's right. It prevents the linker from merging sections.

In theory it would be possible to use the hash of the full output path name or
similar, which would be a bit more deterministic, but there are still
ways this could break (e.g. if someone copies object files around)

How about your "deterministic build" tools just learn to ignore that
suffix?

-Andi

[Bug tree-optimization/66101] [5 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug tree-optimization/66101] [5 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Wed May 27 14:05:37 2015
New Revision: 223757

URL: https://gcc.gnu.org/viewcvs?rev=223757&root=gcc&view=rev
Log:
2015-05-27  Richard Biener  

Backport from mainline
2015-05-12  Richard Biener  

PR tree-optimization/66101
* tree-ssa-dce.c (remove_dead_stmt): Properly mark loops for
fixup if we turn a loop exit edge to a fallthru edge.

* gcc.dg/torture/pr66101.c: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr66101.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-ssa-dce.c

[Bug bootstrap/66304] [6 Regression] Can't bootstrap on x86_64-linux-gnu with gcc 4.3.4

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug libstdc++/66302] Wrong output sequence of double precision uniform C++ RNG distribution

[andrey.kolesov at intel dot com]

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

--- Comment #2 from Andrey Kolesov  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Andrey Kolesov from comment #0)
> > Double precision uniform distribution of C++ random number generators from
> > libstdc++ produces sequence which is significantly different from floating
> > point and integer (direct engine) generators.
> > Double precision sequence contains only every second (odd: 1,3,5,7...)
> > element from float and integer sequences. Generally generator output
> > shouldn't depend on output data type up to precision bounds.
> 
> Where does it say that in the standard?
> 
> Your code says:
> 
> /* All three sequences expected to be equal up to precision bounds */
> 
> Where does the standard say you should expect that?

Right, the C++ standard says that "The algorithms for producing each of the
specified distributions are implementation-defined" (25.8.1.3). 
The Standard has strict requirements for engines to satisfy equations (for
example, for rand0 LCG :  x[i+1] ← (a*x[i]+c) mod m ) but not for the
distributions based on these engines.
Formally it is not a "bug", I agree, you may close the issue.

>From perspective of data scientist or analytic application developer, the way
in which double precision output of the uniform distribution generator is
produced is questionable.
Let's consider the following scenario: a data scientist designs a stochastic
model and uses RNG for the model based Monte Carlo simulations.
To tune the parameters of the model he/she needs to fix a seed and, say, single
precision random number sequence. 
During tuning of the parameters, the researcher understands that single
precision is not sufficient for modeling goals and he needs to switch double
precision sequence produced with the same RNG/seed.
However, switching to double precision with C++ RNGs will result in different
values of the parameters. You can imagine amount of efforts necessary to
understand what went wrong with the model, tuning, and simulations.

Pseudo random generators are indeed deterministic algorithms (almost like other
math functions - sin, exp...) which produce sequences which look like random. 
But (float)sin(x1) is always equal to (double)sin(x1) up to precision. The same
behavior we can expect from RNGs, though the standard doesn't guarantee this. 
Our team is responsible for statistical features including random number
generators in Intel(R) Math Kernel Library. Intel(R) MKL RNGs were designed
keeping in mind multiple requirements including similar up to precision
sequences produced by the double and single versions of the same distribution
relying on the same algorithm and fixed seed.

Does it make sense?
Does it make sense to approach C++ Standard WG to get their perspective and
understand whether this specific behavior of the generators should be clearly
described in the standard?

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
The one valid entry in the backtrace is in the function kickoff in proc.c. 
That function is supposed to stop the trace.  Search for "kickoff" in
libgo/runtime/go-callers.c.  The question is why that didn't work.  Can you set
a breakpoint on that code, or add some print statements, and find out the value
of the local variable function?

[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #25 from ktkachov at gcc dot gnu.org ---
This should be fixed on trunk for GCC 6.
I'll keep this open for a few days to make sure there are no glaring complaints
about the patch as it gets through the auto-testers

[Bug middle-end/66307] New: Partial argument overlapping with itself should try to reuse infrastructure in calls.c

[ktkachov at gcc dot gnu.org]

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

Bug ID: 66307
   Summary: Partial argument overlapping with itself should try to
reuse infrastructure in calls.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

With r223753 as a fix for PR 65358 we now detect cases where a partial argument
overlaps with itself during a sibcall optimization.

As pointed out by https://gcc.gnu.org/ml/gcc-patches/2015-05/
it would be nice if we could reuse the existing infrastructure that detects
overlap of a partial argument with *other* arguments in the call. This is found
in calls.c (check_sibcall_argument_overlap for example).

This PR is to keep track of that.

[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #24 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Wed May 27 13:25:01 2015
New Revision: 223753

URL: https://gcc.gnu.org/viewcvs?rev=223753&root=gcc&view=rev
Log:
[expr.c] PR target/65358 Avoid clobbering partial argument during sibcall

PR target/65358
* expr.c (memory_load_overlap): New function.
(emit_push_insn): When pushing partial args to the stack would
clobber the register part load the overlapping part into a pseudo
and put it into the hard reg after pushing.  Change return type
to bool.  Add bool argument.
* expr.h (emit_push_insn): Change return type to bool.
Add bool argument.
* calls.c (expand_call): Cancel sibcall optimization when encountering
partial argument on targets with ARGS_GROW_DOWNWARD and
!STACK_GROWS_DOWNWARD.
(emit_library_call_value_1): Update callsite of emit_push_insn.
(store_one_arg): Likewise. 

PR target/65358
* gcc.dg/pr65358.c: New test. 


Added:
trunk/gcc/testsuite/gcc.dg/pr65358.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/expr.c
trunk/gcc/expr.h
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/66304] [6 Regression] Can't bootstrap on x86_64-linux-gnu with gcc 4.3.4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-27
  Component|c++ |bootstrap
   Target Milestone|--- |6.0
Summary|Can't bootstrap on  |[6 Regression] Can't
   |x86_64-linux-gnu with gcc   |bootstrap on
   |4.3.4   |x86_64-linux-gnu with gcc
   ||4.3.4
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed, btw.

[Bug lto/66305] -ffat-lto-objects create unreproducible objects

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 CC||andi-gcc at firstfloor dot org

--- Comment #1 from Richard Biener  ---
I think they become deterministic with -frandom-seed=0 for example.  They are
not deterministic to support partial linking of LTO objects as far as I know.

Should have the same issue with -fno-fat-lto-objects.

Why are python packages shipping with LTO bytecode?

[Bug c++/66304] Can't bootstrap on x86_64-linux-gnu with gcc 4.3.4

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> I suppose you are reporting this against trunk.

Yeah, sorry, it's really against trunk.

[Bug c++/66304] Can't bootstrap on x86_64-linux-gnu with gcc 4.3.4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|5.1.0   |6.0

--- Comment #1 from Richard Biener  ---
I suppose you are reporting this against trunk.

[Bug rtl-optimization/66306] New: ICE in reload

[krebbel at gcc dot gnu.org]

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

Bug ID: 66306
   Summary: ICE in reload
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35635&action=edit
Reduced testcase

cc1plus -O1 t.c
...
 unsigned int linemap_position_for_loc_and_offset(unsigned int, unsigned int)
t.c: In function ‘unsigned int linemap_position_for_loc_and_offset(unsigned
int, unsigned int)’:   
t.c:20:1: internal compiler error: in subst_reloads, at reload.c:6308   
 } 
...

t.c.193r.ira:
(insn 15 14 16 2 (parallel [
(set (reg:CCL1 33 %cc)
(compare:CCL1 (plus:SI (reg:SI 46 [ D.1846 ])
(mem/j:SI (plus:DI (reg/f:DI 44 [ map.0 ])
(const_int 4 [0x4])) [0 map.0_1->ordinary+0 S4
A32]))
(reg:SI 46 [ D.1846 ])))
(clobber (scratch:SI))
]) t.c:15 276 {*addsi3_carry1_cconly}
 (expr_list:REG_DEAD (reg/f:DI 44 [ map.0 ])
(nil)))

Insn 15 is supposed to match the following pattern. Admittedly a nasty
combination of a commutative constraint modifier, matching constraints and a
scratch register:

(define_insn "*add3_carry1_cconly"
  [(set (reg CC_REGNUM)
(compare (plus:GPR (match_operand:GPR 1 "nonimmediate_operand"
"%0,d,0,0")
   (match_operand:GPR 2 "general_operand"  
"d,d,R,T"))
 (match_dup 1)))
   (clobber (match_scratch:GPR 0  
"=d,d,d,d"))]
  "s390_match_ccmode (insn, CCL1mode)"
  "@
   alr\t%0,%2
   alrk\t%0,%1,%2
   al\t%0,%2
   al\t%0,%2"
  [(set_attr "op_type"  "RR,RRF,RX,RXY")
   (set_attr "cpu_facility" "*,z196,*,*")
   (set_attr "z10prop" "z10_super_E1,*,z10_super_E1,z10_super_E1")])

Reload ends up picking alternative 0 with swapped operands 1 and 2.
Unfortunately the reload does not get a reload register assigned and therefore
dies with the ICE.

Reloads for insn # 15
Reload 0: reload_in (SI) = (mem/j:SI (plus:DI (reg/f:DI 1 %r1 [orig:44 map.0 ]
[44])
(const_int 4 [0x4])) [0
map.0_1->ordinary+0 S4 A32])
reload_out (SI) = (scratch:SI)
GENERAL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (mem/j:SI (plus:DI (reg/f:DI 1 %r1 [orig:44 map.0 ]
[44])
(const_int 4 [0x4])) [0
map.0_1->ordinary+0 S4 A32])
reload_out_reg: (scratch:SI)


Regression hunt returns r186861 as the culprit (unfortunately one of my patches
:(. However, the patch only seems to reveal the problem since it changes which
alternative gets chosen in that example. Even with the patch reverted the same
error appears when disabling/removing the other alternatives manually. E.g. by
limiting them to higher CPU levels:

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index a875eec..71b2e57 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -4592,7 +4592,7 @@
al\t%0,%2
al\t%0,%2"
   [(set_attr "op_type"  "RR,RRF,RX,RXY")
-   (set_attr "cpu_facility" "*,z196,*,*")
+   (set_attr "cpu_facility" "*,z196,z196,z196")
(set_attr "z10prop" "z10_super_E1,*,z10_super_E1,z10_super_E1")])

 ; alr, alfi, slfi, al, aly, algr, algfi, slgfi, alg, alsi, algsi, alrk, algrk,
alhsik, alghsik

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #34 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #33)
> 
> > It looks that the log for 4.8.4-2 includes
> >  gcc/d/ctfeexpr.dmd.o differs
> > line just after its 'Bootstrap comparison failure!' line.  It looks that
> > that is the cause of failure and is a differnt issue.
> 
> Ah, thanks for spotting that. Now, should we move this into a new bug report
> then?

If 4.8.something doesn't bootstrap, it would be a "4.8 Regression" type of bug.
 I'd move it to a new PR.

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
When removing the fn spec from GOACC_data_start, we run into the problem that
this example doesn't get parallelized anymore:
...
#include 

#define N (1024 * 512)
#define COUNTERTYPE unsigned int

int
main (void)
{
  unsigned int *__restrict a;
  unsigned int *__restrict b;
  unsigned int *__restrict c;

  a = (unsigned int *)malloc (N * sizeof (unsigned int));
  b = (unsigned int *)malloc (N * sizeof (unsigned int));
  c = (unsigned int *)malloc (N * sizeof (unsigned int));

  for (COUNTERTYPE i = 0; i < N; i++)
a[i] = i * 2;

  for (COUNTERTYPE i = 0; i < N; i++)
b[i] = i * 4;

#pragma acc data copyin (a[0:N], b[0:N]) copyout (c[0:N])
  {
#pragma acc kernels present (a[0:N], b[0:N], c[0:N])
{
  for (COUNTERTYPE ii = 0; ii < N; ii++)
c[ii] = a[ii] + b[ii];
}
  }

  for (COUNTERTYPE i = 0; i < N; i++)
if (c[i] != a[i] + b[i])
  abort ();

  free (a);
  free (b);
  free (c);

  return 0;
}
...

In this sequence, we take the address of a and pass it to GOACC_data_start:
...
  .omp_data_arr.18.a = &a;
  __builtin_GOACC_data_start (-1, 6, &.omp_data_arr.18, &.omp_data_sizes.19,
&.omp_data_kinds.20);
...

With the fnspec, we need to assume that a could be modified by
__builtin_GOACC_data_start. And that inhibits optimization.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #33 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #32)
> (In reply to John Paul Adrian Glaubitz from comment #28)
> I should have been more clear about these comparison messages.
> Warning is warning and doesn't cause failure.  gcc/cc1*-checksum.o
> objects depend on the virtual addresses of executables.  If
> randomize-va-space feature of kernel on the target machine is used,
> then stage2/3 cc1*-checksum.o differs without any compiler problem.
> These differences are warned but aren't handled as errors for that reason.

Aha, that would explain that, indeed as it. Checking on two of the buildds:

root@tirpitz:~> cat /proc/sys/kernel/randomize_va_space 
2
root@tirpitz:~> 

yamashiro:~# cat /proc/sys/kernel/randomize_va_space 
2
yamashiro:~#


> It looks that the log for 4.8.4-2 includes
>  gcc/d/ctfeexpr.dmd.o differs
> line just after its 'Bootstrap comparison failure!' line.  It looks that
> that is the cause of failure and is a differnt issue.

Ah, thanks for spotting that. Now, should we move this into a new bug report
then?

> For the original PR, I've apply the fix on 5/6 in behalf of Oleg after
> the regtest on trunk which has become possible because 66181 is fixed.

Great. Can't wait for the new gcc-5 package to arrive in Debian. Will report
back as soon as I know more.

Adrian

[Bug libstdc++/66017] Undefined behaviour in std::set

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed May 27 11:18:37 2015
New Revision: 223745

URL: https://gcc.gnu.org/viewcvs?rev=223745&root=gcc&view=rev
Log:
PR libstdc++/66017
* include/bits/stl_tree.h (_Rb_tree_node): Use __aligned_membuf.
(_Rb_tree_iterator, _Rb_tree_const_iterator): Support construction
from _Base_ptr.
(_Rb_tree_const_iterator::_M_const_cast): Remove static_cast.
(_Rb_tree::begin, _Rb_tree::end): Remove static_cast.
* include/ext/aligned_buffer.h (__aligned_membuf): New type using
alignment of _Tp as a member subobject, not as a complete object.
* python/libstdcxx/v6/printers.py (StdRbtreeIteratorPrinter): Lookup
_Link_type manually as it might not be in the debug info.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_tree.h
trunk/libstdc++-v3/include/ext/aligned_buffer.h
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug middle-end/66276] [5/6 Regression] internal compiler error: in get_loop_body, at cfgloop.c:856

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Richard Biener  ---
A dup of PR66101.

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

[Bug tree-optimization/66101] [5 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||martin.sjolund at liu dot se

--- Comment #6 from Richard Biener  ---
*** Bug 66276 has been marked as a duplicate of this bug. ***

[Bug lto/66305] New: -ffat-lto-objects create unreproducible objects

[lunar at debian dot org]

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

Bug ID: 66305
   Summary: -ffat-lto-objects create unreproducible objects
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lunar at debian dot org
  Target Milestone: ---

Hi!

We are working in Debian—and I know other free software projects
care—in providing our users with a way to reproduce bit-for-bit
identical binary packages from the source and build enviroment.
See  for more information.

Python packages in Debian are built with `-flto -ffat-lto-objects`
on architectures that support it. Sadly, this makes the resulting
binary unreproducible.

For a trivial test case:

$ cat a.c
int a(void) {
return 42;
}
$ gcc -flto -ffat-lto-objects -c a.c
$ strings a.o | grep lto_
.gnu.lto_.inline.4980dca9e6ae4d45
.gnu.lto_a.4980dca9e6ae4d45
.gnu.lto_.symbol_nodes.4980dca9e6ae4d45
.gnu.lto_.refs.4980dca9e6ae4d45
.gnu.lto_.decls.4980dca9e6ae4d45
.gnu.lto_.symtab.4980dca9e6ae4d45
.gnu.lto_.opts
__gnu_lto_v1
$ gcc -flto -ffat-lto-objects -c a.c
$ strings a.o | grep lto_
.gnu.lto_.inline.24c30dabb443e726
.gnu.lto_a.24c30dabb443e726
.gnu.lto_.symbol_nodes.24c30dabb443e726
.gnu.lto_.refs.24c30dabb443e726
.gnu.lto_.decls.24c30dabb443e726
.gnu.lto_.symtab.24c30dabb443e726
.gnu.lto_.opts
__gnu_lto_v1

Would it be possible to make the section names deterministic?

[Bug c++/66304] New: Can't bootstrap on x86_64-linux-gnu with gcc 4.3.4

[marxin at gcc dot gnu.org]

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

Bug ID: 66304
   Summary: Can't bootstrap on x86_64-linux-gnu with gcc 4.3.4
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35634&action=edit
config.log

Hello.

Starting from r223691, I have following error in stage1:

g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build
-I../../gcc/../include  -I../../gcc/../libcpp/include  \
-o build/genmddeps.o ../../gcc/genmddeps.c
cc1plus: error: unrecognized command line option "-Wno-narrowing"

I see very suspicious lines in config.log file which I attached:

configure:6330: result: yes
configure:6382: checking for int64_t underlying type
configure:6406: g++ -c -g   conftest.cpp >&5
configure:6406: $? = 0
configure:6413: result: long
configure:6485: checking whether gcc supports -W
configure:6502: g++ -c -g   conftest.cpp >&5
configure:6502: $? = 0
configure:6511: result: yes
configure:6485: checking whether gcc supports -Wall
configure:6502: g++ -c -g   conftest.cpp >&5
configure:6502: $? = 0
configure:6511: result: yes
configure:6485: checking whether gcc supports -Wnarrowing
configure:6502: g++ -c -g   conftest.cpp >&5
configure:6502: $? = 0

Thanks,
Martin

[Bug debug/66301] internal compiler error when using -fopt-info

[t at sharklasers dot com]

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

--- Comment #1 from JD  ---
german@prometheus ~/test $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=local/gcc5.1/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=local/gcc5.1
--enable-languages=c,c++ --enable-gold=yes --enable-ld=yes --enable-lto
--enable-bootstrap --disable-multilib
Thread model: posix
gcc version 5.1.0 (GCC)

openSUSE 13.2 (Harlequin) (x86_64)

[Bug go/66303] New: runtime.Caller() returns infinitely deep stack frames on s390x

[e29253 at jp dot ibm.com]

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

Bug ID: 66303
   Summary: runtime.Caller() returns infinitely deep stack frames
on s390x
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: e29253 at jp dot ibm.com
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 35633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35633&action=edit
Sample program

The function runtime.Caller() returns infinitely deep stack frames on s390x
when we increase the argument 'skip'. 

Attached sample program does not terminate when we ran with GCCGO on s390x:
[inagaki@inagaki caller]$ go version
go version go1.4.2 gccgo (GCC) 5.1.1 20150527 linux/s390x
[inagaki@inagaki caller]$ go run caller.go | head
pc=4397991940204, file=../../../src/libgo/runtime/proc.c, line=235, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
^Cexit status 2
[inagaki@inagaki caller]$

The same program terminates with GC on x86_64:
-bash-4.1$ go version
go version go1.4.2 linux/amd64
-bash-4.1$ go run caller.go
pc=4329617, file=/usr/local/go/src/runtime/asm_amd64.s, line=2232, ok=true
pc=0, file=, line=0, ok=false
-bash-4.1$

Is it valid usage to detect a stack bottom by the return value 'ok'?

[Bug libstdc++/66302] Wrong output sequence of double precision uniform C++ RNG distribution

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Andrey Kolesov from comment #0)
> Double precision uniform distribution of C++ random number generators from
> libstdc++ produces sequence which is significantly different from floating
> point and integer (direct engine) generators.
> Double precision sequence contains only every second (odd: 1,3,5,7...)
> element from float and integer sequences. Generally generator output
> shouldn't depend on output data type up to precision bounds.

Where does it say that in the standard?

Your code says:

/* All three sequences expected to be equal up to precision bounds */

Where does the standard say you should expect that?

[Bug middle-end/66276] [5/6 Regression] internal compiler error: in get_loop_body, at cfgloop.c:856

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Can't reproduce on (only slightly modified) trunk, might be latent there now. 
Investigating on the branch instead.

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-27
  Component|fortran |tree-optimization
 Ever confirmed|0   |1

--- Comment #3 from vries at gcc dot gnu.org ---
Occurs on gomp-4_0-branch.

Minimal testcase in c:
...
$ cat src/libgomp/testsuite/libgomp.oacc-c-c++-common/data-end-sib-call.c
/* { dg-do run } */
/* { dg-options "-O2" } */

void
__attribute__((noinline,noclone))
f (void)
{
  int i;

#pragma acc data copyout (i)
  {

  }
}

int
main (void)
{
  f ();

  return 0;
}
...

The execution test passes on the host, but not on host_nonshm:
...
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/data-end-sib-call.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 execution test
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/data-end-sib-call.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 execution test
...

The problem is in the declaration of GOACC_data_start:
...
DEF_GOACC_BUILTIN_FNSPEC (BUILT_IN_GOACC_DATA_START, "GOACC_data_start",
  BT_FN_VOID_INT_SIZE_PTR_PTR_PTR,
  ATTR_FNSPEC_DOT_DOT_r_r_r_NOTHROW_LIST,
  ATTR_NOTHROW_LIST, "..rrr")
...

[ There's a problem with the matching.  The rs in "..rrr" were supposed to
match the PTR_PTR_PTR arguments. But that's not the case, since we need to add
a dot even for a void result. So the intended spec string was "...rrr".
AFAIU, this problem does not affect this PR. But I will review omp-builtins.def
for similar problems. ]

The 'r' means NOCLOBBER and NOESCAPE.

However, we take the address of 'i', assign it to .omp_data_arr.1 and pass that
to GOACC_data_start:
...
f ()
{
  int i;
  struct .omp_data_t.0 .omp_data_arr.1;
  static long unsigned int .omp_data_sizes.2[1] = {4};
  static short unsigned int .omp_data_kinds.3[1] = {642};

  :
  .omp_data_arr.1.i = &i;
  __builtin_GOACC_data_start (-1, 1, &.omp_data_arr.1, &.omp_data_sizes.2,
&.omp_data_kinds.3);
...

'i' escapes and is overwritten in __builtin_GOACC_data_start, so NOCLOBBER and
NOESCAPE do not hold.

[Bug c/66296] Gcc generated wrong code with uint16_t add/sub even with no optimization

[wanght at tsinghua dot org.cn]

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

Haitao Wang  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from Haitao Wang  ---
Agreed. It is invalid issue through it is really confusing at first.

[Bug libstdc++/66302] New: Wrong output sequence of double precision uniform C++ RNG distribution

[andrey.kolesov at intel dot com]

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

Bug ID: 66302
   Summary: Wrong output sequence of double precision uniform C++
RNG distribution
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.kolesov at intel dot com
  Target Milestone: ---

Created attachment 35632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35632&action=edit
Difference between int, float and double C++ RNG uniform distribution sequences

Double precision uniform distribution of C++ random number generators from
libstdc++ produces sequence which is significantly different from floating
point and integer (direct engine) generators.
Double precision sequence contains only every second (odd: 1,3,5,7...) element
from float and integer sequences. Generally generator output shouldn't depend
on output data type up to precision bounds.
Looks like the issue doesn't depend on engine types: reproduced on rand0 and
mt19937.
Attached test case output (U - unisigned int direct engine sequence, F - float
distribution sequence, D - double distribution sequence):

#  : U  F  D
-
0  | 1.306e+07  1.306e+07  4.399e+08
1  | 4.399e+08  4.399e+08  7.970e+08
2  | 2.262e+08  2.262e+08  2.819e+08
3  | 7.970e+08  7.970e+08  1.026e+09
4  | 2.062e+09  2.062e+09  5.506e+08
5  | 2.819e+08  2.819e+08  1.260e+09
6  | 1.189e+09  1.189e+09  1.852e+09
7  | 1.026e+09  1.026e+09  1.239e+09
8  | 1.747e+09  1.747e+09  2.108e+09
...

[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null

[rs2740 at gmail dot com]

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

--- Comment #14 from TC  ---
Well, I would have argued that if the specification doesn't say that a function
does X, then it doesn't do X. NullablePointer/CopyAssignable only means that
the assignment operation must be supported.

But then I realized that a literal reading of the specification would mean that
the deleter must be called using a copy of the stored pointer - the return
value of get() - rather than the stored pointer itself (again, hypothetically
detectable using an instrumented fancy pointer-like thing). Which would be just
absurd.

[Bug c++/66301] New: internal compiler error when using -fopt-info

[t at sharklasers dot com]

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

Bug ID: 66301
   Summary: internal compiler error when using -fopt-info
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t at sharklasers dot com
  Target Milestone: ---

Created attachment 35631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35631&action=edit
preprocessed source

$ g++ -O3 -fopt-info-missed-optall test.cpp
test.cpp: In member function 'std::ctype::char_type
std::ctype::widen(char) const':
test.cpp:14:1: internal compiler error: Segmentation fault
 }
 ^
0xaf4caf crash_signal
../../gcc-5.1.0/gcc/toplev.c:383
0x975511 dump_possible_polymorphic_call_targets(_IO_FILE*, tree_node*, long,
ipa_polymorphic_call_context const&)
../../gcc-5.1.0/gcc/ipa-devirt.c:3190
0xc09e85 eliminate_dom_walker::before_dom_children(basic_block_def*)
../../gcc-5.1.0/gcc/tree-ssa-pre.c:4394
0xfd8741 dom_walker::walk(basic_block_def*)
../../gcc-5.1.0/gcc/domwalk.c:188
0xc0900b eliminate
../../gcc-5.1.0/gcc/tree-ssa-pre.c:4540
0xc09325 execute
../../gcc-5.1.0/gcc/tree-ssa-pre.c:4978
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.