Re: Problems with in-tree host libraries (gmp, ppl, etc)
Even then, the ppl configury isn't detecting the gmp we just built. It seems as though we should install gmp in a local temporary install tree and point ppl at that. See below for a trace of the ppl configury as it attempts to detect an in-tree gmp (after applying the patch above). AG I don't know if ppl was ever setup to detect/use an in-tree gmp. No, it was not. So you can drop in gmp/mpfr, or ppl/cloog, but not all four. Paolo
Re: gfortran-dev branch bootstrap breakage
On Mon, May 4, 2009 at 01:42, Jerry DeLisle jvdeli...@verizon.net wrote: I just completed a sync to trunk that I have not committed back yet and I get the following error during bootstrap on the local branch. libbackend.a(plugin.o): In function `plugin_default_version_check': /home/jerry/gcc/objdev/gcc/../../gccdev/gcc/plugin.c:825: undefined reference to `plugin_gcc_version' There was a patch that went in about 3 days ago related to this. r146962. That patch is in place in my local gfortran-dev branch. local branch svn is at r147078 Suggestions anyone? FWIW, there was recently some mention on gcc@ that the server now runs svn 1.5 which supposedly has slightly less braindamaged merging, making svnmerge.py superfluous. See http://gcc.gnu.org/wiki/SvnBranch -- Janne Blomqvist
Re: [gnat] reuse of ASTs already constructed
Oliver Kellogg wrote: Further question, what is the process for integrating my changes into the GCC trunk? The generic procedure is documented at the gcc web site: http://gcc.gnu.org/contribute.html http://gcc.gnu.org/svnwrite.html I would assume that I need to 1) Make my modifications complete and functioning 2) Make sure bootstrap works for all languages 3) Run the gcc testsuite and make sure I do not introduce regressions Basically, that's what it says on those pages, yep! Probably still worth having a quick browse of the above links, to fill out the details. 4) What about testing on different platforms? I'm only testing on x86 SuSE Linux and setting up other platforms could be a problem. (Coming to think, I could actually test on x86_64 SuSE Linux with small effort, though.) Knowing how much testing to do can be tricky, it depends on the nature of the changes. Target-specific changes need testing on the targets they affect; with more generic changes (IIUC you're contemplating FE changes in this thread) it's usually sufficient to show bootstrap + no testsuite regressions on any of the primary or secondary supported platforms. I'd recommend doing that before submitting the patch, and the relevant maintainers can ask you to do further testing if they feel it's needed. Testing on both 32 and 64 bit platforms is an obvious good way to spot minor type-size-assumption bugs. One thing that does have a tendency to go a bit undertested and break from time to time is SjLj EH, which GNAT uses on at least some platforms (non-ZCX targets), you might want to try testing one each way for extra brownie points :) cheers, DaveK
Re: Trunk freeze next Friday morning GMT for cond-optab merge
On Mon, May 4, 2009 at 3:36 PM, Paolo Bonzini bonz...@gnu.org wrote: Hi all, I plan to merge the cond-optab branch next Friday morning European time. No commit should be made to trunk from Friday 6:00 AM GMT to 12:00 AM GMT (or probably earlier). While I think the slush is practially over (I am not aware of any bootstrap issues anymore) I'd like to have Mark clarify that as it was him announcing the slush. Thanks, Richard.
Re: Trunk freeze next Friday morning GMT for cond-optab merge
On Mon, May 4, 2009 at 7:14 AM, Richard Guenther richard.guent...@gmail.com wrote: On Mon, May 4, 2009 at 3:36 PM, Paolo Bonzini bonz...@gnu.org wrote: Hi all, I plan to merge the cond-optab branch next Friday morning European time. No commit should be made to trunk from Friday 6:00 AM GMT to 12:00 AM GMT (or probably earlier). While I think the slush is practially over (I am not aware of any bootstrap issues anymore) I'd like to have Mark clarify that as it was him announcing the slush. See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978 It may be also caused by revision 146817, which has triggered a few bugs. -- H.J.
Re: Trunk freeze next Friday morning GMT for cond-optab merge
Richard Guenther wrote: On Mon, May 4, 2009 at 3:36 PM, Paolo Bonzini bonz...@gnu.org wrote: Hi all, I plan to merge the cond-optab branch next Friday morning European time. No commit should be made to trunk from Friday 6:00 AM GMT to 12:00 AM GMT (or probably earlier). While I think the slush is practially over (I am not aware of any bootstrap issues anymore) I'd like to have Mark clarify that as it was him announcing the slush. I expect to lift the slush as part of the status report I will send out later today. If anyone else has comments on whether or not we've had enough slush, let me know. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Trunk freeze next Friday morning GMT for cond-optab merge
Hi all, I plan to merge the cond-optab branch next Friday morning European time. No commit should be made to trunk from Friday 6:00 AM GMT to 12:00 AM GMT (or probably earlier). Thanks! Paolo
Re: Unexpected offsets when eliminating SP
Michael Hope wrote: (define_expand reload_outsi [(parallel [(match_operand 0 memory_operand =m) Perhaps the problem is that the output operand is an unallocated pseudo-reg instead of a MEM. Looking at other targets that have reload_out* patterns, I see that they have predicates that accept both mem and pseudo-regs here. I'm a bit confused with the documentation versus the ports. For example, REGNO_MODE_CODE_OK_FOR_BASE_P doesn't appear to need a strict form according to the documentation but the bfin port has a strict and non-strict version. Most of the ports have a REG_OK_FOR_BASE_P macro with strict and non-strict versions macro but it's not documented, isn't used, and might have been removed around gcc 4.0. The current docs say that REGNO_MODE_CODE_OK_FOR_BASE_P has strict and non-strict variants. The REG_OK_FOR_BASE_P stuff is obsolete. That is something that could be cleaned up. However, since most ports are both defining it and using it in the GO_IF_LEGITIMATE_ADDRESS macros, it is something that will take some work, and it might be simpler to just leave the macros there. Jim
Re: Empty loops removal (Was Re: Some extra decorations)
2009/5/4 Peter Dimov: Jonathan Wakely: 2009/5/4 Joseph S. Myers: On Mon, 4 May 2009, Jan Hubicka wrote: On mainline I enabled infinite loop removal at -funsafe-loop-optimizations. I would suggest adding -fempty-loops-terminate and make it default for C++? It does not apply for C, right? You mean for C++0x (I see no such rule in C++03), and there is no such rule for C at present. Yes, the rule is new for C++0x, and it is in the context of for, while and do-while loops only, not recursive calls. It might be worth raising this issue on c++std-core, because it's easy for a compiler to transform recursion to a loop using tail call elimination, and I suspect that it is in line with the original intent to treat recursion with no side effects as finite in the same way. Thanks for the suggestion, Peter. I've asked for clarification and will report back here whatever conclusion is reached. Jonathan
Re: Problems with in-tree host libraries (gmp, ppl, etc)
Paolo Bonzini wrote: Even then, the ppl configury isn't detecting the gmp we just built. It seems as though we should install gmp in a local temporary install tree and point ppl at that. See below for a trace of the ppl configury as it attempts to detect an in-tree gmp (after applying the patch above). AG I don't know if ppl was ever setup to detect/use an in-tree gmp. No, it was not. So you can drop in gmp/mpfr, or ppl/cloog, but not all four. I would like to again suggest that we declare in-tree builds of this stuff out of scope. Build them up front, pass configure options to say where they can be found, and declare victory. As GCC depends on more external libraries, it gets harder and harder for us to maintain this build system. We all want to get the build system to the point where we're doing staged installs, instead of the current mess -- but the more we put into the build system the more complex it becomes. I think we should leave the process of building and installing components to packaging systems like RPM or .deb or Cygwin. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: CONSTRAINT__LIMIT
Ian, thanks for reporting this. I'll investigate this more. It affects only ports using priority allocation (I know only one which is m32c). DJ just recently reported a reload failure problem on m32c. Probably that is because of this wrong code. In checking through this code, I see that it depends on having define_constraint's in the *.md file. m32c has none, so this code is not triggered. Has any port ever used this code? Would the lack of define_constraints be causing problems for the m32c backend?
Re: Plugins GGC ie GTY
Sorry for dragging this discussion out from the distant past. I'm in the process of porting some plug-ins from the old plugin SVN branch to the new plug-in system, and this is one of the issues blocking me. My plug-ins maintain some tree nodes that I want to stay alive from function to function. Managing these nodes manually isn't an option, since they get allocated (with garbage collection) by internal GCC functions. Basically, my plug-in wants to sprinkle logging function calls throughout compiled code. I generate the types and decls for these with build_function_type_list() and build_fn_decl(), and then use them when I need them. Now, I don't _need_ to hold on to these references, but regenerating them every time I use them seems inefficient to me. We just have to add some small code [2] into the ggc_mark_roots routine of gcc/ggc-common.c to add the scanning using this gt_ggc_r_gt_FOO_h. This is not a big deal. We should simply add a routine ggc_register_plugin_root_tab(const struct ggc_root_tab*) that adds its argument to some (static variable in gcc/ggc-common.c which is a) linked list or vector, and have ggc_mark_root scan that list or vector by adding a few lines there. We require plugin initializers to call ggc_register_plugin_root_tab appropriatly, exactly like they do already call register_callback etc... This is in fact exactly the solution I was using in the old plugin branch (though I never submitted the code once it became clear that the newer plug-in system was going to take over). I can send out the patch if anyone is interested; it's as simple as it sounds. With that extra bit of garbage collector support in place, I hacked up a simple header file that provides macros to manually generate ggc_add_plugin_root struct entries just like the ones gengtype would generate (for a small set of types). So a plug-in author can declare a vector of tree nodes like so: static GC_ROOT_TREE_VEC (my_tree_vector); Another macro (to be called from plugin_init()) lets the author register that root with the garbage collector. register_root (my_tree_vector); This isn't an end-all solution, but it actually provides all the support that I need for my plug-ins, and it is perhaps a useful stepping stone. The main reason I'm bringing this up is because I've got a handful of plug-ins I'd like to make public. Without any support from the garbage collector, I'll have to do some rewriting to get around the issue. If other plug-in authors thinks this is a useful idea (would it be sufficient to port MELT, for instance?), I'd be willing to prepare some patches to add it in. --Justin
[Announcement] Creating lightweight IPO branch
Hi, I am going to create a gcc branch for the functionality of lightweight IPO. The description of the project and current status can be found in http://gcc.gnu.org/wiki/LightweightIpo. Some highlights: 1) If you already use FDO in your build, you also get IPO almost for free; 2) It is an IPO solution practical to very large real world C++ applications; 3) Performance potential is very large (though I've seen case increased compiler freedom can lead to performance degradation due to over-optimization (inliner, unroller etc) -- but this is a different matter). If the idea is generally accepted, I will prepare a series of patches and submit them to gcc trunk. Thanks, David
[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #13 from julian1844 at yahoo dot com 2009-05-04 06:23 --- (In reply to comment #12) Should I conclude that the MinGW site is now www.equation.com? (In reply to comment #11) (In reply to comment #9, comment #10) I did not build MinGW 4.3.0. I got it from the official MinGW site (gcc-4.3.0-20080502-mingw32-alpha). I have also found that on www.equation.com there are even newer versions (binaries), like 4.3.3 with OpenMP 2.5, 4.4.0 with OpenMP 3.0 and MinGW 4.5 compilation snapshot. They seem to work fine with OpenMP. Its a shame that www.equation.com doesn't tell us how to obtain their source code for the gcc, gdb ands make binaries. They aren't present on the official MinGW site. Why? No one has had put them there. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #2 from dominiq at lps dot ens dot fr 2009-05-04 06:30 ---
Confirmed on i686-apple-darwin9, array_memcpy_4.f90.003t.original is
MAIN__ ()
{
struct t d[5];
struct t s[5];
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_options (8, (void *) options.0);
(void) __builtin_memcpy ((void *) d, (void *) s, 60);
}
and does not depend on the optimization level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #3 from dominiq at lps dot ens dot fr 2009-05-04 06:32 ---
At revision 147065 I get:
MAIN__ ()
{
struct t d[5];
struct t s[5];
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_options (8, (void *) options.0);
d = VIEW_CONVERT_EXPRstruct t[5](s);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #20 from kreckel at ginac dot de 2009-05-04 06:47 --- So, Joseph explained that the code should execute as expected, at least with -frounding-math as a workaround. However, with GCC 4.4 it is still not possible to write code that takes advantage of those advanced features of IEEE754, even on hardware that supports it directly. Could someone, please, set this bug's status to something less inappropriate than unconfirmed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug fortran/39997] Procedure(), pointer implicit typing: rejects-valid / accepts-invalid?
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-04 07:11 --- Wrong comp.lang.fortran link; the correct one is: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b3a7e94ddf6b8ff3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #10 from jv244 at cam dot ac dot uk 2009-05-04 07:12 --- This is the outermost stack trace to the segfault (with default 8M stack), shows the depth of the recursion, and the location: #174699 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174700 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174701 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174702 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174703 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174704 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174705 0x0052884d in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:213 #174706 0x005283e7 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:315 #174707 0x00528831 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:211 #174708 0x005283e7 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:315 #174709 0x005283d9 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:314 #174710 0x005283d9 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:314 #174711 0x00528041 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:457 #174712 0x005283e7 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:315 #174713 0x00528519 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:291 #174714 0x006f6955 in gt_ggc_mx_cgraph_node (x_p=value optimized out) at gtype-desc.c:228 #174715 0x006f6a76 in gt_ggc_m_P11cgraph_node4htab (x_p=value optimized out) at gtype-desc.c:2142 #174716 0x006c0bce in ggc_mark_roots () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:107 #174717 0x00572108 in ggc_collect () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1941 #174718 0x00543253 in gfc_generate_function_code (ns=0x3603e890) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-decl.c:4140 #174719 0x005298eb in gfc_generate_module_code (ns=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1322 #174720 0x004f6404 in gfc_parse_file () at /data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:3865 #174721 0x00526bbd in gfc_be_parse_file (set_yydebug=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:236 #174722 0x007f39b4 in toplev_main (argc=13, argv=0x7fff5db02a88) at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:977 #174723 0x7f9454765436 in __libc_start_main () from /lib64/libc.so.6 #174724 0x00499679 in _start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #11 from jv244 at cam dot ac dot uk 2009-05-04 07:49 ---
I have a gdb session open, but I'm rather clueless. I have this:
(gdb) print (*x).generic.type
$5 = {common = {base = {code = RECORD_TYPE, side_effects_flag = 0,
constant_flag = 0, addressable_flag = 0, volatile_flag = 0,
readonly_flag = 0, unsigned_flag = 0, asm_written_flag = 0,
nowarning_flag = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0, public_flag = 0, private_flag = 0, protected_flag = 0,
deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0,
lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0,
lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0, type =
0x0}, values = 0x7f94536c6780, size = 0x7f9453fada80,
size_unit = 0x7f9453e43cc0, attributes = 0x0, uid = 769447, precision = 0,
mode = BLKmode, string_flag = 0, no_force_blk_flag = 0,
needs_constructing_flag = 0, transparent_union_flag = 0, packed_flag = 0,
restrict_flag = 0, contains_placeholder_bits = 0,
lang_flag_0 = 0, lang_flag_1 = 1, lang_flag_2 = 0, lang_flag_3 = 0,
lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0,
user_align = 0, align = 64, alias_set = -1, pointer_to = 0x0, reference_to =
0x0, symtab = {address = 0, pointer = 0x0, die = 0x0},
name = 0x7f9452151150, minval = 0x0, maxval = 0x0, next_variant =
0x7f941d7c60c0, main_variant = 0x7f9453d66e40, binfo = 0x0,
context = 0x0, canonical = 0x7f9453d66e40, lang_specific = 0x7f941d7c7600}
but the following fails:
(gdb) call debug_tree((*x).generic.type.next_variant)
Cannot access memory at address 0x7fff5d302f78
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
--- Comment #10 from dennis dot wassel at googlemail dot com 2009-05-04 08:50 --- Edited the Known to fail instead of Reported against. -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Known to fail||4.3.2 4.3.3 Version|4.3.3 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
--- Comment #9 from dennis dot wassel at googlemail dot com 2009-05-04 08:45 --- Also fails with 4.3.3 (precisely the same error message as 4.3.2) gfortran -O2 -ftree-parallelize-loops=2 -c ma57.f -o ma57.o ma57.f: In function 'ma57od': ma57.f:2724: error: edge from 676 to 686 should be marked irreducible ma57.f:2724: error: basic block 686 should be marked irreducible ma57.f:2724: error: edge from 686 to 679 should be marked irreducible ma57.f:2724: error: basic block 679 should be marked irreducible ma57.f:2724: error: edge from 679 to 124 should be marked irreducible ma57.f:2724: confused by earlier errors, bailing out Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-O2' '-ftree-parallelize-loops=2' '-c' '-o' 'ma57.o' '-mtune=generic' '-pthread' /localdata/libexec/gcc/i686-pc-linux-gnu/4.3.3/f951 ma57.f -ffixed-form -quiet -dumpbase ma57.f -mtune=generic -auxbase-strip ma57.o -O2 -version -ftree-parallelize-loops=2 -fintrinsic-modules-path /localdata/lib/gcc/i686-pc-linux-gnu/4.3.3/finclude -o /tmp/ccHYlhlQ.s GNU F95 (GCC) version 4.3.3 (i686-pc-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3, MPFR version 2.4.1-p5. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Is anyone interested in fixing this? I think it would not infringe the spirit of license agreement, if I provided someone off-list with the source _for debugging purposes only_. -- dennis dot wassel at googlemail dot com changed: What|Removed |Added CC||dennis dot wassel at ||googlemail dot com Version|4.3.2 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING and TYPEs
--- Comment #3 from dennis dot wassel at googlemail dot com 2009-05-04 08:55 --- Also fails with 4.3.3: gfortran -v pr37744.f90 Driving: gfortran -v pr37744.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' /localdata/libexec/gcc/i686-pc-linux-gnu/4.3.3/f951 pr37744.f90 -quiet -dumpbase pr37744.f90 -mtune=generic -auxbase pr37744 -version -fintrinsic-modules-path /localdata/lib/gcc/i686-pc-linux-gnu/4.3.3/finclude -o /tmp/ccQTr6UN.s GNU F95 (GCC) version 4.3.3 (i686-pc-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3, MPFR version 2.4.1-p5. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 pr37744.f90:22.19: foo%flags(trouble) = .FALSE._C_BOOL 1 Error: Symbol 'trouble' at (1) has no IMPLICIT type f951: internal compiler error: Segmentation fault -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Known to fail|4.3.2 4.4.0 |4.3.2 4.3.3 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #5 from rguenther at suse dot de 2009-05-04 09:01 ---
Subject: Re: [4.5.0 Regression] Revision 147083 failed
gfortran.dg/array_memcpy_4.f90
On Mon, 4 May 2009, dominiq at lps dot ens dot fr wrote:
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59
---
This test has been introduced by the patch in
http://gcc.gnu.org/ml/fortran/2007-01/msg00425.html.
The tests gfortran.dg/array_memcpy_[1-3].f90 use
! { dg-final { scan-tree-dump-times memcpy * original } }
So a simple fix would be to replace
! { dg-final { scan-tree-dump-times d = 1 original } }
with
! { dg-final { scan-tree-dump-times memcpy 1 original } }
but I don't understand why array_memcpy_4.f90 used to give a different
construct and this change could mask a more serious problem.
I will investigate - we really should get the memcpy removed.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING and TYPEs
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 09:06 --- Also ICE on trunk r147065 powerpc-apple-darwin9 or r147085 i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #1 from pault at gcc dot gnu dot org 2009-05-04 09:10 --- Dominique, Thanks for setting this up. I'll poll everybody involved for contributions and have assigned myself the bug(s). Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 09:10:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #2 from pault at gcc dot gnu dot org 2009-05-04 09:29 --- see PR40006: allow type cheating for procedures with an implicit interface -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||40006 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-04 09:41 --- (In reply to comment #6) We can compute the maximum possible function length first. If the length is not large enough far jump is not necessary, and we can do this optimization safely. No, it's not that easy, since reload can add instructions. Realistically, there is a finite limit beyond which even reload couldn't generate sufficiently large numbers of instructions to cause failure, but it's hard to *prove* what that lower bound is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #3 from pault at gcc dot gnu dot org 2009-05-04 09:31 --- ...and PR39896 : ICE with -fwhole-file -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39896 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #8 from carrot at google dot com 2009-05-04 10:08 --- Sorry for my ignorance to gcc. What types of instructions reload will add? Spilling and loading registers? and more? By reading the the implementation of thumb_far_jump_used_p() I can get the conclusion that if reload thinks there is a far jump, later pass won't change this decision. But if reload thinks there is no far jump, later pass still need to re-check the far jump existence and may change this decision. So if reload occasionally makes a wrong decision later pass should correct it, is it right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #5 from pault at gcc dot gnu dot org 2009-05-04 10:19 --- (In reply to comment #2) It may be worth noting that there are no warnings in the application about labels not being in the same block as the corresponding GOTO if compiled without -fwhole-file, but if compiled with -fwhole-file some of these warnings appear. If these warnings are missed without -fwhole-file or spurious with -fwhole-file, I can not say yet. I'll try to get a testcase ... For some reason that I do not see right now, cs_base in resolve.c is not being pushed or popped correctly. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-04 09: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|NEW |ASSIGNED Last reconfirmed|2009-05-04 05:54:58 |2009-05-04 09:25:57 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59 ---
This test has been introduced by the patch in
http://gcc.gnu.org/ml/fortran/2007-01/msg00425.html.
The tests gfortran.dg/array_memcpy_[1-3].f90 use
! { dg-final { scan-tree-dump-times memcpy * original } }
So a simple fix would be to replace
! { dg-final { scan-tree-dump-times d = 1 original } }
with
! { dg-final { scan-tree-dump-times memcpy 1 original } }
but I don't understand why array_memcpy_4.f90 used to give a different
construct and this change could mask a more serious problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c++/40013] [4.4 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.3 Summary|[4.4 regression] ICE when |[4.4 Regression] ICE when |creating a local array with |creating a local array with |size from the return value |size from the return value |of a member function of an |of a member function of an |object in a nested class in |object in a nested class in |a template class|a template class Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #6 from pault at gcc dot gnu dot org 2009-05-04 10:31 --- For some reason that I do not see right now, cs_base in resolve.c is not being pushed or popped correctly. Ah yes! resolve_codes nulls out cs_base. The problem is fixed by storing cs_base before calling gfc_resolve, at line 1674, and then restoring the value afterwards. It might be cleaner to do this in gfc_resolve - I'll check later. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #7 from pault at gcc dot gnu dot org 2009-05-04 10:32 --- I guess that I should take it :-) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 10:32:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-04 11:02 --- Subject: Bug 40015 Author: rguenth Date: Mon May 4 11:01:59 2009 New Revision: 147094 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147094 Log: 2009-05-04 Richard Guenther rguent...@suse.de PR middle-end/40015 * builtins.c (fold_builtin_memory_op): Do not decay to element type if the size matches the whole array. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c++/40013] [4.4 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 11:26 --- http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00116.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 11:26:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug bootstrap/39968] [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 11:42 --- This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #3 to #5, I don't close it as fixed. If someone wants to keep this PR open, (s)he should change subject and priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-apple-darwin9 and powerpc-ibm-aix
--- Comment #15 from dominiq at lps dot ens dot fr 2009-05-04 11:45 --- This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #11 to #13, I don't close it as fixed. If someone wants to keep this PR open, (s)he should change subject, platform, and priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-04 12:43 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c++/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #9 from manu at gcc dot gnu dot org 2009-05-04 12:48 --- Subject: Bug 28152 Author: manu Date: Mon May 4 12:47:53 2009 New Revision: 147097 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147097 Log: 2009-05-04 Manuel Lopez-Ibanez m...@gcc.gnu.org PR c++/28152 cp/ * parser.c (cp_lexer_get_preprocessor_token): Do not store the canonical spelling for keywords. (cp_parser_attribute_list): Use the canonical spelling for keywords in attributes. testsuite/ * g++.dg/parse/parser-pr28152.C: New. * g++.dg/parse/parser-pr28152-2.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/parser-pr28152-2.C trunk/gcc/testsuite/g++.dg/parse/parser-pr28152.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c++/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #10 from manu at gcc dot gnu dot org 2009-05-04 12:49 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c/40016] New: regex_internal.h:185: error: integer overflow in preprocessor expression
Hi, when i compiling gnu parted 1.8.8 with gcc 4.5.0, got error include regex.i TIA = /bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -I. -Os -Werror -MT regex.lo -MD -MP -MF .deps/regex.Tpo -c -o regex.lo regex.c gcc -std=gnu99 -I. -Os -Werror -MT regex.lo -MD -MP -MF .deps/regex.Tpo -c regex.c -fPIC -DPIC -o .libs/regex.o cc1: warnings being treated as errors In file included from regex.c:58: regex_internal.h:185: error: integer overflow in preprocessor expression make[2]: *** [regex.lo] Error 1 make[2]: Leaving directory `/home/user/d/parted-1.8.8/lib' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/user/d/parted-1.8.8/lib' make: *** [all-recursive] Error 1 bash-4.0$ cc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap --disable-multilib Thread model: posix gcc version 4.5.0 20090503 (experimental) (GCC) bash-4.0$ -- Summary: regex_internal.h:185: error: integer overflow in preprocessor expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: happyarch at gmail dot com GCC build triplet: x86_64 GCC host triplet: x86_64 GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug c/40016] regex_internal.h:185: error: integer overflow in preprocessor expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-04 14:23 --- Works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug target/40017] New: [4.4/4.5 Regression] stdbool.h/altivec.h
#include stdbool.h
#include altivec.h
vector bool int b;
int
main (void)
{
return 0;
}
used to compile up to 4.3, doesn't any longer. I wonder what can be done here
though, for C++ with the conditional macros bool keywords can coexist well with
the context sensitive keywords, but unfortunately #define bool _Bool
kills the conditional keyword behavior.
--
Summary: [4.4/4.5 Regression] stdbool.h/altivec.h
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug bootstrap/39849] [4.3/4.4 Regression] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #8 from dennis dot wassel at googlemail dot com 2009-05-04 14:18 --- Marked as 4.3/4.4 regression. What should I try next? Need I provide any additional info? Any help is much appreciated! -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Severity|normal |major Summary|segfault for '__divtf3' |[4.3/4.4 Regression] |during bootstrap and non- |segfault for '__divtf3' |bootstrap install |during bootstrap and non- ||bootstrap install http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug bootstrap/39849] [4.3/4.4 Regression] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-04 14:28 --- Do not set CFLAGS in make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' profiledbootstrap or specify your host compiler version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-04 14:29 --- It obviously works for me, you system seems to be messed up / special. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 Regression]|segfault for '__divtf3' |segfault for '__divtf3' |during bootstrap and non- |during bootstrap and non- |bootstrap install |bootstrap install | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 14:30 --- I'd say handling _Bool the same way as bool after vector would be a good idea. It has a disadvantage that in addition to the (I'd say desirable): #include stdbool.h #include altivec.h ... vector bool int i; also vector _Bool int i; would be accepted, but the advantages IMHO outweight disadvantages. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org, ||bje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-04 14:32 --- Yes that seems like the right idea; the altivec specs was written before C99 was out. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #13 from dennis dot wassel at googlemail dot com 2009-05-04 14:55 --- I just noticed/remembered that [x]gcc only drives the compilers, so I plugged cc1 into gdb and here is the (somewhat messy, slightly edited) result: gdb /localdata/install/gcc/gcc-4.4.0-build/./gcc/cc1 GNU gdb 6.8 This GDB was configured as i686-pc-linux-gnu... run -quiet -v -I. -I. -I../.././gcc -I../../../gcc-4.4.0/libgcc -I../../../gcc-4.4.0/libgcc/. -I../../../gcc-4.4.0/libgcc/../gcc -I../../../gcc-4.4.0/libgcc/../include -I../../../gcc-4.4.0/libgcc/config/libbid -iprefix /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/ -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include-fixed -MD divtf3.d -MF divtf3.dep -MP -MT divtf3.o -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -DHIDE_EXPORTS -isystem /localdata/i686-pc-linux-gnu/include -isystem /localdata/i686-pc-linux-gnu/sys-include -isystem ./include ../../../gcc-4.4.0/libgcc/../gcc/config/soft-fp/divtf3.c -quiet -dumpbase divtf3.c -mtune=generic -auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wcast-qual -Wold-style-definition -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -fvisibility=hidden -o /tmp/ccuJ4Jyu.s Starting program: /localdata/install/gcc/gcc-4.4.0-build/gcc/cc1 -quiet -v -I. -I. -I../.././gcc -I../../../gcc-4.4.0/libgcc -I../../../gcc-4.4.0/libgcc/. -I../../../gcc-4.4.0/libgcc/../gcc -I../../../gcc-4.4.0/libgcc/../include -I../../../gcc-4.4.0/libgcc/config/libbid -iprefix /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/ -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include-fixed -MD divtf3.d -MF divtf3.dep -MP -MT divtf3.o -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -DHIDE_EXPORTS -isystem /localdata/i686-pc-linux-gnu/include -isystem /localdata/i686-pc-linux-gnu/sys-include -isystem ./include ../../../gcc-4.4.0/libgcc/../gcc/config/soft-fp/divtf3.c -quiet -dumpbase divtf3.c -mtune=generic -auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wcast-qual -Wold-style-definition -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -fvisibility=hidden -o /tmp/ccuJ4Jyu.s Failed to read a valid object file image from memory. ignoring nonexistent directory /localdata/i686-pc-linux-gnu/include ignoring nonexistent directory /localdata/i686-pc-linux-gnu/sys-include ignoring nonexistent directory ./include ignoring nonexistent directory /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/include ignoring nonexistent directory /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed ignoring nonexistent directory /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include ignoring nonexistent directory /localdata/lib/gcc/i686-pc-linux-gnu/4.4.0/include ignoring nonexistent directory /localdata/lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed ignoring nonexistent directory /localdata/lib/gcc/i686-pc-linux-gnu/../../../i686-pc-linux-gnu/include ignoring duplicate directory . ignoring duplicate directory ../../../gcc-4.4.0/libgcc/. #include ... search starts here: #include ... search starts here: . ../.././gcc ../../../gcc-4.4.0/libgcc ../../../gcc-4.4.0/libgcc/../gcc ../../../gcc-4.4.0/libgcc/../include ../../../gcc-4.4.0/libgcc/config/libbid /localdata/install/gcc/gcc-4.4.0-build/./gcc/include /localdata/install/gcc/gcc-4.4.0-build/./gcc/include-fixed /usr/local/include /localdata/include /usr/include End of search list. GNU C (GCC) version 4.4.0 (i686-pc-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3, MPFR version 2.4.1-p5. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: ac242e6eff36fdeb132b194aac7540a7 Program received signal SIGSEGV, Segmentation fault. 0x0816a5ba in c_tree_printer (pp=0x9e3d288, text=0xbfd3ca04, spec=0x9e23129 D, precision=0, wide=0 '\0', set_locus=0 '\0', hash=0 '\0') at ../../gcc-4.4.0/gcc/c-objc-common.c:99 99tree t = va_arg (*text-args_ptr, tree); (gdb) bt #0 0x0816a5ba in c_tree_printer (pp=0x9e3d288, text=0xbfd3ca04, spec=0x9e23129 D, precision=0, wide=0 '\0', set_locus=0 '\0', hash=0 '\0') at ../../gcc-4.4.0/gcc/c-objc-common.c:99 #1 0x088568b4 in pp_base_format (pp=0x9e3d288, text=0xbfd3ca04) at ../../gcc-4.4.0/gcc/pretty-print.c:557 #2 0x083cc846 in diagnostic_report_diagnostic (context=0x9dc3aa0, diagnostic=0xbfd3ca04) at ../../gcc-4.4.0/gcc/diagnostic.c:402 #3 0x083ccbb1 in
[Bug bootstrap/38523] [4.4/4.5 regression] arm build fails to link cc1-dummy
--- Comment #21 from laurent at guerby dot net 2009-05-04 14:50 --- No objection in one week, so closing as WORKSFORME with binutils from CVS = 20090423 -- laurent at guerby dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #15 from dennis dot wassel at googlemail dot com 2009-05-04 15:09 --- Created an attachment (id=17796) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17796action=view) Preprocessed source Sure! Attaching preprocessed source of gcc-4.4.0/gcc/config/soft-fp/divtf3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug c/40016] regex_internal.h:185: error: integer overflow in preprocessor expression
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:52 --- Not surprisingly when the error is during preprocessing. regex.h parted ships (why?) is broken by the #elif changes, there is: #if some_condition_that_is_true_on_sane_targets ... #elif BITSET_WORD_MAX == (0x + 2) * 0x /* Work around a bug in 64-bit PGC (before version 6.1-2), where the preprocessor mishandles large unsigned values as if they were signed. */ ... #endif To make GCC happy about this at least the #elif should be changed into #else #if ... #endif. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-05-04 15:00 --- Yes slightly, it is trying to warn about something which is unitialized. This works for me on i686-linux-gnu. Can you provide the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug ada/38874] gnatmake doesn't pass through --param options
--- Comment #3 from guerby at gcc dot gnu dot org 2009-05-04 15:32 --- Subject: Bug 38874 Author: guerby Date: Mon May 4 15:32:00 2009 New Revision: 147102 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147102 Log: 2009-05-04 Laurent GUERBY laur...@guerby.net PR ada/38874 * make.adb (Scan_Make_Arg): Pass --param= to compiler and linker. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/make.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38874
[Bug bootstrap/39977] [4.5 Regression] r146817 broke bootstrap on PA
--- Comment #7 from danglin at gcc dot gnu dot org 2009-05-04 15:35 --- The patch from comment #4 was installed here: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00018.html From my perspective, this fixes the 4.5 regression reported here. Possibly the change should be back ported to fix PR 29209. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #8 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04 15:41 --- Oops... forgot about that bit, sorry. Compile flags: -m32 -O3 -mcpu=power[4|5|6] -ffast-math -ftree-loop-linear -funroll-loops -fpeel-loops This reproduces on both 32-bit and 64-bit. Luis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #9 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04 15:50 --- Follows the configure options, although i think you'll be able to reproduce it with the flags i've mentioned. /gcc/HEAD/configure --target=powerpc64-linux --host=powerpc64-linux --build=powerpc64-linux --with-cpu=default32 --enable-threads=posix --enable-shared --enable-__cxa_atexit --with-gmp=/gmp --with-mpfr=mpfr --with-long-double-128 --enable-decimal-float --enable-secure-plt --disable-bootstrap --disable-alsa --prefix=/install/gcc/HEAD build_alias=powerpc64-linux host_alias=powerpc64-linux target_alias=powerpc64-linux --enable-languages=c,c++,fortran --no-create --no-recursion -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #11 from dennis dot wassel at googlemail dot com 2009-05-04 14:35 --- (In reply to comment #9) Do not set CFLAGS in make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' profiledbootstrap This ^ was only in my first iteration, and I've omitted it in the following ones. My last (unsuccessful) attempt was a plain: ../gcc-4.4.0/configure --prefix=/localdata --program-suffix=-4.4.0 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --with-ppl=/localdata --with-cloog=/localdata --enable-version-specific-runtime-libs make and nothing out of the ordinary. or specify your host compiler version. My host compiler is gcc 4.3.3 gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-04
13:48 ---
Subject: Re: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
Which pass? p *pass in frame 20 should tell you.
(gdb) p *pass
$1 = {type = GIMPLE_PASS, name = 0x27bb734 forwprop,
gate = 0x152d6d4 gate_forwprop,
execute = 0x152cc8c tree_ssa_forward_propagate_single_use_vars, sub = 0x0,
next = 0x2a806c8, static_pass_number = 123, tv_id = TV_TREE_FORWPROP,
properties_required = 40, properties_provided = 0, properties_destroyed = 0,
todo_flags_start = 0, todo_flags_finish = 2055}
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #7 from matz at gcc dot gnu dot org 2009-05-04 14:37 --- Compile options please. I can't reproduce it with a powerpc64 compiler with -O2, neither with -m32 nor -m64, -ffast-math or no -ffast-math. Also 'gcc -v' can't hurt to make sure our compilers are configured the same. Hint: I use this command to quickly skim over the situation with labels and bdnz: % egrep '^.L|bdnz' thin6d.s If the bdnz lines always mention the label from a line above it's a single basic block loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug c/40016] regex_internal.h:185: error: integer overflow in preprocessor expression
--- Comment #1 from happyarch at gmail dot com 2009-05-04 13:59 --- Created an attachment (id=17795) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17795action=view) .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #10 from matz at gcc dot gnu dot org 2009-05-04 16:10 --- Yes, I can now, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #12 from dennis dot wassel at googlemail dot com 2009-05-04 14:43 --- (In reply to comment #10) It obviously works for me, you system seems to be messed up / special. Seems so, although it is a Debian 4 with an unknown amount of modifications by our admin. One symptom of specialness is the fact that neither the system nor the gcc's headers define SSIZE_MAX, but I have a workaround for that (namely defining it as SHRT_MAX in config/host-linux.c, if it is undefined). Shall I dig around somewhere to find out the exact amount of my system's specialness? Is there a way to build the bootstrap compiler with debugging info, so I can use gdb to figure out where the segfault happens? PS: I think this *is* a regression, because I can build 4.3, but not 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:39 --- _Bool would need to be a conditional macro too though, I wonder if some ISO C99 pedantry can't test that _Bool isn't defined or something like that. But then for C++ it is similar with defined(bool) also being true with -maltivec instead of false. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #6 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04 13:50 --- Just for the sake of information, -fselective-scheduling doesn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 17:54 --- With thee patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html without type cheating, all the ICEs in my tests are gone. It even fixes pr37744!-(it may give a clue on how to fix it without -fwhole-file). For the test arr_fun.f90, I now get: arr_fun.f90:10.6: res = test(2) 1 Error: The reference to function 'test' at (1) either needs an explicit INTERFACE or the rank is incorrect which seems right (without -fwhole-file I get a bus error at run time). Test gcc/testsuite/gfortran.dg/hollerith.f90 and friends won't probably pass regtesting: call test (8h hello) 1 Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8) I have to run the polyhedron tests and to regtest, so it is all for this time. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-05-04 18:08 --- Paul, your patch fixes all issues I came across when compiling my largish set of fortran sources with -fwhole-file. So, now I just need to sort out all the warnings that came up *cough* ;) Many thanks! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2009-05/msg00046.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug fortran/40018] New: ICE in output_constructor
$ cat a.f90 integer(kind=8) :: i write(*,*) [(i, i = 1, 10)] end $ gfortran a.f90 a.f90:2: internal compiler error: in output_constructor, at varasm.c:4712 The GDB backtrace is: #0 fancy_abort (file=0xd7999a ../../trunk/gcc/varasm.c, line=4716, function=0xd792d0 output_constructor) at ../../trunk/gcc/diagnostic.c:723 #1 0x0094b762 in output_constructor (exp=value optimized out, size=value optimized out, align=value optimized out) at ../../trunk/gcc/varasm.c:4716 #2 0x009bec65 in varpool_assemble_decl (node=0x2ace99df7a40) at ../../trunk/gcc/varpool.c:364 #3 0x0098f991 in cgraph_output_in_order () at ../../trunk/gcc/cgraphunit.c:1202 #4 0x00991622 in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1318 #5 0x005125e5 in gfc_be_parse_file (set_yydebug=value optimized out) at ../../trunk/gcc/fortran/f95-lang.c:237 #6 0x007e0324 in toplev_main (argc=2, argv=0x7fff143ae1b8) at ../../trunk/gcc/toplev.c:977 Happens on x86_64-linux with current trunk (rev. 147105), and i686-apple-darwin9 rev. 144983. -- Summary: ICE in output_constructor Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org OtherBugsDependingO 32834 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug fortran/40018] ICE in output_constructor
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-04 19:19 --- Confirmed on trunk and 4.4.0. Works with 4.3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug fortran/40019] New: LEADZ and TRAILZ give wrong results
LEADZ and TRAILZ can give wrong results for kinds other than 4 and 8. For example, the following code: integer(kind=1) :: i1 integer(kind=2) :: i2 integer(kind=4) :: i4 integer(kind=8) :: i8 integer(kind=16) :: i16 i1 = -1 i2 = -1 i4 = -1 i8 = -1 i16 = -1 print *, leadz(i1), leadz(i2), leadz(i4), leadz(i8), leadz(i16) gives -24 -16 0 0 64 as results, while it should only yield zeros! There are a few reasons: - for kinds 1 and 2, we should not cast directly to (unsigned int), but do a double cast: (unsigned int)(unsigned char) for kind=1, for example; otherwise, negative values are screwed. - trans-intrinsic.c uses a correspondance, kinds == 1, 2 and 4 use BUILT_IN_CLZ, kind 8 uses BUILT_IN_CLZL and kind 16 uses BUILT_IN_CLZLL; in reality, there is no such correspondance, as kind==16 is larger than long long! This, of course, makes it harder, because there is no function ready for use in kind==16. -- Summary: LEADZ and TRAILZ give wrong results Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40019
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-04 19:37
---
About POPCNT and POPPAR, beware! Implementations are much harder than simply
using the GCC __builtin_popcount{,l,ll}: see PR40019 for similar issue with
LEADZ and TRAILZ.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug c/33466] mixed-case suffix for decimal float constants
--- Comment #10 from janis at gcc dot gnu dot org 2009-05-04 19:50 --- Fixed for trunk, expected to become GCC 4.5.0. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted
--- Comment #5 from janis at gcc dot gnu dot org 2009-05-04 19:55 --- This was fixed in trunk, expected to become GCC 4.5.0, on 2009-04-01 as revision 145422. The ChangeLog entries have the correct PR number but the svn log messages use 29027, which is why the checkins were not recorded here. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug fortran/39772] add a correctness check for the size intrinsic to -fbounds-check
--- Comment #10 from mikael at gcc dot gnu dot org 2009-05-04 20:24 --- cf PR36462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
[Bug fortran/39971] kinds.h fails at building libgfortran
--- Comment #13 from mikael at gcc dot gnu dot org 2009-05-04 20:27 --- (In reply to comment #12) don't know how to use it to compile gcc being a normal user (no root privileges) without scrambling everything else. Any help on this direction? Thanks export LD_LIBRARY_PATH=/your/libc/path ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39971
[Bug middle-end/39973] [4.5 Regression] Revision 146817 miscompiled 416.gamess in SPEC CPU 2006
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 20:44 --- blas.fppized.f was miscompiled by -m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
[Bug middle-end/39972] [4.5 Regression] Revision 146817 miscompiled 465.tonto in SPEC CPU 2006
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 20:52 --- blas.f90 was miscompiled by -m32 -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
[Bug target/39986] decimal float constant is incorrect when cc1 is a 64-bit binary
--- Comment #3 from janis at gcc dot gnu dot org 2009-05-04 21:24 --- On x86_64 with a 64-bit compiler, positive decimal float constants are OK, negative decimal float constants are wrong for both -m64 (the default) and -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39986
[Bug fortran/40020] New: Bad value during floating point read
I tried to migrate well running program from g77 to gfortran. I found a problem with new gfortan: Fortran runtime error: Bad value during floating point read to read REAL from file. read(nin,'(6e11.0)') a and numbers were: 7.73118- 3 4.26617+ 0 8.17285- 3 ... It helps to add number '0' to exponent instead of space 7.73118-03 4.26617+00 8.17285-03 ... Input decks are very old so I'm not sure if it was some feature off g77. -- Summary: Bad value during floating point read Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ased at cce dot cz 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=40020
[Bug middle-end/40021] New: [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
On Linux/ia32, revision 146817 miscompiled DAXPY in BLAS with -m32 O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form -- Summary: [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-04 21:52 --- With the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html gas_dyn.f90 fails as in commet #0, except for -O1: [ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90 gas_dyn.f90: In function 'chozdt': gas_dyn.f90:216: internal compiler error: Bus error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-04 21:52 --- *** Bug 39972 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/39972] [4.5 Regression] Revision 146817 miscompiled 465.tonto in SPEC CPU 2006
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-04 21:52 --- *** This bug has been marked as a duplicate of 40021 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
[Bug middle-end/39973] [4.5 Regression] Revision 146817 miscompiled 416.gamess in SPEC CPU 2006
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 21:53 --- *** This bug has been marked as a duplicate of 40021 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-04 21:53 --- *** Bug 39973 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug fortran/40020] Bad value during floating point read
--- Comment #1 from kargl at gcc dot gnu dot org 2009-05-04 22:17 --- (In reply to comment #0) I tried to migrate well running program from g77 to gfortran. I found a problem with new gfortan: Fortran runtime error: Bad value during floating point read to read REAL from file. read(nin,'(6e11.0)') a and numbers were: 7.73118- 3 4.26617+ 0 8.17285- 3 ... It helps to add number '0' to exponent instead of space 7.73118-03 4.26617+00 8.17285-03 ... Input decks are very old so I'm not sure if it was some feature off g77. Works fine with 4.5.0 and I suspect 4.4.0. Please try 4.4.0. REMOVE:kargl[30] gfc4x -o z gf.f90 REMOVE:kargl[31] ./z 0.12345e- 3 1.23449994E-04 REMOVE:kargl[32] gfc43 -o z gf.f90 REMOVE:kargl[33] ./z 0.12345e- 3 At line 3 of file gf.f90 (unit = 5, file = 'stdin') Fortran runtime error: Bad value during floating point read REMOVE:kargl[34] cat gf.f90 program gf real x read(*,'(e11.0)') x write(*,*) x end program gf -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40020
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 22:20 ---
Regtest gives:
=== gfortran Summary ===
# of expected passes117714
# of unexpected failures576
# of expected failures 78
# of unsupported tests 906
for RUNTESTFLAGS=--target_board=unix'{,-m64,/-fwhole-file,-m64/-fwhole-file}'
with no unexpected failures for {,-m64}. 444 failures come from
cc1: warning: command line option -fwhole-file is valid for Fortran but not
for C
I think I know how to filter them.
--- generic_actual_arg.f90 fails with
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/generic_actual_arg.f90:40.64:
CALL F(CALCULATION2) ! OK because there is a same name specific
1
Error: More actual than formal arguments in procedure call at (1)
False positive?
--- global_references_1.f90 fails with
SUBROUTINE j (x)! { dg-error is already being used as a FUNCTION }
2
Error: Global name 'j' at (1) is already being used as a SUBROUTINE at (2)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:39.6:
T = j () ! { dg-error is already being used as a FUNCTION }
1
Error: Missing actual argument for argument 'x' at (1)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:68.64:
--- hollerith.f90 fails with
call test (8h hello)
1
Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8)
--- hollerith_legacy.f90 same failure
--- import6.f90 fails with
opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13:
call func1(x)
1
Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to
TYPE(my_type)
Obviously some tests will require adjustments to pass with -fwhole-file.
More tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug libstdc++/39382] FAIL: abi_check on trunk revision 144629
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-05-04 22:33 --- No feedback. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39382
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-04 22:44 --- Also gfortran.dg/contained_3.f90 is miscompiled with -fwhole-file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 23:07 --- Created an attachment (id=17797) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17797action=view) A testcase [...@gnu-33 pr40021]$ make /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form test.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form daxpy.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -Wl,-rpath,/export/gnu/import/rrs/146817/usr/lib -o daxpy test.o daxpy.o ./daxpy 2 -2.20932289958000183E-002 != -2.22017297318430201E-002 4.88703976462625395E-003 [...@gnu-33 pr40021]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug c/40022] New: 4.4 regression breaks reply to all in alpine
Hello, I have to admit I'm clueless about how to debug this.
On Fedora 11 preview release with gcc-4.4.0 alpine reply to all
does not include the list of cc'd addresses. Linus found that if
you compile the pith/reply.cc without optimizations it works
properly (see Fedora bug report at
http://bugzilla.redhat.com/show_bug.cgi?id=496400 ).
Here is how to reproduce:
mkdir alpinetest
cd alpinetest
svn checkout https://svn.cac.washington.edu/public/alpine/snapshots/
cd snapshots
_sysconfdir=/etc/
touch imap/ip6
./configure \ --enable-debug=no \
--without-tcl \
--with-c-client-target=lfd \
--with-passfile=.alpine.passfile \
--with-spellcheck-prog=aspell \
--with-system-pinerc=%{_sysconfdir}/pine.conf \
--with-system-fixed-pinerc=%{_sysconfdir}/pine.conf.fixed
make
alpine/alpine # try Reply to all and see bug
cd pith
make clean make CFLAGS=-O0
cd ..
make
alpine/alpine # try Reply to all and see it working
--
Summary: 4.4 regression breaks reply to all in alpine
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joshuadfranklin at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 23:09 --- The vectorizer seems broken: /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize -msse2 -mfpmath=sse -ffast-math -ffixed-form test.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize -msse2 -mfpmath=sse -ffast-math -ffixed-form daxpy.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -Wl,-rpath,/export/gnu/import/rrs/146817/usr/lib -o daxpy test.o daxpy.o ./daxpy 2 -2.20932289958000183E-002 != -2.22017297318430201E-002 4.88703976462625395E-003 [...@gnu-33 pr40021]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-04 23:16 --- Hmm, so -fwrapv and -fno-strict-aliasing fixes the problem which case it might be a bug in the source. Can you provide the preprocessed source of pith/reply.cc? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
--- Comment #2 from joshuadfranklin at yahoo dot com 2009-05-04 23:36 --- Created an attachment (id=17798) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17798action=view) alpine pith/reply.c compiled with O0 and save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
-- joshuadfranklin at yahoo dot com changed: What|Removed |Added CC||joshuadfranklin at yahoo dot ||com Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-04 23:55 --- That is the assembler that is produced not the preprocessed source, use -save-temps and attach the .ii file. Thanks, Andrew Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
