Re: Problem compiling GCC source code in AIX
Thanks a lot David , You saved my time. I have not installed bash earlier. When i installed the bash and sat the environment varialble. % CONFIG_SHELL=/usr/local/bin % export CONFIG_SHELL Then everything is OK. :) AIX shell is not supported compiling GCC source code. Rgs, Kithsiri On 7/24/06, David Edelsohn [EMAIL PROTECTED] wrote: Kithsiri Lekamge writes: Kithsiri I am in great difficult compiling GCC source code in AIX box. Kithsiri I installed the binary of GCC 3.3.2 and using this compiler I started Kithsiri to compile the GCC 3.4.6 source codes. Kithsiri After 5 hrs of compiling I received the following error. Kithsiri 46286 Segmentation fault: Kithsiri Configure-target-libstdc++-v3 First, you probably should build and install a more recent version of GCC than 3.4.6. Second, please make sure that you are following the AIX machine-specific directions for building GCC, such as using GNU Make and using Bash as the SHELL and CONFIG_SHELL (unless you are on a very old, slow machine, it should not take 5 hours unless you used the wrong shell.) Third, the detailed output from the libstdc++-v3 configuration process is in a file named config.log in the libstdc++-v3 build directory. David
Re: How to extract internal tree structure information?
Hi, Steven Bosscher wrote: On 7/25/06, Christian Wagner [EMAIL PROTECTED] wrote: Hi, I'm trying to extract information from C++ code during the compilation process. I need information about declarations, statements, functions (including parameters and symbol name), source line and source file. Perhaps you can tell why? Yes, I need this information to create a description of my source code as a graph, like a call graph, but with more information on the nodes. Every code line should be one node in the graph. If I have a function: I want to use the symbol name to link the function to another graph which describes it. And I need to identify the source file and the line to find the comments in the original code file. Could somebody please point out good places for me to add such a function? Could you please name tree structures which contain the full information? Look in gcc/cp/semantics.c, there's a function (I don't recall which) that finalizes the tree in the front end and hands it to the middle-end for gimplification (probably through a call to cgraph_finalize or something like that). Thanks for the hint. It will take me some time to look into that. Christian
Re: Documentation for loop infrastructure
On Mon, Jul 24, 2006 at 08:57:29PM +0200, Zdenek Dvorak wrote: + @node Loop Representation + @chapter Analysis and Representation of Loops + + GCC provides extensive infrastructure for work with natural loops, + i.e., strongly connected components of CFG with only one entry block. + This chapter describes representation of loops in GCC, both on trees + and in RTL, as well as the interfaces to loop-related analyses + (induction variable analysis and number of iterations analysis). s/for work with/for working with/ ? s/on trees/in trees/ s/analyses/analysis/ -- Rask Ingemann Lambertsen
Re: [boehms-gc] Performance results
2006/7/25, Basile STARYNKEVITCH [EMAIL PROTECTED]: A theoritical alternative might be to use a precise copying collector like Qish. http://starynkevitch.net/Basile/qishintro.html In practice, this would be impractical (even if the GTY marker could help) because it requires changing a lot of code. Precise copying collector is certainly a viable idea, there have already been some experiments with GCC, see http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01266.html . -- Laurynas
Patch for PR15832 and PR28071
Vladimir, I've run into problem with your patch for PR15832 on the testcase PR rtl-optimization/28071. Bug2.c compiled with -O3 -fno-tree-pre -fno-tree-fre it needs about 200MB extra memory for bitmaps because the bitmap stack_regs ends up very dense and it is copied indo all the pavins. (I have couple of patches in queue to bring whole compilation of testcase under 300MB so the 200MB is quite important fraction - more than whole liveness info together). I don't quite follow your reasoning in the mail explaining your patch - if the uninitialized and initialized variables are both allocated to the same stack register, after the postreload dataflow they end up looking exactly same as partially initialized variable that needs to be handled fluently by regstack anyway. After commenting out all the ifdef STAC_REGS code I still can compile the testcase mentioned in original PR. Perhaps you was just hitting bug in reg-stack concerning partially initialized vars that was later fixed independently or am I missing something? (also the dataflow branch contains neccesary patches to make reg-stack happy with the more precise liveness dataflow, but I don't think they are neccesary as we build our conservative dataflow on the hardregs anyway) Thanks, Honza
Re: [boehms-gc] Performance results
Laurynas Biveinis wrote: That's certainly possible, maybe even interesting, but I'm not going to try this :) Circular references could be handled by fallbacking to mark-and-sweep time from time. Or by just being careful. Even type correct full garbage collection does not guarantee freedom from memory leaks, as Java and Algol-68 programmers know well. You still have to be careful not to accidentally hold onto garbage!
Re: Patch for PR15832 and PR28071
Jan Hubicka wrote: Perhaps you was just hitting bug in reg-stack concerning partially initialized vars that was later fixed independently or am I missing something? I think your are right. That was added because of the bug in reg-stack. If removing the code for stack regs in global.c does not work, I could modify algorithm to keep pavin sparse. Just let me know.
Re: Documentation for loop infrastructure
Zdenek Dvorak wrote on 07/24/06 14:57:
this patch adds documentation for loop analysis and representation of
loops, as well as other loop-related analyses, and for functions to
manipulate loops. As I am not a native English speaker, there are
probably many language errors in the document, so I would appreciate
if someone could read it and fix them.
Awesome! Thanks for adding this documentation. I'm not terribly
familiar with texi, so I skipped over the markup stuff. Hopefully
Gerald or Joseph will chime in.
+ This chapter describes the representation of loops in GCC, and functions
+ that can be used to analyze them and construct and update this
representation.
to build, modify and analyze this representation.
+ Most of the interfaces and data structures are declared in
@file{cfgloop.h}.
+ At the moment, loop structures are analyzed and this information is
updated
+ only by the optimization passes that deal with loops, but some
efforts are
+ being made to make it available throughout most of the optimization
passes.
+
+ In general form, the natural loop has one entry block (header) and
possibly
^
In general, a natural loop
+ several back edges (latches) leading to the header from the inside
of the loop.
+ Loops with several latches may appear if several loops share a
single header,
+ or if there is a branching in the middle of the loop. The
representation of
+ loops in GCC however allows only loops with a single latch. During
the loop
loop
+ analysis, headers of such loops are split and forwarder blocks are
created in
+ order to disambiguate their structures. A heuristic based on profile
+ information is used to determine whether the latches correspond to
sub-loops or
+ to control flow in a single loop. This in particular means that the
analysis
This means
+ sometimes changes the CFG, and if you run it in the middle of an
optimization
+ pass, you must be able to deal with the new blocks.
+
+ Natural loops form a tree defined by the subset relation, i.e., sons
of a loop
+ are its immediate sub-loops.
Maybe something along the lines of 'Natural loops are organized in a
containment hierarchy such that all the loops immediately contained
inside loop L are its children in the hierarchy.'
This tree is represented by the @code{struct
+ loops} structure. The root of this tree is a fake loop that contains
all blocks
You should probably say that each loop structure contains all the
blocks that are contained in the loop. But, that much can be deduced
from context, so I guess it's fine.
+ in the function. Each of the loops is represented in a @code{struct
loop}
+ structure. Each loop is assigned an index (@code{num} field of the
+ @code{struct loop} structure), and the pointer to the loop is stored
in the
+ corresponding field of the @code{parray} field of the loops
structure. Index
+ of a sub-loop is always greater than the index of its super-loop.
The indices do
+ not have to be continuous, there may be empty (@code{NULL}) entries
in the
+ @code{parray} created by deleting loops. The index of a loop never
changes.
+ The first unused index is stored in the @code{num} field of the loops
+ structure.
+
+ Each basic block contains the reference to the innermost loop it
belongs to
+ (@code{loop_father}). For this reason, it is only possible to have one
+ @code{struct loops} structure initialized at the same time for each
CFG. It is
+ recommended to use the global variable @code{current_loops} to
contain the
+ @code{struct loops} structure, especially if the loop structures are
updated
+ throughout several passes. Many of the loop manipulation functions
assume that
+ dominance information is up-to-date.
+
+ The loops are analyzed through @code{loop_optimizer_init} function. The
+ argument of this function is an or of flags that specify what other
properties
^
??? Are you trying to say that the
flags should be OR'd together? How
about something like 'is a set of flags
represented in an integer bitmask'.
+ of the loop structures should be calculated/enforced and preserved
later:
+
+ @itemize
+ @item @code{LOOPS_HAVE_PREHEADERS}: Each loop has only one entry edge.
+ Additionally, the source block of this entry edge has only one
successor.
+ This creates a natural place where the code can be moved out of the
loop,
+ and ensures that the entry edge of the loop leads from its immediate
super-loop.
It's not clear from the text whether specifying these flags will
actually modify the CFG to comply
Re: Documentation for loop infrastructure
Bah, sorry about this. I sent the half-finished reply that I was meaning to continue later today. I'll send the other half in a little while.
Re: [cygwin/mingw32] DBX_REGISTER_NUMBER vs DWARF2_FRAME_REF_OUT
Date: Mon, 24 Jul 2006 11:00:55 +1200 From: Danny Smith [EMAIL PROTECTED] Any other ideas? What is likely GDB fallout? GDB by default uses the SVR4 register numbering for DWARF DWARF 2, and the old dbx register numbering scheme for other debugging formats (most notably stabs). Mixing the two is no problem for GDB since can tell which debugging format it is processing. But whatever format you chose, make sure the numbering scheme used for .eh_frame (exception handling) unwind info is the same as .debug_frame normal DWARF2) unwind info. The best thing to do is probably to define DWARF2_FRAME_REG_OUT to always use the SVR4 register map. Mark
New testsuite failures with -fprofile-use
Hi, since a couple of days we have the following new failures on mainline: FAIL: gcc.dg/tree-prof/inliner-1.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/inliner-1.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-1.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-1.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-2.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-2.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-3.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-3.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-4.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-4.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-5.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-5.c execution,-fprofile-use See for example: http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg01139.html The testresults of 2006-07-24 seem to be clean, though. Here's one of the failures: % gcc -O2 -fprofile-generate val-prof-1.c % a.out % gcc -O2 -fprofile-use val-prof-1.c val-prof-1.c: In function 'main': val-prof-1.c:17: internal compiler error: in set_bb_for_stmt, at tree-cfg.c:2775 Please submit a full bug report, [etc.] Is anybody looking into this? Regards, Volker
Re: [cygwin/mingw32] DBX_REGISTER_NUMBER vs DWARF2_FRAME_REF_OUT
Date: Thu, 27 Jul 2006 09:46:36 +1200 From: Danny Smith [EMAIL PROTECTED] From: Mark Kettenis [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 9:34 AM The best thing to do is probably to define DWARF2_FRAME_REG_OUT to always use the SVR4 register map. Thanks for that advice. I'm in process of testing with the simple one-line change: #define DBX_REGISTER_NUMBER(n) svr4_dbx_register_map[n] That'd be bad, since it will break debugging code compiled with -gstabs in a very confusing way. And it would be impossible to fix in GDB without screwing over people that are still using older versions of GCC. Mark
Re: New testsuite failures with -fprofile-use
Hi, Is anybody looking into this? Honza said he was going to look into this. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28480 -- Pinski
Strange floating point problems on SH4 with gcc 4.1.0
Hi, I have been porting mozilla firefox to the SH4 platform. However, I have
run into some horrible floating point problems.
details:
gcc 4.1.0
glibc 2.3.6
(built using crosstool)
firefox 1.5.0.4
linux kernel 2.6.11
Running on an STB7100 with SH4-202 processor core (yes it does have an FPU).
I have been trying to make a small test case to illustrate the problem.. but I
cannot seem to manage it. It seems to be a prerequisite that I must have the
massive mozilla XPCOM shared libraries loaded or something.
Anyway, I manged to get my test code down to:
int main()
{
// printf(HELLO\n);
int x = 20;
float k = (float) x;
NS_InitXPCOM2(nsnull, nsnull, nsnull);
printf(THERE\n);
}
I also have debug prints inside NS_InitXPCOM2.
Basically if I leave the HELLO printf commented out, I do not see the debug in
NS_InitXPCOM2(). Instead I get a floating point exception.
If I uncomment it I *do* see the debug (althought it later gets another FP
exception; this is the problem I'm really trying to solve).
If I comment out the call to NS_InitXPCOM2() it runs fine.
As far as I can make out it is NOT the NS_InitXPCOM2() itself which is failing
since it outputs my debug if I have the first printf uncommented.
If I add more trace elsewhere the problem sort of shifts about... it sounds
like some form of alignment problem to me.
Oh, I also tried creating my own shared library with an NS_InitXPCOM5() method
and calling that instead... that worked fine.
Can anyone advise a way I can try and work out what is going on to provide a
small example that _doesn't_ involve calling into mozilla XPCOM?
I can always provide the binaries and source if people want it.. but mozilla
is _huge_.
Oh, my test file was compiled with:
sh4-unknown-linux-gnu-gcc -o TestXPC.o -c -O0 \
-DMOZILLA_INTERNAL_API -DOSTYPE=\Linux\ -DOSARCH=\Linux\ \
-I../../../../dist/include/xpconnect \
-I../../../../dist/include/xpcom \
-I../../../../dist/include/js \
-I../../../../dist/include/nspr \
-fPIC \
/etv/branches/aminet130/scratch/amino-stb710x-mozilla/mozilla/js/src/xpconnect/tests/TestXPC.cpp
and linked with:
sh4-unknown-linux-gnu-gcc \
-o TestXPC \
TestXPC.o \
-L../../../../dist/bin -lxpcom -lxpcom_core \
-L../../../../dist/lib -lplds4 -lplc4 -lnspr4 \
-lpthread -ldl -ldl -lm -lsupc++
Re: Strange floating point problems on SH4 with gcc 4.1.0
On Jul 26, 2006, at 3:54 PM, Andrew de Quincey wrote: Hi, I have been porting mozilla firefox to the SH4 platform. However, I have run into some horrible floating point problems. This list isn't for what you think it is for. This list is for contributors to gcc to talk about the development _of_ gcc.
Re: Strange floating point problems on SH4 with gcc 4.1.0
On Thursday 27 July 2006 02:20, Mike Stump wrote: On Jul 26, 2006, at 3:54 PM, Andrew de Quincey wrote: Hi, I have been porting mozilla firefox to the SH4 platform. However, I have run into some horrible floating point problems. This list isn't for what you think it is for. This list is for contributors to gcc to talk about the development _of_ gcc. Oh sorry I wasn't entirely certain from the description general development discussions seemed likely. Would gcc-help be more suitable?
gcc-4.3 projects page?
Is it time to create a GCC_4.3_Projects page like http://gcc.gnu.org/wiki/GCC_4.2_Projects ? I imagine several projects are already in progress, but not yet mentioned on the wiki... - Dan
Re: gcc-4.3 projects page?
On Jul 26, 2006, at 7:27 PM, Dan Kegel wrote: Is it time to create a GCC_4.3_Projects page like http://gcc.gnu.org/wiki/GCC_4.2_Projects ? I imagine several projects are already in progress, but not yet mentioned on the wiki... I have mentioned one via my user page on wiki. But it is not a full written up project yet. -- Pinski
[Bug fortran/28335] [4.1 only] flush() / write() statement on closed units - error?
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-26 06:22 --- Hum... don't we want to backport that fix to 4.1? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at verizon dot net Known to fail||4.1.2 Known to work||4.2.0 Summary|flush() / write() statement |[4.1 only] flush() / write() |on closed units - error?|statement on closed units - ||error? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug middle-end/28476] msp430-gcc with -Wunreachable-code Segmentation fault
--- Comment #5 from stefano dot franzoni at marposs dot com 2006-07-26 07:13 --- Subject: Re: msp430-gcc with -Wunreachable-code Segmentation fault I think this was fixed in 3.3 and I think this is a dup of bug 11142 or even PR 10660 or PR 10580. I believe you are correct Can you try a 3.3 release? I could try it. I need some help to dowload the right sources and recompile them for msp430. As an alternative I can point out the bug in the msp430 forum (http://sourceforge.net/mailarchive/forum.php?forum_id=7539) waiting for a msp430 guru. What do you suggest? pinskia at gcc dot gnu dot org [EMAIL PROTECTED] To .gnu.org [EMAIL PROTECTED] cc 26/07/2006 02:40 Subject [Bug middle-end/28476] msp430-gcc Please respond to with -Wunreachable-code [EMAIL PROTECTED] Segmentation fault gnu.org --- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-26 00:40 --- I think this was fixed in 3.3 and I think this is a dup of bug 11142 or even PR 10660 or PR 10580. Can you try a 3.3 release? Also msp430 is not part of the FSF GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28476 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28476
[Bug c/28488] incorrect warning says signed and unsigned type in conditional expression
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-26 08:03 --- It says warning: signed and unsigned type in conditional expression and that is the case: unsigned int found_len = 0 ? a - b : foo; because a - b is signed and foo is unsigned. -- 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=28488
[Bug tree-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-26 08:05 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-26 08:05:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-26 08:06 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-26 08:06:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug libfortran/27895] problem with SPREAD and zero-sized arrays
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-07-26 08:34 --- A patch for the library functions CSHIFT, PACK and SPREAD has been submitted: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01103.html The only one that is still not working is thus RESHAPE; it's proving difficult to fix! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||07/msg01103.html Keywords|diagnostic | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27895
[Bug tree-optimization/26948] ICE: tree check: expected ssa_name, with -ftree-vectorize
--- Comment #4 from micis at gmx dot de 2006-07-26 09:04 --- The patch http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01043.html fixes that bug for the reduced source as well as for the original source. Many thanks! Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26948
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|tree-optimization |rtl-optimization Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #1 from pcarlini at suse dot de 2006-07-26 11:26 --- Out of curiosity, can you try whether changing the optimization level has any effect? I'm asking because we are also seeing random failures of ext/pb_ds/regression/priority_queue_rand.cc on ia64-linux which go away at -O0 and -O1... In that case, I'm suspecting some sort of miscompilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug c++/28250] [4.2 regression] ICE with invalid catch
--- Comment #9 from patchapp at dberlin dot org 2006-07-26 11:30 --- Subject: Bug number PR c++/28250 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/2006-07/msg01108.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28250
[Bug c/28488] incorrect warning says signed and unsigned type in conditional expression
--- Comment #5 from gurganbl at rose-hulman dot edu 2006-07-26 11:42 --- That would be a problem in assignment, not in the conditional. Additionally, if I do unsigned int baz = 0; signed int bar = -1; baz = bar; I get no warning. I agree with what you say about there being a problem and what the problem is, but it should give the same warning as for the above code. Currently, the ?: syntax gives a misleading warning since the problem is not in the conditional but in the assignment and strictly having the assignment problem is not generating a warning. -- gurganbl at rose-hulman dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28488
[Bug c/28488] incorrect warning says signed and unsigned type in conditional expression
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-26 11:47 --- No, you are incorrect. Anyways the warnings about ?: are to make sure that you know that they are different signedness, which might change the behavior slightly than what you are expecting. unsigned int baz = 0; signed int bar = -1; baz = bar; This is a different issue and I think is being fixed by the -Wcoercion work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28488
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #27 from fxcoudert at gcc dot gnu dot org 2006-07-26 12:07 --- I just got the missing g77 intrinsics list down to: Access, fcn, Check file accessibility. ChMod,sub, Change file modes. FSeek,fcn, Position file (low-level). GMTime, fcn, Convert time to GMT time info. LShift, fcn, Left-shift bits LTime,sub, Convert time to local time info. RShift, fcn, Right-shift bits. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-11-12 23:29:51 |2006-07-26 12:07:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug debug/27574] [4.1 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
--- Comment #11 from amylaar at gcc dot gnu dot org 2006-07-26 12:30 --- (In reply to comment #10) If I had to guess I'd say that this was a C++ front end problem, or maybe a recent change in cgraph. It can't have been a particularly recent change, since it already failed with GNU C++ version 4.1.0 20050323 (experimental) (sh-elf) . It worked with GNU C++ version 4.1.0 20050314 (experimental) (sh-elf) . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug target/27075] [4.1/4.2 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE
--- Comment #15 from dtemirbulatov at gmail dot com 2006-07-26 12:53 --- As Andrew posted, the question is the impact on other targets... Looking at the patch, it is only about e500(TARGET_E500 defined only for e500), so it should not impact other targets -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075
[Bug libgcj/28491] New: NetworkInterface.getNetworkInterfaces() doesn't report ipv6 interfaces.
$ cat IPv6Test.java
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.util.Enumeration;
public class IPv6Test
{
public static void main( String args[] ) throws Exception
{
Enumeration nics = NetworkInterface.getNetworkInterfaces();
while ( nics.hasMoreElements() )
{
NetworkInterface ni = (NetworkInterface)nics.nextElement();
System.out.println(ni);
}
}
}
$ gcj IPv6Test.java -C
$ java IPv6Test // java-sun-1.5.0.06
name:eth0 (eth0) index: 2 addresses:
/fe80:0:0:0:20f:eaff:fed3:1f6d%2;
/10.0.2.35;
name:lo (lo) index: 1 addresses:
/0:0:0:0:0:0:0:1%1;
/127.0.0.1;
$ gij IPv6Test
name: lo (lo) addresses:
/127.0.0.1;
name: eth0 (eth0) addresses:
/10.0.2.35;
$ /sbin/ip a l
1: lo: LOOPBACK,UP mtu 16436 qdisc noqueue
(...)
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
(...)
2: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000
(...)
inet 10.0.2.35/24 brd 10.0.2.255 scope global eth0
inet6 fe80::20f:eaff:fed3:1f6d/64 scope link
(...)
--
Summary: NetworkInterface.getNetworkInterfaces() doesn't report
ipv6 interfaces.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28491
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #2 from drow at gcc dot gnu dot org 2006-07-26 13:11 --- Subject: Re: ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed. On Wed, Jul 26, 2006 at 11:26:01AM -, pcarlini at suse dot de wrote: Out of curiosity, can you try whether changing the optimization level has any effect? I'm asking because we are also seeing random failures of ext/pb_ds/regression/priority_queue_rand.cc on ia64-linux which go away at -O0 and -O1... In that case, I'm suspecting some sort of miscompilation. Fails at -O1 in the same way. Fails differently at -O0. Failure at /space/fsf/commit/gcc/libstdc++-v3/testsuite/util/regression/rand/assoc/detail/insert_fn_imps.hpp: 71 container: aabaaab bccadab aacdbc dab more... native container: ...more... Uncaught exception: insert Failed at index 297 Test failed with seed 1153519516 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #4 from tbm at cyrius dot com 2006-07-26 13:26 --- Created an attachment (id=11945) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11945action=view) test case Testcase from application dcraw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #5 from tbm at cyrius dot com 2006-07-26 13:26 --- Created an attachment (id=11946) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11946action=view) test case Testcase from application dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #3 from pcarlini at suse dot de 2006-07-26 13:27 --- Thanks a lot for your feedback. Then, I think we should look first for things like uninitialized variables and/or miscompilations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug middle-end/28402] [4.0/4.1 Regression] Doubleword shifts implemented using word_mode libcalls
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-07-26 13:30 --- Subject: Bug 28402 Author: rsandifo Date: Wed Jul 26 13:30:34 2006 New Revision: 115755 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115755 Log: gcc/ PR middle-end/28402 * optabs.c (expand_binop): Pass next_methods rather than methods to expand_doubleword_shift. gcc/testsuite/ PR middle-end/28402 * gcc.dg/pr28402.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr28402.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/optabs.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28402
[Bug middle-end/28403] [4.0/4.1 Regression] Missed argument pop after doubleword shift
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-07-26 13:32 --- Subject: Bug 28403 Author: rsandifo Date: Wed Jul 26 13:32:01 2006 New Revision: 115756 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115756 Log: gcc/ PR middle-end/28403 * optabs.c (expand_doubleword_shift): Wrap the call to do_compare_rtx_and_jump with NO_DEFER_POP and OK_DEFER_POP. gcc/testsuite/ PR middle-end/28403 * gcc.c-torture/execute/pr28403.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr28403.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/optabs.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28403
[Bug middle-end/28402] [4.0/4.1 Regression] Doubleword shifts implemented using word_mode libcalls
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-07-26 13:34 --- Subject: Bug 28402 Author: rsandifo Date: Wed Jul 26 13:34:17 2006 New Revision: 115757 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115757 Log: gcc/ PR middle-end/28402 * optabs.c (expand_binop): Pass next_methods rather than methods to expand_doubleword_shift. gcc/testsuite/ PR middle-end/28402 * gcc.dg/pr28402.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr28402.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/optabs.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28402
[Bug middle-end/28403] [4.0/4.1 Regression] Missed argument pop after doubleword shift
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-07-26 13:35 --- Subject: Bug 28403 Author: rsandifo Date: Wed Jul 26 13:35:34 2006 New Revision: 115758 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115758 Log: gcc/ PR middle-end/28403 * optabs.c (expand_doubleword_shift): Wrap the call to do_compare_rtx_and_jump with NO_DEFER_POP and OK_DEFER_POP. gcc/testsuite/ PR middle-end/28403 * gcc.c-torture/execute/pr28403.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/pr28403.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/optabs.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28403
[Bug middle-end/28402] [4.0/4.1 Regression] Doubleword shifts implemented using word_mode libcalls
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-07-26 13:38 --- Patch applied to branches. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.4 4.1.2 | Known to work|3.4.4 4.2.0 |3.4.4 4.0.4 4.1.2 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28402
[Bug middle-end/28403] [4.0/4.1 Regression] Missed argument pop after doubleword shift
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-07-26 13:39 --- Patch applied to branches -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.4 4.1.2 | Known to work|3.4.4 4.2.0 |3.4.4 4.0.4 4.1.2 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28403
[Bug c/28492] New: -Wmissing-format-attribute causes warning for vsnprintf()
The options -Wformat -Wmissing-format-attribute causes the
warning: function might be possible candidate for `printf' format attribute
for a call to vsnprintf() even though its prototype already
has the printf format attribute.
This is observed with the
preinstalled gcc 4.1.0 on SUSE Linux 10.1 (AMD64) and with a
manually installed gcc 4.1.0 on Scientific Linux 4.0 (Xeon) (and also with the
preinstalled gcc 3.2.2 on Red Hat Linux 9.0 (i686))
with this command:
gcc -save-temps -c vsnprintf_one.c -Wformat -Wmissing-format-attribute
The vsnprintf_one.i produced on Scientific Linux is pasted here:
# 1 vsnprintf_one.c
# 1 built-in
# 1 command line
# 1 vsnprintf_one.c
# 1 /usr/include/stdio.h 1 3 4
# 28 /usr/include/stdio.h 3 4
# 1 /usr/include/features.h 1 3 4
# 314 /usr/include/features.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 315 /usr/include/features.h 2 3 4
# 337 /usr/include/features.h 3 4
# 1 /usr/include/gnu/stubs.h 1 3 4
# 338 /usr/include/features.h 2 3 4
# 29 /usr/include/stdio.h 2 3 4
# 1 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 1 3 4
# 213 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 3 4
typedef unsigned int size_t;
# 35 /usr/include/stdio.h 2 3 4
# 1 /usr/include/bits/types.h 1 3 4
# 28 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 29 /usr/include/bits/types.h 2 3 4
# 1 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 1 3 4
# 32 /usr/include/bits/types.h 2 3 4
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 129 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/typesizes.h 1 3 4
# 130 /usr/include/bits/types.h 2 3 4
__extension__ typedef __u_quad_t __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef __u_quad_t __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef __quad_t __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef __u_quad_t __rlim64_t;
__extension__ typedef unsigned int __id_t;
__extension__ typedef long int __time_t;
__extension__ typedef unsigned int __useconds_t;
__extension__ typedef long int __suseconds_t;
__extension__ typedef int __daddr_t;
__extension__ typedef long int __swblk_t;
__extension__ typedef int __key_t;
__extension__ typedef int __clockid_t;
__extension__ typedef int __timer_t;
__extension__ typedef long int __blksize_t;
__extension__ typedef long int __blkcnt_t;
__extension__ typedef __quad_t __blkcnt64_t;
__extension__ typedef unsigned long int __fsblkcnt_t;
__extension__ typedef __u_quad_t __fsblkcnt64_t;
__extension__ typedef unsigned long int __fsfilcnt_t;
__extension__ typedef __u_quad_t __fsfilcnt64_t;
__extension__ typedef int __ssize_t;
typedef __off64_t __loff_t;
typedef __quad_t *__qaddr_t;
typedef char *__caddr_t;
__extension__ typedef int __intptr_t;
__extension__ typedef unsigned int __socklen_t;
# 37 /usr/include/stdio.h 2 3 4
typedef struct _IO_FILE FILE;
# 62 /usr/include/stdio.h 3 4
typedef struct _IO_FILE __FILE;
# 72 /usr/include/stdio.h 3 4
# 1 /usr/include/libio.h 1 3 4
# 32 /usr/include/libio.h 3 4
# 1 /usr/include/_G_config.h 1 3 4
# 14 /usr/include/_G_config.h 3 4
# 1 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 1 3 4
# 325 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 3 4
typedef long int wchar_t;
# 354 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 3 4
typedef unsigned int wint_t;
# 15 /usr/include/_G_config.h 2 3 4
# 24 /usr/include/_G_config.h 3 4
# 1 /usr/include/wchar.h 1 3 4
# 48 /usr/include/wchar.h 3 4
# 1 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 1 3 4
# 49 /usr/include/wchar.h 2 3 4
# 1 /usr/include/bits/wchar.h 1 3 4
# 51 /usr/include/wchar.h 2 3 4
# 76 /usr/include/wchar.h 3 4
typedef struct
{
int __count;
union
{
wint_t __wch;
char __wchb[4];
} __value;
} __mbstate_t;
# 25 /usr/include/_G_config.h 2 3 4
typedef struct
{
__off_t __pos;
__mbstate_t __state;
} _G_fpos_t;
typedef struct
{
__off64_t __pos;
__mbstate_t __state;
} _G_fpos64_t;
# 44 /usr/include/_G_config.h 3 4
# 1 /usr/include/gconv.h 1 3 4
# 28 /usr/include/gconv.h 3 4
# 1 /usr/include/wchar.h 1 3 4
# 48
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #4 from tbm at cyrius dot com 2006-07-26 13:48 --- Created an attachment (id=11947) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11947action=view) test case Testcase from application 'john'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug debug/27574] [4.1 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
--- Comment #12 from drow at gcc dot gnu dot org 2006-07-26 13:59 --- It is a cgraph change. There were several patches affecting cgraph_remove_node during this time period; it was probably one of those. The problem is that we throw away the body of the abstract copy of the constructor, before we get around to emitting debug information for it. There's already a debug hook at what looks like the right time. It's just not used for dwarf2: deferred_inline_function. It was replaced by outlining_inline_function, which is called only when we know we'll generate a concrete instance. There's a couple of things we could do: - Not throw away the body. - Try to generate the debug info earlier, and then prune it if it isn't needed. - Try to treat one of the concrete clones (whose bodies we need) as the origin. I think the first one is going to be safest for now. I don't really see how to do it. Jan, do you have a suggestion? -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #4 from pcarlini at suse dot de 2006-07-26 14:55 --- Confirmed on x86-linux. I did: Index: rand_regression_test.hpp === --- rand_regression_test.hpp(revision 115714) +++ rand_regression_test.hpp(working copy) @@ -111,7 +111,7 @@ // Sane defaults. size_t n = iter; size_t m = keys; -size_t sd = 0; // 0 = time-determined arbitrary +size_t sd = 1153519516; // 0 = time-determined arbitrary double tp = 0.2; double ip = 0.6; double ep = 0.2; -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-26 14:55:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug c++/28493] New: Wrong address of stack object used for destructor call on PPC
-- sample program --
struct Command {
Command() {}
virtual ~Command() {}
};
void tryfunc() {
Command cmd;
for (;;) { throw 1; }
}
-- end sample program --
Disassembly of tryfunc():
(notice at 58-5c, constructor is called on r1+8, but at
88-90, destructor is called on r1+0)
tryfunc():
0: 94 21 ff 60 stwur1,-160(r1)
4: 7c 08 02 a6 mflrr0
8: 3d 20 00 00 lis r9,0
a: R_PPC_ADDR16_HA __gxx_personality_sj0
c: 39 29 00 00 addir9,r9,0
e: R_PPC_ADDR16_LO __gxx_personality_sj0
10: 7d 80 00 26 mfcrr12
14: 91 21 00 30 stw r9,48(r1)
18: 3d 20 00 00 lis r9,0
1a: R_PPC_ADDR16_HA .gcc_except_table
1c: 38 61 00 18 addir3,r1,24
20: 90 01 00 a4 stw r0,164(r1)
24: 39 29 00 00 addir9,r9,0
26: R_PPC_ADDR16_LO .gcc_except_table
28: 80 01 00 00 lwz r0,0(r1)
2c: 91 21 00 34 stw r9,52(r1)
30: 3d 20 00 00 lis r9,0
32: R_PPC_ADDR16_HA .text+0x84
34: 39 29 00 84 addir9,r9,132
36: R_PPC_ADDR16_LO .text+0x84
38: 90 01 00 40 stw r0,64(r1)
3c: 38 01 00 08 addir0,r1,8
40: 90 01 00 38 stw r0,56(r1)
44: 91 81 00 54 stw r12,84(r1)
48: 91 21 00 3c stw r9,60(r1)
4c: bd c1 00 58 stmwr14,88(r1)
50: 90 21 00 44 stw r1,68(r1)
54: 48 00 00 01 bl 54 tryfunc()+0x54
54: R_PPC_REL24 _Unwind_SjLj_Register
58: 38 61 00 08 addir3,r1,8
5c: 48 00 00 01 bl 5c tryfunc()+0x5c
5c: R_PPC_REL24 Command::Command()
60: 38 60 00 04 li r3,4
64: 48 00 00 01 bl 64 tryfunc()+0x64
64: R_PPC_REL24 __cxa_allocate_exception
68: 38 00 00 01 li r0,1
6c: 3c 80 00 00 lis r4,0
6e: R_PPC_ADDR16_HA typeinfo for int
70: 90 03 00 00 stw r0,0(r3)
74: 38 84 00 00 addir4,r4,0
76: R_PPC_ADDR16_LO typeinfo for int
78: 38 a0 00 00 li r5,0
7c: 90 01 00 1c stw r0,28(r1)
80: 48 00 00 01 bl 80 tryfunc()+0x80
80: R_PPC_REL24 __cxa_throw
84: 80 01 00 20 lwz r0,32(r1)
88: 7c 23 0b 78 mr r3,r1
8c: 90 01 00 4c stw r0,76(r1)
90: 48 00 00 01 bl 90 tryfunc()+0x90
90: R_PPC_REL24 Command::~Command()
94: 38 00 ff ff li r0,-1
98: 80 61 00 4c lwz r3,76(r1)
9c: 90 01 00 1c stw r0,28(r1)
a0: 48 00 00 01 bl a0 tryfunc()+0xa0
a0: R_PPC_REL24 _Unwind_SjLj_Resume
Program was compiled with the following command line options:
g++ -Os -msoft-float -fno-inline sample-program.cc -c
The -msoft-float and -Os aren't necessary to reproduce this problem,
but reduce clutter.
The optimization level doesn't matter. Looking at a disassembly at
-O0 may shed more light on the problem:
Disassembly of tryfunc() at -O0 (all other CL arguments unchanged):
tryfunc():
0: 94 21 ff 50 stwur1,-176(r1)
4: 7c 08 02 a6 mflrr0
8: 7d 80 00 26 mfcrr12
c: 91 c1 00 68 stw r14,104(r1)
10: 91 e1 00 6c stw r15,108(r1)
14: 92 01 00 70 stw r16,112(r1)
18: 92 21 00 74 stw r17,116(r1)
1c: 92 41 00 78 stw r18,120(r1)
20: 92 61 00 7c stw r19,124(r1)
24: 92 81 00 80 stw r20,128(r1)
28: 92 a1 00 84 stw r21,132(r1)
2c: 92 c1 00 88 stw r22,136(r1)
30: 92 e1 00 8c stw r23,140(r1)
34: 93 01 00 90 stw r24,144(r1)
38: 93 21 00 94 stw r25,148(r1)
3c: 93 41 00 98 stw r26,152(r1)
40: 93 61 00 9c stw r27,156(r1)
44: 93 81 00 a0 stw r28,160(r1)
48: 93 a1 00 a4 stw r29,164(r1)
4c: 93 c1 00 a8 stw r30,168(r1)
50: 93 e1 00 ac stw r31,172(r1)
54: 90 01 00 b4 stw r0,180(r1)
58: 91 81 00 64 stw r12,100(r1)
5c: 7c 3f 0b 78 mr r31,r1
60: 3d 20 00 00 lis r9,0
62: R_PPC_ADDR16_HA __gxx_personality_sj0
64: 38 09 00 00 addir0,r9,0
66: R_PPC_ADDR16_LO __gxx_personality_sj0
68: 90 1f 00 30 stw r0,48(r31)
6c: 3d 20 00 00 lis r9,0
6e: R_PPC_ADDR16_HA .gcc_except_table
70: 38 09 00 00 addir0,r9,0
72: R_PPC_ADDR16_LO .gcc_except_table
74: 90 1f 00 34 stw r0,52(r31)
78: 39 7f 00 38 addir11,r31,56
7c: 38 1f 00 08 addir0,r31,8
80: 90 0b 00 00 stw
[Bug target/28493] Wrong address of stack object used for destructor call on PPC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28493
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #15 from tbm at cyrius dot com 2006-07-26 15:25 --- One of our (Debian's) Hurd porters has confirmed that this patch works. Alfred, can you please clean it up and submit it to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #16 from ams at gnu dot org 2006-07-26 15:35 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared I'll try to get around it as soon as I can. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28493] Wrong address of stack object used for destructor call on PPC
--- Comment #1 from atgraham at gmail dot com 2006-07-26 15:42 ---
Actually, the for loop is unnecessary. Here's a shorter version that displays
the same problem:
struct Command {
virtual ~Command() {}
};
void tryfunc() {
Command cmd;
throw 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28493
[Bug fortran/28494] New: Unclear run time error message
I received the run time error message upper bound of dimension 1 exceeded. I initially thought that I had an array with an upper bound of 1, and that the array index was larger than that. I now think that the error message tells me that I have a rank-2 array, and that the upper bound of the first rank was exceeded. The error message could be improved to read rank 1 or index 1 instead. -- Summary: Unclear run time error message Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28494
[Bug c++/28495] New: [4.2 regression] ICE in final_scan_insn, at final.c:2448
I get the following ICE with gcc 4.2 on ia64. The reduced testcase fails on
gcc 4.0/4.1 with an error but the original file compiles fine and only produces
an ICE with gcc 4.2 at -O.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O xstow-tree.cpp
xstow-tree.cpp: In member function 'bool Tree::check(RefNode, RefNode,
Refstd::vectorTree::Link, std::allocatorTree::Link )':
xstow-tree.cpp:718: error: could not split insn
(call_insn 359 358 360 24 (parallel [
(call (mem:DI (const:DI (plus:DI (symbol_ref:DI
(_ZTV14VecStringValue) [flags 0x40] var_decl 0x204fca50
_ZTV14VecStringValue)
(const_int 16 [0x10]))) [0 S8 A64])
(const_int 1 [0x1]))
(clobber (reg:DI 320 b0))
(clobber (scratch:DI))
(clobber (scratch:DI))
]) 322 {call_gp} (insn_list:REG_DEP_TRUE 354 (insn_list:REG_DEP_TRUE
357 (insn_list:REG_DEP_TRUE 358 (nil
(expr_list:REG_DEAD (reg:DI 120 r120)
(expr_list:REG_DEAD (reg:DI 121 r121)
(expr_list:REG_UNUSED (scratch:DI)
(expr_list:REG_UNUSED (scratch:DI)
(expr_list:REG_UNUSED (reg:DI 320 b0)
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
(expr_list:REG_DEP_TRUE (use (reg:DI 121 r121))
(expr_list:REG_DEP_TRUE (use (reg:DI 120 r120))
(nil)
xstow-tree.cpp:718: internal compiler error: in final_scan_insn, at
final.c:2448
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c xstow-tree.cpp
[EMAIL PROTECTED]:~$
Here's proof that the original source is valid code. ;)
[EMAIL PROTECTED]:~/src/xstow-0.5.1/src$ /usr/lib/gcc-snapshot/bin/g++
-DHAVE_CONFIG_H -I.. -g -O2 -DNDEBUG -DNFORMAT -DSYSCONFDIR='/etc/xstow'
-c -o tree.o tree.cpp
tree.cpp: In member function 'bool Tree::check(RefNode, RefNode,
Refstd::vectorTree::Link, std::allocatorTree::Link )':
tree.cpp:613: error: could not split insn
(call_insn 4695 32617 32618 444 tree.cpp:468 (parallel [
(call (mem:DI (const:DI (plus:DI (symbol_ref:DI
(_ZTV14VecStringValue) [flags 0x40] var_decl 0x224fd340
_ZTV14VecStringValue)
(const_int 80 [0x50]))) [0 S8 A64])
(const_int 1 [0x1]))
(clobber (reg:DI 320 b0))
(clobber (scratch:DI))
(clobber (scratch:DI))
]) 322 {call_gp} (nil)
(expr_list:REG_DEAD (reg:DI 120 r120)
(expr_list:REG_DEAD (reg:DI 121 r121)
(expr_list:REG_UNUSED (scratch:DI)
(expr_list:REG_UNUSED (scratch:DI)
(expr_list:REG_UNUSED (reg:DI 320 b0)
(expr_list:REG_EH_REGION (const_int 145 [0x91])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
(expr_list:REG_DEP_TRUE (use (reg:DI 121 r121))
(expr_list:REG_DEP_TRUE (use (reg:DI 120 r120))
(nil)
tree.cpp:613: internal compiler error: in final_scan_insn, at final.c:2448
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
[EMAIL PROTECTED]:~/src/xstow-0.5.1/src$ g++-4.1 -DHAVE_CONFIG_H -I.. -g -O2
-DNDEBUG -DNFORMAT -DSYSCONFDIR='/etc/xstow' -c -o tree.o tree.cpp
[EMAIL PROTECTED]:~/src/xstow-0.5.1/src$ g++-4.0 -DHAVE_CONFIG_H -I.. -g -O2
-DNDEBUG -DNFORMAT -DSYSCONFDIR='/etc/xstow' -c -o tree.o tree.cpp
[EMAIL PROTECTED]:~/src/xstow-0.5.1/src$
--
Summary: [4.2 regression] ICE in final_scan_insn, at final.c:2448
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC host triplet: ia64-linux-gnu
GCC target triplet: ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #1 from tbm at cyrius dot com 2006-07-26 16:22 --- Created an attachment (id=11948) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11948action=view) test case Testcase from application xstow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug fortran/28494] Unclear run time error message
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 16:22 --- dimension 1 means to me, the first dimension. I don't see why it was not hard to understand, in fact I did not read the rest of your message until I already said to myself this was the first dimension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28494
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #2 from tbm at cyrius dot com 2006-07-26 16:30 --- Huh, the testcase fails at -O but works at -O2. (But the original sources failed at -O2). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #3 from tbm at cyrius dot com 2006-07-26 16:36 --- This bug got introduced between 20051122 and 20060218. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/27907] [4.2 regression] ICE in expand_simple_unop, at optabs.c:2307
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-07-26 16:47 --- Subject: Bug 27907 Author: rakdver Date: Wed Jul 26 16:47:28 2006 New Revision: 115760 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115760 Log: PR rtl-optimization/27907 * expr.c (force_operand): Use convert_move to handle FLOAT_EXTEND and FLOAT_TRUNCATE. * gcc.c-torture/compile/pr27907.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr27907.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27907
[Bug target/27907] [4.2 regression] ICE in expand_simple_unop, at optabs.c:2307
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-26 17:02 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27907
[Bug fortran/28496] New: Error during array initialization with gfortran
When using the following test : === CODE BEGIN == ::: test.f90 ::: program test implicit none integer, dimension(3), parameter :: a=(/1,2,3/) integer, dimension(3), parameter :: b=(/4,5,6/) !integer, dimension(6), parameter :: y=(/ a(1), a(2), a(3), b(1), b(2), b(3) /) integer, dimension(6), parameter :: y=(/ a(:), b(:) /) print *, a= , a print *, b= , b print *, y= , y end === CODE END == compilation with gfortran fails whith the following message : $ gfortran test.f90 In file test.f90:9 integer, dimension(6), parameter :: y=(/ a(:), b(:) /) 1 Internal Error at (1): In file test.f90:9 integer, dimension(6), parameter :: y=(/ a(:), b(:) /) 1 Initialization expression didn't reduce (1) __ When the initialization expression is replaced by the commented way. All works properly. Did I misunderstand something ? Or this way of initializing is not supported yet ? I also tried the loop initialization way, but obtained the same message. i.e. integer, dimension(6), parameter :: y=(/ (a(i),i=1,size(a)), (b(i),i=1,size(b) /) Thanks for help -- Summary: Error during array initialization with gfortran Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: snordin_ng at yahoo dot fr GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28496
[Bug bootstrap/28497] New: /usr/ccs/bin/ld: Unrecognized argument: +init
It appears that GCC is assuming that the system linker can accept the +init option. In the ld(1) man page, +init appears under the heading 64 Bit (ELF) Link Editor options, and the system is 32-bit-only---might that have something to do with it? (begin build log excerpt) ranlib libbackend.a stage1/xgcc -Bstage1/ -B/opt/tg/hppa2.0w-hp-hpux11.00/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o dummy-checksum.o \ main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a ../libiberty/libiberty.a /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (c-lang.o) was detected. The linked output may not run on a PA 1.x system. /usr/ccs/bin/ld: Unrecognized argument: +init /usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld flags... files... collect2: ld returned 1 exit status gmake[2]: *** [cc1-dummy] Error 1 gmake[2]: Leaving directory `/home/cport/tmp/gcc--4.1.1.build/gcc' gmake[1]: *** [stage2_build] Error 2 gmake[1]: Leaving directory `/home/cport/tmp/gcc--4.1.1.build/gcc' gmake: *** [bootstrap-lean] Error 2 (end build log excerpt) Output of /usr/ccs/bin/ld -V: 92453-07 linker command s800.sgs ld B.11.13 REL 990903 /usr/ccs/bin/ld: 92453-07 linker linker ld B.11.13 990903 /usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld flags... files... Output of uname -a: HP-UX hrdygrdy B.11.00 A 9000/785 2003934647 two-user license -- Summary: /usr/ccs/bin/ld: Unrecognized argument: +init Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skunk at iskunk dot org GCC build triplet: hppa2.0w-hp-hpux11.00 GCC host triplet: hppa2.0w-hp-hpux11.00 GCC target triplet: hppa2.0w-hp-hpux11.00 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug c++/28498] New: fstack-protector causes crash in combination with -Os
When compiling c++ code, you can get an error similar to this one: /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h: In function '_RandomAccessIterator std::__unguarded_partition(_RandomAccessIterator, _RandomAccessIterator, _Tp) [with _RandomAccessIterator = __gnu_cxx::__normal_iteratorQRect*, std::vectorQRect, std::allocatorQRect , _Tp = QRect]': /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h:2182: internal compiler error: Segmentation fault according to gcc -v, cc1plus was run with /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/cc1plus -quiet -v -D_GNU_SOURCE -D__PIC__ -DPIC windowgrabber.cc -fPIC -fstack-protector-all -quiet -dumpbase windowgrabber.cc -mtune=pentiumpro -auxbase windowgrabber -Os -version -fPIC -fstack-protector-all -o /tmp/cchIBKrS.s I'll attach source -- Summary: fstack-protector causes crash in combination with -Os Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m dot b dot lankhorst at gmail dot com 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=28498
[Bug middle-end/28498] fstack-protector causes crash in combination with -Os
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2006-07-26 17:42 --- Created an attachment (id=11949) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11949action=view) The source mentioned in description Source that won't compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28498
[Bug bootstrap/28497] /usr/ccs/bin/ld: Unrecognized argument: +init
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 17:42 --- I think GCC needs the GNU binutils linker now. Also how did you configure GCC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug bootstrap/28497] /usr/ccs/bin/ld: Unrecognized argument: +init
--- Comment #2 from skunk at iskunk dot org 2006-07-26 17:55 --- (In reply to comment #1) I think GCC needs the GNU binutils linker now. It certainly needs the GNU assembler (explicit configure-time error to that effect), and I built binutils 2.17. That one said that (GNU) ld is not supported in this configuration... moreover, the documentation for GCC's HPPA-specific options list a few relevant to the HP linker. Also how did you configure GCC? .../configure --disable-dependency-tracking --disable-maintainer-mode --disable-shared --disable-nls --enable-version-specific-runtime-libs --with-arch=2.0 --with-gnu-as --with-as=/usr/local/bin/gnu-as --enable-languages=c,c++ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug c++/27668] [4.0/4.1/4.2 regression] ICE with invalid template parameter
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-26 15:06:09 |2006-07-26 18:04:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug bootstrap/28499] New: Bogus whitespace in preprocessor directives breaks bootstrap
The file in question here is gcc-4.1.1/gcc/tree-vectorizer.h, though I notice
there are many more instances of this issue in the GCC tree:
find gcc-4.1.1 -name '*.[ch]' -exec pcregrep
'^\s+#\s*(define|undef|if|endif)' {} \; | wc -l
326
(same command, but with pcregrep -l)
62
I know that the topic of whitespace before the # has been discussed here
before, that the applicable standards allow it and compilers that don't are
broken, etc. ... but I do believe the bootstrapping process, by its nature, has
to accomodate quirks such as these.
(begin build log excerpt)
make[2]: Entering directory `/usr/home/cport/tmp/gcc--4.1.1.build/gcc'
cc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-DHAVE_CONFIG_H -I. -I. -I/tg/freeport/src/gcc/gcc--4.1.1/gcc
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/.
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../include
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../libcpp/include
/tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c -o tree-vectorizer.o
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 33: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define UNKNOWN_LOC NULL
--^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 34: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define EXPR_LOC(e) EXPR_LOCUS(e)
--^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 35: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define LOC_FILE(l) (l)-file
--^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 36: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define LOC_LINE(l) (l)-line
--^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 813: In
this statement, UNKNOWN_LOC is not declared. (undeclared)
if (loop_loc != UNKNOWN_LOC)
--^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1112: In
this statement, UNKNOWN_LOC is not declared. (undeclared)
if (loop_loc != UNKNOWN_LOC)
--^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1236: In
this statement, UNKNOWN_LOC is not declared. (undeclared)
return UNKNOWN_LOC;
---^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1242:
In this statement, EXPR_LOC(...) of type int, is being converted to
pointer to struct location_s. (cvtdiftypes)
return EXPR_LOC (node);
---^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1256:
In this statement, EXPR_LOC(...) of type int, is being converted to
pointer to struct location_s. (cvtdiftypes)
return EXPR_LOC (node);
---^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1330: In
this statement, UNKNOWN_LOC is not declared. (undeclared)
if (vect_loop_location == UNKNOWN_LOC)
^
make[2]: *** [tree-vectorizer.o] Error 1
make[2]: Leaving directory `/usr/home/cport/tmp/gcc--4.1.1.build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/usr/home/cport/tmp/gcc--4.1.1.build/gcc'
make: *** [bootstrap-lean] Error 2
(end build log excerpt)
--
Summary: Bogus whitespace in preprocessor directives breaks
bootstrap
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: alphaev56-dec-osf4.0g
GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 18:23 --- Your compiler is not ANSI/ISO C complaint. And in GCC 4.1.0 and above (maybe it was 4.0.0), we require an ISO C90 compiler which this is valid ISO C90. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #2 from skunk at iskunk dot org 2006-07-26 18:36 --- I was under the impression that the bootstrapping process would first build an intermediate compiler, itself written in a safe subset of C, that would then build the full GCC, which could use modern features as needed. Was it decided to no longer support bootstrapping on systems with dumb C compilers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug boehm-gc/25652] Java support for amd64-pc-freebsd
--- Comment #5 from arno at heho dot snv dot jussieu dot fr 2006-07-26 18:36 --- Created an attachment (id=11950) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11950action=view) take-II this one works at -head as well Bon, apparently I'm (almost) the only one who uses gcj on freebsd-amd64, but here's another patch; the basic differences with the first one are removal of unneeded diffs (apart non-tested gcconfig.h support for freebsd-[arm|powerpc]) and explicitly using FREEBSD_STACKBOTTOM as well as GC_FreeBSDGetDataStart(). === libjava Summary === # of expected passes6887 # of unexpected failures21 # of expected failures 12 # of untested testcases 28 Failures are : FAIL: PR16923.c FAIL: PR27908 FAIL: Throw_2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25652
[Bug c/28500] New: DBL_RADIX missing
$ cat radix.c
#include stdio.h
#include float.h
int main()
{
printf(FLT_RADIX = %i\n,FLT_RADIX);
printf(DBL_RADIX = %i\n,DBL_RADIX);
return 0;
}
$ gcc radix.c
radix.c: In function 'main':
radix.c:7: error: 'DBL_RADIX' undeclared (first use in this function)
radix.c:7: error: (Each undeclared identifier is reported only once
radix.c:7: error: for each function it appears in.)
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc/trunk/configure --prefix=/home/ig25
--enable-languages=c,fortran
Thread model: posix
gcc version 4.2.0 20060723 (experimental)
--
Summary: DBL_RADIX missing
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28500
[Bug c/28500] DBL_RADIX missing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 18:50 --- only FLT_RADIX exists in the C99 standard. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28500
[Bug c/28500] DBL_RADIX missing
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-26 18:52 --- FLT_RADIX is for all of float, double and long double. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28500
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #3 from skunk at iskunk dot org 2006-07-26 19:00 --- I'm sorry; I meant to write Why was it decided to...? What strikes me as odd about this, moreover, is that the incompatibility appears gratuitous; the extra whitespace doesn't help anything. Is this a case of wanting to (eventually) use modern C features in the intermediate compiler? More importantly, what is the support status for systems like the one in question? Is it to build 3.4.x first, and then use that to build 4.x? Or is 4.x not intended to support it at all, hacks notwithstanding? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-26 19:02 --- (In reply to comment #3) What strikes me as odd about this, moreover, is that the incompatibility appears gratuitous; the extra whitespace doesn't help anything. Is this a case of wanting to (eventually) use modern C features in the intermediate compiler? Modern C as in 15 years is a joke. 15 years is enough for vendors to provide a new C compiler. More importantly, what is the support status for systems like the one in question? Is it to build 3.4.x first, and then use that to build 4.x? Or is 4.x not intended to support it at all, hacks notwithstanding? Build 3.4.x first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug fortran/28496] Error during array initialization with gfortran
--- Comment #1 from kargl at gcc dot gnu dot org 2006-07-26 19:15 --- First, you'll want to upgrade to at least 4.1.1 form 4.0.2. Second, yes, it appears to be a bug. These lines work as expected. integer, dimension(6), parameter :: y=(/ a(1:3), b(1:3) /) integer, dimension(6), parameter :: y=(/ a, b /) It appears the (:) in a(:) and b(:) is not handled correctly. I haven't looked into the implicit do loop method. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28496
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #27 from rakdver at gcc dot gnu dot org 2006-07-26 19:38 --- Patch for the wrong choice of induction variable: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01125.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug libfortran/28452] __gfortran_random_r10 not found
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-07-26 19:49 --- Created an attachment (id=11951) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11951action=view) Current status of patch Here's the current patch. It regtests fine, and seems to do the Right Thing. I haven't been able to test it on a system with REAL(16), nor on an S/360 where FLT_RADIX == 16. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #11929|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28452
[Bug fortran/28496] Error during array initialization
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-07-26 19:52 --- gfortran 4.0 series is seriously broken and shouldn't be considered for production use. Indeed, your testcase and variations work with the gfortran 4.2 branch, except for the following: $ cat a.f90 integer, dimension(3), parameter :: a=(/1,2,3/) integer, dimension(3), parameter :: b=(/a(:)/) end $ gfortran a.f90 a.f90:0: internal compiler error: Segmentation fault which is an ICE. Removing the (:) makes it work. The backtrace for the ICE is: Program received signal SIGSEGV, Segmentation fault. 0xb7ee5473 in __gmpz_set () from /usr/lib/libgmp.so.3 (gdb) where #0 0xb7ee5473 in __gmpz_set () from /usr/lib/libgmp.so.3 #1 0x08061c04 in simplify_const_ref (p=0x8729548) at ../../../trunk/gcc/fortran/expr.c:1089 #2 0x0806260d in gfc_simplify_expr (p=0x8729548, type=1) at ../../../trunk/gcc/fortran/expr.c:1499 #3 0x08062bb4 in simplify_parameter_variable (p=0x8729420, type=1) at ../../../trunk/gcc/fortran/expr.c:1374 #4 0x080625ee in gfc_simplify_expr (p=0x8729420, type=1) at ../../../trunk/gcc/fortran/expr.c:1470 #5 0x0804f4da in expand_constructor (c=0x8728c68) at ../../../trunk/gcc/fortran/array.c:1375 #6 0x0804f66b in gfc_array_size (array=0x87293c8, result=0xbf919208) at ../../../trunk/gcc/fortran/array.c:1968 #7 0x0808d4ff in expression_rank (e=0x87293c8) at ../../../trunk/gcc/fortran/resolve.c:2798 #8 0x0808e7f8 in gfc_resolve_expr (e=0x87293c8) at ../../../trunk/gcc/fortran/resolve.c:3026 #9 0x08062e16 in gfc_match_init_expr (result=0xbf919444) at ../../../trunk/gcc/fortran/expr.c:1843 #10 0x0805b49a in variable_decl (elem=Variable elem is not available. ) at ../../../trunk/gcc/fortran/decl.c:1268 #11 0x0805ba4a in gfc_match_data_decl () at ../../../trunk/gcc/fortran/decl.c:2316 #12 0x08084b0a in match_word (str=Variable str is not available. ) at ../../../trunk/gcc/fortran/parse.c:65 #13 0x080850ad in decode_statement () at ../../../trunk/gcc/fortran/parse.c:134 #14 0x08085a3e in next_statement () at ../../../trunk/gcc/fortran/parse.c:493 #15 0x080876ec in parse_spec (st=ST_DATA_DECL) at ../../../trunk/gcc/fortran/parse.c:1870 #16 0x08087c09 in parse_progunit (st=Variable st is not available. ) at ../../../trunk/gcc/fortran/parse.c:2870 #17 0x080880d1 in gfc_parse_file () at ../../../trunk/gcc/fortran/parse.c:3206 #18 0x080a91fd in gfc_be_parse_file (set_yydebug=0) at ../../../trunk/gcc/fortran/f95-lang.c:303 #19 0x0839d14a in toplev_main (argc=13, argv=0xbf919744) at ../../../trunk/gcc/toplev.c:999 #20 0x080dcd6f in main (argc=1, argv=0x1) at ../../../trunk/gcc/main.c:35 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|blocker |major Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-redhat-linux | GCC host triplet|x86_64-redhat-linux | GCC target triplet|x86_64-redhat-linux | Last reconfirmed|-00-00 00:00:00 |2006-07-26 19:52:36 date|| Summary|Error during array |Error during array |initialization with gfortran|initialization Version|4.0.2 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28496
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #5 from skunk at iskunk dot org 2006-07-26 19:53 --- (In reply to comment #4) Modern C as in 15 years is a joke. 15 years is enough for vendors to provide a new C compiler. Sometimes, you can't get a newer version (e.g. licensing issues). Sometimes, you don't want to (e.g. backward compatibility problems). I can't imagine why plain ANSI C89 wasn't good enough for the intermediate compiler. Whatever newer features were desired, they can't have been worth breaking the bootstrap process for older systems. (I'd have been more inclined to agree if the change was to drop KR compatibility, though even then there would have been a good argument against. And there's always ansi2knr and other workarounds.) Build 3.4.x first. A six-stage bootstrap, then... I'll do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #6 from schwab at suse dot de 2006-07-26 20:03 --- This _is_ plain ANSI C89. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug tree-optimization/27742] [4.2 regression] ICE with -ftree-vectorizer-verbose
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-07-26 20:08
---
Here's a reduced testcase:
Compile (on x86_64-unknown-linux-gnu) with:
g++ -O -ftree-vectorize -ftree-vectorizer-verbose=1 --param ggc-min-expand=0
--param ggc-min-heapsize=0
On i686-pc-linux-gnu you'll probably have to add -march=pentium4 or so.
void foo() {}
void bar(int *p)
{
for (int i = 0; i 4; i++)
p[i] = 0;
}
inline void baz(int i)
{
while (i) ++i;
}
struct A
{
A() { baz(3); }
};
A a, b;
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742
[Bug tree-optimization/27882] [4.1/4.2 regression] segfault in ipa-inline.c, if (e-callee-local.disregard_inline_limits
--- Comment #28 from hubicka at gcc dot gnu dot org 2006-07-26 20:17 --- Subject: Bug 27882 Author: hubicka Date: Wed Jul 26 20:17:32 2006 New Revision: 115763 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115763 Log: PR tree-optimization/27882 * cgraph.c (cgraph_remove_node): Clear needed, reachable, next, previous and decl fields. * cgraphunit.c (cgraph_reset_node): Expect cgraph_remove_node to kill next pointer (cgraph_analyze_compilation_unit): Likewise. * ipa.c (cgraph_remove_unreachable_nodes): Likewise. * ipa-inline.c (cgraph_decide_recursive_inlining): Likewise. (cgraph_early_inlinine): Make order garbage collected. * Makefile.in (gt-ipa-inline): New garbagecollected file. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/cgraph.c trunk/gcc/cgraphunit.c trunk/gcc/ipa-inline.c trunk/gcc/ipa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
[Bug target/28170] [4.1 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #16 from dje at gcc dot gnu dot org 2006-07-26 20:22 ---
Subject: Bug 28170
Author: dje
Date: Wed Jul 26 20:21:49 2006
New Revision: 115764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus [EMAIL PROTECTED]
PR target/27287
* config/rs6000/spe.md (frob_di_df_2): Add m-r alternative.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
PR target/28150
* config/rs6000/rs6000.c (rs6000_legitimate_address): Do not allow
PRE_{INC,DEC} of TFmode.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
Alan Modra [EMAIL PROTECTED]
PR target/28170
* config/rs6000/rs6000.c (insvdi_rshift_rlwimi_p): Correct shiftop
bounds. Simplify.
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_1-branch/gcc/config/rs6000/spe.md
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/28150] ICE in reload_cse_simplify_operands, at postreload.c:394
--- Comment #9 from dje at gcc dot gnu dot org 2006-07-26 20:22 ---
Subject: Bug 28150
Author: dje
Date: Wed Jul 26 20:21:49 2006
New Revision: 115764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus [EMAIL PROTECTED]
PR target/27287
* config/rs6000/spe.md (frob_di_df_2): Add m-r alternative.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
PR target/28150
* config/rs6000/rs6000.c (rs6000_legitimate_address): Do not allow
PRE_{INC,DEC} of TFmode.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
Alan Modra [EMAIL PROTECTED]
PR target/28170
* config/rs6000/rs6000.c (insvdi_rshift_rlwimi_p): Correct shiftop
bounds. Simplify.
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_1-branch/gcc/config/rs6000/spe.md
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
[Bug target/27287] [4.1 Regression] returning constant double
--- Comment #19 from dje at gcc dot gnu dot org 2006-07-26 20:22 ---
Subject: Bug 27287
Author: dje
Date: Wed Jul 26 20:21:49 2006
New Revision: 115764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus [EMAIL PROTECTED]
PR target/27287
* config/rs6000/spe.md (frob_di_df_2): Add m-r alternative.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
PR target/28150
* config/rs6000/rs6000.c (rs6000_legitimate_address): Do not allow
PRE_{INC,DEC} of TFmode.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
Alan Modra [EMAIL PROTECTED]
PR target/28170
* config/rs6000/rs6000.c (insvdi_rshift_rlwimi_p): Correct shiftop
bounds. Simplify.
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_1-branch/gcc/config/rs6000/spe.md
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1 Regression] returning constant double
--- Comment #20 from dje at gcc dot gnu dot org 2006-07-26 20:25 --- patch backported -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/28150] ICE in reload_cse_simplify_operands, at postreload.c:394
--- Comment #10 from dje at gcc dot gnu dot org 2006-07-26 20:26 --- patch backported -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
[Bug target/28170] [4.1 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #17 from dje at gcc dot gnu dot org 2006-07-26 20:27 --- patch backported -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug c++/28501] New: ICE with __real__ and implicit type conversion
The following testcase triggers an ICE since at least GCC 2.95.3:
=
struct A
{
operator int();
};
int i = __real__ A();
=
bug.cc:6: internal compiler error: in add_builtin_candidate, at cp/call.c:1979
Please submit a full bug report, [etc.]
The code is probably invalid, but I'm not sure.
--
Summary: ICE with __real__ and implicit type conversion
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug c/28502] New: ICE with invalid declaration after definition
The following testcase triggers an ICE since at least GCC 2.95.3:
=
void foo() {}
void foo(void[]);
=
bug.c:2: error: declaration of 'type name' as array of voids
bug.c:2: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in validate_proto_after_old_defn, at c-decl.c:1087
Please submit a full bug report, [etc.]
Will post a patch soon.
--
Summary: ICE with invalid declaration after definition
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28502
[Bug c/28503] New: ICE on invalid arguments for inline-asm
The following testcase triggers an ICE since at least GCC 2.95.3:
=
void i;
void foo()
{
__asm__ ( : +r (i));
}
=
bug.c: In function 'foo':
bug.c:5: internal compiler error: in gimplify_expr, at gimplify.c:5902
Please submit a full bug report, [etc.]
The C++ frontend emits a proper error message.
--
Summary: ICE on invalid arguments for inline-asm
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28503
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 --- (In reply to comment #6) This _is_ plain ANSI C89. ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the #---but what of it? It's good practice anyhow to place the mark first, and the Tru64 compiler isn't exactly alone in enforcing this convention. (Is there _any_ good reason for having the whitespace? I don't mean a defense of but the standard allows it, your compiler sucks---I mean, a hard, technical reason for doing it that way instead of placing the # first?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #6 from tbm at cyrius dot com 2006-07-26 20:58 --- Created an attachment (id=11952) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11952action=view) test case Testcase from application yorick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
Re: [Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 --- (In reply to comment #6) This _is_ plain ANSI C89. ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the #---but what of it? It's good practice anyhow to place the mark first, and the Tru64 compiler isn't exactly alone in enforcing this convention. ISO C90 is ANSI C89 :). -- Pinski
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #8 from pinskia at physics dot uc dot edu 2006-07-26 20:59 --- Subject: Re: Bogus whitespace in preprocessor directives breaks bootstrap --- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 --- (In reply to comment #6) This _is_ plain ANSI C89. ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the #---but what of it? It's good practice anyhow to place the mark first, and the Tru64 compiler isn't exactly alone in enforcing this convention. ISO C90 is ANSI C89 :). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
