[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #3 from rfm at gnu dot org 2008-12-08 08:29 --- Any news on when this can be done? The path is tiny/trivial, so even though it might be judged low priority I'd have hoped it could be fitted in quickly. -- rfm at gnu dot org changed: What|Removed |Added CC||rfm at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
--- Comment #1 from rfm at gnu dot org 2008-12-08 08:39 --- It turns out that solving this bug, even though it's conceptually simple, is quite a lot of work. I have new code to fix it, but it took me a whole day to develop and involves extensive additions and alterations to sendmsg.c (though I tried to keep the existing code unchanged as much as possible). I'm running the new code on my system to see if I can find any problems before I supply a patch, but if there's any interest I can provide a patch earlier for people to test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug tree-optimization/38401] TreeSSA-PRE load after store misoptimization
--- Comment #10 from sergeid at il dot ibm dot com 2008-12-08 10:08 --- Subject: Re: TreeSSA-PRE load after store misoptimization Sorry, forgot to attach the patch.(See attached file: gcse-las-counter.patch) --- Comment #11 from sergeid at il dot ibm dot com 2008-12-08 10:08 --- Created an attachment (id=16850) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16850action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
[Bug tree-optimization/38401] TreeSSA-PRE load after store misoptimization
--- Comment #9 from sergeid at il dot ibm dot com 2008-12-08 10:03 --- Subject: Re: TreeSSA-PRE load after store misoptimization Can you post your gcc configuration options? I've created and attached a little patch which adds some more information to dump file. Can you apply it and send me the new .gcse1 dump? Then I'll compare it with mine and may be we'll find the reason. steven at gcc dot gnu dot org [EMAIL PROTECTED] wrote on 04/12/2008 20:16:05: I still don't see why this is caught on powerpc by RTL PRE, but not on ia64 (note *ia64*, not x86). I compile with -O3 -fgcse-las. The compiler is yesterday's trunk on ia64-unknown-linux-gnu. The .gcse1 dump is attached. Why is it optimized for you on powerpc but not for me on ia64? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
[Bug middle-end/36802] [4.4 Regression] pop_gimplify_context ICE using openmp task construct
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-08 10:42 --- Your testcase has data races, but I came up with valid testcases. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36802
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #7 from burnus at gcc dot gnu dot org 2008-12-08 11:33 --- (In reply to comment #6) To add the default paths defined in gcc/cppdefault.c (cpp_include_defaults) to the module/INCLUDE search path, one could clone gcc/incpath.c (add_standard_paths) and call gfc_add_include_path() instead of add_path(). Tobias, do we still need/want this? Good question. FX and Joe don't like the idea, but Fortran files (.h/.inc and .mod files one can find in /usr/include in some Linux distributions. openSUSE has a .mod file and *.inc for NetCDF in /usr/include. The place for the .mod looks wrong, but for .inc? A semi-proper place for .mod files is: /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/ (Semi because finclude does not distinguish between e.g. 32bit and 64bit.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug c/38443] New: scoping problems with identically named identifiers
The following program gives -1208725329 0 as output, and no warnings are
generated despite all warnings being turned on (-W -Wall).
#include stdio.h
int main()
{
int x = 0;
{
int x = x - 1;
printf(%d\n, x);
}
printf(%d\n, x);
return 0;
}
I am not sure as to the exact scoping rules employed by C in this case, and I
couldn't find a passage in the ISO C standard which would unambiguously
indicate the right version (probably because I'm not thoroughly familiar with
the standard and didn't want to read the whole document).
Even if this behaviour is correct I think there should at least be a warning.
Anyway, whatever the C standard says, it would be much more useful if the
second x were assigned -1 in this case. I actually came upon this problem in a
complicated macro expression (involving a macro inside a macro, etc.) where it
was not apparent that the names were the same. The macro would work regardless
of the names if the behaviour of GCC was as I expected it to be.
--
Summary: scoping problems with identically named identifiers
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lc235951 at students dot mimuw dot edu dot pl
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38443
[Bug tree-optimization/38401] TreeSSA-PRE load after store misoptimization
--- Comment #13 from rguenther at suse dot de 2008-12-08 12:40 --- Subject: Re: TreeSSA-PRE load after store misoptimization On Mon, 8 Dec 2008, sergeid at il dot ibm dot com wrote: --- Comment #12 from sergeid at il dot ibm dot com 2008-12-08 11:53 --- I have to mention that tree PRE still don't catch this LOAD with -O3. Though the patch Richard posted does the job. Sorry if the comment wasn't clear - -O3 doesn't catch it, but this is only because of the implementation decision fixed with that patch. (In reply to comment #1) It works with -O3 (with partial-partial PRE enabled). At least phi-translation figures out that *res is zero on the incoming edge. Un-leashing partial-PRE like with -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
[Bug tree-optimization/38401] TreeSSA-PRE load after store misoptimization
--- Comment #12 from sergeid at il dot ibm dot com 2008-12-08 11:53 --- I have to mention that tree PRE still don't catch this LOAD with -O3. Though the patch Richard posted does the job. (In reply to comment #1) It works with -O3 (with partial-partial PRE enabled). At least phi-translation figures out that *res is zero on the incoming edge. Un-leashing partial-PRE like with -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
[Bug middle-end/36802] [4.4 Regression] pop_gimplify_context ICE using openmp task construct
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-08 10:37 --- Subject: Bug 36802 Author: jakub Date: Mon Dec 8 10:36:01 2008 New Revision: 142546 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142546 Log: PR middle-end/36802 * omp-low.c (use_pointer_for_field): Only call maybe_lookup_decl on parallel and task contexts. * testsuite/libgomp.c/pr36802-1.c: New test. * testsuite/libgomp.c/pr36802-2.c: New test. * testsuite/libgomp.c/pr36802-3.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr36802-1.c trunk/libgomp/testsuite/libgomp.c/pr36802-2.c trunk/libgomp/testsuite/libgomp.c/pr36802-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36802
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #8 from dfranke at gcc dot gnu dot org 2008-12-08 12:50 --- A semi-proper place for .mod files is: /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/ (Semi because finclude does not distinguish between e.g. 32bit and 64bit.) One could argue that .mod files are library support files and could be placed/distributed in a project's $libdir?! If there's a difference between 32-bit and 64-bit .mod-files, placing them in their respective $multilibdir would solve this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug tree-optimization/36922] [4.4 Regression] ICE in tree-data-ref.c with -ftree-loop-linear
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-08 14:00 --- Any news on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36922
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #9 from mikael at gcc dot gnu dot org 2008-12-08 14:25 --- (In reply to comment #7) A semi-proper place for .mod files is: /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/ (Semi because finclude does not distinguish between e.g. 32bit and 64bit.) Isn't (...)/x86_64-(...) enough to tell that it is 64 bits (besides /usr/lib64) ? My opinion is that the proper way to distribute fortran so-called headers is via interfaces in fortran files, not via modules. If we add a standard place for fortran modules, everybody will use it, and it will raise countless problems (need to provide several modules versions for different compiler versions, doesn't work if the compiler is upgraded, ...) In short, I agree with FX. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/38444] New: poor error message
IMPLICIT NONE INTEGER :: a,b,c,d,e,f,g,h,a a=0 ; b=0 ; c=0 ; d=0 ; e=0 ; f=0 ; g=0 ; h=0 END this typo leads to 9 error messages. -- Summary: poor error message Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38444
[Bug tree-optimization/27004] [4.2/4.3/4.4 Regression] Insane amount of memory needed at -O1 and above because of salias and large switch
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-08 14:41 --- It is unclear which target this was tested on, in any case current trunk tops on this at around 1.2GB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
[Bug tree-optimization/27004] [4.2/4.3 Regression] Insane amount of memory needed at -O1 and above because of salias and large switch
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-12-08 14:47 --- I think this is a dup of PR26854 on the trunk at least - the excess memory used is used by DF (SFTs are gone on the trunk). So, this is now a 4.2/4.3 regression only (which still have SFTs). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26854 Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression] Insane |Insane amount of memory |amount of memory needed at - |needed at -O1 and above |O1 and above because of |because of salias and large |salias and large switch |switch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
[Bug tree-optimization/33237] [4.3/4.4 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #17 from dnovillo at google dot com 2008-12-08 15:03 --- Subject: Re: [4.3/4.4 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile. On Sun, Dec 7, 2008 at 06:55, steven at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #15 from steven at gcc dot gnu dot org 2008-12-07 11:55 --- Diego, in comment #7 you said you will work on this... So? Have you worked on this? Not at all. Sorry. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/35468] [4.2/4.3/4.4 Regression] LHS of assignment can be folded to a constant causing ICE
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-12-08 15:06 --- Unassigning for now. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35468
[Bug c/38445] New: [4.4 Regression] ICE in tree-ssa-struct-alias when compiling grub-0.97
Using built-in specs. Target: i686-linux-uclibc Configured with: /there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=i686-linux-uclibc --enable-languages=c,c++ --with-sysroot=/there/src/buildroot.git.pentium4/i686_build/staging --with-build-time-tools=/there/src/buildroot.git.pentium4/i686_build/staging/usr/i686-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/there/src/buildroot.git.pentium4/i686_toolchain/gmp --with-mpfr=/there/src/buildroot.git.pentium4/i686_toolchain/mpfr --enable-threads --disable-multilib --with-arch=core2 --with-tune=core2 --disable-libssp --disable-libssp --disable-libmudflap --disable-libgomp --enable-decimal-float=no Thread model: posix gcc version 4.4.0 20081208 (experimental) [trunk revision 142549] (GCC) COLLECT_GCC_OPTIONS='-DHAVE_CONFIG_H' '-I.' '-I.' '-I..' '-I../stage1' '-DSUPPORT_LOOPDEV' '-Wall' '-Wmissing-prototypes' '-Wunused' '-Wshadow' '-Wpointer-arith' '-falign-jumps=1' '-falign-loops=1' '-falign-functions=1' '-Wundef' '-nostdinc' '-DSUPPORT_SERIAL=1' '-DSUPPORT_HERCULES=1' '-DSUPPORT_GRAPHICS=1' '-DFSYS_EXT2FS=1' '-DFSYS_FAT=1' '-DFSYS_FFS=1' '-DFSYS_UFS2=1' '-DFSYS_MINIX=1' '-DFSYS_REISERFS=1' '-DFSYS_VSTAFS=1' '-DFSYS_JFS=1' '-DFSYS_XFS=1' '-DFSYS_ISO9660=1' '-DUSE_MD5_PASSWORDS=1' '-Os' '-pipe' '-fno-builtin' '-MT' 'pre_stage2_exec-char_io.o' '-MD' '-MP' '-MF' '.deps/pre_stage2_exec-char_io.Tpo' '-c' '-o' 'pre_stage2_exec-char_io.o' '-v' '-mtune=core2' '-march=core2' /there/src/buildroot.git.pentium4/i686_build/staging/usr/bin/../libexec/gcc/i686-linux-uclibc/4.4.0/cc1 -quiet -nostdinc -v -I. -I. -I.. -I../stage1 -iprefix /there/src/buildroot.git.pentium4/i686_build/staging/usr/bin/../lib/gcc/i686-linux-uclibc/4.4.0/ -MD pre_stage2_exec-char_io.d -MF .deps/pre_stage2_exec-char_io.Tpo -MP -MT pre_stage2_exec-char_io.o -DHAVE_CONFIG_H -DSUPPORT_LOOPDEV -DSUPPORT_SERIAL=1 -DSUPPORT_HERCULES=1 -DSUPPORT_GRAPHICS=1 -DFSYS_EXT2FS=1 -DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_UFS2=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -DFSYS_VSTAFS=1 -DFSYS_JFS=1 -DFSYS_XFS=1 -DFSYS_ISO9660=1 -DUSE_MD5_PASSWORDS=1 char_io.c -quiet -dumpbase char_io.c -mtune=core2 -march=core2 -auxbase-strip pre_stage2_exec-char_io.o -Os -Wall -Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -Wundef -version -falign-jumps=1 -falign-loops=1 -falign-functions=1 -fno-builtin -o - | /there/src/buildroot.git.pentium4/i686_build/staging/usr/bin/../lib/gcc/i686-linux-uclibc/4.4.0/../../../../i686-linux-uclibc/bin/as -V -Qy -o pre_stage2_exec-char_io.o - GNU assembler version 2.19 (i686-linux-uclibc) using BFD version (GNU Binutils) 2.19 ignoring duplicate directory . #include ... search starts here: #include ... search starts here: . .. ../stage1 End of search list. GNU C (GCC) version 4.4.0 20081208 (experimental) [trunk revision 142549] (i686-linux-uclibc) compiled by GNU C version 4.3.2, GMP version 4.2.4, MPFR version 2.3.2. warning: GMP header version 4.2.4 differs from library version 4.2.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 6a40f4131f5176b43bb64e609d95341a char_io.c: In function grub_sprintf: char_io.c:253: warning: dereferencing pointer dataptr does break strict-aliasing rules char_io.c:248: warning: dereferencing pointer dataptr does break strict-aliasing rules char_io.c:253: note: initialized from here char_io.c:253: note: initialized from here char_io.c:253: note: initialized from here char_io.c:253: note: initialized from here char_io.c:253: note: initialized from here char_io.c:253: note: initialized from here char_io.c:253: note: initialized from here char_io.c:253: note: initialized from here char_io.c:253: note: initialized from here char_io.c:253: note: initialized from here [snip gazillions of these] char_io.c:253: note: initialized from here i686-linux-uclibc-gcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. #0 0xb7e18c1e in _IO_default_xsputn_internal () from /lib/i686/cmov/libc.so.6 #1 0xb7deb783 in vfprintf () from /lib/i686/cmov/libc.so.6 #2 0xb7e1308c in vasprintf () from /lib/i686/cmov/libc.so.6 #3 0x0815d96f in build_message_string (msg=0x87e5d1a %s:%d: %s) at /there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/gcc/diagnostic.c:75 #4 0x0815d9fd in diagnostic_build_prefix (diagnostic=0xbf7b585c) at /there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/gcc/diagnostic.c:158 #5 0x0815db96 in default_diagnostic_starter (context=0x8982020, diagnostic=0xbf7b585c) at /there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/gcc/diagnostic.c:264 #6 0x0815d1a0 in diagnostic_report_diagnostic (context=0x8982020, diagnostic=0xbf7b585c) at /there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/gcc/diagnostic.c:403 #7 0x0815d716 in inform (location=265376, gmsgid=0x8838368
[Bug c/38445] [4.4 Regression] ICE in tree-ssa-struct-alias when compiling grub-0.97
--- Comment #1 from aldot at gcc dot gnu dot org 2008-12-08 15:08 --- Created an attachment (id=16851) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16851action=view) preprocess source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38445
[Bug c/38445] [4.4 Regression] ICE in tree-ssa-struct-alias when compiling grub-0.97
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-08 15:13 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38445
[Bug c/38445] [4.4 Regression] ICE in tree-ssa-struct-alias when compiling grub-0.97
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-08 15:25 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-08 15:25:30 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38445
[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown
--- Comment #56 from rguenth at gcc dot gnu dot org 2008-12-08 15:37 --- Unassigning. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug c++/38410] g++.dg/eh/crossjump1.C (internal compiler error)
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-08 16:43:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38410
[Bug c++/38410] [4.4 regression] g++.dg/eh/crossjump1.C (internal compiler error)
--- Comment #3 from jason at gcc dot gnu dot org 2008-12-08 16:45 --- added regression tag. -- jason at gcc dot gnu dot org changed: What|Removed |Added Summary|g++.dg/eh/crossjump1.C |[4.4 regression] |(internal compiler error) |g++.dg/eh/crossjump1.C ||(internal compiler error) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38410
[Bug c++/38410] [4.4 regression] g++.dg/eh/crossjump1.C (internal compiler error)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38410
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #2 from r dot emrich at de dot tecosim dot com 2008-12-08
17:08 ---
(In reply to comment #1)
Created an attachment (id=16815)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16815action=view) [edit]
preproccesed source
the following looks weired for me:
# 31 /opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c 2
# 1 ../config.h 1
# 32 /opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c 2
float
((float)fabs((double)(float)(float x)))
{
return (float) fabs(x);
}
And this is caused by the following lines in /usr/include/math.h
#ifdef _PA_RISC
# define _FPCLASSIFY(x)
(_IS32(x)?_Fpclassifyf(x)1:_Fpclassify(x)1)
extern int _Fpclassify(double);
extern int _Fpclassifyf(float);
# ifndef _DISALLOW_MASKING_MACROS
#define fabsf(x) ((float)fabs((double)(float)(x)))
# endif
#else /* __IA64__ */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug middle-end/38240] Vector type definitions not compatible with attribute target
--- Comment #2 from rth at gcc dot gnu dot org 2008-12-08 17:14 --- Subject: Bug 38240 Author: rth Date: Mon Dec 8 17:12:55 2008 New Revision: 142556 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142556 Log: PR 38240 * tree.h (TYPE_MODE): Invoke vector_type_mode when needed. (SET_TYPE_MODE): New. * c-decl.c (parser_xref_tag): Use it. (finish_enum): Likewise. * tree.c (build_pointer_type_for_mode): Likewise. (build_reference_type_for_mode, build_index_type): Likewise. (build_range_type, make_vector_type): Likewise. (build_common_tree_nodes_2): Likewise. * stor-layout.c (compute_record_mode): Likewise. (finalize_type_size, layout_type, make_fract_type): Likewise. (make_accum_type, initialize_sizetypes): Likewise. (vector_type_mode): New. * function.c (allocate_struct_function): Call invoke_set_current_function_hook before querying anything else. * config/i386/i386.c (ix86_valid_target_attribute_inner_p): Add avx. cp/ * class.c (finish_struct_bits): Use SET_TYPE_MODE. * decl.c (record_unknown_type): Likewise. (start_enum, finish_enum): Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr38240.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/config/i386/i386.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/function.c trunk/gcc/stor-layout.c trunk/gcc/tree.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38240
[Bug c/38446] New: [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
gloog calls rewrite_into_sese_closed_ssa, which in turn calls sese_find_uses_to_rename_bb. sese_find_uses_to_rename_bb looks at every phi in every basic block. For each incoming edge into that basic block which is associated with the corresponding use argument of the phi, graphite then calls sese_find_uses_to_rename_bb. Now for the use found, the def_bb is looked up. If the def_bb exists and def_bb belongs to the scop and use_bb does not belong to scope, then a phi is created that can reach the use_bb because def_bb does not reach use_bb. Right now the check which determines if def_bb belongs to the scop and use_bb does not belong to scop is broken since it looks at dominators and post dominators instead of travesing or looking up the bb's in scop which match with a given bb. -- Summary: [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: hjagasia at gcc dot gnu dot org ReportedBy: hjagasia at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
[Bug c/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
--- Comment #1 from hjagasia at gcc dot gnu dot org 2008-12-08 17:26 --- Created an attachment (id=16852) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16852action=view) Reduced test case for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
[Bug libffi/26048] [4.2/4.3/4.4 Regression] libffi doesn't build on Solaris 10/x86 with native assembler
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-12-08 17:32 --- Subject: Re: [4.2/4.3/4.4 Regression] libffi doesn't build on Solaris 10/x86 with native assembler New patch here: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00481.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26048
[Bug c/35442] [4.2/4.3/4.4 Regression] Completely broken diagnostic with view_convert_expr
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-08 18:05 --- Subject: Bug 35442 Author: jakub Date: Mon Dec 8 18:03:40 2008 New Revision: 142558 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142558 Log: PR c/35442 * c-pretty-print.c (pp_c_cast_expression, pp_c_expression): Handle VIEW_CONVERT_EXPR the same as CASE_CONVERT. * gcc.dg/pr35442.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr35442.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-pretty-print.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35442
[Bug c/35443] [4.2/4.3/4.4 regression] Completely broken diagnostic with bind_expr
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-08 18:06 --- Subject: Bug 35443 Author: jakub Date: Mon Dec 8 18:04:58 2008 New Revision: 142559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142559 Log: PR c/35443 * c-pretty-print.c (pp_c_expression): Handle BIND_EXPR. * gcc.dg/pr35443.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr35443.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-pretty-print.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35443
[Bug c/35442] [4.2/4.3/4.4 Regression] Completely broken diagnostic with view_convert_expr
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-08 18:07 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35442
[Bug c/35443] [4.2/4.3/4.4 regression] Completely broken diagnostic with bind_expr
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-08 18:07 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35443
[Bug fortran/38444] poor error message
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-08 18:24 ---
Yeah, this has always bothered me. I typically use -fmax-errors=1 when
developing new code because of the run-on errors for simple mistakes.
This fixes the excessive errors in this case.
Index: symbol.c
===
--- symbol.c(revision 142481)
+++ symbol.c(working copy)
@@ -1559,7 +1559,8 @@ gfc_add_type (gfc_symbol *sym, gfc_types
|| gfc_notification_std (GFC_STD_GNU) == ERROR
|| pedantic)
{
- gfc_error (msg, sym-name, where, gfc_basic_typename (sym-ts.type));
+ gfc_fatal_error (msg, sym-name, where,
+ gfc_basic_typename (sym-ts.type));
return FAILURE;
}
if (gfc_notify_std (GFC_STD_GNU, msg, sym-name, where,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38444
[Bug c/38447] New: special characters in C
[gcc -v]
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
[source code]-
#include stdio.h
main()
{
printf(ciao\b\a\n);
}
[software used]---
Gedit for editing the source
gcc for compiling
[command]-
gcc ./test.c
[problem]-
running this hello world the special characters \b doesn't seems to be
effective .
--
Summary: special characters in C
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: krecis at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38447
[Bug fortran/38444] poor error message
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-08 18:39 --- (In reply to comment #1) - gfc_error (msg, sym-name, where, gfc_basic_typename (sym-ts.type)); + gfc_fatal_error (msg, sym-name, where, + gfc_basic_typename (sym-ts.type)); That produces too few error messages. I.e. IMPLICIT NONE INTEGER :: a,b,c,d,e,f,g,h,a a=0 ; b=0 ; c=0 ; d=0 ; e=0 ; f=0 ; g=0 ; h=0; i=0 END should produce (like NAG f95, ifort) two errors only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38444
[Bug debug/38390] Missing DW_TAG_imported_module
--- Comment #4 from dodji at gcc dot gnu dot org 2008-12-08 19:02 --- Subject: Bug 38390 Author: dodji Date: Mon Dec 8 19:00:46 2008 New Revision: 142562 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142562 Log: gcc/cp/ChangeLog: 2008-12-07 Dodji Seketeli [EMAIL PROTECTED] PR debug/38390 * name-lookup.c (kept_level_p): Don't forget the case of levels having using directives. gcc/testsuite/ChangeLog: 2008-12-07 Dodji Seketeli [EMAIL PROTECTED] PR debug/38390 * g++.dg/debug/dwarf2/imported-module-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38390
[Bug target/38448] New: referenced external symbol not marked weak for ppc64
Tests weak-1.c and weak-16.c from gcc.dg/weak fail on
powerpc64-unknown-linux-gnu with -m64. A small test case from the last check
in weak-1.c is:
#pragma weak weakvar
extern int weakvar;
int use_it () { return weakvar; }
That check has failed since r139233, when it started failing for both -m32 and
-m64. The check started passing again for -m32 with r140539, but continues to
fail for -m64.
A referenced external weak symbol used to be added to the weak_decls list in a
call to declare_weak, but now is added to that list from assemble_external.
For -m64 there is no call to assemble_external for this weak reference. The
fix in r140539 has special handling for Darwin, so perhaps similar special
handling is needed for GNU/Linux, or perhaps the rs6000 backend needs to call
mark_symbol_refs_as_used as is done for sh, arm, and s390; I haven't figured
out where that would be.
Test weak-16.c was added in r140540 for the fix in r140539 for PR 37280.
--
Summary: referenced external symbol not marked weak for ppc64
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38448
[Bug debug/38390] Missing DW_TAG_imported_module
--- Comment #5 from dodji at gcc dot gnu dot org 2008-12-08 19:25 --- Fixed in trunk. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38390
[Bug fortran/38444] poor error message
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-08 19:31 --- (In reply to comment #2) (In reply to comment #1) - gfc_error (msg, sym-name, where, gfc_basic_typename (sym-ts.type)); + gfc_fatal_error (msg, sym-name, where, + gfc_basic_typename (sym-ts.type)); That produces too few error messages. I.e. IMPLICIT NONE INTEGER :: a,b,c,d,e,f,g,h,a a=0 ; b=0 ; c=0 ; d=0 ; e=0 ; f=0 ; g=0 ; h=0; i=0 END should produce (like NAG f95, ifort) two errors only. Unfortunately, the first error causes the entire line to be rejected. Thus, all your variables are implicitly typed when gfortran tries to continue with processing the file. AFAIK, gfortran cannot accept a partially correct specification statement. If you fix the fatal error, you'll then see the second error. So, you can view my patch as an all-or-nothing solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38444
[Bug rtl-optimization/38449] New: delay branch scheduling follows REG_CROSSING_JUMP jumps indiscriminately
I see an assemble failure for gcc.dg/tree-prof/bb-reorg.c; compare-and-branch instructions are modified to jump to another section. Some jumps simply can't be made cross-section; one for the ones that can, it is essential that the REG_CROSSING_JUMP note is added. I have this patch: * hooks.c (hook_bool_const_rtx_const_rtx_true): New function. * hooks.h (hook_bool_const_rtx_const_rtx_true): Declare. * target.h (can_follow_jump): New hook. * target-def.h (TARGET_CAN_FOLLOW_JUMP): Define. (TARGET_INITIALIZER): Include it. * reorg.c (follow_jumps): New parameters jump and cp. Changed all callers. * config/arc/arc.c (arc_can_follow_jump): New function. (TARGET_CAN_FOLLOW_JUMP): Override. * config/arc/arc.md (jump_i): If a REG_CROSSING_JUMP is present, length is 4. Which I can post with a tm.texi patch once our Copyright assignment has been acknowledged. -- Summary: delay branch scheduling follows REG_CROSSING_JUMP jumps indiscriminately Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: assemble-failure Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38449
[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-08 19:34 ---
|
\ ' /
-- (*) --
*
0@
@*
@*0
*@@
@0*@
*0@@
@*@*0*
\*/ 0*@0*@
___\\U//___ *@0*@*0
|\\ | | \\|@0*0@0*@
| \\| | _(UU)_ ((*))_0*0@0*
|\ \| || / //||.*.*.*.|@*@0
jgs |\\_|_|_// ||*.*.*.*|_\\db//_
|'.'.'.|~~|.*.*.*| |_
|'.'.'.| ^^|||
'`--'
5 years later ... adding a Christmas tree to the bug report.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Last reconfirmed|2005-12-10 05:30:31 |2008-12-08 19:34:48
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
[Bug c/38447] special characters in C
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-08 19:36 --- This bug is not related to GCC, it is up to printf/console to take into account /b and printf is not part of GCC. Also the standard says the behavior of the display device is unspecified. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38447
[Bug c/38443] scoping problems with identically named identifiers
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-08 19:40 --- On the trunk we get: t.c: In function 'main': t.c:7: warning: 'x' is used uninitialized in this function Which is correct. x in the inner scope comes alive right after the = sign. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38443
[Bug target/38448] referenced external symbol not marked weak for ppc64
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-08 19:49 --- Either: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01218.html or call mark_symbol_refs_as_used (x); at the very end of output_toc in rs6000.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38448
[Bug rtl-optimization/38449] delay branch scheduling follows REG_CROSSING_JUMP jumps indiscriminately
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-08 20:06 --- What is target dependent about this, that you need a target hook for it? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-08 20:06:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38449
[Bug middle-end/37980] [graphite] ICE : verify_ssa failed
--- Comment #5 from grosser at gcc dot gnu dot org 2008-12-08 20:11 --- *** Bug 37883 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37980
[Bug middle-end/37883] [graphite] ICE : in scan_tree_for_params, at graphite.c:2274
--- Comment #8 from grosser at gcc dot gnu dot org 2008-12-08 20:11 --- Fixed in branch and trunk. Now fails in trunk on verify_ssa(). This is already solved in branch and will be imported to trunk soon. *** This bug has been marked as a duplicate of 37980 *** -- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37883
[Bug target/38294] Enable multilib support for mingw
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-12-08 20:16 --- From my point of view this patch seems to be ok. Multilib is just enabled for 64-bit default target, what makes sende at the moment. Just about the point of multilib library specifier, I am not sure. Shouldn't it separated by comman. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-08 20:16:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
[Bug middle-end/38084] [graphite] ICE : in build_graphite_scops, at graphite.c:1829
--- Comment #2 from grosser at gcc dot gnu dot org 2008-12-08 20:17 --- We get SCoPs that overlap each other. This should be easy to fix. -- grosser at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |grosser at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-08 20:17:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38084
[Bug web/12821] [4.2/4.3/4.4 Regression] dead link on onlinedocs/gccint/Top-Level.html
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-08 20:20 --- Joseph Myers introduced this in the manual with the following patch: http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00726.html So this is a regression. Ah, and Joseph also explained how to fix this, see comment #2. So this should be fixed in the blink of an eye then, no? -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Summary|dead link on|[4.2/4.3/4.4 Regression] |onlinedocs/gccint/Top- |dead link on |Level.html |onlinedocs/gccint/Top- ||Level.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-12-08 20:29 --- As I explained in 2003, this is a web problem, not a source code bug, and so not a regression. It is a new feature of the manual such that each user of the manual may need to do something to take advantage of the new feature, and that applies to the onlinedocs on gcc.gnu.org just as it does to any user of make install-html. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jsm28 at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.2/4.3/4.4 Regression]|dead link on |dead link on|onlinedocs/gccint/Top- |onlinedocs/gccint/Top- |Level.html |Level.html | Target Milestone|4.2.5 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
[Bug web/12821] [4.2/4.3/4.4 Regression] dead link on onlinedocs/gccint/Top-Level.html
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
[Bug middle-end/38271] [4.4 Regression] Spurious / missing ... used uninitialized in this function warning
--- Comment #8 from d dot g dot gorbachev at gmail dot com 2008-12-08
20:34 ---
(In reply to comment #7)
The patch causes segfault. This is how it happens:
tree-sra.c:1612
for (f = TYPE_FIELDS (elt-type);
f; f = TREE_CHAIN (f))
{
tree-sra.c:1700
if (size != TREE_INT_CST_LOW (TYPE_SIZE (TREE_TYPE (elt-element
return f; // NULL
tree-sra.c:1764
for (f = TYPE_FIELDS (type); f ; f = TREE_CHAIN (f))
if (TREE_CODE (f) == FIELD_DECL)
{
tree last = try_instantiate_multiple_fields (elt, f);
if (last != f)
{
f = last;
continue;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
[Bug bootstrap/38314] multilib bootstrap broken for x86_64-apple-darwin10
--- Comment #18 from andreast at gcc dot gnu dot org 2008-12-08 20:34 --- Should be fixed: http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00125.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00124.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00068.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00067.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00066.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00065.html Message 65 and 67 are for completeness. -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
[Bug rtl-optimization/38449] delay branch scheduling follows REG_CROSSING_JUMP jumps indiscriminately
--- Comment #2 from amylaar at gcc dot gnu dot org 2008-12-08 20:36 --- (In reply to comment #1) What is target dependent about this, that you need a target hook for it? Some jumps are OK to be made section crossing, while others are not. And which ones are OK also depends on target options - the ARCompact architecture has branches with 21 and 25 bit offset range. These may cross section boundaries if the binary is not too large. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38449
[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html
--- Comment #7 from steven at gcc dot gnu dot org 2008-12-08 20:40 --- Well, I can't even find this paragraph you want to reference. And I was under the impression that there was a kind-of you broke it, you fix it rule with GCC bugs. Am I wrong or does this just not apply to you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
[Bug target/38448] referenced external symbol not marked weak for ppc64
--- Comment #2 from janis at gcc dot gnu dot org 2008-12-08 20:43 --- Either of the suggestions in comment #1 fixes this, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38448
[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html
--- Comment #8 from joseph at codesourcery dot com 2008-12-08 21:00 --- Subject: Re: dead link on onlinedocs/gccint/Top-Level.html On Mon, 8 Dec 2008, steven at gcc dot gnu dot org wrote: Well, I can't even find this paragraph you want to reference. The reference is to a whole manual (etc/configure.texi in the src repository), not to one paragraph. And I was under the impression that there was a kind-of you broke it, you fix it rule with GCC bugs. Am I wrong or does this just not apply to you? There is no such rule beyond the limited reversion rule in develop.html. As explained, this is a missing website feature, not a GCC bug. The link in the manual is a correct link in the global namespace for Texinfo manuals. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
[Bug fortran/37829] ICE in resolve_symbol
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-08 21:06 ---
reduced:
module modx
use, intrinsic :: iso_c_binding
end module modx
block data
use modx
end
A simple way to fix it would be this:
Index: resolve.c
===
--- resolve.c (révision 142546)
+++ resolve.c (copie de travail)
@@ -9263,6 +9263,7 @@ resolve_symbol (gfc_symbol *sym)
module function and is not PRIVATE. */
if (sym-ts.type == BT_DERIVED
sym-ts.derived-attr.use_assoc
+sym-ns-proc_name
sym-ns-proc_name-attr.flavor == FL_MODULE)
{
gfc_symbol *ds;
Paul, I'm adding you as you may know better what to do here.
see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295#c7
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug middle-end/38084] [graphite] ICE : in build_graphite_scops, at graphite.c:1829
--- Comment #3 from grosser at gcc dot gnu dot org 2008-12-08 21:49 --- Created an attachment (id=16853) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16853action=view) Fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38084
[Bug target/38448] referenced external symbol not marked weak for ppc64
--- Comment #3 from janis at gcc dot gnu dot org 2008-12-08 22:03 --- Eric, Your sparc patch referenced in comment #1 fixes this powerpc64-linux failure. Are you planning to push for it to be accepted for 4.4? In http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00500.html Mark Mitchell says that it's probably a reasonable short-term solution, and it seems better than a hack in yet another backend. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38448
[Bug middle-end/38084] [graphite] ICE : in build_graphite_scops, at graphite.c:1829
--- Comment #4 from sebpop at gmail dot com 2008-12-08 22:07 --- Subject: Re: [graphite] ICE : in build_graphite_scops, at graphite.c:1829 On Mon, Dec 8, 2008 at 3:49 PM, grosser at gcc dot gnu dot org [EMAIL PROTECTED] wrote: Fix The patch looks good. Please apply to graphite branch and trunk. For trunk, please also include the new testcases pr38084.c and id-3.f90, and make sure that the patch bootstraps and passes testsuite. Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38084
[Bug fortran/37497] Fortran openMP compiler error: Segmentation fault
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-08 22:10 --- (In reply to comment #0) Do you still see the bug ? If so, please provide more information. Otherwise, we will close it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37497
[Bug testsuite/36889] [4.4 regression] gfortran.fortran-torture/execute/execute.exp tries to run sse2 execute tests without checking for host support
--- Comment #9 from janis at gcc dot gnu dot org 2008-12-08 22:11 --- Subject: Bug 36889 Author: janis Date: Mon Dec 8 22:10:06 2008 New Revision: 142566 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142566 Log: Backport from mainline: 2008-09-16 Jakub Jelinek [EMAIL PROTECTED] PR testsuite/36889 * lib/fortran-torture.exp (get-fortran-torture-options): Only set test_tree_vectorize on i?86/x86_64 resp. sparc* if sse2 resp. ultrasparc hw is available. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/lib/fortran-torture.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36889
[Bug fortran/37527] conftest.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'me'
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-08 22:17 --- (In reply to comment #4) Using a different object directory I was able to compile c and c++, but not fortran. I configured with: ./configure --prefix=/home/rkraft/apps/gcc4 --with-mpfr=/home/rkraft/apps/mpfr-2.3.2 --disable-multilib --enable-languages=c,c++,fortran --with-gmp=/home/rkraft/apps/gmp-4.2.3 --with-gmp-lib=/home/rkraft/apps/gmp-4.2.3/lib --with-mpfr-lib=/home/rkraft/apps/mpfr-2.3.2/lib This is still wrong. If you are using a separated build directory, your command shall look like: ../gcc-4.3.2/configure (your options here ...) Does it work now ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37527
[Bug debug/37738] Fortran DW_TAG_common_block has incorrect placement/scope
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-08 22:23 --- Is it fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
[Bug c/37865] gfortran build fails in stage 3 bootstrap with --enable-intermodule
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-08 22:32 --- (Sorry for the delay) Do you still see the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37865
[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
--- Comment #8 from doko at ubuntu dot com 2008-12-08 22:32 --- a current snapshot from the branch, exluding r142149 works for me. I'll try to reduce the applied patches until the builds succeeds again with r142149, but again, this may take a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug fortran/36355] matmul argument-check: wrong error messages
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-08 22:35 --- (In reply to comment #4) Judging from the latest status reports, I'll find the time to look into it again in December before 4.4 is released. We are in December, and 4.4 is not yet released. :p -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36355
[Bug debug/37738] Fortran DW_TAG_common_block has incorrect placement/scope
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-08 22:42 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
[Bug target/38062] FAIL: gfortran.dg/include_2.f90 -O (test for excess errors): error: stray '#' in program
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-08 22:51 --- Does it still happen? If so, can you provide more information (host, version, configure options)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38062
[Bug c++/38410] [4.4 regression] g++.dg/eh/crossjump1.C (internal compiler error)
--- Comment #4 from danglin at gcc dot gnu dot org 2008-12-08 22:56 --- I also see this failure on hppa-unknown-linux-gnu compiling empty2.C: Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/home /dave/gnu/gcc/objdir/gcc/testsuite/g++/../../ -nostdinc++ -I/home/dave/gnu/gcc/ objdir/hppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gnu/gcc/objdir/hp pa-linux/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I /home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/li bstdc++-v3/testsuite/util -fmessage-length=0 -ansi -pedantic-errors -Wno-long- long -c -o empty2.o /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.abi/ empty2.C(timeout = 300) /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.abi/empty2.C: In function 'int main()': /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.abi/empty2.C:112: internal compiler error: in expr_size, at explow.c:250 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38410
[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-12-08 23:01 --- a current snapshot from the branch, exluding r142149 works for me. I'll try to reduce the applied patches until the builds succeeds again with r142149, but again, this may take a while. So are the dates in your first message correct or not? IOW did you have the failure *before* my patch? If so, there is strictly no point in considering it. It would also be interesting to attach the df-scan.i generated before and after my patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug fortran/38248] Ignored temporary module files manipulation errors
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-08 23:03 --- Can we close ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug target/38448] referenced external symbol not marked weak for ppc64
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-12-08 23:11 --- Your sparc patch referenced in comment #1 fixes this powerpc64-linux failure. Are you planning to push for it to be accepted for 4.4? Already done yesterday: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00418.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-08 23:11:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38448
[Bug target/38062] FAIL: gfortran.dg/include_2.f90 -O (test for excess errors): error: stray '#' in program
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-08 23:17 --- Subject: Re: FAIL: gfortran.dg/include_2.f90 -O (test for excess errors): error: stray '#' in program Does it still happen? Not sure. It takes a long time to do a full build on the this machine. The test didn't fail in my last build on head. Was there a recent backport that might have fixed this PR? If so, can you provide more information (host, version, configure options)? ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --enable-shared --prefix=/opt/gnu/gcc/gcc-4.3.2 --with-gmp=/opt/gnu/gcc/gcc-4.3.2 --enable-debug=no --disable-nls --enable-checking=release --enable-languages=c,c++,objc,fortran,ada,obj-c++ The rest of the info is already in the PR (host, target, build). Is there a way to capture the generated .c file? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38062
[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails
--- Comment #10 from hp at gcc dot gnu dot org 2008-12-08 23:25 --- (In reply to comment #9) Please try this patch. That did it! Thanks. (Haven't checked whether this eliminates the valgrind complaints in the posted trace, but the FAILs in this PR were fixed.) brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
[Bug middle-end/38084] [graphite] ICE : in build_graphite_scops, at graphite.c:1829
--- Comment #5 from grosser at gcc dot gnu dot org 2008-12-08 23:35 --- Subject: Bug 38084 Author: grosser Date: Mon Dec 8 23:34:36 2008 New Revision: 142569 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142569 Log: 2008-12-08 Tobias Grosser [EMAIL PROTECTED] PR middle-end/38084 Fix testsuite/gfortran.dg/graphite/id-3.f90. * graphite.c (scopdet_basic_block_info): Fix bug that found some regions more than once. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38084
[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
--- Comment #10 from doko at ubuntu dot com 2008-12-08 23:42 --- So are the dates in your first message correct or not? hmm, did reply to this, but probably in another report ... seen with 4.3.3 20081029, seen the last successful bootstrap with 20081022, not seen on the trunk. this should be 11 (Nov) instead of 10 (Oct). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug target/38062] FAIL: gfortran.dg/include_2.f90 -O (test for excess errors): error: stray '#' in program
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-09 00:50 --- (In reply to comment #2) The test didn't fail in my last build on head. Was there a recent backport that might have fixed this PR? Not really, I was having a look at forgotten PRs If so, can you provide more information (host, version, configure options)? ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --enable-shared --prefix=/opt/gnu/gcc/gcc-4.3.2 --with-gmp=/opt/gnu/gcc/gcc-4.3.2 --enable-debug=no --disable-nls --enable-checking=release --enable-languages=c,c++,objc,fortran,ada,obj-c++ The rest of the info is already in the PR (host, target, build). Yes, sorry. Is there a way to capture the generated .c file? I'm not sure there should be a .c generated file here. Can you compile the file with your host fortran compiler? With the bootstrapped f951? (For me, both work with the -g3 option) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38062
[Bug middle-end/38426] Incorrect code produced with -momit-leaf-frame-pointer -fno-unit-at-a-time
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2008-12-09 01:11 --- Ira() calls setup_eliminable_regset() at ira.c:1794, which calls ix86_frame_pointer_required() at ira.c:1296, which checks current_function_is_leaf, but this variable is updated only at ira.c:1866. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38426
[Bug ada/38450] New: [4.4 Regression] ada bootstrap is broken
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict- prototypes -Wmissing-prototypes -Wcast-qual -fno-common -DHAVE_CONFIG_H -I.. -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include -I../.. /gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../l ibdecnumber/dpd -I../libdecnumber../../gcc/gcc/ada/gcc-interface/decl.c -o a da/decl.o gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict- prototypes -Wmissing-prototypes -Wcast-qual -fno-common -DHAVE_CONFIG_H -I.. -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include -I../.. /gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../l ibdecnumber/dpd -I../libdecnumber../../gcc/gcc/ada/gcc-interface/misc.c -o a da/misc.o ../../gcc/gcc/ada/gcc-interface/decl.c: In function 'gnat_to_gnu_entity': ../../gcc/gcc/ada/gcc-interface/decl.c:2035: error: lvalue required as left oper and of assignment ../../gcc/gcc/ada/gcc-interface/decl.c:2876: error: lvalue required as left oper and of assignment ../../gcc/gcc/ada/gcc-interface/decl.c: In function 'make_aligning_type': ../../gcc/gcc/ada/gcc-interface/decl.c:5575: error: lvalue required as left oper and of assignment make[3]: *** [ada/decl.o] Error 1 make[3]: *** Waiting for unfinished jobs 142549 was ok. -- Summary: [4.4 Regression] ada bootstrap is broken Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38450
[Bug ada/38450] [4.4 Regression] ada bootstrap is broken
--- Comment #1 from danglin at gcc dot gnu dot org 2008-12-09 02:56 --- All the errors are lines like: TYPE_MODE (record_type) = BLKmode; Probably caused by: 2008-12-08 Richard Henderson [EMAIL PROTECTED] PR 38240 * tree.h (TYPE_MODE): Invoke vector_type_mode when needed. (SET_TYPE_MODE): New. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38450
[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-12-09 03:20 --- Subject: Bug 38430 Author: jvdelisle Date: Tue Dec 9 03:19:09 2008 New Revision: 142575 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142575 Log: 2008-12-08 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/38430 * io/transfer.c (data_transfer_init): Move constraint check for REC= and STREAM access into condition for other REC= constraints to simplify. Comment out this constraint to avoid breaking compatibility with 4.3 until later. Added a TODO for above comment and this one. Fix test for max pos. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
[Bug middle-end/38084] [graphite] ICE : in build_graphite_scops, at graphite.c:1829
--- Comment #6 from grosser at gcc dot gnu dot org 2008-12-09 04:44 --- Subject: Bug 38084 Author: grosser Date: Tue Dec 9 04:43:24 2008 New Revision: 142578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142578 Log: 2008-12-09 Tobias Grosser [EMAIL PROTECTED] PR middle-end/38084 Fix testsuite/gfortran.dg/graphite/id-3.f90. * graphite.c (scopdet_basic_block_info): Fix bug that found some regions more than once. * testsuite/gfortran.dg/graphite/id-3.f90: New. * gcc/testsuite/gcc.dg/graphite/pr38084.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr38084.c trunk/gcc/testsuite/gfortran.dg/graphite/id-3.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38084
[Bug middle-end/38084] [graphite] ICE : in build_graphite_scops, at graphite.c:1829
--- Comment #7 from grosser at gcc dot gnu dot org 2008-12-09 04:49 --- Fixed in branch and current. -- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38084
[Bug c++/38410] [4.4 regression] g++.dg/eh/crossjump1.C (internal compiler error)
--- Comment #5 from jason at gcc dot gnu dot org 2008-12-09 06:06 --- Subject: Bug 38410 Author: jason Date: Tue Dec 9 06:04:50 2008 New Revision: 142580 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142580 Log: PR c++/38410 * gimplify.c (gimplify_init_constructor): Don't write out a static copy of the CONSTRUCTOR for TREE_ADDRESSABLE types or small sparse initializers. Added: trunk/gcc/testsuite/gcc.dg/ctor1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38410
