[Bug bootstrap/45796] New: make targets info-gcc, dvi-gcc etc. should work from unbuilt configured tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45796 Summary: make targets info-gcc, dvi-gcc etc. should work from unbuilt configured tree Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: rw...@gcc.gnu.org Running configure and then 'make info-gcc' currently fails with: make[1]: Entering directory `/tmp/build/gcc' make[1]: Circular s-tm-texi - ../../gcc/gcc/doc/tm.texi dependency dropped. build/genhooks \ ../../gcc/gcc/doc/tm.texi.in tmp-tm.texi /bin/sh: line 1: build/genhooks: No such file or directory make[1]: *** [s-tm-texi] Error 127 It should not be necessary to 'make all' before this. Likewise for the other toplevel doc targets.
[Bug bootstrap/35855] build locale not properly handled with awk scripts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35855 --- Comment #2 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-26 06:07:56 UTC --- Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02027.html. You don't state how exactly the build fails, and what locale you needed to set for the failure to become apparent. That makes it harder to find out whether a patch fixes it. Please state so, and also please try out the patch. Thanks.
[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 --- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-09-26 07:33:13 UTC --- (In reply to comment #2) It is very likely a duplicate of pr45783. The code compiles at r164549
[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793 --- Comment #7 from Kazumoto Kojima kkojima at gcc dot gnu.org 2010-09-26 07:41:39 UTC --- (In reply to comment #6) does this patch fix the problem for you? Yes. I've confirmed that all fortran regressions on sh4-unknown-linux-gnu go away with your patch in #5.
[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 --- Comment #4 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-09-26 07:43:51 UTC --- (In reply to comment #3) (In reply to comment #2) It is very likely a duplicate of pr45783. The code compiles at r164549 and fails at r164550
[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-26 07:49:34 UTC --- (In reply to comment #3) When building f951, there was a warning ../trunk/gcc/fortran/module.c: In function 'create_int_parameter_array': ../trunk/gcc/fortran/module.c:5346: warning: 'e' may be used uninitialized in this function I have never quite understood when -Werror is effective and when not! (In reply to comment #5) This patch untested gets rid of the valgrind error I was seeing. @@ -5342,8 +5341,8 @@ create_int_parameter_array (const char *name, int sym-as-upper[0] = gfc_get_int_expr (gfc_default_integer_kind, NULL, size); sym-value = value; - e-shape = gfc_get_shape (1); - mpz_init_set_ui (e-shape[0], size); + sym-value-shape = gfc_get_shape (1); + mpz_init_set_ui (sym-value-shape[0], size); } The patch is obvious and OK for committal. Thanks for fixing this stupid copy-and-paste bug of mine!
[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 Daniel Kraft domob at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.26 08:04:08 date|| CC||domob at gcc dot gnu.org AssignedTo|unassigned at gcc dot |domob at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #5 from Daniel Kraft domob at gcc dot gnu.org 2010-09-26 08:04:08 UTC --- Confirmed. I do not yet see how this is related to my commit, but will look into it of course. Thanks for the report!
[Bug fortran/45783] [4.6 Regression] ICE in gfc_add_component_ref, at fortran/class.c:77
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45783 Daniel Kraft domob at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.26 08:05:10 date|| CC||domob at gcc dot gnu.org AssignedTo|unassigned at gcc dot |domob at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Daniel Kraft domob at gcc dot gnu.org 2010-09-26 08:05:10 UTC --- Taking this also, when working on PR 45795.
[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081 --- Comment #13 from Paul Thomas pault at gcc dot gnu.org 2010-09-26 09:04:38 UTC --- I'll do 4.4 and 4.3 when I get back to Barcelona on Tuesday night. Paul
[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 --- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-09-26 10:27:41 UTC --- (In reply to comment #5) Confirmed. I do not yet see how this is related to my commit, but will look into it of course. Thanks for the report! Well, considering how many times I have been burned by things that should not have anything to do with, it was relatively easy to home in onto the only change in recent days that had touched SELECT TYPE :-) As I read somewhere Interesting problems prove their worth by biting back Salvatore
[Bug fortran/45797] New: ICE (segfault) with gfortran.dg/derived_constr_func_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45797 Summary: ICE (segfault) with gfortran.dg/derived_constr_func_1.f90 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The ICE is in the following line of gfc_use_derived if (sym-components != NULL || sym-attr.zero_comp) valgrind outputs the following. I checked with GCC 4.4 and 4.5 that those also ICE. [...] gfortran.dg/derived_constr_func_1.f90:14.11: type(foo) function constructor() 1 Error: PROCEDURE attribute of 'foo' conflicts with DERIVED attribute at (1) ==27731== Invalid read of size 8 ==27731==at 0x549D99: gfc_use_derived (symbol.c:1934) ==27731==by 0x5214FA: match_variable (primary.c:3043) ==27731==by 0x5062E4: gfc_match (match.c:1115) ==27731==by 0x50706A: gfc_match_assignment (match.c:1292) ==27731==by 0x5188D9: match_word (parse.c:65)
[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-09-26 12:30:57 UTC --- Author: jvdelisle Date: Sun Sep 26 12:30:54 2010 New Revision: 164631 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164631 Log: 2010-09-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/45793 * module.c (create_int_parameter_array): Set the array value shape. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c
[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Version|unknown |4.6.0 Resolution||FIXED AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Target Milestone|--- |4.6.0 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-09-26 12:36:13 UTC --- Closing
[Bug bootstrap/44621] syntax error in gcc-4.5.0/configure for ksh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.26 13:18:34 date|| AssignedTo|unassigned at gcc dot |rwild at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-26 13:18:34 UTC --- Patch at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02031.html. The failure shown in comment #3 is either a followup error, or should have been fixed in the binutils tree on Mar 5 2010, by including libiberty.h in incremental.cc.
[Bug fortran/42954] [4.5 regression] TARGET_*_CPP_BUILDINS issues with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.09.26 13:19:37 date|| CC||fxcoudert at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |fxcoudert at gcc dot |gnu.org |gnu.org Summary|gfortran with libcpp: |[4.5 regression] |TARGET_*_CPP_BUILDINS |TARGET_*_CPP_BUILDINS |issues (MinGW, FreeBSD, |issues with gfortran |MIPS, Fry) | Ever Confirmed|0 |1 --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2010-09-26 13:19:37 UTC --- (In reply to comment #5) Patch for fixing at least target part for preprocessor Doesn't work, for example as config/alpha/linux.h uses c_dialect_cxx() in the macro, which is not accessible from the Fortran front-end (being a C-family function). I'm conducting of full audit of these macros in config/, and will report back here when it's done.
[Bug web/45798] New: bugzilla: line-wrapping issues with description and comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45798 Summary: bugzilla: line-wrapping issues with description and comments. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: rw...@gcc.gnu.org When I type text into a bug description or a comment, I usually make sure to not enter hard newlines within a paragraph. Nevertheless, the comments are shown with newlines where they appeared in my typed text, in addition to automatic wrapping done by the browser. This leads to ugly display like this where you have one or two words and then another newline. IIRC the old bugzilla did not do this. How can I avoid it/can it be fixed? Thanks!
[Bug bootstrap/37888] make install fails attempting to build gcc/intl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.09.26 13:29:43 date|| Ever Confirmed|0 |1 --- Comment #1 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-26 13:29:43 UTC --- Can you reconfirm whether this still happens for you with current sources? The weird thing about this is that 'make install' should not cause any recompilations nor relinking at all, at least not after a successful 'make'. Did you maybe not run 'make' or 'make all' beforehand? If this still happens for you, my next best bet would be timing issues, such as your build system and the AFS server not having synchronized clocks.
[Bug fortran/42954] [4.5 regression] TARGET_*_CPP_BUILDINS issues with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 --- Comment #7 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2010-09-26 13:44:10 UTC --- After some auditing: TARGET_OBJFMT_CPP_BUILTINS is safe (it's only called in config/elfos.h and config/alpha/elf.h, and contains a single, unconditionnal call to builtin_define()). Regarding TARGET_OS_CPP_BUILTINS, definitions in the following files may not be safe for the Fortran front-end: alpha/linux.h: c_dialect_cxx alpha/osf5.h: c_dialect_cxx arm/vxworks.h: arm_arch_xscale, arm_arch5, arm_arch4, thumb_code cris/linux.h: flag_leading_underscore i386/cygming.h: flag_iso i386/darwin.h: darwin_cpp_builtins i386/i386-interix.h: preprocessing_asm_p, c_dialect_cxx, c_dialect_objc i386/netware.h: flag_iso ia64/hpux.h: c_dialect_cxx, flag_iso mips/iris6.h: flag_isoc99, c_dialect_cxx, flag_iso mips/linux.h: c_dialect_cxx mips/netbsd.h: mips_abi pa/pa-hpux.h: c_dialect_cxx, flag_iso, preprocessing_trad_p pa/pa-hpux10.h: c_dialect_cxx, flag_iso, preprocessing_trad_p, flag_pa_unix pa/pa-hpux11.h: c_dialect_cxx, flag_iso, preprocessing_trad_p, flag_pa_unix, flag_isoc94, flag_isoc99, pa/pa.h: c_dialect_cxx, flag_iso rs6000/darwin.h: darwin_cpp_builtins rs6000/sysv4.h: target_flags_explicit sol2.h: c_dialect_cxx (each time, I give the list of variables/functions which may not be accessible from the Fortran front-end). One thing we could do is wrap all that with some IS_INSIDE_C_FAMILY_FRONTEND macro, so that it's just protected in Fortran and potentially other languages. Or we double the work and split TARGET_OS_CPP_BUILTINS into TARGET_OS_CPP_CFAMILY_BUILTINS and TARGET_OS_CPP_OTHERLANG_BUILTINS (you get the idea). I still have to audit TARGET_CPU_CPP_BUILTINS, but I'm running out of time for today.
[Bug other/37210] Prohibit Default Builds in the GCC Source Tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37210 --- Comment #5 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-26 13:44:43 UTC --- status update: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02033.html.
[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248 --- Comment #9 from margali at imapmail dot org 2010-09-26 14:04:21 UTC --- So in the end I did the following and it finally compiled: - uninstall binutils - apply cumulative fink patch to source directory - hack configure to include the --with-dwarf2 flag (also did this to configure.ac but didn't want to install another version of autoconf etc. just to regenerate configure) - configure with --disable-libjava-multilib --program-suffix=-4.5 I did not run the testsuite as I don't have the right software installed and would not know how to interpret the results in any case. Installed with --prefix=/usr/local/stow/gcc-4.5.1 and then stowed in the usual way. gcc-4.5 -v: Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/usr/local/stow/gcc-4.5.1/bin/../libexec/gcc/powerpc-apple-darwin8.11.0/4.5.1/lto-wrapper Target: powerpc-apple-darwin8.11.0 Configured with: ../gcc-4.5.1/configure --disable-libjava-multilib --program-suffix=-4.5 Thread model: posix gcc version 4.5.1 (GCC) I'm still having problems but I think these are due to my ignorance rather than anything else. Note that this method not only involves steps not listed in the host-specific installation notes but involves steps which seem to directly contradict the instructions given there. For example, I took it that two sections of the notes were relevant to me: the notes for powerpc-*-* and powerpc-*-darwin*. The former suggests that binutils is required but in fact installing binutils actually prevents the build from succeeding. The latter suggested to me that I probably needed to get cctools but in fact this wasn't the case. (I admit the notes here merely suggested this to me and I likely misinterpreted them but perhaps it could be a little clearer.) In addition, the notes say nothing about the cumulative fink patch or using --with-dwarf2 or the need to disable multilib support for libjava. But these are obviously not fink-specific requirements since I'm not using fink. Rather, they are host-specific and it would be helpful if they were listed with the host-specific installation notes. Perhaps the host-specific notes for darwin could be updated and a section specific to darwin8.11.0/os x 10.4.11 could be added outlining the stages necessary to compile? That would have been a huge help to me and would have saved me a great deal of time spent on failed builds. (My g4 takes a *long* time to build gcc!) This is not a criticism of the gcc developers since it is not, I know, your responsibility. But it seems a shame that issues such as the need to disable multilib for libjava are not flagged up even though they are obviously well recognised by those packaging gcc for fink. There never seems to be much feedback to upstream from those working on fink/macports etc. packages even when issues are clearly platform-specific rather than relevant only to the particular packaging system. This is obviously not confined to gcc but it does seem to me a shame that known fixes don't benefit the upstream sources more generally.
[Bug plugins/45787] r164531 breaks plugin support on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45787 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2010-09-26 14:11:34 UTC --- Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02037.html and test results at http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg02343.html.
[Bug c++/45799] New: ICE + segfault when compiling Qt's WebKit JavaScriptCore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45799 Summary: ICE + segfault when compiling Qt's WebKit JavaScriptCore Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Host: x86_64-w64-mingw32 Target: x86_64-w64-mingw32 Build: x86_64-w64-mingw32 Output from 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 --with-ppl=/home/Ruben/mingw64/build64/gcc-libs --with-cloog-ppl=/home/Ruben/mingw64/build64/gcc-libs --disable-win32-registry --enable-fully-dynamic-string --enable-checking=release --disable-werror --disable-nls CFLAGS='-mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer' LFLAGS= Thread model: win32 gcc version 4.6.0 20100918 (experimental) (GCC) Command used to compile the source file: g++ -c -Wall -Wreturn-type -fno-strict-aliasing -Wcast-align -Wchar-subscripts -Wformat-security -Wreturn-type -Wno-unused-parameter -Wno-sign-compare -Wno-switch -Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self -O2 -frtti -fexceptions -mthreads -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DJSC=QTJSC -Djscyyparse=qtjscyyparse -Djscyylex=qtjscyylex -Djscyyerror=qtjscyyerror -DWTF=QTWTF -DQT_BUILD_SCRIPT_LIB -DQT_NO_USING_NAMESPACE -DQLALR_NO_QSCRIPTGRAMMAR_DEBUG_INFO -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 -DBUILDING_QT__=1 -DWTF_USE_ACCELERATED_COMPOSITING -DUSE_SYSTEM_MALLOC -DNDEBUG -DBUILDING_QT__ -DBUILDING_JavaScriptCore -DBUILDING_WTF -DWTF_USE_JAVASCRIPTCORE_BINDINGS=1 -DWTF_CHANGES=1 -DNDEBUG -DJS_NO_EXPORT -DQT_DLL -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -I..\..\include\QtCore -I..\..\include -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore -Im:\Development\Source\Qt\src\3rdparty\javascriptcore -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\assembler -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\bytecode -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\bytecompiler -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\debugger -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\interpreter -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\jit -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\parser -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\pcre -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\profiler -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\runtime -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\wrec -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\wtf -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\wtf\unicode -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\yarr -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\API -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\ForwardingHeaders -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\generated -I..\..\include\QtScript -Itmp\rcc\release_shared -Itmp -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\WebKit\qt\Api -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\pcre -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\tmp -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\parser -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\bytecompiler -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\debugger -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\runtime -Im:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\wtf -Im:\Development\Source\Qt\src\script\..\3rdparty\javascriptcore\JavaScriptCore\unicode
[Bug target/45787] r164531 breaks plugin support on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45787 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2010-09-26 15:12:36 UTC --- Revised patch with corrected changelog at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02054.html.
[Bug target/45800] New: [M32C] compile error on increment volatile long var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45800
Summary: [M32C] compile error on increment volatile long var
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ae...@gcc.gnu.org
CC: d...@redhat.com
Target: M32C
Hi!
The following code snippet leads to compile error
volatile long boo = 0;
void
foo (void)
{
boo++;
}
[]$ /opt/m32c-elf/bin/m32c-elf-gcc -O1 -c test.c -o test.o
unconvertible operand - `Sms'(subreg:HI (mem/v/c/i:SI (symbol_ref:HI (boo)
[flags 0x2] var_decl 0x7faa9a811000 boo) [0 boo+0 S4 A8]) 0)
unconvertible operand - `Sms'(subreg:HI (mem/v/c/i:SI (symbol_ref:HI (boo)
[flags 0x2] var_decl 0x7faa9a811000 boo) [0 boo+0 S4 A8]) 2)
/tmp/ccx0sAA0.s: Assembler messages:
/tmp/ccx0sAA0.s:6: Error: Invalid literal `add.w #0x1,[-.Sms]'
/tmp/ccx0sAA0.s:7: Error: Invalid literal `adcf.w [-.Sms]'
Anatoly.
[Bug objc/45763] incorrect @encode(BOOL *)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45763 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.26 16:43:36 date|| AssignedTo|unassigned at gcc dot |nicola at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2010-09-26 16:43:36 UTC --- Posted a patch to gcc-patches that fixes this. Thanks
[Bug objc/25450] Enums are encoded incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25450 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||nicola at gcc dot gnu.org AssignedTo|unassigned at gcc dot |nicola at gcc dot gnu.org |gnu.org | --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2010-09-26 16:44:43 UTC --- Posted a patch to gcc-patches that fixes this. Thanks
[Bug objc/25464] objc_sizeof_type vs zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25464 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||nicola at gcc dot gnu.org AssignedTo|unassigned at gcc dot |nicola at gcc dot gnu.org |gnu.org | --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2010-09-26 16:47:51 UTC --- Posted a patch to gcc-patches that fixes this. Thanks
[Bug objc/25361] vectors are not encoded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25361 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||nicola at gcc dot gnu.org --- Comment #8 from Nicola Pero nicola at gcc dot gnu.org 2010-09-26 16:51:30 UTC --- Posted a patch to gcc-patches that implements encoding vectors. That all works but unfortunately is not enough because you also have to get structures containing vectors to work to fix the issue. :-( I'm reducing the priority though, since the failing testcase now is reduced to structures containing vectors, which is rather unusual in Objective-C. Thanks
[Bug bootstrap/25672] [4.3/4.4?/4.5 regression] cross build's libgcc picks up CFLAGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Target|ppc64-pld-linux |x86_64-pc-mingw32 Known to work|| Summary|[4.3 regression] cross |[4.3/4.4?/4.5 regression] |build's libgcc picks up |cross build's libgcc picks |CFLAGS |up CFLAGS Known to fail||4.5.2 --- Comment #27 from Pawel Sikora pluto at agmk dot net 2010-09-26 17:21:01 UTC --- this bug still exists on current 4.5 branch and probably on trunk. e.g. for mingw64 cross compilation libgcc's configure fails with: (...) checking for suffix of object files... configure: error: in `/home/users/pluto/rpm/BUILD/gcc-4.5.1/BUILDDIR/x86_64-pc-mingw32/libgcc': configure: error: cannot compute suffix of object files: cannot compile config.log contains: (...) configure:3020: /home/users/pluto/rpm/BUILD/gcc-4.5.1/BUILDDIR/./gcc/xgcc -B/home/users/pluto/rpm/BUILD/gcc-4.5.1/BUILDDIR/./gcc/ -L/usr/x86_64-pc-mingw32/lib -L/usr/mingw/lib -isystem /usr/x86_64-pc-mingw32/include -isystem /usr/mingw/include -B/usr/x86_64-pc-mingw32/bin/ -B/usr/x86_64-pc-mingw32/lib/ -isystem /usr/x86_64-pc-mingw32/include -isystem /usr/x86_64-pc-mingw32/sys-include -o conftest -g -O2 -fno-strict-aliasing -fwrapv -march=i686 -mtune=pentium4 -gdwarf-3 -g2conftest.c 5 conftest.c:1:0: error: CPU you selected does not support x86-64 instruction set conftest.c:1:0: error: CPU you selected does not support x86-64 instruction set configure:3023: $? = 1 as you can see libgcc's configure uses CFLAGS (-O2 -fno-strict-aliasing -fwrapv -march=i686 -mtune=pentium4 -gdwarf-3 -g2) passed to top-level configure script :/
[Bug web/45798] bugzilla: line-wrapping issues with description and comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45798 --- Comment #1 from Frédéric Buclin LpSolit at netscape dot net 2010-09-26 17:47:19 UTC --- This is not supposed to happen. Maybe a bug in your browser?
[Bug bootstrap/45801] New: [4.6 regression] powerpc64-linux bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45801 Summary: [4.6 regression] powerpc64-linux bootstrap comparison failure Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Trying to bootstrap 4.6-20100925 (r164623) on powerpc64-linux fails with: make[3]: Leaving directory `/mnt/scratch/objdir46' Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/fortran/trans-intrinsic.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/mnt/scratch/objdir46' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir46' make: *** [bootstrap] Error 2 The previous weekly snapshot (4.6-20100918) bootstrapped w/o issue. Target: powerpc64-unknown-linux-gnu Configured with: /mnt/scratch/gcc-4.6-20100925/configure --with-gmp=/home/mikpe/pkgs/linux-ppc64/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-ppc64/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-ppc64/mpc-0.8.2 --disable-plugin --disable-lto --disable-nls --enable-multilib --enable-threads=posix --with-cpu=default32 --enable-checking=release --disable-libmudflap --enable-languages=c,c++,objc,obj-c++,java,fortran
[Bug web/45798] bugzilla: line-wrapping issues with description and comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45798 --- Comment #2 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-26 17:59:13 UTC --- Surely possible, but I'd wonder if I'm the only one seeing that then. Running Debian's iceweasel 3.0.6, Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.19) Gecko/2010091807 Iceweasel/3.0.6 (Debian-3.0.6-3).
[Bug c++/45770] global access allowance exceeds that of derived class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45770
MichieldeB at aim dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #4 from MichieldeB at aim dot com 2010-09-26 18:14:26 UTC ---
My last counterexample was invalid, sorry. Furthermore, the problem does not
seem a template problem. I now have an example where the local object has lower
rights than the inherited object, thus no access inheritance for the local.
// g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
// Copyright (C) 2009 Free Software Foundation, Inc.
// This is free software; see the source for copying conditions. There is NO
// warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
class A
{
friend class B;
public:
A(int i) { a = i; }
protected:
A(int i, int j) { a = i ^ j; }
private:
A() { a = 0; }
int a;
};
class B : private A // making protected will allow local variables A below
{
public:
B(int i) : A () { a = i 1; b = i 1; }
private:
bool b;
};
class C : public B
{
public:
C() : B(4) { ::A foo(3); } // functions of B may have local variables ::A
// but not A
};
class D : public A
{
friend class D;
D(int i, int j) : A(i,j)
{
A d(i,j); // friend class D of class D has no inherited rights here
// note that friends do not have inherited objects in general
}
};
main () { A bar(3); } // main may have local variables A
[Bug web/45798] bugzilla: line-wrapping issues with description and comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45798 --- Comment #3 from kargl at gcc dot gnu.org 2010-09-26 18:15:00 UTC --- (In reply to comment #2) Surely possible, but I'd wonder if I'm the only one seeing that then. Running Debian's iceweasel 3.0.6, Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.19) Gecko/2010091807 Iceweasel/3.0.6 (Debian-3.0.6-3). It happens in firefox 3.6.4 on FreeBSD. I see lines extending outside the comment area in comments #2 and #5 of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778 Note, changing the fontsize via ctrl- or ctrl+ has no affect. -- steve
[Bug c++/45770] global access allowance exceeds that of derived class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45770 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2010-09-26 18:25:29 UTC --- Without having looked into your last snippet, I note that the Intel Compiler, VC++, and Comeau also reject it.
[Bug other/45802] New: [bugzilla] driver component description needs updating
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45802 Summary: [bugzilla] driver component description needs updating Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: fxcoud...@gcc.gnu.org It currently says A problem with a compiler driver, namely gcc, g++, g77, gcj or gnat. g77 should be replaced by gfortran.
[Bug web/45798] bugzilla: line-wrapping issues with description and comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45798 --- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-26 18:31:50 UTC --- Hmm, that's not what I meant though. I see e.g., in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888#c1 the word as being wrapped to a line of its own. Hmm, larger or smaller text sizes do not show that particular issue though, so I guess you're right that what I'm seeing is a browser issue.
[Bug web/45802] [bugzilla] driver component description needs updating
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45802 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Component|other |web Severity|normal |enhancement
[Bug web/45798] bugzilla: line-wrapping issues with description and comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45798 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #5 from Frédéric Buclin LpSolit at netscape dot net 2010-09-26 19:15:20 UTC --- (In reply to comment #3) It happens in firefox 3.6.4 on FreeBSD. I see lines extending outside the comment area in comments #2 and #5 of Unrelated. Quoted text is never wrapped. That's not a bug. (In reply to comment #4) the word as being wrapped to a line of its own. I see as at the end of the line, not on its own line. Firefox 3.0.6 is old. Maybe this is fixed in 3.6 or 4.0beta. Resolving as WFM as it doesn't look like a Bugzilla bug.
[Bug fortran/45783] [4.6 Regression] ICE in gfc_add_component_ref, at fortran/class.c:77
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45783 --- Comment #5 from Daniel Kraft domob at gcc dot gnu.org 2010-09-26 19:25:55 UTC --- Author: domob Date: Sun Sep 26 19:25:52 2010 New Revision: 164638 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164638 Log: 2010-09-26 Daniel Kraft d...@domob.eu PR fortran/45783 PR fortran/45795 * resolve.c (resolve_select_type): Clarify code. (resolve_assoc_var): Only set typespec if it is currently unknown. 2010-09-26 Daniel Kraft d...@domob.eu PR fortran/45783 PR fortran/45795 * gfortran.dg/select_type_18.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/select_type_18.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 --- Comment #7 from Daniel Kraft domob at gcc dot gnu.org 2010-09-26 19:25:55 UTC --- Author: domob Date: Sun Sep 26 19:25:52 2010 New Revision: 164638 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164638 Log: 2010-09-26 Daniel Kraft d...@domob.eu PR fortran/45783 PR fortran/45795 * resolve.c (resolve_select_type): Clarify code. (resolve_assoc_var): Only set typespec if it is currently unknown. 2010-09-26 Daniel Kraft d...@domob.eu PR fortran/45783 PR fortran/45795 * gfortran.dg/select_type_18.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/select_type_18.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45783] [4.6 Regression] ICE in gfc_add_component_ref, at fortran/class.c:77
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45783 Daniel Kraft domob at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Daniel Kraft domob at gcc dot gnu.org 2010-09-26 19:31:28 UTC --- Fixed.
[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 Daniel Kraft domob at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Daniel Kraft domob at gcc dot gnu.org 2010-09-26 19:32:37 UTC --- Fixed.
[Bug c++/45770] global access allowance exceeds that of derived class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45770
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2010-09-26
19:36:39 UTC ---
(In reply to comment #4)
class A
{
friend class B;
public:
A(int i) { a = i; }
protected:
A(int i, int j) { a = i ^ j; }
private:
A() { a = 0; }
int a;
};
class B : private A // making protected will allow local variables A below
{
public:
B(int i) : A () { a = i 1; b = i 1; }
B is a friend of A so can call the private constructor.
private:
bool b;
};
class C : public B
{
public:
C() : B(4) { ::A foo(3); } // functions of B may have local variables ::A
// but not A
A(int) is public, so it can be called
};
class D : public A
{
friend class D;
What is this supposed to do?
D(int i, int j) : A(i,j)
A(int, int) is protected, so D can call it on its base sub-object
{
A d(i,j); // friend class D of class D has no inherited rights here
// note that friends do not have inherited objects in general
The object 'd' is not a sub-object of D, so there is no access to that
constructor from D's member functions.
}
};
main () { A bar(3); } // main may have local variables A
That constructor is public, so of course it can.
Your example is not valid C++, that's not a problem with GCC.
[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248 Vincent Lefèvre vincent at vinc17 dot org changed: What|Removed |Added CC||vincent at vinc17 dot org --- Comment #10 from Vincent Lefèvre vincent at vinc17 dot org 2010-09-26 19:42:07 UTC --- Same problem when building GCC 4.5.1 via MacPorts. FYI, the MacPorts bug report: https://trac.macports.org/ticket/26378 GCC 4.5.0 build was fine. So, this is a 4.5.1 regression. The summary should probably be changed to: [4.5.1 Regression] Stage 3 bootstrap comparison failure (powerpc-darwin8)
[Bug bootstrap/35855] build locale not properly handled with awk scripts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35855 --- Comment #3 from Mike Frysinger vapier at gentoo dot org 2010-09-26 20:16:07 UTC --- the same locale that breaks every time: et_EE example build failure: http://bugs.gentoo.org/215828
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #29 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-09-26 22:09:16 UTC --- Thanks Cesar for your analysis, I was doing the same thing but you beat me to it. Anyhow, I can confirm your results, i.e. that the increase in size is first and foremost due to the inflation of the total number of sections (which is multiplied roughly by 10) as well as the changes to the .eh_frame and .drectve sections sizes. I compared the object files for 4.4, 4.5 and 4.5 when using auto-export, i.e. not using __attribute__((dllexport)) on exported classes declarations. The typical results (the exact numbers are, of course, different for each object file but the trend is the same) are: 4.4 4.5 4.5-autoexp -- file size151K 1.2M 87K # sections371 314585 .text size 1688817264 24856 .eh_frame40046442416 .drectve 8620 113232 0 The difference in number of sections seems to correspond to the fact that 4.5 now generates one section per method of any exported class used by the object file instead of just one section per class as in 4.4. Please let me know if I can provide any other information.
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-26 22:30:52 UTC --- Author: burnus Date: Sun Sep 26 22:30:48 2010 New Revision: 164639 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164639 Log: 2010-09-27 Tobias Burnus bur...@net-b.de PR fortran/40569 PR fortran/40568 * intrinsic.h (gfc_simplify_compiler_options, gfc_simplify_compiler_version): New prototypes. * intrinsic.c (gfc_intrinsic_function_by_id, make_from_module): New functions. (gfc_find_function, gfc_find_subroutine, gfc_generic_intrinsic, gfc_specific_intrinsic): Don't return module intrinsics. (add_functions): Add compiler_options, compiler_version. (gfc_intrinsic_func_interface): Also lookup symbol by ISYM ID. * symbol.c (std_for_isocbinding_symbol): Add version check for NAMED_FUNCTIONS. * iso-fortran-env.def: Add compiler_options, compiler_version. * iso-c-binding.def: Add c_sizeof. * gfortran.h (gfc_intrinsic_sym): Add from_module:1. (iso_c_binding_symbol, iso_fortran_env_symbol): Add NAMED_FUNCTIONS. (gfc_intrinsic_function_by_id): New prototype. * module.c (create_intrinsic_function): New function. (import_iso_c_binding_module, use_iso_fortran_env_module): Use it. * trans-types.c (init_c_interop_kinds): Add NAMED_FUNCTIONS. * resolve.c (resolve_intrinsic): Try also to resolve intrinsics by ISYM ID. * simplify.c (gfc_simplify_compiler_options, gfc_simplify_compiler_version): New functions. 2010-09-27 Tobias Burnus bur...@net-b.de PR fortran/40569 PR fortran/40568 * gfortran.dg/storage_size_2.f08: Fix test. * gfortran.dg/c_sizeof_1.f90: Fix test. * gfortran.dg/c_sizeof_2.f90: Update dg-error. * gfortran.dg/c_sizeof_3.f90: New. * gfortran.dg/c_sizeof_4.f90: New. * gfortran.dg/iso_c_binding_compiler_1.f90: New. * gfortran.dg/iso_c_binding_compiler_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/c_sizeof_3.f90 trunk/gcc/testsuite/gfortran.dg/c_sizeof_4.f90 trunk/gcc/testsuite/gfortran.dg/iso_c_binding_compiler_1.f90 trunk/gcc/testsuite/gfortran.dg/iso_c_binding_compiler_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/iso-c-binding.def trunk/gcc/fortran/iso-fortran-env.def trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_sizeof_1.f90 trunk/gcc/testsuite/gfortran.dg/c_sizeof_2.f90 trunk/gcc/testsuite/gfortran.dg/storage_size_2.f08
[Bug fortran/40568] F2008: C_SIZEOF is in the wrong scope, rejected as initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-26 22:30:52 UTC --- Author: burnus Date: Sun Sep 26 22:30:48 2010 New Revision: 164639 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164639 Log: 2010-09-27 Tobias Burnus bur...@net-b.de PR fortran/40569 PR fortran/40568 * intrinsic.h (gfc_simplify_compiler_options, gfc_simplify_compiler_version): New prototypes. * intrinsic.c (gfc_intrinsic_function_by_id, make_from_module): New functions. (gfc_find_function, gfc_find_subroutine, gfc_generic_intrinsic, gfc_specific_intrinsic): Don't return module intrinsics. (add_functions): Add compiler_options, compiler_version. (gfc_intrinsic_func_interface): Also lookup symbol by ISYM ID. * symbol.c (std_for_isocbinding_symbol): Add version check for NAMED_FUNCTIONS. * iso-fortran-env.def: Add compiler_options, compiler_version. * iso-c-binding.def: Add c_sizeof. * gfortran.h (gfc_intrinsic_sym): Add from_module:1. (iso_c_binding_symbol, iso_fortran_env_symbol): Add NAMED_FUNCTIONS. (gfc_intrinsic_function_by_id): New prototype. * module.c (create_intrinsic_function): New function. (import_iso_c_binding_module, use_iso_fortran_env_module): Use it. * trans-types.c (init_c_interop_kinds): Add NAMED_FUNCTIONS. * resolve.c (resolve_intrinsic): Try also to resolve intrinsics by ISYM ID. * simplify.c (gfc_simplify_compiler_options, gfc_simplify_compiler_version): New functions. 2010-09-27 Tobias Burnus bur...@net-b.de PR fortran/40569 PR fortran/40568 * gfortran.dg/storage_size_2.f08: Fix test. * gfortran.dg/c_sizeof_1.f90: Fix test. * gfortran.dg/c_sizeof_2.f90: Update dg-error. * gfortran.dg/c_sizeof_3.f90: New. * gfortran.dg/c_sizeof_4.f90: New. * gfortran.dg/iso_c_binding_compiler_1.f90: New. * gfortran.dg/iso_c_binding_compiler_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/c_sizeof_3.f90 trunk/gcc/testsuite/gfortran.dg/c_sizeof_4.f90 trunk/gcc/testsuite/gfortran.dg/iso_c_binding_compiler_1.f90 trunk/gcc/testsuite/gfortran.dg/iso_c_binding_compiler_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/iso-c-binding.def trunk/gcc/fortran/iso-fortran-env.def trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_sizeof_1.f90 trunk/gcc/testsuite/gfortran.dg/c_sizeof_2.f90 trunk/gcc/testsuite/gfortran.dg/storage_size_2.f08
[Bug fortran/40568] F2008: rejected as initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|F2008: C_SIZEOF is in the |F2008: rejected as |wrong scope, rejected as|initialization expression |initialization expression | --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-26 22:36:14 UTC --- The bug of comment 0 is fixed - I have thus updated the summary. TODO: Issue mentioned in comment 1: - Documentation fixes (cf. .texi part of the patch in attachment 20612) - Function is CLASS_INQUIRY - ?
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-26 22:40:26 UTC --- Basic implementation works. Remains to do: (a) COMPILER_OPTIONS(): Return a more useful string than (b) -Wall gives a bogus warning: Warning: Type specified for intrinsic function 'compiler_version' at (1) is ignored for use iso_fortran_env, only: compiler_version print *,compiler_version() end
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-26 22:46:10 UTC --- (In reply to comment #6) Basic implementation works. Remains to do: ... (c) CLASS_INQUIRY instead of CLASS_IMPURE?
[Bug fortran/42954] [4.5/4.6 regression] TARGET_*_CPP_BUILDINS issues with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 Summary|[4.5 regression]|[4.5/4.6 regression] |TARGET_*_CPP_BUILDINS |TARGET_*_CPP_BUILDINS |issues with gfortran|issues with gfortran
[Bug middle-end/45388] [4.6 Regression] Global constructor not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45388 --- Comment #7 from dave at hiauly1 dot hia.nrc.ca 2010-09-26 23:21:44 UTC --- Hi Steve, I have a patch I am testing. It worked on the test case but I haven't fully bootstrapped it. Keep plugging away on this. I have the sense that the breakage is intentional. I fought the same battle in 4.5, so Honza should be aware what's happened. I believe that he doesn't want the constructors to be global to improve interprocedurial optimisations. I'm sure this could be fixed with a target hook, but Honza doesn't really work on anything but x86. Regards, Dave
[Bug c/44803] LIBRARY_PATH should work on cross-compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44803 --- Comment #3 from Felipe Contreras felipe.contreras at gmail dot com 2010-09-27 01:28:24 UTC --- Is this not clear? It would be useful to cross-compile like this: export C_INCLUDE_PATH=/opt/arm/ffmpeg/include export LIBRARY_PATH=/opt/arm/ffmpeg/lib But LIBRARY_PATH is ignored.
[Bug c/45804] New: ARM: unnecessary sign extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45804
Summary: ARM: unnecessary sign extension
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: felipe.contre...@gmail.com
In the following code gcc add an unnecessary uxth operation.
static inline uint16_t read16_be(const uint8_t *p)
{
uint16_t v;
__asm__(ldrh %0, %1 : =r(v) : m(*(const uint16_t *)p));
__asm__(rev16 %0, %0 : +r(v));
return v;
}
Many other people have experienced this issue:
http://article.gmane.org/gmane.comp.video.ffmpeg.cvs/33470
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/106781
https://bugs.launchpad.net/gcc-linaro/+bug/634682
[Bug target/45805] New: VFP/Neon double precision register expected -- `vmovl.s16 q2,s8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 Summary: VFP/Neon double precision register expected -- `vmovl.s16 q2,s8 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: raj.k...@gmail.com Created attachment 21892 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21892 testcase The attached testcase does not compile with gcc trunk when using vectorizer and neon on arm. arm-oe-linux-gnueabi-gcc -mfpu=neon -mfloat-abi=softfp -O3 -c test.c It works fine if I add -mvectorize-with-neon-quad option here is my gcc configuration Using built-in specs. COLLECT_GCC=arm-none-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/kraj/work/cross/arm-none-linux-gnueabi/tools/libexec/gcc/arm-none-linux-gnueabi/4.6.0/lto-wrapper Target: arm-none-linux-gnueabi Configured with: /home/kraj/work/cross/arm-none-linux-gnueabi/../../gcc-trunk/configure --target=arm-none-linux-gnueabi --prefix=/home/kraj/work/cross/arm-none-linux-gnueabi/tools --with-sysroot=/home/kraj/work/cross/arm-none-linux-gnueabi/sysroot --enable-__cxa_atexit --disable-libssp --disable-libgomp --disable-libmudflap --enable-languages=c,c++ Thread model: posix gcc version 4.6.0 20100927 (experimental) (GCC)
[Bug other/45806] New: gcc build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45806 Summary: gcc build failure Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: te...@chem.gu.se Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu I find it hard to believe this is actually a gcc bug, but I'm reporting it anyway because I don't know what else to do. make for 4.5.1 fails on i686 with Ubuntu 8.04. I configure with: ../gcc-4.5.1/configure --disable-multilib --enable-languages=c,c++,fortran After some make progress, I hit this: make[3]: Leaving directory `/home/tjf/InstallTrees/gcc-4.5.1-build/gcc' Checking multilib configuration for libgcc... Configuring stage 1 in i686-pc-linux-gnu/libgcc configure: loading cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... mawk checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for i686-pc-linux-gnu-ar... ar checking for i686-pc-linux-gnu-lipo... lipo checking for i686-pc-linux-gnu-nm... /home/tjf/InstallTrees/gcc-4.5.1-build/./gcc/nm checking for i686-pc-linux-gnu-ranlib... ranlib checking for i686-pc-linux-gnu-strip... strip checking whether ln -s works... yes checking for i686-pc-linux-gnu-gcc... /home/tjf/InstallTrees/gcc-4.5.1-build/./gcc/xgcc -B/home/tjf/InstallTrees/gcc-4.5.1-build/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include checking for suffix of object files... configure: error: in `/home/tjf/InstallTrees/gcc-4.5.1-build/i686-pc-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[2]: Leaving directory `/home/tjf/InstallTrees/gcc-4.5.1-build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/tjf/InstallTrees/gcc-4.5.1-build' make: *** [all] Error 2 The gcc that's currently running is: gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.4-20100323/configure --disable-multilib --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.4 20100323 (prerelease) (GCC) uname -a gives Linux rscpc28 2.6.24-28-generic #1 SMP Thu Sep 16 15:01:14 UTC 2010 i686 GNU/Linux What on Earth is going on here?
