[Bug fortran/46100] [Fortran 2008] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Tobias Burnus  2010-10-21 
06:16:59 UTC ---
FIXED on the trunk (4.6).

[Bug fortran/46100] [Fortran 2008] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2010-10-21 
06:15:34 UTC ---
Author: burnus
Date: Thu Oct 21 06:15:30 2010
New Revision: 165749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165749
Log:
2010-10-21  Tobias Burnus  

PR fortran/46100
* expr.c (gfc_check_vardef_context): Treat pointer functions
as variables.

2010-10-21  Tobias Burnus  

PR fortran/46100
* gfortran.dg/ptr-func-1.f90: New.
* gfortran.dg/ptr-func-2.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/ptr-func-1.f90
trunk/gcc/testsuite/gfortran.dg/ptr-func-2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/46107] [4.6 Regression] -ftree-loop-distribute-patterns caused verify_loop_structure problem

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||yuri at tsoft dot com

--- Comment #78 from Andrew Pinski  2010-10-21 
05:42:47 UTC ---
*** Bug 46109 has been marked as a duplicate of this bug. ***

[Bug c++/46109] gcc-4.5.0 fails to build on

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2010-10-21 
05:42:47 UTC ---
Fixed in 4.5.1 see PR 43170.

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

[Bug c++/46103] [c++0x] moving from std::array copies the elements

[marc.glisse at normalesup dot org]

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

--- Comment #4 from marc.glisse at normalesup dot org 2010-10-21 05:36:58 UTC 
---
Adding an explicit A(A&&)=default; doesn't help, so I don't think this is
related to the implicit stuff. More like a missing piece of code telling the
compiler how to move from an array.

[Bug lto/46083] gcc.dg/initpri1.c FAILs with -flto/-fwhopr (attribute constructor/destructor doesn't work)

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  2010-10-21 05:32:00 UTC 
---
> Honza, maybe your constructor re-ordering doesn't honor priority?
It should via the same logic as non-ELF ctor/dtor code does, but I will double
check.

Honza

[Bug target/36503] x86 can use x >> -y for x >> 32-y

[astrange at ithinksw dot com]

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

--- Comment #8 from Alexander Strange  2010-10-21 
04:39:36 UTC ---
I built ffmpeg for x86-64 with --disable-asm with the attached patch and the
regression tests failed. Reverting the patch fixes them. I saved the binaries
but haven't investigated yet.

[Bug pch/46110] New: Precompiled headers: GCC fails to properly locate include files

[aleksey.covacevice at gmail dot com]

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

   Summary: Precompiled headers: GCC fails to properly locate
include files
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aleksey.covacev...@gmail.com


Created attachment 22102
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22102
Test case script

GCC fails to properly locate include files when using precompiled headers that
are located in a deeper directory in the search path. This problem happens when
a file "z.h" includes two other files, "x.h" and "y.h", such that "y.h" also
includes "x.h", and they are all located in another directory in the include
path (yielding include lines such as '#include "dir/x.h"').

The issue is much better explained through a test case. The following command
sequence is a simple test case that yields the symptom:

==
#!/bin/sh

mkdir -p include/dir pch/dir
touch include/dir/x.h
echo "#include \"dir/x.h\"" > include/dir/y.h
echo "#include \"dir/x.h\"" > include/dir/z.h
echo "#include \"dir/y.h\"" >> include/dir/z.h
gcc -I pch -I include include/dir/x.h -o pch/dir/x.h.gch
gcc -I pch -I include include/dir/y.h -o pch/dir/y.h.gch
gcc -I pch -I include include/dir/z.h -o pch/dir/z.h.gch
==

The output is the following:

==
In file included from include/dir/z.h:2:
include/dir/y.h:1:19: error: pch/dir/x.h: No such file or directory
==

If the include path "-I pch" is ommited from the above commands (i.e., removing
the precompiled headers from the search path), everything runs fine. Also, if
the subdirectory "dir/" is properly removed from every place above, everything
runs fine. Now, if the include path "-I include" is ommited, the output is:

==
include/dir/z.h:2:19: error: dir/y.h: No such file or directory
==

although the precompiled header "pch/dir/y.h.gch" already exists (there should
be no reason to avoid using it, "-Winvalid-pch" does not report anything and
the compilation for "y.h", which is pretty similar, proceeds fine).

The snippet above should also help generate proper ".i" files for further
investigation.

Running GCC on a Ubuntu 9.10 x86 host.

Output of gcc -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)

Cheers,
Alek

[Bug c++/46109] New: gcc-4.5.0 fails to build on

[yuri at tsoft dot com]

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

   Summary: gcc-4.5.0 fails to build on
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com


I tried to build gcc-4.5.0 exactly the same way that succeeds on LInux and
failed on Mac OS X.

Darwin MacBook.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53
PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386


--- build log ---
<...skipped...>
make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH"
"TARGET_SUBDIR=i386-apple-darwin10.4.0" "bindir=/usr/local/bin"
"datadir=/usr/local/share" "exec_prefix=/usr/local"
"includedir=/usr/local/include" "datarootdir=/usr/local/share"
"docdir=/usr/local/share/doc/" "infodir=/usr/local/share/info"
"pdfdir=/usr/local/share/doc/" "htmldir=/usr/local/share/doc/"
"libdir=/usr/local/lib" "libexecdir=/usr/local/libexec" "lispdir="
"localstatedir=/usr/local/var" "mandir=/usr/local/share/man"
"oldincludedir=/usr/include" "prefix=/usr/local" "sbindir=/usr/local/sbin"
"sharedstatedir=/usr/local/com" "sysconfdir=/usr/local/etc"
"tooldir=/usr/local/i386-apple-darwin10.4.0"
"build_tooldir=/usr/local/i386-apple-darwin10.4.0"
"target_alias=i386-apple-darwin10.4.0" "AWK=awk" "BISON=bison"
"CC_FOR_BUILD=gcc" "CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=g++"
"EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install -c"
"INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c"
"INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS_FOR_BUILD=" "LEX=flex" "M4=gm4"
"MAKE=make" "RUNTEST=runtest" "RUNTESTFLAGS=" "SED=/usr/bin/sed"
"SHELL=/bin/sh" "YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e
s'/[^=][^=]*=$/XFOO=/'`" "ADA_CFLAGS=" "AR_FLAGS=rc" "`echo
'BOOT_ADAFLAGS=-gnatpg -gnata' | sed -e s'/[^=][^=]*=$/XFOO=/'`"
"BOOT_CFLAGS=-g -O2 -fomit-frame-pointer" "BOOT_LDFLAGS=" "CFLAGS=-g -O2"
"CXXFLAGS=-g -O2" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2
-fno-implicit-templates" "STAGE1_CHECKING=--enable-checking=yes,types"
"STAGE1_LANGUAGES=c" "GNATBIND=no" "GNATMAKE=no" "AR_FOR_TARGET=ar"
"AS_FOR_TARGET=as" "CC_FOR_TARGET=/tmp/gcc-build/4.5.0/bld/./gcc/xgcc
-B/tmp/gcc-build/4.5.0/bld/./gcc/" "CFLAGS_FOR_TARGET=-g -O2"
"CPPFLAGS_FOR_TARGET=" "CXX_FOR_TARGET=/tmp/gcc-build/4.5.0/bld/./gcc/g++
-B/tmp/gcc-build/4.5.0/bld/./gcc/ -nostdinc++ 
-L/tmp/gcc-build/4.5.0/bld/i386-apple-darwin10.4.0/libstdc++-v3/src
-L/tmp/gcc-build/4.5.0/bld/i386-apple-darwin10.4.0/libstdc++-v3/src/.libs"
"CXXFLAGS_FOR_TARGET=-g -O2" "DLLTOOL_FOR_TARGET=dlltool"
"FLAGS_FOR_TARGET=-B/usr/local/i386-apple-darwin10.4.0/bin/
-B/usr/local/i386-apple-darwin10.4.0/lib/ -isystem
/usr/local/i386-apple-darwin10.4.0/include -isystem
/usr/local/i386-apple-darwin10.4.0/sys-include" "GCJ_FOR_TARGET="
"GFORTRAN_FOR_TARGET="
"LD_FOR_TARGET=/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld"
"LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" "LIBCFLAGS_FOR_TARGET=-g -O2"
"LIBCXXFLAGS_FOR_TARGET=-g -O2 -fno-implicit-templates" "NM_FOR_TARGET=nm"
"OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_TARGET=ranlib"
"STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres"
"WINDMC_FOR_TARGET=windmc" "BUILD_CONFIG=bootstrap-debug" "`echo 'LANGUAGES=' |
sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "STAGE1_CFLAGS=-g
-fkeep-inline-functions" "STAGE1_CXXFLAGS=-g -O2" "STAGE1_TFLAGS="
"STAGE2_CFLAGS=-g -O2 -fomit-frame-pointer -gtoggle" "STAGE2_CXXFLAGS=-g -O2"
"STAGE2_TFLAGS=" "STAGE3_CFLAGS=-g -O2 -fomit-frame-pointer"
"STAGE3_CXXFLAGS=-g -O2" "STAGE3_TFLAGS=" "STAGE4_CFLAGS=-g -O2
-fomit-frame-pointer" "STAGE4_CXXFLAGS=-g -O2" "STAGE4_TFLAGS="
"STAGEprofile_CFLAGS=-g -O2 -fomit-frame-pointer -gtoggle -fprofile-generate"
"STAGEprofile_CXXFLAGS=-g -O2" "STAGEprofile_TFLAGS=" "STAGEfeedback_CFLAGS=-g
-O2 -fomit-frame-pointer -fprofile-use" "STAGEfeedback_CXXFLAGS=-g -O2"
"STAGEfeedback_TFLAGS=" "TFLAGS=" "CONFIG_SHELL=/bin/sh" "MAKEINFO=makeinfo
--split-size=500 --split-size=500"  compare
rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
i386-apple-darwin10.4.0/libgomp/.libs/bar.o differs
i386-apple-darwin10.4.0/libgomp/.libs/barrier.o differs
i386-apple-darwin10.4.0/libgomp/.libs/env.o differs
i386-apple-darwin10.4.0/libgomp/.libs/iter.o differs
i386-apple-darwin10.4.0/libgomp/.libs/iter_ull.o differs
i386-apple-darwin10.4.0/libgomp/.libs/lock.o differs
i386-apple-darwin10.4.0/libgomp/.libs/loop.o differs
i386-apple-darwin10.4.0/libgomp/.libs/loop_ull.o differs
i386-apple-darwin10.4.0/libgomp/.libs/ordered.o differs
i386-apple-darwin10.4.0/libgomp/.libs/parallel.o differs
i386-apple-darwin10.4.0/libgomp/.libs/proc.o differs
i386-apple-darwin10.4.0/libgomp/.libs/sections.o differs
i386-apple-darwin10.4.0/libgomp/.libs/single.o differs
i386-apple-darwin10.4.0/libgomp/.libs/task.o differs
i386-apple-darwin10.4.0/libgomp/.libs/tea

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #8 from Jeffrey Walton  2010-10-21 
02:00:51 UTC ---
(In reply to comment #4)
> I had a look at Cryptopp-SO-Test-1.zip
> 
> 
> 
> I can see some value in the warning you want, but it's not going to help if 
> you
> don't use the compiler correctly (maybe I'm being unfair and you're using it
> correctly for 32-bit, but my first instinct is that if it fails to build for a
> different target then *something* is wrong!)

For completeness, while trying to avoid a pissing contest:

I agree the file should have been (and should be) correct wrt x64 (I should
have walked it over to an x64 machine and tried it). And I know my *nix skills
are rusty - its been over 10 years since I needed them. The last time I used
them was circa RedHat shipping a broken compiler, which I believe occurred at
RedHat 4.0 or 5.0 (back then, we usually had to rebuild our own kernel due to
poor network card support and drivers that were worse). 

Finally, the feature request and the underlying reason for the request are not
really related. Despite poor sample code on my part, I believe programmers and
package maintainers could benefit from the ability to have GCC issue warnings
during compilation, rather than using objdump or nm later to tease out the
information later.

Jeff

[Bug fortran/46079] [4.6 Regression] ABI for empty stop statement broken

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Jerry DeLisle  2010-10-21 
00:48:25 UTC ---
Fixed on trunk.

[Bug fortran/46079] [4.6 Regression] ABI for empty stop statement broken

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  2010-10-21 
00:45:19 UTC ---
Author: jvdelisle
Date: Thu Oct 21 00:45:15 2010
New Revision: 165746

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165746
Log:
2010-10-20  Jerry DeLisle  

PR libgfortran/46079
* runtime/stop.c (stop_numeric_f08): New function.
(stop_numeric): Restoreto previous behavior.
* gfortran.map: Add symbol _gfortran_stop_numeric_f08.

2010-10-20  Jerry DeLisle  

PR fortran/46079
* trans_stmt.c (gfc_trans_stop): Fix whitespace.  Build a call to new
F08 numeric stop function.
* trans.h: Add declaration for gfor_fndecl_stop_numeric_f08.
* trans-decl.c (gfc_build_builtin_function_decls): Build declaration
for stop_numeric_f08.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/libgfortran/ChangeLog
trunk/libgfortran/gfortran.map
trunk/libgfortran/runtime/stop.c

[Bug middle-end/46106] Error in Manpage? -fstack-protection => -fstack-protector(-all)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-10-20 
23:52:29 UTC ---
gcc.1 is generated from doc/invoke.texi.

[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  2010-10-20 
23:49:18 UTC ---
%.60f

You really should use hex float to see the diferences.  I bet it is just the
final digit of the hex float that is different and only by one.  This is
actually ok IIRC.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2010-10-20 
23:48:33 UTC ---
(In reply to comment #6)
> Hi Johnathon,
> (In reply to comment #5)
> > oh, and I only see one process invovled there ... I'm still confused about 
> > the
> > claim that more than one process is involved...
> My bad - the image only depicts one process. However, the first thing main()
> does is a fork to get two processes in play.

No fork() in the first zipfile I looked at (from [1] in comment 2), and unless
the globals use something inter-process such as semaphores or file locking,
there is no way they should interfere with globals in other processes. Using
RTLD_GLOBAL, exceptions or RTTI doesn't change the fact that processes have
their own memory space.


> Try crypto++ 5.6.0 (which _had_ global objects) located at
> http://www.cryptopp.com/cryptopp560.zip. Crypto 5.6.1 fixed the global object
> problem.
> The stress test which should trigger the issue (depicted in the image) is
> located at http://www.cryptopp.com/w/images/b/be/Cryptopp-SO-Test.zip.

Ah, I tried that stress test against 5.6.1 as that's what my distro provides.
That stress test *does* use fork, but didn't crash for me.   If I get time
tomorrow I'll try it against 5.6.0

I'm probably taking this enhancement request wy off-topic, I just want to
convince myself you're not wasting time asking for a warning that won't help
prevent user error

[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[vincent at vinc17 dot org]

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

--- Comment #7 from Vincent Lefèvre  2010-10-20 
23:43:33 UTC ---
But there's something strange in the generated code: sometimes the fsqrt
instruction is used, sometimes "call sqrtf" is used (for the same sqrtf() call
in the C source). This is not consistent.

[Bug c++/46108] constexpr ICE: streambuf_iterator.h:97

[bkoz at gcc dot gnu.org]

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

--- Comment #1 from Benjamin Kosnik  2010-10-20 
23:38:10 UTC ---
Created attachment 22101
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22101
pre-processed sources

[Bug c++/46108] New: constexpr ICE: streambuf_iterator.h:97

[bkoz at gcc dot gnu.org]

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

   Summary: constexpr ICE: streambuf_iterator.h:97
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@gcc.gnu.org


running into this ICE on the constexpr library.

CRN Free Subscription

[CRN Magazine]

Unparalleled channel insights. Management strategies you can implement now. 
Impeccable research. These are just a few of the topics highlighted in each 
issue of CRN magazine, the voice of the channel for over 20 years. As a channel 
professional, you are entitled to a FREE subscription today:  
http://crnnetwork.com/portal/wts/ccmceDmckkk6ecsxv6rv0C2erOzyk

With global coverage, CRN includes channel observations and examination as well 
as product analysis of the newest technologies. Well known research including 
the VAR500, State of the Market, and our State of Technology series also appear 
in CRN. 

As business and the workforce continue to change, each FREE issue of CRN will 
help you navigate the channel.

Subscribe free now:
http://crnnetwork.com/portal/wts/ccmceDmckkk6ecsxv6rv0C6erOzyk

Welcome to CRN magazine! 

###
Everything Channel - a UBM company
550 Cochituate Road - Framingham, MA 01701 
Please do not respond to this email.
Unsubscribe from Everything Channel CRN Magazine Subscription emails:
http://crnnetwork.com/portal/unsubscribeconfirm/?SS6dNtHASpX4xB5eZhQgSx1PRwKo1iHoA

[Bug c++/46103] [c++0x] moving from std::array copies the elements

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2010-10-20 
23:26:33 UTC ---
What if implicitly-defined move-constructors go away again? If I understand
correctly that the bits we are missing are part of the recent work on implicit
moves and the Committee ends up returning to something similar to what we had
before (I didn't follow the pre-meeting exchanges in detail, but seems well
possible, see n3153) maybe we don't have to do much here in GCC ;) Looks like
we should suspend this PR pending the resolution of those thorny issues...

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #6 from Jeffrey Walton  2010-10-20 
23:18:48 UTC ---
Hi Johnathon,

(In reply to comment #5)
> oh, and I only see one process invovled there ... I'm still confused about the
> claim that more than one process is involved...
My bad - the image only depicts one process. However, the first thing main()
does is a fork to get two processes in play.

> do you mean more than one thread?!
Multiple threads were an artifact of trying to reproduce the original issue (it
turned out to be Shared object, RTLD_GLOBAL, and multiple processes). But the
multiple threads made for a nice stress test ;)

==

Try crypto++ 5.6.0 (which _had_ global objects) located at
http://www.cryptopp.com/cryptopp560.zip. Crypto 5.6.1 fixed the global object
problem.
The stress test which should trigger the issue (depicted in the image) is
located at http://www.cryptopp.com/w/images/b/be/Cryptopp-SO-Test.zip.

==

Sorry about the poor Linux skills at times. I'm a Windows guy, and its
frustrating when I know what I want to say in terms of Windows, but not in
terms of Linux.

Jeff

[Bug c/46107] [4.6 Regression] -ftree-loop-distribute-patterns caused verify_loop_structure problem

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.20 23:05:14
 CC||hjl.tools at gmail dot com
Summary|verify_loop_structure   |[4.6 Regression]
   |problem |-ftree-loop-distribute-patt
   ||erns caused
   ||verify_loop_structure
   ||problem
 Ever Confirmed|0   |1

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2010-10-20 
22:47:59 UTC ---
oh, and I only see one process invovled there ... I'm still confused about the
claim that more than one process is involved - do you mean more than one
thread?!

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2010-10-20 
22:46:45 UTC ---
I had a look at Cryptopp-SO-Test-1.zip

building on 32-bit I can reproduce a segfault

it doesn't build on 64-bit at all:

1) you can insert a pointer into an ostream without casting to int (and if you
insist on casting, do it to a type that has the same size as a pointer!)

2) that makefile doesn't compile dsotest-1.o and dsotest-2.o with -fPIC

To get it build I had to edit the code and the makefile, and after doing so it
doesn't crash. And with the same changes, it doesn't crash on 32-bit either.

So are you sure this isn't just user error?

I can see some value in the warning you want, but it's not going to help if you
don't use the compiler correctly (maybe I'm being unfair and you're using it
correctly for 32-bit, but my first instinct is that if it fails to build for a
different target then *something* is wrong!)

[Bug debug/46101] [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.20 22:03:18
 CC||dseketel at redhat dot com,
   ||hjl.tools at gmail dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-10-20 22:03:18 
UTC ---
It is caused by revision 160347:

http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00260.html

[Bug c/46107] New: verify_loop_structure problem

[dcb314 at hotmail dot com]

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

   Summary: verify_loop_structure problem
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 22100
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22100
C source code

I just tried to compile package gambas2-2.21.0 with the latest 4.6
snapshot 20101016 on a Fedora Linux box. The compiler said

gbx_subr_math.c: In function 'SUBR_add_quick':
gbx_subr_math.c:295:6: error: edge from 7 to 9 should be marked irreducible
gbx_subr_math.c:295:6: internal compiler error: in verify_loop_structure, at
cfgloop.c:1562
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Source code attached. Flag -O3 required.

[Bug c++/36694] g++-4.2 rejects code, that other versions of gcc accept

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.10.20 21:55:26
 Ever Confirmed|0   |1

--- Comment #4 from Jonathan Wakely  2010-10-20 
21:55:26 UTC ---
I can't compile the preprocessed source with GCC 4.4, but that's pretty normal
for anything that includes boost because it uses so much conditional
compilation.

do you by any chance still have the origianl un-preprocessed source?
if not, I don't think this will be fixed, gcc 4.2 is no longer supported so if
it works with 4.3 (and I hope later versions) then it won't be fixed now

[Bug c++/46105] Ordering failure among partial specializations with non-deduced context

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-10-20 
21:39:23 UTC ---
(you can edit an existing attachment to set the content type)

thanks for the nice minimal testcase, that's very useful

I *think* this is a dup of another bug I've seen in bugzilla but I can't find
it right now

[Bug c++/46103] [c++0x] moving from std::array copies the elements

[marc.glisse at normalesup dot org]

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

--- Comment #2 from marc.glisse at normalesup dot org 2010-10-20 21:30:22 UTC 
---
(In reply to comment #1)
> so this would demonstrate the problem?
[snip example]

Yes, precisely.

> I haven't checked whether this is valid

I looked at N3126 around 12.8.17.

[Bug tree-optimization/45919] [4.6 Regression] ICE: SIGSEGV in fold_ctor_reference (tree-ssa-ccp.c:1527) at -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2010-10-20 
21:19:34 UTC ---
Fixed.

[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Jakub Jelinek  2010-10-20 
21:19:08 UTC ---
Fixed.

[Bug c/46106] New: Error in Manpage? -fstack-protection => -fstack-protector(-all)

[cdp_xe at gmx dot net]

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

   Summary: Error in Manpage? -fstack-protection =>
-fstack-protector(-all)
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cdp...@gmx.net
CC: cdp...@gmx.net


Hi,

isn't that wrong? Here is my very tiny patch for the gcc.1:

--- gcc.12010-10-20 23:11:16.0 +0200
+++ gcc.1.new2010-10-20 23:11:24.0 +0200
@@ -7661,7 +7661,7 @@ ratio is 3.
 .IP "\fBssp-buffer-size\fR" 4
 .IX Item "ssp-buffer-size"
 The minimum size of buffers (i.e. arrays) that will receive stack smashing
-protection when \fB\-fstack\-protection\fR is used.
+protection when \fB\-fstack\-protector\fR is used.
 .IP "\fBmax-jump-thread-duplication-stmts\fR" 4
 .IX Item "max-jump-thread-duplication-stmts"
 Maximum number of statements allowed in a block that needs to be

with best regards
Steffen

[Bug lto/45907] [4.6 Regression] Revision 164995 failed gcc.dg/torture/fp-int-convert-*.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from H.J. Lu  2010-10-20 21:18:25 
UTC ---
Fixed.

[Bug tree-optimization/45919] [4.6 Regression] ICE: SIGSEGV in fold_ctor_reference (tree-ssa-ccp.c:1527) at -O1

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-10-20 
21:17:35 UTC ---
Author: jakub
Date: Wed Oct 20 21:17:30 2010
New Revision: 165740

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165740
Log:
PR tree-optimization/45919
* tree-ssa-ccp.c (fold_nonarray_ctor_reference): Handle flexible
array members.

* gcc.c-torture/compile/pr45919.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr45919.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug c++/46105] Ordering failure among partial specializations with non-deduced context

[potswa at mac dot com]

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

David Krauss  changed:

   What|Removed |Added

  Attachment #22098|0   |1
is obsolete||

--- Comment #2 from David Krauss  2010-10-20 21:18:02 
UTC ---
Created attachment 22099
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22099
third time's a charm… content type autodetect failed

[Bug bootstrap/46055] [4.6 Regression] -fwhopr failed configure test

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #12 from H.J. Lu  2010-10-20 21:17:30 
UTC ---
Fixed by

http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00840.html

[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2010-10-20 
21:15:52 UTC ---
Author: jakub
Date: Wed Oct 20 21:15:49 2010
New Revision: 165739

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165739
Log:
PR tree-optimization/46066
* tree-parloops.c (create_parallel_loop): Use gsi_last_nondebug_bb
instead of gsi_last_bb.

* gcc.dg/autopar/pr46066.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr46066.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug c++/46105] Ordering failure among partial specializations with non-deduced context

[potswa at mac dot com]

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

--- Comment #1 from David Krauss  2010-10-20 21:15:27 
UTC ---
Created attachment 22098
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22098
small example

[Bug c++/46105] New: Ordering failure among partial specializations with non-deduced context

[potswa at mac dot com]

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

   Summary: Ordering failure among partial specializations with
non-deduced context
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pot...@mac.com


See attachment.

The second arguments of the two partial specializations evaluate to "void." If
void is substituted manually, the code works fine. (But the desired SFINAE side
effect is removed.)

As neither such argument contains a parameter in a deduced context, they should
not participate in deduction. Once the partial specialization has been
determined to match, the parameters should be substituted and evaluated to
simply void.

[Bug c/46104] New: Linker error "cannot find -liberty"

[enrico.miglino at ovi dot com]

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

   Summary: Linker error "cannot find -liberty"
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: enrico.migl...@ovi.com
CC: dougmenc...@gmail.com
  Host: Ubuntu 10.04 LT
Target: ARM LPC32xx


This error was received trying to compile sourced for the ARM EABI firmware
from Embedded Artists using the gnu toolchain of CodeSourcery G++ Lite for ARM
EABI.

The toolchain compile correctly the sources, generate libraries and create
object files, but at link time linker reports the following error:

/home/tech/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/bin/ld:
cannot find -liberty

The specific linker command from the toolchain commands sequence is the
following:

arm-none-eabi-gcc timer_example.o   ../common/crt0_gnu.o  -static
-Wl,--start-group
/home/tech/CodeSourcery/software/csps/lpc32xx/lib/liblpc32xxgnu.a
/home/tech/CodeSourcery/software/csps/lpc32xx/bsps/ea3250/lib/libea3250gnu.a
/home/tech/CodeSourcery/software/lpc/lib/liblpcarm926ej-sgnu.a -lgcc -lc -lg
-lm -liberty -lstdc++ -lsupc++  -Wl,--end-group  -Xlinker -Map -Xlinker \
timer.map -Xlinker -T   ../linker/ldscript_ram_gnu.ld   \
-o timer.elf

After investigations and tests, the problem concerns libiberty library, that is
installed in the toolchain of CodeSourcery only as static library and not
shared.

Trying to find the library in the host, the result is the following:

$ find / -name *libiberty* -print

/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot/lib/libiberty.a
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot/vfp/lib/libiberty.a
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/lib/libiberty.a
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/lib/vfp/libiberty.a
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/libiberty.a

[Bug c++/46103] [c++0x] moving from std::array copies the elements

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2010-10-20 
21:10:27 UTC ---
so this would demonstrate the problem?

struct MoveOnly {
  MoveOnly(const MoveOnly&) = delete;
  MoveOnly(MoveOnly&&) { }
  MoveOnly() = default;
};

struct A {
  MoveOnly mo[1];
};

int main() {
  A a;
  A aa = static_cast(a);
}

(I haven't checked whether this is valid, or is meant to be implemented yet in
g++)

[Bug tree-optimization/46099] [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.20 20:37:15
 CC||hjl.tools at gmail dot com,
   ||jakub at redhat dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-10-20 20:37:15 
UTC ---
It is caused by revision 157402:

http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00239.html

[Bug debug/46095] [4.6 Regression] ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:2341 with -fstack-protector

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.20 19:09:13
 CC||hjl.tools at gmail dot com,
   ||rth at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-10-20 19:09:13 
UTC ---
It is caused by revision 164628:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00926.html

Re: [Bug fortran/40054] [F08] Pointer functions as lvalue

[Mikael Morin]

> two() = 7
I don't see how it is possible to distinguish between a statement function and 
an assignment here.

[Bug c++/46103] New: [c++0x] moving from std::array copies the elements

[marc.glisse at normalesup dot org]

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

   Summary: [c++0x] moving from std::array copies the elements
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


Hello,

this is probably another "not implemented yet" (although the status page seems
to say that this is done), but I noticed that moving from:
struct A { Type t; };
properly moves t while moving from:
struct B { Type t[1]; };
copies t[0] (this is the case for std::array).

[Bug fortran/40054] [F08] Pointer functions as lvalue

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  2010-10-20 
18:05:23 UTC ---
Another example (from PR 46100):

two() = 7
contains
  function two ()
integer, pointer  :: two
allocate(two)
  end function two
end



Fails with:

  function two ()
  1
two() = 7
   2
Error: Procedure 'two' at (1) is already defined at (2)

  function two ()
  1
Error: INTERNAL-PROC procedure at (1) is already declared as STATEMENT-PROC
procedure

[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-10/msg01724.htm
   ||l
   Last reconfirmed||2010.10.20 18:03:32
 CC||hjl.tools at gmail dot com
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-10-20 18:03:32 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01724.html

[Bug fortran/46100] [Fortran 2008] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2010-10-20 
18:01:54 UTC ---
Untested patch:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 5711634..ef516a4 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4316,7 +4316,18 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer,
const char* context)
   symbol_attribute attr;
   gfc_ref* ref;

-  if (e->expr_type != EXPR_VARIABLE)
+  if (!pointer && e->expr_type == EXPR_FUNCTION
+  && e->symtree->n.sym->result->attr.pointer)
+{
+  if (!(gfc_option.allow_std & GFC_STD_F2008))
+   {
+ if (context)
+   gfc_error ("Fortran 2008: Pointer functions in variable definition"
+  " context (%s) at %L", context, &e->where);
+ return FAILURE;
+   }
+}
+  else if (e->expr_type != EXPR_VARIABLE)
 {
   if (context)
gfc_error ("Non-variable expression in variable definition context
(%s)"

[Bug tree-optimization/46099] [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.2

[Bug debug/46101] [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug debug/46102] New: ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490) with -feliminate-dwarf2-dups when using precompiled headers

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490)
with -feliminate-dwarf2-dups when using precompiled
headers
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.H -
/* NOTHING */
--
- testcase.C -
#include "testcase.H"
int i;
--

Generate files:
echo "" > testcase.H
echo '#include "testcase.H"' > testcase.C
echo 'int i;' >> testcase.C

Compile:
(testcase.H can be compiled with -feliminate-dwarf2-dups, it still fails)
$ gcc -g testcase.H
$ gcc -g testcase.C -feliminate-dwarf2-dups
testcase.C:2:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Related valgrind output:
==21702== Invalid read of size 8
==21702==at 0x74AB61: dwarf2out_finish (dwarf2out.c:8490)
==21702==by 0x9C6A15: toplev_main (toplev.c:961)
==21702==by 0x658ABBC: (below main) (in /lib64/libc-2.11.2.so)
==21702==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==21702== 
testcase.C:2:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165719 - crash
r158095 - crash
r153685 - crash
4.1.2, 4.2.4, 4.3.5, 4.4.5 - crash

[Bug fortran/46100] [Fortran 2008] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|Non-variable pointer|[Fortran 2008] Non-variable
   |expression as actual|pointer expression as
   |argument to INTENT(OUT) |actual argument to
   |non-pointer dummy   |INTENT(OUT) non-pointer
   ||dummy

--- Comment #2 from Tobias Burnus  2010-10-20 
17:45:27 UTC ---
After carefully reading the interpretation request,
http://www.j3-fortran.org/doc/year/08/08-172.txt, I think the reason that it is
invalid in Fortran 95/2003 is that only variables are definable and as "f()" is
not a variable, it is invalid.

Fortran 2008 has (cf. PR 40054):
   R602 variable  is  designator
  or  expr
   C602 (R602) expr shall be a reference to a function that has a pointer
   result."

Which makes the program valid.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #3 from Jeffrey Walton  2010-10-20 
17:38:59 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > When a module meets the above compile and runtime requirements, a crash 
> > > can
> > > occur in global objects with destructors when more than one process loads 
> > > and
> > > subsequently unloads a shared object.
> > Are you saying independent processes interfere with each other?
> ...
> Crpyto++ has a test case demonstrating the RTLD_GLOBAL crash at [1]. [1] is
> accompanied by an analysis under GDB at [2]. Unfortunately, the test case is
> not minimal. It is based on the Crypto++ library and needs intermediate SOs to
> load the SO of interest. So the final executable never directly loads the
> Crypto++ shared object.
If a picture is worth a 1000 words, here's the scenario we are trying to
accomplist (to verify Crypto++ does not crash when unloaded). But keep in mind
that two distinct process will perform what's in the image.
http://www.cryptopp.com/wiki/File:Cryptopp-so-test.png

[Bug c++/46024] g++.dg/warn/miss-format-1.C FAILs on Solaris 8 and 9

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  2010-10-20 17:36:24 UTC 
---
Author: ro
Date: Wed Oct 20 17:36:15 2010
New Revision: 165731

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165731
Log:
fixincludes:
PR c++/46024
* inclhack.def (solaris_sys_va_list): New fix.
* fixincl.x: Regenerate.
* tests/base/sys/va_list.h: New test.

gcc/testsuite:
PR c++/46024
* g++.dg/warn/miss-format-1.C: Enclose dg-error target list in braces.

Added:
trunk/fixincludes/tests/base/sys/va_list.h
Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/miss-format-1.C

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton  2010-10-20 
17:33:43 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > When a module meets the above compile and runtime requirements, a crash can
> > occur in global objects with destructors when more than one process loads 
> > and
> > subsequently unloads a shared object.
> Are you saying independent processes interfere with each other?
Yes and No :/

If each process loads the SO with RTLD_LOCAL, then No. If the processes each
load with RTLD_GLOBAL (so an exception can be caught) *AND* the SO has an
non-trivial global (such as an object with a destructor) then YES.

Crpyto++ has a test case demonstrating the RTLD_GLOBAL crash at [1]. [1] is
accompanied by an analysis under GDB at [2]. Unfortunately, the test case is
not minimal. It is based on the Crypto++ library and needs intermediate SOs to
load the SO of interest. So the final executable never directly loads the
Crypto++ shared object.

Based on the demonstartion, Wei Dai modified global objects so that only PODs
were global. Non-trivial objects were hidden in a GetGlobalXxx() (some hand
waiving). A write up distribution packagers (from our understanding of the
moving parts) is available at [3,4].

[1] http://www.cryptopp.com/w/images/8/89/Cryptopp-SO-Test-1.zip
[2]
http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726
[3] http://www.cryptopp.com/wiki/Linux#Note_for_Shared_Object_Callers
[4] http://www.cryptopp.com/wiki/Linux#Note_for_Distribution_Packagers

[Bug fortran/46100] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2010-10-20 
17:21:30 UTC ---
Forgot to add: In the current ISO Fortran standard (Fortran 2008), one finds:

"If a nonpointer dummy argument without the VALUE attribute corresponds
to a pointer actual argument that is pointer associated with a target,
the dummy argument becomes argument associated with that target."

"The INTENT (INOUT) attribute for a nonpointer dummy argument specifies
that any actual argument that corresponds to the dummy argument shall be
definable."

"definable -- capable of definition and permitted to become defined"

Thus, it boils down to the questions whether the target (to which the
pointer is pointer associated) is definable. I think that is usually
the case, which makes the example valid.

 * * *

Note, however, that Richard Maine disagrees - he thinks that it is invalid
Fortran 2003, while it might be valid Fortran 2008. I cannot see an essential
difference between the F2003 and F2008 wording, but there might be.

(See thread and see interpretation request F95/0074 in
http://j3-fortran.org/doc/standing/links/022.txt . Using a pointer function as
LHS of an assignment is tracked by F2008's PR 40054.)

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  2010-10-20 
17:18:33 UTC ---
> Maybe just always compiling without optimizations will do?

Adding "volatile" is exactly saying "do not optimize this loop", i.e. you get
at -O2 what you do at -O0, nothing more, nothing less.  This is a language
feature that is orthogonal to the synchronization stuff.

[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.20 16:58:52
 CC||hjl.tools at gmail dot com,
   ||matz at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-10-20 16:58:52 
UTC ---
It is caused by revision 146817:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  2010-10-20 
16:57:45 UTC ---
If the value changes because of IO (rather than being set by another thread, as
in your testcase) then volatile might be the right option.  Condvars could also
work and allow you to block, rather than doing a busy wait while holding a
lock.

[Bug debug/46101] New: [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in build_abbrev_table, at
dwarf2out.c:10333 with -feliminate-dwarf2-dups -g
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22097
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22097
reduced testcase

Compiler output:
$ gcc -feliminate-dwarf2-dups -g pr46101.C 
pr46101.C:6:4: internal compiler error: in build_abbrev_table, at
dwarf2out.c:10333
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165719 - crash
r161659 - crash
r159696 - OK
4.5 r163761 - OK

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

--- Comment #12 from Danilo  2010-10-20 16:53:53 UTC 
---
(In reply to comment #11)
> Busy waiting is rarely a good idea, so it depends on what are you exactly
> waiting for and whether say pthread_barrier_wait, or mutex, or condvar etc.
> wouldn't be more appropriate.

My objective of using threads is to detach a system in a simulation
environment. For this reason, it would be impracticable to use any type of lock
for everytime the I/O changes (which will happen all the time), so I guess
volatiles are the only way??

I am still reading the sites posted by Jonathan and understanding the
difficulties of doing this in modern CPUs, while it is so easy in hardware.
Maybe just always compiling without optimizations will do?

[Bug rtl-optimization/43721] Failure to optimise (a/b) and (a%b) into single __aeabi_idivmod call

[ams at gcc dot gnu.org]

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

Andrew Stubbs  changed:

   What|Removed |Added

 CC||ams at gcc dot gnu.org

--- Comment #6 from Andrew Stubbs  2010-10-20 16:53:13 
UTC ---
Here's the problem: expand_divmod always prefers the straight "div" library
call over the "divmod" library call, no exceptions.

Yes, "divmodsi4" in a .md is indeed preferred over "divsi4", so the
optimization works fine on targets that have those, but ARM doesn't, so those
rules are irrelevant.

ARM does not provide a separate library function for "mod", so expand_divmod
does use "divmod" for mod operations, but never for div operations.

The reason for the apparent opposite rules appears to be that the divmodsi4
rule can be coded to auto-detect the most optimal kind of underlying operation
to use, whereas the library call is fixed, once chosen.

I see two possible ways to fix this:
 1. Teach CSE (or somewhere) that div and divmod library calls have some
overlap.
 2. Always prefer divmod, and find some other way to convert it to div, where
appropriate.

I don't see any way to generate the RTL with the right call, so I'm pretty sure
it does have to be fixed up after the fact.

Or, I could be way off. :)

[Bug fortran/46100] New: Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

   Summary: Non-variable pointer expression as actual argument to
INTENT(OUT) non-pointer dummy
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Reported at c.l.f by Thomas Jahns:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread
/a64e2f255466a87a

GNU Fortran (and most other compilers) reject passing a non-variable pointer
expression as actual argument to an INTENT(OUT)/INTENT(INOUT) non-pointer dummy
argument.

The reason for rejecting is that the pointer expression (i.e. a function
returning a pointer) itself is not definable. However, I believe now that it
the code is valid. Thus, only if the argument were a pointer dummy or the
expression were not a pointer expression, it would be invalid.

Example:

call one (two ())
contains
  subroutine one (x)
integer, intent(inout) :: x
  end subroutine one
  function two ()
integer, pointer :: two
allocate(two)
  end function two
end

Error message:

call one (two ())
  1
Error: Non-variable expression in variable definition context (actual argument
to INTENT = OUT/INOUT) at (1)

[Bug tree-optimization/46099] New: [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g

[zsojka at seznam dot cz]

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

   Summary: [4.5/4.6 Regression] ICE: in replace_ssa_name, at
tree-cfg.c:5643 with -ftree-parallelize-loops -g
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22096
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22096
reduced testcase

Compiler output:
$ gcc -ftree-parallelize-loops=2 -g -O pr46099.c 
pr46099.c: In function 'foo':
pr46099.c:7:1: internal compiler error: in replace_ssa_name, at tree-cfg.c:5643
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165719 - crash
r158095 - crash
r153685 - OK
4.5 r163761 - crash
4.4 r160770 - OK

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2010-10-20 
15:52:53 UTC ---
(In reply to comment #0)
> When a module meets the above compile and runtime requirements, a crash can
> occur in global objects with destructors when more than one process loads and
> subsequently unloads a shared object.

Are you saying independent processes interfere with each other?

[Bug tree-optimization/45919] [4.6 Regression] ICE: SIGSEGV in fold_ctor_reference (tree-ssa-ccp.c:1527) at -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2010-10-20 
15:19:12 UTC ---
Created attachment 22095
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22095
gcc46-pr45919.patch

Untested fix.

[Bug target/46098] New: [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[zsojka at seznam dot cz]

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

   Summary: [4.5/4.6 Regression] ICE: in extract_insn, at
recog.c:2100 with -msse3 -ffloat-store and
__builtin_ia32_loadupd()
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.c -
typedef double v2df __attribute__((vector_size (16)));

v2df foo (double *d)
{
  return __builtin_ia32_loadupd (d);
}
--

Compiler output:
$ gcc -msse3 -ffloat-store testcase.c
testcase.c: In function 'foo':
testcase.c:6:1: error: unrecognizable insn:
(insn 7 6 8 3 (set (mem/c/i:V2DF (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -16 [0xfff0])) [0 D.2706+0 S16 A128])
(unspec:V2DF [
(mem:V2DF (reg:DI 60) [0 S16 A8])
] UNSPEC_MOVU)) testcase.c:5 -1
 (nil))
testcase.c:6:1: internal compiler error: in extract_insn, at recog.c:2110
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165719 - crash
r153685 - crash
4.5 r163761 - crash
4.4 r160770 - OK

[Bug c++/45983] [4.5 Regression] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill  2010-10-20 
15:05:28 UTC ---
Author: jason
Date: Wed Oct 20 15:05:22 2010
New Revision: 165728

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165728
Log:
PR c++/45983
* tree.c (cp_build_qualified_type_real): Don't reuse a variant
with a different typedef variant of the element type.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/lto/pr45983_0.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/tree.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

  Known to fail||4.3.5, 4.4.5, 4.5.2

--- Comment #1 from Zdenek Sojka  2010-10-20 15:02:12 
UTC ---
4.1.2 doesn't know _Decimal128, 4.2.4 refuses to compile

$ gcc-4.1.2 -Os -fno-omit-frame-pointer pr45946.c
pr45946.c:3: warning: parameter names (without types) in function declaration

$ gcc-4.2.4 pr45946.c
pr45946.c:2: error: decimal floating point not supported for this target

4.3.5 and newer compile without any optimisation, but fail with given flags

[Bug tree-optimization/38153] ICE in testcase when compiled with -ftree-parallelize-loops

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #4 from Zdenek Sojka  2010-10-20 14:52:32 
UTC ---
A bit different testcase, crashes on x86_64-pc-linux-gnu, r165719

- testcase.c -
void
foo (void **a, int i)
{
  while (i--)
a[i] = &&label;
label:;
}
--

$ gcc -O -ftree-parallelize-loops=2 testcase.c
testcase.c: In function 'foo':
testcase.c:2:1: error: label 
label has incorrect context in bb 6testcase.c:2:1: internal compiler error:
verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

-ftree-parallelize-loops=N, crashes for N>=2

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2010-10-20 
14:46:24 UTC ---
Busy waiting is rarely a good idea, so it depends on what are you exactly
waiting for and whether say pthread_barrier_wait, or mutex, or condvar etc.
wouldn't be more appropriate.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

Danilo  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #10 from Danilo  2010-10-20 14:45:18 UTC 
---
(In reply to comment #8)
> I don't recommend people use volatile to avoid multithreading races, it only
> prevents compiler optimisations, not hardware reordering. Using proper 
> atomics,
> memory barriers or other explicit synchronisation is better.
> But for this testcase, yes, volatile will "fix" it.
> 
> Danilo, you might like to read these
> http://www.drdobbs.com/cpp/201804238
> http://www.drdobbs.com/high-performance-computing/212701484

Thanks you very much, Jonathan! I will surely read the references.

I am considering this as closed.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

--- Comment #9 from Danilo  2010-10-20 14:43:18 UTC 
---
(In reply to comment #7)
> > Using a mutex around the reads and writes of shared data will make it work 
> > as
> > expected, the compiler won't optimise away the read and will re-read the 
> > value
> > every time.
> 
> This is overkill here though, you just need:
> 
>   volatile alpha *alpha1 = ( alpha * )data;

This solved it! Did not know about volatile variables. I was trying to avoid
exactly the use of mutexes and the like.

Thank you very much!

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2010-10-20 
14:40:21 UTC ---
I don't recommend people use volatile to avoid multithreading races, it only
prevents compiler optimisations, not hardware reordering. Using proper atomics,
memory barriers or other explicit synchronisation is better.
But for this testcase, yes, volatile will "fix" it.

Danilo, you might like to read these
http://www.drdobbs.com/cpp/201804238
http://www.drdobbs.com/high-performance-computing/212701484

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #90 from dave at hiauly1 dot hia.nrc.ca 2010-10-20 14:39:26 UTC ---
> The armv5 failure is a stage2 miscompilation.  Is it caused by Bernd's patch
> too?  Or by fwprop?

Actually, the ICE I saw this morning was in stage3.  This box is only
accessible at my contractor's site, so my access to it is limited.

Dave

[Bug c++/46097] New: Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

   Summary: Switch to warn of global variables in a C++ shared
object
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: noloa...@gmail.com


Feature reqeust only. Not a bug.

C++ shared objects are an interesting beast under certain circumstances (many
times, the shared object acts like a generic C module). Interesting includes:
* C++ module
* Shared object
* Shared object throws an exception which will cross module boundaries
* Shared object opened with RTLD_GLOBAL
* Shared object has global objects with destructors

Lots have been said about C++ exceptions, RTTI, type equality for the
'catch(const Exception&)', and RTLD_GLOBAL (versus RTLD_LOCAL) [1,2,3,4,5].

When a module meets the above compile and runtime requirements, a crash can
occur in global objects with destructors when more than one process loads and
subsequently unloads a shared object.

A switch to warn of global variables in a compilation unit would be very
helpful for those who are aware of the issue (and the circumstances to
encounter the issue). It appears that GCC does not supply such a switch [6].

The switch would be useful for module writers since its not always feasible to
'hand audit' all project files. And a warning would be exetremely useful for
package maintainers who don't write the module - they simply fixup the code and
package it for a distribution.

Perhaps -Wglobal-variable?

Jeffrey Walton
Baltimore, MD, US

[1] Minimal GCC/Linux shared lib + EH bug example,
http://gcc.gnu.org/ml/gcc/2002-05/msg00866.html
[2] dlopen and placing exception body in .cpp file,
http://gcc.gnu.org/ml/gcc-help/2010-08/msg00290.html
[3] Comparing types across SOs (sic),
http://groups.google.com/group/cryptopp-users/browse_thread/thread/eb815f228db50380
[4] Errors with multiple loading cryptopp as shared lib on Linux,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc22e8c6e2f48
[5] RTLD_GLOBAL and libcryptopp.so crash,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726
[6] Audit Use of Global Variables in C++ Shared Object (GCC Warning?), GCC-Help
mailing list, October, 2010 [not yet indexed].

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #7 from Eric Botcazou  2010-10-20 
14:34:40 UTC ---
> Using a mutex around the reads and writes of shared data will make it work as
> expected, the compiler won't optimise away the read and will re-read the value
> every time.

This is overkill here though, you just need:

  volatile alpha *alpha1 = ( alpha * )data;

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2010-10-20 
14:29:09 UTC ---
Using a mutex around the reads and writes of shared data will make it work as
expected, the compiler won't optimise away the read and will re-read the value
every time.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2010-10-20 
14:27:18 UTC ---
The field is not volatile, so in the loop nothing forces ->number field to be
loaded from memory again.
So it is perfectly fine to optize the whole loop into:
if (alpha1->number!=4)
  for (;;); /* Endless loop.  */

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Jonathan Wakely  2010-10-20 
14:24:30 UTC ---
yes, they share the same address space, but modern processors have multilevel
caches and unless you provide suitable synchronisation the write to
alpha1->number might not get made visible to other threads

I suggest you use a mutex around shared data

[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators

[alserkli at inbox dot ru]

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

Alexander Klimov  changed:

   What|Removed |Added

  Attachment #22086|0   |1
is obsolete||

--- Comment #9 from Alexander Klimov  2010-10-20 
14:19:23 UTC ---
Created attachment 22094
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22094
simple testcase

Your patch seems to work, thanks!

Btw, the original "simple testcase" did not contain

  It(const It&){ ++it_counter; }

and thus would fail (It() is called twice, while ~It() -- thrice).

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

Danilo  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #3 from Danilo  2010-10-20 14:17:30 UTC 
---
Changed the status back to unconfirmed.

[Bug lto/45667] [4.6 Regression] ICE: verify_stmts failed: type mismatch in address expression with -flto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2010-10-20 
14:14:07 UTC ---
Fixed.

[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  2010-10-20 
14:13:44 UTC ---
Author: jason
Date: Wed Oct 20 14:13:38 2010
New Revision: 165726

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165726
Log:
PR c++/46056
* parser.c (cp_convert_range_for): Call cp_finish_decl
instead of finish_expr_stmt.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/45667] [4.6 Regression] ICE: verify_stmts failed: type mismatch in address expression with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2010-10-20 
14:11:09 UTC ---
Author: rguenth
Date: Wed Oct 20 14:11:06 2010
New Revision: 165725

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165725
Log:
2010-10-20  Richard Guenther  

PR lto/45667
* lto-streamer-out.c (output_gimple_stmt): Fix typo.
* tree-cfg.c (verify_gimple_call): Properly get the call fndecl.
(verify_gimple_assign_single): Disable ADDR_EXPR type check
when in LTO.

* g++.dg/lto/20101020-1_0.h: New testcase.
* g++.dg/lto/20101020-1_0.C: Likewise.
* g++.dg/lto/20101020-1_1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/lto/20101020-1_0.C
trunk/gcc/testsuite/g++.dg/lto/20101020-1_0.h
trunk/gcc/testsuite/g++.dg/lto/20101020-1_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[bonzini at gnu dot org]

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

--- Comment #89 from Paolo Bonzini  2010-10-20 14:09:33 
UTC ---
The armv5 failure is a stage2 miscompilation.  Is it caused by Bernd's patch
too?  Or by fwprop?

According to comment 22, previously it was not bootstrapping but the failure
was elsewhere.  But we don't know if it is one or two bugs, and we don't know
how it relates with the fwprop problem (which was latent all the time even
before Bernd's patch).  The only good news is that a stage2 libgcc crash is
slightly simpler to debug than a stage3 comparison failure.  In any case, the
next thing to do is to bisect to find where the crash appeared, then go to the
previous revision, try applying my patch and see if it fixes the failure of
comment 22.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

--- Comment #2 from Danilo  2010-10-20 14:07:45 UTC 
---
(In reply to comment #1)
> There is no memory synchronisation, so there is no guarantee that the write to
> alpha1->number ever becomes visible to other threads.

According to http://wiki.libsdl.org/moin.cgi/SDL_CreateThread, the threads
created share the same memory. So I guess sync is not needed.

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[vmakarov at gcc dot gnu.org]

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

--- Comment #25 from Vladimir Makarov  2010-10-20 
14:06:11 UTC ---
Author: vmakarov
Date: Wed Oct 20 14:06:08 2010
New Revision: 165724

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165724
Log:
2010-10-20  Vladimir Makarov  

PR fortran/42169
* ira-emit.c (store_can_be_removed_p): Return false instead of
gcc_unreachable.


Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/ira-emit.c

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[vmakarov at gcc dot gnu.org]

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

--- Comment #24 from Vladimir Makarov  2010-10-20 
14:05:25 UTC ---
Author: vmakarov
Date: Wed Oct 20 14:05:21 2010
New Revision: 165723

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165723
Log:
2010-10-20  Vladimir Makarov  

PR fortran/42169
* ira-emit.c (store_can_be_removed_p): Return false instead of
gcc_unreachable.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/ira-emit.c

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
   Severity|major   |normal

--- Comment #1 from Jonathan Wakely  2010-10-20 
14:00:49 UTC ---
There is no memory synchronisation, so there is no guarantee that the write to
alpha1->number ever becomes visible to other threads.

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[vmakarov at gcc dot gnu.org]

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

--- Comment #23 from Vladimir Makarov  2010-10-20 
13:51:37 UTC ---
Author: vmakarov
Date: Wed Oct 20 13:51:31 2010
New Revision: 165722

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165722
Log:
2010-10-20  Vladimir Makarov  

PR fortran/42169
* ira-emit.c (store_can_be_removed_p): Return false instead of
gcc_unreachable.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-emit.c

[Bug c++/46096] New: Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

   Summary: Code produces two different outputs when optimized
respectively with -O2 and without it.
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zwei...@gmail.com


Created attachment 22093
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22093
Minimal testcase

The code attached is a very simple application of threads using SDL_threads
library. 

In the code just one thread is created and it should enter in a loop waiting
for a class variable to become 4 and exit printing "END" on the screen. Since
the variable is modified to 4 in the main program, the thread should exit and
print "END" on the screen always. However, this does not happen all the time in
the -O2 compiled version.

The compiled version WITHOUT -O2 gives the expected output "END" (Reproducible:
always).
On the other hand, the -O2 version of the code produces an executable which
sometimes print and sometimes do not print "END" on the screen (Occasionally
one may need to run the program 20 times to spot 1 error). 

I attached the very simple test.cpp file.

And here is the output from g++ without optimization:

g++ -v -save-temps -o sdl_thread -Wall test.cpp -lSDL 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.3.4 p1.1, pie-10.1.5'
Thread model: posix
gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=i686 -Wall -fpch-preprocess
-o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/i686-pc-linux-gnu
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/backward
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=i686 -auxbase test -Wall -version -o
test.s
GNU C++ (Gentoo 4.3.4 p1.1, pie-10.1.5) version 4.3.4 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.4, GMP version 4.3.2, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a9af7e955b36498814b0c0d47ad1b377
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o test.o test.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.18
COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/collect2 --eh-frame-hdr -m elf_i386
-dynamic-li

[Bug c/45062] [4.6 Regression] Revision 162223 caused ICE at c-decl.c:4064

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||froydnj at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |froydnj at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Nathan Froyd  2010-10-20 
13:47:51 UTC ---
I will fix this shortly after stage 3 starts.

[Bug c++/46065] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at cp/decl.c:477

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |froydnj at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Nathan Froyd  2010-10-20 
13:46:08 UTC ---
I will fix this shortly after stage 3 starts.

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[danglin at gcc dot gnu.org]

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

--- Comment #88 from John David Anglin  2010-10-20 
13:41:38 UTC ---
(In reply to comment #85)
> Created attachment 22079 [details]
> patch
> I haven't yet tested this on a cross-compiler, but it bootstrapped and
> regtested fine on x86_64-pc-linux-gnu.

I also tested the patch on armv5tejl-unknown-linux-gnueabi.  The ICE in
function '__popcountsi2' is still there, so this must be a separate issue.

[Bug c/46090] 16 bit uint16_t puts non-zero in highest bits when shifting

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-10-20 
13:34:31 UTC ---
Because that's what the C standard says, under the rules for integer promotions

[Bug c/46090] 16 bit uint16_t puts non-zero in highest bits when shifting

[kshakhna at gmail dot com]

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

--- Comment #2 from Kamo Shakhnazaryan  2010-10-20 
13:30:40 UTC ---
(In reply to comment #1)
> input * 0x0101 is really ((int)input) * 0x0101.  So this behavior is correct.

input is declared as uint16_t.

Why input * 0x0101 is really ((int)input) * 0x0101 ?

[Bug debug/46095] New: [4.6 Regression] ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:2341 with -fstack-protector

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in dwarf2out_frame_debug_expr,
at dwarf2out.c:2341 with -fstack-protector
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22092
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22092
reduced testcase

Compiler output:
$ gcc -O -fschedule-insns2 -fno-omit-frame-pointer -fstack-protector pr46095.c
pr46095.c: In function 'foo':
pr46095.c:8:1: internal compiler error: in dwarf2out_frame_debug_expr, at
dwarf2out.c:2341
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165719 - crash
r163636 - OK

[Bug fortran/46067] [F03] invalid procedure pointer assignment not detected

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.20 13:11:39
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #5 from janus at gcc dot gnu.org 2010-10-20 13:11:39 UTC ---
Mine. The accepts-invalid problem in comment #2 is fixed by the following
patch:

Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 165712)
+++ gcc/fortran/interface.c(working copy)
@@ -1056,7 +1056,7 @@ gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol
   }

 /* Check type and rank.  */
-if (!compare_type_rank (f1->sym, f2->sym))
+if (!compare_type_rank (f2->sym, f1->sym))
   {
 if (errmsg != NULL)
   snprintf (errmsg, err_len, "Type/rank mismatch in argument '%s'",