[dba-issues] [Issue 91091] active database is not hig hlighted in table data toolbar
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=91091 Issue #|91091 Summary|active database is not highlighted in table data toolb |ar Component|Database access Version|OOo 2.4.0 Platform|PC URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|none Assigned to|dbaneedsconfirm Reported by|mlebek --- Additional comments from [EMAIL PROTECTED] Thu Jun 26 08:21:15 + 2008 --- If i open the table data toolbar in writer, the active database should be highlighted and focused. But only the first entry is highlighted/focused. The active db is bold but not highlighted/focused. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR jakub at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR dodji at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR dodji at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR dodji at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR jakub at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR jakub at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR jakub at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR rguenth at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR dodji at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR dodji at gcc dot gnu dot org [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR jakub at gcc dot gnu dot org Reply via email to
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #10 from ubizjak at gmail dot com 2008-06-26 07:05 --- (In reply to comment #9) > So, do you think I need to exclude all along '-fPIC' for the other platform > specific builds of 4.3.1? I tried to compile latest 4.3.x SVN branch for i686-pc-linux-gnu with CFLAGS="-O2 -fPIC" and it worked OK. Same with trunk SVN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #18 from jakub at gcc dot gnu dot org 2008-06-26 08:01 --- You can reproduce it with a cross compiler too. Just use 4.3 branch (IMHO unrelated changes on the trunk made this bug latent) and don't combine everything into the same file. The #c12 program+routines have to be in one file, #c13 in a different one. The latter is miscompiled, if you are on ia64, you can compile the former with any optimization options, the latter with -O2, link, run. If you have just a cross compiler, just compile the #c13 source and inspect the assembly (look at ld4.a: addl r41 = @ltoff(slate_#), r1 ... adds r14 = 60, r41 ... .mmi mov r44 = r14 mov r50 = r15 mov r59 = r14 ... ! Instructions that don't modify r44 nor r59, no labels .mmi ld4.a r18 = [r44] ! *r44 aka slate_.k is uninitialized here, 0x20202020 st4 [r59] = r14, -60 ! This stores 1 into slate_.k adds r16 = 48, r41 and look at the *.compgotos dump that right before scheduling that slate_.k = 1 preceeded the prephitmp.78 (== r18) = slate_.k load, while after scheduling it is the other way around. The alias set looks correct for both MEMs (4) and MEM_EXPR/MEM_OFFSET etc. too, so IMHO if alias.c was asked if the two MEMs can overlap, it would certainly say so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #19 from jakub at gcc dot gnu dot org 2008-06-26 08:41 --- To be more precise, the problem is in speculating conditional store: ld4.a r18 = [r44] st4 [r59] = r14, -60 ... cmp4.ge p6, p7 = r22, r18 (p7) ld4 r14 = [r62] ... (p7) st4 [r77] = r14 chk.a.clr r18, .L69 .L70: ... .L69: ld4 r18 = [r44] ;; cmp4.ge p6, p7 = r22, r18 ;; (p7) ld4 r14 = [r62] ;; (p7) st4 [r77] = r14 br .L70 Now, ld4.a returns the stale value in r18 (0x20202020), $r22 is 2 and so in the code before chk.a.clr p7 is 1, so [r62] is loaded into r14 and stored into [r77] (i.e. MR = M in IF (K.GT.M1) MR = M is executed). Then chk.a.clr realizes the [r44] memory changed, so branches to .L69 to do the speculated stuff again. This time r18 is 1, so p7 will be 0 and MR = M is not done. But this really doesn't and can't undo the st4 [r77] = r14 store that already happened before chk.a.clr and wasn't supposed to happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #20 from maxim at codesourcery dot com 2008-06-26 09:21 --- Subject: Re: [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64 jakub at gcc dot gnu dot org wrote: > --- Comment #19 from jakub at gcc dot gnu dot org 2008-06-26 08:41 > --- > To be more precise, the problem is in speculating conditional store: > ld4.a r18 = [r44] > st4 [r59] = r14, -60 > ... > cmp4.ge p6, p7 = r22, r18 > (p7) ld4 r14 = [r62] > ... > (p7) st4 [r77] = r14 > chk.a.clr r18, .L69 > .L70: > ... > .L69: > ld4 r18 = [r44] > ;; > cmp4.ge p6, p7 = r22, r18 > ;; > (p7) ld4 r14 = [r62] > ;; > (p7) st4 [r77] = r14 > br .L70 > > Now, ld4.a returns the stale value in r18 (0x20202020), $r22 is 2 and so in > the > code before chk.a.clr p7 is 1, so [r62] is loaded into r14 and stored into > [r77] > (i.e. MR = M in IF (K.GT.M1) MR = M is executed). > Then chk.a.clr realizes the [r44] memory changed, so branches to .L69 to do > the > speculated stuff again. This time r18 is 1, so p7 will be 0 and MR = M is not > done. But this really doesn't and can't undo the st4 [r77] = r14 store that > already happened before chk.a.clr and wasn't supposed to happen. Oh, now I see the problem. I need some time to check what the best fix would be. Probably, the fix will be to exclude predicated instructions from speculation set, but I'd like to consider alternatives. Thanks, Maxim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #21 from mkuvyrkov at gcc dot gnu dot org 2008-06-26 09:23 --- Assign to self -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-06-24 15:04:50 |2008-06-26 09:23:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #25 from rguenther at suse dot de 2008-06-26 09:33 --- Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above On Thu, 26 Jun 2008, aoliva at gcc dot gnu dot org wrote: > --- Comment #24 from aoliva at gcc dot gnu dot org 2008-06-26 00:33 > --- > It's not just the result type that changed. You actually changed the type of > the variable created to hold the group of bit fields, out of which we further > extract members that were not mapped to separate variables. This might affect > bitfield simplifications based on mode size rather than type width. I can't > say that's it, but I know I may have based some code on this assumption that > you broke. > > It also seems to me that this change to the base type of the variable breaks > sra_build_elt_assignment(), because the by-design conditions might no longer > be > met. Finally, I don't see how you could assume that the else block for the if > full-width bit-field could be extracted with as little as a cast. > > This is what jumped at me at first. I haven't actually built compilers based > on the state before and after your patch to tell whether that's it, but these > are the most likely culprits. > > I hope this helps, No, sorry. Please point me to the place where I changed the type of the variable created to hold the group of bit fields. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug target/35965] -fstack-protector produces segfaulting binaries on arm/armel
--- Comment #4 from jules at gcc dot gnu dot org 2008-06-26 10:10 --- I've posted a candidate fix: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01641.html -- jules at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jules at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-26 10:10:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35965
[Bug inline-asm/36639] pointer referenced in asm statement not regarded as VUSE
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-26 10:15 --- I wasn't able to follow your example, but eventually this "bug" is fixed with the call-clobber reorganize patch? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36639
[Bug ada/36562] gnatmake not processing shared library projects
--- Comment #2 from sam at gcc dot gnu dot org 2008-06-26 10:17 --- Fixed in SVN trunk, thanks Chris for the patch. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36562
[Bug rtl-optimization/36635] [4.4 Regression] cc1 segfault from svn 137122
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-26 10:25 --- Confirmed. We endlessly recurse in cse_cc_succs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |rtl-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2008-06-26 10:25:28 date|| Summary|cc1 segfault from svn 137122|[4.4 Regression] cc1 ||segfault from svn 137122 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36635
[Bug middle-end/36554] [4.4 regression] verify_flow_info ICE can not throw but has EH edges
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-06-26 11:02 --- The new forward_propagate_comparison in tree-ssa-forwprop.c screws up the CFG: : D.1416_13 = v_1(D) != v_1(D); is_nan_6 = (const boolean) D.1416_13; D.1402_28 = v_1(D) > 1.79769313486231570814527423731704356798070567526e+308; : is_p_inf_22 = (const boolean) D.1402_28; D.1403_29 = v_1(D) < -1.79769313486231570814527423731704356798070567526e+308; : is_m_inf_36 = (const boolean) D.1403_29; is turned into : is_nan_6 = v_1(D) != v_1(D); : is_p_inf_22 = v_1(D) > 1.79769313486231570814527423731704356798070567526e+308; : is_m_inf_36 = v_1(D) < -1.79769313486231570814527423731704356798070567526e+308; without any EH updating. The idiom used in tidy_after_forward_propagate_addr /* We may have turned a trapping insn into a non-trapping insn. */ if (maybe_clean_or_replace_eh_stmt (stmt, stmt) && tree_purge_dead_eh_edges (bb_for_stmt (stmt))) cfg_changed = true; wouldn't be sufficient here because statements are removed (is it really the job of the pass to remove statements?) But all this mess stems again from the non-canonical "boolean" type of Ada so it's probably worth trying to make it canonical at last... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36554
[Bug middle-end/36554] [4.4 regression] verify_flow_info ICE can not throw but has EH edges
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-06-26 11:19 --- The fix would be to not propagate the comparisons if they can throw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36554
[Bug c++/36628] [c++0x] incorrect decltype() handling of conditional operator
--- Comment #2 from abarbati at iaanus dot com 2008-06-26 11:39 --- After a more careful reading of 5/5, 5.16/4 and 7.1.6.2/4, I believe that gcc is correctly handling the int& case, that is the expected output should be: FivE FRivE FivE Only the int&& case is thus incorrect, according to my interpretation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36628
[Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer
--- Comment #2 from irar at il dot ibm dot com 2008-06-26 11:57 ---
For access function (short int) {(short unsigned int) i_44, +, 1}_1)
evolution_part_in_loop_num() returns NULL, which causes the failure.
I tried to peel NOP_EXPRs from POLYNOMIAL_CHRECs in
evolution_part_in_loop_num(), but it caused lots of testsuite failures, and I
am not sure this is the correct way.
The access function is for vectorizer created calculation of peeling needed for
misaligned access:
:
# ivtmp.42_89 = PHI
# ivtmp.41_87 = PHI
# ivtmp.34_78 = PHI
# i_18 = PHI
D.1578_4 = (long unsigned int) i_18;
D.1579_5 = D.1578_4 + -1;
D.1580_7 = x_6(D) + D.1579_5;
D.1581_9 = x_6(D) + D.1578_4;
vect_var_.35_80 = M*ivtmp.34_78{misalignment: 0};
D.1582_10 = *D.1581_9;
*ivtmp.41_87 = vect_var_.35_80;
i.0_11 = (short unsigned int) i_18;
D.1584_12 = i.0_11 + 1;
i_13 = (short int) D.1584_12;
ivtmp.34_79 = ivtmp.34_78 + 16;
ivtmp.41_88 = ivtmp.41_87 + 16;
ivtmp.42_90 = ivtmp.42_89 + 1;
if (ivtmp.42_90 < bnd.26_52)
goto ;
else
goto ;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36630
[Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer
--- Comment #3 from rguenther at suse dot de 2008-06-26 12:11 ---
Subject: Re: [4.3/4.4 Regression] ICE in
vect_update_ivs_after_vectorizer
On Thu, 26 Jun 2008, irar at il dot ibm dot com wrote:
> --- Comment #2 from irar at il dot ibm dot com 2008-06-26 11:57 ---
> For access function (short int) {(short unsigned int) i_44, +, 1}_1)
> evolution_part_in_loop_num() returns NULL, which causes the failure.
>
> I tried to peel NOP_EXPRs from POLYNOMIAL_CHRECs in
> evolution_part_in_loop_num(), but it caused lots of testsuite failures, and I
> am not sure this is the correct way.
Well, the problem is that an unsigned induction variable may validly
wrap while a signed induction variable may not. This is probably the
cause of the testsuite failures. Can't you simply handle a NULL return
from evolution_part_in_loop_num in the vectorizer?
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36630
[Bug other/31754] Include column number along line in error messages main.cpp:5:38
--- Comment #8 from dseketel at redhat dot com 2008-06-26 12:38 --- Created an attachment (id=15817) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15817&action=view) correct issues raised by reviews on the mailing list I have corrected the issues raised at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01552.html. I have also refreshed the patch against trunk of 2008-06-25. -- dseketel at redhat dot com changed: What|Removed |Added Attachment #15793|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
[Bug libgcj/36640] New: Build gcc-4.2.1 release fails when configured with --with-xmlj using Sun's ld
I desire to replace my OS's gcc toolchain with a newer version since the one supplied by the manufacturer is a little old (and missing some languages). I am compiling gcc-4.2.1 (release from ftp://mirrors.kernel.org/gnu/). Sun's gcc (not used during build): # gcc -v Reading specs from /user/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs Configured with: /builds/sfwnv-86/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc --enable shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-20050802) Linker used during build: # /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.622 GCC used to build (From BlastWave): # gcc -v Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/specs Target: i386-pc-solaris2.8 Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --with-system-zlib --enable-languages=c,c++,f95,java,objc,ada Thread model: posix gcc version 4.0.2 Failing configure command: /opt/gcc-4.2.1/configure --build=i386-pc-solaris2.11 --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared --enable-threads=posix --enable-libada --enable-libssp --enable-libmudflap --enable-libgomp --enable-decimal-float --with-x --x-includes=/usr/include/X11 --x-libraries=/usr/X11/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-gconf-peer --with-stabs --enable-stage1-checking=release --enable-multilib --enable-nls --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --enable-xmlj The reason I am using the "--without-gnu-ld --with-ld=/usr/ccs/bin/ld" option is because the Solaris OS supplied gcc (configured by SUN) (and other gcc's such as BlastWave's) all seem to use it. It seems reasonable to follow the manufacturers advice if you are going to replace the OS's system compiler. It may well be true (or not) that _after_ I successfully build a newer gcc that I should compile a newer binutils and use that -- but building the newer gcc with the 'recommended' linker is what I desire to do (for now). If I configure without "--enable-xmlj" the build (or if you prefer Sun's ld) works. If I configure using "--enable-xmlj" I get a relocation error in gnu-xml concerning debug_info (so it seems we could fix one small section and get everything to work). Here is a portion of my build log: # grep -B 10 -A 2 LASF7986 /opt/gcc-4.2.1-build-1/made_1j_log.txt mkdir .libs/libgcj.lax/libffi_convenience.a (cd .libs/libgcj.lax/libffi_convenience.a && /usr/sfw/i386-pc-solaris2.11/bin/ar x /opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava/../libffi/.libs/libffi_convenience.a) rm -fr .libs/libgcj.lax/libzgcj_convenience.a mkdir .libs/libgcj.lax/libzgcj_convenience.a (cd .libs/libgcj.lax/libzgcj_convenience.a && /usr/sfw/i386-pc-solaris2.11/bin/ar x /opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava/../zlib/.libs/libzgcj_convenience.a) rm -fr .libs/libgcj.lax/libgcjgc_convenience.a mkdir .libs/libgcj.lax/libgcjgc_convenience.a (cd .libs/libgcj.lax/libgcjgc_convenience.a && /usr/sfw/i386-pc-solaris2.11/bin/ar x /opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava/../boehm-gc/.libs/libgcjgc_convenience.a) /opt/gcc-4.2.1-build/./gcc/xgcc -shared-libgcc (HUGE command deleted) /i386-pc-solaris2.11/../../../i386-pc-solaris2.11/lib -L/usr/sfw/lib/gcc/i386-pc-solaris2.11/../.. -lgcc_s -lgcc_s -lc /opt/gcc-4.2.1-build/./gcc/crtend.o /usr/lib/crtn.o -Wl,-h -Wl,libgcj.so.8 -o .libs/libgcj.so.8.0.0 ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF7985: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF7986: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF7987: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF40: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored (The errors continue for over 2 lines, finally ending with this:) /i386-pc-solaris2.11/../../../i386-pc-solaris2.11/lib -L/usr/sfw/lib/gcc/i386-pc-solaris2.11/../.. -lgcc_s -lgcc_s -lc /opt/gcc-4.2.1-build/./gcc/crtend.o /usr/lib/crtn.o -Wl,-h -Wl,libgcj.so.8 -o .libs/libgcj.so.8.0.0 ld: warning:
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #11 from imam dot toufique at intel dot com 2008-06-26 15:58 --- (In reply to comment #10) > (In reply to comment #9) > > So, do you think I need to exclude all along '-fPIC' for the other platform > > specific builds of 4.3.1? > I tried to compile latest 4.3.x SVN branch for i686-pc-linux-gnu with > CFLAGS="-O2 -fPIC" and it worked OK. Same with trunk SVN. How did you fetch the 4.3.1 SVN branch? Do I have to put a specific revision # for fetching that. I took the latest rev. (4.4.0 experimental) and it worked OK. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #12 from ubizjak at gmail dot com 2008-06-26 17:45 --- (In reply to comment #11) > > I tried to compile latest 4.3.x SVN branch for i686-pc-linux-gnu with > > CFLAGS="-O2 -fPIC" and it worked OK. Same with trunk SVN. > > How did you fetch the 4.3.1 SVN branch? Do I have to put a specific revision > # > for fetching that. I took the latest rev. (4.4.0 experimental) and it worked > OK. Thanks. Please read instructions at http://gcc.gnu.org/svn.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug libgcj/36640] Build gcc-4.2.1 release fails when configured with --with-xmlj using Sun's ld
--- Comment #1 from rob1weld at aol dot com 2008-06-26 17:52 --- Correction: The "finally ending with this" section should read: --- .LPR2 0x123aa1.libs/gnu-xml.o .LPR2 0x123ba1.libs/gnu-xml.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make[3]: *** [libgcj.la] Error 1 make[3]: Leaving directory `/opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/opt/gcc-4.2.1-build' make: *** [all] Error 2 --- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36640
[Bug inline-asm/36639] pointer referenced in asm statement not regarded as VUSE
--- Comment #4 from aoliva at gcc dot gnu dot org 2008-06-26 18:10 --- I have not tried 4.4. Anyhow, I have looked further into this issue, and I came to the conclusion that a memory clobber (that should have always been there anyway) will get things right. I cannot tell for sure that it guarantees GCC will not ever get smart and delete the initializer because it cannot see that it is used (the ASM needs not be a VUSE if it is marked as using only the pointer, after all), but I find it unlikely that this will ever break. So, nevermind... Just another case of inlining exposing latent problems. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36639
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #26 from aoliva at gcc dot gnu dot org 2008-06-26 18:13 --- The place where you said you were just changing the type of the result. Note that it's that type that determines the type of the scalar variable created to hold the group. If it differs from the expected type, the type of the BIT_FIELD_EXPR is adjusted *after* the temporary is created in instantiate_missing_elements_1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer
--- Comment #4 from irar at il dot ibm dot com 2008-06-26 18:33 ---
(In reply to comment #3)
> Can't you simply handle a NULL return
> from evolution_part_in_loop_num in the vectorizer?
The problem is that this happens during the transformation (for the code
created by the vectorizer). We assume that all the checks were done during the
analysis phase, and don't expect anything to go wrong during the
transformation. This is why there is an assert that the evolution is not NULL.
But, anyway, shouldn't evolution_part_in_loop_num return a valid value for
(short int) {(short unsigned int) i_44, +, 1}_1?
Ira
> Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36630
[Bug c++/36641] New: erroneous ambiguous error for subclasses overloaded templated interfaces
---Offending Code---
#include
class Foo
{
};
class Bar
{
};
template
class Handler
{
public:
virtual void handle(A*) = 0;
};
class Baz : public Handler,
public Handler
{
};
class Foobar : public Baz
{
public:
virtual void handle(Bar* bar)
{
std::cout << "handle bar" << std::endl;
}
virtual void handle(Foo* foo)
{
std::cout << "handle foo" << std::endl;
}
};
int main()
{
Foo* foo = new Foo();
Baz* baz = new Foobar();
baz->handle(foo);
return 0;
}
--- compilation command ---
g++ test.cpp
--- compiler error ---
test.cpp: In function int main():
test.cpp:45: error: request for member handle is ambiguous
test.cpp:18: error: candidates are: void Handler::handle(A*) [with A = Bar]
test.cpp:18: error: void Handler::handle(A*) [with A = Foo]
--- notes ---
This error doesn't happen if Foobar doesn't exist and the interfaces are
implemented in Baz.
--
Summary: erroneous ambiguous error for subclasses overloaded
templated interfaces
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot clarke at techsmith dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36641
[Bug c++/36641] erroneous ambiguous error for subclasses overloaded templated interfaces
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-26 19:07 --- This is how C++ works IIRC. If two functions with the same name are inherited from two different classes, they are considered ambiguous. If you use a non template version of Handler you will also see it is the same issue. Anyways adding: using Handler::handle; using Handler::handle; To Baz, cause the ambiguous to go away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36641
[Bug c++/36642] New: Problem with non matching template args in tr1_impl/hashtable
I think there may be two issues here demonstrated in the code below. The
example code is distilled from ./include/c++/4.3.0/tr1_imp/hashtable. GCC
compiles this code without a diagnostic, but both the Intel and Microsoft
compilers diagnose an error with too few template args for __detail::_Map_base'
:
% cl -c t.cpp -nologo
t.cpp
t.cpp(10) : error C2976: '__detail::_Map_base' : too few template arguments
t.cpp(4) : see declaration of '__detail::_Map_base'
% cat t.cpp
namespace __detail
{
template struct _Map_base { };
}
struct _Hashtable
{
template
friend struct __detail::_Map_base;
};
So, you may want to fix the template in and/or try to
diagnose this case in the compilation.
--
Summary: Problem with non matching template args in
tr1_impl/hashtable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff dot sullivan at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36642
[Bug c++/36642] Problem with non matching template args in tr1_impl/hashtable
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-26 19:42 --- (In reply to comment #0) > I think there may be two issues here demonstrated in the code below. The > example code is distilled from ./include/c++/4.3.0/tr1_imp/hashtable. To be clear: the example code is *not* distilled from the 4.3.0 library. The problem has been fixed long ago (2008-01-09) and is not present in 4_3-branch neither in mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36642
[Bug libstdc++/36643] New: make check error:FAIL: abi_check
Get a error while running make check within or out of the libstdc++-v3/testsuite. I'm using Debian Etch on PC. I'm building gcc 4.3.1 Debian Etch. so i'm stuck at make check. Here's the log: === libstdc++ tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... FAIL: abi_check Running /home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... . === libstdc++ Summary === # of expected passes4936 # of unexpected failures3 # of unexpected successes 1 # of expected failures 59 # of unsupported tests 326 make[1]: *** [check-DEJAGNU] Error 1 make[1]: Leaving directory `/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/testsuite' make: *** [check-am] Error 2 -- Summary: make check error:FAIL: abi_check Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dtom77 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=36643
[Bug libstdc++/36644] New: make check fails:FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors)
Running make check fails after executing make. Shows two errors while installing gcc version 4.3.1 I'm using Debian Etch on PC. stuck at make check. === libstdc++ tests === Schedule of variations: unix Running /home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors) FAIL: tr1/8_c_compatibility/cmath/overloads.cc (test for excess errors) === libstdc++ Summary === # of expected passes4936 # of unexpected failures3 # of unexpected successes 1 # of expected failures 59 # of unsupported tests 326 make[1]: *** [check-DEJAGNU] Error 1 make[1]: Leaving directory `/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/testsuite' make: *** [check-am] Error 2 And libstdc++.log: -include bits/stdc++.h Executing on host: /home/ad/dloads/gcc-4.3.1/build/./gcc/g++ -shared-libgcc -B/home/ad/dloads/gcc-4.3.1/build/./gcc -nostdinc++ -L/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/src -L/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/opt/gcc-4.3.1/i686-pc-linux-gnu/bin/ -B/opt/gcc-4.3.1/i686-pc-linux-gnu/lib/ -isystem /opt/gcc-4.3.1/i686-pc-linux-gnu/include -isystem /opt/gcc-4.3.1/i686-pc-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/include -I/home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/libsupc++ -I/home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/include/backward -I/home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/testsuite/util /home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/testsuite/tr1/8_c_compatibility/cmath/functions.cc -include bits/stdc++.h -S -o functions.s(timeout = 600) /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: symbol lookup error: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: undefined symbol: mpfr_remainder compiler exited with status 1 output is: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: symbol lookup error: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: undefined symbol: mpfr_remainder FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors) Excess errors: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: symbol lookup error: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: undefined symbol: mpfr_remainder extra_tool_flags are: -include bits/stdc++.h Executing on host: /home/ad/dloads/gcc-4.3.1/build/./gcc/g++ -shared-libgcc -B/home/ad/dloads/gcc-4.3.1/build/./gcc -nostdinc++ -L/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/src -L/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/opt/gcc-4.3.1/i686-pc-linux-gnu/bin/ -B/opt/gcc-4.3.1/i686-pc-linux-gnu/lib/ -isystem /opt/gcc-4.3.1/i686-pc-linux-gnu/include -isystem /opt/gcc-4.3.1/i686-pc-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/home/ad/dloads/gcc-4.3.1/build/i686-pc-linux-gnu/libstdc++-v3/include -I/home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/libsupc++ -I/home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/include/backward -I/home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/testsuite/util /home/ad/dloads/gcc-4.3.1/gcc-4.3.1/libstdc++-v3/testsuite/tr1/8_c_compatibility/cmath/overloads.cc -include bits/stdc++.h -S -o overloads.s(timeout = 600) /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: symbol lookup error: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: undefined symbol: mpfr_remainder compiler exited with status 1 output is: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: symbol lookup error: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: undefined symbol: mpfr_remainder FAIL: tr1/8_c_compatibility/cmath/overloads.cc (test for excess errors) Excess errors: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: symbol lookup error: /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: undefined symbol: mpfr_remainder -- Summary: make check fails:FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors) Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dtom77 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/bugz
[Bug libstdc++/36643] make check error:FAIL: abi_check
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-26 20:14 --- (In reply to comment #0) > # of unsupported tests 326 This tells you that you don't have the required localedata installed, and the abi-check is bound to fail: http://gcc.gnu.org/onlinedocs/libstdc++/manual/build.html#build.prereq -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36643
[Bug c++/36644] make check fails:FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors)
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-26 20:16 --- (In reply to comment #0) > Excess errors: > /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: symbol lookup error: > /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: undefined symbol: > mpfr_remainder If anything, this is not a libstdc++ issue. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36644
[Bug c++/36642] Problem with non matching template args in tr1_impl/hashtable
--- Comment #2 from paolo dot carlini at oracle dot com 2008-06-26 20:45 --- *** This bug has been marked as a duplicate of 34724 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36642
[Bug c++/34724] Trouble with friend declaration across namespaces
--- Comment #2 from paolo dot carlini at oracle dot com 2008-06-26 20:45 --- *** Bug 36642 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jeff dot sullivan at intel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34724
[Bug c++/36625] bogus error on __attribute__((aligned(N))) in template code
--- Comment #3 from sebor at roguewave dot com 2008-06-26 20:46 ---
Oddly enough, doubling up on the parens around N works:
template
struct A { struct S { short f[3]; } __attribute__ ((aligned ((N; };
int main ()
{
A<123>::S s;
}
--
sebor at roguewave dot com changed:
What|Removed |Added
Summary|missing diagnostic on |bogus error on
|invalid |__attribute__((aligned(N)))
|__attribute__((aligned(N))) |in template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
[Bug target/36644] make check fails:FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors)
--- Comment #2 from paolo dot carlini at oracle dot com 2008-06-26 20:48 --- Let's tentatively recategorize as target: certainly doesn't happen on x86_64. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36644
[Bug c++/36645] New: Friend class template declaration does not check for matching template parameters
The friend declaration should be rejected because the template parameter list
does not match the template definition in __detail. If the friend declaration
appears in the same namespace as the original template and does not use a
qualified name, the expected error is issued.
namespace __detail
{
template struct _Map_base { };
}
struct _Hashtable
{
template
friend struct __detail::_Map_base;
};
--
Summary: Friend class template declaration does not check for
matching template parameters
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jhs at edg dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36645
[Bug c++/16517] warn about variables that are only ever assigned to, but never read
--- Comment #4 from ghazi at gcc dot gnu dot org 2008-06-26 20:51 --- This is a valid feature request... -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16517
[Bug c++/16517] warn about variables that are only ever assigned to, but never read
--- Comment #5 from ghazi at gcc dot gnu dot org 2008-06-26 20:52 --- but it is a dup... *** This bug has been marked as a duplicate of 18624 *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16517
[Bug c/18624] GCC does not detect local variable set but never used
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-06-26 20:52 --- *** Bug 16517 has been marked as a duplicate of this bug. *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||tneumann at pi3 dot ||informatik dot uni-mannheim ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624
[Bug c++/36645] Friend class template declaration does not check for matching template parameters
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-26 20:53 --- *** This bug has been marked as a duplicate of 34724 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36645
[Bug c++/34724] Trouble with friend declaration across namespaces
--- Comment #3 from paolo dot carlini at oracle dot com 2008-06-26 20:53 --- *** Bug 36645 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jhs at edg dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34724
[Bug testsuite/29071] gcc.dg/20020919-1.c compilation test fails on powerpc-apple-darwin8 at -m64
--- Comment #5 from dominiq at lps dot ens dot fr 2008-06-26 21:21 --- Could the patch in comment #4 be commited? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29071
[Bug target/36644] make check fails:FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors)
--- Comment #3 from dtom77 at gmail dot com 2008-06-26 21:26 --- Subject: Re: make check fails:FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors) On Thursday 26 June 2008 16:48, paolo dot carlini at oracle dot com wrote: > --- Comment #2 from paolo dot carlini at oracle dot com 2008-06-26 > 20:48 --- Let's tentatively recategorize as target: certainly doesn't > happen on x86_64. Actually i'm using amd64 with 32bit Linux OS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36644
[Bug c/36629] ICE in _lshrdi3 when compiling 06/20/08 snapshot on x86_64
--- Comment #1 from hjl dot tools at gmail dot com 2008-06-26 21:27 --- I think it is fixed by http://gcc.gnu.org/ml/gcc-cvs/2008-06/msg00759.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36629
[Bug testsuite/29071] gcc.dg/20020919-1.c compilation test fails on powerpc-apple-darwin8 at -m64
--- Comment #6 from dominiq at lps dot ens dot fr 2008-06-26 21:29 --- Forgot to say that I also see this pr on powerpc-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29071
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #13 from imam dot toufique at intel dot com 2008-06-26 21:56 --- (In reply to comment #12) > (In reply to comment #11) > > > I tried to compile latest 4.3.x SVN branch for i686-pc-linux-gnu with > > > CFLAGS="-O2 -fPIC" and it worked OK. Same with trunk SVN. > > > > How did you fetch the 4.3.1 SVN branch? Do I have to put a specific > > revision # > > for fetching that. I took the latest rev. (4.4.0 experimental) and it > > worked > > OK. Thanks. > Please read instructions at http://gcc.gnu.org/svn.html Hello, I just tried the 4.3_branch release of gcc with the CFFLAGS='-02 -fPIC' option. It seem to fail now in libiberty/md5.c Here is the error: --snip-- In file included from ../../../gcc-4.3/libiberty/md5.c:40: ../../../gcc-4.3/libiberty/../include/md5.h:85: error: expected ?:?, ?,?, ?;?, ?}? or ?__attribute__? before ?ATTRIBUTE_ALIGNED_ALIGNOF ../../../gcc-4.3/libiberty/md5.c: In function ?md5_finish_ctx?: ../../../gcc-4.3/libiberty/md5.c:110: error: ?struct md5_ctx? has no member named ?buffer? ../../../gcc-4.3/libiberty/md5.c:113: error: ?struct md5_ctx? has no member named ?buffer? ../../../gcc-4.3/libiberty/md5.c:114: error: ?struct md5_ctx? has no member named ?buffer? ../../../gcc-4.3/libiberty/md5.c:118: error: ?struct md5_ctx? has no member named ?buffer? ../../../gcc-4.3/libiberty/md5.c: In function ?md5_process_bytes?: ../../../gcc-4.3/libiberty/md5.c:207: error: ?struct md5_ctx? has no member named ?buffer? ../../../gcc-4.3/libiberty/md5.c:212: error: ?struct md5_ctx? has no member named ?buffer? ../../../gcc-4.3/libiberty/md5.c:214: error: ?struct md5_ctx? has no member named ?buffer? ../../../gcc-4.3/libiberty/md5.c:214: error: ?struct md5_ctx? has no member named ?buffer? ../../../gcc-4.3/libiberty/md5.c:251: error: ?struct md5_ctx? has no member named ?buffer? gmake[3]: *** [md5.o] Error 1 --snip-- I am using SLES 9 32-bit system to do this build. any suggestions? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug target/36634] -msecure-plt combine gives invalid call insn
--- Comment #1 from amodra at bigpond dot net dot au 2008-06-27 01:52
---
(insn 9 8 11 1 (set (reg/v/f:SI 119 [ p ])
(mem/u/c:SI (plus:SI (reg:SI 30 30)
(const:SI (minus:SI (symbol_ref/u:SI ("*.LC2") [flags 0x2])
(symbol_ref:SI ("*.LCTOC1") [5 S4 A8])) -1 (nil)
(expr_list:REG_EQUAL (symbol_ref:SI ("myprint") [flags 0x1] )
(nil)))
[snip]
(call_insn 12 11 13 1 (parallel [
(call (mem:SI (reg/v/f:SI 119 [ p ]) [0 S4 A8])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
]) -1 (nil)
(nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 3 3))
(nil)))
The first instruction is a GOT load of the function address, the second an
indirect call. No problem there. Indirect calls for -msecure-plt don't need
the GOT pointer to be valid.
The trouble occurrs when combine substitutes the first insn into the second to
get:
(call_insn 12 11 13 0 (parallel [
(call (mem:SI (symbol_ref:SI ("myprint") [flags 0x1] ) [0 S4 A8])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
]) 402 {*call_nonlocal_sysv} (insn_list:REG_DEP_TRUE 11 (nil))
(expr_list:REG_UNUSED (scratch:SI)
(expr_list:REG_DEAD (reg:SI 3 3)
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 3 3))
(nil)))
Note that lack of anything marking r30 as used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
[Bug tree-optimization/36646] New: [4.4 regression] Unnecessary moves generated on loop boundaries
The attached source is a loop+switch statement, where only some of the switch cases change the variable 'val'. 4.4 generates moves for it in every case, even the ones where it's not mentioned, while 4.2 didn't; the difference is visible in tree dumps. This part: case Op_Inc1: (*tape)++; break; with 4.2 at -O: :; *tape = *tape + 1; goto (); L5: incb(%edx) jmp L13 SVN at -O: :; *tape.17 = *tape.17 + 1; val.16 = val; goto (); L6: incb(%esi) movl%edx, %eax jmp L10 Suprisingly, -O3 is worse: L6: movl%edx, %eax incb(%esi) movl%eax, %edx jmp L2 IRA doesn't improve it. This isn't from real-world code, so it's not really important, but I'd like to make a code-copying VM out of this. -- Summary: [4.4 regression] Unnecessary moves generated on loop boundaries Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: astrange at ithinksw dot com GCC target triplet: i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36646
[Bug tree-optimization/36646] [4.4 regression] Unnecessary moves generated on loop boundaries
--- Comment #1 from astrange at ithinksw dot com 2008-06-27 04:57 --- Created an attachment (id=15818) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15818&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36646
[Bug tree-optimization/36646] [4.4 regression] Unnecessary moves generated on loop boundaries
--- Comment #2 from astrange at ithinksw dot com 2008-06-27 05:04 --- Created an attachment (id=15819) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15819&action=view) svn 20080625 + -O compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36646
[Bug target/36644] make check fails:FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors)
--- Comment #4 from dtom77 at gmail dot com 2008-06-27 05:08 --- Subject: Re: make check fails:FAIL: tr1/8_c_compatibility/cmath/functions.cc (test for excess errors) On Thursday 26 June 2008 16:16, paolo dot carlini at oracle dot com wrote: > > > Excess errors: > > /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: symbol lookup error: > > /home/ad/dloads/gcc-4.3.1/build/./gcc/cc1plus: undefined symbol: > > mpfr_remainder > > If anything, this is not a libstdc++ issue. Then do you think it is on the mpfr side? I grep the directory where i installed it. Indeed mpfr.h has this mpfr_remainder() function. Don't know why this is referenced as undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36644
[Bug libstdc++/36647] New: configure script can not find out version of GNU ld 2.18
gcc-4.3.1/libgomp/configure and gcc-4.3.1/libstdc++-v3/configure
can not find out version of ld 2.18 (from GNU Binutils 2.18)
I have GNU ld 2.18 but when compiling gcc I get messages:
checking for ld version... 1800
...
and
configure: WARNING: === Linker version 1800 is too old for
...
I found that ld version is determined by (following lines from configure
scripts mentioned above)
...
ldver=`$LD --version 2>/dev/null | head -1 | \
sed -e 's/GNU ld \(version \)\{0,1\}\(([^)]*)
\)\{0,1\}\([0-9.][0-9.]*\).*/\3/'`
...
That gives:
$ echo $ldver
GNU ld (GNU Binutils) 2.18
whereas $ldver should be "2.18"
--
Summary: configure script can not find out version of GNU ld 2.18
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: YLitvinenko at astana dot oilfield dot slb dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36647
