[Bug rtl-optimization/25514] [4.0/4.1 regression] internal consistency failure
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-11-02 08:03 --- I think Roger is OK in principle with a backport, but the questions are (a) whether we should keep your patch on mainline too and, if not, (b) whether we should revert it on the branches too. Roger, let me know if I've misrepresented you there. I don't think my patch should be taken into account to make the decision. However, I can first revert it everywhere to make the backport easier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25514
[Bug fortran/28004] Warn if intent(out) dummy variable is not set
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-11-02 09:47 --- (In reply to comment #1) I presented a patch for this problem and for detected unassigned r-values that was rejected. I don't know what to say; I think that it's a bug, in principle, but the standard does not require it. Paul, I looked at that bug again but couldn't find the patch you proposed. I think we should issue a warning but not an error, because you can write code that is still valid: logical function foo(a, x) integer,intent(in) :: a integer,intent(out) :: x foo = .false. if (a 0) then foo = .true. x = a end if end function foo program test integer :: a, x a = -1 if (foo (a,x)) print *, x end program test -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-02 09:47:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28004
[Bug target/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-11-02 10:25 --- Yes since it just went in during the time frame you mentioned: 2006-10-28 Eric Botcazou [EMAIL PROTECTED] My bad. Patch crossing with Richard S. section anchor stuff. Testing fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug c/29687] New: internal compiler error in push_reload, at reload.c:1315 building liboil-0.3.9
While building liboil-0.3.9 on GNU/Linux: http://liboil.freedesktop.org/download/liboil-0.3.9.tar.gz I got: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -msse -msse2 -Wall -D_BSD_SOURCE -D_GNU_SOURCE -I../.. -g -O2 -MT libsse_la-composite_sse_2pix.lo -MD -MP -MF .deps/libsse_la-composite_sse_2pix.Tpo -c composite_sse_2pix.c -fPIC -DPIC -o .libs/libsse_la-composite_sse_2pix.o composite_sse_2pix.c: In function `composite_in_argb_sse_2pix': composite_sse_2pix.c:162: internal compiler error: in push_reload, at reload.c:1315 I attach the full build log. Claudio -- Summary: internal compiler error in push_reload, at reload.c:1315 building liboil-0.3.9 Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sick_soul at yahoo dot it GCC build triplet: i486-slackware-linux GCC host triplet: i486-slackware-linux GCC target triplet: i486-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29687
[Bug c/29687] internal compiler error in push_reload, at reload.c:1315 building liboil-0.3.9
--- Comment #1 from sick_soul at yahoo dot it 2006-11-02 10:31 --- Created an attachment (id=12534) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12534action=view) console build log added console log (text/plain) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29687
[Bug bootstrap/28400] install-driver is missing $(exeext) from gcc-$(version)
--- Comment #10 from vprus at gcc dot gnu dot org 2006-11-02 10:39 --- Subject: Bug 28400 Author: vprus Date: Thu Nov 2 10:39:33 2006 New Revision: 118414 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118414 Log: 2006-11-02 Vladimir Prus [EMAIL PROTECTED] Backport from mainline: 2006-11-01 Chris Johns [EMAIL PROTECTED] PR bootstrap/28400 * Makefile.in (install-driver): Use exeext when installing $target-gcc-$version. Modified: branches/csl/sourcerygxx-4_1/ChangeLog.csl branches/csl/sourcerygxx-4_1/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28400
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc
--- Comment #4 from irar at il dot ibm dot com 2006-11-02 11:18 ---
The loop at config/rs6000/rs6000.c:3674 requires versioning for alignment, so
when bootstrapping with
-ftree-vectorize -fno-tree-vect-loop-version it does not get vectorized.
However, we still fail bootstrap... This is the failure we get:
/home/irar/main-boot/build17/./gcc/xgcc -B/home/irar/main-boot/build17/./gcc/
-B/home/irar/main-boot/ppc64-redhat-linux/bin/
-B/home/irar/main-boot/ppc64-redhat-linux/lib/ -isystem
/home/irar/main-boot/ppc64-redhat-linux/include -isystem
/home/irar/main-boot/ppc64-redhat-linux/sys-include -O2 -O2 -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss
-fno-toplevel-reorder -msdata=none \
-c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
../../gcc/gcc/crtstuff.c: In function â__do_global_dtors_auxâ:
../../gcc/gcc/crtstuff.c:304: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [crtbegin.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod gfortran.pod gpl.pod
make[3]: Leaving directory `/home/irar/main-boot/build17/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/irar/main-boot/build17'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/irar/main-boot/build17'
make: *** [bootstrap] Error 2
I found that this time a different loop in rs6000 is related to the failure -
when it is vectorized, the Stage2 compiler is bad, and when we force the loop
not to be vectorized, the Stage2 compiler is good (bootstrap passes with
vectorization enabled). The loop is config/rs6000/rs6000.c:17204:
for (i = 0; i issue_rate; i++)
{
group_insns[i] = 0;
}
Looks like the problem is not related to some specific loop vectorization.
Don't know if it makes sense to try to create a reduced testcase (or how...).
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc
--- Comment #5 from irar at il dot ibm dot com 2006-11-02 11:44 --- I found that revision 110671 passed bootstrap with vectorization enabled, and revision 110846 failed bootstrap with vectorization enabled (but passed w/o). Janis - could you help track down the patch that exposed/caused the bootstrap failure with BOOT_CFLAGS=-O2 -g -ftree-vectorize -maltivec? Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug c++/29688] New: resize initializes whole array
in valarray.h I found that resize is always deleting the old array,
reallocating a new array and initialize to the value specified. The text book
(Stroustrup) indicates that only the newly allocated elements should be
initialized. In my case the array size was not changed but the array
reinitialized (bad code will be changed). I assume this has been corrected in
later versions. I solved the problem by putting the destroy and fill inside
the if block.
Regards,
Theo Bosman
template class _Tp
inline void
valarray_Tp::resize (size_t __n, _Tp __c)
{
// This complication is so to make valarrayvalarrayT work
// even though it is not required by the standard. Nobody should
// be saying valarrayvalarrayT anyway. See the specs.
__valarray_destroy_elements(_M_data, _M_data + _M_size);
if (_M_size != __n)
{
__valarray_release_memory(_M_data);
_M_size = __n;
_M_data = __valarray_get_storage_Tp(__n);
}
__valarray_fill_construct(_M_data, _M_data + __n, __c);
}
--
Summary: resize initializes whole array
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: theo dot bosman at net dot HCC dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29688
[Bug libstdc++/29688] resize initializes whole array
--- Comment #1 from pcarlini at suse dot de 2006-11-02 13:34 --- I do not have Stroustrup at hand, but certainly the ISO C++ Standard 2003, the real reference for our work (we are implementing it), says, in 26.3.2.7/9, that resize first changes the length of *this to sz and then assigns to each element the value of the second argument. It also says that the operation invalidates all pointers and references to elements in the array, thus, the meaning is clear and our implementation is 100% conforming. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29688
[Bug c/29687] internal compiler error in push_reload, at reload.c:1315 building liboil-0.3.9
--- Comment #2 from falk at debian dot org 2006-11-02 13:36 --- Please attach the .i file as obtained by adding -save-temps. Also, please try a newer gcc version, the 3.3 branch is dead. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29687
[Bug target/29686] [4.1 Regression] ICE when building the kernel on ARM
--- Comment #3 from falk at debian dot org 2006-11-02 13:40 --- Confirmed with a native 4.1.2 20061020. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29686
[Bug libstdc++/29688] resize initializes whole array
--- Comment #2 from pcarlini at suse dot de 2006-11-02 13:51 --- The only possible change I can see, as an optimization, is using __valarray_fill instead of __valarray_destroy_elements and __valarray_fill_construct, when _M_size == __n. Let's ask Gaby... -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de, gdr ||at integrable-solutions dot ||net Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29688
[Bug fortran/29689] New: gfortran should use g77-compatible format for error message
There's a thread [EMAIL PROTECTED] started from emacs developers wishing that gfortran used a g77-compatible error message format, starting here: http://gcc.gnu.org/ml/fortran/2006-10/msg00751.html The friendly discussion has been a bit heated. I don't think anybody disagrees with the fact that using an error format closer to the GNU standard would be nice. They usually are reasons behind standards. On the other hand, there is broad agreement that the standard GNU error format offers very poor possibilities for the description of the error locations, especially for multiple-loci errors. -- Summary: gfortran should use g77-compatible format for error message Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
[Bug fortran/29689] gfortran should use g77-compatible format for error message
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-02 14:01:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
[Bug fortran/29689] gfortran should use g77-compatible format for error message
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-02 14:34 --- Some incomplete patch proposals here: http://gcc.gnu.org/ml/fortran/2006-10/msg00825.html and there: http://gcc.gnu.org/ml/fortran/2006-11/msg00017.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #30 from ghazi at gcc dot gnu dot org 2006-11-02 14:41 --- (In reply to comment #28) (In reply to comment #27) It's likely that I'll end up doing it, so would you please tell me how? According to the C rationale (I haven't checked), the sign of gamma(x) is -1 if [iff] x 0 remainder(floor(x), 2) != 0. But if x is a non-positive integer, the sign of gamma(x) isn't defined. Handle these cases first. The test x 0 is easy to do. In MPFR, you can compute floor(x) (or trunc(x)) with the precision min(PREC(x),max(EXP(x),MPFR_PREC_MIN)), but then, there's no direct function to decide whether the result is even or odd (I thought we added this, but this isn't the case). The solution can be to divide x by 2 (this is exact, except in case of underflow) and call mpfr_frac directly. If the result is between -0.5 and 0, then gamma(x) is negative. If the result is between -1 and -0.5, then gamma(x) is positive. So, a 2-bit precision for mpfr_frac should be sufficient (as -0.5 is representable in this precision), but choose a directed rounding (not GMP_RNDN) for that. Then you can just do a comparison with -0.5; the case of equality with -0.5 depends on the chosen rounding (if you obtain -0.5, then it is an inexact result since x is not an integer). For instance, if you choose GMP_RNDZ, then a result -0.5 means that gamma(x) is negative, and a result = -0.5 means that gamma(x) is positive. Vincent, thank you for the detailed instructions. I also read your two possible solutions posted here: http://sympa.loria.fr/wwsympa/arc/mpfr/2006-10/msg00036.html I could be satisfied with either solution from that message. However in the case of choice 1, I feel the calculation of signgam should be provided from a function call in the library rather than forcing each user to write a routine to calculate it. IMHO, I'd rather leave the math to the mathematicians. :-) E.g. you could add a function mpfr_signgam() that figures out the value for the user and thereby leave the interface for mpfr_lngamma() unchanged. Choice 2 also solves the issue by providing the int* parameter. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug libstdc++/29688] resize initializes whole array
--- Comment #3 from theo dot bosman at net dot HCC dot nl 2006-11-02 15:56 --- Subject: Re: resize initializes whole array There is no argument against the ISO standard, but to a non C/C++ programmer it seems a waist of time to reallocate the array and initialize it when one wants to add something to an array. Some other compilers will copy the existing data into the newly allocated space which seems more in line with the text book. The application will be changed to avoid the loss of data on a resize of arrays, which is a better idea anyway. Thanks for the speedy reply. Theo Bosman - Original Message - From: pcarlini at suse dot de [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 02, 2006 2:51 PM Subject: [Bug libstdc++/29688] resize initializes whole array --- Comment #2 from pcarlini at suse dot de 2006-11-02 13:51 --- The only possible change I can see, as an optimization, is using __valarray_fill instead of __valarray_destroy_elements and __valarray_fill_construct, when _M_size == __n. Let's ask Gaby... -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de, gdr ||at integrable-solutions dot ||net Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29688 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29688
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #31 from vincent at vinc17 dot org 2006-11-02 15:57 --- (In reply to comment #30) So, I don't think a mpfr_signgam alone would really be useful. So, I think that choice 2 would be better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug fortran/28484] system_clock with real-type count_rate does not compile
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-02 16:02 --- Created an attachment (id=12535) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12535action=view) Idea how libgfortran/intrinsic/system_clock.c could look like Some bits of thought. Methods obtaining the time: * clock_gettime() [POSIX] 10^-9s (nanosecond) resolution, options: CLOCK_REALTIME - on unix time since the epoch [I would suggested this] CLOCK_MONOTONIC - survives even changing the time, but starting point is arbitrary See also PR 15516 for assembler calling sequences for Linux * gettimeofday (tv, NULL) [POSIX] 10^-6s (microsecond) resolution * time() [POSIX] second resolution Resolution - time able to be represented - For huge(i4) = 2147483647 1000 ms:68 years 100 ms: 2485 days 10 ms: 246 days 1 ms:25 days 100 us:60 hours 10 us: 6 hours = 10 ms seems to be a good resolution, 25 days might be a bit short for some calculation jobs, but 250 days should be enough. For huge(i8) = 9223372036854775807 1 s: 2e11 years 1 ms: 2e8 years 1 us: 292271years 1 ns:292years = 1 ns seems to be ok I'm thinking of the following library implementation: Only do integer(8) as this seems to be enough. (See attachment.) For iresolve.c one needs to do something like the following (pseudo code): if(count != NULL counts.type != 8) gfc_convert_type() if(count != NULL count_max.type != 8) gfc_convert_type() if(count != NULL count_rate.type != 8) gfc_convert_type() c-resolved_sym = gfc_get_intrinsic_sub_symbol (system_clock) if (count != NULL count.type == 4) count = (int4) ((count8/1000) % GFC_INTEGER_4_HUGE) else if (count != NULL count.type != 8) count = (type) count8 if (count_rate != NULL count_rate.type == 4) add_expression(if(count_rate8 == 0) count_rate = 0 else count_rate = 100) else if (count != NULL count.type != 8) count_rate = (type) count_rate8 if (count_max != NULL count_max.type == 4) add_expression(if(count_max8 == 0) count_max = 0 else count_max = GFC_INTEGER_4_HUGE) else if (count != NULL count.type != 8) count_rate = (type) count_rate8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug tree-optimization/29145] unsafe use of restrict qualifier
--- Comment #3 from ian at airs dot com 2006-11-02 16:07 --- This looks like a compiler bug to me. The code in base_addr_differ_p seems dubious anyhow: in principle,may_alias_p should handle restrict, it shouldn't be handled by the caller. It looks like this code has been there since tree-vect-analyze.c was added in 2005-02-17. -- ian at airs dot com changed: What|Removed |Added CC||dorit at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
[Bug tree-optimization/29145] unsafe use of restrict qualifier
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-02 16:10 --- Confirmed. (this is also why effective restrict is hard to do without better PTA) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-11-02 16:10:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
[Bug fortran/28484] system_clock with real-type count_rate does not compile
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-02 16:32 ---
Created an attachment (id=12536)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12536action=view)
Revised idea how libgfortran/intrinsic/system_clock.c could look like
The latter part is of cause not completely right if count_rate = 1 or 100,
and for an error int16 and real counts didn't contain -huge().
Maybe having in the library a system_clock_4 version makes life easier.
The following pseudocode should then work with system_clock_4 and
system_clock_8 (which has also the advantage that we don't modify the library
which is nice in terms of compatibility :-)
if ( (counts != NULL counts.type == 4)
||(count_max != NULL count_max.type == 4) {
if(count != NULL counts.type != 4)
gfc_convert_type()
if(count != NULL count_max.type != 4)
gfc_convert_type()
if(count != NULL count_rate.type != 4)
gfc_convert_type()
c-resolved_sym = gfc_get_intrinsic_sub_symbol (system_clock_4)
if (counts != NULL counts.type != 4)
add_expression(if(counts4 0) counts = -huge_max(type)
else counts = (type) counts4)
if (count_rate != NULL count_rate.type != 4)
count_rate = (type) count_rate4
if (count_max != NULL count_max.type != 4)
count_rate = (type) count_rate4
} else {
if(count != NULL counts.type != 8)
gfc_convert_type()
if(count != NULL count_max.type != 8)
gfc_convert_type()
if(count != NULL count_rate.type != 8)
gfc_convert_type()
c-resolved_sym = gfc_get_intrinsic_sub_symbol (system_clock_8)
if (counts != NULL counts.type != 8)
add_expression(if(counts8 0) counts = -huge_max(type)
else counts = (type) counts8)
if (count_rate != NULL count_rate.type != 8)
count_rate = (type) count_rate8
if (count_max != NULL count_max.type != 8)
count_rate = (type) count_rate8
}
Now I only have to figure out how to add the conversion and the if(counts8
0) expression in iresolve.c.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Attachment #12535|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug c++/28553] [4.1 Regression] string processing -O3 optimization bug under GCC 4.1.1
--- Comment #7 from peter at chocky dot org 2006-11-02 16:34 --- I can confirm that this is fixed with the GCC 4.1 now in Debian unstable. -- peter at chocky dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28553
[Bug target/29250] [4.0/4.1 Regression] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #12 from dje at gcc dot gnu dot org 2006-11-02 17:19 --- Subject: Bug 29250 Author: dje Date: Thu Nov 2 17:18:52 2006 New Revision: 118421 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118421 Log: 2006-10-13 David Edelsohn [EMAIL PROTECTED] Ian Lance Taylor ian@airs.com PR middle-end/29250 * expr.c (expand_expr_real_1) NON_LVALUE_EXPR, NOP_EXPR, CONVERT_EXPR: Change EXPAND_SUM modifier to EXPAND_NORMAL when recursing. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29250
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-11-02 18:41 --- Subject: Bug 29639 Author: ebotcazou Date: Thu Nov 2 18:40:54 2006 New Revision: 118422 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118422 Log: PR other/29639 * except.c (switch_to_exception_section): Do not cache the section if named sections are supported and HAVE_LD_EH_GC_SECTIONS is defined and flag_function_sections is set. Added: trunk/gcc/testsuite/g++.dg/eh/gcsec1.C Modified: trunk/gcc/ChangeLog trunk/gcc/except.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-11-02 18:44 --- Should work now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||11/msg00100.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug libmudflap/29691] New: libmudflap misses buffer overrun in sprintf
The attached program writes to buf[16] using sprintf. The format writes 15 characters and then explicitly appends a \0 byte using %c. Subsequently sprintf will implicitly append another \0 byte itself so that in total 17 bytes are written to buf, i.e. 1 byte too many. One can readily check that the first character of a[4] is indeed overwritten by a \0 byte. libmudflap misses this buffer overrun: gcc -fmudflap test8.i -lmudflap a.out gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /dump1/root/temp/gcc/configure --prefix=/usr/local/gcc430 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20061030 (experimental) If the character written with the %c format specifier would have been anything other than \0, the buffer overrun would have been caught by libmudflap. This bug is present with the following gcc versions: 4.0.3, 4.1.1, 4.2.0 (20061030), and the mainline as listed above. This applies to both AMD64 and IA32 platforms. -- Summary: libmudflap misses buffer overrun in sprintf Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: p dot vanhoof at oma dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29691
[Bug libmudflap/29691] libmudflap misses buffer overrun in sprintf
--- Comment #1 from p dot vanhoof at oma dot be 2006-11-02 18:47 --- Created an attachment (id=12537) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12537action=view) preprocessed test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29691
[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-11-02 19:18 --- Subject: Bug 27891 Author: rakdver Date: Thu Nov 2 19:18:25 2006 New Revision: 118423 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118423 Log: PR tree-optimization/27891 * tree-ssa-loop-ivopts.c (rewrite_use_outer): Do not insert code on abnormal edge. * gcc++.dg/tree-ssa/pr27891.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/tree-ssa/pr27891.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-11-02 20:57 --- Subject: Bug 27891 Author: rakdver Date: Thu Nov 2 20:57:35 2006 New Revision: 118430 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118430 Log: PR tree-optimization/27891 * tree-ssa-loop-ivopts.c (rewrite_use_outer): Do not insert code on abnormal edge. * gcc++.dg/tree-ssa/pr27891.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/tree-ssa/pr27891.C Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #32 from ghazi at gcc dot gnu dot org 2006-11-02 22:44 --- (In reply to comment #31) (In reply to comment #30) So, I don't think a mpfr_signgam alone would really be useful. So, I think that choice 2 would be better. Okay, sounds fine. Would this make it into 2.2.1 or 2.3? And do you have any very rough timeframe for each release so I can plan accordingly for gcc? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug target/27405] [4.2/4.3 Regression] gcc.c-torture/execute/960209-1.c ICEs on sh64-* with -O3
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-11-02 22:57 ---
Subject: Bug 27405
Author: kkojima
Date: Thu Nov 2 22:57:13 2006
New Revision: 118435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118435
Log:
PR target/27405
* config/sh/sh.md (cmp{eq,gt,gtu}{si,di}_media): Remove.
(cmpsi{eq,gt,gtu}{si,di}_media): Rename to
cmp{eq,gt,gtu}{si,di}_media.
(*cmpne0si_media): Remove.
(*movsicc_umin): Adjust gen_cmp*_media call.
(unordered): Change the mode of unordered and operands[1] to
SImode.
(seq): Adjust gen_cmp*_media calls. Make the mode of
a temporary result of compare SImode if needed. If the mode
of operands[0] is DImode, extend the temporary result to DImode.
(slt, sle, sgt, sge, sgtu, sltu, sleu, sgue, sne): Likewise.
(sunorderd): Change the mode of match_operand and unorderd to
SImode.
(cmpeq{sf,df}_media): Remove.
(cmpsieq{sf,df}_media): Rename to cmpeq{sf,df}_media.
(cmp{gt,ge,un}{sf,df}_media): Change the mode of match_operand
and compare operation to SImode.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27405
[Bug libfortran/29649] Force core dump on runtime library errors
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-02 23:42 --- PR 5773 is about addr2line in gcj. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||5773 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649
[Bug libfortran/29649] Force core dump on runtime library errors
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-11-02 23:52 --- We can fork+exec addr2line, but we can't link libbfd because it's GPL. It was mentionned on IRC tonight that Daniel Berlin has a library that extracts line and file information from DWARF2 info. It's internal to Google, but he said he'll see if he can get it released. We'll have to get back to him in some time... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649
[Bug libstdc++/29688] resize initializes whole array
--- Comment #4 from pcarlini at suse dot de 2006-11-03 00:08 --- (In reply to comment #3) Subject: Re: resize initializes whole array There is no argument against the ISO standard, but to a non C/C++ programmer it seems a waist of time to reallocate the array and initialize it when one wants to add something to an array. Some other compilers will copy the existing data into the newly allocated space which seems more in line with the text book. I don't know. We are definitely implementing the ISO C++ Standard, and, by the way, many details in Stroustrup' books, predating the Standard, are know to be slightly different. I will also add that valarray is *very* special - its design was motivated by considerations of highest performance on superscalar architectures, etc. - for example vector::resize behaves in a completely different way, which probably you like better. The application will be changed to avoid the loss of data on a resize of arrays, which is a better idea anyway. Thanks for the speedy reply. For portability, that is the safe thing to do, yes, I agree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29688
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc
--- Comment #6 from janis at gcc dot gnu dot org 2006-11-03 00:08 --- A regression hunt on powerpc64-linux identified the following large patch: http://gcc.gnu.org/viewcvs?view=revrev=110705 r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #18 from pcarlini at suse dot de 2006-11-03 00:29 --- Thanks again for the quick fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug c/29693] New: ICE while compiling gcc-3.4.3 with gcc-4.1.1
This was the error I got from gcc-4.1.1 while attempting to compile gcc-3.4.3. $ arm-none-linux-gnueabi-gcc -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -fexceptions -c ../../gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o -save-temps ../../gcc/unwind-dw2.c: In function 'extract_cie_info': ../../gcc/unwind-dw2.c:328: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ../../gcc/unwind-dw2.c:381: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind-dw2.c: In function 'execute_cfa_program': ../../gcc/unwind-dw2.c:844: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind-dw2.c: In function 'uw_frame_state_for': ../../gcc/unwind-dw2.c:1060: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind-dw2.c: In function 'init_dwarf_reg_size_table': ../../gcc/unwind-dw2.c:1272: internal compiler error: in arm_dbx_register_number, at config/arm/arm.c:15183 -- Summary: ICE while compiling gcc-3.4.3 with gcc-4.1.1 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mriben at globallocate dot com GCC host triplet: i686-host_pc-linux-gnu GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693
[Bug c/29693] ICE while compiling gcc-3.4.3 with gcc-4.1.1
--- Comment #1 from mriben at globallocate dot com 2006-11-03 02:08 --- Created an attachment (id=12539) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12539action=view) unwind-dw2.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693
[Bug c/29693] ICE while compiling gcc-3.4.3 with gcc-4.1.1
--- Comment #2 from mriben at globallocate dot com 2006-11-03 02:09 --- Created an attachment (id=12540) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12540action=view) unwind-dw2.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693
[Bug fortran/29689] gfortran should use g77-compatible format for error message
--- Comment #2 from brooks dot moses at codesourcery dot com 2006-11-03 02:52 --- Created an attachment (id=12541) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12541action=view) Proposed patch including testsuite changes I attempted to send this to the list, but I'm not sure if it went through. Thus, posting it here; the following text had been included in the email: Steve Kargl wrote: I have stated more than once THE TRIVIAL FIX DOES NOT WORK. It causes REGRESSIONS in the gfortran testsuite. If someone wants to fix whatever is causing the regressions, I'll be more than happy to commit the patch. The attached only-slightly-less-trivial patch should fix the regressions, although I have not yet tested it to confirm that. Since my build machine is currently occupied with running CFD calculations for my dissertation, would you mind regtesting it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
[Bug bootstrap/26814] Bootstrapping with a non default ABI (-m64 on ppc-darwin or on ppc-linux with a compiler defaulting to 32 and now defaulting to 64)
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2006-11-03
03:14 ---
I can now complete a multilib build of the languages c, c++, objc and fortran
on a G4 under Darwin8 if I apply the following patch...
--- gcc-4.2-20061031/zlib/configure.ac.org 2006-11-02 11:44:36.0
-0500
+++ gcc-4.2-20061031/zlib/configure.ac 2006-11-02 12:19:04.0 -0500
@@ -31,15 +31,6 @@
AC_ARG_WITH(cross-host,
[ --with-cross-host=HOST configuring with a cross compiler])
-dnl Default to --enable-multilib
-AC_ARG_ENABLE(multilib,
-[ --enable-multilib build many library versions (default)],
-[case ${enableval} in
- yes) multilib=yes ;;
- no) multilib=no ;;
- *) AC_MSG_ERROR(bad value ${enableval} for multilib option) ;;
- esac], [test -z $with_target_subdir multilib=no || multilib=yes])dnl
-
AC_ARG_WITH(system-zlib,
[ --with-system-zlib use installed libz])
and do a...
cd libgfortran
aclocal -I ../config
autoconf -I ../config
cd ..
cd zlib
aclocal -I ../config
autoreconf -I ../config
cd ..
before I run configure. I have worked out a similar patch for configure.ac in
libjava which I will test next on a build with the java language included.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
[Bug bootstrap/26814] Bootstrapping with a non default ABI (-m64 on ppc-darwin or on ppc-linux with a compiler defaulting to 32 and now defaulting to 64)
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2006-11-03 03:36 --- After patching configure.ac and regenerating configure in zlib with... aclocal -I ../config autoreconf -I ../config I find that I don't get a zlib subdirectory in the powerpc-apple-darwin8 build directory anymore. I am assuming that the patch has freed the gcc build to use the system zlib instead. Interestingly, if I compare what I see on i386 linux, I don't see a zlib build subdirectory created for a stock gcc 4.2 build there. However if I look at a build on x86_64, I see a zlib build subdirectory which suggests I may have fixed a bug in the build of zlib on multilib systems with this zlib patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
[Bug fortran/29689] gfortran should use g77-compatible format for error message
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-11-03 04:07 --- I will give it a spin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
[Bug libstdc++/29688] resize initializes whole array
--- Comment #5 from fang at csl dot cornell dot edu 2006-11-03 07:28 --- There is no argument against the ISO standard, but to a non C/C++ programmer it seems a waist of time to reallocate the array and initialize it when one wants to add something to an array. Some other compilers will copy the existing data into the newly allocated space which seems more in line with the text book. The application will be changed to avoid the loss of data on a resize of arrays, which is a better idea anyway. Thanks for the speedy reply. If you really want efficient appending to a dynamically allocated array, then use std::vector, which is capable of pre-allocating more memory than the number of elements, using the reserve() member function. From looking in the implementation, N push_back operations result in lg N reallocations, by doubling the reserve size each time the capacity is exceeded. vector achieves this by tracking three pointers: beginning, end-of-elements (size), end-of-storage (capacity). valarray is lighter-weight, having only two pointers, beginning- and end-of-storage; thus it must reallocate upon resize (otherwise, how could size() be reported correctly?). I'd only use valarray when the sizeof(container) is crucial and/or the size of the container is unlikely/infrequently to change at run-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29688
[Bug libfortran/27895] problem with RESHAPE and zero-sized arrays
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||11/msg00129.html Keywords||patch Known to fail|4.2.0 4.1.2 |4.2.0 4.1.2 4.3.0 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27895
