[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #65 from steven at gcc dot gnu dot org 2008-05-15 05:59 --- integrated RA : 373.36 (66%) usr 0.33 ( 2%) sys 375.87 (64%) wall 12064 kB ( 2%) ggc 'nuff said. Oh, not entirely yet: IRA should have more than one timevar. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug fortran/36239] New: ICE: gfc_validate_kind(): Got bad kind
James Van Buskirk found the following bug, see http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1cc4ce4ecec2933d integer, parameter :: k_k11 = kind(int(Parg1,kind=k11)) 1 Internal Error at (1): gfc_validate_kind(): Got bad kind module bugmod parameter(ik1 = selected_int_kind(2)) implicit complex (P) contains subroutine bug1(P1) integer(ik1), parameter :: k11 = ik1 complex, parameter :: carg1 = 0 parameter(Parg1 = carg1) integer, parameter :: k_k11 = kind(int(Parg1,kind=k11)) end subroutine bug1 end module bugmod -- Summary: ICE: gfc_validate_kind(): Got bad kind Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-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=36239
[Bug c/36238] New: ICE
[EMAIL PROTECTED] tmp0]$ current-gcc -O small.c
small.c: In function 'func_5':
small.c:27: internal compiler error: in reg_or_subregno, at jump.c:1730
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED] tmp0]$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr
Thread model: posix
gcc version 4.4.0 20080514 (experimental) (GCC)
[EMAIL PROTECTED] tmp0]$ cat small.c
typedef signed char int8_t;
typedef int int32_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
int32_t g_19 = 0x67F5AEE0L;
uint16_t g_169 = 0x89E3L;
const volatile uint32_t g_258 = 0x63AFEBCAL;
int32_t func_11;
int32_t func_29;
int32_t
func_5 (int32_t p_6, int32_t p_8, uint16_t p_10)
{
if (lshift_s_s (func_11, p_8))
{
int8_t l_18 = 0x6FL;
if (l_18)
for (p_6 = -14;; g_19 += 6)
{
int32_t l_283 = -1L;
if (((0x45L / 1L) > 0x07414511L * 1L / 1L > func_29) / 1L)
for (p_8 = 6;; p_8 -= 5)
l_283 = 0xC90541F7L;
}
}
else
g_169 = g_258;
}
--
Summary: ICE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
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=36238
[Bug preprocessor/35010] preprocessor loses leading whitespace
--- Comment #2 from neil at gcc dot gnu dot org 2008-05-15 02:56 --- Never mind, I see your point. The comma isn't being eaten, right. -- neil at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-15 02:56:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010
[Bug preprocessor/35010] preprocessor loses leading whitespace
--- Comment #1 from neil at gcc dot gnu dot org 2008-05-15 02:54 --- Chris - unless I'm missing something I disagree. The , ## __VA_ARGS__ token sequence is being eaten in its entirety by the empty argument. Then between "format" and the ')' on the #define line, which is the ')' that appears on the output, there is no whitespace. It seems GCC's output is correct to me. -- neil at gcc dot gnu dot org changed: What|Removed |Added CC||neil at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #64 from lucier at math dot purdue dot edu 2008-05-15 02:51 --- Created an attachment (id=15640) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15640&action=view) statistics for ira branch with -fira This is the output of the command in the previous comment with -fira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #63 from lucier at math dot purdue dot edu 2008-05-15 02:50 --- Created an attachment (id=15639) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15639&action=view) statistics for ira branch with -fno-ira This is the output of the command in the previous comment with -fno-ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #62 from lucier at math dot purdue dot edu 2008-05-15 02:48 --- I thought I might test the ira branch with euler-3% /pkgs/gcc-ira/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../ira/configure --enable-checking=release --with-gmp=/pkgs/gmp-4.2.2/ --with-mpfr=/pkgs/gmp-4.2.2/ --prefix=/pkgs/gcc-ira --enable-languages=c --enable-gather-detailed-mem-stats Thread model: posix gcc version 4.4.0 20080328 (experimental) [ira revision 135280] (GCC) The command line was /pkgs/gcc-ira/bin/gcc -fno-ira -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -ftime-report -fmem-report -c all.i with -fira and with -fno-ira. The ira branch takes a lot longer to compile this code with -fira than without it; the relevant lines seem to be: for -fira: integrated RA : 373.36 (66%) usr 0.33 ( 2%) sys 375.87 (64%) wall 12064 kB ( 2%) ggc TOTAL : 563.8515.94 582.98 763565 kB for -fno-ira: local alloc : 8.42 ( 4%) usr 0.03 ( 0%) sys 8.43 ( 4%) wall 7073 kB ( 1%) ggc global alloc : 20.91 (11%) usr 0.30 ( 2%) sys 21.23 (10%) wall 4961 kB ( 1%) ggc TOTAL : 196.2517.55 213.84 766052 kB I'll add the complete reports as the next two attachments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug testsuite/28032] gfortran.dg/secnds.f test not honoring dg-options flag
--- Comment #3 from janis at gcc dot gnu dot org 2008-05-15 00:42 --- The test is being run with "-O0 -O0 -ffloat-store", then "-O1 -O0 -ffloat-store", and so on through the torture options used for the gfortran.dg tests. I recommend removing "-O0" from dg-options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #10 from hp at gcc dot gnu dot org 2008-05-14 23:58 --- Worked again with trunk as of r134973, stopped working again as in comment #7 with r135298. I don't see any signs of this bug actively fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug testsuite/30401] FAIL: gfortran.dg/gnu_logical_1.F -O0 (test for excess errors)
--- Comment #1 from janis at gcc dot gnu dot org 2008-05-14 23:37 --- This failure was apparently only for GCC 4.0.3 so I'm closing this. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30401
[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-05-14 23:24 --- (In reply to comment #5) > Patch by FX: > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00546.html > > My review: > http://gcc.gnu.org/ml/fortran/2008-03/msg00232.html Your second point in the review is spot on, the patch is certainly not doing the right thing (the trans-expr.c part, at least) :( I've spent some time looking into other options, but this is all too confusing: I wonder if we shouldn't have made these derived types into structures all the way, instead of trying to morph things into pointer types when comes code generation. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2008- | |03/msg00546.html| Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199
[Bug testsuite/27706] gcc.dg/pr27095.c scan-assembler-not (?n)strlen(.*\n)+.*strlen fails
--- Comment #2 from janis at gcc dot gnu dot org 2008-05-14 22:29 --- Steve Ellcey fixed this in r114467. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27706
[Bug fortran/36059] -frepack-arrays: symbols w/ TARGET should not be repacked
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-14 21:47 --- Fixed on 4.4. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36059
[Bug fortran/36059] -frepack-arrays: symbols w/ TARGET should not be repacked
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-14 21:45 --- Subject: Bug 36059 Author: fxcoudert Date: Wed May 14 21:44:36 2008 New Revision: 135310 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135310 Log: PR fortran/36059 * trans-decl.c (gfc_build_dummy_array_decl): Don't repack arrays that have the TARGET attribute. * gfortran.dg/repack_arrays_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/repack_arrays_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36059
[Bug fortran/36186] Wrong handling of BOZ in CMPLX
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-14 21:37 --- Fixed on 4.4. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36186
[Bug fortran/36186] Wrong handling of BOZ in CMPLX
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-14 21:37 --- Subject: Bug 36186 Author: fxcoudert Date: Wed May 14 21:36:26 2008 New Revision: 135308 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135308 Log: PR fortran/36186 * simplify.c (only_convert_cmplx_boz): New function. (gfc_simplify_cmplx, gfc_simplify_complex, gfc_simplify_dcmplx): Call only_convert_cmplx_boz. * gfortran.dg/boz_11.f90: New test. * gfortran.dg/boz_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/boz_11.f90 trunk/gcc/testsuite/gfortran.dg/boz_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36186
[Bug fortran/36233] [Regression 4.4,4.3] Array valued actual procedure argument rejected
--- Comment #5 from pault at gcc dot gnu dot org 2008-05-14 21:33 --- Subject: Bug 36233 Author: pault Date: Wed May 14 21:32:53 2008 New Revision: 135307 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135307 Log: 2008-05-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/36233 * interface.c (compare_actual_formal): Do not check sizes if the actual is BT_PROCEDURE. 2008-05-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/36233 * gfortran.dg/actual_procedure_1.f90: New test Added: trunk/gcc/testsuite/gfortran.dg/actual_procedure_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36233
[Bug fortran/35682] assignment to run-time zero-sized complex section stores a value
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-05-14 21:22 --- Fixed on 4.4. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35682
[Bug fortran/35682] assignment to run-time zero-sized complex section stores a value
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-05-14 21:21 --- Subject: Bug 35682 Author: fxcoudert Date: Wed May 14 21:20:10 2008 New Revision: 135306 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135306 Log: PR fortran/35682 * trans-array.c (gfc_conv_ss_startstride): Any negative size is the same as zero size. (gfc_conv_loop_setup): Fix size calculation. * gfortran.dg/bound_4.f90: New test. * gfortran.dg/bounds_check_14.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bound_4.f90 trunk/gcc/testsuite/gfortran.dg/bounds_check_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35682
[Bug fortran/35685] UBOUND incorrect for run-time zero-sized section
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-14 21:20 --- Fixed on 4.4. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35685
[Bug fortran/35685] UBOUND incorrect for run-time zero-sized section
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-14 21:18 --- Subject: Bug 35685 Author: fxcoudert Date: Wed May 14 21:17:54 2008 New Revision: 135305 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135305 Log: PR fortran/35685 * trans-intrinsic.c (gfc_conv_intrinsic_bound): Correctly handle zero-size sections. * gfortran.dg/bound_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bound_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35685
[Bug c++/36237] internal compiler error: in lower_stmt, at gimple-low.c:282
--- Comment #2 from silviug at gmail dot com 2008-05-14 21:11 --- (In reply to comment #1) > Created an attachment (id=15638) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15638&action=view) [edit] > Archive containing source code wich generated the bug, makefile and *.ii > files. > The problem comes from the following lines from 'qsort_openmp_v2.cpp' file: 121:#pragma omp parallel shared(vec, globalTodoStack, \ 122:numBusyThreads) private(localTodoStack) More precisely, if I erase 'private(localTodoStack)' it compiles successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36237
[Bug c++/36237] internal compiler error: in lower_stmt, at gimple-low.c:282
--- Comment #1 from silviug at gmail dot com 2008-05-14 21:06 --- Created an attachment (id=15638) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15638&action=view) Archive containing source code wich generated the bug, makefile and *.ii files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36237
[Bug c++/36237] New: internal compiler error: in lower_stmt, at gimple-low.c:282
* the exact version of GCC; * the system type; * the options given when GCC was configured/built; The output of g++ -v is: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) * the complete command line that triggers the bug; The command is simply `make' wich will turn into: g++ -Wall -O0 -fopenmp qsort_openmp_v2.cpp utils.o -o qsort_openmp_v2 * the compiler output (error messages, warnings, etc.); and qsort_openmp_v2.cpp: In function int main(int, char**): qsort_openmp_v2.cpp:0: internal compiler error: in lower_stmt, at gimple-low.c:282 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . make: *** [qsort_openmp_v2] Error 1 * the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below). I will attach them. -- Summary: internal compiler error: in lower_stmt, at gimple- low.c:282 Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: silviug at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36237
[Bug fortran/36233] [Regression 4.4,4.3] Array valued actual procedure argument rejected
--- Comment #4 from pault at gcc dot gnu dot org 2008-05-14 20:44 --- (In reply to comment #3) > (In reply to comment #2) > Jerry, > > In the clear light of day, I think that I need to separate the character and > the array checks. I'll check the standard and try other compilers - once I 'm > happy, I'll commit. > It's OK as it is. Full testcase regtesting now. 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-14 20:44:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36233
[Bug target/36004] alpha doesn't see stores, through other variables, for "struct hack"
--- Comment #4 from oliver at linux-kernel dot at 2008-05-14 19:41 --- (In reply to comment #3) > (In reply to comment #2) > > Regarding gnat; Can we use this ticket for tracking the problem? > > No, please file a new bug. Or is this the same as PR 36025? Oh yes. Sorry, forgot, that I already opened a bz for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36004
[Bug c++/36236] New: ICE with forwarding variadic function template in class template
The following triggers an ICE when forwarded_foo is a template.
#include
template< typename Type >
Type& lvalue_of();
char foo( int );
// Note: void is just a dummy type, any argument causes error.
template< typename = void >
class forwarded_foo
{
public:
template< typename ... Param >
decltype( foo( std::forward< Param >( lvalue_of< Param >() )... ) )
operator ()( Param&&... arg ) const;
};
int main()
{
forwarded_foo<> bar;
bar( 0 );
}
../main.cpp: In instantiation of forwarded_foo:
../main.cpp:20: instantiated from here
../main.cpp:15: internal compiler error: in tsubst, at cp/pt.c:9421
--
Summary: ICE with forwarding variadic function template in class
template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mcalabrese_gp at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36236
[Bug other/36210] [4.3/4.4 Regression] as doesn't like the assembler code
--- Comment #5 from bunk at stusta dot de 2008-05-14 18:30 --- I can confirm that it's fixed. -- bunk at stusta dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36210
[Bug fortran/36234] Support g77's "complex function name*16" syntax
--- Comment #1 from kargl at gcc dot gnu dot org 2008-05-14 17:43 --- I'd vote against supporting this very questionable extension. It may be better to add a section to the manual that documents this extension works with g77 and is not supported by gfortran. I've compiled a large amount of the F77 code found on netlib with gfortran. This extension never triggered an error, so I suspect that it is very rarely used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36234
[Bug middle-end/36235] Invalid optimization related to heavy function inlining with -O3
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-14 16:54 --- Can you try 4.3.0? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Component|c++ |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36235
[Bug c++/36235] Invalid optimization related to heavy function inlining with -O3
--- Comment #1 from cxl at ntllib dot org 2008-05-14 16:52 --- (fixed compiler version) -- cxl at ntllib dot org changed: What|Removed |Added Version|4.1.3 |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36235
[Bug c++/36235] New: Invalid optimization related to heavy function inlining with -O3
g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Used flags:
-ggdb -g2 -fexceptions -O3 -x c++
Code (has to be in 4 files to keep inlining constelation):
-
CGGBug.h
#include
#include
#include
#include
template inline const T& my_max(const T& a, const T& b) { return a >
b ? a : b; }
template inline const T& my_min(const T& a, const T& b) { return a <
b ? a : b; }
template
inline T minmax(T x, T _min, T _max) { return my_min(my_max(x, _min), _max); }
void *MemoryAllocSz(size_t& sz);
void MemoryFree(void *);
template
class Vector {
T *vector;
int items;
int alloc;
static void RawFree(T *ptr){ if(ptr) MemoryFree(ptr); }
static T *RawAlloc(int& n);
void RawInsert(int q, int count);
public:
void InsertN(int q, int count);
const T& First() { return vector[0]; }
int GetCount() const { return items; }
Vector() { vector = NULL; items = alloc = 0; }
};
template
T * Vector::RawAlloc(int& n)
{
size_t sz0 = n * sizeof(T);
size_t sz = sz0;
void *q = MemoryAllocSz(sz);
n += (int)((sz - sz0) / sizeof(T));
return (T *)q;
}
template
void Vector::RawInsert(int q, int count)
{
if(!count) return;
if(items + count > alloc) {
T *newvector = RawAlloc(alloc = alloc + my_max(alloc, count));
if(vector) {
memcpy(newvector, vector, q * sizeof(T));
memcpy(newvector + q + count, vector + q, (items - q) *
sizeof(T));
RawFree(vector);
}
vector = newvector;
}
else {
memmove(vector + q + count, vector + q, (items - q) *
sizeof(T));
}
items += count;
}
template
void Vector::InsertN(int q, int count)
{
RawInsert(q, count);
}
void *MemoryAllocSz(size_t& sz);
void MemoryFree(void *);
struct Item {
char h[32];
};
struct Bar {
Vector li;
void DoTest(int i, int count);
};
---
GCCBug1.cpp:
#include "GCCBug.h"
char array[256];
void *MemoryAllocSz(size_t& sz)
{
printf("%d\n", sz);
return array;
}
void MemoryFree(void *) {}
-
GCCBug2.cpp:
#include "GCCBug.h"
void Bar::DoTest(int i, int count)
{
li.InsertN(minmax(i, 0, li.GetCount()), my_max(count, 0));
}
GCCBug.cpp:
#include "GCCBug.h"
int main(int argc, char argv[])
{
Bar b;
b.DoTest(0, 1);
return 0;
}
---
This code should print "32" (== sizeof(T)) and it does when compiled -Os, but
compiled -O3 it prints "0". In assembly there seems a bug at the beginning of
inlined "RawAlloc" method around the shift to perform "n * sizeof(T)" multiply.
Note that changing sizeof(T) to something else than power of two makes the code
work as expected.
AMD64 compiler seems to be affected as well.
--
Summary: Invalid optimization related to heavy function inlining
with -O3
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cxl at ntllib dot org
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36235
[Bug fortran/36234] New: Support g77's "complex function name*16" syntax
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d5b81d61b3e39cff ifort, openf95, Sun (legacy mode/"sunf77"), g77 allow the complex FUNCTION name*16() syntax as legacy feature. gfortran currently rejects it and accepts only: complex*16 FUNCTION name() I'm not sure whether one should accept it as legacy extension or not. -- Summary: Support g77's "complex function name*16" syntax Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement 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=36234
[Bug fortran/36215] [4.4 regression] Fortran bootstrap fails on _abs_c4.F90
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-14 14:24 --- (In reply to comment #2) > This removes all valgrind errors under linux and allows compilation of > preprocessed files on mingw (bootstrapped is not yet finished, but it compiled > _abs_c4.F90 OK and is proceeding further). Bootstrap on i586-pc-mingw32 finished OK, I've committed the fix. Sorry for breaking bootstrap. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36215
[Bug fortran/36215] [4.4 regression] Fortran bootstrap fails on _abs_c4.F90
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-14 14:23 --- Subject: Bug 36215 Author: fxcoudert Date: Wed May 14 14:23:01 2008 New Revision: 135294 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135294 Log: PR fortran/36215 * scanner.c (preprocessor_line): Allocate enough memory for a wide string. * gfortran.dg/include_3.f95: New test. Added: trunk/gcc/testsuite/gfortran.dg/include_3.f95 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36215
[Bug fortran/36215] [4.4 regression] Fortran bootstrap fails on _abs_c4.F90
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-14 14:14
---
I forgot to allocate enough memory for wide strings instead of regular string
while unescaping filenames in preprocessor directives, which is fixed by the
following patch:
Index: scanner.c
===
--- scanner.c (revision 135088)
+++ scanner.c (working copy)
@@ -1570,7 +1570,7 @@ preprocessor_line (gfc_char_t *c)
if (unescape)
{
gfc_char_t *s = wide_filename;
- gfc_char_t *d = gfc_getmem (c - wide_filename - unescape);
+ gfc_char_t *d = gfc_get_wide_string (c - wide_filename - unescape);
wide_filename = d;
while (*s)
This removes all valgrind errors under linux and allows compilation of
preprocessed files on mingw (bootstrapped is not yet finished, but it compiled
_abs_c4.F90 OK and is proceeding further).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36215
[Bug fortran/36215] [4.4 regression] Fortran bootstrap fails on _abs_c4.F90
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-14 14:01 --- This one is mine, it's apparently due to my recent wide-characters patch. It can be reproduced on x86_64-linux by compiling the following preprocessed file under valgrind: # 1 "../../../trunk/libgfortran/generated/_abs_c4.F90" # 1 "C:\\msys\\1.0.10\\home\\FX\\ibin\\i586-pc-mingw32\\libgfortran//" # 1 "" # 1 "" # 1 "../../../trunk/libgfortran/generated/_abs_c4.F90" ! Copyright 2002, 2007 Free Software Foundation, Inc. # 1 "./config.h" 1 # 37 "../../../trunk/libgfortran/generated/_abs_c4.F90" 2 # 1 "./kinds.inc" 1 # 38 "../../../trunk/libgfortran/generated/_abs_c4.F90" 2 # 1 "./c99_protos.inc" 1 # 39 "../../../trunk/libgfortran/generated/_abs_c4.F90" 2 elemental function _gfortran_specific__abs_c4 (parm) complex (kind=4), intent (in) :: parm real (kind=4) :: _gfortran_specific__abs_c4 _gfortran_specific__abs_c4 = abs (parm) end function $ valgrind ./libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 s.f95 ==6514== Memcheck, a memory error detector. ==6514== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==6514== Using LibVEX rev 1658, a library for dynamic binary translation. ==6514== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==6514== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==6514== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==6514== For more details, rerun with: -v ==6514== ==6514== Invalid write of size 4 ==6514==at 0x46BCCF: preprocessor_line (scanner.c:1579) ==6514==by 0x46C1E4: load_file (scanner.c:1851) ==6514==by 0x46C524: gfc_new_file (scanner.c:1912) ==6514==by 0x48390F: gfc_init (f95-lang.c:288) ==6514==by 0x6FE768: toplev_main (toplev.c:2039) ==6514==by 0x4B3B4C9: (below main) (in /usr/lib/debug/libc-2.3.6.so) (it evens then manages to crash valgrind with "VALGRIND INTERNAL ERROR" and then "valgrind: the 'impossible' happened"). Thanks Aaron for reporting it, I'll fix it as fast as I can. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-14 14:01:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36215
[Bug bootstrap/34257] --with-sysroot does not change default linux glibc dynamic-linker path
--- Comment #4 from drow at gcc dot gnu dot org 2008-05-14 13:47 --- I agree that a new option would be useful. Something like --target-sysroot to go parallel to --sysroot, with an optional value or a special value "same" or some other way to avoid duplicating the path on the command line. In general you need both -dynamic-linker and -rpath. -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34257
Error
Hi, I'm getting this error: " mkdir -p -- ./libiberty mkdir -p -- ./intl /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments /bin/sh: line 5: [: too many arguments Configuring in intl Configuring in libiberty /bin/sh: /cygdrive/c/Documents: No such file or directory /bin/sh: /cygdrive/c/Documents: No such file or directory make: *** [configure-libiberty] Error 1 make: *** Waiting for unfinished jobs make: *** [configure-intl] Error 1 ../scripts/001-binutils-2.16.1.sh: Failed. " can someone help me please? --
[Bug tree-optimization/36098] [4.4 Regression] 435.gromacs miscompares at -O3
--- Comment #7 from irar at il dot ibm dot com 2008-05-14 12:30 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36098
[Bug tree-optimization/36098] [4.4 Regression] 435.gromacs miscompares at -O3
--- Comment #6 from irar at gcc dot gnu dot org 2008-05-14 12:29 --- Subject: Bug 36098 Author: irar Date: Wed May 14 12:28:53 2008 New Revision: 135290 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135290 Log: PR tree-optimization/36098 * tree-vect-analyze.c (vect_analyze_group_access): Set the gap value for the first load in the group in case of a gap. (vect_build_slp_tree): Check that there are no gaps in loads. Added: trunk/gcc/testsuite/gcc.dg/vect/O3-pr36098.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36098
[Bug tree-optimization/36098] [4.4 Regression] 435.gromacs miscompares at -O3
--- Comment #5 from irar at gcc dot gnu dot org 2008-05-14 12:12 --- Subject: Bug 36098 Author: irar Date: Wed May 14 12:11:21 2008 New Revision: 135288 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135288 Log: PR tree-optimization/36098 * tree-vect-analyze.c (vect_analyze_group_access): Set the gap value for the first load in the group in case of a gap. (vect_build_slp_tree): Check that there are no gaps in loads. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/O3-pr36098.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/vect.exp branches/gcc-4_3-branch/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36098
[Bug target/36004] alpha doesn't see stores, through other variables, for "struct hack"
--- Comment #3 from falk at debian dot org 2008-05-14 11:08 --- (In reply to comment #2) > Regarding gnat; Can we use this ticket for tracking the problem? No, please file a new bug. Or is this the same as PR 36025? -- falk at debian dot org changed: What|Removed |Added CC||falk at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36004
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-14 10:48 --- (In reply to comment #3) > Fortran files should not be put into /usr/local/include or /usr/include. Those > directories are defined for C headers. It is particularly bad to put binary > files there. You're confusing module files and included files. Noone's talking about module files here. > We should instead develop a standard location for Fortran-specific > files, as is done with all non-C languages. For example: > /usr/lib/gfortran/modules /usr/local/lib/gfortran/modules. For modules files, this is not enough: they depend on compiler and compiler version, so you need at least /usr/lib/gfortran/4.4.0/modules, at least. But module files are not intended to be used system-wide, really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug c++/36151] gcc fails to find template specializations within namespace
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-14 10:42 --- (In reply to comment #2) > 1.) I've been unable to find an explanation of this behaviour in ISO/IEC 14882 > or other literature like Stroustrup - The C++ Programming Language. See [temp.dep.res] which is 14.6.4 in C++98. There is nothing more to say here really, the above referenced section explains the whole thing. Basically declarations visible already and in the namespace of the function arguments are the ones in the overloaded set. Thanks, Andrew Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36151
[Bug c++/36151] gcc fails to find template specializations within namespace
--- Comment #2 from juergen dot wallner at philips dot com 2008-05-14
09:23 ---
1.) I've been unable to find an explanation of this behaviour in ISO/IEC 14882
or other literature like Stroustrup - The C++ Programming Language.
Please explain and cite reference: How can a unique name from an enclosing
scope be "hidden" by a namespace?
2.) It also doesen't work the other way around (template classes in namespace):
namespace {
class X
{
public:
void foo() {}
};
template class A
{
public:
T& operator*() { return *m; }
T *m;
};
template class B
{
public:
T& operator*() { return *m; }
T *m;
};
}
template void bar( T& v ) { v.foo(); }
template void bar( B& x ) { bar( *x ); }
template void bar( A& x ) { bar( *x ); }
int main()
{
B< A > m1;
bar( m1 ); // ERROR if class X is in ANY namespace, otherwise OK
A< B > m2;
bar( m2 ); // OK
}
--
3.) A similar and more practical example (working on 4.0.1 but not 4.2.1.):
// io_int.h
void Write( int x )
{
}
// io_vector.h
#include
template void Write(const std::vector &x)
{
for(typename std::vector::const_iterator i=x.begin() ; i!=x.end() ;
++i)
Write(*i);
}
// io_list.h
#include
template void Write(const std::list &x)
{
for(typename std::list::const_iterator i=x.begin() ; i!=x.end() ;
++i)
Write(*i);
}
// main.cc
int main(int argc, char *argv[])
{
std::vector< std::list > o;
Write(o);
}
--
If we were to implement IO functionality for stl containers, someone would have
to forward declare Write functions of ALL containers in every single io_xxx.h,
or the user of this functionality would have to forward declare all write
templates he intends to use prior to including any of the io_xxx.h - all
because the stl containers are inside the std-namespace (which should be
completely irrelevant)
--
juergen dot wallner at philips dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36151
[Bug ada/35645] ICE in gimplify_expr, at gimplify.c:6120
--- Comment #2 from sam at gcc dot gnu dot org 2008-05-14 09:20 --- The code is not legal, adding keyword -- sam at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35645
[Bug tree-optimization/36098] [4.4 Regression] 435.gromacs miscompares at -O3
--- Comment #4 from irar at il dot ibm dot com 2008-05-14 07:04 --- It's a bug in SLP analysis. I am working on a fix. Ira -- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-05-02 05:05:28 |2008-05-14 07:04:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36098
