[Bug rtl-optimization/56992] building Wine with -Og causes GCC to seg fault

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||jakub at gcc dot gnu.org

  Component|c   |rtl-optimization

 Resolution||FIXED

   Target Milestone|--- |4.8.1



--- Comment #2 from Jakub Jelinek  2013-04-18 
06:37:30 UTC ---

Fixed already by:

Author: krebbel

Date: Fri Apr 12 05:39:49 2013

New Revision: 197840



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

Log:

2013-04-12  Andreas Krebbel  



* ifcvt.c (end_ifcvt_sequence): Mark a and b for unsharing as

well.





Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/ifcvt.c



I've added the testcase:

Author: jakub

Date: Thu Apr 18 06:29:35 2013

New Revision: 198046



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

Log:

PR rtl-optimization/56992

* gcc.dg/pr56992.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/pr56992.c

Modified:

trunk/gcc/testsuite/ChangeLog



Author: jakub

Date: Thu Apr 18 06:30:39 2013

New Revision: 198047



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

Log:

PR rtl-optimization/56992

* gcc.dg/pr56992.c: New test.



Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr56992.c

Modified:

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug fortran/56994] New: Incorrect documentation for Fortran NEAREST intrinsic function

[spam.brian.taylor at gmail dot com]

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



 Bug #: 56994

   Summary: Incorrect documentation for Fortran NEAREST intrinsic

function

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: trivial

  Priority: P3

 Component: fortran

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

ReportedBy: spam.brian.tay...@gmail.com





The GNU Fortran documentation** for the Fortran intrinsic function NEAREST(X,S)

says that S is an optional argument.  It is not optional according to the

Fortran standard.  It is implemented correctly in gfortran, so this is only an

error in the documentation.



** http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gfortran/NEAREST.html

[Bug c/56682] -fsanitize documentation

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2013-04-18 
01:58:03 UTC ---

>-fsanitize=thread 



I think it requires -fPIE but really it should not.

[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well

[jvdelisle at gcc dot gnu.org]

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



--- Comment #6 from Jerry DeLisle  2013-04-18 
01:21:42 UTC ---

I like Jannes idea with the flags.  Also, it seems that at the time we open a

file we know it is /dev/null or /dev/nul in some cases by the file name.  It

would be very low overhead in a few cases to disable some or all checks and

even disable the writing completely.  We would not get all situations, but the

low hanging fruit we could.  It could be done by setting a "NULL" bit.



One could consider doing this at compile time in some cases where the frontend

could have more elaborate configuration checks that determine the name of the

null device on the target system and look for its use. (probably not really

worth if fur NULL I/O



The other idea to consider is a compiler flag, say -fast-IO or similar that

also disables the extra error checking that is not critical to runtime after a

program has been debugged.

[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()

[bugfeed at online dot de]

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



--- Comment #10 from Leif Leonhardy  2013-04-18 
01:17:31 UTC ---

"One proposed requirement on setjmp is that it be usable like any other

function, that is, that it be callable in *any* expression context, and that

the expression evaluate correctly whether the return from setjmp is direct or

via a call to longjmp. Unfortunately, any implementation of setjmp as a

conventional called function cannot know enough about the calling environment

to save any temporary registers or dynamic stack locations used part way

through an expression evaluation. [...] The temporaries may be correct on the

initial call to setjmp, but are not likely to be on any return initiated by a

corresponding call to longjmp. These considerations dictated the constraint

that setjmp be called only from within fairly simple expressions, ones not

likely to need temporary storage.



An alternative proposal considered by the C89 Committee was to require that

implementations recognize that calling setjmp is a special case, and hence that

they take whatever precautions are necessary to restore the setjmp environment

properly upon a longjmp call. This proposal was rejected on grounds of

consistency: implementations are currently allowed to implement library

functions specially, but no other situations require special treatment."





So according to this (The C99 Rationale [1], page 139 ff., likewise the Single

UNIX Specification), here setjmp() is simply used in an invalid context (i.e.,

in an assignment statement). ;-)



Still, with -Og at least, GCC 4.8.0 produces wrong code even if setjmp() is

used in an "allowed" context (as in e.g. if (setjmp(...)>0) ..., or switch

(setjmp(...)) { ... }), and no matter whether n is declared volatile or not.





[1] http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

[Bug target/56993] New: power gcc built 416.gamess generates wrong result

[carrot at google dot com]

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



 Bug #: 56993

   Summary: power gcc built 416.gamess generates wrong result

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: car...@google.com

  Host: powerpc-linux-gnu

Target: powerpc-linux-gnu

 Build: powerpc-linux-gnu





When I use the trunk gcc to run spec2006 416.gamess, I got the following error



$ runspec --config=test.cfg --tune=base --size=test --nofeedback --noreportable

game

runspec v6152 - Copyright 1999-2008 Standard Performance Evaluation Corporation

Using 'linux-ydl23-ppc' tools

Reading MANIFEST... 18357 files

Loading runspec modules

Locating benchmarks...found 31 benchmarks in 6 benchsets.

Reading config file '/usr/local/google/carrot/spec2006/config/test.cfg'

Benchmarks selected: 416.gamess

Compiling Binaries

  Building 416.gamess base Linux64 default: (build_base_Linux64.)



Build successes: 416.gamess(base)



Setting Up Run Directories

  Setting up 416.gamess test base Linux64 default: created

(run_base_test_Linux64.)

Running Benchmarks

  Running (#1) 416.gamess test base Linux64 default





Contents of exam29.err



STOP IN ABRT







*** Miscompare of exam29.out; for details see

   

/usr/local/google/carrot/spec2006/benchspec/CPU2006/416.gamess/run/run_base_test_Linux64./exam29.out.mis

Invalid run; unable to continue.

If you wish to ignore errors please use '-I' or ignore_errors



The log for this run is in

/usr/local/google/carrot/spec2006/result/CPU2006.111.log

The debug log for this run is in

/usr/local/google/carrot/spec2006/result/CPU2006.111.log.debug



*

* Temporary files were NOT deleted; keeping temporaries such as

* /usr/local/google/carrot/spec2006/result/CPU2006.111.log.debug and

* /usr/local/google/carrot/spec2006/tmp/CPU2006.111

* (These may be large!)

*

runspec finished at Wed Apr 17 16:37:27 2013; 93 total seconds elapsed







My gcc is configured as



$ gcc -v

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnu/4.6/lto-wrapper

Target: powerpc-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-12'

--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 --enable-clocale=gnu --enable-libstdcxx-debug

--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-secureplt

--disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux

--with-cpu=default32 --with-long-double-128 --enable-checking=release

--build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu

Thread model: posix

gcc version 4.6.2 (Debian 4.6.2-12)





GCC4.8 has the same error, but gcc4.7 is good.

[Bug c/56992] building Wine with -Og causes GCC to seg fault

[jimportal at gmail dot com]

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



--- Comment #1 from James Eder  2013-04-17 23:47:39 
UTC ---

Created attachment 29892

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

testcase-min.c

[Bug c/56992] New: building Wine with -Og causes GCC to seg fault

[jimportal at gmail dot com]

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

 Bug #: 56992
   Summary: building Wine with -Og causes GCC to seg fault
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jimpor...@gmail.com


GCC seg faults when building Wine with -Og.  The Wine developers pointed me at
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction which helped me reduce
the problem down to the attached file (~14 lines).

$ gcc -Og -c testcase-min.c
testcase-min.c: In function ‘DnsHostnameToComputerNameA’:
testcase-min.c:13:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I'm using "gcc (GCC) 4.8.0 20130411 (prerelease)" as supplied by ArchLinux.

My processor is an AMD Phenom(tm) II X4 955

For hints about how GCC was built, you can look for the configure line here:
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/gcc-multilib

[Bug rtl-optimization/56847] [4.8/4.9 Regression] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

[shenhan at google dot com]

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



--- Comment #8 from Han Shen  2013-04-17 23:42:22 
UTC ---

Hi, any progress on this?



Thanks!

[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c

[glisse at gcc dot gnu.org]

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



--- Comment #12 from Marc Glisse  2013-04-17 
21:49:15 UTC ---

(In reply to comment #11)

> If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my

> ability to extract a stand-alone-test from glibc-testsuite then I'm

> realy sorry for not having the necessary skills (as already stated).



Skills can be learned, and the best way is through practice. Ideally someone

with the right combination of knowledge, hardware and free time would look at

it, and you seem to be the closest currently ;-)



> Why not simply using the failing test-cases from gcc-testsuite

> which are all standalone and depends on XOP:



Good idea. I suggest you pick a simple one:



> +FAIL: gcc.target/i386/sse2-mul-1.c execution test



it looks like a list of several tests in a row. If you can first replace the

aborts with printf to determine the first one that fails, then remove

everything after that point, you have already narrowed the issue quite a bit.

Then you can try to simplify what remains. Ideally, you would get a program

small enough that posting the dumps would show the obvious issue. Do make sure

while reducing the program that it still works correctly without the bdver2

option.

[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32

[ebotcazou at gcc dot gnu.org]

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



--- Comment #15 from Eric Botcazou  2013-04-17 
21:35:54 UTC ---

> Why below output has '-march=pentiumpro'?



I think it's the autodetected arch, but maybe I'm confused.  Never mind.

[Bug c/56989] wrong location in error message

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-04-17
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  2013-04-17 
21:08:52 UTC ---
Index: c-typeck.c
===
--- c-typeck.c  (revision 198021)
+++ c-typeck.c  (working copy)
@@ -1981,11 +1981,12 @@ default_conversion (tree exp)
   if (TREE_NO_WARNING (orig_exp))
 TREE_NO_WARNING (exp) = 1;

   if (code == VOID_TYPE)
 {
-  error ("void value not ignored as it ought to be");
+  error_at (EXPR_LOC_OR_HERE (exp),
+"void value not ignored as it ought to be");
   return error_mark_node;
 }

   exp = require_complete_type (exp);
   if (exp == error_mark_node)



/home/manuel/void.c:6:12: error: void value not ignored as it ought to be
   if (voidf() < 0
^

The location could be even better, but that is what the c-parser records.

I like Clang's diagnostic much more:

/home/manuel/void.c:6:15: error: invalid operands to binary expression ('void'
and 'int')
  if (voidf() < 0
  ~~~ ^ ~

It is similar to what g++ produces:

/home/manuel/void.c:6:17: error: invalid operands of types ‘void’ and ‘int’ to
binary ‘operator<’
   if (voidf() < 0
 ^

but with better locations.

[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c

[winfried.mag...@t-online.de]

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



--- Comment #11 from Winfried Magerl  2013-04-17 
21:02:38 UTC ---

Hi Mike,



On Wed, Apr 17, 2013 at 08:15:47PM +, mikpe at it dot uu.se wrote:

>  

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

>  

> --- Comment #10 from Mikael Pettersson  2013-04-17 
> 20:15:47 UTC --- 

> (In reply to comment #9) 

> > How to proceed? 

>  

> Derive a stand-alone test case from the failing glibc module and whatever 
> glibc 

> code it requires, then minimize it. 



If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my

ability to extract a stand-alone-test from glibc-testsuite then I'm

realy sorry for not having the necessary skills (as already stated).



Why not simply using the failing test-cases from gcc-testsuite

which are all standalone and depends on XOP:



+FAIL: gcc.c-torture/execute/pr51581-1.c execution,  -O3 -fomit-frame-pointer

+FAIL: gcc.c-torture/execute/pr51581-1.c execution,  -O3 -fomit-frame-pointer

-funroll-loops

+FAIL: gcc.c-torture/execute/pr51581-1.c execution,  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions

+FAIL: gcc.c-torture/execute/pr51581-1.c execution,  -O3 -g

+FAIL: gcc.c-torture/execute/pr51581-2.c execution,  -O3 -fomit-frame-pointer

+FAIL: gcc.c-torture/execute/pr51581-2.c execution,  -O3 -fomit-frame-pointer

-funroll-loops

+FAIL: gcc.c-torture/execute/pr51581-2.c execution,  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions

+FAIL: gcc.c-torture/execute/pr51581-2.c execution,  -O3 -g

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -O1

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -O2

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -O3 -fomit-frame-pointer

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -O3 -fomit-frame-pointer

-funroll-loops

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -O3 -g

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -Os

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -Og -g

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -O2 -flto

-fno-use-linker-plugin -flto-partition=none

+FAIL: gcc.c-torture/execute/pr53645.c execution,  -O2 -flto

-fuse-linker-plugin -fno-fat-lto-objects

+FAIL: gcc.dg/vect/pr51581-1.c execution test

+FAIL: gcc.dg/vect/pr51581-2.c execution test

+FAIL: gcc.dg/vect/pr51581-3.c execution test

+FAIL: gcc.dg/vect/pr51581-1.c -flto execution test

+FAIL: gcc.dg/vect/pr51581-2.c -flto execution test

+FAIL: gcc.dg/vect/pr51581-3.c -flto execution test

+FAIL: gcc.target/i386/avx-mul-1.c execution test

+FAIL: gcc.target/i386/avx-pr51581-1.c execution test

+FAIL: gcc.target/i386/avx-pr51581-2.c execution test

+FAIL: gcc.target/i386/sse2-mul-1.c execution test

+FAIL: gcc.target/i386/sse4_1-mul-1.c execution test



Or is this a formal problem because the subject does not realy match

the whole problem which looks like a more general problem with

extensions specific to bdver1/2/3 (and for this not reproducable

on other cpu's).



regards



winfried

[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32

[mail2arthur at gmail dot com]

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



--- Comment #14 from Arthur Zhang  2013-04-17 
21:02:14 UTC ---

(In reply to comment #13)

> > What is the benefit to use '--build=i686-pc-mingw32' than 
> > '--with-arch=i686'?

> 

> It doesn't force -march=i686 by default.



Why below output has '-march=pentiumpro'?



bash-3.1$ gcc -v  -o t.exe ./test.c

Using built-in specs.

COLLECT_GCC=c:\MinGW\bin\gcc.exe

COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.8.0/lto-wrappe

r.exe

Target: i686-pc-mingw32

Configured with: ../gcc-4.8.0/configure

--enable-languages=c,c++,ada,fortran,obj

c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared

--enable-libgo

mp --disable-win32-registry --enable-libstdcxx-debug

--enable-version-specific-r

untime-libs --build=i686-pc-mingw32 --prefix=/mingw

Thread model: win32

gcc version 4.8.0 (GCC)

COLLECT_GCC_OPTIONS='-v' '-o' 't.exe' '-mtune=generic' '-march=pentiumpro'

...

[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||WONTFIX



--- Comment #13 from Eric Botcazou  2013-04-17 
20:41:54 UTC ---

> I can build successfully with either '--with-arch=i686 --build=mingw32' or

> '--build=i686-pc-mingw32', but as I mentioned in comment 10, change build

> target cause packaging issue. 



Too bad, but I don't think this will ultimately change the decision, as

i686-pc-mingw32 is the standard triplet for Windows these days.



> What is the benefit to use '--build=i686-pc-mingw32' than '--with-arch=i686'?



It doesn't force -march=i686 by default.

[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c

[mikpe at it dot uu.se]

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



--- Comment #10 from Mikael Pettersson  2013-04-17 
20:15:47 UTC ---

(In reply to comment #9)

> How to proceed?



Derive a stand-alone test case from the failing glibc module and whatever glibc

code it requires, then minimize it.

[Bug c++/56991] New: constexpr std::initializer_list crashes on too complex initialization

[morwenn29 at hotmail dot fr]

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



 Bug #: 56991

   Summary: constexpr std::initializer_list crashes on too complex

initialization

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: morwen...@hotmail.fr





I found some strange behaviour that, after a discussion on StackOverflow, seems

to be a bug (discussion here:

http://stackoverflow.com/questions/16057690/confusion-about-constant-expressions/16068953?noredirect=1#16068953).



It seems that GCC implements N3471 which means that every function of an

std::initializer_list are constexpr. When trying to pass simple constexpr

things in the initializer_list, it works fine:



#include 

#include 



int main()

{

constexpr std::array a = {{ 1, 2, 3 }};

constexpr int a0 = a[0];

constexpr int a1 = a[1];

constexpr int a2 = a[2];

constexpr std::initializer_list b = { a0, a1, a2 };



return 0;

}



However, without the intermediate variables a0, a1 and a2, the example above

crashes:



#include 

#include 



int main()

{

constexpr std::array a = {{ 1, 2, 3 }};

constexpr std::initializer_list b = { a[0], a[1], a[2] };



return 0;

}



The error is the following one:



error: 'const std::initializer_list{((const int*)(&)), 3u}' is

not a constant expression



This last example works fine if I remove the constexpr qualifier at the

beginning of the line or if I replace the initializer_list by a std::array. It

seems that the bug is only triggered when using std::initializer_list with

constexpr.

[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32

[mail2arthur at gmail dot com]

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



Arthur Zhang  changed:



   What|Removed |Added



 Status|RESOLVED|NEW

 Resolution|WONTFIX |



--- Comment #12 from Arthur Zhang  2013-04-17 
19:44:34 UTC ---

I can build successfully with either '--with-arch=i686 --build=mingw32' or

'--build=i686-pc-mingw32', but as I mentioned in comment 10, change build

target cause packaging issue. 



What is the benefit to use '--build=i686-pc-mingw32' than '--with-arch=i686'?



Thanks.

[Bug fortran/40958] module files too large

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #11 from Joost VandeVondele  
2013-04-17 19:36:45 UTC ---

With these patches in, parallel compilation of multi-file cp2k becomes

significantly faster. Time for a full build goes from 70s to 50s. I think that

in a parallel build the IO bottleneck (bandwidth) was significant, while this

is now much improved. The effect will likely be even larger on mounted

filesystems.

[Bug sanitizer/56990] New: ICE: SIGFPE with -fsanitize=thread and empty struct

[zsojka at seznam dot cz]

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



 Bug #: 56990

   Summary: ICE: SIGFPE with -fsanitize=thread and empty struct

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: sanitizer

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

ReportedBy: zso...@seznam.cz

CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,

ja...@gcc.gnu.org, k...@gcc.gnu.org





Created attachment 29891

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

reduced testcase



Compiler output:

$ gcc -fsanitize=thread testcase.c

testcase.c: In function 'foo':

testcase.c:3:6: internal compiler error: Floating point exception

 void foo(struct S *p)

  ^

0xa24dbf crash_signal

/mnt/svn/gcc-trunk/gcc/toplev.c:332

0xa3af12 instrument_expr

/mnt/svn/gcc-trunk/gcc/tsan.c:134

0xa3c406 instrument_gimple

/mnt/svn/gcc-trunk/gcc/tsan.c:612

0xa3c406 instrument_memory_accesses

/mnt/svn/gcc-trunk/gcc/tsan.c:635

0xa3c406 tsan_pass

/mnt/svn/gcc-trunk/gcc/tsan.c:700

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.





Program received signal SIGFPE, Arithmetic exception.

0x00a3af12 in instrument_expr (gsi=..., expr=0x76d9f000,

is_write=is_write@entry=true) at /mnt/svn/gcc-trunk/gcc/tsan.c:134

134   if (bitpos % (size * BITS_PER_UNIT)



Tested revisions:

r198018 - crash

4.8 r196898 - crash

[Bug c/56989] New: wrong location in error message

[tromey at gcc dot gnu.org]

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

 Bug #: 56989
   Summary: wrong location in error message
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tro...@gcc.gnu.org


Consider this program:

extern void voidf(void);
extern int intf(void);

int check(void)
{
  if (voidf() < 0
  || intf() < 0)
return -1;
  return 0;
}


I compiled it with a recent git gcc and got:

barimba. gcc --syntax-only qq.c
qq.c: In function ‘check’:
qq.c:7:7: error: void value not ignored as it ought to be
   || intf() < 0)
   ^

I think the error message would be more helpful if it pointed
to the call to voidf.

[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c

[winfried.mag...@t-online.de]

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



--- Comment #9 from Winfried Magerl  2013-04-17 
18:41:06 UTC ---

Hi,



at least one confirmation. I've done some further checks about

float-errors in glibc and that FAM/FAM4 are the extension responsible

for the additional float-errors.



How to proceed?



>From my point of view and comapred with '-march=amdfam10' the

extensions XOP/FAM4/FAM are responsible for the failed tests.



Disabling it in gcc-4.8-noxop/gcc/config/i386/i386.c brings me back

to the same test-results I'm seeing with amdfam10 (excluding all

sorts of scan-*-errors).



I would propose the following patch for bdver2-support because

features which are untested and known to break code (like for example

all the additional test-errors in the gcc-testsuite) should be

disabeled:



--- gcc-4.8-noxop/gcc/config/i386/i386.c.orig   2013-04-12 20:49:09.181351855

+0200

+++ gcc-4.8-noxop/gcc/config/i386/i386.c2013-04-12 23:15:09.112185980

+0200

@@ -2976,9 +2976,9 @@

   {"bdver2", PROCESSOR_BDVER2, CPU_BDVER2,

PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3

| PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1

-   | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_FMA4

-   | PTA_XOP | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C

-   | PTA_FMA | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},

+   | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX

+   | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C

+   | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},

   {"bdver3", PROCESSOR_BDVER3, CPU_BDVER3,

PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3

| PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1



just an examp,e because the features should be disabled in bdver1/3 too

(XOP/FMA4/FMA are only available in bdver1/2/3). Maybe adding the

gcc-developers from @amd.com?



regards



winfried

[Bug ada/40986] [4.6 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27

[ludo...@ludovic-brenta.org]

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



Ludovic Brenta  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

  Known to work|4.7.2   |

 Resolution|FIXED   |

  Known to fail||4.7.2



--- Comment #16 from Ludovic Brenta  2013-04-17 
18:30:40 UTC ---

gcc-4.7 -c -I./ -gnato -gnatwl -gnatwauJF -gnatef -g -fno-strict-aliasing

-gnatwA -I- ./test.adb

+===GNAT BUG DETECTED==+

| 4.7.2 (x86_64-linux-gnu) Assert_Failure sinfo.adb:388|

| Error detected at a-unccon.ads:23:27 |





Thanks Markus for noticing the interference of gnatchop.  I did the mistake

of gnatchopping the reproducer, this hid the problem.

[Bug middle-end/56988] New: ipa-cp incorrectly propagates a field of an aggregate

[eraman at google dot com]

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



 Bug #: 56988

   Summary: ipa-cp incorrectly propagates a field of an aggregate

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: era...@google.com





Created attachment 29890

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

Reduced test case



$ trunk_g++ --version

trunk_g++ (GCC) 4.9.0 20130416 (experimental)





$ trunk_g++ -S -O2  -std=c++11 -fno-exceptions upstream_test_case.ii && grep

"mov.* _ZTVN12_GLOBAL__N_18RCTesterE" upstream_test_case.s

movq%rax, _ZTVN12_GLOBAL__N_18RCTesterE+24(%rip)



The generated assembly attempts to write into RCTester class's vtable.



>From the dump generated by -fdump-ipa-whole-program-all (just before ipa-cp),

the caller has the following code:



  # .MEM_11 = VDEF <.MEM_10>

  obj_3->D.2045._vptr.ReferenceCountedD.2013 = &MEM[(voidD.45

*)&_ZTVN12_GLOBAL__N_18RCTesterED.2049 + 16B];

  # .MEM_12 = VDEF <.MEM_11>

  obj_3->destructed_D.2025 = 0B;

  # .MEM_13 = VDEF <.MEM_12>

  obj_3->owner_D.2026 = 0B;

  # .MEM_5 = VDEF <.MEM_13>

  # USE = nonlocal null { D.2015 D.2049 } (glob)

  # CLB = nonlocal null { D.2015 D.2049 } (glob)

  _ZN12_GLOBAL__N_19TestResetEPNS_8RCTesterED.2068 (obj_3);





At the callee, we see:



void {anonymous}::TestReset({anonymous}::RCTester*) (struct RCTesterD.2017 *

objD.2067)

{

  const struct AssertionResultD.1962 gtest_arD.2071;

  boolD.1899 destructedD.2070;

  struct RCTesterD.2017 * obj.3D.2179;



  # .MEM_2 = VDEF <.MEM_1(D)>

  destructedD.2070 = 0;

  # VUSE <.MEM_2>

  # PT = nonlocal escaped 

  obj.3_3 = objD.2067;

  # .MEM_8 = VDEF <.MEM_2>

  MEM[(boolD.1899 * *)obj.3_3 + 8B] = &destructedD.2070;



ipa-cp mistakenly thinks that the move statement

 obj.3_3 = objD.2067;



actually loads from offset 0 of objD.2067 and hence propagates &MEM[(voidD.45

*)&_ZTVN12_GLOBAL__N_18RCTesterED.2049 + 16B] into obj.3_3 which then

subsequently gets propagated to the store of &destructedD.2070. 



The following patch fixes this, but not sure if this could be too restrictive:

Index: gcc/ipa-prop.c

===

--- gcc/ipa-prop.c(revision 197495)

+++ gcc/ipa-prop.c(working copy)

@@ -3892,7 +3892,7 @@ ipcp_transform_function (struct cgraph_node *node)

   {

 struct ipa_agg_replacement_value *v;

 gimple stmt = gsi_stmt (gsi);

-tree rhs, val, t;

+tree rhs, lhs, val, t;

 HOST_WIDE_INT offset;

 int index;

 bool by_ref, vce;

@@ -3900,6 +3900,7 @@ ipcp_transform_function (struct cgraph_node *node)

 if (!gimple_assign_load_p (stmt))

   continue;

 rhs = gimple_assign_rhs1 (stmt);

+lhs = gimple_assign_lhs (stmt);

 if (!is_gimple_reg_type (TREE_TYPE (rhs)))

   continue;



@@ -3924,7 +3925,8 @@ ipcp_transform_function (struct cgraph_node *node)

   continue;

 for (v = aggval; v; v = v->next)

   if (v->index == index

-  && v->offset == offset)

+  && v->offset == offset

+  && TREE_TYPE (v->value) == TREE_TYPE (lhs))

 break;

 if (!v)

   continue;

[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

[mrs at gcc dot gnu.org]

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



--- Comment #19 from mrs at gcc dot gnu.org  2013-04-17 
16:21:39 UTC ---

I've sent a message to the gcc-patches list with a pointer to the gcc-patches

list for the work.

[Bug fortran/56814] [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure

[janus at gcc dot gnu.org]

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



--- Comment #7 from janus at gcc dot gnu.org 2013-04-17 16:15:06 UTC ---

Fixed on trunk with:





Author: janus

Date: Wed Apr 17 16:13:07 2013

New Revision: 198032



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

Log:

2013-04-17  Janus Weil  



PR fortran/56814

* interface.c (check_result_characteristics): Get result from interface

if present.





2013-04-17  Janus Weil  



PR fortran/56814

* gfortran.dg/proc_ptr_42.f90: New.



Added:

trunk/gcc/testsuite/gfortran.dg/proc_ptr_42.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/interface.c

trunk/gcc/testsuite/ChangeLog







Will backport to 4.8 soon.

[Bug tree-optimization/56718] Early inlining prevents type based devirtualization

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2013-04/msg01034.htm

   ||l



--- Comment #1 from Martin Jambor  2013-04-17 
16:03:01 UTC ---

I have submitted a patch to address this issue:



http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01034.html

[Bug middle-end/42371] dead code not eliminated during folding with whole-program

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2013-04/msg01032.htm

   ||l

 CC||jamborm at gcc dot gnu.org



--- Comment #16 from Martin Jambor  2013-04-17 
15:58:17 UTC ---

I have submitted a patch to address this issue:



http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01032.html

[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

[mrs at gcc dot gnu.org]

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



m...@gcc.gnu.org  changed:



   What|Removed |Added



  Known to work||4.7.4



--- Comment #18 from mrs at gcc dot gnu.org  2013-04-17 
15:55:25 UTC ---

Fixed the ChangeLog, thanks for spotting it.

[Bug middle-end/10474] shrink wrapping for functions

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



 CC||jamborm at gcc dot gnu.org

  Component|tree-optimization   |middle-end



--- Comment #11 from Martin Jambor  2013-04-17 
15:52:44 UTC ---

I've submitted a patch that actually makes shrink wrapping happen, at

least on x86_64.  It would be great if someone checked whether it

helps on other platforms:



http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01033.html



(I'm also changing the component to to middle end as this is hardly a

tree-optimization matter.)

[Bug translation/56987] New: gcc/config/avr/avr.opt:80: "change" -> "changed"?

[stigge at antcom dot de]

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



 Bug #: 56987

   Summary: gcc/config/avr/avr.opt:80: "change" -> "changed"?

Classification: Unclassified

   Product: gcc

   Version: 4.8.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: translation

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

ReportedBy: sti...@antcom.de





Translatable string:



gcc/config/avr/avr.opt:80:

"Warn if the address space of an address is change." -> "changed"?

[Bug translation/56986] New: config/epiphany/epiphany.opt:108: "floatig"

[stigge at antcom dot de]

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



 Bug #: 56986

   Summary: config/epiphany/epiphany.opt:108: "floatig"

Classification: Unclassified

   Product: gcc

   Version: 4.8.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: translation

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

ReportedBy: sti...@antcom.de





Translatable string:



config/epiphany/epiphany.opt:108: "floatig" -> "floating"?

[Bug c/35649] Incorrect printf warning: expect double has float

[trevmrgn+bug at gmail dot com]

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



Trevor Morgan  changed:



   What|Removed |Added



 Target|h8300-elf   |h8300-elf, rx-elf, avr



--- Comment #12 from Trevor Morgan  2013-04-17 
15:22:48 UTC ---

printf( "%f", 2.0D );

will also produce the erroneous warning (tried on rx-elf)

[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well

[burnus at gcc dot gnu.org]

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



--- Comment #5 from Tobias Burnus  2013-04-17 
14:50:16 UTC ---

(In reply to comment #4)

> The reason why gfortran is slow here is that for non-regular files we use

> unbuffered I/O. If you write to a regular file instead of /dev/null, you'll 

> see us doing ~8 KB writes at a time.

> 

> The reason for this is that non-regular files (a.k.a. special files) are

> special in many ways wrt seeking. Some allow seeking just fine, some always

> return 0, some return an error (and which special files behave in which way is

> to some extent different on different OS'es).



I do not understand the argument regarding seek. If seek doesn't work - why

should there be a problem with buffering but not without? At least with

SEQUENTIAL one cannot do without (buffer exceeded or no buffering) and with

STREAM no seek should be required.



> Also, for special files users often expect non-buffered IO, e.g. they want

> output on the terminal directly instead of waiting until the 8 KB buffer fills

> up, programs communicating via pipes can deadlock if data sits in the buffers,

> etc.



But the code should be able to wait until a complete record has been written?

That should be rather quick, unless one write a 2GB array. I am not talking

about flushing the data only when 8kB are filled or when the file is closed.

And doing buffering within a record avoids seeks.



> One could of course make "unbuffered" I/O in gfortran really mean "flush

> the buffer at the end of each I/O statement" rather than not using a buffer at

> all.



We should consider this.



 * * *



I have now updated timings with writing to a file.



Results for the example in comment 0, but writing to a file ("test.dat",

tmpfs). Unformatted is much faster with a normal file, but some others

compilers are still significantly faster. And for formatted, all other

compilers are significantly faster.



 Timing in sec 

Unformatted  Formatted

real / user  real / user  Compiler

---  ---  -

0.378/0.352  2.815/2.804  GCC 4.8.0 (-Ofast, 20130308, Rev. 196547)

0.307/0.296  1.303/1.288  g95 4.0.3 (g95 0.93!) Aug 17 2010 (-O3)

0.210/0.196  0.555/0.532  Sun Fortran 95 8.3 Linux_i386 2007/05/03

0.208/0.184  0.920/0.888  PathScale 3.2.99

0.176/0.152  2.185/2.168  NAGWare Fortran 5.1

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

0.127/0.125  1.091/1.080  GCC 4.9 (trunk, -Ofast)

0.120/0.118  0.465/0.459  g95 4.0.3 (g95 0.94!) Dec 17 2012

0.136/0.131  0.527/0.524  PathScale EKOPath 4.9.0

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

0.335/0.316  2.866/2.860  GCC 4.7.2 20120920 (Cray Inc.)

0.204/0.188  0.659/0.628  Cray Fortran : Version 8.1.6

0.881/0.328  1.281/0.672  Intel 64, Version 13.1.1.163

0.444/0.432  0.884/0.864  pgf90 12.10-0

---

[Bug c++/55149] capturing VLA in lambda

[paolo.carlini at oracle dot com]

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



--- Comment #5 from Paolo Carlini  2013-04-17 
14:19:07 UTC ---

Likewise capturing VLAs is covered in N3639 (only capture by reference allowed)

[Bug c++/54320] [c++11] range access to VLA

[paolo.carlini at oracle dot com]

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



--- Comment #9 from Paolo Carlini  2013-04-17 
14:16:40 UTC ---

Sorry, the most recent paper in the series is actually N3639.

[Bug c++/54320] [c++11] range access to VLA

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-17

 Ever Confirmed|0   |1



--- Comment #8 from Paolo Carlini  2013-04-17 
14:11:54 UTC ---

This is now covered (allowed) in N3497.

[Bug fortran/40958] module files too large

[burnus at gcc dot gnu.org]

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



--- Comment #10 from Tobias Burnus  2013-04-17 
13:50:58 UTC ---

Author: jb

Date: Wed Apr 17 10:19:40 2013

New Revision: 198023



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

Log:

PR 40958 Compress module files with zlib.



frontend ChangeLog:



2013-04-17  Janne Blomqvist  



PR fortran/40958

* scanner.h: New file.

* Make-lang.in: Dependencies on scanner.h.

* scanner.c (gfc_directorylist): Move to scanner.h.

* module.c: Don't include md5.h, include scanner.h and zlib.h.

(MOD_VERSION): Add comment about backwards compatibility.

(module_fp): Change type to gzFile.

(ctx): Remove.

(gzopen_included_file_1): New function.

(gzopen_included_file): New function.

(gzopen_intrinsic_module): New function.

(write_char): Use gzputc.

(read_crc32_from_module_file): New function.

(read_md5_from_module_file): Remove.

(gfc_dump_module): Use gz* functions instead of stdio, check gzip

crc32 instead of md5.

(read_module_to_tmpbuf): Use gz* functions instead of stdio.

(gfc_use_module): Use gz* functions.



testsuite ChangeLog:



2013-04-17  Janne Blomqvist  



PR fortran/40958

* lib/gcc-dg.exp (scan-module): Uncompress module file before

scanning.

* gfortran.dg/module_md5_1.f90: Remove.



Added:

trunk/gcc/fortran/scanner.h

Removed:

trunk/gcc/testsuite/gfortran.dg/module_md5_1.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/Make-lang.in

trunk/gcc/fortran/module.c

trunk/gcc/fortran/scanner.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/lib/gcc-dg.exp

[Bug fortran/40958] module files too large

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #9 from Tobias Burnus  2013-04-17 
13:50:31 UTC ---

Author: jb

Date: Tue Mar 26 22:08:17 2013

New Revision: 197124



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

Log:

PR 25708 Use a temporary buffer when parsing module files.



2013-03-27  Janne Blomqvist  



PR fortran/25708

* module.c (module_locus): Use long for position.

(module_content): New variable.

(module_pos): Likewise.

(prev_character): Remove.

(bad_module): Free data instead of closing mod file.

(set_module_locus): Use module_pos.

(get_module_locus): Likewise.

(module_char): use buffer rather than stdio file.

(module_unget_char): Likewise.

(read_module_to_tmpbuf): New function.

(gfc_use_module): Call read_module_to_tmpbuf.



Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/module.c

[Bug web/45688] Typo in __attribute__((version-id)) docs

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  2013-04-17 
13:30:35 UTC ---
Actually, the bug was "version level functioning". Since it is obvious, I fixed
it.

http://gcc.gnu.org/r198028

[Bug target/56948] PPC V2DI ICE when loading zero into GPRs

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #2 from David Edelsohn  2013-04-17 13:27:24 
UTC ---

Patch applied to trunk and GCC 4.8 branch.

[Bug web/45688] Typo in __attribute__((version-id)) docs

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||FIXED

--- Comment #3 from Manuel López-Ibáñez  2013-04-17 
13:04:42 UTC ---
So FIXED. Thanks!

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[vincent-gcc at vinc17 dot net]

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

--- Comment #24 from Vincent Lefèvre  2013-04-17 
12:34:40 UTC ---
BTW, since with the latest GCC versions (such as Debian's GCC 4.7.2), the
warning is no longer issued with -Wno-maybe-uninitialized, perhaps the bug
severity could be lowered to "enhancement".

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[vincent-gcc at vinc17 dot net]

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

--- Comment #23 from Vincent Lefèvre  2013-04-17 
12:24:56 UTC ---
(In reply to comment #21)
> When an unrecognized warning option is requested (e.g., -Wunknown-warning), 
> GCC
> will emit a diagnostic stating that the option is not recognized.  However, if
> the -Wno- form is used, the behavior is slightly different: No diagnostic will
> be
> produced for -Wno-unknown-warning unless other diagnostics are being 
> produced. 

That was mainly for pre-4.7 GCC versions, where without the i=i idiom, one
would get the usual "may be used uninitialized in this function" warning
because -Wno-maybe-uninitialized is not supported, but also the

  unrecognized command line option "-Wno-maybe-uninitialized"

warning because there was already a warning. However this may not really be
important.

[Bug rtl-optimization/56921] [4.9 Regression] ICE in rtx_cost called by doloop_optimize_loops for PPC

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #15 from Richard Biener  2013-04-17 
12:02:05 UTC ---

Author: rguenth

Date: Wed Apr 17 12:01:46 2013

New Revision: 198025



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

Log:

2013-04-17  Richard Biener  



PR rtl-optimization/56921

* cfgloop.h (struct loop): Add simple_loop_desc member.

(struct niter_desc): Mark with GTY(()).

(simple_loop_desc): Do not use aux field but simple_loop_desc.

* loop-iv.c (get_simple_loop_desc): Likewise.

(free_simple_loop_desc): Likewise.



Revert

2013-04-16  Richard Biener  



PR rtl-optimization/56921

* loop-init.c (pass_rtl_move_loop_invariants): Add

TODO_do_not_ggc_collect to todo_flags_finish.

(pass_rtl_unswitch): Same.

(pass_rtl_unroll_and_peel_loops): Same.

(pass_rtl_doloop): Same.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/cfgloop.h

trunk/gcc/loop-init.c

trunk/gcc/loop-iv.c

[Bug fortran/56814] [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure

[janus at gcc dot gnu.org]

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



--- Comment #6 from janus at gcc dot gnu.org 2013-04-17 11:41:21 UTC ---

(In reply to comment #5)

> Alternative patch:



In contrast to the patch in comment #3, this one regtests cleanly ...

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu.org]

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

--- Comment #22 from Manuel López-Ibáñez  2013-04-17 
11:31:29 UTC ---
(In reply to comment #20)
> (In reply to comment #18)
> > In fact, we should have removed the i=i idiom a long time ago. The correct
> > thing to do (as Linus says) is to initialize the variable to a sensible 
> > value
> > to silence the warning: http://lwn.net/Articles/529954/
> 
> There is no real sensible value except some trap value. Letting the variable
> uninitialized at that point (the declaration) allows some tools, like the
> Formalin compiler described in WG14/N1637, to detect potential problems if the
> variable is really used uninitialized.

That doesn't contradict my assessment above that i=i idiom should die. With the
Pragma one can choose to ignore GCC warnings if they don't want to initialize
the value.

The trap value would be an additional improvement, but someone needs to
implement it. Clang has fsanitize=undefined-trap:

http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu.org]

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

--- Comment #21 from Manuel López-Ibáñez  2013-04-17 
11:26:01 UTC ---
(In reply to comment #20)
> OK, so a solution would be to add a configure test for projects that don't 
> want
> such warnings (while still using -Wall) to see whether 
> -Wno-maybe-uninitialized
> is supported.

When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC
will emit a diagnostic stating that the option is not recognized.  However, if
the -Wno- form is used, the behavior is slightly different: No diagnostic will
be
produced for -Wno-unknown-warning unless other diagnostics are being produced. 
This allows the use of new -Wno- options with old compilers, but if something
goes wrong, the compiler will warn that an unrecognized option was used.

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[vincent-gcc at vinc17 dot net]

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

--- Comment #20 from Vincent Lefèvre  2013-04-17 
11:17:14 UTC ---
(In reply to comment #18)
> In fact, we should have removed the i=i idiom a long time ago. The correct
> thing to do (as Linus says) is to initialize the variable to a sensible value
> to silence the warning: http://lwn.net/Articles/529954/

There is no real sensible value except some trap value. Letting the variable
uninitialized at that point (the declaration) allows some tools, like the
Formalin compiler described in WG14/N1637, to detect potential problems if the
variable is really used uninitialized.

(In reply to comment #19)
> Note that -Wmaybe-uninitialized is available since at least GCC 4.8.0

OK, so a solution would be to add a configure test for projects that don't want
such warnings (while still using -Wall) to see whether -Wno-maybe-uninitialized
is supported.

[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well

[jb at gcc dot gnu.org]

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



--- Comment #4 from Janne Blomqvist  2013-04-17 10:50:07 
UTC ---

The reason why gfortran is slow here is that for non-regular files we use

unbuffered I/O. If you write to a regular file instead of /dev/null, you'll see

us doing ~8 KB writes at a time. On my system, timing writing to /dev/null

gives



real0m0.727s

user0m0.272s

sys 0m0.452s



whereas writing to a file gives



real0m0.202s

user0m0.180s

sys 0m0.020s





The reason for this is that non-regular files (a.k.a. special files) are

special in many ways wrt seeking. Some allow seeking just fine, some always

return 0, some return an error (and which special files behave in which way is

to some extent different on different OS'es). As the buffered IO keeps track of

the logical file pointer position, it can easily get out of sync with the

physical position if it doesn't behave as for a regular file.



Also, for special files users often expect non-buffered IO, e.g. they want

output on the terminal directly instead of waiting until the 8 KB buffer fills

up, programs communicating via pipes can deadlock if data sits in the buffers,

etc. One could of course make "unbuffered" I/O in gfortran really mean "flush

the buffer at the end of each I/O statement" rather than not using a buffer at

all and instead using the raw POSIX I/O syscalls. This would perhaps not be a

bad idea per se, but would require making the buffered I/O code handle special

files in some sensible way.



Another reason for gfortran slowness is that we do quite a lot of checking in

data_transfer_init(), which means that there's quite a lot of per-record

overhead. Writing a single element unformatted is thus the worst case. One way

to speed up data_transfer_init, I think, is that instead of checking each flag

bit (which says which I/O specifiers are present) separately, create a variable

with forbidden flags for each I/O type (unformatted/formatted,

sequential/direct/stream => 6x), and check the entire flag variable once (flag

& forbidden_flags == 0). Only if there is an error, do the bit-by-bit checking

in order to generate the error message.

[Bug web/45688] Typo in __attribute__((version-id)) docs

[skannan at redhat dot com]

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



Shakthi Kannan  changed:



   What|Removed |Added



 CC||skannan at redhat dot com



--- Comment #2 from Shakthi Kannan  2013-04-17 
10:36:30 UTC ---

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes



now mentions version_id correctly:



  extern int foo () __attribute__((version_id ("20040821")));

[Bug web/45655] GCC WIki Needs Text Colorizing Capability

[skannan at redhat dot com]

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



Shakthi Kannan  changed:



   What|Removed |Added



 CC||skannan at redhat dot com



--- Comment #1 from Shakthi Kannan  2013-04-17 
10:06:03 UTC ---

I tested with the following:



<>



<>



<>



<>



<>



at:



  http://gcc.gnu.org/wiki/WikiSandBox



and can confirm that text colorizing macro isn't working on the GCC Wiki.

[Bug translation/56985] New: gcc/fortran/resolve.c:920: "'%s' in cannot appear in COMMON ..."

[stigge at antcom dot de]

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



 Bug #: 56985

   Summary: gcc/fortran/resolve.c:920: "'%s' in cannot appear in

COMMON ..."

Classification: Unclassified

   Product: gcc

   Version: 4.8.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: translation

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

ReportedBy: sti...@antcom.de





In gcc/fortran/resolve.c:920: "'%s' in cannot appear in COMMON ..."



-> I guess the "in" is not intended?

[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()

[rguenth at gcc dot gnu.org]

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



--- Comment #9 from Richard Biener  2013-04-17 
09:57:52 UTC ---

Created attachment 29889

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

patch



Untested patch.  The patch handles setjmp similar to a non-local label,

thus force it to start a new basic-block and get abnormal edges from all

sites that can make a non-local goto or call longjmp.



Fixes the testcase for me.  Somewhat reduced:



#include 

#include 

#include 



static sigjmp_buf env;



static inline int g(int x)

{

if (x)

{

fprintf(stderr, "Returning 0\n");

return 0;

}

else

{

fprintf(stderr, "Returning 1\n");

return 1;

}

}



int f(int *e)

{

if (*e)

  return 1;



int x = setjmp(env);

int n = g(x);

if (n == 0)

  exit(0);

if (x)

  abort();

longjmp(env, 42);

}



int main(int argc, char** argv)

{

int v = 0;

return f(&v);

}



but I cannot remove the remaining printfs, so it's not appropriate for the

testsuite yet.

[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well

[burnus at gcc dot gnu.org]

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



--- Comment #3 from Tobias Burnus  2013-04-17 
09:39:58 UTC ---

(In reply to comment #2)

> There is a seek inside next_record_w_unf. That function is used for DIRECT 
> I/O.

> Looks conceptually wrong to me for sequential unformatted.  I won't have time

> for a few days to look at this further.



Well, what gfortran does is:



* write place-holder record length in the heading record marker

* write actual data

* write tailing record marker (1st call to write_us_marker in

next_record_w_unf)

* write actual length of this record, i.e. seek back + write_us_marker + see to

past the tailing record marker (all in next_record_w_unf)





I think what other compilers do is to make use of the following item in the

Fortran standard:



"The value of the RECL= specifier shall be positive. It specifies the length of

each record in a file being connected for direct access, or specifies the

maximum length of a record in a file being connected for sequential access."

(F2008, "9.5.6.15 RECL= specifier in the OPEN statement")





I tried the following program:

---

integer, allocatable :: array(:)

integer :: rl, i

open(99,file="/dev/null",form="unformatted")

inquire(99,recl=rl)

allocate(array(1024*1024*100))

array = 0

print *,rl, size(array)/4

write(99) (array, i=1,1000)

close(99)

end

---



With gfortran, it takes only: 0.203s and one has:

 19 mmap

 26 open

392 lseek

   1784 write



The question is why there are that many seeks. There should be only a single

record!





With pathf95, it fails after 0.099s with the error:

 "This request exceeds the maximum record size."



And with g95, it takes 4.946s (!) until it fails with "Writing more data than

the record size (RECL)":

 11 close

 17 fstat

 20 mprotect

 21 stat

 25 mmap

 30 write

 47 open

where the mmap+munmap pairs seem to take the lion share of the time.





However, one can do better: NAG f95 only needs 0.007s and does:

  5 read

  6 lseek

  8 mprotect

 10 fstat

 23 stat

 29 mmap

 40 open

   2003 write





Maybe something like the following would work:

* Create a reasonable sized buffer

* Use it to buffer the writes, and if it fits, write the length, the buffer,

the length.

* If the argument is a (too) big array, write the length of data in the buffer

plus array byte size, then the data - and only if another item comes, seek to

the beginning and update the length.



That should take care of:

  write(99) i, j, k

  write(99) i, j, k, small_array

  write(99) big_array

and even

  write(99) i, j, k, big_array

but it will not help for

  write(99) big_array1, big_array2



I think that covers the most important cases. One question is how large the

buffer should be initially, whether it should be resizable - and how long it

should remain allocated. Even a small buffer of 1024 kbyte (= 128 real(8)

values) will help when writing small data like in the example of comment 0.



If it is larger, the issue of freeing the data and/or resizing becomes more

important - and one needs to be careful not to require huge amount of memory

and/or do do very frequent memory allocation+freeing, which causes the problems

with g95.



 * * *



Closer look at NAG: It does the following (allocate moved before open, inquire

removed):



open("/dev/null", O_RDWR)   = 3

mmap(NULL, 3856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =

0x2ab0e000

mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =

0x2ab22000

fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0

ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,

0x7fff645b1c90) = -1 ENOTTY (Inappropriate ioctl for device)

fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0

ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,

0x7fff645b2200) = -1 ENOTTY (Inappropriate ioctl for device)

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =

0x2ac22000

lseek(3, 0, SEEK_CUR)   = 0



write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,

4096) = 4096

write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,

419426304) = 419426304



(and 999 further write lines)



lseek(3, 0, SEEK_SET)   = 0

read(3, "", 4096)   = 0

lseek(3, 12, SEEK_CUR)  = 0

write(3, "\0\0\0\250", 4)   = 4

lseek(3, 18446744072233156608, SEEK_SET) = 0

read(3, "", 4096)   = 0

lseek(3, 20, SEEK_CUR)  = 0

lseek(3, 0, SEEK_CUR)   = 0

ftruncate(3, 0) = -1 EINVAL (Invalid argument)

close(3)= 0

munmap(0x2ac22000, 4096)= 0

munmap(0x

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu.org]

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

--- Comment #19 from Manuel López-Ibáñez  2013-04-17 
09:37:24 UTC ---
(In reply to comment #2)

> 1. Split the -Wuninitialized into two different warnings: one for which gcc
> knows that the variable is uninitialized and one for which it cannot decide.
> -Wuninitialized currently does both.

Note that -Wmaybe-uninitialized is available since at least GCC 4.8.0

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu.org]

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

--- Comment #18 from Manuel López-Ibáñez  2013-04-17 
09:31:59 UTC ---
In fact, we should have removed the i=i idiom a long time ago. The correct
thing to do (as Linus says) is to initialize the variable to a sensible value
to silence the warning: http://lwn.net/Articles/529954/

If GCC is smart enough to remove the initialization, then there is no harm. If
GCC is not smart enough, then the code is probably complex enough that GCC
cannot optimize it properly and this is why it gives a false positive, so the
fake initialization is the least of your worries.

[Bug web/44269] Search for PR number in mailing lists fails

[skannan at redhat dot com]

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



Shakthi Kannan  changed:



   What|Removed |Added



 CC||skannan at redhat dot com



--- Comment #2 from Shakthi Kannan  2013-04-17 
09:31:28 UTC ---

Searching for 18249 in the web archive of the gcc-patches mailing list with

mnoGoSearch 3.3.13 does return the link to PR 18249.



http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01458.html

[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()

[jakub at gcc dot gnu.org]

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



--- Comment #8 from Jakub Jelinek  2013-04-17 
09:28:55 UTC ---

#include 

#include 



static sigjmp_buf env;

static inline int g (int x)

{

  if (x)

{   

  fprintf (stderr, "Returning 0\n");

  return 0;

}

  else

{ 

  fprintf (stderr, "Returning 1\n");

  return 1;

}

}

__attribute__ ((noinline))

void bar (int n)

{

  if (n == 0)

exit (0);

  static int x;

  if (x++) abort ();

  longjmp (env, 42);

}

int

f (int *e)

{

  int n = *e;

  if (n)

return 1;

  int x = setjmp (env);

  n = g (x);

  fprintf (stderr, "x = %i, n = %i\n", x, n);

  bar (n);

}

int

main () 

{

  int v = 0;

  return f (&v);

}



Adjusted testcase that fails even with GCC 4.7.2 at -O2, works with -O2

-fno-dominator-opts (which disables uncprop).  Again, I don't see how

this could be declared invalid, while n is declared before the setjmp, it is

not live across the setjmp call.  This adjusted testcase regressed in April

2005 (i.e. 4.1+ regression).

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #17 from Manuel López-Ibáñez  2013-04-17 
09:19:09 UTC ---
(In reply to comment #16)
> (In reply to comment #3)
> > A way to tell gcc a variable is not uninitialized is to perform
> > self-initialization like
> > 
> >  int i = i;
> > 
> > this will cause no code generation but inhibits the warning.  Other 
> > compilers
> > may warn about this construct of course.

> The only good solution would be to fix the bug. I've checked that it is still
> there in the trunk revision 197260 (current Debian's gcc-snapshot).

If you mean to fix the false warning, then you are likely to wait a long long
time (in order of years) because it doesn't seem a trivial thing to fix and
there are very very few people with enough GCC knowledge to fix it (and they
are busy with other things).

What would be trivial to fix (but require persistence, patience and time) is to
implement this idea:

http://gcc.gnu.org/ml/gcc/2010-08/msg00297.html

that is, either  __attribute__ ((initialized))

or _Pragma("GCC diagnostic ignored \"-Wuninitialized\"").

(Personally, I prefer the latter, since it reuses existing code).

Add as a follow-up, get rid of the non-portable valgrind-unfriendly i=i idiom
that has caused so much grief over the years.

However, we still need someone with the persistence, patience and time to
implement this and get it past the powers that be.

[Bug bootstrap/56644] --disable-nls requires symbols from libintl

[meisenmann....@fh-salzburg.ac.at]

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



--- Comment #7 from Markus Eisenmann  
2013-04-17 09:17:36 UTC ---

At least this error is based on some libintl-macros, which will "redirect" some

stdio-functions (like vsnprintf ...) to their libintl-version(s); I.e. the

header-file libintl.h is available and included, but NLS/libintl isn't

requested.



Solution (as be possible by processing the attached patch/diff-file):



Add following undef's in the #else-region of gcc/intl.h (of #ifdef ENABLE_NLS),

for example after line #54:



#undeffprintf

#undefvfprintf

#undefprintf

#undefvprintf

#undefsprintf

#undefvsprintf

#undefsnprintf

#undefvsnprintf

#undefasprintf

#undefvasprintf

#undefsetlocale



Additional comment:

The header-file gcc/intl.h does already contain undef's to prevent using

libintl if not requested or configured. But not for the affected "stdio-funcs"

as vsnprintf [...], which may cause linker-errors (I.e. unresolved externals).

[Bug ada/40986] [4.6 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27

[markus.schoepflin at comsoft dot de]

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

--- Comment #15 from Markus Schöpflin  
2013-04-17 09:15:22 UTC ---
I have bisected the problem using the git gcc repository, unfortunately 121
commits are left after bisecting, as in between the last known good and the
first known bad commit the gcc tree does not compile for a lot of commits.

Anyway, this is the last known good commit:

commit 244de65defd519a1245551886fce58113a4b7b2a
Author: charlet 
Date:   Wed Jun 6 10:13:25 2007 +

This is the first known bad commit:

commit 7b29e7de1cf940343eeeb25058b7870877d15524
Author: charlet 
Date:   Wed Jun 6 10:54:04 2007 +

The 120 commits in between do not compile, and all do massive changes in the
Ada part of gcc.

[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()

[rguenther at suse dot de]

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



--- Comment #7 from rguenther at suse dot de  
2013-04-17 09:07:10 UTC ---

On Wed, 17 Apr 2013, jakub at gcc dot gnu.org wrote:



> 

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

> 

> --- Comment #6 from Jakub Jelinek  2013-04-17 
> 08:56:00 UTC ---

> I don't see how we could declare the testcase invalid, why would n need to be

> volatile?  It isn't live across the setjmp call, it is even declared after the

> setjmp call, and it is always initialized after the setjmp call.



Then there is no other way but to model the abnormal control flow

properly.  Even simple CSE can break things otherwise.  Consider



int tmp = a + 1;

setjmp ()

int tmp2 = a + 1;



even on RTL CSE would break that, no?  setjmp doesn't even

forcefully start a new basic-block.



Hmm, maybe doing that, start a new BB for all returns-twice

calls and add an abnormal edge from FN entry is enough to

avoid all possibly dangerous transforms.



Richard.

[Bug bootstrap/56644] --disable-nls requires symbols from libintl

[meisenmann....@fh-salzburg.ac.at]

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



--- Comment #6 from Markus Eisenmann  
2013-04-17 09:01:04 UTC ---

Created attachment 29888

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

Prevent redirect to some libintl-functions if NLS isn't requested



This Patch will undefine some macros which would cause unneed redirections to

libintl-functions (like vsnprintf); while NLS isn't configured (I.e. ENABLE_NLS

is not set).

[Bug fortran/56814] [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure

[janus at gcc dot gnu.org]

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



--- Comment #5 from janus at gcc dot gnu.org 2013-04-17 08:58:25 UTC ---

Alternative patch:



Index: gcc/fortran/interface.c

===

--- gcc/fortran/interface.c(revision 198007)

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

@@ -1184,9 +1184,20 @@ check_result_characteristics (gfc_symbol *s1, gfc_

 {

   gfc_symbol *r1, *r2;



-  r1 = s1->result ? s1->result : s1;

-  r2 = s2->result ? s2->result : s2;

+  if (s1->ts.interface && s1->ts.interface->result)

+r1 = s1->ts.interface->result;

+  else if (s1->result)

+r1 = s1->result;

+  else

+r1 = s1;



+  if (s2->ts.interface && s2->ts.interface->result)

+r2 = s2->ts.interface->result;

+  else if (s2->result)

+r2 = s2->result;

+  else

+r2 = s2;

+

   if (r1->ts.type == BT_UNKNOWN)

 return true;





Regtesting now ...

[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2013-04-17 
08:56:00 UTC ---

I don't see how we could declare the testcase invalid, why would n need to be

volatile?  It isn't live across the setjmp call, it is even declared after the

setjmp call, and it is always initialized after the setjmp call.

[Bug tree-optimization/50789] Gather vectorization

[rguenther at suse dot de]

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



--- Comment #12 from rguenther at suse dot de  
2013-04-17 08:53:21 UTC ---

On Wed, 17 Apr 2013, andrey.turetskiy at gmail dot com wrote:



> 

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

> 

> Andrey Turetskiy  changed:

> 

>What|Removed |Added

> 

>  CC||andrey.turetskiy at gmail

>||dot com

> 

> --- Comment #11 from Andrey Turetskiy  
> 2013-04-17 08:31:29 UTC ---

> It looks like gathers can be used for vectorization in cases like:

> 

> #define N 1024

> 

> float x[4*N], y[N];

> 

> void foo ()

> {

>   int i;

>   for (i = 0; i < N; i++)

> y[i] = x[179 + 3*i];

> }

> 

> Now this code isn't vectorized.

> In addition there are a lot of such exampes in SPECS 2006. Vectorization with

> gathers can give noticeable gain.



The above can be vectorized with the strided-load vectorization support

(just it doesn't trigger here).  And strided-load vectorization

code-generation can be imrpoved by using gather vectorization by

first building a vector of addresses / indices and then performing

a gather load.  If building a vector of addresses / indices is

cheaper than performing scalar loads and building a vector from

the results, that is.



So the above is more related to strided load support (and the

not yet implemented strided store support as well, if there

are also gather stores ...)



Richard.

[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-04-17 
08:48:33 UTC ---

So the questions are:

- is it desirable that uncprop does anything to SSA_NAME_VAR == NULL phis?



sure - it is all about improving out-of-SSA coalescing opportunities

and avoiding copies



- shouldn't something like that be not performed if current function calls

setjmp (or more narrowly, if there is a returns twice function somewhere in

between the considered setter and user)?



the testcase shows that uncprop extends the lifetime of an SSA name

across a setjmp call - but it can only do so because it's an SSA name.

Which means the testcase is questionable as 'n' is not declared volatile, no?



- what other optimizations might be similarly problematic across returns twice

calls?



every optimization pass that performs hosting.  PRE comes to my mind for



  if (x)

tem = expr;

  setjmp ()

  var = expr;



which would happily eliminate the partial redundancy, moving expr to the

else arm of the if () and thus extending the lifetime of 'var' across

the setjmp call.



We do not explicitely model the abnormal control flow for setjmp / longjmp

which is the reason all these issues may appear.  So I believe the

correct fix is to either declare the testcase invalid or to model

the abnormal control flow explicitely. Add abnormal edges from all

call sites in the function that may end up calling longjmp _and_ eventually an

abnormal edge from function entry as we can call longjmp from callers

as well (though that may be invalid and thus we do not have to care?).



I don't see an "easy" fix for the issue (well, maybe the specific testcase).

That it happens only after my patch is probably pure luck because of for

example the PRE issue.  Testcase for that:



int f (int a, int flag)

{

  int tem;

  if (flag)

tem = a + 1;

  int x = setjmp (env);

  int tem2 = a + 1;

  if (x)

return tem2;

  return tem;

}



validity of course is questionable, but we clearly use tem only on the

normal path and tem2 on the abnormal path.  PRE does the transform

I indicated, proper abnormal edges would disable the transform.

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[vincent-gcc at vinc17 dot net]

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

--- Comment #16 from Vincent Lefèvre  2013-04-17 
08:40:09 UTC ---
(In reply to comment #3)
> A way to tell gcc a variable is not uninitialized is to perform
> self-initialization like
> 
>  int i = i;
> 
> this will cause no code generation but inhibits the warning.  Other compilers
> may warn about this construct of course.

What makes things worse about this workaround is that even protecting this by a

#if defined(__GNUC__)

may not be sufficient as other compilers may claim GNUC compatibility and
behave differently. This is the case of clang (at least under Debian):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705583

The only good solution would be to fix the bug. I've checked that it is still
there in the trunk revision 197260 (current Debian's gcc-snapshot).

[Bug tree-optimization/50789] Gather vectorization

[andrey.turetskiy at gmail dot com]

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



Andrey Turetskiy  changed:



   What|Removed |Added



 CC||andrey.turetskiy at gmail

   ||dot com



--- Comment #11 from Andrey Turetskiy  
2013-04-17 08:31:29 UTC ---

It looks like gathers can be used for vectorization in cases like:



#define N 1024



float x[4*N], y[N];



void foo ()

{

  int i;

  for (i = 0; i < N; i++)

y[i] = x[179 + 3*i];

}



Now this code isn't vectorized.

In addition there are a lot of such exampes in SPECS 2006. Vectorization with

gathers can give noticeable gain.

[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |



--- Comment #4 from Richard Biener  2013-04-17 
08:26:20 UTC ---

I will have a look.

[Bug tree-optimization/56984] [4.8/4.9 Regression] ICE in tree_vrp.c

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org

   |gnu.org |



--- Comment #2 from Jakub Jelinek  2013-04-17 
07:30:20 UTC ---

Created attachment 29887

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

gcc49-pr56984.patch



Untested fix.  Another thing is that fold resp. gimple_fold aren't able to

optimize (x >> N) < M into 0 if M << N is the minimum value, but that isn't

something VRP should handle.

[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 CC||ebotcazou at gcc dot

   ||gnu.org



--- Comment #17 from Eric Botcazou  2013-04-17 
07:17:18 UTC ---

The patch was silently backported yesterday, but the wrong ChangeLog has been

modified.  Please post a message on gcc-patches@ and fix the ChangeLog.  TIA.