[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813 --- Comment #6 from Darren Jenkins 2010-09-29 03:55:39 UTC --- Also if I don't use -fno-omit-frame-pointer the code seems to be generated correctly
[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813 --- Comment #5 from Darren Jenkins 2010-09-29 03:33:27 UTC --- > Please show us the output of "gcc -v", we want to see how the compiler was > configured (wrt certain defaults etc). Also, when you invoke the compiler we > want to see the exact options YOU supply to it; right now it's difficult to > separate your options from what the compiler driver passes to the backend. This is a little difficult as the compiler is part of a whole "development/build environment" thing, and I can't find an executable called "gcc" in it. I will investigate how it is put together and see what I can find out.
[Bug fortran/45826] NOT bug but web link error?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45826 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #3 from Jerry DeLisle 2010-09-29 03:03:09 UTC --- Most of the folks that do provide these unofficial binaries also subscribe to the gfortran list at fort...@gcc.gnu.org. Your questions are better asked there.
[Bug other/45808] FreeBSD: -pthread is handled incompletely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45808 Gerald Pfeifer changed: What|Removed |Added CC||gerald at pfeifer dot com --- Comment #5 from Gerald Pfeifer 2010-09-29 02:55:47 UTC --- I'm doing the necessary regression testing and will report the patch with a proper ChangeLog entry later this week. (I actually was the one encouraging Andriy to post the patch and file a Bugzilla, just missed the latter.)
[Bug fortran/45826] NOT bug but web link error?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45826 --- Comment #2 from Andrew Pinski 2010-09-28 23:34:50 UTC --- Forgot to mention anyone can edit the wiki too. So the uploaded binaries are not supported via this form at all.
[Bug fortran/45826] NOT bug but web link error?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45826 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2010-09-28 23:34:02 UTC --- "This page gathers links to all ___unofficial___ gfortran binary packages people regularly build, based on the current development gfortran source code. " "Note: There do not exist any official FSF/GNU/GCC binary builds (only source packages)."
[Bug fortran/45826] New: NOT bug but web link error?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45826 Summary: NOT bug but web link error? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: nki...@giss.nasa.gov This is not a bug, but maybe an error in the web link to a binary. On this page: http://gcc.gnu.org/wiki/GFortranBinaries#MacOS the binary that downloads for Mac OS 10.5 (Leopard) is named gfortran-macos-x86.dmg. This opens to an installation application named gfortran-4.5-x86_64-SnowLeopard. Why does it have the name SnowLeopard in it? Did someone zip in the wrong file for Leopard? When I installed this binary, I cannot run gfortran, but I always get the error, simply invoking gfortran by itself: dyld: unknown required load command 0x8022 I was able to install gfortran 4.2.3 and run that without this error. So, is the correct binary uploaded for gfortran for Leopard?
[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813 --- Comment #4 from Mikael Pettersson 2010-09-28 23:21:27 UTC --- Please show us the output of "gcc -v", we want to see how the compiler was configured (wrt certain defaults etc). Also, when you invoke the compiler we want to see the exact options YOU supply to it; right now it's difficult to separate your options from what the compiler driver passes to the backend.
[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813
--- Comment #3 from Darren Jenkins 2010-09-28
23:07:08 UTC ---
unsigned short ReadLE16U( volatile unsigned char * ptr )
{
unsigned short value;
unsigned char * bytes = (unsigned char *)&value;
bytes[0] = ptr[0];
bytes[1] = ptr[1];
return value;
}
Gives me the same erroneous results.
The compiler I am using is part of Rowley "CrossWorks for ARM" 2.0.7 which
claims to be an unmodified GCC 4.4.4
http://www.rowley.co.uk/crossworks/gpl_sources.htm
cc1 --version
GNU C (GCC) version 4.4.4 (arm-unknown-elf)
compiled by GNU C version 3.4.4 (mingw special), GMP version 4.3.2
version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
What gets passed to the compiler seems to be :
"C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM
2.0/gcc/bin/cc1" -fmessage-length=0 -mcpu=arm7tdmi-s -mthumb -mthumb-interwork
-mlittle-endian -mfpu=vfp -mfloat-abi=soft -nostdinc "-isystemC:/Program Files
(x86)/Rowley Associates Limited/CrossWorks for ARM 2.0/include"
"-isystemC:/Users/DarrenJenkins/AppData/Local/Rowley Associates
Limited/CrossWorks for ARM/packages/include" -I. -I../.. -I../../include
-I../../system -I../../LwIP -I../../LwIP/include -I../../LwIP/include/lwip
-I../../LwIP/include/ipv4 -I../../NXP_Lib -I../../fat_file_system -I../../usb
-I../../usb/UsbHost/Include -I../../Macro -D__ARM_ARCH_4T__ -D__CROSSWORKS_ARM
-D__CROSSWORKS_MAJOR_VERSION=2 -D__CROSSWORKS_MINOR_VERSION=0
-D__CROSSWORKS_REVISION=7 -D__TARGET_PROCESSOR=LPC2468 -DNESTED_INTERRUPTS
-DSRAM_EXCEPTIONS -D__THUMB -D__FLASH_BUILD
-DOSCILLATOR_CLOCK_FREQUENCY=1200 -DDEBUG -MD "THUMB Flash
Debug/usbhost_lpc2468.d" -MQ "THUMB Flash Debug/usbhost_lpc2468.o" -quiet -Wall
-fno-omit-frame-pointer -fno-schedule-insns2 -gdwarf-2 -Os -fno-dwarf2-cfi-asm
-fno-builtin -ffunction-sections -fdata-sections
C:/Users/DarrenJenkins/Documents/NXP_darren/src/projects/Darren/../../usb/UsbHost/Host/usbhost_lpc2468.c
-o "C:/Users/DarrenJenkins/Documents/NXP_darren/src/projects/Darren/THUMB Flash
Debug/usbhost_lpc2468.asm"
and
"C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM
2.0/gcc/bin/as" --traditional-format -mcpu=arm7tdmi-s -mthumb -mthumb-interwork
-EL -mfpu=vfp -mfloat-abi=soft
"C:/Users/DarrenJenkins/Documents/NXP_darren/src/projects/Darren/THUMB Flash
Debug/usbhost_lpc2468.asm" -o
"C:/Users/DarrenJenkins/Documents/NXP_darren/src/projects/Darren/THUMB Flash
Debug/usbhost_lpc2468.o"
Yell out if you would like to know anything else.
[Bug target/45800] [M32C] compile error on increment volatile long var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45800 --- Comment #2 from dj at gcc dot gnu.org 2010-09-28 22:01:58 UTC --- Author: dj Date: Tue Sep 28 22:01:54 2010 New Revision: 164705 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164705 Log: PR target/45800 * config/m32c/m32c.c (m32c_subreg): Force adjustment of subregs of volatile MEMs. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m32c/m32c.c
[Bug preprocessor/44526] libcpp should avoid circular dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44526 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #1 from Tom Tromey 2010-09-28 21:59:21 UTC --- It seems like it would be simpler for gfortran to do this check.
[Bug target/45800] [M32C] compile error on increment volatile long var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45800 DJ Delorie changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.28 21:18:10 date|| AssignedTo|unassigned at gcc dot |dj at redhat dot com |gnu.org | Ever Confirmed|0 |1
[Bug bootstrap/45816] [4.6 Regression] Bootstrap comparison failure! for powerpc-apple-darwin9 with --enable-checking=release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45816 --- Comment #2 from Dominique d'Humieres 2010-09-28 20:52:27 UTC --- > I don't think I have access to that type of machine. If you send me a public key, I can give you access to my machine. > Can you help narrow it down as was done in PR45445? I can try (under supervision!-), but probably not before the end of the week.
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445 --- Comment #24 from Mikael Pettersson 2010-09-28 20:50:01 UTC --- (In reply to comment #23) > Created attachment 21902 [details] > A patch which should fix it > > Please verify whether this patch fixes it. I did a C-only bootstrap of 4.6 r162418 + this patch and it succeeded with no comparison failures. The resulting compiler also correctly compiled the test case I posted. Thanks.
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #22 from Tobias Burnus 2010-09-28
20:43:57 UTC ---
Another case of off-by-one line numbers:
http://gcc.gnu.org/ml/fortran/2010-09/msg00500.html
For
if (Gridded_resid_mask(4,4)) then ! Line 5
write(*,*) 'Boo' ! Line 6
The "if" is in the wrong line (6 instead of 5) - while the condition itself is
in the correct line; i.e.:
[ghghjh.f90 : 6] if ([ghghjh.f90 : 5] (*gridded_resid_mask)[[ghghjh.f90 : 5]
(stride.2 + 1) * 4 + offset.3])
{
[...]
[ghghjh.f90 : 6] _gfortran_transfer_character ([ghghjh.f90 : 6]
&dt_parm.7, [ghghjh.f90 : 6] &[ghghjh.f90 : 6] "Boo"[1]{lb: 1 sz: 1}, 3);
[Bug c++/45822] [4.6-regression] Qt 4.7.0 build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45822 --- Comment #3 from Ruben Van Boxem 2010-09-28 20:34:48 UTC --- This also happens later in the build process, with this command and output: g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"..\..\..\include\QtCore" -I"..\..\..\include\QtGui" -I"..\..\..\include" -I"..\..\..\include\ActiveQt" -I"tmp\moc\release_shared" -I"m:\Development\Source\qt\examples\animation\moveblocks" -I"." -I"..\..\..\mkspecs\win32-g++" -o tmp\obj\release_shared\main.o m:\Development\Source\qt\examples\animation\moveblocks\main.cpp m:\Development\Source\qt\examples\animation\moveblocks\main.cpp: In constructor 'QGraphicsRectWidget::QGraphicsRectWidget()': m:\Development\Source\qt\examples\animation\moveblocks\main.cpp:69:7: error: no matching function for call to 'QFlags::QFlags(int)' ..\..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2181:12: note: candidates are: QFlags::QFlags(QFlag) [with Enum = Qt::WindowType] ..\..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2180:12: note: QFlags::QFlags(QFlags::Zero) [with Enum = Qt::WindowType, QFlags::Zero = void**] ..\..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2179:12: note: QFlags::QFlags(Enum) [with Enum = Qt::WindowType] ..\..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2178:12: note: QFlags::QFlags(const QFlags&) [with Enum = Qt::WindowType, QFlags = QFlags] m:\Development\Source\qt\examples\animation\moveblocks\main.cpp: In function 'int qMain(int, char**)': m:\Development\Source\qt\examples\animation\moveblocks\main.cpp:177:40: note: synthesized method 'QGraphicsRectWidget::QGraphicsRectWidget()' first required here I can provide preprocessed source for this if needed.
[Bug c++/44673] static const variable works in if/else, fails at linking in ternary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673 Andrew Pinski changed: What|Removed |Added CC||derzuomaia at gmail dot com --- Comment #16 from Andrew Pinski 2010-09-28 20:33:38 UTC --- *** Bug 45825 has been marked as a duplicate of this bug. ***
[Bug c++/45825] The operator ? : doesn't work when Class::attr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45825 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski 2010-09-28 20:33:38 UTC --- num==0 ? Port::ASI_PORT : Port::IP_PORT produces a lvalue so you need a definition for those two. See PR 44673. *** This bug has been marked as a duplicate of bug 44673 ***
[Bug bootstrap/45816] [4.6 Regression] Bootstrap comparison failure! for powerpc-apple-darwin9 with --enable-checking=release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45816 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #1 from Bernd Schmidt 2010-09-28 20:27:11 UTC --- I don't think I have access to that type of machine. Can you help narrow it down as was done in PR45445?
[Bug c++/45825] New: The operator ? : doesn't work when Class::attr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45825
Summary: The operator ? : doesn't work when Class::attr
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: derzuom...@gmail.com
Created attachment 21909
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21909
contains 2 ii files.
The operator ? : doesn't work correctly, when is used a static class attribute
like Class::attr as the second param of the operator ?: . Exemple:
printf("type %d\n", num==0 ? Port::ASI_PORT : Port::IP_PORT);
G++ "thinks" that the first ':' is already the else ':'
Follows the output of the execution of:
bugg++$ g++ -v -Wall -save-temps main.cpp port.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--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-plugin --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.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE main.cpp
-D_FORTIFY_SOURCE=2 -mtune=generic -march=i486 -Wall -fpch-preprocess
-fstack-protector -o main.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/i486-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=i486 -auxbase main -Wall -version
-fstack-protector -o main.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 35224f2c24023afb0a5be7befe8d5f3f
COLLECT_GCC_OPTIONS='-v' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=i486'
as -V -Qy -o main.o main.s
GNU assembler version 2.20.1 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.20.1-system.20100303
COLLECT_GCC_OPTIONS='-v' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE port.cpp
-D_FORTIFY_SOURCE=2 -mtune=generic -march=i486 -Wall -fpch-preprocess
-fstack-protector -o port.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/i486-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -fpreprocessed port.ii -quiet
-dumpbase port.cpp -mtune=generic -march=i486 -auxbase port -Wall -version
-fstack-protector -o port.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 35224f2c24023afb0a5be7befe8d5f3f
[Bug fortran/40568] F2008: C_SIZEOF rejected as initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Tobias Burnus 2010-09-28 19:55:45 UTC --- Really mark as FIXED.
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Tobias Burnus 2010-09-28 19:55:51 UTC --- Really mark as FIXED.
[Bug fortran/40568] F2008: C_SIZEOF rejected as initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568 --- Comment #10 from Tobias Burnus 2010-09-28 19:53:01 UTC --- Close as FIXED (for 4.6). Separately tracked follow ups: For simplify of array valued arguments, cf. PR36437. For updating check_inquiry, cf. PR 45824.
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569 --- Comment #11 from Tobias Burnus 2010-09-28 19:52:55 UTC --- Close as FIXED (for 4.6). Separately tracked follow ups: For updating check_inquiry, cf. PR 45824. For the bogus warning, cf. PR 45823 (In reply to comment #9) > this is nice... can this be used in an initialization expression ? > > CHARACTER(LEN=100), PARAMETER :: module_compile_info = & > compiler_version()//compiler_options() Yes, but you need to add "use iso_fortran_env".
[Bug fortran/40568] F2008: C_SIZEOF rejected as initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568 --- Comment #9 from Tobias Burnus 2010-09-28 19:51:43 UTC --- Author: burnus Date: Tue Sep 28 19:51:38 2010 New Revision: 164698 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164698 Log: gcc/ 2010-09-28 Tobias Burnus PR fortran/40569 PR fortran/40568 * toplev.h (save_decoded_options, save_decoded_options_count): New global variables. * toplev.c (save_decoded_options, save_decoded_options_count): export variables. gcc/fortran/ 2010-09-28 Tobias Burnus PR fortran/40569 PR fortran/40568 * intrinsic.c (add_functions): Make compiler_version and compiler_options CLASS_INQUIRY. * gfortran.h (gfc_get_option_string): New prototype. * intrinsic.texi (COMPILER_VERSION, COMPILER_OPTIONS): Add documentation. (C_SIZEOF): Mark as inquiry function of ISO_C_BINDING. (ISO_FORTRAN_ENV): Refer to COMPILER_VERSION and COMPILER_OPTIONS. (ISO_C_BINDING): Refer to C_SIZEOF. * options.c (gfc_get_option_string): New function. * simplify.c (gfc_simplify_compiler_options): Use it. (gfc_simplify_compiler_version): Include compiler name. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/options.c trunk/gcc/fortran/simplify.c trunk/gcc/toplev.c trunk/gcc/toplev.h
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569 --- Comment #10 from Tobias Burnus 2010-09-28 19:51:42 UTC --- Author: burnus Date: Tue Sep 28 19:51:38 2010 New Revision: 164698 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164698 Log: gcc/ 2010-09-28 Tobias Burnus PR fortran/40569 PR fortran/40568 * toplev.h (save_decoded_options, save_decoded_options_count): New global variables. * toplev.c (save_decoded_options, save_decoded_options_count): export variables. gcc/fortran/ 2010-09-28 Tobias Burnus PR fortran/40569 PR fortran/40568 * intrinsic.c (add_functions): Make compiler_version and compiler_options CLASS_INQUIRY. * gfortran.h (gfc_get_option_string): New prototype. * intrinsic.texi (COMPILER_VERSION, COMPILER_OPTIONS): Add documentation. (C_SIZEOF): Mark as inquiry function of ISO_C_BINDING. (ISO_FORTRAN_ENV): Refer to COMPILER_VERSION and COMPILER_OPTIONS. (ISO_C_BINDING): Refer to C_SIZEOF. * options.c (gfc_get_option_string): New function. * simplify.c (gfc_simplify_compiler_options): Use it. (gfc_simplify_compiler_version): Include compiler name. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/options.c trunk/gcc/fortran/simplify.c trunk/gcc/toplev.c trunk/gcc/toplev.h
[Bug fortran/45824] New: Update expr.c's check_inquiry for C_SIZEOF, compiler_version/_options, etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45824 Summary: Update expr.c's check_inquiry for C_SIZEOF, compiler_version/_options, etc. 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 CC: dfra...@gcc.gnu.org Follow up to PR 40568 - but also to PR 40569. The PR of the former - I might not have copied all remaining tasks. ISO_C_BINDING's C_SIZEOF but also ISO_FORTRAN_ENV's compiler_options/compiler_version as listed under Fortran 2008's "7.1.11 Speci cation expression" as "speci cation inquiry". If I understood this part of the previous PR correctly, it means that expr.c's check_inquiry needs to be updated. I think except for some F95 vs. newer checks, most items should be handled via flags in add_function/subroutine of intrinsic.c as one easily forgets to update check_inquiry.
[Bug fortran/45823] New: Bogus warning for intrinsic module procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45823 Summary: Bogus warning for intrinsic module procedures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Follow up to PR 40569. The following program prints with -Wall: use iso_Fortran_env 1 Warning: Type specified for intrinsic function 'compiler_options' at (1) is ignored use iso_Fortran_env 1 Warning: Type specified for intrinsic function 'compiler_version' at (1) is ignored For some reason, c_sizeof is not affected. use iso_c_binding use iso_Fortran_env implicit none intrinsic sin real :: x = 3.4 print *, sin(x), c_sizeof(c_int), compiler_options(), compiler_version() end
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #19 from Damian Rouson 2010-09-28 18:38:12 UTC --- Could someone please comment on the relevance (or lack thereof) of the component being public in the example I submitted? My real goal is to have all data components private, but I left that out in the test case I submitted. The question of whether the code would still be valid appears to be a sticking point in getting one vendor to support the requested feature.
[Bug target/45805] VFP/Neon double precision register expected -- `vmovl.s16 q2,s8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 --- Comment #7 from Khem Raj 2010-09-28 18:30:52 UTC --- (In reply to comment #6) > Created attachment 21903 [details] > vmov[l,n] fix yes the 'w' constraint will do the trick. this patch works well for me.
[Bug target/45815] [4.6 Regression] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from Ian Lance Taylor 2010-09-28 18:27:15 UTC --- Should be fixed now. Thanks for the bug report.
[Bug target/45815] [4.6 Regression] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815 --- Comment #8 from ian at gcc dot gnu.org 2010-09-28 18:22:19 UTC --- Author: ian Date: Tue Sep 28 18:22:13 2010 New Revision: 164695 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164695 Log: PR target/45815 * opts.c (decode_options): Don't test whether the target supports split stack if flag_split_stack == 0. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug c++/45822] New: [4.6-regression] Qt 4.7.0 declarative build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45822 Summary: [4.6-regression] Qt 4.7.0 declarative build fails Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../src/gcc/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/mingw64 --enable-lto --disable-multilib --enable-shared --enable-stage1-languages=c,lto --enable-languages=c,c++,lto --with-libiconv-prefix=/home/Ruben/mingw64/build64/gcc-libs --with-libexpat-prefix=/home/Ruben/mingw64/build64/gcc-libs --with-gmp=/home/Ruben/mingw64/build64/gcc-libs --with-mpfr=/home/Ruben/mingw64/build64/gcc-libs --with-mpc=/home/Ruben/mingw64/build64/gcc-libs --disable-win32-registry --enable-fully-dynamic-string --enable-checking=release --disable-werror --disable-nls CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer' LFLAGS=-no-undefined BOOT_CFLAGS= 'BOOT_LFLAGS=-flto -fwhopr=2' TARGET_CFLAGS= 'TARGET_LFLAGS=-flto -fwhopr=2' Thread model: win32 gcc version 4.6.0 20100918 (experimental) (GCC) This is built from a snapshot and patched for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580 Command used to compile the file and its output: g++ -c -O2 -Wall -frtti -fexceptions -mthreads -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_DECLARATIVE_LIB -DQT_NO_URL_CAST_FROM_STRING -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -D_USE_MATH_DEFINES -DQT_DLL -DQT_NO_DEBUG -DQT_SCRIPT_LIB -DQT_SVG_LIB -DQT_SQL_LIB -DQT_XMLPATTERNS_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I"..\..\include\QtCore" -I"..\..\include\QtNetwork" -I"..\..\include\QtGui" -I"..\..\include\QtOpenGL" -I"..\..\include\QtXmlPatterns" -I"..\..\include\QtSql" -I"..\..\include\QtSvg" -I"..\..\include\QtScript" -I"..\..\include" -I"..\..\include\QtDeclarative" -I"tmp\rcc\release_shared" -I"tmp" -I"m:\Development\Source\qt\src\declarative\util" -I"m:\Development\Source\qt\src\declarative\graphicsitems" -I"m:\Development\Source\qt\src\declarative\qml" -I"m:\Development\Source\qt\src\declarative\qml\parser" -I"m:\Development\Source\qt\src\declarative\qml\rewriter" -I"m:\Development\Source\qt\src\declarative\debugger" -I"..\..\include\ActiveQt" -I"tmp\moc\release_shared" -I"m:\Development\Source\qt\src\declarative" -I"." -I"..\..\mkspecs\win32-g++" -o tmp\obj\release_shared\qdeclarativeitemsmodule.o m:\Development\Source\qt\src\declarative\graphicsitems\qdeclarativeitemsmodule.cpp In file included from ..\..\include/QtDeclarative/qdeclarativeprivate.h:1:0, from ..\..\include\QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarative.h:45, from ..\..\include\QtDeclarative/qdeclarative.h:1, from ..\..\include\QtDeclarative/private/../../../../../Source/qt/src/declarative/graphicsitems/qdeclarativeitemsmodule_p.h:45, from ..\..\include\QtDeclarative/private/qdeclarativeitemsmodule_p.h:1, from m:\Development\Source\qt\src\declarative\graphicsitems\qdeclarativeitemsmodule.cpp:42: ..\..\include/QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarativeprivate.h: In constructor 'QDeclarativePrivate::QDeclarativeElement::QDeclarativeElement()': ..\..\include/QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarativeprivate.h:85:11: instantiated from 'void QDeclarativePrivate::createInto(void*) [with T = QGraphicsWidget]' ..\..\include\QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarative.h:185:5: instantiated from 'int qmlRegisterType(const char*, int, int, const char*) [with T = QGraphicsWidget]' m:\Development\Source\qt\src\declarative\graphicsitems\qdeclarativeitemsmodule.cpp:154:64: instantiated from here ..\..\include/QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarativeprivate.h:85:11: error: no matching function for call to 'QFlags::QFlags(int)' ..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2181:12: note: candidates are: QFlags::QFlags(QFlag) [with Enum = Qt::WindowType] ..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2180:12: note: QFlags::QFlags(QFlags::Zero) [with Enum = Qt::WindowType, QFlags::Zero = void**] ..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2179:12: note: QFlags::QFlags(Enum) [with Enum = Qt::WindowType] ..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2178:12: note: QFl
[Bug c/45821] no warning when returning a local variable address within a statement expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45821
--- Comment #3 from Andrew Gaul 2010-09-28 17:51:21 UTC
---
The web form truncates all my attachedments at 244 bytes. Here is the source
inline:
/*
* GCC warns about returning a local variable address within a function but not
* within a statement expression:
*
* $ gcc statement_expression_return_local.c -c -Wall
* statement_expression_return_local.c: In function ‘function_return_local’:
* statement_expression_return_local.c:13: warning: function returns address of
local variable
*/
int *function_return_local(void)
{
int x = 0;
return &x;
}
int *statement_expression_return_local(void)
{
int *y = ({
int x = 0;
&x;
});
return y;
}
[Bug c/45821] New: no warning when returning a local variable address within a statement expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45821 Summary: no warning when returning a local variable address within a statement expression Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gaul.org Created attachment 21904 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21904 example of bug GCC warns when returning a local variable address within a function but not within a statement expression.
[Bug target/45815] [4.6 Regression] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815 --- Comment #7 from Ian Lance Taylor 2010-09-28 17:14:04 UTC --- I'm sorry, I said options.h, but of course I meant options.c. Can you check options.c?
[Bug target/44452] gcc.target/i386/abi-2.c and gcc.target/i386/pr22076.c fail on 32-bit Solaris 10+/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44452 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.6.0 Resolution||FIXED Known to fail||4.4.5, 4.5.2 --- Comment #5 from Rainer Orth 2010-09-28 17:03:05 UTC --- Fixed for 4.6.0, backport inappropriate for 4.4 and 4.5 branches.
[Bug target/45815] [4.6 Regression] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815 --- Comment #6 from Dominique d'Humieres 2010-09-28 17:01:07 UTC --- > Dominique: yes, but flag_split_stack should be -1 going into that code, so the > effect of that should be to set flag_split_stack to 0. Can you confirm that > the generated file options.h was correctly regenerated in your build? It > should contain the lines > > /* Set by -fsplit-stack. >Generate discontiguous stack frames */ > int flag_split_stack = -1; It does not: [macbook] gcc/build_w% grep flag_split_stack *gcc/options.h gcc/options.h:extern int flag_split_stack; prev-gcc/options.h:extern int flag_split_stack; stage1-gcc/options.h:extern int flag_split_stack;
[Bug target/44452] gcc.target/i386/abi-2.c and gcc.target/i386/pr22076.c fail on 32-bit Solaris 10+/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44452 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-09/msg02190.htm ||l Last reconfirmed||2010.09.28 17:00:25 date|| Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #4 from Rainer Orth 2010-09-28 17:00:25 UTC --- Assign to self, patch above.
[Bug target/44452] gcc.target/i386/abi-2.c and gcc.target/i386/pr22076.c fail on 32-bit Solaris 10+/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44452 --- Comment #3 from Rainer Orth 2010-09-28 16:55:43 UTC --- Author: ro Date: Tue Sep 28 16:55:40 2010 New Revision: 164691 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164691 Log: PR target/44452 * gcc.target/i386/abi-2.c: XFAIL on i?86-*-solaris2* && ilp32. * gcc.target/i386/pr22076.c: Skip on i?86-solaris2* && ilp32. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/abi-2.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr22076.c
[Bug target/44452] gcc.target/i386/abi-2.c and gcc.target/i386/pr22076.c fail on 32-bit Solaris 10+/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44452 --- Comment #2 from Rainer Orth 2010-09-28 16:53:53 UTC --- Author: ro Date: Tue Sep 28 16:53:49 2010 New Revision: 164690 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164690 Log: PR target/44452 * gcc.target/i386/abi-2.c: XFAIL on i?86-*-solaris2* && ilp32. * gcc.target/i386/pr22076.c: Skip on i?86-solaris2* && ilp32. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/abi-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr22076.c
[Bug target/45817] __aeabi_uidiv broken when built with -Os (5/3 == 3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45817 enrico.scholz at informatik dot tu-chemnitz.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from enrico.scholz at informatik dot tu-chemnitz.de 2010-09-28 16:51:57 UTC --- closing
[Bug target/43999] Gcc (lib1funcs.asm) doesn't build on ARM/Thumb2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43999 enrico.scholz at informatik dot tu-chemnitz.de changed: What|Removed |Added CC||enrico.scholz at informatik ||dot tu-chemnitz.de --- Comment #7 from enrico.scholz at informatik dot tu-chemnitz.de 2010-09-28 16:50:10 UTC --- patch breaks non-thumb2 mode; see bug #45817
[Bug target/45817] __aeabi_uidiv broken when built with -Os (5/3 == 3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45817 --- Comment #2 from enrico.scholz at informatik dot tu-chemnitz.de 2010-09-28 16:49:57 UTC --- sorry; my fault. Caused by broken patch for #43999
[Bug web/45818] Missing message-ids in Bugzilla messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45818 Frédéric Buclin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.09.28 16:37:28 date|| Ever Confirmed|0 |1 --- Comment #1 from Frédéric Buclin 2010-09-28 16:37:28 UTC --- New bugs have e.g.: Message-ID: And additional comments and changes have: In-Reply-To: References: So you can still list bugs in threads correctly. But I agree that RFC 2822 recommends that *each* message has its own unique Message-ID, which we don't do here. I will report the bug upstream.
[Bug target/45815] [4.6 Regression] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815 --- Comment #5 from Ian Lance Taylor 2010-09-28 16:32:16 UTC --- Dominique: yes, but flag_split_stack should be -1 going into that code, so the effect of that should be to set flag_split_stack to 0. Can you confirm that the generated file options.h was correctly regenerated in your build? It should contain the lines /* Set by -fsplit-stack. Generate discontiguous stack frames */ int flag_split_stack = -1;
[Bug c/45819] [4.5 Regression] unexpected unaligned access to volatile int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45819
--- Comment #2 from Atsushi Nemoto 2010-09-28
16:26:17 UTC ---
(In reply to comment #1)
> (why use packed if the int is always aligned?)
The original problem was found with this structure in linux ehci_def.h:
struct ehci_caps {
u32hc_capbase;
u32hcs_params; /* HCSPARAMS - offset 0x4 */
u32hcc_params; /* HCCPARAMS - offset 0x8 */
u8portroute [8]; /* nibbles for routing - offset 0xC */
} __attribute__ ((packed));
In this case maybe the "packed" is not needed, but there will be other cases
which require "packed" attribute on struct for memory-mapped I/O.
[Bug target/45805] VFP/Neon double precision register expected -- `vmovl.s16 q2,s8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 --- Comment #5 from belagod at gcc dot gnu.org 2010-09-28 16:25:37 UTC --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > Created attachment 21897 [details] [details] [details] [details] > > > > Fix register specifier in instruction template for vmovl. > > > > > > I tried similar patch locally before submitting the bug (changed only > > > vmovl > > > pattern) > > > but I got an ICE which is again same I am getting with this patch too > > > > > > $ arm-none-linux-gnueabi-gcc-4.6.0 -mfloat-abi=softfp -mfpu=neon a.c -O3 > > > a.c: In function ‘try_8x8basis_c’: > > > a.c:14:1: internal compiler error: output_operand: invalid operand for > > > code 'P' > > > > That's strange. I'm not able to reproduce the ICE on my side with or without > > -mvectorize-with-neon-quad with this patch. I don't know if configuring to > > build for cortex-a9 has anything to do with this because that's what is on > > my > > side and you don't seem to have it configured to build for a cpu with NEON. > > Does the ICE happen if you specify -mcpu=cortex-a9 on the command-line? > > Also, > > are you using trunk's HEAD? > > with -mcpu=cortex-a9 it works without it gets the ICE. you can try > -mcpu=cortex-a8 it should ICE. Ah, now I can reproduce it. The rtl-trace shows that memory operands were being matched for the neon_unpack_ pattern inpsite of the 'register_operand' predicate. The constraint here needs a "w" which makes the ICE go away by matching register operands only and your example to compile fine. I've attached another patch.
[Bug target/44452] gcc.target/i386/abi-2.c and gcc.target/i386/pr22076.c fail on 32-bit Solaris 10+/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44452 --- Comment #1 from Rainer Orth 2010-09-28 16:24:17 UTC --- Author: ro Date: Tue Sep 28 16:24:11 2010 New Revision: 164687 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164687 Log: gcc/testsuite: PR target/44452 * gcc.target/i386/pr22076.c: Add -mno-vect8-ret-in-mem on i?86-*-solaris2.[89], *-*-vxworks*. * gcc.target/i386/pr22152.c: Likewise. * gcc.target/i386/vect8-ret.c: New test. gcc: PR target/44452 * config/i386/i386.opt (mvect8-ret-in-mem): Define. * config/i386/i386.c (ix86_target_string): Handle -mvect8-ret-in-mem. (ix86_solaris_return_in_memory): Remove. * config/i386/i386-protos.h (ix86_solaris_return_in_memory): Remove. * config/i386/sol2.h (SUBTARGET_RETURN_IN_MEMORY): Remove. (TARGET_SUBTARGET_DEFAULT): Redefine. * config/i386/sol2-10.h (TARGET_SUBTARGET_DEFAULT): Update comment. * config/i386/vx-common.h (SUBTARGET_RETURN_IN_MEMORY): Remove. (TARGET_SUBTARGET_DEFAULT): Redefine. * doc/invoke.texi (Option Summary, i386 and x86-64 Options): Add -mvect8-ret-in-mem. (i386 and x86-64 Options): Document -mvect8-ret-in-mem. Added: trunk/gcc/testsuite/gcc.target/i386/vect8-ret.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.opt trunk/gcc/config/i386/sol2-10.h trunk/gcc/config/i386/sol2.h trunk/gcc/config/i386/vx-common.h trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr22076.c trunk/gcc/testsuite/gcc.target/i386/pr22152.c
[Bug target/45815] [4.6 Regression] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
||med.uc.edu
--- Comment #4 from Jack Howarth 2010-09-28
16:20:31 UTC ---
(In reply to comment #3)
> > That shouldn't happen, because flag_split_stack is initialized to -1, and
> > you
> > should only see that error if flag_split_stack != -1 in decode_options. Can
> > you find out what is setting flag_split_stack to a value other than -1?
>
> In gcc/opts.c at lines 1092-1102, I see
>
> if (flag_split_stack == -1)
> flag_split_stack = 0;
> else
> {
> if (!targetm.supports_split_stack (true))
> {
> error ("%<-fsplit-stack%> is not supported by "
> "this compiler configuration");
> flag_split_stack = 0;
> }
> }
I can confirm on x86_64-apple-darwin that the section...
if (flag_split_stack == -1)
flag_split_stack = 0;
is being executed during the compilation of /gcc.dg/pr37106-1.c
[Bug target/45820] New: FAIL: gcc.c-torture/compile/pr45728.c at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45820
Summary: FAIL: gcc.c-torture/compile/pr45728.c at -O1 and above
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
Build: hppa64-hp-hpux11.11
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-
O1 -w -c -o pr45728.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr
45728.c(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr45728.c: In function
'fo
o':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr45728.c:17:1: error:
ins
n does not satisfy its constraints:
(insn 32 12 33 2 (set (reg/f:DI 31 %r31)
(plus:DI (reg:DI 27 %r27)
(high:DI (symbol_ref/u:DI ("*L$C") [flags 0x2]
/test/gnu/gcc
/gcc/gcc/testsuite/gcc.c-torture/compile/pr45728.c:16 84 {*pa.md:2562}
(nil))
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr45728.c:17:1: internal
c
ompiler error: in reload_cse_simplify_operands, at postreload.c:402
The insn doesn't satisfy its constraints because *L$C is a function label.
[Bug c/45819] [4.5 Regression] unexpected unaligned access to volatile int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45819
--- Comment #1 from Richard Guenther 2010-09-28
16:04:38 UTC ---
As a matter of clean implementation I suggest to do
struct st {
int ptr;
} __attribute__ ((packed,aligned(__alignof__(int;
(why use packed if the int is always aligned?)
[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704 --- Comment #7 from Atsushi Nemoto 2010-09-28 15:34:59 UTC --- (In reply to comment #6) > It should be as this is likely a problem with unaligned access > support. I think you can't generally expect unaligned volatile > accesses to work (on ia64 for example they certainly wouldn't). OK, filed as PR 45819. ARM linux kernel depends on this unaligned volatile access.
[Bug fortran/45756] Multiple DECL for array valued PARAMETER (-fwhole-file issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45756 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Burnus 2010-09-28 15:34:37 UTC --- FIXED for GCC 4.6.
[Bug fortran/45756] Multiple DECL for array valued PARAMETER (-fwhole-file issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45756 --- Comment #2 from Tobias Burnus 2010-09-28 15:34:01 UTC --- Author: burnus Date: Tue Sep 28 15:33:56 2010 New Revision: 164686 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164686 Log: 2010-09-28 Tobias Burnus PR fortran/45756 * trans-decl.c (gfc_get_symbol_decl): Use gsym for decl of module parameters. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612 --- Comment #12 from dave at hiauly1 dot hia.nrc.ca 2010-09-28 15:32:01 UTC --- > Hi, > I would really apprechiate the answer to comment #6. Since the patch should > only > introduce more (valid) inlining this must be latent bug somewhere In the hppa-hpux case, the label would have had to be a code label. The linker and dynamic loader don't support label differences between code and data symbols. This suggests that the change exposed an inlining bug that removed the symbol. I'll take a look on my next build. Dave
[Bug c/45819] New: [4.5 Regression] unexpected unaligned access to volatile int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45819
Summary: [4.5 Regression] unexpected unaligned access to
volatile int
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: an...@mba.ocn.ne.jp
An unexpected unaligned access instructions for volatile int are
generated on gcc 4.5 or 4.6 with this test case.
struct st {
int ptr;
} __attribute__ ((packed));
int foo(struct st *st)
{
int v = *(volatile int *)&st->ptr;
return v;
}
This test case is derived from something like this in ARM linux kernel.
struct st {
unsigned int ptr;
} __attribute__ ((packed));
unsigned int foo(struct st *st)
{
return readl(&st->ptr);
}
mipsel-linux-gcc-4.5.1 -O2 foo.c -S output:
lwl$2,3($4)
nop
lwr$2,0($4)
j$31
nop
arm-linux-gnueabi-gcc-4.5.1 -O2 foo.c -S output:
ldrbr3, [r0, #0]@ zero_extendqisi2
ldrbr1, [r0, #1]@ zero_extendqisi2
ldrbr2, [r0, #2]@ zero_extendqisi2
orrr3, r3, r1, asl #8
ldrbr0, [r0, #3]@ zero_extendqisi2
orrr3, r3, r2, asl #16
orrr0, r3, r0, asl #24
bxlr
It seems the cast is ignored and unaligned access is assumed.
gcc 4.4.4 works fine.
mipsel-linux-gcc-4.4.4 -O2 foo.c -S output:
lw$2,0($4)
j$31
nop
arm-linux-gnueabi-gcc-4.4.4 -O2 foo.c -S output:
ldrr0, [r0, #0]
bxlr
The similar problem was found as PR 45704.
git-bisect tell me same commit
0d9f1189f3df5ce5c0efc3ecadc7c0a4f75b202d is the first bad commit.
Like PR 45704, reverting this change fixes this problme too.
- STRIP_USELESS_TYPE_CONVERSION (sub);
+ STRIP_NOPS (sub);
But the final fix for PR 45704 does not fix this problem.
mipsel-linux-gcc (4.6.0 20100927):
lbu$5,0($4)
lbu$6,1($4)
lbu$3,2($4)
andi$6,$6,0x00ff
lbu$2,3($4)
andi$5,$5,0x00ff
sll$6,$6,8
andi$3,$3,0x00ff
or$4,$6,$5
sll$3,$3,16
or$3,$3,$4
sll$2,$2,24
j$31
or$2,$2,$3
arm-linux-gnueabi-gcc (4.6.0 20100927):
ldrbr3, [r0, #0]@ zero_extendqisi2
ldrbr1, [r0, #1]@ zero_extendqisi2
ldrbr2, [r0, #2]@ zero_extendqisi2
orrr3, r3, r1, asl #8
ldrbr0, [r0, #3]@ zero_extendqisi2
orrr3, r3, r2, asl #16
orrr0, r3, r0, asl #24
bxlr
[Bug web/45818] New: Missing message-ids in Bugzilla messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45818 Summary: Missing message-ids in Bugzilla messages Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: js...@gcc.gnu.org CC: lpso...@netscape.net It appears that messages generated by the new Bugzilla only have a Message-ID header if they are messages for new bugs, not for comments. This breaks at least the "Raw text" links in the gcc-bugs list archives. I don't think it matters much what the message-ids are as long as they are unique, but Bugzilla should generate them rather than leaving this to some downstream MTA.
[Bug target/45807] Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45807 --- Comment #2 from Alan Modra 2010-09-28 15:25:08 UTC --- Author: amodra Date: Tue Sep 28 15:25:03 2010 New Revision: 164685 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164685 Log: PR target/45807 * config/rs6000/aix.h (SETUP_FRAME_ADDRESSES): Delete. * config/rs6000/linux64.h (SETUP_FRAME_ADDRESSES): Delete. * config/rs6000/rs6000-protos.h (rs6000_aix_emit_builtin_unwind_init): Delete. * config/rs6000/rs6000.c (rs6000_aix_emit_builtin_unwind_init): Delete. (rs6000_emit_prologue): Don't just create frame save info for r2, actually save r2. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/aix.h trunk/gcc/config/rs6000/linux64.h trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c
[Bug target/45805] VFP/Neon double precision register expected -- `vmovl.s16 q2,s8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 --- Comment #4 from Khem Raj 2010-09-28 15:22:53 UTC --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Created attachment 21897 [details] [details] [details] > > > Fix register specifier in instruction template for vmovl. > > > > I tried similar patch locally before submitting the bug (changed only vmovl > > pattern) > > but I got an ICE which is again same I am getting with this patch too > > > > $ arm-none-linux-gnueabi-gcc-4.6.0 -mfloat-abi=softfp -mfpu=neon a.c -O3 > > a.c: In function ‘try_8x8basis_c’: > > a.c:14:1: internal compiler error: output_operand: invalid operand for code > > 'P' > > That's strange. I'm not able to reproduce the ICE on my side with or without > -mvectorize-with-neon-quad with this patch. I don't know if configuring to > build for cortex-a9 has anything to do with this because that's what is on my > side and you don't seem to have it configured to build for a cpu with NEON. > Does the ICE happen if you specify -mcpu=cortex-a9 on the command-line? Also, > are you using trunk's HEAD? with -mcpu=cortex-a9 it works without it gets the ICE. you can try -mcpu=cortex-a8 it should ICE.
[Bug target/45815] [4.6 Regression] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815
--- Comment #3 from Dominique d'Humieres 2010-09-28
15:19:29 UTC ---
> That shouldn't happen, because flag_split_stack is initialized to -1, and you
> should only see that error if flag_split_stack != -1 in decode_options. Can
> you find out what is setting flag_split_stack to a value other than -1?
In gcc/opts.c at lines 1092-1102, I see
if (flag_split_stack == -1)
flag_split_stack = 0;
else
{
if (!targetm.supports_split_stack (true))
{
error ("%<-fsplit-stack%> is not supported by "
"this compiler configuration");
flag_split_stack = 0;
}
}
[Bug target/45815] [4.6 Regression] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #2 from Ian Lance Taylor 2010-09-28 15:09:07 UTC --- That shouldn't happen, because flag_split_stack is initialized to -1, and you should only see that error if flag_split_stack != -1 in decode_options. Can you find out what is setting flag_split_stack to a value other than -1?
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #8 from Tobias Burnus 2010-09-28 14:57:34 UTC --- Using -fno-inline-functions, the program recovers the speed of the no-LTO version. Notes from #gcc: (dominiq) For fatigue the key for speed-up is inlining of generalized_hookes_law and you need -finline-limit=400 (richi) "Considering inline candidate generalized_hookes_law." / "Inlining failed: --param max-inline-insns-auto limit reached"
[Bug target/45817] __aeabi_uidiv broken when built with -Os (5/3 == 3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45817 Andrew Pinski changed: What|Removed |Added Component|c |target Severity|critical|normal
[Bug target/45815] [4.6 Regression] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815 Andrew Pinski changed: What|Removed |Added Target|x86_64-apple-darwin10.4.0 |*-darwin10.4.0 Component|c |target Host|x86_64-apple-darwin10.4.0 | Target Milestone|--- |4.6.0 Summary|error: '-fsplit-stack' |[4.6 Regression] error: |currently only supported on |'-fsplit-stack' currently |GNU/Linux |only supported on GNU/Linux Build|x86_64-apple-darwin10.4.0 | Severity|normal |major
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #7 from Joost VandeVondele 2010-09-28 14:19:38 UTC --- (In reply to comment #6) > No, -fdump-tree-all works great... I forgot to look in /tmp, and -save-temps also works fine.
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #6 from Richard Guenther 2010-09-28 14:07:54 UTC --- (In reply to comment #5) > (In reply to comment #4) > > Sure. As with all performance related bugs this needs analysis and is > > unlikely an "LTO" problem - LTO does not (not-)optimize, optimization > > passes do. > > I'm wondering if there is any description on how to do this. For example, how > do I get the assembly of a function and the -fdump-tree-all files from a gold > based linking that goes as: > > rm -f test.s test2.s test.o test2.o ; > gfortran -c -flto test.f90 ; > gfortran -c -flto test2.f90 ; > gfortran -O3 -march=native -fuse-linker-plugin -fwhopr=2 test.o test2.o > > just using -S or -fdump-tree-all doesn't work. > > Is 'objdump -d' the only tool ? No, -fdump-tree-all works, it just uses maybe un-intuitive base-names. Append -v to see them, for -fwhopr it should be the output file specified with -o (which you leave out which causes us to use not a.out but some temporary file in /tmp), with -o t I get t.ltrans[01].147t.optimized, etc. With -flto it's just t.147t.optimized. To retain assembler you have to use -save-temps which retains t.ltrans[01].s, with -flto it retains t1.s (using the base of the first object file).
[Bug java/40816] error: 'jvariant::jvariant(jbyte)' cannot be overloaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40816 Andrew Haley changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Andrew Haley 2010-09-28 14:05:59 UTC --- .
[Bug java/45773] gcj fails to compile java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45773 Andrew Haley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #21 from Andrew Haley 2010-09-28 14:03:25 UTC --- .
[Bug middle-end/44554] Stack space after sigsetjmp is reused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #16 from Bernd Schmidt 2010-09-28 14:00:30 UTC --- Argh, wrong PR. I wanted 45445.
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #5 from Joost VandeVondele 2010-09-28 13:58:18 UTC --- (In reply to comment #4) > Sure. As with all performance related bugs this needs analysis and is > unlikely an "LTO" problem - LTO does not (not-)optimize, optimization > passes do. I'm wondering if there is any description on how to do this. For example, how do I get the assembly of a function and the -fdump-tree-all files from a gold based linking that goes as: rm -f test.s test2.s test.o test2.o ; gfortran -c -flto test.f90 ; gfortran -c -flto test2.f90 ; gfortran -O3 -march=native -fuse-linker-plugin -fwhopr=2 test.o test2.o just using -S or -fdump-tree-all doesn't work. Is 'objdump -d' the only tool ?
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #4 from Richard Guenther 2010-09-28 13:38:58 UTC --- (In reply to comment #3) > (In reply to comment #2) > > For single-file programs -fwhole-program and -flto should be basically > > equivalent if the Frontend provides correctly merged decls. I suppose > > it does not and thus we do less inlining with -fwhole-program compared > > to -flto. > > It might well be the reason that one does less inlining without LTO - but more inlining with LTO. You read my stmt wrong. > that's then not only a FE bug (not correctly merged decls) but also a > ME/target > bug as the LTO program is _slower_. Sure. As with all performance related bugs this needs analysis and is unlikely an "LTO" problem - LTO does not (not-)optimize, optimization passes do. > > Cf. also PR 44334, which is about a -fwhole-program slowdown (w/ and w/o > -flto). For the latter program, it helped to use "--param > hot-bb-frequency-fraction=2000". However, for this PR, the option does not > seem > to help.
[Bug rtl-optimization/45570] [4.6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4584
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45570
Andrey Belevantsev changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.09.28 13:23:13
date||
Ever Confirmed|0 |1
--- Comment #3 from Andrey Belevantsev 2010-09-28
13:23:13 UTC ---
Confirmed. It is hidden now by 163998.
The problem is simple, yet again when inserting a bookkeeping code together
with pipelining outer loops, we can see the situation when we need to devise a
positive seqno for a bookkeeping insn, yet we can't do that by examining its
neighbours. Fixed by relaxing the failing assert so that the first patch for
PR40101 would provide an arbitrary positive value.
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 853205d..8a88c55 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -4580,8 +4580,12 @@ cfg_preds_1 (basic_block bb, insn_t **preds, int *n, int
*size)
basic_block pred_bb = e->src;
insn_t bb_end = BB_END (pred_bb);
- /* ??? This code is not supposed to walk out of a region. */
- gcc_assert (in_current_region_p (pred_bb));
+ if (!in_current_region_p (pred_bb))
+{
+ gcc_assert (flag_sel_sched_pipelining_outer_loops
+ && current_loop_nest);
+ continue;
+}
if (sel_bb_empty_p (pred_bb))
cfg_preds_1 (pred_bb, preds, n, size);
@@ -4594,7 +4598,9 @@ cfg_preds_1 (basic_block bb, insn_t **preds, int *n, int
*size)
}
}
- gcc_assert (*n != 0);
+ gcc_assert (*n != 0
+ || (flag_sel_sched_pipelining_outer_loops
+ && current_loop_nest));
}
/* Find all predecessors of BB and record them in PREDS and their number
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612 --- Comment #11 from Eric Botcazou 2010-09-28 12:34:28 UTC --- > Eric, Olivier, > > could you please have a look at Jan's question in Comment #6? This bug > currently breaks Ada bootstrap on Solaris 2/SPARC and hampers my Solaris > testing. Sorry, I won't really have time to look into this before a couple of weeks. The GCC Compile Farm has several SPARC/Linux boxes with pre-built Ada compilers.
[Bug c/45817] __aeabi_uidiv broken when built with -Os (5/3 == 3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45817 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2010-09-28 12:25:22 UTC --- It appears to be --enable-target-optspace that's broken, not -Os. With --enable-target-optspace lib1funcs.asm is compiled with __OPTIMIZE_SIZE__, which selects a different definition for the ARM_DIV_BODY macro than the default one. It seems the other definition is broken for this case. Without --enable-target-optspace I get the correct result (1) with 4.4/4.5/4.6.
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 Tobias Burnus changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Tobias Burnus 2010-09-28 12:23:06 UTC --- (In reply to comment #2) > For single-file programs -fwhole-program and -flto should be basically > equivalent if the Frontend provides correctly merged decls. I suppose > it does not and thus we do less inlining with -fwhole-program compared > to -flto. It might well be the reason that one does less inlining without LTO - but that's then not only a FE bug (not correctly merged decls) but also a ME/target bug as the LTO program is _slower_. Cf. also PR 44334, which is about a -fwhole-program slowdown (w/ and w/o -flto). For the latter program, it helped to use "--param hot-bb-frequency-fraction=2000". However, for this PR, the option does not seem to help.
[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45658 --- Comment #6 from Jan Hubicka 2010-09-28 12:16:53 UTC --- I think I will just commit it as the patch fixes known problems anyway and let you know then. If it won't help in this case, it is not difficult to make patch to dump folding that happens with initializers that mis the TREE_STATIC bit and we can figure out if the problem is caused by Ada frontend putting something weird into the constructor. There was related problem with C++ vtable constructors having references to static variables from other compilation unit, so it is quite posible that it is FE<->BE interface issue, too. I wonder if it is possible to get this into self contained testcase - I will try to reproduce problem at compile farm, I think it has sparc machine there. Honza
[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45658 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2010-09-28 12:13:01 UTC --- Fine, thanks. Let me know if you need Solaris/SPARC testing before commit.
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612 Rainer Orth changed: What|Removed |Added CC||hainque at gcc dot gnu.org --- Comment #10 from Rainer Orth 2010-09-28 12:11:35 UTC --- Eric, Olivier, could you please have a look at Jan's question in Comment #6? This bug currently breaks Ada bootstrap on Solaris 2/SPARC and hampers my Solaris testing. Thanks, Rainer
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612 --- Comment #9 from Jan Hubicka 2010-09-28 12:07:54 UTC --- Hi, I would really apprechiate the answer to comment #6. Since the patch should only introduce more (valid) inlining this must be latent bug somewhere Honza
[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45658 --- Comment #4 from Jan Hubicka 2010-09-28 12:06:39 UTC --- Hi, the contant folding in tree-ssa-ccp has several bugs in it concerning to arrays with non-0 low bounds. This happens in Ada and fortran and since fortran produces array constructors that the code confuses in a way that we don't fold most of time, Ada is probably only one affected. I rewrote the code but the patch took a while to settle since it is quite touchy area. I am just doing final testing and will commit it shortly. Hopefully it will fix both the problems. If not, we need to figure out what Ada does special about static constructors - this would seem more like a frontend bug. Honza
[Bug c/45817] New: __aeabi_uidiv broken when built with -Os (5/3 == 3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45817
Summary: __aeabi_uidiv broken when built with -Os (5/3 == 3)
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: enrico.sch...@informatik.tu-chemnitz.de
int main(int argc, char *argv[])
{
unsigned int volatilea = 5;
unsigned int volatileb = 3;
__asm__ __volatile__("" ::: "memory");
return a/b;
}
$ arm-linux-gnueabi-gcc -O0 m.c
---
# /a.out ; echo $?
3
Implementation of uidiv in gcc/config/arm/lib1funcs.asm differs depending on
the -Os flag (which is used by me) and issue might be missed by regression
tests which were run with non -Os compilers.
--
$ LANG=C arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/libexec/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper
Target: arm-linux-gnueabi
Configured with:
/srv/projects/elito-ref/COLIBRI270/tmp/work/armv5te-linux-gnueabi/gcc-cross-4.5-r1+svnr163322/gcc-4.5/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-linux-gnueabi
--prefix=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te
--exec_prefix=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te
--bindir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/bin
--sbindir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/bin
--libexecdir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/libexec
--datadir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/share
--sysconfdir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/etc
--sharedstatedir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/com
--localstatedir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/var
--libdir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/lib
--includedir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/include
--oldincludedir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/include
--infodir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/share/info
--mandir=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/share/man
--with-gnu-ld --enable-shared --enable-languages=c,c++,objc
--enable-threads=posix --disable-multilib --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-linux-gnueabi-
--enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap
--disable-libgomp --disable-libmudflap --with-abi=aapcs-linux --with-float=soft
--with-sysroot=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/armv5te-linux-gnueabi
--with-build-sysroot=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/armv5te-linux-gnueabi
--with-build-time-tools=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr/armv5te/bin
--disable-libunwind-exceptions
--with-mpfr=/srv/projects/elito-ref/COLIBRI270/tmp/sysroots/x86_64-linux/usr
--with-system-zlib --program-prefix=arm-linux-gnueabi- --enable-__cxa_atexit
Thread model: posix
gcc version 4.5.2 20100818 (prerelease) (GCC)
[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352
--- Comment #7 from Andrey Belevantsev 2010-09-28
11:47:33 UTC ---
Thanks for the test, it shows one more case of using issue_rate that I have
missed. We need to distinguish between the stalls caused by data dependencies
and by lack of functional units, i.e. DFA related stalls. This is because when
resetting the cycles, we know that the latter should remain as is (which is
actually is checked by the failing assert) but not the former. Fixed by
allowing need_stall to be negative and handling this situation in
stall_for_cycles. This again fixes all tests with all option combinations.
Zdenek, if you can, please test this in your environment, and I will check ia64
and possibly ppc/ppc64, because with this kind of patch I need to make sure
that other (honest) targets are unaffected.
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 041c471..5bf0e19 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -4051,10 +4051,11 @@ sel_dfa_new_cycle (insn_t insn, fence_t fence)
/* Invoke reorder* target hooks on the ready list. Return the number of insns
we can issue. FENCE is the current fence. */
static int
-invoke_reorder_hooks (fence_t fence)
+invoke_reorder_hooks (fence_t fence, bool *pran_hook)
{
int issue_more;
- bool ran_hook = false;
+
+ *pran_hook = false;
/* Call the reorder hook at the beginning of the cycle, and call
the reorder2 hook in the middle of the cycle. */
@@ -4077,7 +4078,7 @@ invoke_reorder_hooks (fence_t fence)
if (pipelining_p)
++ready.n_ready;
- ran_hook = true;
+ *pran_hook = true;
}
else
/* Initialize can_issue_more for variable_issue. */
@@ -4106,14 +4107,14 @@ invoke_reorder_hooks (fence_t fence)
++ready.n_ready;
}
- ran_hook = true;
+ *pran_hook = true;
}
else
issue_more = FENCE_ISSUE_MORE (fence);
/* Ensure that ready list and vec_av_set are in line with each other,
i.e. vec_av_set[i] == ready_element (&ready, i). */
- if (issue_more && ran_hook)
+ if (issue_more && *pran_hook)
{
int i, j, n;
rtx *arr = ready.vec;
@@ -4313,7 +4314,7 @@ get_expr_cost (expr_t expr, fence_t fence)
/* Find the best insn for scheduling, either via max_issue or just take
the most prioritized available. */
static int
-choose_best_insn (fence_t fence, int privileged_n, int *index)
+choose_best_insn (fence_t fence, int privileged_n, bool ran_hook, int *index)
{
int can_issue = 0;
@@ -4338,6 +4339,8 @@ choose_best_insn (fence_t fence, int privileged_n, int
*index)
if (get_expr_cost (expr, fence) < 1)
{
can_issue = can_issue_more;
+ if (!ran_hook && !can_issue)
+can_issue = 1;
*index = i;
if (sched_verbose >= 2)
@@ -4360,12 +4363,15 @@ choose_best_insn (fence_t fence, int privileged_n, int
*index)
/* Choose the best expr from *AV_VLIW_PTR and a suitable register for it.
BNDS and FENCE are current boundaries and scheduling fence respectively.
Return the expr found and NULL if nothing can be issued atm.
- Write to PNEED_STALL the number of cycles to stall if no expr was found.
*/
+ Write to PNEED_STALL the number of cycles to stall if no expr was found.
+ The positive number of cycles means a data dependency stall, while
+ the negative one means a functional stall (DFA stall). */
static expr_t
find_best_expr (av_set_t *av_vliw_ptr, blist_t bnds, fence_t fence,
int *pneed_stall)
{
expr_t best;
+ bool ran_hook;
/* Choose the best insn for scheduling via:
1) sorting the ready list based on priority;
@@ -4376,8 +4382,8 @@ find_best_expr (av_set_t *av_vliw_ptr, blist_t bnds,
fence_t fence,
{
int privileged_n, index;
- can_issue_more = invoke_reorder_hooks (fence);
- if (can_issue_more > 0)
+ can_issue_more = invoke_reorder_hooks (fence, &ran_hook);
+ if (can_issue_more > 0 || !ran_hook)
{
/* Try choosing the best insn until we find one that is could be
scheduled due to liveness restrictions on its destination
register.
@@ -4385,7 +4391,7 @@ find_best_expr (av_set_t *av_vliw_ptr, blist_t bnds,
fence_t fence,
in the order of their priority. */
invoke_dfa_lookahead_guard ();
privileged_n = calculate_privileged_insns ();
- can_issue_more = choose_best_insn (fence, privileged_n, &index);
+ can_issue_more = choose_best_insn (fence, privileged_n, ran_hook,
&index);
if (can_issue_more)
best = find_expr_for_ready (index, true);
}
@@ -4394,7 +4400,7 @@ find_best_expr (av_set_t *av_vliw_ptr, blist_t bnds,
fence_t fence,
if (can_issue_more == 0)
{
best = NULL;
- *pneed_stall = 1;
+ *pneed_stall = -1;
}
}
@@ -4402,8 +4408,9 @@ find_best_expr (av_set_t *av_vliw_ptr
[Bug bootstrap/45816] New: [4.6 Regression] Bootstrap comparison failure! for powerpc-apple-darwin9 with --enable-checking=release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45816 Summary: [4.6 Regression] Bootstrap comparison failure! for powerpc-apple-darwin9 with --enable-checking=release Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ber...@codesourcery.com Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 Since revision 164552: Author:bernds Date:Thu Sep 23 10:04:33 2010 UTC (5 days, 1 hour ago) Changed paths:14 Log Message: PR rtl-optimization/44374 * basic-block.h (enum bb_flags): Add BB_MODIFIED. * df-core.c (df_set_bb_dirty): Set it. * ifcvt.c (find_memory): Remove function. (dead_or_predicable): Use can_move_insns_across. * df.h (can_move_insns_across): Declare function. * cfgcleanup.c (block_was_dirty): New static variable. (try_crossjump_bb, try_forward_edges): Test BB_MODIFIED flag rather than df_get_bb_dirty. (try_head_merge_bb): New static function. (try_optimize_cfg): Call it. Call df_analyze if block_was_dirty is set. * df-problems.c: Include "target.h" (df_simulate_find_uses): New static function. (MEMREF_NORMAL, MEMREF_VOLATILE): New macros. (find_memory, find_memory_store): New static functions. (can_move_insns_across): New function. * Makefile.in (df-problems.o): Update dependencies. testsuite/ PR rtl-optimization/44374 * gcc.target/arm/headmerge-1.c: New test. * gcc.target/arm/headmerge-2.c: New test. * gcc.target/i386/headmerge-1.c: New test. * gcc.target/i386/headmerge-2.c: New test. bootstrapping powerpc-apple-darwin9 fails with ... rm -f stage_current Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/cfghooks.o differs make[2]: *** [compare] Error 1 make[1]: *** [stage3-bubble] Error 2 make: *** [all] Error 2 Reverting this commit allows bootstrap to complete Using built-in specs. COLLECT_GCC=/opt/gcc/gcc4.6w-rel/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6w-rel/libexec/gcc/powerpc-apple-darwin9/4.6.0/lto-wrapper Target: powerpc-apple-darwin9 Configured with: ../gcc-4.6-work/configure --prefix=/opt/gcc/gcc4.6w-rel --target=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --build=powerpc-apple-darwin9 --enable-languages=c,fortran,lto --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-cloog=/sw --enable-checking=release Thread model: posix gcc version 4.6.0 20100927 (experimental) [trunk revision 164648r2] (GCC) This does not occurs for x86_64-apple-darwin10.4 nor without --enable-checking=release Using built-in specs. COLLECT_GCC=gfc COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6w/libexec/gcc/powerpc-apple-darwin9/4.6.0/lto-wrapper Target: powerpc-apple-darwin9 Configured with: ../gcc-4.6-work/configure --prefix=/opt/gcc/gcc4.6w --target=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --build=powerpc-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java,lto --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-cloog=/sw Thread model: posix gcc version 4.6.0 20100927 (experimental) [trunk revision 164648r1] (GCC)
[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson 2010-09-28 11:24:18 UTC --- I can't reproduce this with a freshly-built vanilla 4.4.4 for arm-linux-gnueabi. Please tell us (a) exactly how your compiler was configured, and (b) exactly how you invoked it on the test case.
[Bug middle-end/44554] Stack space after sigsetjmp is reused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554 --- Comment #15 from Christian Eggers 2010-09-28 11:01:05 UTC --- (In reply to comment #14) > Created attachment 21901 [details] > A patch that should fix it > > Please verify whether this fixes it. Hasn't it already been fixed in comment #11? My plan was to wait until release of gcc-4.4.5 and test then. Are additional changes required to fix this bug?
[Bug target/45805] VFP/Neon double precision register expected -- `vmovl.s16 q2,s8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 --- Comment #3 from belagod at gcc dot gnu.org 2010-09-28 10:58:31 UTC --- (In reply to comment #2) > (In reply to comment #1) > > Created attachment 21897 [details] [details] > > Fix register specifier in instruction template for vmovl. > > I tried similar patch locally before submitting the bug (changed only vmovl > pattern) > but I got an ICE which is again same I am getting with this patch too > > $ arm-none-linux-gnueabi-gcc-4.6.0 -mfloat-abi=softfp -mfpu=neon a.c -O3 > a.c: In function ‘try_8x8basis_c’: > a.c:14:1: internal compiler error: output_operand: invalid operand for code > 'P' That's strange. I'm not able to reproduce the ICE on my side with or without -mvectorize-with-neon-quad with this patch. I don't know if configuring to build for cortex-a9 has anything to do with this because that's what is on my side and you don't seem to have it configured to build for a cpu with NEON. Does the ICE happen if you specify -mcpu=cortex-a9 on the command-line? Also, are you using trunk's HEAD?
[Bug c/45815] error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815 --- Comment #1 from Dominique d'Humieres 2010-09-28 10:06:58 UTC --- Forgot the -v output: [macbook] f90/bug% gcc46 -c -v /opt/gcc/work/gcc/testsuite/gcc.dg/pr37106-1.c Using built-in specs. COLLECT_GCC=gcc46 COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.4.0 Configured with: ../work/configure --prefix=/opt/gcc/gcc4.6w --enable-languages=c,c++,fortran,objc,obj-c++,java,lto --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64 --with-quad=/opt/sw64 Thread model: posix gcc version 4.6.0 20100928 (experimental) [trunk revision 164677p2] (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-c' '-v' '-mtune=generic' /opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/cc1 -quiet -v -D__DYNAMIC__ /opt/gcc/work/gcc/testsuite/gcc.dg/pr37106-1.c -fPIC -quiet -dumpbase pr37106-1.c -mmacosx-version-min=10.6.4 -mtune=generic -auxbase pr37106-1 -version -o /var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//ccx5QAEF.s GNU C (GCC) version 4.6.0 20100928 (experimental) [trunk revision 164677p2] (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100928 (experimental) [trunk revision 164677p2], GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/opt/gcc/gcc4.6w/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/../../../../x86_64-apple-darwin10.4.0/include" #include "..." search starts here: #include <...> search starts here: /opt/gcc/gcc4.6w/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/include /opt/gcc/gcc4.6w/include /opt/gcc/gcc4.6w/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C (GCC) version 4.6.0 20100928 (experimental) [trunk revision 164677p2] (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100928 (experimental) [trunk revision 164677p2], GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: bc8bd9f4043af97e1ce3a30f0eb920c8 /opt/gcc/work/gcc/testsuite/gcc.dg/pr37106-1.c:9:1: error: '-fsplit-stack' currently only supported on GNU/Linux /opt/gcc/work/gcc/testsuite/gcc.dg/pr37106-1.c:9:1: error: '-fsplit-stack' is not supported by this compiler configuration
[Bug c/45815] New: error: '-fsplit-stack' currently only supported on GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45815 Summary: error: '-fsplit-stack' currently only supported on GNU/Linux Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: i...@google.com Host: x86_64-apple-darwin10.4.0 Target: x86_64-apple-darwin10.4.0 Build: x86_64-apple-darwin10.4.0 On x86_64-apple-darwin10.4.0 at revision 164677 I see several errors in the test suite of the kind: [macbook] f90/bug% gcc46 -c /opt/gcc/work/gcc/testsuite/gcc.dg/pr37106-1.c /opt/gcc/work/gcc/testsuite/gcc.dg/pr37106-1.c:9:1: error: '-fsplit-stack' currently only supported on GNU/Linux /opt/gcc/work/gcc/testsuite/gcc.dg/pr37106-1.c:9:1: error: '-fsplit-stack' is not supported by this compiler configuration >From where this '-fsplit-stack' is coming?
[Bug java/45773] gcj fails to compile java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45773 --- Comment #20 from Andrew Haley 2010-09-28 09:54:30 UTC --- Author: aph Date: Tue Sep 28 09:54:27 2010 New Revision: 164679 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164679 Log: 2010-09-27 Andrew Haley PR java/45773 * jvgenmain.c (main): Fix arg processing. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/jvgenmain.c
[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2010.09.28 09:17:33
date||
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther 2010-09-28
09:17:33 UTC ---
I can't reproduce this on x86_64-linux with GCC 4.4.4 and -O2 (what options
did you use?). A cross to arm I still have around for GCC 4.5.0 also doesn't
show the problem.
I used
unsigned short ReadLE16U ( volatile unsigned char *pmem)
{
unsigned short val;
unsigned char *bytes = (unsigned char *)&val;
bytes[0] = pmem[0];
bytes[1] = pmem[1];
return val;
}
if that is not enough to reproduce the problem please provide
complete preprocessed source that can be compiled.
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at pci ||dot uzh.ch --- Comment #9 from Joost VandeVondele 2010-09-28 08:38:52 UTC --- this is nice... can this be used in an initialization expression ? MODULE X CHARACTER(LEN=100), PARAMETER :: module_compile_info=compiler_version()//compiler_options() END MODULE
[Bug other/45808] FreeBSD: -pthread is handled incompletely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45808 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez 2010-09-28 08:28:07 UTC --- (In reply to comment #3) > > (In reply to comment #2) > > Patches should be posted to gcc-patc...@gcc.gnu.org > > And, in fact, I did that a (short?) while ago: > http://thread.gmane.org/gmane.comp.gcc.patches/217482/focus=217484 > But it seems that nobody has picked it so far. > Perhaps I am the one to blame for that given the incorrect attachments. http://gcc.gnu.org/contribute.html If you do not receive a response to a patch that you have submitted within two weeks or so, it may be a good idea to chase it by sending a follow-up email to the same list(s). Patches can occasionally fall through the cracks. Please be sure to include a brief summary of the patch and the URL of the entry in the mailing list archive of the original submission. If you do not have write access and a patch of yours has been approved, but not committed, please advise the approver of that fact. You may want to point out lack of write access in your initial submission, too. And point 6 here: http://gcc.gnu.org/wiki/GCC_Research
[Bug fortran/40568] F2008: C_SIZEOF rejected as initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568 --- Comment #8 from Tobias Burnus 2010-09-28 07:44:13 UTC --- And expr.c's check_inquiry needs to be updated. I think except for some F95 vs. newer checks, most items should be handled via flags in add_symbol (intrinsic.c) as one easily forgets to update that file ...
