Re: 4.3 release plan
On Sun, May 20, 2007 at 10:39:43PM -0700, Brooks Moses wrote: Bernardo Innocenti wrote: (the next proposal is likely to cause some dissent) What about moving 4.3 to stage 3 *now* and moving everything else in 4.4 instead? Hopefully, it will be a matter of just a few months. From http://gcc.gnu.org/gcc-4.3/changes.html, it looks like it would already be quite a juicy release. Why? I mean, I suppose there could be advantages to doing this, but you haven't mentioned even one. I think a few people (me!) are waiting for GCJ to have official support for Java 5 syntax and class libraries. Not that I would like to rush you - or skip any valuable merges - but if the code that is in right now is in a near ready state, waiting up to a year before releasing seems unfortunate. :-( Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Re: Is FTZ/DAZ for SSE via fast math available for x86 arch other than Linux?
Hi Zuxy Meng [EMAIL PROTECTED] дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED] Hi, 2007/3/11, Danny Smith [EMAIL PROTECTED]: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zuxy Meng Sent: Wednesday, 7 March 2007 12:36 a.m. I've uploaded a proposed patch for this bug (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151action=diff). Putting crtfastmath.o in the endfile section of specs causes undefined reference to memset, so I moved it to the startfile section. Anyone to review this? Quite trivial anyway. Hello Zuxy, crtfasmath.o is an endfile for a reason. _set_fast_math is run from the .ctors section. It needs to be run before other constructors that might use fastmath, so is made an end ctor (ctors are run from right to left). The reference to memset does not occur on trunk with optimization. It can be avoided with 4.2.0 by adding -minline-all-stringops to rule for (T)crtfastmath.o Maybe such optimization isn't turned on for mingw. I updated the patch to force this by using -minline-all-stringops. http://gcc.gnu.org/bugzilla/attachment.cgi?id=13189 Any developer to have a look at this? -- Zuxy
Re: Is FTZ/DAZ for SSE via fast math available for x86 arch other than Linux?
Hello! Maybe such optimization isn't turned on for mingw. I updated the patch to force this by using -minline-all-stringops. http://gcc.gnu.org/bugzilla/attachment.cgi?id=13189 Any developer to have a look at this? Please post the patch to [EMAIL PROTECTED] Also add appropriate ChangeLog and a reference to the PR. I can find the patch, but can't find the PR from your message. Patch contribution procedure is described in great detail at http://gcc.gnu.org/contribute.html. Thanks, Uros.
Re: Is FTZ/DAZ for SSE via fast math available for x86 arch other than Linux?
Hi, 2007/5/21, Uros Bizjak [EMAIL PROTECTED]: Hello! Maybe such optimization isn't turned on for mingw. I updated the patch to force this by using -minline-all-stringops. http://gcc.gnu.org/bugzilla/attachment.cgi?id=13189 Any developer to have a look at this? Please post the patch to [EMAIL PROTECTED] Also add appropriate ChangeLog and a reference to the PR. I can find the patch, but can't find the PR from your message. It's PR 29498. Thanks! Patch contribution procedure is described in great detail at http://gcc.gnu.org/contribute.html. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Re: A reload inheritance bug
On Tue, May 15, 2007 at 04:27:21PM +0100, Mark Shinwell wrote: Part of the reason for starting this thread was that I was concerned about invalidating reloads that could be re-used later. However, it seems to me that in every circumstance where the reload register is a hard register and the value assigned to that reload register is different from the value held by the register during the evaluation of the subexpression being reloaded (as we have here with r9 - r9 + r10), we must invalidate all previous reloads involving that hard register. I may well have encoded that logic incorrectly in the patch, though. I'd say try the usual testing procedure with the addition of saving away libgcc, newlib, libiberty etc. for code size comparison. If you find any, at least we'll be that much wiser. -- Rask Ingemann Lambertsen
Basic block execution records in gprof
Hello all, According to GNU gprof manual http://www.gnu.org/software/binutils/manual/gprof-2.9.1/html_chapter/gprof_5.html#SEC18 basic-block counting can be analyzed with gprof if a program is augmented for that.For this the program is to be compiled with `gcc ... -g -pg -a' option . But '-a' option has been replaced with -fprofile-arcs and with this options the output files are actually produced for gcov. But GNU C library has code for printing basic block records on to gmon.out file. So is it possible to do the above with gprof ? If it is possible with is the option that has to be used when compiling the program? Thanks for your time. Regards, Shafi
a question regarding ifcvt.c
Hi, I'd like to get an explanation why ifcvt.c checks whether 1 of the 2 successors of the IF-header block has a stmt that exits from the loop? Why does it prevent the if-conversion? I'm referring to the following code: /* Nor exit the loop. */ if ((then_edge-flags EDGE_LOOP_EXIT) || (else_edge-flags EDGE_LOOP_EXIT)) return NULL; Thanks, Tehila.
A question about push_reload()
I think push_reload() is doing something weird with this insn:
Breakpoint 1, find_reloads (insn=0xb7f7e348, replace=0, ind_levels=0,
live_known=0, reload_reg_p=0x8878a7c) at ../../../cvssrc/gcc/gcc/reload.c:2535
2535{
(gdb) call debug_rtx(insn)
(insn 12 10 16 2 /tmp/ashiftsi3_1.c:3 (parallel [
(set (subreg:HI (reg:SI 2 a [orig:20 D.1497 ] [20]) 0)
(ashift:HI (reg:HI 8 si [orig:26 x ] [26])
(const_int 1 [0x1])))
(clobber (reg:CC 13 cc))
]) 353 {*ashlhi3} (nil)
(expr_list:REG_DEAD (reg:HI 8 si [orig:26 x ] [26])
(expr_list:REG_UNUSED (reg:CC 13 cc)
(insn_list:REG_RETVAL 13 (nil)
where operands 0 and 1 must match. The resulting reloads are:
Spilling for insn 12.
Using reg 8 for reload 0
Reloads for insn # 12
Reload order: 0
Reload 0: reload_in (HI) = (reg:HI 26 [ x ])
reload_out (SI) = (reg:SI 2 a [orig:20 D.1497 ] [20])
GENERAL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (reg:HI 26 [ x ])
reload_out_reg: (reg:SI 2 a [orig:20 D.1497 ] [20])
reload_reg_rtx: (reg:SI 8 si)
;; Register dispositions:
20 in 2 21 in 8 22 in 9 23 in 2 24 in 0 25 in 0
It seems unnecessary to create a SImode output reload here and worse, it
clobbers (reg:HI 4 d) which is live ((reg:SI 2 a) is four registers):
(insn 40 10 12 2 /tmp/ashiftsi3_1.c:3 (set (reg:HI 8 si)
(mem/c:HI (plus:HI (reg/f:HI 10 bp)
(const_int -2 [0xfffe])) [0 S2 A8])) 9 {*movhi} (nil)
(nil))
(insn 12 40 41 2 /tmp/ashiftsi3_1.c:3 (parallel [
(set (reg:HI 8 si)
(ashift:HI (reg:HI 8 si)
(const_int 1 [0x1])))
(clobber (reg:CC 13 cc))
]) 353 {*ashlhi3} (nil)
(nil))
(insn 41 12 42 2 /tmp/ashiftsi3_1.c:3 (set (reg:HI 2 a [orig:20 D.1497 ] [20])
(reg:HI 8 si)) 9 {*movhi} (nil)
(nil))
(insn 42 41 14 2 /tmp/ashiftsi3_1.c:3 (set (reg:HI 4 d [ D.1497+2 ])
(reg:HI 9 di [+2 ])) 9 {*movhi} (nil)
(nil))
Register di was dead at this point, btw. The call to push_reload() seems
OK:
push_reload (in=0xb7f833b0, out=0xb7f7578c, inloc=0xb7f758bc,
outloc=0xb7f758c8, class=GENERAL_REGS, inmode=HImode, outmode=HImode,
strict_low=0, optional=0,
opnum=0, type=RELOAD_OTHER) at ../../../cvssrc/gcc/gcc/reload.c:929
(gdb) call debug_rtx(in)
(reg:HI 8 si [orig:26 x ] [26])
(gdb) call debug_rtx(out)
(subreg:HI (reg:SI 2 a [orig:20 D.1497 ] [20]) 0)
Starting at line 1097 of reload.c is the interesting part:
/* Similarly for paradoxical and problematical SUBREGs on the output.
Note that there is no reason we need worry about the previous value
of SUBREG_REG (out); even if wider than out,
storing in a subreg is entitled to clobber it all
(except in the case of STRICT_LOW_PART,
and in that case the constraint should label it input-output.) */
[...]
|| (REG_P (SUBREG_REG (out))
REGNO (SUBREG_REG (out)) FIRST_PSEUDO_REGISTER
((GET_MODE_SIZE (outmode) = UNITS_PER_WORD
(GET_MODE_SIZE (GET_MODE (SUBREG_REG (out)))
UNITS_PER_WORD)
((GET_MODE_SIZE (GET_MODE (SUBREG_REG (out)))
/ UNITS_PER_WORD)
!= (int) hard_regno_nregs[REGNO (SUBREG_REG (out))]
[GET_MODE (SUBREG_REG (out))]))
|| ! HARD_REGNO_MODE_OK (subreg_regno (out), outmode)))
[...]
{
out_subreg_loc = outloc;
outloc = SUBREG_REG (out);
out = *outloc;
#if ! defined (LOAD_EXTEND_OP) ! defined (WORD_REGISTER_OPERATIONS)
gcc_assert (!MEM_P (out)
|| GET_MODE_SIZE (GET_MODE (out))
= GET_MODE_SIZE (outmode));
#endif
outmode = GET_MODE (out);
}
What is the condition with hard_regno_nregs[][] supposed to check?
In this particular case, we have:
GET_MODE_SIZE (GET_MODE (SUBREG_REG (out))) = 4
UNITS_PER_WORD = 2
hard_regno_nregs[2][SImode] = 4 (8-bit registers)
so the condition 4 / 2 != 4 is true and reload thinks the SUBREG is
problematical. I don't see what is problematical about it.
I tried to svn blame someone, but ended with:
r363 | kenner | 1992-02-28 11:23:25 +0100 (fre, 28 feb 1992) | 2 lines
Initial revision
--
Rask Ingemann Lambertsen
Problem when using optimization on aix 5.2 and gcc 4.1.1
Hello, We have a large app with a lot of static libraries in it (and I mean a lot, about 20) and it compiles and links successfully. If I compile it without optimiztion turned on (-O2 or some more subtle with -O and others), the program also runs. With optimizations, though, the program would crash. Entailed is the gdb stacktrace. We use the native linker of aix and are updated to the latest bos packages for 5.2. Thanks for hints! thomas Eventc, which has no line number information. 0xd12c04b0 in XtDispatchEventToWidget () from /usr/lib/libXt.a(shr4.o) (gdb) c Continuing. terminate called after throwing an instance of 'std::bad_cast' what(): St8bad_cast Program received signal SIGABRT, Aborted. 0xd005b288 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o) (gdb) bt #0 0xd005b288 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o) #1 0xd005ad24 in _p_raise () from /usr/lib/libpthreads.a(shr_xpg5.o) #2 0xd01f20a4 in raise () from /usr/lib/libc.a(shr.o) #3 0xd0212758 in abort () from /usr/lib/libc.a(shr.o) #4 0xd287e6f0 in __gnu_cxx::__verbose_terminate_handler () at _start_ :97 #5 0xd2886cb8 in __cxxabiv1::__terminate (handler=incomplete type) at _start_ :43 #6 0xd287e57c in std::terminate () at _start_ :53 #7 0xd2886ae8 in __cxa_throw (obj=incomplete type, tinfo=incomplete type, dest=incomplete type) at _start_ :77 #8 0xd2894714 in std::__throw_bad_cast () at _start_ :55 #9 0xd28d31ec in std::basic_ioschar, std::char_traitschar ::widen ( this=incomplete type, __c=10 '\n') from /opt/compiler/gcc-4.1/bin/../lib/gcc/powerpc-ibm-aix5.2.0.0/4.1.1/libstdc++.a(libstdc++.so.6) #10 0x118ffd38 in ReadLine () #11 0x11901e00 in ReadStlFile () #12 0x103488d4 in FEMeshPartC::ReadSTL () #13 0x10b03a68 in AssPoolItemNativeC::LoadPart () #14 0x10afd1b4 in AssRefItemNativeC::TableChanged () #15 0x10b111f0 in AssFactoryNativeC::SelectDefaultLines () #16 0x10b0febc in AssFactoryNativeC::BuildRefAssItem () [EMAIL PROTECTED] gcc -v Using built-in specs. Target: powerpc-ibm-aix5.2.0.0 Configured with: ../gcc-4.1.1/configure --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-static --enable-shared --enable-threads --prefix=/opt/gcc-4.1 --without-gnu-ld --disable-nls --with-pic --disable-symvers --enable-symvers=no Thread model: aix gcc version 4.1.1
Re: Problem when using optimization on aix 5.2 and gcc 4.1.1
On Mon, May 21, 2007 at 07:06:47PM +0200, Thomas Mittelstaedt wrote: Hello, We have a large app with a lot of static libraries in it (and I mean a lot, about 20) and it compiles and links successfully. If I compile it without optimiztion turned on (-O2 or some more subtle with -O and others), the program also runs. With optimizations, though, the program would crash. While compiler bugs are possible, it is much more likely that it is a program bug. Common causes are uninitialized memory or heap corruption; the effects of this tend to change with optimization.
Re: I don't understand some of gcc-4.1-20070514, a patch here.
On May 19, 2007, at 11:54 AM, Manuel López-Ibáñez wrote: We tried to be polite And we should go back to being polite... He's email a patch recently. That's buys him more niceness in my book. I think he does want to help, he just needs more guidance. Our goal is to turn him into a useful contributor. Now, to get him to download 4.3 and fix it instead of 4.1. :-)
Re: I don't understand some of gcc-4.1-20070514, a patch here.
On May 19, 2007, at 3:57 AM, J.C. Pizarro wrote: you have this nice cleanup's patch of gcc/loop.c that transliterates the logic of the uses of the loop_invariant_p (..) and consec_sets_invariant_p (..) functions. Please resubmit against 4.3 (the top of the svn tree)... This is the canonical place where developers should be doing development. Thanks.
Re: I don't understand some of gcc-4.1-20070514, a patch here.
On 5/21/07, Mike Stump [EMAIL PROTECTED] wrote: Please resubmit against 4.3 (the top of the svn tree)... This is the canonical place where developers should be doing development. Thanks. Except loop.c has been removed already which has mentioned like 5 time already. Thanks, Andrew Pinski
Re: I don't understand some of gcc-4.1-20070514, a patch here.
On Mon, May 21, 2007 at 11:00:17AM -0700, Mike Stump wrote: On May 19, 2007, at 3:57 AM, J.C. Pizarro wrote: you have this nice cleanup's patch of gcc/loop.c that transliterates the logic of the uses of the loop_invariant_p (..) and consec_sets_invariant_p (..) functions. Please resubmit against 4.3 (the top of the svn tree)... This is the canonical place where developers should be doing development. Thanks. But gcc/loop.c is only in 4.1.x. It is not in 4.2.0, and not in the trunk. The patch can't be re-submitted against the trunk.
Re: a question regarding ifcvt.c
Tehila Meyzels [EMAIL PROTECTED] writes: I'd like to get an explanation why ifcvt.c checks whether 1 of the 2 successors of the IF-header block has a stmt that exits from the loop? Why does it prevent the if-conversion? I'm referring to the following code: /* Nor exit the loop. */ if ((then_edge-flags EDGE_LOOP_EXIT) || (else_edge-flags EDGE_LOOP_EXIT)) return NULL; I think it's just a heuristic. If one of the edges exits the loop, then it is probably a loop-exit test, and it is quite unlikely that we can do any useful if-conversion. Ian
Re: 4.3 release plan
Brooks Moses wrote: What about moving 4.3 to stage 3 *now* and moving everything else in 4.4 instead? Hopefully, it will be a matter of just a few months. From http://gcc.gnu.org/gcc-4.3/changes.html, it looks like it would already be quite a juicy release. Why? I mean, I suppose there could be advantages to doing this, but you haven't mentioned even one. I apologize. I guess you could get 10 different reasons by 10 different people. The reason _we_ care to get 4.3 sooner rather than later is that we'd like to have the AMD Geode tuning and the memcpy/strcpy() optimizations. And also: why not? -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Re: 4.3 release plan
On 5/21/07, Bernardo Innocenti [EMAIL PROTECTED] wrote: And also: why not? I had hoped to get my pointer plus branch merged in which should improve code gen and memory usage and compile time. -- Pinski
Re: 4.3 release plan
On Mon, May 21, 2007 at 11:31:19AM -0700, Andrew Pinski wrote: On 5/21/07, Bernardo Innocenti [EMAIL PROTECTED] wrote: And also: why not? I had hoped to get my pointer plus branch merged in which should improve code gen and memory usage and compile time. There seem to be quite a large number of not-yet-merged projects on the wiki page at http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning Go straight to phase 3 would presumably mean that none of them get in. On the other hand, phase 1 has been running for a long time, long past its original end date. I'm surprised that phase 2 hasn't started.
Re: 4.3 release plan
On May 21, 2007, at 11:23 AM, Bernardo Innocenti wrote: The reason _we_ care to get 4.3 sooner rather than later is that we'd like to have the AMD Geode tuning Submit to gcc 4.2. Tuning seems to be the type of thing that should be safe to backport, if you really must have it. Anyway, these reasons don't sound like reasons to goose the 4.3 plan. I'd argue for status quo.
Re: a question regarding ifcvt.c
On 5/21/07, Tehila Meyzels [EMAIL PROTECTED] wrote: Hi, I'd like to get an explanation why ifcvt.c checks whether 1 of the 2 successors of the IF-header block has a stmt that exits from the loop? Why does it prevent the if-conversion? I'm referring to the following code: /* Nor exit the loop. */ if ((then_edge-flags EDGE_LOOP_EXIT) || (else_edge-flags EDGE_LOOP_EXIT)) return NULL; To prevent ifcvt from moving computations into loops. See this patch: http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01864.html Gr. Steven
Re: I don't understand some of gcc-4.1-20070514, a patch here.
On 5/21/07, Andrew Pinski [EMAIL PROTECTED] wrote: On 5/21/07, Mike Stump [EMAIL PROTECTED] wrote: Please resubmit against 4.3 (the top of the svn tree)... This is the canonical place where developers should be doing development. Thanks. Except loop.c has been removed already which has mentioned like 5 time already. Let's make a guess: Mike still sees loop.c in GCC 4.2 *His* GCC 4.2 tree that is (Apple's) Just like the last minute GCC 4.2 bug that wasn't an FSF GCC 4.2 bug ;-) Joke joke... Gr. Steven
Re: 4.3 release plan
Joe Buck wrote: I had hoped to get my pointer plus branch merged in which should improve code gen and memory usage and compile time. There seem to be quite a large number of not-yet-merged projects on the wiki page at Never mind, I just did some investigation and it appears that the patches we want are quite trivial to backport to 4.2, so we don't need to rush 4.3 out. Go straight to phase 3 would presumably mean that none of them get in. But on the other end, if we do push GCC 4.3 out now, there will be another stage 1 very soon :-) Well, I don't want to step on anybody's feet. GCC has historically had longer release cycles than other projects of comparable size and this has clearly been consciously planned by experienced people, most probably for good reason. For the impatient, backporting is always an option. -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Re: I don't understand some of gcc-4.1-20070514, a patch here.
2007/5/21, Mike Stump [EMAIL PROTECTED] wrote: On May 19, 2007, at 3:57 AM, J.C. Pizarro wrote: you have this nice cleanup's patch of gcc/loop.c that transliterates the logic of the uses of the loop_invariant_p (..) and consec_sets_invariant_p (..) functions. Please resubmit against 4.3 (the top of the svn tree)... This is the canonical place where developers should be doing development. Thanks. It's impossible to resubmit the similar patch to =4.2. Try this command $ grep -iR loop_invariant_p . | grep '\.c:\|\.h:' $ So, you can compare the lectures of loop invariant's algorithms between 4.1.3-ss, 4.2 and 4.3. The main difference is that patched 4.1.3-ss works well, it's 3in1 in the loop function and is comprehensible. Since 4.2, it'd changed a lot! it's 2in1! I hate the '-b-r-a-i-n-f-u-c-k-e-d- -c-o-d-e- -w-i-t-h-o-u-t- -e-x-p-l-a-n-a-t-i-o-n-'.
help writing gcc code
I need to edit a gcc source code, then recompile. My goal is to change what gets output in the assembly file, when using the '-S' flag. I figured a good first step would be, being able to print out Hello World! somewhere in the '.s' file. I'm having trouble finding which source code file I need to edit though. Any help would be great. Thanks. -- View this message in context: http://www.nabble.com/help-writing-gcc-code-tf3793037.html#a10727717 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: help writing gcc code
On May 21, 2007, at 2:43 PM, AaronCloyd wrote: I need to edit a gcc source code, then recompile. Wrong list... gcc-help is closer that what you want...
Re: I don't understand some of gcc-4.1-20070514, a patch here.
2007/5/21, Mike Stump [EMAIL PROTECTED] wrote:
On May 21, 2007, at 2:04 PM, J.C. Pizarro wrote:
I hate the '-b-r-a-i-n [ ... ]
We don't use that sort of language around here...
Don't you understand the b-r-a-i-n-f-u-c-k-e-d source code?
http://en.wikipedia.org/wiki/Brainfuck
I'm saying is that you do not develop the source code directly to machine
and distantly to the human natural language.
The lecture of the legible source code is more important than brainfucking
the source code for maximum speed.
I hate if (ptr) { ... } /* - It's b-r-a-i-n-f-u-c-k-e-d source code! */
I love if (ptr != NULL) { ... }
Re: Problem when using optimization on aix 5.2 and gcc 4.1.1
Thomas Mittelstaedt wrote: Hello, We have a large app with a lot of static libraries in it (and I mean a lot, about 20) and it compiles and links successfully. If I compile it without optimiztion turned on (-O2 or some more subtle with -O and others), the program also runs. With optimizations, though, the program would crash. Entailed is the gdb stacktrace. We use the native linker of aix and are updated to the latest bos packages for 5.2. You need to debug the program to find out where the bug is (most likely the bug is in your code, optimization often shows up bugs that do not appear at -O0).
Volunteer for bug summaries?
I've received some feedback suggesting that some contributors may not always be aware of what open issues are available to work on, and, perhaps more importantly, what regressions they may have caused. Is there a volunteer who would like to help prepare a regular list of P3-and-higher PRs, together with -- where known -- the name of the person responsible for the checkin which caused the regression? Or, is this something that could be automated through Bugzilla, perhaps by adding a pointer to the SVN revision at which the regression was introduced? The goal would be to send a weekly/bi-weekly reminder to the list, and to the responsible parties, to help remind those of us who've caused problems to clean them up. I know that this would help me, both as a developer and as the RM: as RM, it would help me see what's going on, and as a developer, it would encourage me to clean up my messes, even when I'm busy. What do others think? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Volunteer for bug summaries?
On Mon, May 21, 2007 at 03:35:53PM -0700, Mark Mitchell wrote: Is there a volunteer who would like to help prepare a regular list of P3-and-higher PRs, together with -- where known -- the name of the person responsible for the checkin which caused the regression? Or, is this something that could be automated through Bugzilla, perhaps by adding a pointer to the SVN revision at which the regression was introduced? A semi-automated approach would be to add a field in Bugzilla that would contain the SVN revision; this field could be filled in by volunteers, and then a Bugzilla query could generate the report whenever you want to look at it. Of course, some bugs predate the conversion to Bugzilla, and release branches complicate life a bit.
gcc-4.1-20070521 is now available
Snapshot gcc-4.1-20070521 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070521/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 124925 You'll find: gcc-4.1-20070521.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070521.tar.bz2 C front end and core compiler gcc-ada-4.1-20070521.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070521.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070521.tar.bz2 C++ front end and runtime gcc-java-4.1-20070521.tar.bz2 Java front end and runtime gcc-objc-4.1-20070521.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070521.tar.bz2The GCC testsuite Diffs from 4.1-20070514 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: 4.3 release plan
Bernardo Innocenti wrote: I extracted the relevant patches that would apply to 4.2 as they were. Currently regtesting just in case. Err, allow me to rephrase that more clearly: I have extracted the Geode patches from the trunk and they applied without modification to the 4.2 branch. I'm currently bootstrapping 4.2 with --with-arch=geode and will run the testsuite shortly. -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Re: Volunteer for bug summaries?
is is very difficult work? i did't know whether i can competent for it. i'.m a volunteer. On 5/22/07, Mark Mitchell [EMAIL PROTECTED] wrote: I've received some feedback suggesting that some contributors may not always be aware of what open issues are available to work on, and, perhaps more importantly, what regressions they may have caused. Is there a volunteer who would like to help prepare a regular list of P3-and-higher PRs, together with -- where known -- the name of the person responsible for the checkin which caused the regression? Or, is this something that could be automated through Bugzilla, perhaps by adding a pointer to the SVN revision at which the regression was introduced? The goal would be to send a weekly/bi-weekly reminder to the list, and to the responsible parties, to help remind those of us who've caused problems to clean them up. I know that this would help me, both as a developer and as the RM: as RM, it would help me see what's going on, and as a developer, it would encourage me to clean up my messes, even when I'm busy. What do others think? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 -- i'm a newbie in GCC community. Wei Chen
GCC, Wei Chen wants to chat
I've been using Google Talk and thought you might like to try it out. We can use it to call each other for free over the internet. Here's an invitation to download Google Talk. Give it a try! --- Wei Chen wants to stay in better touch using some of Google's coolest new products. If you already have Gmail or Google Talk, visit: http://mail.google.com/mail/b-2e449a07c2-e08b71486f-e1969e1dac77466f You'll need to click this link to be able to chat with Wei Chen. To get Gmail - a free email account from Google with over 2,800 megabytes of storage - and chat with Wei Chen, visit: http://mail.google.com/mail/a-2e449a07c2-e08b71486f-10549a4ddb Gmail offers: - Instant messaging right inside Gmail - Powerful spam protection - Built-in search for finding your messages and a helpful way of organizing emails into conversations - No pop-up ads or untargeted banners - just text ads and related information that are relevant to the content of your messages All this, and its yours for free. But wait, there's more! By opening a Gmail account, you also get access to Google Talk, Google's instant messaging service: http://www.google.com/talk/ Google Talk offers: - Web-based chat that you can use anywhere, without a download - A contact list that's synchronized with your Gmail account - Free, high quality PC-to-PC voice calls when you download the Google Talk client Gmail and Google Talk are still in beta. We're working hard to add new features and make improvements, so we might also ask for your comments and suggestions periodically. We appreciate your help in making our products even better! Thanks, The Google Team To learn more about Gmail and Google Talk, visit: http://mail.google.com/mail/help/about.html http://www.google.com/talk/about.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser).
Re: GCC, Wei Chen wants to chat
On 5/21/07, Wei Chen [EMAIL PROTECTED] wrote: I've been using Google Talk and thought you might like to try it out. I would suggest that you use the public IRC channel on irc.oftc.net. See the GCC wiki page for details (http://gcc.gnu.org/wiki/GCConIRC)
Re: help writing gcc code
Mike Stump wrote: On May 21, 2007, at 2:43 PM, AaronCloyd wrote: I need to edit a gcc source code, then recompile. Wrong list... gcc-help is closer that what you want... Is it? Changing the internals of what GCC puts into .s files seems a topic that's more appropriate here, I would think. - Brooks
Re: help writing gcc code
i think you can read GCC backend to understand GCC how to write .s files. On 5/22/07, Brooks Moses [EMAIL PROTECTED] wrote: Mike Stump wrote: On May 21, 2007, at 2:43 PM, AaronCloyd wrote: I need to edit a gcc source code, then recompile. Wrong list... gcc-help is closer that what you want... Is it? Changing the internals of what GCC puts into .s files seems a topic that's more appropriate here, I would think. - Brooks -- i'm a newbie in GCC community. Wei Chen
http://gcc.gnu.org/svn.html have a error.
i think http://gcc.gnu.org/svn.html have a error. Using the SVN repository Assuming you have version 1.0.0 and higher of Subversion installed, you can check out the GCC sources using the following command: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc the right is svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk orsvn -q checkout svn://gcc.gnu.org/svn/gcc/trunk/gcc -- i'm a newbie in GCC community. Wei Chen
Re: http://gcc.gnu.org/svn.html have a error.
On 5/21/07, Wei Chen [EMAIL PROTECTED] wrote: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc the right is svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk Not really, the syntax mentioned in the page is correct. The additional argument 'gcc' merely means that on checkout, 'trunk' will be created as 'gcc' in your local copy. orsvn -q checkout svn://gcc.gnu.org/svn/gcc/trunk/gcc Careful with this one. If you use this syntax, you will only be checking out the trunk/gcc sub-directory and will not be able to build the compiler.
Re: http://gcc.gnu.org/svn.html have a error.
Wei Chen wrote: i think http://gcc.gnu.org/svn.html have a error. Using the SVN repository Assuming you have version 1.0.0 and higher of Subversion installed, you can check out the GCC sources using the following command: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc I think you are mistaken. The command above does in fact check out the source into a directory named gcc. the right is svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk This will work as well, but the workspace will be in a directory called 'trunk' orsvn -q checkout svn://gcc.gnu.org/svn/gcc/trunk/gcc That is probably not what you want. That will only checkout the gcc subdirectory. The result while interesting, will not be sufficient to build a working compiler. David Daney
Re: http://gcc.gnu.org/svn.html have a error.
On 5/22/07, David Daney [EMAIL PROTECTED] wrote: Wei Chen wrote: i think http://gcc.gnu.org/svn.html have a error. Using the SVN repository Assuming you have version 1.0.0 and higher of Subversion installed, you can check out the GCC sources using the following command: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc I think you are mistaken. The command above does in fact check out the source into a directory named gcc. the right is svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk This will work as well, but the workspace will be in a directory called 'trunk' orsvn -q checkout svn://gcc.gnu.org/svn/gcc/trunk/gcc That is probably not what you want. That will only checkout the gcc subdirectory. The result while interesting, will not be sufficient to build a working compiler. David Daney I'm using tortosieSVN. it's a visual version with SVN. so the url is svn://gcc.gnu.org/svn/gcc/trunk. forgive me that i didn't know the syntax about SVN in command line that's right. i'm wrong. -- i'm a newbie in GCC community. Wei Chen
Re: http://gcc.gnu.org/svn.html have a error.
Wei Chen wrote: i think http://gcc.gnu.org/svn.html have a error. Using the SVN repository Assuming you have version 1.0.0 and higher of Subversion installed, you can check out the GCC sources using the following command: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc the right is svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk orsvn -q checkout svn://gcc.gnu.org/svn/gcc/trunk/gcc Why do you feel that this is an error? Did you try the command in the form that it was written, and if so, what happened? (It works fine for me.) If you look at the helpfile for the svn checkout command (which you can see if you enter the svn help checkout command), you'll see that it has an optional PATH argument, which tells it the name of the directory that it should put the checked-out files into. That's what the gcc is in form of the command that's given. - Brooks
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #9 from matz at gcc dot gnu dot org 2007-05-21 07:45 --- Richard, the problem isn't the compare or where to store the live values alen and blen (FYI, the store looks invalid, because reload will not immediately stop when it sees an invalid asm insn, but instead just patch it out, but it will leave the operands in a funny state, hence the compare insn looks incorrect). The problem is the asm instruction itself, and it's actually the exact same bug as pr21291 , which was worked around by the outof-ssa change to coalesce both operand, which doesn't work anymore due to the change in forwprop. This could have happened also by some other random transformation, so forwprop isn't at fault. To recap, the problem goes like this: You start with int inout, orig; orig = inout; asm (: +mr (inout)); use (orig); which is transformed very early to use explicit output and match operands (this in fact is the source of all evil, as far as reloads capabilities are concerned): asm (: =mr (inout) : 0 (inout)); Now SSA form properly assigns a new SSA name for the output operand in the asm to inout, and some other transformation can now make use of the original SSA name of inout (in this case it's forwprop), so we have: asm (: =mr (inout_2) : 0 (inout_1)); use (inout_1); Clearly inout_2 and inout_1 can't be coalesced easily anymore, as they represent two separate values, so they will get different pseudo registers during expansion. Pseudos are okay, as we indeed would accept registers at all in the constraint. But still from there everything goes downhill: Both operands need to match per the constraints, but use different pseudo registers, so they don't match. The only solution (for reload) is to register a reload for these operands. But reloads can only be satisfied by hardregs, not by memory, so we need a register for this reload, just because we are presented with non-matching operands. So, even though we allow memory for this operand, no memory can be used for it, because both operand parts don't match. That together with the other necessary registers will get us over the total limit of 6 available registers in the end. So it's a symptom of reload not being able to use memory for reloads (secondary reloads don't come into play here), a long standing problem. Alternatively it's also a symptom of both operands not coming into reload as matching (in which case the pseudo could go to memory just fine, as the alternative allows it, and no reload would be necessary). Extending reload to make use of memory for some reloads, where allowed, might be nice, but is unrealistic in its gory detail (even the secondary mem support doesn't really help here). So I think the only feasible fix or work-around is to present reload with matching operands, where required. Strictly it's required only if the alternative allows registers and memory and both operands are different pseudo regs, all other cases can be handled by reload equally well. That might still be done in tree form (what the old outof-ssa hack still tries but can't really work), or in RTL form shortly before reload. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #1 from bonzini at gnu dot org 2007-05-21 08:19 --- I know what's going on :-) -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-05-20 21:26:42 |2007-05-21 08:19:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #2 from bonzini at gnu dot org 2007-05-21 08:21 --- Created an attachment (id=13593) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13593action=view) tentative patch? Please test this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #97 from jv244 at cam dot ac dot uk 2007-05-21 08:30 --- This morning's mainline gives a new ICE on the CVS version of CP2K (the file in question is not in the tarbal of comment #0) gfortran -c -O3 -ftree-vectorize -ffast-math -march=native semi_empirical_int_ana.f90 /scratch/vondele/clean/cp2k/src/../src/semi_empirical_int_ana.F: In function dterep_ana: /scratch/vondele/clean/cp2k/src/../src/semi_empirical_int_ana.F:2319: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [semi_empirical_int_ana.o] Error 1 -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #10 from ubizjak at gmail dot com 2007-05-21 08:33 --- Extending reload to make use of memory for some reloads, where allowed, might be nice, but is unrealistic in its gory detail (even the secondary mem support doesn't really help here). Should we XFAIL this test? -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn||19398 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #11 from bonzini at gnu dot org 2007-05-21 08:48 --- Micha, do you mean transforming (while expanding to RTL) asm (: =mr (inout_2) : 0 (inout_1)); to inout_2 = inout_1; asm (: =mr (inout_2) : 0 (inout_2)); ? That shouldn't be too hard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #12 from matz at gcc dot gnu dot org 2007-05-21 09:03 --- Exactly. If during expansion or at some other time before reload, doesn't matter that much. Of course there's a remote possibility that some RTL passes between expand and reload would do the copy propagation to counter that transformation. As inout_2 would have two writes this would require some data flow analysis in the RTL phase to determine that this copy-prop is valid. There's hope that this isn't done, so that nobody would destroy that work-around again :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug libstdc++/32017] Exception-safety bug
--- Comment #1 from pcarlini at suse dot de 2007-05-21 09:22 --- Ok, thanks, but this bug is already fixed. *** This bug has been marked as a duplicate of 25288 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug libstdc++/25288] std::list insert members should have no effects if an exception is thrown
--- Comment #6 from pcarlini at suse dot de 2007-05-21 09:22 --- *** Bug 32017 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||dave at boost-consulting dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25288
[Bug libstdc++/21772] exception safety testing allocator
--- Comment #3 from pcarlini at suse dot de 2007-05-21 09:26 --- Also see libstdc++/32017 for some additional details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #13 from bonzini at gnu dot org 2007-05-21 09:32 --- So we'd just be replacing a weak workaround with a stronger (but not definitive) workaround. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-05-21 09:41 --- Subject: Re: [4.3 regression] : gcc.target/i386/pr21291.c matz at gcc dot gnu dot org wrote: --- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 --- Yes. The place where I would think the work-around to become definitive is exactly before regclass. Between it and reload nothing interesting happens transformation wise. I was thinking of the same. Also, if the patch included adding a cfun-have_asm_statement flag set during RTL expansion, it would probably cost little to do it in an entirely new pass before regclass. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug c/11051] -Wno-deprecated needed also for C
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-21 09:54 --- This bug will be fixed as soon as Tom's patch goes in. *** This bug has been marked as a duplicate of 22168 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-21 09:54 --- *** Bug 11051 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 --- Yes. The place where I would think the work-around to become definitive is exactly before regclass. Between it and reload nothing interesting happens transformation wise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-21 10:13 --- My patch for PR31867 fixes this in all its manifestations: see http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00961.html The amusing thing is that I was hurting for testcases for this latter PR:) It shows what a limited imagination is incapable of. Thanks, Elizabeth. Perhaps FX or Jerry, you could review the above patch? I will incorporate Elizabeth and FX's examples into the PR31867 testscase. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||31867 AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-05-20 15:43:41 |2007-05-21 10:13:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug testsuite/32014] new gcc failures
--- Comment #1 from irar at il dot ibm dot com 2007-05-21 10:43 --- On PowerPC revision 124785 from May 17 we get: FAIL: gcc.dg/vect/vect-64.c (internal compiler error) FAIL: gcc.dg/vect/vect-64.c (test for excess errors) WARNING: gcc.dg/vect/vect-64.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-68.c (internal compiler error) FAIL: gcc.dg/vect/vect-68.c (test for excess errors) WARNING: gcc.dg/vect/vect-68.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-70.c (internal compiler error) FAIL: gcc.dg/vect/vect-70.c (test for excess errors) WARNING: gcc.dg/vect/vect-70.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times vectorized 1 loops 1 Revision 124739 from May 15 works fine. On today's snapshot (124895) we also see XPASS: gcc.dg/vect/vect-iv-4.c scan-tree-dump-times vectorized 1 loops 1 in addition to the above failures. Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug testsuite/32014] new gcc failures
--- Comment #2 from dominiq at lps dot ens dot fr 2007-05-21 10:58 --- vect-intfloat-conversion-4b.c is four days old, but the other tests seem pretty old so the failures are regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug libstdc++/31621] libstdc++ uses -xc++ which can cause exceptions to show up which causes __gxx_personality_v0 to be referenced
--- Comment #3 from paolo at gcc dot gnu dot org 2007-05-21 11:26 --- Subject: Bug 31621 Author: paolo Date: Mon May 21 10:25:52 2007 New Revision: 124896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124896 Log: 2007-05-21 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31621 * acinclude.m4 ([GLIBCXX_CHECK_LINKER_FEATURES]): Use the C compiler. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31621
[Bug libstdc++/31621] libstdc++ uses -xc++ which can cause exceptions to show up which causes __gxx_personality_v0 to be referenced
--- Comment #4 from paolo at gcc dot gnu dot org 2007-05-21 11:27 --- Subject: Bug 31621 Author: paolo Date: Mon May 21 10:26:49 2007 New Revision: 124897 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124897 Log: 2007-05-21 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31621 * acinclude.m4 ([GLIBCXX_CHECK_LINKER_FEATURES]): Use the C compiler. * configure: Regenerate. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_2-branch/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31621
[Bug libstdc++/31621] libstdc++ uses -xc++ which can cause exceptions to show up which causes __gxx_personality_v0 to be referenced
--- Comment #5 from pcarlini at suse dot de 2007-05-21 11:27 --- Fixed for 4.2.1. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31621
[Bug target/31167] ICE wnen using __int128_t on x86_64
--- Comment #8 from uros at gcc dot gnu dot org 2007-05-21 12:31 --- Subject: Bug 31167 Author: uros Date: Mon May 21 11:31:14 2007 New Revision: 124900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124900 Log: PR target/31167 Backport from mainline. * config/i386/i386.md (*addti3_1, *addti3_1 splitter): Use x86_64_general_operand as operand[2] predicate. Remove iF from operand constraints and use e constraint instead. (*subti3_1, *subti3_1 splitter): Ditto. (*negti2_1, *negti2_1 splitter): Use nonimmediate_operand as operand[1] predicate. PR target/30041 Backport from mainline. * config/i386/sse.md (*sse3_movddup): Use operands[0] and operands[1] in insn constraint. Correct type attribute to sselog1. testsuite/ChangeLog Backport from mainline. * gcc.target/i386/pr31167.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr31167.c - copied unchanged from r122945, trunk/gcc/testsuite/gcc.target/i386/pr31167.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/i386.md branches/gcc-4_2-branch/gcc/config/i386/sse.md branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
[Bug target/30041] FAIL: gcc.target/i386/sse3-movddup.c (internal compiler error)
--- Comment #6 from uros at gcc dot gnu dot org 2007-05-21 12:31 --- Subject: Bug 30041 Author: uros Date: Mon May 21 11:31:14 2007 New Revision: 124900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124900 Log: PR target/31167 Backport from mainline. * config/i386/i386.md (*addti3_1, *addti3_1 splitter): Use x86_64_general_operand as operand[2] predicate. Remove iF from operand constraints and use e constraint instead. (*subti3_1, *subti3_1 splitter): Ditto. (*negti2_1, *negti2_1 splitter): Use nonimmediate_operand as operand[1] predicate. PR target/30041 Backport from mainline. * config/i386/sse.md (*sse3_movddup): Use operands[0] and operands[1] in insn constraint. Correct type attribute to sselog1. testsuite/ChangeLog Backport from mainline. * gcc.target/i386/pr31167.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr31167.c - copied unchanged from r122945, trunk/gcc/testsuite/gcc.target/i386/pr31167.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/i386.md branches/gcc-4_2-branch/gcc/config/i386/sse.md branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30041
[Bug middle-end/32018] New: ICE on optimization
Attached code from CP2K crashes f951 on i686-pc-linux-gnu if these flags
FCFLAGS=-c -O2 -ftree-vectorize -msse2
are specified. All of them are necessary, omitting any will avoid the segfault.
The crash seems to be related to the length of the subroutine. Further reducing
the number of initializations avoid the segfault as well.
(gdb) run -O2 -ftree-vectorize -msse2 periodic_table.f90
Starting program:
/h/franke/packages/i686-pc-linux-gnu/gcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951
-O2 -ftree-vectorize -msse2 periodic_table.f90
init_periodic_table
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inline static-var pure-const
type-escape-varAssembling functions:
init_periodic_table {GC 5333k -
Program received signal SIGSEGV, Segmentation fault.
0x080f7413 in ggc_set_mark (p=0xa5a5a5a5) at
../../../svn/gcc/gcc/ggc-page.c:605
605 return base[L1][L2];
(gdb) bt
#0 0x080f7413 in ggc_set_mark (p=0xa5a5a5a5) at
../../../svn/gcc/gcc/ggc-page.c:605
#1 0x08253d98 in gt_ggc_mx_loop (x_p=0xb7ac5c94) at gtype-desc.c:302
#2 0x08253e00 in gt_ggc_mx_loop (x_p=0xb78d32e0) at gtype-desc.c:311
#3 0x08253de2 in gt_ggc_mx_loop (x_p=0xb7a9d114) at gtype-desc.c:309
#4 0x08253c83 in gt_ggc_mx_basic_block_def (x_p=0xb7a99ca8) at
gtype-desc.c:825
#5 0x08253d19 in gt_ggc_mx_tree_ann_d (x_p=0xb7bc8b2c) at gtype-desc.c:703
#6 0x080b14bf in gt_ggc_mx_lang_tree_node (x_p=0xb7dbfac4) at
./gt-fortran-f95-lang.h:358
#7 0x0824c99e in gt_ggc_mx_cgraph_edge (x_p=0xb7c09c98) at gtype-desc.c:159
#8 0x0824c98f in gt_ggc_mx_cgraph_edge (x_p=0xb7c09ccc) at gtype-desc.c:158
#9 0x0824c81c in gt_ggc_mx_cgraph_node (x_p=0xb7d5e780) at gtype-desc.c:183
#10 0x0824ca8f in gt_ggc_m_P11cgraph_node4htab (x_p=0xb7dc2a14) at
gtype-desc.c:1931
#11 0x0822bf09 in ggc_mark_roots () at ../../../svn/gcc/gcc/ggc-common.c:118
#12 0x080f7e38 in ggc_collect () at ../../../svn/gcc/gcc/ggc-page.c:1906
#13 0x0828112a in execute_one_pass (pass=0x87af720) at
../../../svn/gcc/gcc/passes.c:1087
#14 0x082812af in execute_pass_list (pass=0x87af720) at
../../../svn/gcc/gcc/passes.c:1117
#15 0x082812c2 in execute_pass_list (pass=0x87af620) at
../../../svn/gcc/gcc/passes.c:1118
#16 0x082812c2 in execute_pass_list (pass=0x87aee60) at
../../../svn/gcc/gcc/passes.c:1118
#17 0x08359f4c in tree_rest_of_compilation (fndecl=0xb7d5e680) at
../../../svn/gcc/gcc/tree-optimize.c:406
#18 0x084b3cf0 in cgraph_expand_function (node=0xb7d5e780) at
../../../svn/gcc/gcc/cgraphunit.c:1086
#19 0x084b6415 in cgraph_optimize () at ../../../svn/gcc/gcc/cgraphunit.c:1155
#20 0x080aeacc in gfc_be_parse_file (set_yydebug=0) at
../../../svn/gcc/gcc/fortran/f95-lang.c:307
#21 0x083004a8 in toplev_main (argc=5, argv=0xbf88fe24) at
../../../svn/gcc/gcc/toplev.c:1051
#22 0x080f263f in main (argc=Cannot access memory at address 0xc
) at ../../../svn/gcc/gcc/main.c:35
Valgrind:
init_periodic_table
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inline static-var pure-const
type-escape-varAssembling functions:
init_periodic_table {GC 5333k - ==22375== Invalid read of size 4
==22375==at 0x80F7413: ggc_set_mark (ggc-page.c:605)
==22375== Address 0x2968 is not stack'd, malloc'd or (recently) free'd
--
Summary: ICE on optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
[Bug middle-end/32018] ICE on optimization
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-05-21 12:33 --- Created an attachment (id=13594) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13594action=view) Described test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #98 from dfranke at gcc dot gnu dot org 2007-05-21 12:38 --- Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64 equivalent and got the ICE described in PR32018. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/32018] ICE on optimization
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-21 12:56:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-21 13:04 --- Sorry about the bad news, but I still have the very same failure with the patch: # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. /bin/sh ../../../gcc-4.3-20070519/libgcc/../mkinstalldirs . /sw/src/fink.build/gcc4-4.3.0-20070519/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.3.0-20070519/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin7/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin7/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin7/include -isystem /sw/lib/gcc4/powerpc-apple-darwin7/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib -nodefaultlibs -install_name /sw/lib/gcc4/lib/libgcc_s`if test . = ppc64 ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 -current_version 1.0 -g -O2 -mdynamic-no-pic -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o darwin-fallback_s.o emutls_s.o -lc /sw/lib/odcctools/bin/ld: warning -dylib_install_name /sw/lib/gcc4/lib/libgcc_s.1.dylib not found in segment address table LD_SEG_ADDR_TABLE /sw/var/lib/fink/prebound/seg_addr_table /sw/lib/odcctools/bin/ld: _enable_execute_stack_s.o has local relocation entries in non-writable section (__TEXT,__text) collect2: ld returned 1 exit status make[3]: *** [libgcc_s.dylib] Error 1 make[2]: *** [all-stage2-target-libgcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 Apparently '-mdynamic-no-pic' is hiding somewhere it is not expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug fortran/31930] [4.1/4.2 only] bes[jy]n intrinsics do not follow definition of elemental functions
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-21 13:05 --- Daniel cleared this one on trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31930
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #4 from andreast at gcc dot gnu dot org 2007-05-21 13:06 --- Nope. It clinches somehow with this one: config/mh-ppc-darwin. Here the BOOT_CFLAGS is set to -g -O2 -mdynamic-no-pic. In the libgcc Makefile.in I see that MULTILIB_CFLAGS is set to CFLAGS + extra stuff. CFLAGS itself is BOOT_CFLAGS, so the -mdynamic-no-pic in a shared lib :) I'll see if I understand a bit more later. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug testsuite/32014] new gcc failures
--- Comment #3 from ubizjak at gmail dot com 2007-05-21 13:06 --- (In reply to comment #1) FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times vectorized 1 loops 1 These are new test files, and either relevant conversion optabs should be added for ppc, or xfail for these test needs to be adjusted. Please look to PR tree-optimization/24695, Comment #14. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug c++/32019] New: Condition operator ?: and ambiguous convertions
The following program should not compile (without warnings) on two counts, but
in fact only fails on one, and not for the right reason, as far as I can see.
class C
{
public:
C(const char *);
operator const char *();
};
void
foo (bool b)
{
// Prove that the implicit convertions work both ways.
C c = 1;
const char * s = C(2);
// This is ambiguous; both operands may be converted to the other's type.
// However, the compiler accepts it without a diagnostic.
b ? 1 : C(2);
// This is basically the same as the previous statement, but it fails with
// the error operands to ?: have different types.
b ? c : s;
}
Both conditional operators should fall foul of clause 5.16, paragraph 3, of the
C++ standard. The last two operands are of different types, and each may be
implicitly converted to the opposite, as demonstrated by the assignments above.
The second conditional operator looks like a different way of writing the
first, but fails with an error stating that the operands have different types.
They do have different types, but again, the conversions should apply just the
same.
If I alter the program to use a type other than const char * (such as int, or
another class type) then I get different results again, which is surprising.
--
Summary: Condition operator ?: and ambiguous convertions
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32019
[Bug testsuite/32014] new gcc failures
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-21 13:15 --- Please look to PR tree-optimization/24695 Are you sure about the number? PR24695 is [csl-arm-branch] Bootstrap failure with current csl-arm-branch and has only three comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug c++/32020] New: Invalid template error on non-dependent name
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++ EE 2005.
Here is the source code:
class template_function
{
public:
template int N
int func()
{
return N;
};
};
class non_template_class
{
public:
template_function tf;
void run()
{
tf.func36(); // SUCCESS
}
};
// The PointLess template parameter makes gcc
// fail to see that tf is a non-dependent name
template int PonitLess
class template_class
{
public:
template_function tf;
void run()
{
tf.func42(); // FAIL
}
};
int main()
{
non_template_class ntc;
ntc.run();
template_class0 tc;
tc.run();
return 0;
}
Here is the output of G++:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/cpp0 -lang-c++ -D__GNUG__=3
-D__DEPRECATED -D__EXCEPTIONS -v -D__GNUC__=3 -D__GNUC_MINOR__=2
-D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix
-D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__
-D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1
-D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__
-D__tune_i386__ main.cpp -Wall main.ii
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (cpplib) (i386
Linux/ELF)
ignoring nonexistent directory /usr/i386-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/3.2.3
/usr/include/c++/3.2.3/i386-redhat-linux
/usr/include/c++/3.2.3/backward
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -Wall -version -o main.s
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (cpplib) (i386
Linux/ELF)
GNU C++ version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (i386-redhat-linux)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-34).
main.cpp: In member function `void template_classPonitLess::run()':
main.cpp:34: syntax error before `;' token
And here is the main.ii file:
# 1 main.cpp
# 1 built-in
# 1 command line
# 1 main.cpp
class template_function
{
public:
template int N
int func()
{
return N;
};
};
class non_template_class
{
public:
template_function tf;
void run()
{
tf.func36();
}
};
template int PonitLess
class template_class
{
public:
template_function tf;
void run()
{
tf.func42();
}
};
int main()
{
non_template_class ntc;
ntc.run();
template_class0 tc;
tc.run();
return 0;
}
--
Summary: Invalid template error on non-dependent name
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trundeg at hotmail dot com
GCC host triplet: Linux cfr1ll19 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55
EDT 200
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
[Bug testsuite/32014] new gcc failures
--- Comment #5 from ubizjak at gmail dot com 2007-05-21 14:01 --- (In reply to comment #4) Please look to PR tree-optimization/24695 Are you sure about the number? PR24695 is Oops, PR24659. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug fortran/31867] function result with character LEN computed at run time
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-21 14:16 --- Subject: Bug 31867 Author: pault Date: Mon May 21 13:16:06 2007 New Revision: 124903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124903 Log: 2007-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/31867 PR fortran/31994 * trans-array.c (gfc_conv_expr_descriptor): Obtain the stored offset for non-descriptor, source arrays and correct for stride not equal to one before writing to field of output descriptor. 2007-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/31867 * gfortran.dg/char_length_5.f90: New test. PR fortran/31994 * gfortran.dg/array_reference_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_reference_1.f90 trunk/gcc/testsuite/gfortran.dg/char_length_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-21 14:16 --- Subject: Bug 31994 Author: pault Date: Mon May 21 13:16:06 2007 New Revision: 124903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124903 Log: 2007-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/31867 PR fortran/31994 * trans-array.c (gfc_conv_expr_descriptor): Obtain the stored offset for non-descriptor, source arrays and correct for stride not equal to one before writing to field of output descriptor. 2007-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/31867 * gfortran.dg/char_length_5.f90: New test. PR fortran/31994 * gfortran.dg/array_reference_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_reference_1.f90 trunk/gcc/testsuite/gfortran.dg/char_length_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug fortran/31867] [4.2 only] function result with character LEN computed at run time
--- Comment #12 from pault at gcc dot gnu dot org 2007-05-21 14:18 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Summary|function result with|[4.2 only] function result |character LEN computed at |with character LEN computed |run time|at run time http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.
--- Comment #10 from pault at gcc dot gnu dot org 2007-05-21 14:21 --- Fixed on trunk. The patch will be backported to 4.2, as soon as the dust has settled on trunk and 4.2 is open again. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug libstdc++/32017] Exception-safety bug
--- Comment #2 from dave at boost-consulting dot com 2007-05-21 14:25 --- I won't push the subject any further, but again, if you don't adopt the tests mentioned in the threads cited above, you will almost certainly have further exception safety bugs lurking. Howard Hinnant can verify that this test works as he used it to validate the MSL. -- dave at boost-consulting dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug c++/32020] Invalid template error on non-dependent name
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 14:27 --- GCC 3.2 is no longer maintained. This works with the new C++ parser that went in for GCC 3.4.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
[Bug fortran/32021] New: Fix,document,remove GFORTRAN_* environment variables
The following environment variables exist in gfortran (inherited from g95, cf.
http://ftp.g95.org/G95Manual.pdf). They are not documented and don't seem to
work, however they are partially implemented.
GFORTRAN_FPU_PRECISION can probably be removed (cf. -mpc32, -mpc64 and -mpc80)
GFORTRAN_MEM_INIT sounds something which should be handled by the front end (w/
a flag) for speed reasons. (cf. -finit-local-zero, PR20441).
Similar for GFORTRAN_MEM_CHECK.
GFORTRAN_SIG* could be implemented, if someone needs it. (can be done via the
signal vendor intrinsic).
GFORTRAN_FPU_ROUND etc. could be handled by the Fortran 2003 IEEE rounding
modes - or is this environment variable needed?
--- gfortran.texi (Revision 124895)
+++ gfortran.texi (Arbeitskopie)
@@ -604,6 +612,51 @@
when @command{a.out} is the compiled Fortran program that you want to run.
Default is a single space.
[EMAIL PROTECTED] GFORTRAN_MEM_INIT
[EMAIL PROTECTED] @env{GFORTRAN_MEM_INIT}---Default initialization of allocated
memory
+
+This environment variable specifies how allocated memory is initialized.
+Default value is @samp{NONE} for no initialization (faster); other options
+are @samp{NAN} for not-a-number with mantissa @samp{0x40f95} or
+a custom hexadecimal value.
+
[EMAIL PROTECTED] GFORTRAN_MEM_CHECK
[EMAIL PROTECTED] @env{GFORTRAN_MEM_CHECK}---Default initialization of
allocated memory
+
+If the first letter is @samp{y}, @samp{Y} or @samp{1}, memory which is still
+allocated when the program ends is reported; it is not reported if the first
+letter is @samp{n}, @samp{N} or @samp{0}. Default is not to report.
+
[EMAIL PROTECTED] GFORTRAN_SIGHUP
[EMAIL PROTECTED] @env{GFORTRAN_SIGHUP}---Behavior on SIGHUP
+
+When the @env{GFORTRAN_SIGHUP} variable is set to @samp{IGNORE}, the signal
+SIGHUP is ignored. It it is set to @samp{ABORT}, the program aborts.
+Default is to abort.
+
[EMAIL PROTECTED] GFORTRAN_SIGINT
[EMAIL PROTECTED] @env{GFORTRAN_SIGINT}---Behavior on SIGINT
+
+When the @env{GFORTRAN_SIGINT} variable is set to @samp{IGNORE}, the signal
+SIGINT is ignored. It it is set to @samp{ABORT}, the program aborts.
+Default is to abort.
+
[EMAIL PROTECTED] GFORTRAN_FPU_ROUND
[EMAIL PROTECTED] @env{GFORTRAN_FPU_ROUND}---Floating point rounding
+
+The @env{GFORTRAN_FPU_ROUND} variable specifies the floating point
+rounding. Possible values are: to round to the @samp{NEAREST}
+integer, to always round @samp{UP}, to always round @samp{DOWN},
+or to round always towards @samp{ZERO}. Default is to round
+to the nearest integer.
+
[EMAIL PROTECTED] GFORTRAN_FPU_PRECISION
[EMAIL PROTECTED] @env{GFORTRAN_FPU_PRECISION}---Precision of intermediate
results
+
+The @env{GFORTRAN_FPU_PRECISION} variable specifies the precision
+of intermediate results. Possible values are
[EMAIL PROTECTED], @samp{53} and @samp{64}. Default is @samp{64}.
+
@node GFORTRAN_CONVERT_UNIT
@section @env{GFORTRAN_CONVERT_UNIT}---Set endianness for unformatted I/O
--
Summary: Fix,document,remove GFORTRAN_* environment variables
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32021
[Bug fortran/32021] Fix,document,remove GFORTRAN_* environment variables
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-21 14:29 --- For GFORTRAN_SIG* one could also add an option to backtrace/dump in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32021
[Bug c++/32022] New: Invalid template error on non-dependent name
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++ EE 2005.
Here is the source code:
class template_function
{
public:
template int N
int func()
{
return N;
};
};
class non_template_class
{
public:
template_function tf;
void run()
{
tf.func36(); // SUCCESS
}
};
// The PointLess template parameter makes gcc
// fail to see that tf is a non-dependent name
template int PonitLess
class template_class
{
public:
template_function tf;
void run()
{
tf.func42(); // FAIL
}
};
int main()
{
non_template_class ntc;
ntc.run();
template_class0 tc;
tc.run();
return 0;
}
Here is the output of G++:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/cpp0 -lang-c++ -D__GNUG__=3
-D__DEPRECATED -D__EXCEPTIONS -v -D__GNUC__=3 -D__GNUC_MINOR__=2
-D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix
-D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__
-D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1
-D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__
-D__tune_i386__ main.cpp -Wall main.ii
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (cpplib) (i386
Linux/ELF)
ignoring nonexistent directory /usr/i386-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/3.2.3
/usr/include/c++/3.2.3/i386-redhat-linux
/usr/include/c++/3.2.3/backward
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -Wall -version -o main.s
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (cpplib) (i386
Linux/ELF)
GNU C++ version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (i386-redhat-linux)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-34).
main.cpp: In member function `void template_classPonitLess::run()':
main.cpp:34: syntax error before `;' token
And here is the main.ii file:
# 1 main.cpp
# 1 built-in
# 1 command line
# 1 main.cpp
class template_function
{
public:
template int N
int func()
{
return N;
};
};
class non_template_class
{
public:
template_function tf;
void run()
{
tf.func36();
}
};
template int PonitLess
class template_class
{
public:
template_function tf;
void run()
{
tf.func42();
}
};
int main()
{
non_template_class ntc;
ntc.run();
template_class0 tc;
tc.run();
return 0;
}
--
Summary: Invalid template error on non-dependent name
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trundeg at hotmail dot com
GCC host triplet: Linux cfr1ll19 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55
EDT 200
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32022
[Bug libstdc++/25288] std::list insert members should have no effects if an exception is thrown
--- Comment #7 from pcarlini at suse dot de 2007-05-21 15:00 --- *** Bug 32017 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25288
[Bug libstdc++/32017] Exception-safety bug
--- Comment #3 from pcarlini at suse dot de 2007-05-21 15:00 --- This specific bug is already fixed and must be marked as duplicate. Then we have 21772, more general. We know what we are doing, thanks. *** This bug has been marked as a duplicate of 25288 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug fortran/30964] optional arguments to random_seed
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:21 --- Created an attachment (id=13595) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13595action=view) Patch for that issue; not tested yet -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug fortran/31198] wrong code: Max() with optional arguments
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:25 --- Scanning the F2003 standard, MIN/MAX are the only intrinsics with a variable number of arguments. They probably need special handling. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 13:42:06 |2007-05-21 15:25:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug c/32023] New: Invalid lvalue in void* increment error inconsitensy
The following program doesn't compile due to invalid lvalue in increment. The
most strange thing is that gcc somehow ignores type coercion
int main ()
{
int **a;
void **b;
*b++;/* works fine */
*((void **)a)++; / gives error */
return 0;
}
--
Summary: Invalid lvalue in void* increment error inconsitensy
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nshmyrev at yandex dot ru
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #16 from hjl at lucon dot org 2007-05-21 15:33 ---
Gcc 4.1/4.2/4.3 will fail and gcc 3.4 has no problem:
---
typedef unsigned long bngdigit;
typedef bngdigit *bng;
typedef unsigned int bngcarry;
typedef unsigned long bngsize;
bngdigit
bng_ia32_mult_sub_digit (bng a, bngsize alen, bng b, bngsize blen, bngdigit d)
{
bngdigit out, tmp;
bngcarry carry;
bngdigit a11;
int x = blen;
out = 0;
asm (
: +r (a), +r (b), +mr (blen), +mr (out), =r (tmp)
: mr (d)
: eax, edx);
if (alen == blen)
{
a11 = out;
goto t;
}
if (x == 0)
goto t;
a11 = 1;
t:
return a11;
}
---
--
hjl at lucon dot org changed:
What|Removed |Added
Summary|[4.3 regression] : |[4.1/4.2/4.3 regression] :
|gcc.target/i386/pr21291.c |can't find a register in
||class 'GENERAL_REGS' while
||reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #99 from jv244 at cam dot ac dot uk 2007-05-21 15:40 --- (In reply to comment #98) Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64 equivalent and got the ICE described in PR32018. thanks for adding this PR. Looking at PR32018, I notice that the segfault you've observed is actually in a different subroutine (file) than what I reported above (based on a run on an opteron). The file you've extracted compiles fine here. It could still be the same issue though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c++/32022] Invalid template error on non-dependent name
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 --- *** This bug has been marked as a duplicate of 32020 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32022
[Bug c++/32020] Invalid template error on non-dependent name
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 --- *** Bug 32022 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
[Bug c++/32020] Invalid template error on non-dependent name
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |3.4.0 Version|unknown |3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
[Bug bootstrap/29382] Bootstrap comparison failure!
--- Comment #3 from tru at pasteur dot fr 2007-05-21 15:43 --- [EMAIL PROTECTED] ~]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-58) [EMAIL PROTECTED] ~]$ rpm -q gcc gcc-3.2.3-58.i386 is failing too, but a plain gcc-3.4.6 can bootstrap gcc-4.2.0 -- tru at pasteur dot fr changed: What|Removed |Added CC||tru at pasteur dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382
[Bug c/32023] Invalid lvalue in void* increment error inconsitensy
--- Comment #1 from schwab at suse dot de 2007-05-21 15:45 --- A cast is not an lvalue. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
[Bug libstdc++/32017] consistent exception-safety container testing
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:57 --- Dave, just to clarify, this is bug 21772. We're working on it. ;) -benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Summary|Exception-safety bug|consistent exception-safety ||container testing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #100 from jv244 at cam dot ac dot uk 2007-05-21 15:58 ---
(In reply to comment #99)
(In reply to comment #98)
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
thanks for adding this PR.
Looking at PR32018, I notice that the segfault you've observed is actually in
a
different subroutine (file) than what I reported above (based on a run on an
opteron). The file you've extracted compiles fine here. It could still be the
same issue though.
might be a different issue, the trace I see here is :
(gdb) run -O3 -ftree-vectorize -ffast-math -march=opteron
semi_empirical_int_ana.f90
Starting program:
/scratch/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951
-O3 -ftree-vectorize -ffast-math -march=opteron semi_empirical_int_ana.f90
check_dterep_ana dterep_ana rotint_ana {GC 8106k - 5800k} dtaper_ana
dnucint_ana check_dnucint_ana invert_derivative invert_integral rotnuc_ana {GC
8112k - 7433k}
Analyzing compilation unit
{GC 10372k - 9175k}Performing interprocedural optimizations
visibility early_local_cleanups {GC 14010k - 13275k} inline
static-var pure-const type-escape-varAssembling functions:
dtaper_ana invert_integral invert_derivative check_dnucint_ana dnucint_ana {GC
17386k - 12699k} rotnuc_ana {GC 16571k - 13382k} dterep_ana {GC 17536k -
11295k}
Program received signal SIGSEGV, Segmentation fault.
verify_ssa_name (ssa_name=0xa5a5a5a5a5a5a5a5, is_virtual=0 '\0') at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:109
109 if (TREE_CODE (ssa_name) != SSA_NAME)
(gdb) bt
#0 verify_ssa_name (ssa_name=0xa5a5a5a5a5a5a5a5, is_virtual=0 '\0') at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:109
#1 0x00784305 in verify_ssa (check_modified_stmt=1 '\001') at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:716
#2 0x006082d5 in execute_function_todo (data=Variable data is not
available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:918
#3 0x0060803b in execute_todo (flags=Variable flags is not
available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:942
#4 0x0060851a in execute_one_pass (pass=0xcc4b80) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1087
#5 0x0060867c in execute_pass_list (pass=0xcc4b80) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1117
#6 0x0060868e in execute_pass_list (pass=0xcc4160) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1118
#7 0x0060868e in execute_pass_list (pass=0xcc3fe0) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1118
#8 0x0060868e in execute_pass_list (pass=0xcc3440) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1118
#9 0x006d2378 in tree_rest_of_compilation (fndecl=0x2a95b3ca00) at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:406
#10 0x0080ff50 in cgraph_expand_function (node=0x2a95c34700) at
/scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1086
#11 0x008123f2 in cgraph_optimize () at
/scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1155
#12 0x00465ebd in gfc_be_parse_file (set_yydebug=Variable set_yydebug
is not available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:307
#13 0x006818e4 in toplev_main (argc=Variable argc is not available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/toplev.c:1051
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug libstdc++/21772] exception safety testing allocator
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:58 --- This is now integrated, but the tests are still ad-hoc. We need a more consistent application of eh-safety tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
