[Bug tree-optimization/55016] New: request for specific builtins for rcp and rsqrt

[vincenzo.innocente at cern dot ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55016



 Bug #: 55016

   Summary: request for specific builtins for rcp and rsqrt

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: vincenzo.innoce...@cern.ch





There are cases where the use of approximate rcp and rsqrt suffice.



I wonder if it would be possible to introduce specific "generic" builtins for

"rcp" and "rsqrt" that produce the proper instruction depending on the target

architecture (see,avx etc) and eventually generate vector instruction in a loop



at the moment anything like this is target specific, inefficient and does not

vectorize!



#include 

float v0[1024];

float v1[1024];

inline

float rsqrtf( float x ) {

  return _mm_cvtss_f32( _mm_rsqrt_ss( _mm_set_ss( x ) ) );

}

void v() {

  for(int i=0; i!=1024; ++i)

v0[i] = rsqrtf(v1[i]);

}

[Bug c++/55015] Lambda functions not found at link time when declared in an inline function

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||assemble-failure

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-22

 CC||pinskia at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #3 from Andrew Pinski  2012-10-22 
05:09:36 UTC ---

Confirmed on the trunk too.

[Bug c++/55015] Lambda functions not found at link time when declared in an inline function

[spam_hole at shaw dot ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015



Robert Xiao  changed:



   What|Removed |Added



 CC||spam_hole at shaw dot ca



--- Comment #2 from Robert Xiao  2012-10-22 05:02:01 
UTC ---

Minimal reproducible testcase:



typedef void (*VoidFunc)();

inline VoidFunc GetFunc() { return [](){}; }

int main() { VoidFunc func = GetFunc(); }



Compiled with gcc version 4.7.2 (MacPorts gcc47 4.7.2_2). Output:



$ g++-mp-4.7 test.cpp -std=c++11

Undefined symbols for architecture x86_64:

  "GetFunc()::{lambda()#1}::_FUN()", referenced from:

  GetFunc()::{lambda()#1}::operator void (*)()() const in cciEeUag.o

ld: symbol(s) not found for architecture x86_64

collect2: error: ld returned 1 exit status

[Bug c++/55015] Lambda functions not found at link time when declared in an inline function

[julien.nitard at m4tp dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015



--- Comment #1 from Julien Nitard  2012-10-22 
02:13:43 UTC ---

Somebody noted in S.O. that declaring the inline function "static" (or using an

anonymous namespace which I guess as same effect) hides (or solves ;) the

problem.

[Bug c++/55015] New: Lambda functions not found at link time when declared in an inline function

[julien.nitard at m4tp dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015



 Bug #: 55015

   Summary: Lambda functions not found at link time when declared

in an inline function

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: julien.nit...@m4tp.org





Hi all,



Following this stackoverflow question

http://stackoverflow.com/questions/13003941/lambda-not-found-when-defined-in-an-inline-function-in-g-4-7,

I was directed here to report a bug.

I have tried to find similar bugs but haven't.



Lambdas are not handled properly when declared inside inline functions (or so

it seems).



Here is a LWS link that demonstrates the error:

http://liveworkspace.org/code/35374b3c9b0d40e8ccc0819eb44d7f9e





In case the link disappears, here the source:



#include 

#include 



#include 



using std::string;



typedef bool (*FieldComparer)(const std::string&, const std::string&);



inline FieldComparer

GetComparer(const std::string& query, string& separator)

{

if (query.find('=') != std::string::npos) {

separator = "=";

return [](const string& s1, const string& s2) { return s1 == s2; };

}

else if (query.find('^') != string::npos) {

separator = "^";

return [](const string& s1, const string& s2) { return

boost::starts_with(s1, s2); };

}

else if (query.find('*') != string::npos) {

separator = "*";

return [](const string& s1, const string& s2) { return

boost::contains(s1, s2); };

}

else if (query.find('!') != string::npos) {

separator = "!";

return [](const string& s1, const string& s2) { return s1 != s2; };

}

else

throw std::invalid_argument("Search: could not find operator in query

string.");

}



int main()

{

  std::string sep;

  auto comp = GetComparer( "=", sep );

}



Many thanks,

[Bug target/55014] ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32

[coolypf at qq dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55014



--- Comment #1 from coolypf  2012-10-22 01:09:01 UTC ---

Created attachment 28501

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28501

preprocessed source

[Bug target/55014] New: ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32

[coolypf at qq dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55014



 Bug #: 55014

   Summary: ICE: Segmentation fault while compiling complex_io.cc

on x86_64-w64-mingw32

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: cool...@qq.com





Revision: 192664

Host & Target: x86_64-w64-mingw32



/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile

/build/./gcc/xgcc -shared-libgcc -B/build/./gcc -nostdinc++

-L/build/x86_64-w64-mingw32/32/libstdc++-v3/src

-L/build/x86_64-w64-mingw32/32/libstdc++-v3/src/.libs

-L/gcc/x86_64-w64-mingw32/lib -L/gcc/mingw/lib -isystem

/gcc/x86_64-w64-mingw32/include -isystem /gcc/mingw/include

-B/gcc/x86_64-w64-mingw32/bin/ -B/gcc/x86_64-w64-mingw32/lib/ -isystem

/gcc/x86_64-w64-mingw32/include -isystem /gcc/x86_64-w64-mingw32/sys-include 

-m32 -I/gcc-svn/libstdc++-v3/../libgcc

-I/build/x86_64-w64-mingw32/32/libstdc++-v3/include/x86_64-w64-mingw32

-I/build/x86_64-w64-mingw32/32/libstdc++-v3/include

-I/gcc-svn/libstdc++-v3/libsupc++-fno-implicit-templates -Wall -Wextra

-Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  

-ffunction-sections -fdata-sections  -frandom-seed=complex_io.lo -g -O2  -m32 

-c -o complex_io.lo

../../../../../../gcc-svn/libstdc++-v3/src/c++98/complex_io.cc

libtool: compile:  /build/./gcc/xgcc -shared-libgcc -B/build/./gcc -nostdinc++

-L/build/x86_64-w64-mingw32/32/libstdc++-v3/src

-L/build/x86_64-w64-mingw32/32/libstdc++-v3/src/.libs

-L/gcc/x86_64-w64-mingw32/lib -L/gcc/mingw/lib -isystem

/gcc/x86_64-w64-mingw32/include -isystem /gcc/mingw/include

-B/gcc/x86_64-w64-mingw32/bin/ -B/gcc/x86_64-w64-mingw32/lib/ -isystem

/gcc/x86_64-w64-mingw32/include -isystem /gcc/x86_64-w64-mingw32/sys-include

-m32 -I/gcc-svn/libstdc++-v3/../libgcc

-I/build/x86_64-w64-mingw32/32/libstdc++-v3/include/x86_64-w64-mingw32

-I/build/x86_64-w64-mingw32/32/libstdc++-v3/include

-I/gcc-svn/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra

-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once

-ffunction-sections -fdata-sections -frandom-seed=complex_io.lo -g -O2 -m32 -c

../../../../../../gcc-svn/libstdc++-v3/src/c++98/complex_io.cc -o complex_io.o

In file included from

../../../../../../gcc-svn/libstdc++-v3/src/c++98/complex_io.cc:25:0:

D:/MinGW/build/x86_64-w64-mingw32/32/libstdc++-v3/include/complex: In function

'std::basic_ostream<_CharT, _Traits>&

std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::complex<_Tp>&)

[with _Tp = float; _CharT = char; _Traits = std::char_traits]':

D:/MinGW/build/x86_64-w64-mingw32/32/libstdc++-v3/include/complex:529:5:

internal compiler error: Segmentation fault

 }

 ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

make[7]: *** [complex_io.lo] Error 1

make[7]: Leaving directory

`/build/x86_64-w64-mingw32/32/libstdc++-v3/src/c++98'

make[6]: *** [all-recursive] Error 1

make[6]: Leaving directory `/build/x86_64-w64-mingw32/32/libstdc++-v3/src'

make[5]: *** [all-recursive] Error 1

make[5]: Leaving directory `/build/x86_64-w64-mingw32/32/libstdc++-v3'

make[4]: *** [all] Error 2

make[4]: Leaving directory `/build/x86_64-w64-mingw32/32/libstdc++-v3'

make[3]: *** [multi-do] Error 1

make[3]: Leaving directory `/build/x86_64-w64-mingw32/libstdc++-v3'

make[2]: *** [all-multi] Error 2

make[2]: Leaving directory `/build/x86_64-w64-mingw32/libstdc++-v3'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/build/x86_64-w64-mingw32/libstdc++-v3'

make: *** [all] Error 2





Reduced command line for prepocessed source:

/build/gcc/xgcc -B/build/gcc -O2 -m32 -c complex_io.cpp



Compiling at -O1 or -O2 triggers ICE.

[Bug c/55009] compile-time assertions no longer usable: error: variably modified ‘ari_sign_32_bit_and_wrap’ at file scope

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55009



--- Comment #1 from joseph at codesourcery dot com  2012-10-21 23:41:28 UTC ---

The C standard requirements that certain source code has certain semantics 

(such as, in this case, overflows making something not an integer constant 

expression and so an array a VLA) are unchanged by -fwrapv; that simply 

concerns what happens for certain code that under standard C would be 

undefined at runtime.



The diagnostic is correct and probably occurs as a result of fixes for 

various internal compiler errors relating to expressions with integer 

operands that are not integer constant expressions.  However, it might be 

possible to downgrade it to a pedwarn the way it is already downgraded for 

some other expressions folding to an integer constant.

[Bug c++/54984] [4.6/4.7/4.8 Regression] Array allocated with new in a template class is default initialised

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54984



Paolo Carlini  changed:



   What|Removed |Added



 CC||bruno-gcc at defraine dot

   ||net



--- Comment #2 from Paolo Carlini  2012-10-21 
23:00:58 UTC ---

*** Bug 51847 has been marked as a duplicate of this bug. ***

[Bug c++/51847] incorrect primitive array initialization in generic methods

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51847



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||paolo.carlini at oracle dot

   ||com

 Resolution||DUPLICATE



--- Comment #1 from Paolo Carlini  2012-10-21 
23:00:58 UTC ---

Same issue. Let's keep one with all the appropriate Regression markers.



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

[Bug c++/54859] [4.8 Regression] constexpr in template aliase rejected as non-constant

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859



Paolo Carlini  changed:



   What|Removed |Added



 CC||lucdanton at free dot fr



--- Comment #2 from Paolo Carlini  2012-10-21 
22:53:21 UTC ---

*** Bug 54912 has been marked as a duplicate of this bug. ***

[Bug c++/54912] [4.8 Regression] Non-type argument to alias template is not a constant expression

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54912



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||DUPLICATE



--- Comment #4 from Paolo Carlini  2012-10-21 
22:53:20 UTC ---

Dup.



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

[Bug c++/54912] [4.8 Regression] Non-type argument to alias template is not a constant expression

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54912



Paolo Carlini  changed:



   What|Removed |Added



 CC||pkeir at outlook dot com



--- Comment #3 from Paolo Carlini  2012-10-21 
22:51:44 UTC ---

*** Bug 55013 has been marked as a duplicate of this bug. ***

[Bug c++/55013] variadic sizeof non-constant with alias template

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55013



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from Paolo Carlini  2012-10-21 
22:51:44 UTC ---

Dup.



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

[Bug c++/55013] New: variadic sizeof non-constant with alias template

[pkeir at outlook dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55013



 Bug #: 55013

   Summary: variadic sizeof non-constant with alias template

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: pk...@outlook.com





Created attachment 28500

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28500

Code that produces the error



The following code fails to compile as the size of the variadic template

parameter pack Ts is considered to be non-constant:



template 

struct Foo {};



template 

using PI = int;



template 

PI q(Foo) {

  return PI(42);

}



With GCC 4.7.2 and Clang 3.2 there is no problem. I am using GCC snapshot 4.8.0

20121014 under Ubuntu.



Compiled with:



g++ -std=c++11 -c alias.cpp

[Bug target/55012] Protected visibility wrongly uses GOT-relative addresses

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012



--- Comment #1 from Rich Felker  2012-10-21 22:06:39 
UTC ---

I'm not sure whether the fix should be in gcc/varasm.c,

default_binds_local_p_1(), or in the config/i386/predicates.md,

local_symbolic_operand predicate.



In the former, all non-default-visibility symbols are considered "local". In

the latter, this "local" flag is used to determine that a got-relative offset

would be allowed.



If varasm.c is modified, it should be to make protected symbols considered

non-local. I don't know if this would hurt code generation on other archs that

don't use copy relocations, however.



If predicated.md is to be modified, I don't see a good way, since the

information on visibility seems to be lost at this point. Hidden symbols must

continue to be considered local, but protected ones should not.

[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128

[planet36 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622



--- Comment #11 from Steve Ward  2012-10-21 22:05:35 
UTC ---

This problem still exists in g++ 4.7.2.

[Bug tree-optimization/52798] __builtin_object_size() based overflow check is a false positive due to parameter optimisation

[dirtyepic at gentoo dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52798



Ryan Hill  changed:



   What|Removed |Added



 CC||dirtyepic at gentoo dot org



--- Comment #2 from Ryan Hill  2012-10-21 22:00:24 
UTC ---

Also 4.6.2, 4.6.3.

[Bug target/19520] protected function pointer and copy relocation don't work right

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520



H.J. Lu  changed:



   What|Removed |Added



 Blocks||55012

Summary|protected function pointer  |protected function pointer

   |doesn't work right  |and copy relocation don't

   ||work right



--- Comment #32 from H.J. Lu  2012-10-21 21:34:50 
UTC ---

Protected data symbol with copy relocation doesn't

work either.

[Bug target/54280] AVR target: -mmcu=atxmega128b support missing

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54280



Georg-Johann Lay  changed:



   What|Removed |Added



 Target||avr

 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Georg-Johann Lay  2012-10-21 
21:18:53 UTC ---

If you need to run the compiler an operating system other than MS Windows, you

have to compile it for your operating system or find a distribution on the web.



GCC is distrubuted as source code.  The GCC project does not distribute

binaries of the compiler.



Besides that and as you can depict from the --version output, the tool chain

you are after is not hosted by the FSF.  Thus you may want to switch over to

the maintainer of that distribution.

[Bug target/47675] [avr] problems with asm when all registers on clobber list

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47675



Georg-Johann Lay  changed:



   What|Removed |Added



 Target||avr

 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #3 from Georg-Johann Lay  2012-10-21 
21:04:39 UTC ---

You must not clobber the frame pointer or other registers used by the ABI.



For the avr-gcc register layout and calling convention, see

http://gcc.gnu.org/wiki/avr-gcc

[Bug other/52278] [avr] inefficient register allocation for SUBREGs

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278



Georg-Johann Lay  changed:



   What|Removed |Added



 CC||Kip.Hicit at gmail dot com



--- Comment #6 from Georg-Johann Lay  2012-10-21 
20:54:12 UTC ---

*** Bug 47644 has been marked as a duplicate of this bug. ***

[Bug target/47644] [avr] Optimisation regression in choosing registers

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47644



Georg-Johann Lay  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||gjl at gcc dot gnu.org

 Resolution||DUPLICATE



--- Comment #3 from Georg-Johann Lay  2012-10-21 
20:54:12 UTC ---

Duplicate of PR52278



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

[Bug fortran/42954] [4.6/4.7/4.8 regression] TARGET_*_CPP_BUILTINS issues with gfortran

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954



janus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||earnie at users dot

   ||sourceforge.net



--- Comment #21 from janus at gcc dot gnu.org 2012-10-21 20:46:07 UTC ---

*** Bug 55007 has been marked as a duplicate of this bug. ***

[Bug fortran/55007] WIN32, _WIN32, etc not defined in fortran

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55007



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #4 from janus at gcc dot gnu.org 2012-10-21 20:46:07 UTC ---

(In reply to comment #3)

> I think this is a dup of another bug where __x86_64__ is not declared as

> currently the target defines are only done for C/C++.



Yes, this is PR 42954.



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

[Bug target/54888] GCC with -Os is faster than -O3 on some AVR code

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888



Georg-Johann Lay  changed:



   What|Removed |Added



 Target||avr

   Priority|P3  |P4

 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-10-21

  Component|c   |target

 Ever Confirmed|0   |1



--- Comment #2 from Georg-Johann Lay  2012-10-21 
20:40:45 UTC ---

atxmega128d3 is not supported by avr-gcc, neither in 4.3 nor in 4.4 nor 4.5 nor

4.6.  Please report to the respective bug tracker, obviously some private

toolchain port.



Compiling with a current compiler that supports ATxmega128D3 (4.7 or newer)

stops compilation with errors.



And I actually don't understand teh issue: Optimizing for size does not require

to produce slow code.  The code may run fast.



If your program relies on slow executable code, the program is incorrect.

[Bug tree-optimization/55008] Internal compiler error : verify_ssa failed

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-21

 CC||mpolacek at gcc dot

   ||gnu.org, wschmidt at gcc

   ||dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2012-10-21 
20:00:32 UTC ---

Started with http://gcc.gnu.org/viewcvs?view=revision&revision=190220

[Bug fortran/54730] [4.6/4.7/4.8 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54730



Thomas Koenig  changed:



   What|Removed |Added



 CC||tkoenig at gcc dot gnu.org



--- Comment #6 from Thomas Koenig  2012-10-21 
19:23:39 UTC ---

Even shorter test case:



program main

  implicit none

  intrinsic :: real

  print *,(/ real(a = 1) /)

end



The problem appears to be that we try to build a backend decl

for a, which doesn't really make a lot of sense.  We do fine

without one for the



program main

  implicit none

  intrinsic :: real

  print *,(/ real(1) /)

end



case.

[Bug fortran/55007] WIN32, _WIN32, etc not defined in fortran

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55007



--- Comment #3 from Andrew Pinski  2012-10-21 
19:09:17 UTC ---

I think this is a dup of another bug where __x86_64__ is not declared as

currently the target defines are only done for C/C++.

[Bug target/55012] New: Protected visibility wrongly uses GOT-relative addresses

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012



 Bug #: 55012

   Summary: Protected visibility wrongly uses GOT-relative

addresses

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bug...@aerifal.cx





Consider the shared library code:



int a __attribute__((visibility("protected")));

int f() { return a; }



For this (on i386 at least), gcc generates a GOT-relative (@GOTOFF) reference

to "a" rather than a GOT lookup. This will then reference the wrong location if

"a" is moved into the main program's data via a copy relocation, which will

happen if the main program makes any references to "a".



The issue is a subtlety in the semantics of protected visibility. As I

understand it and as it's documented, it's supposed to convey the semantic that

the definition will not be overridden in the sense of the abstract machine.

Copy relocations are not a case of overriding the definition in the abstract

machine, but an implementation detail used to support data objects in shared

libraries when the main program is non-PIC. With the current behavior, GCC is

requiring library authors using visibility to be aware of this implementation

detail (which only applies on some targets) and avoid using visibility on these

specific targets. That, in my mind, is unreasonable and buggy behavior.



Note that where this came up is when trying to use #pragma to set visibility

globally in a shared library; doing so broke global objects accessed from the

main application, but otherwise behaved as expected.

[Bug middle-end/55011] New: GCC in an infinite loop at -O2

[antoine.balestrat at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55011



 Bug #: 55011

   Summary: GCC in an infinite loop at -O2

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: antoine.balest...@gmail.com





GCC 4.8.0 as of 20121021 seems to be stuck in an infinite loop while compiling

the following testcase at -O2 (works at -O1 and -O3) :



$ cat infloop.c

char a;



void f(void)

{

char b = 2;



for(;;)

{

unsigned short s = 1, *p = &s, *i;



for(*i = 0; *i < 4; ++*i)

if(a | (*p /= (b += !!a)) <= 63739)

return;



if(!s)

a = 0;



for(;;);

}

}



$ ulimit -t 120



$ xgcc -O2 infloop.c



... 2 minutes later :



gcc: internal compiler error: CPU time limit exceeded (program cc1)

linux-vdso.so.1: No such file or directory

0x40b937 execute

../../srcdir/gcc/gcc.c:2739

0x40c7be do_spec_1

../../srcdir/gcc/gcc.c:4534

0x40f0d5 process_brace_body

../../srcdir/gcc/gcc.c:5782

0x40f0d5 handle_braces

../../srcdir/gcc/gcc.c:5696

0x40d397 do_spec_1

../../srcdir/gcc/gcc.c:5179

0x40f0d5 process_brace_body

../../srcdir/gcc/gcc.c:5782

0x40f0d5 handle_braces

../../srcdir/gcc/gcc.c:5696

0x40d397 do_spec_1

../../srcdir/gcc/gcc.c:5179

0x40cff7 do_spec_1

../../srcdir/gcc/gcc.c:5284

0x40f0d5 process_brace_body

../../srcdir/gcc/gcc.c:5782

0x40f0d5 handle_braces

../../srcdir/gcc/gcc.c:5696

0x40d397 do_spec_1

../../srcdir/gcc/gcc.c:5179

0x40f0d5 process_brace_body

../../srcdir/gcc/gcc.c:5782

0x40f0d5 handle_braces

../../srcdir/gcc/gcc.c:5696

0x40d397 do_spec_1

../../srcdir/gcc/gcc.c:5179

0x40f0d5 process_brace_body

../../srcdir/gcc/gcc.c:5782

0x40f0d5 handle_braces

../../srcdir/gcc/gcc.c:5696

0x40d397 do_spec_1

../../srcdir/gcc/gcc.c:5179

0x40f0d5 process_brace_body

../../srcdir/gcc/gcc.c:5782

0x40f0d5 handle_braces

../../srcdir/gcc/gcc.c:5696

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.



Please let me know if you need more information !

[Bug rtl-optimization/55010] New: Internal consistency failure : invalid rtl sharing found in the insn

[merkil at savhon dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55010

 Bug #: 55010
   Summary: Internal consistency failure : invalid rtl sharing
found in the insn
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mer...@savhon.org


Hi !
With GCC 4.8.0 as of 20121021, at -O2 and higher :

$ cat consistency.c
#include 

int64_t a;
uint64_t b;

void f(void)
{
a = (a < 0) / ((a -= b) ? b >= ((b = a) || 0) : 0);
}

$ xgcc -w -m32 -O2 consistency.c
consistency.c: In function ‘f’:
consistency.c:9:1: error: invalid rtl sharing found in the insn
 }
 ^
(insn 57 55 33 5 (set (reg:SI 83 [ D.1743 ])
(if_then_else:SI (leu (reg:CC 17 flags)
(const_int 0 [0]))
(reg:SI 83 [ D.1743 ])
(reg:SI 59 [ iftmp.1 ]))) consistency.c:8 908 {*movsicc_noc}
 (expr_list:REG_EQUAL (ne:SI (subreg:SI (reg:DI 65 [ D.1745 ]) 0)
(const_int 0 [0]))
(nil)))
consistency.c:9:1: error: shared rtx
(subreg:SI (reg:DI 65 [ D.1745 ]) 0)
consistency.c:9:1: internal compiler error: internal consistency failure
linux-vdso.so.1: No such file or directory
0x6a8575 verify_rtx_sharing
../../srcdir/gcc/emit-rtl.c:2574
0x6a849f verify_rtx_sharing
../../srcdir/gcc/emit-rtl.c:2590
0x6a849f verify_rtx_sharing
../../srcdir/gcc/emit-rtl.c:2590
0x6ad46c verify_rtl_sharing()
../../srcdir/gcc/emit-rtl.c:2655
0x82f87c execute_function_todo
../../srcdir/gcc/passes.c:1966
0x8304cd execute_todo
../../srcdir/gcc/passes.c:1989
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.

Please note that it was found on an x86 machine, and that I had to add -m32 to
the commandline to reproduce the crash on my x86_64 machine.

[Bug c/55009] New: compile-time assertions no longer usable: error: variably modified ‘ari_sign_32_bit_and_wrap’ at file scope

[tg at mirbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55009

 Bug #: 55009
   Summary: compile-time assertions no longer usable: error:
variably modified ‘ari_sign_32_bit_and_wrap’ at file
scope
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@mirbsd.org


Hi everyone,

I’ve been using compile-time assertions, that is, compiling .c files with
arrays that are either 1 or -1 bytes long, depending on some assertion, for a
while now, and one of these now no longer works: the check whether a certain
integer type is 32-bit with usable wraparound, as asked for by -fwrapv. (I need
to check this because the program in question is a shell that guarantees this
behaviour to scripts run in it, even for signed integers, and recent GCC
versions are known to optimise the wraparound away, as it’s UD, strictly
spoken, but can be made to work.)

This affects recent gcc-4.6 and gcc-4.7 uploads into Debian and Ubuntu, at
least, as well as gcc trunk:

tg@zigo:~ $ /usr/lib/gcc-snapshot/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20121008-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--with-system-zlib --disable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-snap
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --with-arch-32=i586 --with-tune=generic --disable-werror
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.0 20121008 (experimental) [trunk revision 192192] (Debian
20121008-1) 
tg@zigo:~ $ cat t.c
#include 
typedef int32_t mksh_ari_t;
char ari_sign_32_bit_and_wrap[(

(mksh_ari_t)(mksh_ari_t)1 << 15) << 15) - 1) * 2 + 1) >
(mksh_ari_t)(mksh_ari_t)1 << 15) << 15) - 1) * 2 + 2)

) ? 1 : -1];

int main(void) { return (sizeof(ari_sign_32_bit_and_wrap)); }
tg@zigo:~ $ if /usr/lib/gcc-snapshot/bin/gcc -O t.c; then ./a.out; echo ok $?;
else echo error $?; fi
t.c:6:62: warning: integer overflow in expression [-Woverflow]
 (mksh_ari_t)(mksh_ari_t)1 << 15) << 15) - 1) * 2 + 2)
  ^
t.c:3:6: error: variably modified 'ari_sign_32_bit_and_wrap' at file scope
 char ari_sign_32_bit_and_wrap[(
  ^
error 1
tg@zigo:~ $ gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-2'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-2) 
tg@zigo:~ $ if gcc-4.7 -O t.c; then ./a.out; echo ok $?; else echo error $?; fi
t.c:6:62: warning: integer overflow in expression [-Woverflow]
t.c:3:6: error: variably modified ‘ari_sign_32_bit_and_wrap’ at file scope
error 1
tg@zigo:~ $ gcc-4.6 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.6.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-10'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysr

[Bug tree-optimization/55008] New: Internal compiler error : verify_ssa failed

[merkil at savhon dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008

 Bug #: 55008
   Summary: Internal compiler error : verify_ssa failed
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mer...@savhon.org


Hello !
The following testcase makes GCC 4.8.0 20121021 crash on my x86_64 machine (at
-O2 and higher) :

$ cat verify_ssa.c
#include 

void f(void)
{
int a, *p;

uint64_t b = 6309343725;

if(*p ? (b = 1) : 0)
if(b - (a = b /= 0) ? : (a + b))
while(1);
}

$ xgcc -w -O2 verify_ssa.c
verify_ssa.c: In function ‘f’:
verify_ssa.c:3:6: error: definition in block 3 follows the use
 void f(void)
  ^
for SSA_NAME: _12 in statement:
_12 = _12;
verify_ssa.c:3:6: internal compiler error: verify_ssa failed
linux-vdso.so.1: No such file or directory
0xa2cc93 verify_ssa(bool)
../../srcdir/gcc/tree-ssa.c:1052
0x82f7a2 execute_function_todo
../../srcdir/gcc/passes.c:1957
0x8304cd execute_todo
../../srcdir/gcc/passes.c:1989
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.

[Bug fortran/55007] WIN32, _WIN32, etc not defined in fortran

[earnie at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55007



--- Comment #2 from Earnie  2012-10-21 
17:05:05 UTC ---

Sorry, yes -cpp is needed.



gcc -cpp -E -dM nul.f | grep -i win



Produces an empty result



Expected:

#define _WIN32 1

#define __WINT_MAX__ 65535

#define __WINT_MIN__ 0

#define __WIN32 1

#define __WINNT 1

#define __WINNT__ 1

#define __WIN32__ 1

#define __SIZEOF_WINT_T__ 2

#define WIN32 1

#define __WINT_TYPE__ short unsigned int

#define WINNT 1



$ gcc --version

gcc.exe (GCC) 4.7.0



But I stated that in the meta data.

[Bug fortran/55007] WIN32, _WIN32, etc not defined in fortran

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55007



janus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||janus at gcc dot gnu.org



--- Comment #1 from janus at gcc dot gnu.org 2012-10-21 16:54:53 UTC ---

(In reply to comment #0)

> gcc -E -dM nul.f



>From this line I get:



gcc: error: gfortran does not support -E without -cpp



with



gcc version 4.7.2 20120920 [gcc-4_7-branch revision 191568] (SUSE Linux)

Target: x86_64-suse-linux





1) Which version arey you using?

2) Have you tried adding -cpp? (or alternatively: "gcc -E -dM nul.F")

[Bug fortran/55007] New: WIN32, _WIN32, etc not defined in fortran

[earnie at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55007



 Bug #: 55007

   Summary: WIN32, _WIN32, etc not defined in fortran

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ear...@users.sourceforge.net





The series of predefined variables defining the _WIN32 environment is not

defined in fortran.



gcc -E -dM nul.f | grep -i win



Produces an empty result



Expected:

#define _WIN32 1

#define __WINT_MAX__ 65535

#define __WINT_MIN__ 0

#define __WIN32 1

#define __WINNT 1

#define __WINNT__ 1

#define __WIN32__ 1

#define __SIZEOF_WINT_T__ 2

#define WIN32 1

#define __WINT_TYPE__ short unsigned int

#define WINNT 1

[Bug tree-optimization/55005] [4.8 Regression] gcc.c-torture/execute/loop-3.c FAILs with -fPIC

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55005



--- Comment #3 from Zdenek Sojka  2012-10-21 16:14:53 
UTC ---

(In reply to comment #2)

> Started with http://gcc.gnu.org/viewcvs?view=revision&revision=192538



Thanks for bisecting. The testcase from comment #1 was failing even before that

(though instead of segfaulting, the code ended in an endless loop), so it might

be a bit different problem.

[Bug tree-optimization/55005] [4.8 Regression] gcc.c-torture/execute/loop-3.c FAILs with -fPIC

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55005



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-21

 CC||mpolacek at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #2 from Marek Polacek  2012-10-21 
16:10:30 UTC ---

Started with http://gcc.gnu.org/viewcvs?view=revision&revision=192538

[Bug fortran/54797] Gnu Fortran compiler does not recognize module file it created

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54797



Thomas Koenig  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-10-21

 CC||tkoenig at gcc dot gnu.org

 Ever Confirmed|0   |1

[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818



Thomas Koenig  changed:



   What|Removed |Added



 CC||tkoenig at gcc dot gnu.org



--- Comment #4 from Thomas Koenig  2012-10-21 
14:49:55 UTC ---

TRANSFER returns its length as a gfc_array_index_type (8 bytes

for 64 bits) and the concatenation operator as a standard string

length, 4 bytes.

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119



Mikael Morin  changed:



   What|Removed |Added



 CC||mikael at gcc dot gnu.org



--- Comment #10 from Mikael Morin  2012-10-21 
13:52:35 UTC ---

(In reply to comment #8)

> Actually, the situation is a bit bizarre. There are no conforming programs for

> which bounds-checking can trigger... all these bounds-checking statements can

> be just optimized away :-). That's not quite what the users want...



Well, if the middle-end is able to prove that the bounds checking code is

useless, it may as well remove it.  In the case of a bogus array access, that

code is useful, so the middle-end shouldn't be able to prove that it isn't, and

the it won't be removed.

For the other case (code removed where it should stay) there is a bug in the

compiler, but that's not what -fbounds-check is supposed to check ;-).





Regarding the initial question:

> Hi,

> can someone fortran aware please double-check that the tests

> 

> * gfortran.dg/bounds_check_9.f90: New test.

> * gfortran.dg/bounds_check_fail_2.f90: New test.

> 

> do not contain out of bounds access?



There should be none, as the -fbounds-check instrumentation is supposed to

catch out of bounds early enough, so that the code is valid from a middle-end

point of view.

[Bug fortran/54997] -Wunused-function gives false warnings for procedures passed as actual argument

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997



--- Comment #5 from janus at gcc dot gnu.org 2012-10-21 13:48:38 UTC ---

(In reply to comment #4)

> The following removes the warning for s3:

> 

> [...]

> 

> but it also removes the warning on procedures which are really unused :(



This fixed by the following:



Index: gcc/fortran/parse.c

===

--- gcc/fortran/parse.c(revision 192619)

+++ gcc/fortran/parse.c(working copy)

@@ -3928,7 +3928,6 @@ gfc_fixup_sibling_symbols (gfc_symbol *sym, gfc_na

   gfc_symtree *st;

   gfc_symbol *old_sym;



-  sym->attr.referenced = 1;

   for (ns = siblings; ns; ns = ns->sibling)

 {

   st = gfc_find_symtree (ns->sym_root, sym->name);

@@ -4050,7 +4049,6 @@ parse_contained (int module)

   /* Mark this as a contained function, so it isn't replaced

  by other module functions.  */

   sym->attr.contained = 1;

-  sym->attr.referenced = 1;



   /* Set implicit_pure so that it can be reset if any of the

  tests for purity fail.  This is used for some optimisation

[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736



Thomas Koenig  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #11 from Thomas Koenig  2012-10-21 
13:44:12 UTC ---

Also fixed on 4.6, closing.

[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736

--- Comment #10 from Thomas Koenig  2012-10-21 
13:43:40 UTC ---
Author: tkoenig
Date: Sun Oct 21 13:43:32 2012
New Revision: 192653

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192653
Log:
2012-10-21  Thomas König  

PR libfortran/54736
Backport from trunk
* runtime/environ.c (search_unit):  Correct logic
for binary search.
(mark_single):  Fix index errors.


Modified:
branches/gcc-4_6-branch/libgfortran/ChangeLog
branches/gcc-4_6-branch/libgfortran/runtime/environ.c

[Bug c++/55003] [C++11] Member function pointer not working as constexpr initializer

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55003

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-10-21 13:36:28 UTC ---
The code presented code example seems incomplete, because it is accepted as
written. Here a complete code-example compiled with gcc 4.8.0 20121014
(experimental) using the compiler flags

-Wall -std=c++11 -pedantic

//-
template
struct MemberGet{
   static constexpr auto assign_operator =
   static_cast(&T::operator=);
};

struct X {};

MemberGet mg;
//-

"3|error: declaration of 'constexpr const auto MemberGet::assign_operator'
has no initializer|"

I agree that this code should be accepted.

[Bug tree-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55006



Dominique d'Humieres  changed:



   What|Removed |Added



 Target||x86_64-apple-darwin10

   Host||x86_64-apple-darwin10

  Build||x86_64-apple-darwin10



--- Comment #2 from Dominique d'Humieres  2012-10-21 
12:38:53 UTC ---

On powerpc-apple-darwin9, aermod is compiled correctly at revision 192623, so

changing the host/target/build fields.

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194



--- Comment #49 from Eric Botcazou  2012-10-21 
12:36:21 UTC ---

Author: ebotcazou

Date: Sun Oct 21 12:36:16 2012

New Revision: 192651



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192651

Log:

PR rtl-optimization/44194

* calls.c (expand_call): Allow sibling calls in the PARALLEL case.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/calls.c

[Bug tree-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55006



--- Comment #1 from Dominique d'Humieres  2012-10-21 
12:24:23 UTC ---

Created attachment 28499

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28499

Compressed archive for aermod



The attachment contains the files needed to compile and run the test aermod.

The original source has been split in aermod_red.f90, wake_dfsn.f90, and

wake_dfsn2.f90 (the two subroutines that are miscompiled).



It can be used as



gfc -c -m64 -O2 -funroll-loops aermod_red.f90 wake_dfsn.f90 wake_dfsn2.f90

gfc aermod_red.o wake_dfsn.o wake_dfsn2.o



where gfc is gfortran at revision 192526 or later. This gives the miscompiled

code. If the files wake_dfsn.f90 and wake_dfsn2.f90 are then compiled with

revision 192525 or older (and same options), then the new executable is OK.

[Bug tree-optimization/55005] [4.8 Regression] gcc.c-torture/execute/loop-3.c FAILs with -fPIC

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55005



--- Comment #1 from Zdenek Sojka  2012-10-21 12:14:59 
UTC ---

This isn't the only testcase that started failing recently.



One interesting flag combination:

$ gcc -O2 -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce testcase.c && ./a.out

Segmentation fault



In this case, the body of main() isn't generated at all, so the code runs away

immediatelly after jumping to main().



main:

.LFB2:

.cfi_startproc

.cfi_endproc

.LFE2:

.sizemain, .-main

[Bug tree-optimization/55006] New: [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55006



 Bug #: 55006

   Summary: [4.8 Regression] aermod.f90 is miscompiled with '-m64

-O2 -funroll-loops' after revision 192526

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: domi...@lps.ens.fr

CC: hubi...@gcc.gnu.org, ste...@gcc.gnu.org





The polyhedron test aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops'

after revision 192526



Author:steven

Date:Wed Oct 17 06:15:38 2012 UTC (4 days, 5 hours ago)

Changed paths:3

Log Message:

* df-problems.c (df_kill_notes): Split up in two functions.

(df_remove_dead_and_unused_notes): New function, first half of

df_kill notes to remove all REG_DEAD and REG_UNUSED notes.

(df_remove_dead_eq_notes): New function, second half of df_kill_notes

to remove REG_EQUAL and REG_EQUIV notes referring to dead registers.

(df_note_bb_compute): Call df_remove_dead_and_unused_notes instead

of df_kill_notes.  Call df_remove_dead_eq_notes after processing insn.



* web.c (web): Re-add DF_RD_PRUNE_DEAD_DEFS;



The executable aborts with the following backtrace



...

 F indicates top of profile (=1) or below (=0)

+Now Processing Data For Day No.1 of 1999



Program received signal SIGSEGV, Segmentation fault.

wake_sig (x=46.0831375, xd=104.343887, xold=44.0807877, turbz=, turby=, szold=Cannot access memory at address 0x8

) at aermod.f90:38204

38204 SZ = SZOLD + DELX*TURBZ

(gdb) bt

#0  wake_sig (x=46.0831375, xd=104.343887, xold=44.0807877, turbz=, turby=, szold=Cannot access memory at

address 0x8

) at aermod.f90:38204

#1  0x00010003302c in wake_dfsn (ldbhr=.FALSE., xi=40.076088,

szi=0.596251428, syi=0.618943393, z=7.06923056) at aermod.f90:36900

#2  0x00010003852a in numrise (ldbhr=.FALSE., h=5, reff=, texit=262.600189, wexit=, ntr=50, xtr=..., 

ytr=..., ztr=..., rtr=..., linwake=.TRUE., numwake=0) at aermod.f90:35360

#3  0x00010003b3d6 in prmdelh (xarg=30.6145649, l_inwake=.TRUE.) at

aermod.f90:39784

#4  0x00010003cc64 in prmcalc (xbrec=, ybrec=) at aermod.f90:6786

#5  0x0001000572b2 in pcalc () at aermod.f90:6282

#6  0x00010005905b in calc () at aermod.f90:5761

#7  0x000100079868 in hrloop () at aermod.f90:2596

#8  0x0001000e7367 in aermod () at aermod.f90:2194

#9  0x0001000f864f in main (argc=, argv=) at aermod.f90:2038

#10 0x000116e4 in start ()



The two subroutines which are miscompiled are wake_dfsn and wake_dfsn2, see the

attached compressed archive for testing it.

[Bug tree-optimization/54901] [4.8 Regression] air.f90, aermod.f90, and mdbx.f90 are miscompiled with '-m64 -O3 -funroll-loops -fwhole-program' after revision 192213

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54901



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #4 from Dominique d'Humieres  2012-10-21 
11:54:47 UTC ---

Fixed by revision 192413:



Author:hubicka

Date:Fri Oct 12 20:36:09 2012 UTC (8 days, 15 hours ago)

Changed paths:4

Log Message:



* web.c (web_main): Do not set DF_RD_PRUNE_DEAD_DEFS flag.



> Probably a dup of the discussion going on here:

> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01414.html



So this looks true. Closing.

[Bug fortran/54465] Implement -Wextra for Fortran

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54465



Thomas Koenig  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Thomas Koenig  2012-10-21 
11:08:23 UTC ---

Fixed on trunk, closing.

[Bug fortran/54725] cross gfortran always searches host paths (e.g. /usr/include)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54725



Tobias Burnus  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #10 from Tobias Burnus  2012-10-21 
10:57:50 UTC ---

FIXED on the trunk (4.8).



Thanks for the bug report, the debugging and for testing the patch!

[Bug fortran/54725] cross gfortran always searches host paths (e.g. /usr/include)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54725



--- Comment #9 from Tobias Burnus  2012-10-21 
10:51:30 UTC ---

Author: burnus

Date: Sun Oct 21 10:51:26 2012

New Revision: 192650



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192650

Log:

gcc/

2012-10-21  Tobias Burnus  



PR fortran/54725

* Makefile.in (TARGET_SYSTEM_ROOT_DEFINE): New.



gcc/fortran

2012-10-21  Tobias Burnus  



PR fortran/54725

* Make-lang.in (CFLAGS-cpp.o): Use TARGET_SYSTEM_ROOT_DEFINE.

* cpp.o (gfc_cpp_init_options): Use it for

setting gfc_cpp_option.sysroot.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/Makefile.in

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/Make-lang.in

trunk/gcc/fortran/cpp.c

[Bug fortran/54465] Implement -Wextra for Fortran

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54465



--- Comment #2 from Thomas Koenig  2012-10-21 
10:32:05 UTC ---

Author: tkoenig

Date: Sun Oct 21 10:32:02 2012

New Revision: 192649



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192649

Log:

2012-10-21  Thomas Koenig  



PR fortran/54465

* lang.opt (Wextra):  Add.

* invoke.texi:  Document that -Wc-binding-type, -Wconversion

and -Wline-truncation are implied by -Wall.  Document that

-Wcompare-reals is implied by -Wextra.  Document -Wextra.

* options.c (set_Wextra):  New function.

(gfc_handle_option):  Handle -Wextra.



2012-10-21  Thomas Koenig  



PR fortran/54465

* gfortran.dg/wextra_1.f:  New test.





Added:

trunk/gcc/testsuite/gfortran.dg/wextra_1.f

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/invoke.texi

trunk/gcc/fortran/lang.opt

trunk/gcc/fortran/options.c

trunk/gcc/fortran/trans.c

trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/47389] ICE: in calc_dfs_tree, at dominance.c:395 with -fno-combine-stack-adjustments -fno-dse -fno-tree-forwprop

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47389



--- Comment #8 from Zdenek Sojka  2012-10-21 10:16:41 
UTC ---

(In reply to comment #7)

> I have done several tests and it seems -fno-combine-stack-adjustments doesn't

> cause any ICEs as it used to. However, 4.7.3 still crashes, even though the 
> fix

> for PR53602 has been backported to 4.7.1. Both testcases behave the same.



Oh, only part of PR53602 has been backported; r188360 (

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53602#c13 ) hasn't.

[Bug rtl-optimization/47389] ICE: in calc_dfs_tree, at dominance.c:395 with -fno-combine-stack-adjustments -fno-dse -fno-tree-forwprop

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47389



Zdenek Sojka  changed:



   What|Removed |Added



  Known to work||4.8.0

  Known to fail||4.6.4, 4.7.3



--- Comment #7 from Zdenek Sojka  2012-10-21 10:14:23 
UTC ---

I have done several tests and it seems -fno-combine-stack-adjustments doesn't

cause any ICEs as it used to. However, 4.7.3 still crashes, even though the fix

for PR53602 has been backported to 4.7.1. Both testcases behave the same.



Tested revisions:

r192641 - OK

4.7 r191640 - crash

4.6 r191640 - crash