[Bug go/77780] Go front-end ignores NO_DOLLAR_IN_LABEL

2016-10-01 Thread ian at airs dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77780

--- Comment #3 from Ian Lance Taylor  ---
My inclination would be to overhaul all the identifiers in the gofrontend to
rationalize them from the rather random collection they are now.

[Bug middle-end/77816] [7 Regression] lots of fortran tests fail on aarch64-linux-gnu

2016-10-01 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77816

--- Comment #2 from Andrew Pinski  ---
It looks like it was working with r240644 .

https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02880.html

[Bug middle-end/77816] [7 Regression] lots of fortran tests fail on aarch64-linux-gnu

2016-10-01 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77816

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||aarch64-linux-gnu
Version|6.1.0   |7.0
   Target Milestone|--- |7.0

--- Comment #1 from Andrew Pinski  ---
Note I also built gcc with these options too (not just with
--with-cpu=thunderx+lse):
Configured with: ../gcc/configure --disable-libsanitizer
--prefix=/home/apinski/src/local/objdir/../tools
--enable-languages=c,c++,fortran,go --disable-werror --with-sysroot=/
--enable-plugins --enable-gnu-indirect-function --with-pkgver

And get the same failures.

[Bug middle-end/77816] New: [7 Regression] lots of fortran tests fail on aarch64-linux-gnu

2016-10-01 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77816

Bug ID: 77816
   Summary: [7 Regression] lots of fortran tests fail on
aarch64-linux-gnu
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

See https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02894.html .
(this is revision 240650).

They used to work:
https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02849.html
(revision 240639).



At line 6 of file
/home/apinski/src/local/gcc/gcc/testsuite/gfortran.dg/adjustl_1.f90
Internal Error: get_unit(): Bad internal unit KIND

Error termination. Backtrace:
FAIL: gfortran.dg/adjustl_1.f90   -O  execution test

[Bug go/77780] Go front-end ignores NO_DOLLAR_IN_LABEL

2016-10-01 Thread dje at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77780

David Edelsohn  changed:

   What|Removed |Added

   Keywords||assemble-failure

--- Comment #2 from David Edelsohn  ---
Is it possible to catch the creation of the decl in go-gcc.cc
Gcc_backend::implicit_variable() and ::immutable_struct_set_init() to change
the string?  Or all calls to build_decl()?

[Bug tree-optimization/59650] Inefficient vector assignment code

2016-10-01 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59650

--- Comment #1 from Andrew Pinski  ---
I think this has been improved already but I don't have a build for x86 to test
on.

[Bug target/77800] Undefined ref to host_detect_local_cpu on netbsd/arm

2016-10-01 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77800

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
   Severity|minor   |normal

[Bug c++/77803] [7 Regression] Bogus implicit-fallthrough warning

2016-10-01 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77803

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
Version|unknown |7.0
   Target Milestone|--- |7.0
Summary|Bogus implicit-fallthrough  |[7 Regression] Bogus
   |warning |implicit-fallthrough
   ||warning

[Bug c++/77815] New: access to destructor via decltype-specifier

2016-10-01 Thread jeff.mirwaisi at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77815

Bug ID: 77815
   Summary: access to destructor via decltype-specifier
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.mirwaisi at gmail dot com
  Target Milestone: ---

Invocation of the destructor or pseudo destructor via a decltype-specifier
results in an error:

T t; t.~decltype(t)();

error: expected identifier before 'decltype'

[Bug tree-optimization/77808] [7 Regression] ICE in duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with r240439

2016-10-01 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77808

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |NEW
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-10/msg0.ht
   ||ml
   Last reconfirmed||2016-10-01
 Ever confirmed|0   |1

[Bug fortran/77390] generates INDIRECT_REF of void type

2016-10-01 Thread paul.richard.thomas at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77390

--- Comment #2 from paul.richard.thomas at gmail dot com  ---
Dear Dominique,

I don't think that the problems are connected. I am having a problem
with a vtable that gets generated in a submodule and so has an address
different from that in the module itself.

I cannot come back to any of this for the next two weeks. I am taking
my wife to Thailand as a birthday present :-)

Cheers

Paul

On 1 October 2016 at 17:41, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77390
>
> Dominique d'Humieres  changed:
>
>What|Removed |Added
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2016-10-01
>  CC||pault at gcc dot gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #1 from Dominique d'Humieres  ---
> Paul,
>
> How is this related to the problem(s) you have with
> gfortran.dg/submodule_6.f08?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug libgcc/77813] __TMC_END__ - __TMC_LIST__ == 0

2016-10-01 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77813

Andrew Pinski  changed:

   What|Removed |Added

 Target|powerpc64le-unknown-linux-g |
   |nu  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-01
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
What the code in crtstuff should do is something like:
char *end = __TMC_END__ ;
char *start = __TMC_LIST__ ;

asm("" :"+r"(end));
asm("" :"+r"(start));

...
  if (end - start == 0)


We have recommended this already in bugzilla for other cases like the above
too.

[Bug libfortran/77473] New PRNG causes regressions on DragonFly BSD

2016-10-01 Thread rimvydas.jas at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473

--- Comment #4 from Rimvydas (RJ)  ---
Yes it is an issue in gthr-posix.h how presence of pthread is checked on
DragonFly.
libc contains pthread_cancel() stub and it is strange why we detected failures
only now on testsuite after new PRNG in libgfortran.
Currently we checking if we could exclude pthread_cancel symbol from libc
without breaking to much stuff (this would automatically fix previous gcc ports
and base compilers on DragonFly 4.7+).
Other variants are to use pthread_create() (as in BIONIC case) or special
variable from libc (z2.diff), however that depends on what __gthread_active_p()
should mean:
1) the pthread library is present and initialized
2) present but might not be initialized yet

[Bug libfortran/77473] New PRNG causes regressions on DragonFly BSD

2016-10-01 Thread rimvydas.jas at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473

--- Comment #3 from Rimvydas (RJ)  ---
Created attachment 39730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39730&action=edit
possible variant to use libc internal status variable

On DragonFly libpthread always brings libc so __isthreaded is available.
__isthreaded is a special variable that is set by libpthread lib.

[Bug libfortran/77473] New PRNG causes regressions on DragonFly BSD

2016-10-01 Thread jb at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473

--- Comment #2 from Janne Blomqvist  ---
(In reply to Rimvydas (RJ) from comment #0)
> Created attachment 39550 [details]
> changes to tests
> 
> Native configuration is x86_64-unknown-dragonfly4.7
> 
> r239356 Replace KISS PRNG with xorshift1024* using per-thread state
> caused all execution failures for:
> FAIL: gfortran.dg/random_7.f90   -O0  execution test
> FAIL: gfortran.fortran-torture/execute/random_1.f90 execution,  -O0
> 
> r239611 Always initialize PRNG using random data from the OS
> added:
> FAIL: gfortran.dg/random_4.f90   -O0  execution test
> 
> Adding prints for seed and check arrays before comparison shows that they
> differ:
> ./random_4.x
>  seed   42  42  42  42  42 
> 42  42  42  42  42  42  42  
> 42  42  42  42  42  42  42  
> 42  42  42  42  42  42  42  
> 42  42  42  42  42  42   0
>  check -2110421118 -1194805269  141524222154534463  1225148040  
> 821055102 -1530405947 -1820502322  2146652427  -147906310 -1761641582
> -1622508139  2006260459   151764285 -1191598697  -239551325 -1064082961 
> 2093503284  1165045647 -1200385605  -867398903  -830236747   846618033  
> 706688103  1954790377   859476278 -1696051309 -1413451556 -1779817981 
> 1071423788  1556108935  1966576166   0
> 
> If -pthread is explicitly used for those tests (attachment) only failure
> left is gfortran.dg/graphite/pr68279.f90 pr71348
> (execute/random_1.f90 still fails in testsuite - doesn't take -pthread flag)
> 
> Should libgfortran.so always bring in libpthread.so or new PRNG could be
> changed to have deterministic behavior with or without -pthread on DragonFly?

I don't know about DragonflyBSD, but at least on Linux the idea is that if a
thread library is not linked in, the various thread functions are stubbed out,
allowing us to support both single-threaded usage without the overhead of
mutexes etc. and multi-threaded usage without needing multiple library builds.
This relies on weak symbols and such fancy linker tricks. If the Dragonfly
linker doesn't have such features, I suspect you need to either always link in
libpthread, or have separate builds for single-threaded and multi-threaded
usage?

But this is not something new introduced with the new random algorithm, it has
been used since the beginning (which is one reason we use the __ghthread_*
functions instead of the pthreads API directly). What hasn't been used in
libgfortran before is the usage of __gthread_active_p() to check whether
threads are linked in or not at runtime. But again, this is not something new,
it has been used at least in libstdc++ before.

So, do all the libstdc++ tests pass on Dragonfly? If not, perhaps there is
something wrong with __ghtread_active_p() on DragonflyBSD?

[Bug libfortran/77473] New PRNG causes regressions on DragonFly BSD

2016-10-01 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-01
 CC||jb at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Janne,

Will you have a look at this PR?

[Bug fortran/77390] generates INDIRECT_REF of void type

2016-10-01 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77390

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-01
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Paul,

How is this related to the problem(s) you have with
gfortran.dg/submodule_6.f08?

[Bug middle-end/77798] [7 Regression] 465.tonto ICE with trunk with -O2

2016-10-01 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77798

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Sat Oct  1 14:34:18 2016
New Revision: 240696

URL: https://gcc.gnu.org/viewcvs?rev=240696&root=gcc&view=rev
Log:
2016-10-01  Richard Biener  

PR middle-end/77798
* genmatch.c (get_operand_type): Add operand position arg
and handle COND_EXPR comparison operand with fixed boolean_type_node.
(expr::gen_transform): Adjust.
(dt_simplify::gen_1): Likewise.

* gfortran.fortran-torture/compile/pr77798.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr77798.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/genmatch.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/77663] libgfortran/caf/single.c: three minor problems and a lost token

2016-10-01 Thread vehre at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77663

--- Comment #3 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sat Oct  1 14:00:57 2016
New Revision: 240695

URL: https://gcc.gnu.org/viewcvs?rev=240695&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2016-10-01  Andre Vehreschild  

PR fortran/77663
* gfortran.dg/coarray_send_by_ref_1.f08: New test.

libgfortran/ChangeLog:

2016-10-01  Andre Vehreschild  

PR fortran/77663
* caf/single.c (caf_internal_error): Fix not terminating va-list.
(_gfortran_caf_register): Free memory also when other allocs failed.
(_gfortran_caf_get_by_ref): Fixed style.
(send_by_ref): Token is now stored at the correct position preventing
inaccessible tokens, memory loss and possibly crashes.



Added:
trunk/gcc/testsuite/gfortran.dg/coarray_send_by_ref_1.f08
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/caf/single.c

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

2016-10-01 Thread n8tm at aol dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593

--- Comment #11 from n8tm at aol dot com ---
I returned to attempts to build trunk on win8.1.  Initial bootstrap of
c++ is failing, attempting (unsuccessfully!) to build eh_arm.  I filed
pr 77814 


On 9/25/2016 3:03 PM, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593
>
> --- Comment #9 from Jerry DeLisle  ---
> (In reply to tprince from comment #8)
>> I show my configure parameters in my test results posts.  At some time in
>> the past, each of them has been important.  I don't know if the parameters
>> quoted by cygwin release pertain to cross compiling.  As the parameters I
>> use have been successful again last week on win8.1 I don't see how they
>> might pertain to the f951 bootstrap failure on win10.  When I get back to
>> the win10 box I will compare with disable bootstrap.
> Tim, using your parameters I was able to build.  I proceeded to do a 
> regression
> hunt and confirmed that it was at the DTIO patch on 8/31/2016.
>
> In this patch we added two new functions to libgfortran and set the symbol
> versioning. I modified the library by inserting a printf("ping\n") in the code
> path for a simple program.
>
> print *, "hello"
> end
>
> The ping does not show which means the wrong library is being used at run 
> time.
>
> I am trying various config and bath settings to see if I can sort it out. No
> luck so far.
>

[Bug libstdc++/77814] New: build fails trying to build eh_arm

2016-10-01 Thread tprince at computer dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77814

Bug ID: 77814
   Summary: build fails trying to build eh_arm
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tprince at computer dot org
  Target Milestone: ---

Created attachment 39729
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39729&action=edit
log from trunk stage 1 bootstrap of libstdc++

Initial bootstrap tries (and fails) to build eh_arm.

/cygdrive/c/users/tim/tim/tim/src/gnu/gcc2/libstdc++-v3/include/bits/std_abs.h:
In function ‘long long int std::abs(long long int)’:
/cygdrive/c/users/tim/tim/tim/src/gnu/gcc2/libstdc++-v3/include/bits/std_abs.h:5
9:3: error: conflicting declaration of C function ‘long long int std::abs(long
l
ong int)’
   abs(long long __x) { return __builtin_llabs (__x); }
   ^~~

full log attached

Guessing that the build shouldn't require this compilation.

[Bug libfortran/77663] libgfortran/caf/single.c: three minor problems and a lost token

2016-10-01 Thread vehre at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77663

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from vehre at gcc dot gnu.org ---
Patch available at:

https://gcc.gnu.org/ml/fortran/2016-10/msg0.html

Waiting for review.

[Bug libfortran/77663] libgfortran/caf/single.c: four minor problems

2016-10-01 Thread vehre at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77663

--- Comment #1 from vehre at gcc dot gnu.org ---
Hi David,

what SW did you use to find this?

#1, #2, #4 are covered by a patch I am doing at the moment.

I believe that the report for #3 is at least misleading. Because when the
associated memory is NULL the token of the allocatable component has to be
unset, too. I.e. it is invalid for allocatable components to be NULL while the
associated token is set. Nevertheless did the report show a logic error. The
token never would have been stored at the appropriate location, but would be
lost. The patch to come fixes this, too (hopefully).

Thanks for the report.

Regards,
Andre

[Bug libfortran/77663] libgfortran/caf/single.c: four minor problems

2016-10-01 Thread vehre at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77663

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-01
 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

2016-10-01 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767

--- Comment #28 from Dominique d'Humieres  ---
Two other tests needing to replace 'L' with '\[lL\]':

gcc.dg/const-uniq-1.c
gcc.target/i386/pr70799-1.c

[Bug fortran/77596] [F03] procedure pointer with implicit interface in type pointing to a function can be 'called'

2016-10-01 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77596

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-01
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of/related to pr24878?

[Bug libgcc/77813] __TMC_END__ - __TMC_LIST__ == 0

2016-10-01 Thread glisse at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77813

--- Comment #1 from Marc Glisse  ---
Created attachment 39728
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39728&action=edit
optimization patch that shows the issue

[Bug libgcc/77813] New: __TMC_END__ - __TMC_LIST__ == 0

2016-10-01 Thread glisse at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77813

Bug ID: 77813
   Summary: __TMC_END__ - __TMC_LIST__ == 0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu

In crtstuff.c, function deregister_tm_clones contains this code:

  if (__TMC_END__ - __TMC_LIST__ == 0)

this currently gives, in the original dump

  if (((unsigned long) &__TMC_END__ + 7) - (unsigned long) &__TMC_LIST__ <= 14)

I was testing an optimization that allows us to get instead

  if ((long int) &__TMC_END__ == (long int) &__TMC_LIST__)

During forwprop, the match.pd pattern (cmp (convert1?@2 addr@0) (convert2?
addr@1)) applies and we fold this to 0. In the libitm testsuite, most runtime
tests then segfault.

It seems that either the optimization to compare addresses is too eager, or the
code in crtstuff.c doesn't mark the variables appropriately...

[Bug target/77756] __get_cpuid() returns wrong values for level 7 (extended features)

2016-10-01 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77756

--- Comment #13 from Uroš Bizjak  ---
(In reply to Yale Zhang from comment #12)
> What's the purpose of subleaf? Is it to distinguish the capabilities of
> different cores in a heterogeneous chip (e.g. ARM big-little)?

No, it is just a value in ECX that in some cases specifies what information to
return.

> Then I would be fine with making this an extra parameter to __get_cpuid(). 

cpuid.h is exported public header and we would break backward compatibility in
this case.

> Microsoft has a __cpuidex() function that also takes subleaf, but for the
> regular __cpuid(), the subleaf default to 0. Should __get_cpuid() default to
> 0 as well?

I think there is no need for default 0. Rhere are other cases (e.g. level 13)
that uses other subleafs to get capabilites info. So, there is no rule, and
defaulting to 0 would be confusing. One should use __get_cpuid_count when
subleaf is to be specified.