[Bug fortran/32899] [4.3 regresssion] Broken diagnostic for invalid use of .eq. for logicals
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-26 08:14 --- Thanks Steve :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC|franke dot daniel at gmail |dfranke at gcc dot gnu dot |dot com |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32899
[Bug middle-end/32887] memset warning
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-26 07:50 --- It might be, can you attach the preprocessed source? Which you can find by adding -save-temps and it will be either end in .i or .ii. The difference in glibc versions could be cause different warnings to show up in some cases, I remember fixing statement with no effect for memset already in 4.2.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-07-26 08:41 --- Created an attachment (id=13985) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13985&action=view) Result on avr target from GCC 4.1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
[Bug middle-end/32887] memset warning
--- Comment #11 from cnstar9988 at gmail dot com 2007-07-26 08:13 --- Created an attachment (id=13981) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13981&action=view) (64bit)gcc -m32 -O3 -Wall test.c -save-temps (64bit)gcc -m32 -O3 -Wall test.c -save-temps In this platform, it's no warning. why these with no warning? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
[Bug middle-end/32887] memset warning
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-07-26 08:10 --- This is a bug in glibc version you are using, the warning is comming from the expansion of a #define. Looking at the expanded version, I see that glibc is violating C aliasing rules anyways so the code might not always work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data
--- Comment #2 from j at uriah dot heep dot sax dot de 2007-07-26 08:39 --- Created an attachment (id=13983) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13983&action=view) Result on i386 target from GCC 3.4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
[Bug fortran/31211] wrong code generated for pointer returning function as actual argument
--- Comment #7 from burnus at gcc dot gnu dot org 2007-07-26 09:49 --- > > Patch looks OK and regtests on x86-64. > That's strange - for me, it breaks ret_pointer_2.f90, at the statement print > *, > x(3) because the elements in the data transfer are incorrectly referenced. In the boot-strapped compiler of today I also get this failure (x86-64: -m32/-m64); I probably should always do the full bootstrap/check-gfortran(-m32/-m64) to make sure it really works :-/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-07-26 10:01 --- Well, honestly not. Still other frontends do not do return type promotion themselves, so the backend is responsible for doing this. Do you have any suggestion on what target to look at to verify this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug tree-optimization/32826] Reduction into a global variable causes a Load Hit Store Hazard (for the Cell)
--- Comment #2 from tehila at il dot ibm dot com 2007-07-26 10:46 --- (In reply to comment #2) Just want a clarification: I see you're compiling on PPU (since you're using -maltivec). Does this problematic also on SPU? Does SPU has this LHS hazard? Another question: lwz r0,-20(r1) < LHS hazard stw r0,lo16(_e)(r2) The problem here is these 2 insns, right? The store that is right after (or too close to) the load ? -- tehila at il dot ibm dot com changed: What|Removed |Added CC||tehila at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32826
[Bug c++/32900] [4.2/4.3 regression] compile time and memory regression
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-26 10:33 --- Maybe related to PR32891. -- 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=32900
[Bug middle-end/21137] Convert (a >> 2) & 1 != 0 into a & 4 != 0
--- Comment #11 from rask at gcc dot gnu dot org 2007-07-26 09:33 --- Reopening since this was only partially fixed. -- rask at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data
--- Comment #3 from j at uriah dot heep dot sax dot de 2007-07-26 08:40 --- Created an attachment (id=13984) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13984&action=view) Result on i386 arch from GCC 4.1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-26 09:14 --- Subject: Bug 32843 Author: rguenth Date: Thu Jul 26 09:13:58 2007 New Revision: 126950 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126950 Log: 2007-07-26 Richard Guenther <[EMAIL PROTECTED]> PR testsuite/32843 * testsuite/libffi.call/return_sc.c (main): Verify call result as signed char, not ffi_arg. Modified: trunk/libffi/ChangeLog trunk/libffi/testsuite/libffi.call/return_sc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug middle-end/32887] memset warning
--- Comment #12 from cnstar9988 at gmail dot com 2007-07-26 08:20 --- I want the warning. but why the warning is glibc's bug? because memset(x,19,0), is buggy code. I need the warning. -- cnstar9988 at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
[Bug fortran/31211] wrong code generated for pointer returning function as actual argument
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-26 09:20 --- (In reply to comment #5) > > This fixes the PR but is not regtested: > Patch looks OK and regtests on x86-64. That's strange - for me, it breaks ret_pointer_2.f90, at the statement print *, x(3) because the elements in the data transfer are incorrectly referenced. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
[Bug rtl-optimization/32747] [4.3 Regression] ICE segmentation fault or abort in combine on alpha
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2007-07-26 09:23 --- Fixed by: http://gcc.gnu.org/viewcvs?view=rev&revision=126942 r126942 | ian | 2007-07-26 04:27:34 +0400 (Thu, 26 Jul 2007) | 7 lines * combine.c (combine_max_regno): Remove. Remove all uses. (struct reg_stat_struct): Rename from struct reg_stat. (reg_stat_type): Define, and declare VECs. (reg_stat): Change from pointer to VEC. Change all uses. (combine_split_insns): New static function. (try_combine, find_split_point): Call it instead of split_insns. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32747
[Bug middle-end/32887] memset warning
--- Comment #7 from cnstar9988 at gmail dot com 2007-07-26 07:45 --- test.c:14: warning: statement with no effect So I think it is gcc warning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
[Bug c++/32900] [4.2/4.3 regression] compile time and memory regression
--- Comment #4 from pluto at agmk dot net 2007-07-26 10:53 --- (In reply to comment #3) > Maybe related to PR32891. > sip-qt problems == PR30052 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32900
[Bug middle-end/31979] ICE compiling openssl-0.9.8e/apps/ocsp.c
--- Comment #5 from drs at nrao dot edu 2007-07-26 14:48 --- I have exactly the same problem with gcc 4.2.1 on a powerpc osx system: oz:~/bug root# gcc -DMONOLITH -I. -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -DB_ENDIAN -c -o ocsp.o ocsp.c ocsp.c: In function 'ocsp_main': ocsp.c:579: warning: function called through a non-compatible type ocsp.c:579: note: if this code is reached, the program will abort ocsp.c:680: warning: function called through a non-compatible type ocsp.c:680: note: if this code is reached, the program will abort ocsp.c:761: warning: function called through a non-compatible type ocsp.c:761: note: if this code is reached, the program will abort ocsp.c:786: warning: function called through a non-compatible type ocsp.c:786: note: if this code is reached, the program will abort ocsp.c: In function 'do_responder': ocsp.c:1207: warning: function called through a non-compatible type ocsp.c:1207: note: if this code is reached, the program will abort ocsp.c: In function 'send_ocsp_response': ocsp.c:1229: warning: function called through a non-compatible type ocsp.c:1229: note: if this code is reached, the program will abort ocsp.c: In function 'ocsp_main': ocsp.c:904: internal compiler error: in move_insn, at haifa-sched.c:1963 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31979
[Bug java/32904] New: Typo in Base64.java's decode function
There is a typo in libjava/classpath/gnu/java/security/util/Base64.java's
decode function.
public static byte[] decode(final byte[] src, final int off, final int len)
{... }
The following loop ends up throwing an exception on correct input.
A "continue" line is missing, as shown below.
When the continue line is added, the function works correctly.
for (i = off; i < off + len; i++)
{
sbiCrop = (byte) (src[i] & 0x7F); // Only the low seven bits
sbiDecode = DECODABET[sbiCrop];
if (sbiDecode >= WHITE_SPACE_ENC)
{ // White space, Equals sign or better
if (sbiDecode >= EQUALS_SIGN_ENC)
{
b4[b4Posn++] = sbiCrop;
if (b4Posn > 3)
{
outBuffPosn += decode4to3(b4, 0, outBuff, outBuffPosn);
b4Posn = 0;
// If that was the equals sign, break out of 'for' loop
if (sbiCrop == EQUALS_SIGN)
break;
} // end if: quartet built
} // end if: equals sign or better
// ERROR HERE: The following line is missing.
// continue;
}
throw new IllegalArgumentException("Illegal BASE-64 character at #"
+ i + ": " + src[i] + "(decimal)");
}
--
Summary: Typo in Base64.java's decode function
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tjk at tksoft dot com
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32904
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #8 from belyshev at depni dot sinp dot msu dot ru 2007-07-26 19:48 --- Bug 32747 fixed, so I successfully bootstrapped r126943 (all languages minus java) with patch from comment #6 on alphaev56-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug tree-optimization/32891] [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-26 19:52 --- Created an attachment (id=13987) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13987&action=view) testcase Whoops - I have boot headers installed!? Try again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #13972|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
[Bug libstdc++/32907] Inefficent operator== in std::string and std::list
--- Comment #2 from chris at bubblescope dot net 2007-07-26 19:41 --- Ah, woops, many apologises. Too long since I've looked at list::size, I forgot which way around libstdc++ differed from the rest of the world :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
[Bug tree-optimization/32891] [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-26 20:21 --- Created an attachment (id=13988) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13988&action=view) preprocessed testcase (trunk) Note preprocessed source is incompatible wrt different gcc versions and so useless for a comparison. But especially for you - here's preprocessed source for trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
[Bug fortran/32909] New: Replace gfc_c_int_type_node with integer_type_node
The frontend creates a tree gfc_c_int_type_node in multiple places, to represent integers the same size as C int. This is unnecessary, as the same thing is found in the tree integer_type_node defined by the middle-end. Assigning this to myself. -- Summary: Replace gfc_c_int_type_node with integer_type_node Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: jb at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32909
[Bug fortran/31818] Wrongly accepts namelists with assumed-shape arrays
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-26 22:16 --- Currently fighting namelists ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-05 09:53:20 |2007-07-26 22:16:35 date|| Summary|Wrongly accepts namelists |Wrongly accepts namelists |with assumed-sized arrays |with assumed-shape arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31818
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Comment #10 from dmixm at marine dot febras dot ru 2007-07-27 01:24 --- Yes, results are: avr-gcc-3.3.6: O0 --> 75, O1,O2,O3,Os --> 79 avr-gcc-4.2.1: O0 --> 109, O1,O2,O3,Os --> 79 The mistake is corrected? It is possible to tell and so as now application of keys of optimization shortens a code. However, "correction" does not improve quality of optimization, it only worsens not optimized code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
[Bug rtl-optimization/32725] Unnecessary reg-reg moves
--- Comment #6 from scovich at gmail dot com 2007-07-26 22:51 --- I've observed several more pieces of code where this bug comes up, and it always seems to be a case of (a) the compiler duplicating a register to preserve the value after a 2-operand insn can clobbers the original, then (b) later failing to notice that the other use(s) got optimized away, never existed, or were reads that got scheduled before the clobber. Perhaps a register renaming pass later in the compilation process might solve the issue? (I don't know how much that would slow down compilation, though). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #9 from falk at debian dot org 2007-07-26 22:49 --- (In reply to comment #8) > Bug 32747 fixed, so I successfully bootstrapped r126943 (all languages minus > java) with patch from comment #6 on alphaev56-unknown-linux-gnu. > So, are you going to post the patch to gcc-patches? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug preprocessor/32868] Don't warn about redefinitions of __STDC_FORMAT_MACROS
-- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-26 21:33:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868
[Bug libstdc++/32908] Miss lexicographical_compare random access override
-- chris at bubblescope dot net changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug libstdc++/32908] New: Miss lexicographical_compare random access override
lexicographical_compare is used to implement operator< and friends on all containers. The code is not optimised for random_access iterators, where we can find which list is the longest before starting and save one comparison every loop. Replace the following line: for (; __first1 != __last1 && __first2 != __last2; ++__first1, ++__first2) With: _InputIterator1 __newlast1 = __first1 + std::min(__last1 - __first1, __last2 - __first2); for (; __first1 != __newlast1; ++__first1, ++__first2) (or something similar. This produces a 15% speed improve on operator< on vector. If this bug remains I will write up code myself, but I am unable to compile g++ from source at the moment. -- Summary: Miss lexicographical_compare random access override Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug fortran/32903] [regression] Default initializer and intent(OUT): default initializer not used
--- Comment #1 from pault at gcc dot gnu dot org 2007-07-26 19:27 --- (In reply to comment #0) > The problem looks similar to PR31205 in so far that gfortran did the Tobias, This PR is caused by the patch for pr31205. If you reference x1 in set, for example by another print, it works correctly. I think that I need to set the symbol as referenced and to update the references. Thanks Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-26 19:27:24 date|| Summary|Default initializer and |[regression] Default |intent(OUT): default|initializer and intent(OUT): |initializer not used|default initializer not used http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32903
[Bug tree-optimization/32891] [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-07-26 18:22 --- Subject: Re: [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp Also, it requires boost :) On 7/26/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > Preprocessed source please. > I don't make installed versions of the compiler to play with :) > > On 25 Jul 2007 11:46:35 -, rguenth at gcc dot gnu dot org > <[EMAIL PROTECTED]> wrote: > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
[Bug fortran/32906] Error: Parameter array ... cannot be automatic or assumed shape
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-26 17:39:34 |2007-07-26 17:50:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32906
[Bug tree-optimization/32087] ICE with FORTRAN and -fprefetch-loop-arrays
--- Comment #4 from sje at cup dot hp dot com 2007-07-26 17:19 --- Fix is checked in. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32087
[Bug middle-end/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #21 from zadeck at naturalbridge dot com 2007-07-26 17:35 --- Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90 Seongbae Park (???, ???) wrote: > On 7/26/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: >> This patch extends the fix in >> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html >> to handle the case of clobbers inside conditional calls. >> >> This problem caused the regression of gfortran.dg/matmul_3.f90 on the >> ia-64 in addition to the regression cited in this pr. >> >> Tested on ppc-32, ia-64 and x86-64. >> >> 2007-07-26 Kenneth Zadeck <[EMAIL PROTECTED]> >> >> PR middle-end/32749 >> >> * df-problems.c (df_note_bb_compute): Handle case of clobber >> inside conditional call. >> >> ok to commit? > > This change is OK. > Though I wonder if we need to do similar checking > for the regular insn case below. No the checking is done in df_create_unused_note. The only reason you have to do it here is that you are not calling that. thanks kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug fortran/32906] New: Error: Parameter array ... cannot be automatic or assumed shape
program test_gfortran implicit none !test case 1, similar to PR26074 integer, parameter :: len = 1 integer, parameter :: arr(max(len,1)) = (/1/) !test case 2 character(len=*), dimension (1), parameter :: specStr = (/'string'/) double precision, dimension (size(specStr)), parameter :: specNum = (/99.0d0/) end This results in: $gfortran-4.2 -c test_gfortran.f90 test_gfortran.f90:7.39: integer,parameter :: arr(max(len,1)) = (/1/) 1 Error: Parameter array 'arr' at (1) cannot be automatic or assumed shape test_gfortran.f90:11.68: double precision, dimension (size(specStr)), parameter :: specNum = (/99.0d0 1 Error: Parameter array 'specnum' at (1) cannot be automatic or assumed shape This is somehow similar to PR26074 (which is fixed and works). NAG and Lahey Fortran compiler work with this code. See http://gcc.gnu.org/ml/fortran/2007-07/msg00486.html -- Summary: Error: Parameter array ... cannot be automatic or assumed shape Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: flad at gmx dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32906
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
--- Comment #11 from sje at cup dot hp dot com 2007-07-26 16:44 --- Sorry, I missed the fact that it was a regression. I will test the 4.2 branch and then backport it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
--- Comment #9 from sje at cup dot hp dot com 2007-07-26 16:30 --- The fix for this was approved and checked into mainline. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-07-26 15:02 --- Unassigning. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug middle-end/32887] warning for memset with zero size
--- Comment #13 from manu at gcc dot gnu dot org 2007-07-26 13:57 --- (In reply to comment #12) > I want the warning. > but why the warning is glibc's bug? Andrew already tried to explain. It is a side-effect of a bug in glibc. > because memset(x,19,0), is buggy code. > I need the warning. I think that is a sensible feature request, am I missing something Andrew? I hope someone will be so kind to implement it for you (or you decide to implement it yourself). -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Summary|memset warning |warning for memset with zero ||size http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
[Bug middle-end/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #19 from zadeck at naturalbridge dot com 2007-07-26 11:51 --- Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90 This patch extends the fix in http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html to handle the case of clobbers inside conditional calls. This problem caused the regression of gfortran.dg/matmul_3.f90 on the ia-64 in addition to the regression cited in this pr. Tested on ppc-32, ia-64 and x86-64. 2007-07-26 Kenneth Zadeck <[EMAIL PROTECTED]> PR middle-end/32749 * df-problems.c (df_note_bb_compute): Handle case of clobber inside conditional call. ok to commit? kenny Index: df-problems.c === --- df-problems.c (revision 126918) +++ df-problems.c (working copy) @@ -3989,7 +3989,7 @@ df_note_bb_compute (unsigned int bb_inde /* However a may or must clobber still needs to kill the reg so that REG_DEAD notes are later placed appropriately. */ - else + else if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL))) bitmap_clear_bit (live, DF_REF_REGNO (def)); } } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug c++/32346] [4.2/4.3 Regression] long long bitfield passed to int argument incorrectly
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-26 09:58 --- Confirmed. This is caused by 2007-04-17 Mark Mitchell <[EMAIL PROTECTED]> PR c++/31513 * call.c (convert_for_arg_passing): Convert bitfields to their declared types. which causes us to expand dosomething ((long long int) bar.item, 0) as convert_for_arg_passing does not demote types. The patch didn't went to the 4.1 branch and I cannot reproduce the failure there. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, mark at codesourcery ||dot com OtherBugsDependingO||31513 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.2.0 4.2.1 4.3.0 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2007-07-26 09:58:28 date|| Summary|long long bitfield passed to|[4.2/4.3 Regression] long |int argument incorrectly|long bitfield passed to int ||argument incorrectly Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-26 09:14 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug middle-end/32887] memset warning
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-26 07:42 --- > can gernerate warning on gcc-4.2.1 on x86 What is the warning? Because I am not seeing it. It might be that glibc is doing the warning. Can you paste the warning you are getting? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
[Bug c++/32346] [4.2/4.3 Regression] long long bitfield passed to int argument incorrectly
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-26 09:58:28 |2007-07-26 23:28:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
[Bug libstdc++/32907] Inefficient operator== in std::string
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-26 21:51:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
[Bug tree-optimization/32891] [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-26 21:19 --- PR 32596 is the ICE. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||32596 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
[Bug fortran/32903] [regression] Default initializer and intent(OUT): default initializer not used
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-26 20:02 --- This is fixed by: Index: gcc/fortran/trans-decl.c === --- gcc/fortran/trans-decl.c(revision 126885) +++ gcc/fortran/trans-decl.c(working copy) @@ -2735,8 +2735,7 @@ /* If an INTENT(OUT) dummy of derived type has a default initializer, it must be initialized here. */ - if (f->sym && f->sym->attr.referenced - && f->sym->attr.intent == INTENT_OUT + if (f->sym && f->sym->attr.intent == INTENT_OUT && f->sym->ts.type == BT_DERIVED && !f->sym->ts.derived->attr.alloc_comp && f->sym->value) @@ -2744,6 +2743,7 @@ gfc_expr *tmpe; tree tmp, present; gcc_assert (!f->sym->attr.allocatable); + gfc_set_sym_referenced (f->sym); tmpe = gfc_lval_expr_from_sym (f->sym); tmp = gfc_trans_assignment (tmpe, f->sym->value, false); I'll regtest and check against cp2k before committing as obvious. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-07-26 19:27:24 |2007-07-26 20:02:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32903
[Bug libstdc++/32907] Inefficent operator== in std::string and std::list
--- Comment #1 from pcarlini at suse dot de 2007-07-26 19:35 --- Well, in our current, C++03, implementation, definitely list::size is O(N). The issue is thorny, as you know well. For C++0x, Howard has a proposal related to the additional splice overload, I'm not sure which is the progress on that... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
[Bug libstdc++/32907] New: Inefficent operator== in std::string and std::list
This is picked up from http://gcc.gnu.org/ml/gcc/2007-07/msg00681.html ,
apologises if it has already been dealt with.
Both std::string and std::list do not compare lengths before comparing elements
in operator==. In std::string this increases the chances of quitting early and
produces a small improvement even for equal length strings. For std::list this
produces a much larger gain. I believe the operator== for list should simply be
replaced implementation used for all the other containers:
{ return (__x.size() == __y.size()
&& std::equal(__x.begin(), __x.end(), __y.begin())); }
Which is efficent as list has a O(1) size.
--
Summary: Inefficent operator== in std::string and std::list
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
[Bug tree-optimization/32891] [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-07-26 18:21 --- Subject: Re: [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp Preprocessed source please. I don't make installed versions of the compiler to play with :) On 25 Jul 2007 11:46:35 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-25 11:46 > --- > Created an attachment (id=13972) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13972&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13972&action=view) > testcase > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
[Bug middle-end/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #22 from seongbae dot park at gmail dot com 2007-07-26 17:56 --- Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90 On 7/26/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Seongbae Park (???, ???) wrote: > > On 7/26/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > >> This patch extends the fix in > >> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html > >> to handle the case of clobbers inside conditional calls. > >> > >> This problem caused the regression of gfortran.dg/matmul_3.f90 on the > >> ia-64 in addition to the regression cited in this pr. > >> > >> Tested on ppc-32, ia-64 and x86-64. > >> > >> 2007-07-26 Kenneth Zadeck <[EMAIL PROTECTED]> > >> > >> PR middle-end/32749 > >> > >> * df-problems.c (df_note_bb_compute): Handle case of clobber > >> inside conditional call. > >> > >> ok to commit? > > > > This change is OK. > > Though I wonder if we need to do similar checking > > for the regular insn case below. > No the checking is done in df_create_unused_note. The only reason you > have to do it here is that you are not calling that. > > thanks Now that I look at df_create_unused_note, this patch smells a bit - because the condition inside the for loop looks identical to df_create_unused_node. I think it would be cleaner if we split the live vector update into a separate function. i.e. attached patch (untested). --- Comment #23 from seongbae dot park at gmail dot com 2007-07-26 17:56 --- Created an attachment (id=13986) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13986&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug fortran/32905] New: NAMELIST accepts types with ultimate POINTER components
F95, 5.4 Namelist Statement, 1st Constraint: "A namelist-group-object shall not be [...] a pointer, a variable of a type that has an ultimate component that is a pointer [...]." This code is accepted by gfortran-20070725: TYPE :: tt INTEGER, POINTER :: x END TYPE TYPE(tt) :: t NAMELIST /nl2/ t END -- Summary: NAMELIST accepts types with ultimate POINTER components Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32905
[Bug middle-end/32887] warning for memset with zero size
--- Comment #14 from pinskia at gmail dot com 2007-07-26 16:51 --- Subject: Re: warning for memset with zero size On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > I think that is a sensible feature request, am I missing something Andrew? memset with a zero size is valid code. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
--- Comment #10 from pluto at agmk dot net 2007-07-26 16:37 --- (In reply to comment #9) > The fix for this was approved and checked into mainline. resolved/fixed? what about 4.2 branch? it's a regression. -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug java/32904] Typo in Base64.java's decode function
--- Comment #1 from tromey at gcc dot gnu dot org 2007-07-26 16:19 --- Note that this is fixed in Classpath and gcj 4.3. As I recall, Casey (? I think) consolidated all the Base64 implementations into a single good one. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-26 16:19:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32904
SegFault by using strcmp
Hi, I know, wenn man uses strcmp(const char* s1, const char* s2), Null pointer values for s1 and s2 are treated the same as pointers to empty strings. But I can only get SegFault in my application, because s1 or s2 sometimes may be NULL. I am using g++ version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4), glibc-2.3.4-2 libstdc++-v3 auf AMD86-64 Is it a bug? Thanks -- View this message in context: http://www.nabble.com/SegFault-by-using-strcmp-tf4152553.html#a11813540 Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #7 from dje at gcc dot gnu dot org 2007-07-26 12:53 --- v0 (and v10 are scratch registers and not saved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug fortran/32903] New: Default initializer and intent(OUT): default initializer not used
I found the following program on my disc; it might well belong to some PR, but
I could not find it anywhere in bugzilla.
I think the program is valid; due to the default initializer, it should print
"2" (as it does with g95, NAG f95, ifort, openf95), but gfortran prints "4".
The problem looks similar to PR31205 in so far that gfortran did the
initialization in the caller and not in the called procedure.
Dump:
set (x1) { (void) 0; }
d.i = 4;
set (&d);
program test
implicit none
type data_type
integer :: i=2
end type data_type
type(data_type) :: d
d%i = 4
call set(d)
print *, d%i
contains
subroutine set(x1)
type(data_type),intent(out):: x1
end subroutine set
end program test
--
Summary: Default initializer and intent(OUT): default initializer
not used
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32903
[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry
--- Comment #42 from debian-gcc at lists dot debian dot org 2007-07-26 11:20 --- *** Bug 32900 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug fortran/32902] New: Document integer KIND of SIZEOF()
The error message of using sizeof() as aktual argument to a default-kind integer is not very clear. One should state in the manual not only that an INTEGER is returned (which implies default kind), but also that depending on the system the integer could be of non-default kind. http://gcc.gnu.org/onlinedocs/gfortran/SIZEOF.html The size is probably "size_t" alias ISO_C_Binding's c_size_t, which shows the advantage of having C Bindings. -- Summary: Document integer KIND of SIZEOF() Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32902
[Bug tree-optimization/32901] New: [4.1 regression] bitfield constants with multiple bitfields take up space in .data
When defining a bitfield constant where multiple bitfields have initializing values, this constant is moved into .data in GCC 4.1. GCC 3.x could realize it can be written and assigned as a single integer number. GCC 4.x only realizes this situation as long as a single bitfield is initialized. Verified on i386 and avr targets, so this is apparently completely independent of the target CPU. -- Summary: [4.1 regression] bitfield constants with multiple bitfields take up space in .data Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j at uriah dot heep dot sax dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #9 from jakub at gcc dot gnu dot org 2007-07-26 09:25 --- But the change was in generic code, are you very sure you haven't changed ABI on any of the targets? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-07-26 08:38 --- Created an attachment (id=13982) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13982&action=view) Test file Test case. Compile with -Os -S, and optionally -DONLY_ONE_BITFIELD to see the difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry
--- Comment #43 from dberlin at gcc dot gnu dot org 2007-07-26 18:03 --- On my current branch, which i will commit soon, i have tree PTA : 14.56 ( 1%) usr 0.57 ( 1%) sys 16.98 ( 1%) wall 26372 kB ( 2%) ggc tree alias analysis : 577.90 (26%) usr 8.72 ( 8%) sys 611.13 (24%) wall 108272 kB ( 7%) ggc I have looked through this bug report again, I also don't see PTA taking up your memory. (Alias analysis i will try to fix, but it's a bit tricky) What is happening is the memory is increasing slowly. It's not like PTA is suddenly allocating 1.5 gig. So your memory usage is not coming from PTA (at least, not in a way I can solve, unless you see a leak somewhere). It is much more likely someone is leaking memory. In short I have absolutely no plans to work on the memory hog portion of this bug, and deny that points-to analysis is "memory hungry" in 4.3 because i don't see it. -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Keywords|memory-hog | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug fortran/32906] Error: Parameter array ... cannot be automatic or assumed shape
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-26 17:39 --- Confirmed. PR26974 has: integer, parameter :: len = 1 integer :: arr(max(len,1)) = (/1/) Above testcase contains: integer, parameter :: len = 1 integer, parameter :: arr(max(len,1)) = (/1/) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.1.2 4.2.1 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-07-26 17:39:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32906
[Bug middle-end/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #20 from seongbae dot park at gmail dot com 2007-07-26 17:27 --- Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90 On 7/26/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > This patch extends the fix in > http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html > to handle the case of clobbers inside conditional calls. > > This problem caused the regression of gfortran.dg/matmul_3.f90 on the > ia-64 in addition to the regression cited in this pr. > > Tested on ppc-32, ia-64 and x86-64. > > 2007-07-26 Kenneth Zadeck <[EMAIL PROTECTED]> > > PR middle-end/32749 > > * df-problems.c (df_note_bb_compute): Handle case of clobber > inside conditional call. > > ok to commit? This change is OK. Though I wonder if we need to do similar checking for the regular insn case below. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-07-26 12:09 --- rs6000_conditional_register_usage (); memset (®_class_size, 0, 84); gets compiled to vxorv0,v0,v0 ... bl 0x104f0c68 ... stvxv0,r0,r9 addir9,r11,32 stw r0,80(r11) stvxv0,r0,r11 addir11,r11,48 stvxv0,r0,r27 stvxv0,r0,r9 stvxv0,r0,r11 The value of v0 gets changed inside rs6000_conditional_register_usage (some loop gets vectorized there and v0 is used), so we are not setting reg_class_size to zero, but to some random value. I am not familiar with ppc abi -- is v0 call clobbered? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug c++/32900] [4.2/4.3 regression] compile time and memory regression
--- Comment #5 from debian-gcc at lists dot debian dot org 2007-07-26 11:20 --- *** This bug has been marked as a duplicate of 30052 *** -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32900
[Bug libstdc++/32910] New: The == operator of hashtable.h and hash_map.h is broken
The operator== of hashtable.h (also used in ext/hash_map.h) is broken. Even if the two hash tables being compared have the same key/value pairs, if the number of *buckets* is different, the == operator returns false. Looking at the code for the ==operator (line 698 of hashtable.h in the trunk of SVN), it returns false unless the number of buckets is the same (not the number of actual items in the hash table). I'm not sure of the specification of == operators in the STL, but it seems that have the number of buckets be part of the == operator is very strange behavior. So, either this is a strangely-specific operation or the implementation of operator== of hashtable isn't correct. From looking at some other on-line documentation, it seems that this is indeed a bug. For example, from http://msdn2.microsoft.com/en-us/library/w2w623zh(VS.80).aspx: "The comparison between hash_map objects is based on a pairwise comparison of their elements. Two hash_maps are equal if they have the same number of elements and their respective elements have the same values. Otherwise, they are unequal." The code below illustrates the problem: hash_map map1(100); hash_map map2(1000); map1[10] = 10; map2[10] = 10; cout << (map1 == map2) << endl; The above code will print "0" instead of the expected "1". I verified this on g++ 4.1, but by looking at the latest code in SVN, the problem clearly hasn't been fixed. The code seems to rely on the number of buckets being the same to enable a parallel walk of the buckets of both hash tables. This comparison operation needs to be re-written to handle the case in which the number of buckets differs. Please feel free to contact me if you have any questions. -- Summary: The == operator of hashtable.h and hash_map.h is broken Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milom at cis dot upenn dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32910
[Bug tree-optimization/32087] ICE with FORTRAN and -fprefetch-loop-arrays
--- Comment #3 from sje at gcc dot gnu dot org 2007-07-26 17:11 --- Subject: Bug 32087 Author: sje Date: Thu Jul 26 17:11:24 2007 New Revision: 126959 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126959 Log: PR tree-optimization/32087 * tree-ssa-loop-manip.c (tree_transform_and_unroll_loop): Do not call scale_bbs_frequencies_int with prob of zero. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-manip.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32087
[Bug tree-optimization/32826] Reduction into a global variable causes a Load Hit Store Hazard (for the Cell)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-26 17:02 --- (In reply to comment #2) > (In reply to comment #2) > Just want a clarification: > I see you're compiling on PPU (since you're using -maltivec). > Does this problematic also on SPU? No because extraction from a vector is a simple rotate. > Does SPU has this LHS hazard? No because there is no store queue on the SPU. > > Another question: > lwz r0,-20(r1) < LHS hazard > stw r0,lo16(_e)(r2) > > The problem here is these 2 insns, right? No, it is the load after the store to the same address: stvewx v1,0,r2 lwz r0,-20(r1) < LHS hazard r2 at this point is equal to -20(r1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32826
[Bug middle-end/32887] warning for memset with zero size
--- Comment #15 from manu at gcc dot gnu dot org 2007-07-26 16:58 ---
(In reply to comment #14)
> Subject: Re: warning for memset with zero size
>
> On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org
> <[EMAIL PROTECTED]> wrote:
> >
> > I think that is a sensible feature request, am I missing something Andrew?
>
> memset with a zero size is valid code.
>
I am not saying that is invalid. I am saying that it is a statement with no
effect. So it could be warned as we warn for: { 0; }
Perhaps memset with size 0 appears frequently in real-code as the result of
macro expansions or such. Then, this must be closed as WONTFIX and similar
requests can be directed at this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
Re: [Bug middle-end/32887] warning for memset with zero size
On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: I think that is a sensible feature request, am I missing something Andrew? memset with a zero size is valid code. Thanks, Andrew Pinski
[Bug middle-end/32887] memset warning
--- Comment #9 from cnstar9988 at gmail dot com 2007-07-26 08:02 --- Created an attachment (id=13980) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13980&action=view) file gcc -m32 -O3 -Wall test.c -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
[Bug fortran/32760] Error defining subroutine named PRINT
--- Comment #15 from patchapp at dberlin dot org 2007-07-27 05:47 --- Subject: Bug number PR32760 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01960.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32760
[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) is written a +Infinity on Darwin8
--- Comment #17 from dominiq at lps dot ens dot fr 2007-07-27 05:56 --- Subject: Re: [4.3 regression] HUGE(1.0d0) is written a +Infinity on Darwin8 > Maybe you could try to delete the conditional defines that redefine isfinite > so > that the native calls are used and see if the problem goes away. I have done something slightly different, but with the same result, I have moved line 167: #undef isfinite outside the #if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__) block. This change fixes the bug, edit_real_1.f90 pass. Now the questions are (1) why HAVE_BROKEN_ISFINITE is not set by gcc 4.3 while it is by gcc 4.2? (2) if the isfinite used by C is working, why isfinite is not working for libfortran? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #11 from patchapp at dberlin dot org 2007-07-27 06:22 --- Subject: Bug number PR32522 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01962.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #10 from belyshev at depni dot sinp dot msu dot ru 2007-07-27 06:18 --- (In reply to comment #9) Patch posted. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||07/msg01962.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2007-07-27 06:50 --- Hum, I don't see anything in rev. 123623 (http://gcc.gnu.org/viewcvs?view=rev&revision=123623) that looks too suspicious. What would need to be done now, in my opinion, is to: 1. check that rev. 123622 passes, 2. check that rev.123623 fails, 3a. check if reverting the libgfortran/io/write.c change makes it pass again 3b. check whether reverting the change to libgfortran/configure.ac makes it pass again (after autoreconf && automake in that directory) This really has the cost of only (sic) one bootstrap, since only libgfortran needs rebuilding each time. I don't have a ppc-darwin computer anymore, so I unfortunately can't test. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Summary|[4.3 regression] HUGE(1.0d0)|[4.3 regression] HUGE(1.0d0) |is written a +Infinity on |output as +Infinity on ppc- |Darwin8 |darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug c/32911] New: Function __attribute__ ((idempotent))
In GNOME's gobject object-oriented code, each type has a "get_type" function.
Something like, eg:
GType
pango_layout_line_get_type(void)
{
static GType our_type = 0;
if (our_type == 0)
our_type = g_boxed_type_register_static (I_("PangoLayoutLine"),
(GBoxedCopyFunc) pango_layout_line_ref,
(GBoxedFreeFunc) pango_layout_line_unref);
return our_type;
}
Since these functions are called quite frequently (as part of casts among other
things), people have started marking them with __attribute__((const)) so the
compiler can optimize away multiple calls to them. However, there is a down
side to it. Sometimes one needs to make sure the type is registered, so they
call the _get_type() function to ensure that, but the compiler, seeing the
((const)) attribute, optimizes away the call.
This is of course a bug to mark functions with side-effects as ((const)).
That's why a new function attribute like "idempotent" is useful. What it means
is that subsequent calls to this function return the same value as the first
call, have no side-effect, and can be optimized away, but not the first call...
Thanks,
--
Summary: Function __attribute__ ((idempotent))
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at behdad dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911
