Re: GCC 4.2.0 Status Report (2007-03-04)
Mark Mitchell wrote: However, I do think that it's important to eliminate some of the 139 open P2 and P1 regressions [2], especially those P1 regressions which did not appear in GCC 4.1.x. 133, not 139. Your search url returns six P3 bugs, one of which (29441) is not even a regression. Does that count as six for my tally? :) - Brooks
Re: RTL insns getting deleted
Rohit Arul Raj wrote: 1. emit_insn to set the flag (moving data to special registers). 2. emit_insn for add_float insn. 3. DONE [...] Any specific reason why these are getting deleted and how to overcome this? I think its maybe because there is no connection between 1. and 2. (or at least gcc thinks it). And because he wanted just 2. in the first place he thinks that he can optimize 1. away. There are different ways to overcome this: a. make the add_float-pattern not only match the add but also the setting of the flags, this way they kept together b. make 1. volatile so he didnt optimize it away (but then it will also remain there if he can optimize 2. away) c. add to the add_float (use special_reg) or whatever to tell him that he requires the special registers. Florian
passes not maintaining CFG ?
hello all, I would like to output a CFG (preferably in VCG format) which describes the final binary. Is it doable or do the last RTL passes change the CFG ? I see that the last vcg outputable is file.c.49.stack.vcg - is it a good description of the final binary flow ? Thank you all sunzir
Re: GCC 4.2.0 Status Report (2007-03-04)
On 05/03/07, Mark Mitchell [EMAIL PROTECTED] wrote: After reviewing all of the traffic[1] that stemmed from my previous status report, I've decided that, indeed, it makes sense to steam ahead with GCC 4.2.0 based on current GCC 4.2.0 release branch. I ask special permission to apply this patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01461.html to GCC 4.2.0. This patch is trivial and it has been in GCC 4.3 for a few weeks already. It replaces two options that are introduced in GCC 4.2 with a single switch -Waddress. I think we should replace them before releasing, to minimise the effect of the change in users. In addition, there are two trivial doc fixes for GCC 4.2, one in invoke.texi and another in opts.c, where it says -Werror- and it should say -Werror= Can I commit them as obvious or do I need to submit a patch? Cheers, Manuel.
Re: GCC project participation in the 2007 Google Summer of Code program?
On 04 Mar 2007 16:22:33 -0800, Ian Lance Taylor ian@airs.com wrote: Yes, we do plan to participate. That link goes to the SoC page for gcc. Right now it's still the 2006 one, but I would assume it will probably the right one once the 2007 setup gets going. OK - I have updated http://www.gnu.org/software/soc-projects/ideas.html accordingly. James.
Re: Massive SPEC failures on trunk
I observe a massive compilation time regression for bootstrap on x86-64 here, in particular libjava now appears to take *ages* to build: I cannot reproduce today at the same revision: real275m23.314s user242m28.724s sys 12m18.249s Something went awry with kpowersave yesterday... sorry for the noise. -- Eric Botcazou
Cross Compiler to Native Compiler
Hi, I am porting/developing GCC onto a new platform. This platform already have a cross tool chain. Can anybody give me a roadmap to port GCC in native environment from scratch? or Way to convert, Croos-Compiler to Native-Compiler? Thanks n Regards, Kapil __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/
Re: vcond implementation in altivec
David Edelsohn [EMAIL PROTECTED] wrote on 02.03.2007 19:10:58: Devang Patel writes: Is there a reason why op0 is V4SF Devang It is destination so, yes this is wrong. and op1 is V4SI (and not V8HI)? Devang condition should be v4si, but it is not op1. So this is also not correct. And also, why not use if_then_else instead of unspec (in all vcond's)? Devang I did not try that path. May be I did not know about it at that time. Patches welcome. David I am working on the patch and will submit it soon. Sa
Re: Fw: Cross Compiler to Native Compiler
Just use your cross-compiler to build a compiler for the target system that'll run on the target system. Then it could be good idea to use new native compiler on its hardware to rebuild gcc once again natively. Two compilers from last two steps should be identical. It's a good way to make sure your cross and native compilers are working correctly, and generating code that actually runs. Have a look at how canadian cross compiler are built, that might give you a hint. Some hacking the script for building canadian cross-compiler may help (See CrossGCC FAQ for details - http://vmlinux.org/crash/mirror/www.objsw.com/CrossGCC/). But be sure to edit specs and change cross_compile to 0 later as specs are dumped by cross-compiler. you can find some more info in this thread: http://sourceware.org/ml/crossgcc/2005-02/msg5.html -- Victor Cross Compiler to Native Compiler Hi, I am porting/developing GCC onto a new platform. This platform already have a cross tool chain. Can anybody give me a roadmap to port GCC in native environment from scratch? or Way to convert, Croos-Compiler to Native-Compiler? Thanks n Regards, Kapil
Re: Who should fix platforms broken by extern inline hack?
On Mon, 4 Mar 2007, Ian Lance Taylor wrote: FX Coudert [EMAIL PROTECTED] writes: I'd like to ping these two problems :) i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc- mingw32 (latest released version) are still completely broken on mainline, as they have been for more that three months. This patch (not yet approved) is my contribution to fixing the problem. http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00021.html I was supposing there would be a patch repost following http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00097.html with the current versions of the patch for consideration. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Improvements of the haifa scheduler
Maxim Kuvyrkov wrote on 03/05/07 02:14:
o Fix passes that invalidate tree-ssa alias export.
Yes, this should be good and shouldn't need a lot of work.
o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa alias
export } in scheduler's data speculation.
unsafe alias export? I would definitely like to see the tree-rtl
alias information transfer fixed once and for all. Finishing RAS's
tree-rtl work would probably make a good SoC project.
subreg pass
Hi,
The new subreg lowering pass seems to generate a bit worse code on m68k
than before, let's take simple example:
unsigned long long f(unsigned long long a, unsigned long long b)
{
return a + b;
}
where currently gcc generates code like this:
move.l 16(%sp),%d1
move.l 20(%sp),%d2
move.l 8(%sp),%d0
add.l 12(%sp),%d2
addx.l %d0,%d1
move.l %d1,%d0
move.l %d2,%d1
whereas with -fno-split-wide-types it generates this:
move.l 16(%sp),%d0
move.l 20(%sp),%d1
move.l 8(%sp),%d2
add.l 12(%sp),%d1
addx.l %d2,%d0
How can I get rid of these extra move instructions?
Another more general question would be how should be wide registers
handled in general. In the past I tried to avoid splitting instructions
before reload, exactly because the extra subregs caused worse code. Has
this changed? AFAICT this would mean in the back end to split DI values as
early as possible, which could have its advantages, but also its
challenges, as m68k is still a cc0 target and with instructions like
addx.l above, so far I avoided splitting these at all.
bye, Roman
Re: Massive SPEC failures on trunk
Hi, All Try minimal reproducer for internal compiler error attached. See go file for command line and report.log for issue reported by trunk compiler/ -Vladimir On 3/5/07, Eric Botcazou [EMAIL PROTECTED] wrote: I observe a massive compilation time regression for bootstrap on x86-64 here, in particular libjava now appears to take *ages* to build: I cannot reproduce today at the same revision: real275m23.314s user242m28.724s sys 12m18.249s Something went awry with kpowersave yesterday... sorry for the noise. -- Eric Botcazou cutted.tgz Description: GNU Zip compressed data
Re: GCC 4.2.0 Status Report (2007-03-04)
On Mon, 5 Mar 2007, Manuel López-Ibáñez wrote: In addition, there are two trivial doc fixes for GCC 4.2, one in invoke.texi and another in opts.c, where it says -Werror- and it should say -Werror= Can I commit them as obvious or do I need to submit a patch? Both. :-) That is, go ahead and commit the patch but post it to the gcc-patches list as well. Gerald
Re: Improvements of the haifa scheduler
Vladimir N. Makarov wrote: Good aliasing is very important for the scheduler. But I'd look at this more wider. We need a good aliasing for many RTL optimizations. What's happened to ISP RAS aliasing patch propagating SSA info to RTL? Why is it stalled? We'll plan to work on it further in the near future. The initial plan was to update it to trunk, then to gather the new numbers of disambiguations and stuff, then to check the consistency of the saved information via some verifier. As for Sanjiv Gupta's aliasing work, that was interesting but as I remember the patch made compiler too slow (like 40% slower). You should make this approach faster to make it accepted as used by default. Alexander Monakov was working on it in the last year (CC'd). I have looked through his paper to recall what was done: - instead of iterating over cfg, a single iteration in topological order was made to calculate address descriptors (which was enough for using this info in the scheduler); - instead of one per-function hashtable for all address descriptors, separate per-bb hashtables were introduced, lowering the time needed to access hashtables; - instead of saving out lists of descriptors for each bb, in lists were saved (and not recalculated several times); - saving descriptors for each mem instead of each bb. Earlier, when an aliasing query was made, we've searched for insns corresponding to mems via hashtable, then reanalyzed a basic block up to that insns, then answered on the query using calculated address descriptors. After the fix, we've just got the final descriptor from the first hashtable, then answered the query. After all fixes, bootstrap and cc1-i-files compiled slower on 2%. The compiler built with the patch enabled compiled tramp3d on 0.5% faster and produced 0.6% faster code. We'll dig out this patch together with the rest of aliasing patches and will send it as a RFC. It is my mistake for not doing this earlier. If you need benchmarking for machines (like ppc) you have no access to, I can provide the benchmarking. That's great, because we have access to powerpc750 only. I have used it to try the scheduler on ppc, but that was slow. I really appreciate. May be if you or ISP RAS could find students (e.g. from Moscow University) to do this as Google Summer Code, it could help you. I think it is not too late. You should ask Ian Taylor or Daniel Berlin, if you want to do this. We'll work on aliasing anyways (see above). Three students are working with us, but they are busy with different projects. I'll ask my advisor about it. Andrey
Re: Massive SPEC failures on trunk
Hi, All
Sorry for my previous post. It was into wrong place.
There is minimal reproducer for cpu2006/h264ref is attached
use
gcc -O2 -c ./image.c
Compiler from trunk produces:
image.c: In function 'UnifiedOneForthPix':
image.c:35: internal compiler error: in set_value_range, at tree-vrp.c:267
-Vladimir
On 3/4/07, Grigory Zagorodnev [EMAIL PROTECTED] wrote:
Grigory Zagorodnev wrote:
Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC
CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level.
Regression introduced somewhere between revision 122487 and 122478.
http://gcc.gnu.org/viewcvs?view=revrevision=122487
Almost all regressions are due to r122487
cpu2006: 403.gcc 416.gamess 434.zeusmp 464.h264ref 465.tonto
cpu2000: 178.galgel 186.crafty
http://gcc.gnu.org/viewcvs?view=revrevision=122484
cpu2006/447.dealII is due to revision 122484.
I'll bring more information and try to get minimal reproducers at Monday.
- Grigory
typedef unsigned char byte;//! byte type definition
#define max(a, b) (((a) (b)) ? (a) : (b))
#define min(a, b) (((a) (b)) ? (a) : (b))
typedef long long int64;
#define imgpel unsigned short
#define pel_t imgpel
#define IMG_PAD_SIZE4 //! Number of pixels padded around the reference
frame (=4)
#define MAX_LIST_SIZE 33
#define imgpel unsigned short
int**img4Y_tmp; //! for quarter pel interpolation
typedef struct storable_picture
{
int size_x, size_y;
imgpel ** imgY; //! Y picture component
} StorablePicture;
const int ONE_FOURTH_TAP[3][2] =
{
{20,20},
{-5,-4},
{ 1, 0},
};
void UnifiedOneForthPix (StorablePicture *s)
{
int i, j, jj,is;
imgpel **imgY = s-imgY;
for (i = -IMG_PAD_SIZE; i s-size_x + IMG_PAD_SIZE; i++)
{
is =
(ONE_FOURTH_TAP[0][0] *
(imgY[jj][max (0, min (s-size_x - 1, i))] +
imgY[jj][max (0, min (s-size_x - 1, i + 1))]) +
ONE_FOURTH_TAP[1][0] *
(imgY[jj][max (0, min (s-size_x - 1, i - 1))] +
imgY[jj][max (0, min (s-size_x - 1, i + 2))]) +
ONE_FOURTH_TAP[2][0] *
(imgY[jj][max (0, min (s-size_x - 1, i - 2))] +
imgY[jj][max (0, min (s-size_x - 1, i + 3))]));
img4Y_tmp[j + IMG_PAD_SIZE][(i + IMG_PAD_SIZE) * 2 + 1] = is * 32; //
1/2 pix pos
}
}
Re: Improvements of the haifa scheduler
Diego Novillo wrote:
Maxim Kuvyrkov wrote on 03/05/07 02:14:
o Fix passes that invalidate tree-ssa alias export.
Yes, this should be good and shouldn't need a lot of work.
o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa alias
export } in scheduler's data speculation.
unsafe alias export? I would definitely like to see the tree-rtl
alias information transfer fixed once and for all. Finishing RAS's
tree-rtl work would probably make a good SoC project.
Unsafe doesn't mean not fixed. My thought is that it would be nice to
have a switch in aliasing that will turn such operations as
join (pt_anything, points_to) - pt_anything
into
join (pt_anything, points_to) - points_to
This transformation will sacrifice correctness for sake of additional
information.
Thanks,
Maxim
Re: Failed
On Sun, 4 Mar 2007, Gerald Pfeifer wrote: I investigated a bit, and it seems that unlike gcc.gnu.org, www.gnu.org lacks the latest revision (at least) of the bin/preprocess script in our wwwdocs module: revision 1.43 date: 2006/06/10 21:52:24; author: gerald; state: Exp; lines: +2 -0 Use sed to work around MetaHTML brokenness wrt. DIV. I have contacted the GNU sysadmins and asked them to update to the latest version of the script. I got a heads up that they did that now, so the problem should be resolved going forward. Please give www.gnu.org twenty-four hours to sync up. Gerald
question about PASSES
hi all, these are the last passes: NEXT_PASS (pass_stack_regs); // last pass to generate VCG file NEXT_PASS (pass_compute_alignments); NEXT_PASS (pass_duplicate_computed_gotos); NEXT_PASS (pass_variable_tracking); NEXT_PASS (pass_free_cfg); NEXT_PASS (pass_machine_reorg); NEXT_PASS (pass_purge_lineno_notes); NEXT_PASS (pass_cleanup_barriers); NEXT_PASS (pass_delay_slots); NEXT_PASS (pass_split_for_shorten_branches); NEXT_PASS (pass_convert_to_eh_region_ranges); NEXT_PASS (pass_shorten_branches); NEXT_PASS (pass_set_nothrow_function_flags); NEXT_PASS (pass_final); / translating to assembly (--binary) the pass_stack_regs is the last one which generates a vcg file (graph of flow). the pass_final is of course the one which translates to assembly, therefore after it I assume the flow of the code does not change. my question is whether I can use the flow dumped by pass_stack_regs pass and assume it is legal as the flow of the real binary ? of do any of the passes between them change the flow ? thank you all sunzir
Re: reload.c as a bugzilla quip
On Sun, Mar 04, 2007 at 09:45:13AM +0100, FX Coudert wrote: One of the bugzilla quips (the headlines appearing at random for each bug list) is actually the head of gcc/reload.c (full text below). That is really obnoxious and should be removed.
Re: Improvements of the haifa scheduler
Maxim Kuvyrkov [EMAIL PROTECTED] writes:
So basically here are three Google Summer of Code projects:
o Scheduler - RA
o Fix passes that invalidate tree-ssa alias export.
o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa alias
export } in scheduler's data speculation.
Ian, Daniel, what do you think?
I think that any of these patches would be quite difficult for anybody
not already familiar with gcc. But for somebody who already
understands the aliasing representation, they would make good
projects.
Can you add them somewhere on this page, or linked from this page:
http://gcc.gnu.org/wiki/SummerOfCode
Thanks!
Ian
Re: Who should fix platforms broken by extern inline hack?
Joseph S. Myers [EMAIL PROTECTED] writes:
On Mon, 4 Mar 2007, Ian Lance Taylor wrote:
FX Coudert [EMAIL PROTECTED] writes:
I'd like to ping these two problems :)
i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc-
mingw32 (latest released version) are still completely broken on
mainline, as they have been for more that three months.
This patch (not yet approved) is my contribution to fixing the
problem.
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00021.html
I was supposing there would be a patch repost following
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00097.html with the current
versions of the patch for consideration.
I only made one of the changes Jakub suggested: I fixed a typo in the
documentation. So I didn't bother sending another copy.
For clarity, here is the current version of the patch.
Ian
gcc/ChangeLog:
2007-03-05 Ian Lance Taylor [EMAIL PROTECTED]
* c.opt (fgnu89-inline): New option.
* c-opts.c (c_common_post_options): Set default value for
flag_gnu89_inline.
* c-decl.c (WANT_C99_INLINE_SEMANTICS): Remove.
(pop_scope): Check flag_gnu89_inline rather than flag_isoc99 for
inline functions.
(diagnose_mismatched_decls, merge_decls, start_decl): Likewise.
(grokdeclarator, start_function): Likewise.
* c-cppbuiltin.c (c_cpp_builtins): Define either
__GNUC_GNU_INLINE__ or __GNUC_STDC_INLINE__.
* doc/invoke.texi (Option Summary): Mention -fgnu89-inline.
(C Dialect Options): Document -fgnu89-inline.
* doc/extend.texi (Function Attributes): Explain what the
gnu_inline attribute does.
* doc/cpp.texi (Common Predefined Macros): Document
__GNUC_GNU_INLINE__ and __GNUC_STDC_INLINE__.
gcc/testsuite/ChangeLog:
2007-03-05 Ian Lance Taylor [EMAIL PROTECTED]
* gcc.dg/inline-18.c: New test.
* gcc.dg/inline-19.c: New test.
* gcc.dg/inline-20.c: New test.
* gcc.dg/inline-21.c: New test.
Index: gcc/doc/cpp.texi
===
--- gcc/doc/cpp.texi(revision 122560)
+++ gcc/doc/cpp.texi(working copy)
@@ -2014,6 +2014,28 @@ functions. You should not use these mac
sure that programs will execute with the same effect whether or not they
are defined. If they are defined, their value is 1.
[EMAIL PROTECTED] __GNUC_GNU_INLINE__
+GCC defines this macro if functions declared @code{inline} will be
+handled in GCC's traditional gnu89 mode. In this mode an @code{extern
+inline} function will never be compiled as a standalone function, and
+an @code{inline} function which is neither @code{extern} nor
[EMAIL PROTECTED] will always be compiled as a standalone function.
+
[EMAIL PROTECTED] __GNUC_STDC_INLINE__
+GCC defines this macro if functions declared @code{inline} will be
+handled according to the ISO C99 standard. In this mode an
[EMAIL PROTECTED] inline} function will always be compiled as a standalone
+externally visible function, and an @code{inline} function which is
+neither @code{extern} nor @code{static} will never be compiled as a
+standalone function.
+
+If this macro is defined, GCC supports the @code{gnu_inline} function
+attribute as a way to always get the gnu89 behaviour. Support for
+this and @code{__GNUC_GNU_INLINE__} was added in GCC 4.1.3. If
+neither macro is defined, an older version of GCC is being used:
[EMAIL PROTECTED] functions will be compiled in gnu89 mode, and the
[EMAIL PROTECTED] function attribute will not be recognized.
+
@item __CHAR_UNSIGNED__
GCC defines this macro if and only if the data type @code{char} is
unsigned on the target machine. It exists to cause the standard header
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 122560)
+++ gcc/doc/extend.texi (working copy)
@@ -1618,8 +1618,37 @@ if no optimization level was specified.
@item gnu_inline
@cindex @code{gnu_inline} function attribute
-This attribute on an inline declaration results in the old GNU C89
-inline behavior even in the ISO C99 mode.
+This attribute should be used with a function which is also declared
+with the @code{inline} keyword. It directs GCC to treat the function
+as if it were defined in gnu89 mode even when compiling in C99 or
+gnu99 mode.
+
+If the function is declared @code{extern}, then this definition of the
+function is used only for inlining. In no case is the function
+compiled as a standalone function, not even if you take its address
+explicitly. Such an address becomes an external reference, as if you
+had only declared the function, and had not defined it. This has
+almost the effect of a macro. The way to use this is to put a
+function definition in a header file with this attribute, and put
+another copy of the function, without @code{extern}, in a library
+file. The definition in the header file
Re: subreg pass
Roman Zippel [EMAIL PROTECTED] writes:
The new subreg lowering pass seems to generate a bit worse code on m68k
than before, let's take simple example:
unsigned long long f(unsigned long long a, unsigned long long b)
{
return a + b;
}
where currently gcc generates code like this:
move.l 16(%sp),%d1
move.l 20(%sp),%d2
move.l 8(%sp),%d0
add.l 12(%sp),%d2
addx.l %d0,%d1
move.l %d1,%d0
move.l %d2,%d1
whereas with -fno-split-wide-types it generates this:
move.l 16(%sp),%d0
move.l 20(%sp),%d1
move.l 8(%sp),%d2
add.l 12(%sp),%d1
addx.l %d2,%d0
How can I get rid of these extra move instructions?
The standard answer would be to add a define_split for the adddi3 insn
which triggers before reload. But that is problematic on a CC0 system
where you want to preserve the overflow flag. I'm not sure what to
suggest at the moment. Note that there is still an extra move.l insn
in the -fno-split-wide-types version.
Another more general question would be how should be wide registers
handled in general. In the past I tried to avoid splitting instructions
before reload, exactly because the extra subregs caused worse code. Has
this changed? AFAICT this would mean in the back end to split DI values as
early as possible, which could have its advantages, but also its
challenges, as m68k is still a cc0 target and with instructions like
addx.l above, so far I avoided splitting these at all.
Yes, it is in general better now to split double-word length
operations before reload. It's not necessarily better to split as
early as possible, as that will essentially disable the RTL level loop
optimizations. But it's still problematic to split before reload on a
CC0 system.
Ian
Re: [RFC]possible improvements to --with-sysroot
First of all, my apology. It seems that I should have posted this
email to binutils's ML.
On 3/5/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Sat, Mar 03, 2007 at 09:47:41PM +0800, Zhang Le wrote:
Wouldn't it be great that we go one step further that we let ld look
for libraries in the dir listed in $SYSROOT/etc/ld.so.conf, if this
file ever exits? Of course for each entry in $SYSROOT/etc/ld.so.conf,
we prefix $SYSROOT to it.
Did you try it? This should already happen if you configured binutils
with a sysroot.
Yes, I have tried.
My distribution is Gentoo, I used the crossdev utility to build the
cross toolchain.
The related code is:
is_cross myconf=${myconf} --with-sysroot=/usr/${CTARGET}
I was cross compiling KDE. However, it's failed because linker can't
find -lqt-mt.
I have used strace -f to check where linker looked for -lqt-mt. From
what I have observed, it seems that ld didn't use
$SYSROOT/etc/ld.so.conf.
--
Zhang Le, Robert
Linux Engineer/Trainer
http://zhllg.blogspot.com
http://zh.gentoo-wiki.com
http://savannah.nongnu.org/projects/pgubook
http://groups.google.com/group/gentoo-china
http://groups.google.com/group/szlug
Re: [RFC]possible improvements to --with-sysroot
On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote: I have used strace -f to check where linker looked for -lqt-mt. From what I have observed, it seems that ld didn't use $SYSROOT/etc/ld.so.conf. Well, it's supposed to, so I suggest you check what's happened in ld. -- Daniel Jacobowitz CodeSourcery
Re: [RFC]possible improvements to --with-sysroot
On 3/6/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote: I have used strace -f to check where linker looked for -lqt-mt. From what I have observed, it seems that ld didn't use $SYSROOT/etc/ld.so.conf. Well, it's supposed to, so I suggest you check what's happened in ld. Thanks, will do -- Zhang Le, Robert Linux Engineer/Trainer http://zhllg.blogspot.com http://zh.gentoo-wiki.com http://savannah.nongnu.org/projects/pgubook http://groups.google.com/group/gentoo-china http://groups.google.com/group/szlug
RE: new auto-inc-dec pass
Hi, I'mm currently looking at the dataflow branch for m68k mainly because of the new auto-inc-dec pass, I worked a bit on the old code in flow.c, but considering the new pass, I think it doesn't make much sense to continue it. I agree. With high probability the auto inc detection will be replaced with the new auto-inc-dec.c on the dataflow branch. I would certainly encourage you to enhance the new code in auto-inc-dec.c where you find that it is lacking. That code does get all of the cases that were found by the old version of flow and does get many things that were missed. But there is no expectation that this is the last word in auto-inc-dec detection. My main concern was to cleanly separate this function from flow without any regressions. I'm attaching my current patch and some test cases, but before delving deeper into the code, I have a few questions and I'd like to hear some opinions. Currently I only looked at the output and it misses some opportunities (not that my patch can do everything either :) ). I agree that the auto-inc-dec code will already get much of this. In particular there is no longer (unless the machine requirres it) a reliance that the increment match the size of the load or store. One case is about multiple increments, the tree optimizer merges them and increments the register only once, so if one only looks at the size of the pointer value one misses them, e.g. something like this: (set (mem (reg)) (x)) (set (mem (plus (reg) (const_int 4))) (x)) (set (reg) (plus (reg) (const_int 8)) Another case are multiple uses of the register within an instruction, the old code didn't do this at all, the new code seems to do a bit better, but there as a rather tricky case I looked into, e.g. (set (mem) (plus (mem) (reg))) could be turned into: (set (post_inc (mem)) (plus (mem) (reg))) I do find this a little wierd but if it makes a difference go for it. or (set (mem) (plus (pre_dec (mem)) (reg))) This is at least what operands_match_p() accepts, but hasn't been generated in a long time and has the potential to trigger bugs in the back end (e.g. m68k only looks only at one of the operands). A question would be now if there is a general interest in reactivating this, so gcc could generate a instruction like add.l %d0,(%a0)+ for m68k. The more general question is whether someone is already working on further improvements, so I won't duplicate anything (which wouldn't be before I looked into the remaining m68k dataflow problems anyway. :) ). We have stopped development on this piece of code. It is efficient and works with no regressions on arm, ppc and ia-64. So it meets the minimun criteria for inclusion onto mainline with the upcoming merge. However, that should in no way stop anyone else from enhancing it further. The dataflow porting document mentions other possible, but doesn't mention any examples. Anything I might have to look out for regardings the m68k post_inc/pre_dec addressing modes? bye, Roman Kenny
Re: Who should fix platforms broken by extern inline hack?
On Mon, 5 Mar 2007, Ian Lance Taylor wrote: I only made one of the changes Jakub suggested: I fixed a typo in the documentation. So I didn't bother sending another copy. For clarity, here is the current version of the patch. This patch is OK. -- Joseph S. Myers [EMAIL PROTECTED]
Re: subreg pass
Hi, On Mon, 5 Mar 2007, Ian Lance Taylor wrote: whereas with -fno-split-wide-types it generates this: move.l 16(%sp),%d0 move.l 20(%sp),%d1 move.l 8(%sp),%d2 add.l 12(%sp),%d1 addx.l %d2,%d0 How can I get rid of these extra move instructions? The standard answer would be to add a define_split for the adddi3 insn which triggers before reload. But that is problematic on a CC0 system where you want to preserve the overflow flag. I'm not sure what to suggest at the moment. Note that there is still an extra move.l insn in the -fno-split-wide-types version. Actually it's correct, addx.l needs two registers. :) Another more general question would be how should be wide registers handled in general. In the past I tried to avoid splitting instructions before reload, exactly because the extra subregs caused worse code. Has this changed? AFAICT this would mean in the back end to split DI values as early as possible, which could have its advantages, but also its challenges, as m68k is still a cc0 target and with instructions like addx.l above, so far I avoided splitting these at all. Yes, it is in general better now to split double-word length operations before reload. It's not necessarily better to split as early as possible, as that will essentially disable the RTL level loop optimizations. I was worried about that too, since some patterns would be more complicated, which may make some optimizations more difficult, e.g. where I noticed it first was mulsidi3, which currently looks like this: [(set (match_operand:SI 0 register_operand =d) (mult:SI (match_operand:SI 1 register_operand %0) (match_operand:SI 2 nonimmediate_operand dm))) (set (match_operand:SI 3 register_operand =d) (truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (match_dup 1)) (zero_extend:DI (match_dup 2))) (const_int 32] The dataflow branch doesn't like this due to the missing (strict_low_part), it's easy to fix by changing it to: [(set (match_operand:DI 0 register_operand =d) (mult:DI (zero_extend:DI (match_operand:SI 1 register_operand %0)) (zero_extend:DI (match_operand:SI 2 nonimmediate_operand dm] which is also easier to recognize as multiply for the rtl optimizers. OTOH combine runs reasonably late, so it's quite easy to add a split to bring it back to the first form (plus strict_low_part). But it's still problematic to split before reload on a CC0 system. I considered it splitting like this. (parallel (set (op0) (plus (op1) (op2))) (set (cc0) (unspec [(op1) (op2)]))) (set (op0) (plus (plus (op1) (op2)) (unspec [(cc0)]))) This should pass as cc0 setter/getter and probably needs additional work in notice_update_cc0(). bye, Roman
Re: Who should fix platforms broken by extern inline hack?
On 04/03/2007, at 12:25 AM, FX Coudert wrote: I'd like to ping these two problems :) i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386- pc-mingw32 (latest released version) are still completely broken on mainline, as they have been for more that three months. I spent some time on this but ran out. The point I got up to was that I found out that the machine I was using apparently didn't have some tool (flex, or maybe bison) which I'd have to rebuild from source. As it turns out, I do now have access to a NetBSD system, and will look at that problem when I next get time. Thanks. When you provid a patch, I will test it. (If someone else ever wants access to a netbsd system, it's worth noting there's one on the GCC compile farm!) My understanding from 30589 is that a sufficiently recent version of mingw32 has solved the problem. The CVS version of mingw32 has the workaround, but most people aren't using the CVS mingw32 (most people aren't using the last released version anyway), so there'll be a need for a fix anyway. smime.p7s Description: S/MIME cryptographic signature
Re: new auto-inc-dec pass
On Mon, Mar 05, 2007 at 03:44:20AM +0100, Roman Zippel wrote:
The dataflow porting document mentions other possible, but doesn't mention
any examples. Anything I might have to look out for regardings the m68k
post_inc/pre_dec addressing modes?
I have not checked what GCC currently generates for
void mystrcpy (char *dest, char *src)
{
while ((*dest++ = *src++))
;
}
but the loop should compile to (a1 = dest, a0 = src)
Loop:
move.b (a0)+, (a1)+
bne.s Loop
at least for -Os or -mtune=68010.
--
Rask Ingemann Lambertsen
Re: Massive SPEC failures on trunk
Vladimir Sysoev [EMAIL PROTECTED] writes: There is minimal reproducer for cpu2006/h264ref is attached use gcc -O2 -c ./image.c Compiler from trunk produces: image.c: In function 'UnifiedOneForthPix': image.c:35: internal compiler error: in set_value_range, at tree-vrp.c:267 I just committed a patch for PR 31034 which may fix this. Ian
Re: subreg pass
On Mon, Mar 05, 2007 at 02:29:05PM +0100, Roman Zippel wrote: challenges, as m68k is still a cc0 target and with instructions like addx.l above, so far I avoided splitting these at all. It would be possible to add an X register to model that one bit from the flags, since X is generally preserved, and not clobbered like the regular overflow bit. r~
Signed overflow patches OK for 4.2?
I'd like to backport the set of signed overflow patches for 4.2, now that they are (almost) all in mainline. These are the patches which add -fstrict-overflow and -Wstrict-overflow. It was the additional reliance of strict signed overflow in 4.2 which led to a long discussion a couple of months ago. This would be a new feature for 4.2, of course. Is it OK to do the backport? Thanks. Ian
Re: Signed overflow patches OK for 4.2?
On 05 Mar 2007 12:00:20 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote: This would be a new feature for 4.2, of course. Is it OK to do the backport? Way too late. Didn't Mark say he wanted to release a prelease soon? Also isn't there still some regressions associated still with this change? http://gcc.gnu.org/ml/gcc/2007-03/msg00120.html for the reference of the regressions. Thanks, Andrew Pinski
gcc and gmp/mpfr - order of build
What is the recommended order of building gcc, gmp, mpfr? I notice that now gcc depends on gmp and mpfr to build. I believe the gmp recommends using gcc to build (although it may build with other compilers). What is the recommended order of building gcc, gmp, mpfr? I can think of two options: Option A. Use the bootstrap compiler to first build gmp and mpfr, then build gcc. Option B. Build gcc without gmp and mpfr. Then use it to build gmp and mpfr. Now rebuild gcc using gmp and mpfr. Are there other options? What is recommended? Kate Minola University of Maryland, College Park
Re: Signed overflow patches OK for 4.2?
Andrew Pinski [EMAIL PROTECTED] writes: On 05 Mar 2007 12:00:20 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote: This would be a new feature for 4.2, of course. Is it OK to do the backport? Way too late. Didn't Mark say he wanted to release a prelease soon? If Mark agrees with you, then I'm unfortunately going to have to lobby to disable VRP by default in 4.2. I don't want to do that, but as we've seen in the signed overflow thread from a couple of months ago, reasonable users are surprised and disturbed by gcc 4.2's current behaviour. As you know, Paul Eggert has proposed having autoconf automatically pass -fwrapv when compiling with gcc. I think that would be extremely unfortunate. Disabling VRP by default will be the lesser of two evils. Also isn't there still some regressions associated still with this change? http://gcc.gnu.org/ml/gcc/2007-03/msg00120.html for the reference of the regressions. That one is already fixed, I believe. Ian
Re: gcc and gmp/mpfr - order of build
gcc-help is a more appropriate list... On Mar 5, 2007, at 12:19 PM, Kate Minola wrote: What is the recommended order of building gcc, gmp, mpfr? Any ordering is probably fine. I notice that now gcc depends on gmp and mpfr to build. Yes. What is the recommended order of building gcc, gmp, mpfr? I can think of two options: Option A. Use the bootstrap compiler to first build gmp and mpfr, then build gcc. Option A.
Re: Signed overflow patches OK for 4.2?
On 05 Mar 2007 12:24:18 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote: Andrew Pinski [EMAIL PROTECTED] writes: If Mark agrees with you, then I'm unfortunately going to have to lobby to disable VRP by default in 4.2. Then it should also be disabled by default also in 4.1.3 and should have been disabled in 4.1.2 which was only released last month so there is no reason why it has to be disabled in 4.2.0 if everyone is using 4.1 anyways. As you know, Paul Eggert has proposed having autoconf automatically pass -fwrapv when compiling with gcc. I think that would be extremely unfortunate. Disabling VRP by default will be the lesser of two evils. but again 4.1.x still has VRP enabled so did you not agree for 4.1.2 to have VRP disabled at the begining of the year after you found out about what Paul was going to do with autoconf? I still don't see why 4.2.0 has to be different from 4.1.x in this respect. Also isn't there still some regressions associated still with this change? http://gcc.gnu.org/ml/gcc/2007-03/msg00120.html for the reference of the regressions. That one is already fixed, I believe. They were referencing wrong code generation and the patch I thought you did was only to fix the internal error. Also I still say this changing of VRP and fold is too destructive to put it on a release branch just after two days, I would wait at least a month for these kind of patches really. -- Pinski
Re: Signed overflow patches OK for 4.2?
Then it should also be disabled by default also in 4.1.3 and should have been disabled in 4.1.2 which was only released last month so there is no reason why it has to be disabled in 4.2.0 if everyone is using 4.1 anyways. VRP has become more aggressive in 4.2.x than in 4.1.x though. -- Eric Botcazou
Re: Signed overflow patches OK for 4.2?
Eric Botcazou wrote on 03/05/07 15:59: Then it should also be disabled by default also in 4.1.3 and should have been disabled in 4.1.2 which was only released last month so there is no reason why it has to be disabled in 4.2.0 if everyone is using 4.1 anyways. VRP has become more aggressive in 4.2.x than in 4.1.x though. Agreed. I don't see the need to backport this functionality to 4.1. It has been out for quite some time now, used in various distros and we have not been flooded with requests from users. While this represents a new feature in 4.2, I don't think it's too risky. Whatever failures are triggered should be easy to identify and fix. I personally don't like this feature very much as it may represent a slippery slope into forcing us to warn in every optimization that exploits undefined aspects of the standard. But user pressure obviously exists, so *shrug*.
gcc-4.1-20070305 is now available
Snapshot gcc-4.1-20070305 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070305/ 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 122577 You'll find: gcc-4.1-20070305.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070305.tar.bz2 C front end and core compiler gcc-ada-4.1-20070305.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070305.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070305.tar.bz2 C++ front end and runtime gcc-java-4.1-20070305.tar.bz2 Java front end and runtime gcc-objc-4.1-20070305.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070305.tar.bz2The GCC testsuite Diffs from 4.1-20070226 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: Signed overflow patches OK for 4.2?
Diego Novillo [EMAIL PROTECTED] writes: Eric Botcazou wrote on 03/05/07 15:59: Then it should also be disabled by default also in 4.1.3 and should have been disabled in 4.1.2 which was only released last month so there is no reason why it has to be disabled in 4.2.0 if everyone is using 4.1 anyways. VRP has become more aggressive in 4.2.x than in 4.1.x though. Agreed. I don't see the need to backport this functionality to 4.1. It has been out for quite some time now, used in various distros and we have not been flooded with requests from users. While this represents a new feature in 4.2, I don't think it's too risky. Whatever failures are triggered should be easy to identify and fix. I gather you are saying here that it is OK with you to backport -fstrict-overflow/-Wstrict-overflow to 4.2. I personally don't like this feature very much as it may represent a slippery slope into forcing us to warn in every optimization that exploits undefined aspects of the standard. But user pressure obviously exists, so *shrug*. Yes, the overflow case, and the strict aliasing case, is clearly a problem with real existing code, and is a problem for real users. Ian
Re: gcc and gmp/mpfr - order of build
On Monday 05 March 2007 22:00, Andreas Schwab wrote: Kate Minola [EMAIL PROTECTED] writes: Option A. Use the bootstrap compiler to first build gmp and mpfr, then build gcc. Option B. Build gcc without gmp and mpfr. Then use it to build gmp and mpfr. Now rebuild gcc using gmp and mpfr. Are there other options? Option C: unpack gmp and mpfr sources in the gcc toplevel and bootstrap all of gcc, gmp, mpfr together. Option D: Use a cross compiler. Paul
Re: Signed overflow patches OK for 4.2?
Ian Lance Taylor wrote on 03/05/07 18:23: I gather you are saying here that it is OK with you to backport -fstrict-overflow/-Wstrict-overflow to 4.2. Yes.
Re: Signed overflow patches OK for 4.2?
Diego Novillo wrote: Ian Lance Taylor wrote on 03/05/07 18:23: I gather you are saying here that it is OK with you to backport -fstrict-overflow/-Wstrict-overflow to 4.2. It is OK with with me to backport the changes, even though this is clearly late in the cycle. None of the choices are particularly pretty. Ian, please do the backport and check in the changes as soon as you can. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Massive SPEC failures on trunk
Ian Lance Taylor wrote: Vladimir Sysoev [EMAIL PROTECTED] writes: There is minimal reproducer for cpu2006/h264ref is attached I just committed a patch for PR 31034 which may fix this. Ian Hi Ian, patch for PR31034 fixes cpu2006/464.h264ref ICE only. Others are still failing - the root cause seems to be more general. cpu2006: 403.gcc 416.gamess 434.zeusmp 465.tonto cpu2000: 178.galgel 186.crafty - Grigory
[Bug tree-optimization/29925] Wrong code with -ftree-vectorize
--- Comment #9 from patchapp at dberlin dot org 2007-03-05 08:01 --- Subject: Bug number PR tree-optimization/29925 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00254.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29925
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #36 from michael dot klein at fazi dot de 2007-03-05 08:43 --- Subject: Re: Discarded Linkonce sections in .rodata One possible workaround is to reorder the objects during link, so that those with .gnu.linkonce.r.* come first. If this a compiler or a linker bug? (I'd blame the linker ;)) It is most likely a Solaris specific compiler bug. Erm, this bug was originally reported for i686-pc-linux-gnu, and none of the 33 previous comments refers to Solaris. Forgot to mention that the bug exhibits only with GNU ld, Solaris ld links fine without object reordering or other tricks. /Michael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug tree-optimization/31040] New: unroll/peel loops not aggressive enough
Looking at the asm for the program below, there plenty of loops left after compiling with gfortran -S -march=native -O3 -funroll-loops -funroll-all-loops -fpeel-loops test.f90 or any combination of these options. A full unrolling (and in that case a return of the value 3) would be possible and much faster. cat test.f90 INTEGER FUNCTION lxy() lxy=0 DO lxa=0,1 DO lxb=0,0 DO lya=0,1-lxa DO lyb=0,0-lxb lxy=lxy+1 ENDDO ENDDO ENDDO ENDDO END FUNCTION write(6,*) lxy() END -- Summary: unroll/peel loops not aggressive enough Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31040
[Bug inline-asm/30505] [4.2/4.3 regression] asm operand has impossible constraints.
--- Comment #5 from bonzini at gnu dot org 2007-03-05 09:17 --- On 4.3, it is still there at -O1 -- bonzini at gnu dot org changed: What|Removed |Added Known to fail||4.2.0 4.3.0 Known to work||4.1.2 Summary|[4.2 regression] asm operand|[4.2/4.3 regression] asm |has impossible constraints. |operand has impossible ||constraints. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug inline-asm/30505] [4.2/4.3 regression] asm operand has impossible constraints.
-- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-05 09:18:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug fortran/29441] [4.1/4.2 only] non-constant parameter (constant) accepted
--- Comment #10 from burnus at gcc dot gnu dot org 2007-03-05 09:29 --- (In reply to comment #9) Tobias Schlüter wrote: Fixed on all release branches. This sounds as if should have been marked as FIXED. Did so. Please reopen if it should not have been closed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
[Bug tree-optimization/24309] [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #15 from irar at il dot ibm dot com 2007-03-05 09:30 --- I tried the reduced testcase on powerpc with -ftree-loop-linear and both -O2 and -O3 on 4.1, 4.2 and 4.3, and it works fine. 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=24309
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #19 from tbm at cyrius dot com 2007-03-05 10:13 --- I will try to get back to this bug this week. I was fighting some other fights last week, i apologize. Danny, any update on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug tree-optimization/31040] unroll/peel loops not aggressive enough
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-05 10:18 --- We don't unroll non-innermost loops at the moment. I don't know if sccp can be taught to handle this case (and if it's worth it). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, rakdver at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-03-05 10:18:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31040
[Bug tree-optimization/21463] min/max and references
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
[Bug c/31041] New: ice for legal code with -O2 -ftree-vectorize
I just tried to compile a Suse Linux package
with the GNU C++ compiler version 4.3 snapshot 20070302.
The compiler said
utrie.c: In function 'utrie_open_3_4':
utrie.c:51: error: invalid operand to binary operator
(int) j_93;
utrie.c:51: error: incorrect sharing of tree nodes
vect_cst_.1224_132 = {(int) j_93, stmp_var_.1221_129, stmp_var_.1222_130,
stmp_var_.1223_131};
(int) j_93;
utrie.c:51: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Preprocessed source code attached. Flags -O2 -ftree-vectorize required.
--
Summary: ice for legal code with -O2 -ftree-vectorize
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug c/31041] ice for legal code with -O2 -ftree-vectorize
--- Comment #1 from dcb314 at hotmail dot com 2007-03-05 10:50 --- Created an attachment (id=13144) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13144action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug tree-optimization/26420] -ftree-vectorizer-verbose=1 prints unvectorized loops information
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-05 10:57 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26420
[Bug tree-optimization/26420] -ftree-vectorizer-verbose=1 prints unvectorized loops information
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-05 10:57 --- Subject: Bug 26420 Author: rguenth Date: Mon Mar 5 10:57:09 2007 New Revision: 122544 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122544 Log: 2007-03-05 Richard Guenther [EMAIL PROTECTED] Dorit Nuzman [EMAIL PROTECTED] PR tree-optimization/26420 * tree-vectorizer.c (vectorize_loops): Bail out early if there are no loops in the function. Only print the number of vectorized loops if it is greater than zero or we are supposed to print information about unvectorized loops. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vectorizer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26420
[Bug target/30961] [4.2 regression] redundant reg/mem stores/moves
--- Comment #1 from pluto at agmk dot net 2007-03-05 11:11 --- 3.4.6 generates a nice code: _Z7convertj: movl%edi, -4(%rsp) movss -4(%rsp), %xmm0 ret _Z4loadPv: movzwl (%rdi), %eax ret -- pluto at agmk dot net changed: What|Removed |Added Known to fail||4.2.0 Known to work||3.4.6 Summary|redundant reg/mem |[4.2 regression] redundant |stores/moves|reg/mem stores/moves http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug tree-optimization/31040] unroll/peel loops not aggressive enough
--- Comment #2 from jv244 at cam dot ac dot uk 2007-03-05 11:47 --- (In reply to comment #1) We don't unroll non-innermost loops at the moment. I don't know if sccp can be taught to handle this case (and if it's worth it). such small loops are quite typical for some quantum chemistry integral routines. I'm just experimenting rewriting the kernel mentioned in PR 31021. If I do this unrolling by hand I get quite a speedup on the full kernel: hand unrolled: # best time5.260329 loops: # best time6.616413 which is quite impressive because these loops take at most 30% of the kernel total time: The actual code in question is: coef(:,:)=0.0_wp lxy=0 ; lx=0 DO lxa=0,1 DO lxb=0,1 lx = lx + 1 g1=0.0_wp g2=0.0_wp g1k=0.0_wp g2k=0.0_wp DO lya=0,1-lxa DO lyb=0,1-lxb lxy=lxy+1 g1=g1+pyx(1,lxy)*dpy(lyb,lya,jg) g2=g2+pyx(1,lxy)*dpy(lyb,lya,jg2) g1k=g1k+pyx(2,lxy)*dpy(lyb,lya,jg) g2k=g2k+pyx(2,lxy)*dpy(lyb,lya,jg2) ENDDO ENDDO DO icoef=1,3 coef(icoef,1)=coef(icoef,1)+alpha(icoef,lx)*g1 coef(icoef,2)=coef(icoef,2)+alpha(icoef,lx)*g2 coef(icoef,3)=coef(icoef,3)+alpha(icoef,lx)*g1k coef(icoef,4)=coef(icoef,4)+alpha(icoef,lx)*g2k ENDDO ENDDO ENDDO and the hand-unrolling just explicitly expands all loops to the loop free version of exactly the same statements: coef(:,:)=0.0_wp g1=0.0_wp g2=0.0_wp g1k=0.0_wp g2k=0.0_wp g1=g1+pyx(1,1)*dpy(0,0,jg) g2=g2+pyx(1,1)*dpy(0,0,jg2) g1k=g1k+pyx(2,1)*dpy(0,0,jg) g2k=g2k+pyx(2,1)*dpy(0,0,jg2) g1=g1+pyx(1,2)*dpy(1,0,jg) g2=g2+pyx(1,2)*dpy(1,0,jg2) g1k=g1k+pyx(2,2)*dpy(1,0,jg) g2k=g2k+pyx(2,2)*dpy(1,0,jg2) g1=g1+pyx(1,3)*dpy(0,1,jg) g2=g2+pyx(1,3)*dpy(0,1,jg2) g1k=g1k+pyx(2,3)*dpy(0,1,jg) g2k=g2k+pyx(2,3)*dpy(0,1,jg2) g1=g1+pyx(1,4)*dpy(1,1,jg) g2=g2+pyx(1,4)*dpy(1,1,jg2) g1k=g1k+pyx(2,4)*dpy(1,1,jg) g2k=g2k+pyx(2,4)*dpy(1,1,jg2) coef(01,01)=coef(01,01)+alpha(1,1)*g1 coef(01,02)=coef(01,02)+alpha(1,1)*g2 coef(01,03)=coef(01,03)+alpha(1,1)*g1k coef(01,04)=coef(01,04)+alpha(1,1)*g2k coef(02,01)=coef(02,01)+alpha(2,1)*g1 coef(02,02)=coef(02,02)+alpha(2,1)*g2 coef(02,03)=coef(02,03)+alpha(2,1)*g1k coef(02,04)=coef(02,04)+alpha(2,1)*g2k coef(03,01)=coef(03,01)+alpha(3,1)*g1 coef(03,02)=coef(03,02)+alpha(3,1)*g2 coef(03,03)=coef(03,03)+alpha(3,1)*g1k coef(03,04)=coef(03,04)+alpha(3,1)*g2k g1=0.0_wp g2=0.0_wp g1k=0.0_wp g2k=0.0_wp g1=g1+pyx(1,5)*dpy(0,0,jg) g2=g2+pyx(1,5)*dpy(0,0,jg2) g1k=g1k+pyx(2,5)*dpy(0,0,jg) g2k=g2k+pyx(2,5)*dpy(0,0,jg2) g1=g1+pyx(1,6)*dpy(0,1,jg) g2=g2+pyx(1,6)*dpy(0,1,jg2) g1k=g1k+pyx(2,6)*dpy(0,1,jg) g2k=g2k+pyx(2,6)*dpy(0,1,jg2) coef(01,01)=coef(01,01)+alpha(1,2)*g1 coef(01,02)=coef(01,02)+alpha(1,2)*g2 coef(01,03)=coef(01,03)+alpha(1,2)*g1k coef(01,04)=coef(01,04)+alpha(1,2)*g2k coef(02,01)=coef(02,01)+alpha(2,2)*g1 coef(02,02)=coef(02,02)+alpha(2,2)*g2 coef(02,03)=coef(02,03)+alpha(2,2)*g1k coef(02,04)=coef(02,04)+alpha(2,2)*g2k coef(03,01)=coef(03,01)+alpha(3,2)*g1 coef(03,02)=coef(03,02)+alpha(3,2)*g2 coef(03,03)=coef(03,03)+alpha(3,2)*g1k coef(03,04)=coef(03,04)+alpha(3,2)*g2k g1=0.0_wp g2=0.0_wp g1k=0.0_wp g2k=0.0_wp g1=g1+pyx(1,7)*dpy(0,0,jg) g2=g2+pyx(1,7)*dpy(0,0,jg2) g1k=g1k+pyx(2,7)*dpy(0,0,jg) g2k=g2k+pyx(2,7)*dpy(0,0,jg2) g1=g1+pyx(1,8)*dpy(1,0,jg) g2=g2+pyx(1,8)*dpy(1,0,jg2) g1k=g1k+pyx(2,8)*dpy(1,0,jg) g2k=g2k+pyx(2,8)*dpy(1,0,jg2) coef(01,01)=coef(01,01)+alpha(1,3)*g1
[Bug tree-optimization/31040] unroll/peel loops not aggressive enough
--- Comment #3 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2007-03-05 11:49 --- Subject: Re: unroll/peel loops not aggressive enough We don't unroll non-innermost loops at the moment. I don't know if sccp can be taught to handle this case (and if it's worth it). It is fairly easy to make gcc completely unroll non-innermost loops, I am working on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31040
[Bug tree-optimization/31040] unroll/peel loops not aggressive enough
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-05 12:22 --- Note that in addition to unrolling the outermost loop you can experiment with adjusting the --param max-completely-peeled-insns param. Also I wonder if DO lxb=0,0 is really common (if so, the frontend might want to lower this differently). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31040
[Bug c++/31042] New: Instantiation with const pointer to member
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mno-string -mstrict-align -O3
-fno-exceptions -fno-rtti -fno-builtin-printf
-Isome include paths
-Dsome #define's
X.CPP -oX.O
// file X.CPP
class X;
template typename T_
int X::** f1 () { return static_castT_*(0); }
int X::** f2 () { return f1int X::* const(); }
The compiler gives the following error messages:
X.CPP: In function `int X::** f1() [with T_ = int X::*]':
X.CPP:6: instantiated from here
X.CPP:4: error: invalid conversion from `int X::**' to `int X::**'
BTW, function f1 is instantiated with 'T_ = int X::* const'
and not with 'T_ = int X::*'.
Kind regards
W. Roehrl
--
Summary: Instantiation with const pointer to member
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at gi-de dot com
GCC build triplet: sparc-sun-solaris2.5.1
GCC host triplet: i386-pc-mingw32
GCC target triplet: powerpc-wrs-vxworks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31042
[Bug fortran/30968] [4.1, 4.2 only] Bogus warning with continued lines of concatenated strings
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-05 12:58 --- Subject: Bug 30968 Author: burnus Date: Mon Mar 5 12:58:14 2007 New Revision: 122547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122547 Log: 2007-03-05 Tobias Burnus [EMAIL PROTECTED] PR fortran/30968 * primary.c (next_string_char): Correct reading a character after the delimiter. (match_string_constant): Print warning message only once. 2007-03-05 Tobias Burnus [EMAIL PROTECTED] PR fortran/30968 * gfortran.dg/continuation_7.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/continuation_7.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/primary.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30968
[Bug fortran/30968] [4.1 only] Bogus warning with continued lines of concatenated strings
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-05 12:59 --- Fixed in 4.2 (and 4.3). I don't think it is worth to porting to 4.1. - close bug. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.1, 4.2 only] Bogus |[4.1 only] Bogus warning |warning with continued lines|with continued lines of |of concatenated strings |concatenated strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30968
[Bug c/31041] ice for legal code with -O2 -ftree-vectorize
--- Comment #2 from tbm at cyrius dot com 2007-03-05 13:09 ---
Reduced testcase:
typedef int int32_t;
struct UNewTrie
{
int32_t index[(0x11 1)];
};
typedef struct UNewTrie UNewTrie;
utrie_open_3_4 ()
{
UNewTrie *trie;
int32_t i, j;
{
i = 0;
do
{
trie-index[i++] = j;
j += 1;
}
while (i 5);
}
}
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug c/31041] [4.3 Regression] ice (verify_stmts failed: invalid operand to binary operator) with -O2 -ftree-vectorize
--- Comment #3 from tbm at gcc dot gnu dot org 2007-03-05 13:11 --- confirmed with GCC 4.3.0 20070303. 4.2.0 works. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-03-05 13:11:16 date|| Summary|ice for legal code with -O2 |[4.3 Regression] ice |-ftree-vectorize|(verify_stmts failed: ||invalid operand to binary ||operator) with -O2 -ftree- ||vectorize Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug fortran/29441] [4.1/4.2 only] non-constant parameter (constant) accepted
--- Comment #11 from tobi at gcc dot gnu dot org 2007-03-05 13:14 --- Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
[Bug middle-end/30364] [4.1/4.2 Regression] Wrong variable ranges due to constant folding
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-03-05 13:15 --- Subject: Bug 30364 Author: rguenth Date: Mon Mar 5 13:15:25 2007 New Revision: 122548 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122548 Log: 2007-03-05 Richard Guenther [EMAIL PROTECTED] Backport from mainline: 2007-02-28 Richard Guenther [EMAIL PROTECTED] PR middle-end/30364 * fold-const.c (fold_binary): Do not associate expressions with more than one variable for integer types that do not wrap. * gcc.dg/torture/pr30364-1.c: New testcase. * gcc.dg/torture/pr30364-2.c: Likewise. * gcc.dg/torture/pr30364-3.c: Likewise. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr30364-1.c - copied unchanged from r122414, trunk/gcc/testsuite/gcc.dg/torture/pr30364-1.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr30364-2.c - copied unchanged from r122414, trunk/gcc/testsuite/gcc.dg/torture/pr30364-2.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr30364-3.c - copied unchanged from r122414, trunk/gcc/testsuite/gcc.dg/torture/pr30364-3.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/fold-const.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug middle-end/30364] [4.1 Regression] Wrong variable ranges due to constant folding
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-05 13:16 --- And the 4.2 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 Summary|[4.1/4.2 Regression] Wrong |[4.1 Regression] Wrong |variable ranges due to |variable ranges due to |constant folding|constant folding http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug c++/31042] Instantiation with const pointer to member
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-05 13:27 ---
Your code is invalid. Valid is
class X;
template typename T_
int X::* const * f1 () { return static_castT_*(0); }
int X::* const * f2 () { return f1int X::* const(); }
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31042
[Bug libstdc++/30675] [4.2/4.3 Regression] libstdc++ testsuite hardcodes ar and ranlib
--- Comment #2 from jsm28 at gcc dot gnu dot org 2007-03-05 13:41 --- Working on a fix. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-05 13:41:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30675
[Bug c/31041] [4.3 Regression] verify_stmts failed: invalid operand to binary operator with -O2 -ftree-vectorize
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-05 13:46 ---
Two times invalid gimple:
L20:;
stmp_var_.41_63 = (int) j_34 + 1;
stmp_var_.42_64 = stmp_var_.41_63 + 1;
stmp_var_.43_65 = stmp_var_.42_64 + 1;
vect_cst_.44_66 = {(int) j_34, stmp_var_.41_63, stmp_var_.42_64,
stmp_var_.43_65};
in tree-vect-transform.c:get_initial_def_for_induction we fail to gimplify
the init_expr.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dorit at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug c++/31042] Misleading error message with instantiation with const pointer to member
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-05 14:10 --- Reopen ... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Keywords||diagnostic Resolution|INVALID | Summary|Instantiation with const|Misleading error message |pointer to member |with instantiation with ||const pointer to member http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31042
[Bug c++/31042] Misleading error message with instantiation with const pointer to member
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-05 14:10 --- ... to mark as fixed in 3.4.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31042
[Bug libstdc++/31031] ostream ambiguous operator
--- Comment #5 from paolo at gcc dot gnu dot org 2007-03-05 14:12 --- Subject: Bug 31031 Author: paolo Date: Mon Mar 5 14:12:29 2007 New Revision: 122549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122549 Log: 2007-03-05 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31031 * include/bits/istream.tcc: Inhibit implicit instantiation of the _M_insert helpers. * include/bits/ostream.tcc: Likewise for _M_extract. * testsuite/27_io/basic_ostream/inserters_arithmetic/char/ 31031.cc: New. * testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/ 31031.cc: Likewise. Added: branches/gcc-4_2-branch/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/31031.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/31031.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/bits/istream.tcc branches/gcc-4_2-branch/libstdc++-v3/include/bits/ostream.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
[Bug libstdc++/31031] ostream ambiguous operator
--- Comment #6 from pcarlini at suse dot de 2007-03-05 14:13 --- Fixed for 4.2.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #37 from hjl at lucon dot org 2007-03-05 14:19 --- (In reply to comment #36) Subject: Re: Discarded Linkonce sections in .rodata One possible workaround is to reorder the objects during link, so that those with .gnu.linkonce.r.* come first. If this a compiler or a linker bug? (I'd blame the linker ;)) It is most likely a Solaris specific compiler bug. Erm, this bug was originally reported for i686-pc-linux-gnu, and none of the 33 previous comments refers to Solaris. Forgot to mention that the bug exhibits only with GNU ld, Solaris ld links fine without object reordering or other tricks. /Michael Can I reproduce it on Linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug other/31043] New: duplicated data in .rodata / .rodata.cst sections.
$ cat pi.cpp
#include cmath
extern double const pi = M_PI;
extern double foo() { return pi; }
.section.rodata.cst8,aM,@progbits,8
.align 8
.LC0: .long 1413754136
.long 1074340347
.globl pi
.section.rodata
.align 8
pi: .long 1413754136
.long 1074340347
_Z3foov:
pushl %ebp
movl%esp, %ebp
fldl.LC0
popl%ebp
ret
--
Summary: duplicated data in .rodata / .rodata.cst sections.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31043
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #38 from hidden_peak at mail dot ru 2007-03-05 14:53 --- (In reply to comment #37) Can I reproduce it on Linux? May be comment #21 help you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #39 from hjl at lucon dot org 2007-03-05 15:25 --- (In reply to comment #38) (In reply to comment #37) Can I reproduce it on Linux? May be comment #21 help you? That is an old compiler bug which has been fixed since then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #40 from michael dot klein at fazi dot de 2007-03-05 16:20 --- Subject: Re: Discarded Linkonce sections in .rodata On Mon, 5 Mar 2007, hjl at lucon dot org wrote: Can I reproduce it on Linux? Using gcc 4.1.1 with binutils-070227 I can also reproduce it on Linux, binutils 2.15 from Debian Sarge do not exhibit this problem. As this is a closes source application I can't upload the source code. Would the generated asm code be of any help? The smallest testcase I have is currently ~500k lines asm, split accross two files. /Michael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts
--- Comment #11 from patchapp at dberlin dot org 2007-03-05 16:30 --- Subject: Bug number PR19637 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00295.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #41 from hjl at lucon dot org 2007-03-05 16:38 --- (In reply to comment #40) Subject: Re: Discarded Linkonce sections in .rodata On Mon, 5 Mar 2007, hjl at lucon dot org wrote: Can I reproduce it on Linux? Using gcc 4.1.1 with binutils-070227 I can also reproduce it on Linux, binutils 2.15 from Debian Sarge do not exhibit this problem. As this is a closes source application I can't upload the source code. Would the generated asm code be of any help? The smallest testcase I have is currently ~500k lines asm, split accross two files. /Michael Assembly files will help. Please make them available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/31044] New: Compilation fails on definition of a static template class member
The following sample fails to compile:
templateclass _Type, int _Val
class Container
{
static const _Type Value = _Val;
};
templateclass _Type
class Test
{
static const uint Value = 2;
static const Container_Type, Value m_Test;
};
templateclass _Type
const Container_Type, Test_Type::Value Test_Type::m_Test;
The compiler says:
Test.cpp:29: error: conflicting declaration 'const Container_Type,
Test_Type::Value Test_Type::m_Test'
Test.cpp:24: error: 'Test_Type::m_Test' has a previous declaration as 'const
Container_Type, 2 Test_Type::m_Test'
Test.cpp:29: error: declaration of 'const Container_Type, 2
Test_Type::m_Test' outside of class is not definition
The problem is the Test_Type::Value in the definition - if i replace it with
2 it is working. I tried the sample above with Visual Studio 2005 and Comeau
4.3.3 (Online) and both compile without any error.
--
Summary: Compilation fails on definition of a static template
class member
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: indiana dot jones at gmx dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31044
[Bug tree-optimization/23777] Does not remove all references to var
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-05 16:55 --- Subject: Bug 23777 Author: rguenth Date: Mon Mar 5 16:55:23 2007 New Revision: 122558 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122558 Log: 2007-03-05 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/23777 * gcc.dg/tree-ssa/pr23777.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23777.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23777
[Bug tree-optimization/23777] Does not remove all references to var
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-03-05 16:56 --- This is fixed now on the mainline. Supposedly by Author: dnovillo Date: Fri Mar 2 19:20:14 2007 New Revision: 122484 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122484 Log: * tree-ssa-structalias.c (could_have_pointers): Tidy. (get_constraint_for): Likewise. (do_structure_copy): Likewise. (find_func_aliases): Fix references to MODIFY_EXPR. (intra_create_variable_infos): Tidy. * tree-ssa-operands.c (add_virtual_operand): Add argument IS_CALL_SITE. When adding members of alias sets, if IS_CALL_SITE is true and the symbol is not call-clobbered, skip it. Adjust all callers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23777
[Bug c++/31045] New: gcc4.1. has problems with pointers
Hi ,
The following simple testcase does not compile using GCC4.1.1
#include cstdlib
int main() {
char **const p = (char **)std::malloc(sizeof*p);
return !p;
}
--
Summary: gcc4.1. has problems with pointers
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31045
[Bug c++/31045] gcc4.1. has problems with pointers
--- Comment #1 from satyaakam at yahoo dot co dot in 2007-03-05 16:58 --- Created an attachment (id=13145) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13145action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31045
[Bug tree-optimization/14052] Combiner weakness
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-05 17:03 --- It was fixed by the fix for PR15911. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||15911 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14052
[Bug tree-optimization/14052] Combiner weakness
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-05 17:03 --- Subject: Bug 14052 Author: rguenth Date: Mon Mar 5 17:03:14 2007 New Revision: 122559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122559 Log: 2007-03-05 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/14052 * gcc.dg/tree-ssa/vrp33.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp33.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14052
[Bug fortran/30929] -pedantic-error produced only warnings and no errors
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-05 17:05 --- I am not sure if gfortran diagnostics are different, but... are you sure that particular warning is a pedantic warning and not simply an unconditional warning? AFAIK, pedantic-errors will turn only pedantic warnings into errors, other warnings will still be warnings unless -Werror. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug middle-end/26198] Unfolded comparison after cfg_cleanup
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-05 17:07 --- Depends on (and is partly fixed by) PR30965. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30965 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26198
[Bug middle-end/31046] New: some i386-pf-sse-1.c started to fail on 3/3/07
Before bootstrapping on 3/3/07, the i386-pf-sse-1.c test passed for me. Now, I get the following: PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=c3-2 (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=c3-2 scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=c3-2 scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=c3-2 scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c
[Bug c++/31047] New: GCC 4.1.1 has template bug
We've uncovered a GCC 4.1.1 template bug when we compile using GCC4.1.1,This
simple testcase shows the issue.
#include iostream
template typename T void foo( T var) { std::cout T std::endl; }
template typename T void doit( T var ) { foo(var); }
void foo(const int var) { std::cout INT std::endl; }
int main() {
doit(3); // prints T
return 0;
}
/// temp.cpp
Run the example with gcc 3.2.3
rm -f a.out
$/v3.2.3/bin/g++ -Wall temp.cpp
LD_LIBRARY_PATH=/v3.2.3/lib:$LD_LIBRARY_PATH; a.out
[~/test]$ gcc3
INT
Now run with GCC 4.1.1
[~/test]$ more gcc4
rm -f a.out
$/v4.1.1/bin/g++ -Wall temp.cpp
LD_LIBRARY_PATH=/v4.1.1/lib:$LD_LIBRARY_PATH; a.out
[EMAIL PROTECTED] ~/test]$ gcc4
T
We can fix this particular example by moving
void foo(const int var) { std::cout INT std::endl; }
to the top of the function. However, this won't work in more complex cases.
--
Summary: GCC 4.1.1 has template bug
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31047
[Bug c++/31047] GCC 4.1.1 has template bug
--- Comment #1 from satyaakam at yahoo dot co dot in 2007-03-05 17:11 --- Created an attachment (id=13146) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13146action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31047
[Bug c++/31048] New: G++ 4.1.1 forgets to allocate memory (skips part of user code)
Hi,
We have problems using gcc 4.1.1. we are trying to compile a code in file
case17.cpp (see attached in testcase area). The problem is that compiler
forgets to call malloc and forgets to check the return value (see case17.s) and
it also forgets to initialize pointer called color. That is we do not see the
following lines reflected in the assembly output:
char **const colorTable = (char **)std::malloc(ncolors*sizeof*colorTable),
**volatile color=colorTable;
if(colorTable); else { return *oldct = 0; }
--
Summary: G++ 4.1.1 forgets to allocate memory (skips part of user
code)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31048
