[Bug middle-end/31699] [4.3 Regression] -march=opteron -ftree-vectorize generates wrong code
--- Comment #10 from irar at gcc dot gnu dot org 2007-06-08 06:31 --- Subject: Bug 31699 Author: irar Date: Fri Jun 8 06:31:39 2007 New Revision: 125560 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125560 Log: Backport from mainline: 2007-05-03 Dorit Nuzman [EMAIL PROTECTED] PR tree-optimization/31699 * tree-vect-analyze.c (vect_update_misalignment_for_peel): Remove wrong code. (vect_enhance_data_refs_alignment): Compute peel amount using TYPE_VECTOR_SUBPARTS instead of vf. * tree-vect-transform.c (vect_gen_niters_for_prolog_loop): Likewise. Added: branches/autovect-branch/gcc/testsuite/gcc.dg/vect/pr31699.c branches/autovect-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-11.c Modified: branches/autovect-branch/gcc/ChangeLog.autovect branches/autovect-branch/gcc/testsuite/ChangeLog.autovect branches/autovect-branch/gcc/testsuite/gcc.dg/vect/vect-floatint-conversion-1.c branches/autovect-branch/gcc/testsuite/gcc.dg/vect/vect-intfloat-conversion-1.c branches/autovect-branch/gcc/testsuite/gcc.dg/vect/vect-iv-4.c branches/autovect-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-1.c branches/autovect-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-4.c branches/autovect-branch/gcc/testsuite/lib/target-supports.exp branches/autovect-branch/gcc/tree-vect-analyze.c branches/autovect-branch/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31699
[Bug libstdc++/32254] New: std::runtime_error thrown by locale()
The following code compiles and run find using my system's
g++-4.1.3 but when compiled with g++-4.2.1 from SVN,
I get
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
//-
#include clocale
#include sstream
int main ()
{
std::wostringstream os;
os.imbue(std::locale());
return 0;
}
//-
--
Summary: std::runtime_error thrown by locale()
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thanate at asu 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=32254
[Bug tree-optimization/32243] [4.3 Regression] ICE in vectorizable_type_promotion, at tree-vect-transform.c:2890
--- Comment #2 from ubizjak at gmail dot com 2007-06-08 07:20 --- Confirmed, fails also on i686 (-O3 -msse2 -ftree-vectorize). Backtrace: #1 0x08686e6e in vectorizable_type_promotion (stmt=0xb7d0624c, bsi=0x0, vec_stmt=0x0) at ../../gcc-svn/trunk/gcc/tree-vect-transform.c:2891 #2 0x086737ad in vect_analyze_operations (loop_vinfo=0xa672c88) at ../../gcc-svn/trunk/gcc/tree-vect-analyze.c:410 #3 0x086788f4 in vect_analyze_loop (loop=0xb7d14170) at ../../gcc-svn/trunk/gcc/tree-vect-analyze.c:2786 #4 0x08428454 in vectorize_loops () at ../../gcc-svn/trunk/gcc/tree-vectorizer.c:2298 #5 0x0827bde3 in execute_one_pass (pass=0x87e01c0) at ../../gcc-svn/trunk/gcc/passes.c:1068 -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-08 07:20:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32243
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #171 from ian at airs dot com 2007-06-08 07:49 ---
Created an attachment (id=13666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13666action=view)
Patch
This variant of the previous patch does better on at least some of the tramp3d
functions. Here we eliminate the CHANGE_DYNAMIC_TYPE_EXPR nodes during the
first aliasing pass, which prevents them from retaining references to local
variables and generally clogging up optimizations.
For this test case it generates the same results as mainline, which was not
true of the previous patch.
typedef __SIZE_TYPE__ size_t;
inline void* operator new(size_t, void* __p) throw() { return __p; }
template class T, int D
class Vector
{
public:
Vector()
{
for (int i = 0; i D; ++i)
new (x_m[i]) T();
}
T operator[](int i) { return x_m[i]; }
private:
T x_m[D];
};
struct sia
{
int ai[3];
};
struct s
{
struct si
{
sia* p;
} asi[3];
float* pd;
};
class c
{
int foo(int, int, int);
s sm;
};
extern void bar(Vectorfloat, 3*, int);
int c::foo(int f1, int f2, int f3)
{
float sum = 0;
for (int i = 0; i 3; ++i)
{
for (int j = 0; j 3; ++j)
{
Vectorfloat, 3 v;
v[0] = 1.0;
v[1] = 2.0;
v[2] = 3.0;
for (int k = 0; k 3; ++k)
{
float f = (f1 * this-sm.asi[0].p-ai[0]
+ f2 * this-sm.asi[1].p-ai[0]
+ f3 * this-sm.asi[2].p-ai[0]);
sum += f * v[k];
}
*this-sm.pd = sum;
}
}
return sum;
}
--
ian at airs dot com changed:
What|Removed |Added
Attachment #13637|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug middle-end/32209] [4.3 Regression] Boot failure Comparing stages 2 and 3 with --disable-checking
--- Comment #12 from rakdver at gcc dot gnu dot org 2007-06-08 07:29 --- Subject: Bug 32209 Author: rakdver Date: Fri Jun 8 07:28:50 2007 New Revision: 125563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125563 Log: PR middle-end/32209 * dominance.c (debug_dominance_tree, debug_dominance_tree_1): New functions. (verify_dominators): Do not change dominance tree. Modified: trunk/gcc/ChangeLog trunk/gcc/dominance.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-08 07:52 --- (In reply to comment #1) no, this is OK (whether it is a good design choice is another thing, I will think about that). I actually have a fix for this issue (the MEM with just index: and offset:) but it is going to wait until after the pointer_plus merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
[Bug fortran/32242] [4.3 Regression] internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:06 --- Patch reverted until Lee comes back, PR assigned to him. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords|ice-on-valid-code | Summary|[4.3 Regression] nternal|[4.3 Regression] internal |compiler error: in |compiler error: in |gfc_conv_variable, at |gfc_conv_variable, at |fortran/trans-expr.c:386|fortran/trans-expr.c:386 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
[Bug fortran/32222] [4.3 Regression] ICE in gfc_trans_assignment_1
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:04 --- (In reply to comment #1) r125316 | fxcoudert | 2007-06-04 22:59:49 +0200 (Mo, 04 Jun 2007) | 31 lines 2007-06-04 Lee Millward [EMAIL PROTECTED] http://gcc.gnu.org/ml/gcc-cvs/2007-06/msg00072.html Patch reverted, bug assigned to Lee so that we don't loose track of it when he reworks the patch. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug target/29953] [SH-4] Perfomance regression in loops. cmp/eq used instead of dt
--- Comment #7 from chrbr at gcc dot gnu dot org 2007-06-08 07:58 --- Subject: Bug 29953 Author: chrbr Date: Fri Jun 8 07:58:41 2007 New Revision: 125564 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125564 Log: PR target/29953 * config/sh/sh.md (doloop_end): New pattern and splitter. * loop-iv.c (simple_rhs_p): Check for hardware registers. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/loop-iv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29953
[Bug tree-optimization/32243] [4.3 Regression] ICE in vectorizable_type_promotion, at tree-vect-transform.c:2890
--- Comment #3 from ubizjak at gmail dot com 2007-06-08 08:02 --- Patch in testing. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-08 07:20:29 |2007-06-08 08:02:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32243
[Bug fortran/32238] [4.3 Regression] ICE in gfc_conv_constant (where() with complex arrays)
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:06 --- Patch reverted until Lee comes back, and bug assigned to him so that he takes care of it in the next round. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords|ice-on-valid-code | Known to fail|4.3.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32238
[Bug target/29953] [SH-4] Perfomance regression in loops. cmp/eq used instead of dt
--- Comment #8 from chrbr at gcc dot gnu dot org 2007-06-08 08:18 --- doloop_optimize does the iv inversion with the doloop_end insn support in the machine description. -- chrbr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29953
[Bug libstdc++/32254] std::runtime_error thrown by locale()
--- Comment #1 from pcarlini at suse dot de 2007-06-08 08:38 --- The only possible explanation is that, at build time, the configury didn't find the required localedata (at least de_DE) or other tests failed, and the generic (instead of gnu) locale model has been selected. In that case the runtime_error is expected. Can you check that? -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
[Bug tree-optimization/32224] [4.3 Regression] ICE in vect_analyze_operations, at tree-vect-analyze.c:374
--- Comment #5 from dorit at gcc dot gnu dot org 2007-06-08 08:58 --- Subject: Bug 32224 Author: dorit Date: Fri Jun 8 08:57:54 2007 New Revision: 125566 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125566 Log: PR tree-optimization/32224 * tree-vect-analyze.c (vect_determine_vectorization_factor): Fail vectorization upon a non GIMPLE_MODIFY_STMT. Added: trunk/gcc/testsuite/gcc.dg/vect/pr32224.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32224
[Bug tree-optimization/32243] [4.3 Regression] ICE in vectorizable_type_promotion, at tree-vect-transform.c:2890
--- Comment #4 from uros at gcc dot gnu dot org 2007-06-08 09:06 --- Subject: Bug 32243 Author: uros Date: Fri Jun 8 09:06:46 2007 New Revision: 125567 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125567 Log: PR tree-optimization/32243 * tree-vect-transform.c (vectorizable_type_promotion): Move check for ncopies after ratio check between nunits_out and nunits_in. (vectorizable_type_demotion): Remove single-use variable scalar_type. testsuite/ChangeLog: PR tree-optimization/32243 * gcc.dg/vect/vect.exp: Add support for -O3 tests. Reset default flags for -Os tests. * gcc.dg/vect/03-vect-pr32243.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/O3-vect-pr32243.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32243
[Bug tree-optimization/32243] [4.3 Regression] ICE in vectorizable_type_promotion, at tree-vect-transform.c:2890
--- Comment #5 from ubizjak at gmail dot com 2007-06-08 09:14 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added CC|ubizjak at gmail dot com| URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg00523.html Status|ASSIGNED|RESOLVED Keywords||patch Known to fail|4.3.0 | Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32243
[Bug fortran/32239] optimize power in loops
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:11 ---
Confirmed. Instead of calls to _gfortran_pow_r4_i4, gfortran should use
__builtin_powi in this case. __builtin_powi is either expanded inline or
implemented by the libgcc powi function which looks like
TYPE
NAME (TYPE x, int m)
{
unsigned int n = m 0 ? -m : m;
TYPE y = n % 2 ? x : 1;
while (n = 1)
{
x = x * x;
if (n % 2)
y = y * x;
}
return m 0 ? 1/y : y;
}
--
rguenth 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-06-08 10:11:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32239
[Bug c++/32241] Compiler segmentation fault when trying to call x.~X(); (X x = f();) in a template
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-08 10:16 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2007-06-08 10:16:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32241
[Bug middle-end/32244] bit-field: optimization BUG
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:28 --- Confirmed. We are wrongly expanding ;; D.2027 = D.2026 32 (insn 18 17 0 (parallel [ (set (reg:DI 59 [ D.2027 ]) (ashift:DI (reg:DI 60 [ D.2026 ]) (const_int 32 [0x20]))) (clobber (reg:CC 17 flags)) ]) -1 (nil) (nil)) without properly truncating the result to 33 bit precision. Not a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||2.95.4 4.1.2 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-06-08 10:28:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32244
[Bug c++/32245] [4.1/4.2/4.3 Regression] wrong POD type initialization with pointer to member
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:36 ---
Confirmed.
{
struct foo x = {.mem1=0, .mem2=-1};
cleanup_point struct foo x = {.mem1=0, .mem2=-1};;
cleanup_point Unknown tree: expr_stmt
bar (x.mem2 == (TARGET_EXPR D.2011, {}).mem2)
;
return retval = 0;
}
2.95 used zero for .mem2 initialization.
--
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
Known to fail||3.3.6 4.1.2 4.2.0
Known to work||2.95.4
Last reconfirmed|-00-00 00:00:00 |2007-06-08 10:36:51
date||
Summary|wrong POD type |[4.1/4.2/4.3 Regression]
|initialization with pointer |wrong POD type
|to member |initialization with pointer
||to member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32245
[Bug c/32246] endless loop due to parsing error
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:39 --- works for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32246
[Bug fortran/32248] [4.3 Regression] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-08 12:56 --- (In reply to comment #2) Also breaks 465.tonto in SPEC2006. I'd say it's 2007-06-04 Lee Millward [EMAIL PROTECTED] Gentlemen, you will see that this patch was reverted this morning because it caused PRs3, 38 42. The trunk, of a few minutes ago, does not exhibit this bug, so I will close it, if you do not mind:) The problem is the REAL((/icell,jcell,kcell/),dp), where Lee's patch screwed up the optional second argument. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32248
[Bug fortran/32248] [4.3 Regression] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-08 12:27 --- Also breaks 465.tonto in SPEC2006. I'd say it's 2007-06-04 Lee Millward [EMAIL PROTECTED] * trans-intrinsic.c (gfc_conv_intrinsic_function_args): Adjust to operate on a stack allocated array for the intrinsic arguments instead of creating a TREE_LIST. Add two new parameters for the array and the number of elements. Update all callers to allocate an array of the correct length to pass in. Update comment. ... what causes it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, lmillward at gcc dot ||gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-06-08 12:27:05 date|| Summary|internal compiler error: in |[4.3 Regression] internal |gfc_trans_assignment_1, at |compiler error: in |fortran/trans-expr.c:3877 |gfc_trans_assignment_1, at ||fortran/trans-expr.c:3877 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32248
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #172 from rguenther at suse dot de 2007-06-08 13:47 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Fri, 8 Jun 2007, ian at airs dot com wrote: --- Comment #171 from ian at airs dot com 2007-06-08 07:49 --- Created an attachment (id=13666) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13666action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13666action=view) Patch This variant of the previous patch does better on at least some of the tramp3d functions. Here we eliminate the CHANGE_DYNAMIC_TYPE_EXPR nodes during the first aliasing pass, which prevents them from retaining references to local variables and generally clogging up optimizations. Quick testing shows that this patch indeed shows better performance. I'll give it complete testing coverage tonight. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #4 from r dot f dot arduini at larc dot nasa dot gov 2007-06-08 14:15 --- Subject: Re: internal compiler error: in gfc_assign_data_value, at fortran/data.c:288 Can you please tell me why the compiler flags tauaero.f:1517 while the problem seems to be associated with the data statement at line 1601? I have tried your suggestion (commenting out the data statement), but the code does not appear to work correctly with this modification. thanks. Bob On Jun 6, 2007, at 4:22 PM, burnus at gcc dot gnu dot org wrote: --- Comment #2 from burnus at gcc dot gnu dot org 2007-06-06 20:22 --- Your example file misses the param module; however, I found it via google: http://www.crseo.ucsb.edu/esrg/pauls_dir/sbdart_browser/html_code/ sbdart/params.f.html The complete package is at: ftp://ftp.icess.ucsb.edu/pub/esrg/sbdart/sbdart_2.4.tar.gz Note: This is a fixed-format Fortran 90 file, not a Fortran 77 file. * * * Using NAG f95 I get the error: Error: tauaero.f, line 1601: WLBAER has already been completely initialised Using g95: In file tauaero.f:1601 data wlbaer/0.,0./ 1 Error: Variable 'wlbaer' at (1) already has an initialization (ifort simply accepts the code.) If one comments out that line 1601, the program actually compiles with gfortran. -- burnus at gcc dot gnu dot org changed: What|Removed |Added -- -- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.2.0 4.1.3 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-06-06 20:22:37 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug fortran/32255] New: warning can't open dynamic library
I down loaded and built a new version of gfortran this morning and now gortran is having trouble finding the dynamic library - /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced from: /usr/local/gfortran/lib/gcc/powerpc-apple-darwin8.9.0/4.3.0/../../../libgfortran.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) [dranta:~/tests] dir% ls /usr/local/gfortran/lib/gcc/powerpc-apple-darwin8.9.0/4.3.0/../../../ gcc libgcc_s_ppc64.1.dylib libgfortran.dylib libgomp.dylib libssp.0.dylib libssp_nonshared.a libgcc_s.1.dyliblibgcc_s_x86_64.1.dylib libgfortran.la libgomp.la libssp.alibssp_nonshared.la libgcc_s.10.4.dylib libgfortran.3.dylib libgomp.1.dylib libgomp.speclibssp.dylib libgcc_s.10.5.dylib libgfortran.a libgomp.a libiberty.a libssp.la [dranta:~/tests] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.9.0 Configured with: ../gcc/configure --disable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070608 (experimental) -- Summary: warning can't open dynamic library Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32255
[Bug fortran/32255] warning can't open dynamic library
--- Comment #1 from dir at lanl dot gov 2007-06-08 14:59 --- I just noticed that programs work anyway - [dranta:~/tests/gfortran-D] dir% rm testioBackspace [dranta:~/tests/gfortran-D] dir% gfortran -o testioBackspace testioBackspace.f /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced from: /usr/local/gfortran/lib/gcc/powerpc-apple-darwin8.9.0/4.3.0/../../../libgfortran.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) [dranta:~/tests/gfortran-D] dir% testioBackspace Number of Tests =4 Number of Tests = 16 Number of Tests = 64 Number of Tests = 256 Number of Tests = 1024 Number of Tests = 4096 Number of Tests =16384 Number of Tests =65536 [dranta:~/tests/gfortran-D] dir% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32255
[Bug fortran/32255] warning can't open dynamic library
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-08 15:13 --- /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced I have seen this problem while regetesting g++. I am not sure, but I think I have reported the problem to the gcc list without answer (couple months ago). Meanwhile I have: lrwxr-xr-x 1 root admin 33 Feb 3 22:30 /libgcc_s.1.dylib - /sw/lib/gcc4/lib/libgcc_s.1.dylib for my install through fink. At first I suspected my hacked fink script, but /libgcc_s.1.dylib may as well be hardcoded in the gcc sources. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32255
[Bug fortran/32255] warning can't open dynamic library
--- Comment #3 from dir at lanl dot gov 2007-06-08 15:32 --- It is something new for me. My last build from 4 days ago did not have the problem - [dranta:~/tests/gfortran-D] dir% gfortran -o testioBackspace testioBackspace.f [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.9.0 Configured with: ../gcc/configure --enable-checking --disable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070604 (experimental) [dranta:~/tests/gfortran-D] dir% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32255
[Bug fortran/32257] New: Scoping problem in implied do loop in I/O statement
The following program exposes a problem with the scoping of the loop variable in the IO statement: program test implicit none character(len=100) :: value integer, dimension(100) :: intvalues integer i i = 2 intvalues = 42 value = 2 5 69 write(*,*) len(trim(value)) read(value,*,end=20,err=20) (intvalues(i),i=1,100) 20 i=i-1 ! ! This should print 1 2 5 69 ! write(*,*) i, intvalues(1:3) ! ! This prints the expected output 1 1 100 ! i = 1 intvalues = (/ (i,i=1,100) /) print *, i, intvalues(1), intvalues(100) end program test -- Summary: Scoping problem in implied do loop in I/O statement Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Magnus dot Hagdorn at marsupium dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32257
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #5 from brolley at redhat dot com 2007-06-08 15:41 --- OK, I've looked into this a bit more. For inspiration I looked into where the error is generated when an incomplete struct is used instead of an unsized array. I found it in: cxx_incomplete_type_diagnostic called by complete_type_or_else called by build_new_1 I also discovered that this sequence of calls should have detected an unsized array and generated the message we want. The reason it didn't is because this knowledge is forgotten in cp_parser_new_type_id (in the case of new A) or in build_new_1 (in the case of new (A)) when the top level array bound is stripped off. This is done (in both cases) before complete_type_or_else is called. Now, the transformation in cp_parser_new_type_id is unnecessary since the same transformation is done in build_new_1 and (as noted above) it is not performed in the case of new (A). This gives us the opportunity to generate the error in build_new_1 by calling complete_type_or_else before the transformation. I'm attaching a patch which implements these two changes. The patch generates the error 31743.C:2: error: invalid use of array with unspecified bounds which is analogous to the message generated when an incomplete struct is used. Andrew's patch is not necessary for the generation of the error, but it makes sense to punt early in array_type_nelts_top when dealing with error_mark_node regardless. Tested against the trunk with no regressions in make check-gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #7 from brolley at redhat dot com 2007-06-08 15:46 --- Small optimization. We need only call complete_type_or_else once we know it's an array type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #6 from brolley at redhat dot com 2007-06-08 15:42 --- Created an attachment (id=13667) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13667action=view) New proposed patch -- brolley at redhat dot com changed: What|Removed |Added Attachment #13659|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug fortran/32255] warning can't open dynamic library
--- Comment #4 from dominiq at lps dot ens dot fr 2007-06-08 15:35 --- You may also have a look to PR30572. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32255
[Bug c++/32256] New: pragma system_header doesn't suppress warnings in tree-cfg
Hi, this header (header.h):
#pragma GCC system_header
int noreturn() { }
included by (file.cc):
#include header.h
void ok() { }
Leads to:
paolo:~/Work g++ -Wall -c file.cc
header.h: In function 'int noreturn()':
header.h:2: warning: control reaches end of non-void function
Note, this problem doesn't happen if file.cc is compiled as C, thus the problem
apparently is the C++ front-end not setting TREE_NO_WARNING on the decl or
something similar...
--
Summary: pragma system_header doesn't suppress warnings in tree-
cfg
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32256
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #8 from brolley at redhat dot com 2007-06-08 15:47 --- Created an attachment (id=13668) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13668action=view) Improvement on previous patch -- brolley at redhat dot com changed: What|Removed |Added Attachment #13667|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c/32258] New: Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied the most recent patches. My version is 2.2.1-p5 . I get this as a result of make -i check: FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O0 scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O1 scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O2 scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O3 -fomit-frame-pointer scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O3 -g scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -Os scan-tree-dump pow Here are a couple of my results from a while ago, and recent: Results for 4.3.0 20070601 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00073.html Results for 4.3.0 20070521 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01083.html Here are some other people's results - some used the --with-mpfr option: Compiled using --with-mpfr=/remote/atg5/jbuck/mpfr-linux : Results for 4.3.0 20070608 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00396.html Results for 4.3.0 20070608 (experimental) testsuite on ia64-suse-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00391.html Compiled using --with-gmp=/opt/gcc-nightly/gmp-mpfr --with-mpfr=/opt/gcc-nightly/gmp-mpfr: Results for 4.3.0 20070608 (experimental) testsuite on powerpc64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00387.html The other people don't seem to have this error occur. I have no reason to think they are using a more recent version of mpfr - since there is none. Perhaps they are using an older version. Looking at the surrounding log entries (edited for similarity of test type): Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/torture/builtin-noret-2.c -Os -fno-show-column -lm -o builtin-noret-2.exe(timeout = 300) PASS: gcc.dg/torture/builtin-noret-2.c -Os (test for excess errors) Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/torture/builtin-pow-mpfr-1.c -Os -fdump-tree-original -fno-show-column -S -o builtin-pow-mpfr-1.s (timeout = 300) PASS: gcc.dg/torture/builtin-pow-mpfr-1.c -Os (test for excess errors) FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -Os scan-tree-dump pow Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/torture/builtin-power-1.c -Os -ffast-math -fno-show-column -lm -o builtin-power-1.exe(timeout = 300) PASS: gcc.dg/torture/builtin-power-1.c -Os (test for excess errors) I notice that this one test is applied differently than the surrounding ones. With the constant folding difficulties we are having at the moment (on i686-pc-linux-gnu) we might want to check the folding on the other tests too. -- Summary: Testsuite reports - FAIL: gcc.dg/torture/builtin-pow- mpfr-1.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug c++/32256] pragma system_header doesn't suppress warnings in tree-cfg
--- Comment #1 from pcarlini at suse dot de 2007-06-08 16:53 --- In fact, the problem is of the same type of that in C++/30500: in C++ only when execute_warn_function_return begins in_system_header is zero (in C is 1 and all the warnings are suppressed because diagnostic_report_warnings_p is false) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32256
[Bug tree-optimization/32224] [4.3 Regression] ICE in vect_analyze_operations, at tree-vect-analyze.c:374
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-08 16:51 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32224
Re: [Em28xx] Compil problemes
Hi, maybe someone of the gcc bugs group can help you, this bug is unrelated to the video4linux/em28xx project. Maybe retrying to compile the code might fix it, (I would try to run memcheck and checking for faulty memory) Markus On 6/8/07, Romain Fluttaz [EMAIL PROTECTED] wrote: Hi, i'm under a fresh feisty install, kernel : 2.6.20-16, and then i've got a probleme ... (before this : sudo apt-get install make gcc build-essential mercurial libxine1-ffmpeg dvb-utils kaffeine linux-headers-$(uname -r) ) then : [EMAIL PROTECTED]:~/.dvb$ hg clone http://mcentral.de/hg/~mrec/v4l-dvbdestination directory: v4l-dvb requesting all changes adding changesets adding manifests adding file changes added 5877 changesets with 16335 changes to 1205 files 913 files updated, 0 files merged, 0 files removed, 0 files unresolved [EMAIL PROTECTED]:~/.dvb$ cd v4l-dvb/ [EMAIL PROTECTED]:~/.dvb/v4l-dvb$ ls COPYING linux Makefile README.HG v4l v4l_experimental INSTALL mailimport READMEREADME.patches v4l2-apps [EMAIL PROTECTED]:~/.dvb/v4l-dvb$ make make -C /home/lou/.dvb/v4l-dvb/v4l make[1]: entrant dans le répertoire « /home/lou/.dvb/v4l-dvb/v4l » scripts/make_makefile.pl No version yet. Updating/Creating .config Preparing to compile for kernel version 2.6.20 ***WARNING:*** You do not have the full kernel sources installed. This does not prevent you from building the v4l-dvb tree if you have the kernel headers, but the full kernel source may be required in order to use make menuconfig / xconfig / qconfig. If you are experiencing problems building the v4l-dvb tree, please try building against a vanilla kernel before reporting a bug. Vanilla kernels are available at http://kernel.org. On most distros, this will compile a newly downloaded kernel: cp /boot/config-`uname -r` your kernel dir/.config cd your kernel dir make all modules_install install Please see your distro's web site for instructions to build a new kernel. VIDEO_PLANB: Requires at least kernel 2.6.99 Created default (all yes) .config file ./scripts/make_myconfig.pl make[1]: quittant le répertoire « /home/lou/.dvb/v4l-dvb/v4l » make[1]: entrant dans le répertoire « /home/lou/.dvb/v4l-dvb/v4l » perl scripts/make_config_compat.pl /lib/modules/2.6.20-16-generic/build ./.myconfig ./config-compat.h creating symbolic links... ln -sf . oss make -C /lib/modules/2.6.20-16-generic/build SUBDIRS=/home/lou/.dvb/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.20-16-generic' CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop-pci.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop-usb.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop-fe-tuner.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop-i2c.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop-sram.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop-eeprom.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop-misc.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop-hw-filter.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/flexcop-dma.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/bttv-driver.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/bttv-cards.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/bttv-if.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/bttv-risc.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/bttv-vbi.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/bttv-i2c.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/bttv-gpio.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/bttv-input.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cpia2_v4l.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cpia2_usb.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cpia2_core.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx25840-core.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx25840-audio.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx25840-firmware.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx25840-vbi.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx88-video.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx88-vbi.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx88-mpeg.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx88-cards.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx88-core.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx88-i2c.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx88-tvaudio.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/cx88-input.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/dvbdev.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/dmxdev.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/dvb_demux.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/dvb_filter.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/dvb_ca_en50221.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/dvb_frontend.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/dvb_net.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/dvb_ringbuffer.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/dvb_math.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/av7110_hw.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/av7110_v4l.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/av7110_av.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/av7110_ca.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/av7110.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/av7110_ipack.o CC [M] /home/lou/.dvb/v4l-dvb/v4l/av7110_ir.o CC [M]
[Bug c/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-08 17:14 --- (In reply to comment #0) I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied the most recent patches. My version is 2.2.1-p5. What does p4 do? -- kargl at gcc dot gnu dot org changed: What|Removed |Added Summary|Testsuite reports - FAIL: |Testsuite reports - FAIL: |gcc.dg/torture/builtin-pow- |gcc.dg/torture/builtin-pow- |mpfr-1.c|mpfr-1.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B
--- Comment #7 from rask at sygehus dot dk 2007-06-08 17:35 --- Created an attachment (id=13669) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13669action=view) Patch v3 to add -L and -B as necessary This patch should fix the mep* case that I accidentally deleted. -- rask at sygehus dot dk changed: What|Removed |Added Attachment #13642|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
[Bug c/32259] New: GCC 4.3.0 20070607 - FAIL: gcc.c-torture/execute/20050316-2.c execution
I checked http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16104 which is for gcc.c-torture/execute/20050316-1.c and this is not related. In this test optimization levels -O0, -O1 and -O2 are broken, levels -O3 and -Os are OK. I am using rtl and rtlflag checking. # gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-examples --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-tune=athlon-xp --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree : (reconfigured) /root/downloads/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-examples --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-tune=athlon-xp --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.3.0 20070607 (experimental) Here is part of my log file: Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050316-2.c -w -O0 -fno-show-column -lm -o /opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050316-2.x0(timeout = 300) PASS: gcc.c-torture/execute/20050316-2.c compilation, -O0 Setting LD_LIBRARY_PATH to :/opt/gcc-4_3-build-2/gcc::/opt/gcc-4_3-build-2/gcc:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build-2/./gcc:/opt/gcc-4_3-build-2/./prev-gcc FAIL: gcc.c-torture/execute/20050316-2.c execution, -O0 Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050316-2.c -w -O1 -fno-show-column -lm -o /opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050316-2.x1(timeout = 300) PASS: gcc.c-torture/execute/20050316-2.c compilation, -O1 Setting LD_LIBRARY_PATH to :/opt/gcc-4_3-build-2/gcc::/opt/gcc-4_3-build-2/gcc:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build-2/./gcc:/opt/gcc-4_3-build-2/./prev-gcc FAIL: gcc.c-torture/execute/20050316-2.c execution, -O1 Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050316-2.c -w -O2 -fno-show-column -lm -o /opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050316-2.x2(timeout = 300) PASS: gcc.c-torture/execute/20050316-2.c compilation, -O2 Setting LD_LIBRARY_PATH to :/opt/gcc-4_3-build-2/gcc::/opt/gcc-4_3-build-2/gcc:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build-2/./gcc:/opt/gcc-4_3-build-2/./prev-gcc FAIL: gcc.c-torture/execute/20050316-2.c execution, -O2 Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050316-2.c -w -O3 -fomit-frame-pointer -fno-show-column -lm -o
[Bug tree-optimization/32169] [4.3 Regression] Ice in set_value_range, at tree-vrp.c:326
--- Comment #4 from ian at airs dot com 2007-06-08 17:57 --- I'm testing this patch. Index: tree-vrp.c === --- tree-vrp.c (revision 125521) +++ tree-vrp.c (working copy) @@ -2208,6 +2208,8 @@ extract_range_from_unary_expr (value_ran is_gimple_val (new_max) tree_int_cst_equal (new_min, orig_min) tree_int_cst_equal (new_max, orig_max) + (!is_overflow_infinity (new_min) + || !is_overflow_infinity (new_max)) (cmp = compare_values (new_min, new_max)) = 0 cmp = -1) -- ian at airs dot com changed: What|Removed |Added CC|ian at gcc dot gnu dot org |ian at airs dot com Last reconfirmed|2007-06-06 23:04:14 |2007-06-08 17:57:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32169
[Bug java/32250] %s substituted with interface/array can't be properly translated
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:35 --- I'm closing this, because parse.y no longer exists on svn trunk. If you find instances of this bug in the remaining parts of gcj, please file a new PR. Thanks. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32250
[Bug java/32249] %s substituted with interface/class can't be properly translated
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:36 --- I'm closing this, because parse.y no longer exists on svn trunk. If you find instances of this bug in the remaining parts of gcj, please file a new PR. Thanks. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32249
[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of
--- Comment #11 from baldrick at gcc dot gnu dot org 2007-06-08 18:46 --- Thank you both for your explanation to a newbie having no experience with valgrind tool. I have come up with a simpler version which similar to Laurent's. Here it goes. Thanks - but how is it supposed to work? You didn't dirty memory like Laurent did (new+free), so Item will contain null and you'll get a constraint error in Item.all'Valid. [If you are very lucky Item will contain a non-zero value and you will get a segmentation fault]. I just ran your example a few thousand times and never saw anything besides constraint error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug c++/32260] New: too many warning: dereferencing type-punned pointer will break strict-aliasing rules
The following code, compiled with -O2 -Wall (g++ 4.3 as of 20070607),
produces the following unexpected/annoying warning:
test_typeinfo.cpp: In function 'int main()':
test_typeinfo.cpp:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test_typeinfo.cpp:5: warning: unused variable 't'
~ cat test_typeinfo.cpp
#include typeinfo
int main()
{
const std::type_info t = typeid(int);
}
Is this really meant to warn for such a code???
--
Summary: too many warning: dereferencing type-punned pointer will
break strict-aliasing rules
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32260
[Bug c++/30759] [4.1/4.2/4.3 Regression] initializer-list accepted for object of non-POD type
--- Comment #4 from simartin at gcc dot gnu dot org 2007-06-08 18:27 --- Fixed on the mainline. -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30759
[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of
--- Comment #12 from anhvofrcaus at gmail dot com 2007-06-08 19:11 --- You are right Constraint_Error is raised when checking for validity through Item.all'Valid if Item is null. Therefore, using Laurent's to check Item for null is the only way. Either one of these methods verifies that the bug exists. In summary, the program, small or large, behaves the same way although it is an undersired behavior in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug java/32250] %s substituted with interface/array can't be properly translated
--- Comment #2 from goeran at uddeborg dot se 2007-06-08 19:25 --- Ok. I've found a few more in parse.y, but I won't bother to report them then. So far nothing outside this time around, but I have a few hundred messages to go ... :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32250
[Bug c++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 19:50 --- It is also fixed in 3.4.6. Well then it is fixed as 3.3.x is no longer being maintained and has not been for over a year (or two). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug c++/32261] New: Thread race segfault in std::string::append with -O and -s
Compiling with:
g++ -g -O3 gccbug.cpp -pthread -o gccbug -s
Note that removing the -s eliminates the segfault, as does removing
optimizations with -O0.
This occurs with gcc 3.3 and 3.3.6 but does not occur with the gcc 3.2.3
delivered as part of RedHat ES3.0u5. It is also fixed in 3.4.6.
#include pthread.h
#include string
void* thread_function(void*) {
for (int k = 0; k 5; k++) {
std::string my_str;
my_str += foo;
}
return 0;
}
int main()
{
pthread_t thread1, thread2;
pthread_create(thread1, NULL, thread_function, NULL);
pthread_create(thread2, NULL, thread_function, NULL);
void* exitcode;
pthread_join(thread1, exitcode);
pthread_join(thread2, exitcode);
return 0;
}
Example stack trace (as a courtesy to future googlers looking for this issue):
#0 0x00d3d4cc in memcpy () from /lib/libc.so.6
#1 0x00ba9120 in std::string::_Rep::_M_clone (this=0x804a700,
[EMAIL PROTECTED], __res=28) at
/build_gnu_build/gcc-3.3.6/i386-redhat-linux/libstdc++-v3/include/bits/char_traits.h:155
#2 0x00ba7519 in std::string::reserve (this=0xb6bf43b0, __res=28) at
/build_gnu_build/gcc-3.3.6/i386-redhat-linux/libstdc++-v3/include/bits/basic_string.h:257
#3 0x00ba77be in std::string::append (this=0xb6bf43b0, [EMAIL PROTECTED]) at
/build_gnu_build/gcc-3.3.6/i386-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:680
#4 0x08048c21 in ?? ()
#5 0x080490da in ?? ()
#6 0x08049093 in ?? ()
#7 0x08048fa6 in ?? ()
#8 0x003ef9d9 in start_thread (arg=0xb6bf4bb0) at pthread_create.c:261
#9 0x00d86f0e in clone () from /lib/libc.so.6
--
Summary: Thread race segfault in std::string::append with -O and
-s
Product: gcc
Version: 3.3.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: appfault at hotmail dot com
GCC host triplet: 2.4.21-32.ELsmp #1 SMP Fri Apr 15 21:17:59 EDT 2005 i686
i686 i3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug target/32262] New: ICE in convert_memory_address, at explow.c:326 compiling libgfortran
I have configure gcc like this: /n/08/rask/src/gcc/configure --target=m68hc11-none --disable-multilib --disable-nls --with-newlib --enable-sim Building libgfortran fails with this message: libtool: compile: /home/rask/build/gcc-m68hc11-none/./gcc/gfortran -B/home/rask/build/gcc-m68hc11-none/./gcc/ -nostdinc -B/home/rask/build/gcc-m68hc11-none/m68hc11-none/newlib/ -isystem /home/rask/build/gcc-m68hc11-none/m68hc11-none/newlib/targ-include -isystem /n/08/rask/src/gcc/newlib/libc/include -B/home/rask/build/gcc-m68hc11-none/m68hc11-none/libgloss/m68hc11 -L/home/rask/build/gcc-m68hc11-none/m68hc11-none/libgloss/libnosys -L/n/08/rask/src/gcc/libgloss/m68hc11 -B/usr/local/m68hc11-none/bin/ -B/usr/local/m68hc11-none/lib/ -isystem /usr/local/m68hc11-none/include -isystem /usr/local/m68hc11-none/sys-include -L/home/rask/build/gcc-m68hc11-none/./ld -I . -Wall -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -g -O2 -c /n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90 -o selected_int_kind.o /n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90: In function '_gfortran_selected_int_kind': /n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:22: internal compiler error: in convert_memory_address, at explow.c:326 Please submit a full bug report, [...] -- Summary: ICE in convert_memory_address, at explow.c:326 compiling libgfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m68hc11-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32262
[Bug other/32263] New: Document the required versions of glibc and binutils
Document the required versions of glibc and binutils. Typically only a couple versions of glibc and binutils are compatible with each version of gcc, and finding out which ones are compatible is often quite time-consuming. While gcc/doc/gccinstall.info does document some minimum versions, it should also document maximum known-working versions as of the release date of gcc, since later versions invariably regress to being incompatible again. -- Summary: Document the required versions of glibc and binutils Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: appfault at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32263
[Bug other/32263] Document the required versions of glibc and binutils
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 20:16 --- HUH? I had never had any problems with older versions of GCC with newer versions of binutils. If you do then either it is a bug in the older version of GCC (which is likely) or a bug in the newer binutils (which is also likely). If you have issues with either, then you should provide more details. I have used GCC 2.95.3-4.1 with binutils 2.17 (which is quiet new) without any troubles and glibc 2.3.6 with GCC 2.95.3 (which had one issue with respect of locales) to 4.1 without any issues. So I don't see what we need to document here really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32263
[Bug target/32264] New: gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
When Linux vanilla kernel 2.4.34.5 is compiled with -march=c3 (VIA C3) - kernel crashes after boot on a VIA C3 .config: CONFIG_MCYRIXIII=y Environment: System: Linux bongo 2.4.34.5-ARXc3 COHERENT #9-ARX (Build 3359) Fri Jun 8 16:41:33 CEST 2007 i686 i686 i386 GNU/Linux Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu VIA C3 -march=c3 configured with: /home/axel/p/rpm/BUILD/gcc-4.2.0/configure --prefix=/opt/gcc4 --exec-prefix=/opt/gcc4 --srcdir=/home/axel/p/rpm/BUILD/gcc-4.2.0 --enable-shared --enable-languages=c,c++,objc How-To-Repeat: compile vanilla linux kernel 2.4.34.5 with CONFIG_MCYRIXIII=y and boot the kernel on a VIA C3 - crash --- Comment #1 from axel at freakout dot de 2007-06-08 20:17 --- Fix: Compile kernel with gcc 4.1.2 Ok and working with -march=c3 -- Summary: gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: axel at freakout dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu VIA C3 -march=c3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
[Bug other/32263] Document the required versions of glibc and binutils
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 20:18 --- I think we need more information from you about what issues you are running into. I also use glibc 2.3.2 with many different versions of GCC too. I still don't see what regressions you are talking about anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32263
[Bug target/32264] gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 20:19 --- Testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
[Bug target/32264] gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
--- Comment #3 from axel at freakout dot de 2007-06-08 20:25 --- Subject: Re: 03.5: gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3 According to pinskia at gcc dot gnu dot org: --- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 20:19 --- Testcase? I did not want to copy the whole 2.4.34.5 kernel into the case. The whole kernel ist the testcase - it compiles fine and crashes at startup. Identical setup with 4.1.2 works fine. Axel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
[Bug c++/31806] [4.1/4.2 Regression] miscompilation with -fschedule-insns2 -fno-threadsafe-statics
--- Comment #9 from mueller at gcc dot gnu dot org 2007-06-08 21:48 --- Subject: Bug 31806 Author: mueller Date: Fri Jun 8 21:48:34 2007 New Revision: 125580 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125580 Log: 2007-06-08 Dirk Mueller [EMAIL PROTECTED] PR c++/31809 PR c++/31806 Backport from mainline: 2007-05-31 Jakub Jelinek [EMAIL PROTECTED] * decl.c (cp_finish_decl): Also clear was_readonly if a static var needs runtime initialization. 2007-05-30 Jakub Jelinek [EMAIL PROTECTED] * decl.c (cp_finish_decl): Clear TREE_READONLY flag on TREE_STATIC variables that need runtime initialization. PR c++/31809 Backport from mainline: 2007-05-30 Jakub Jelinek [EMAIL PROTECTED] * g++.dg/opt/static5.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/opt/static5.C - copied unchanged from r125201, trunk/gcc/testsuite/g++.dg/opt/static5.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806
[Bug c++/31809] [4.1/4.2 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code
--- Comment #10 from mueller at gcc dot gnu dot org 2007-06-08 21:48 --- Subject: Bug 31809 Author: mueller Date: Fri Jun 8 21:48:34 2007 New Revision: 125580 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125580 Log: 2007-06-08 Dirk Mueller [EMAIL PROTECTED] PR c++/31809 PR c++/31806 Backport from mainline: 2007-05-31 Jakub Jelinek [EMAIL PROTECTED] * decl.c (cp_finish_decl): Also clear was_readonly if a static var needs runtime initialization. 2007-05-30 Jakub Jelinek [EMAIL PROTECTED] * decl.c (cp_finish_decl): Clear TREE_READONLY flag on TREE_STATIC variables that need runtime initialization. PR c++/31809 Backport from mainline: 2007-05-30 Jakub Jelinek [EMAIL PROTECTED] * g++.dg/opt/static5.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/opt/static5.C - copied unchanged from r125201, trunk/gcc/testsuite/g++.dg/opt/static5.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31809
[Bug c++/32265] New: --never_inline and --no_automatic_inline options
No matter how high the optimzation level, --never_inline prevents all inlining, even when called for in source code --no_automatic_inline prevents automatic inlining, i.e. inlining by the compiler when not specifically called for in the source code -- Summary: --never_inline and --no_automatic_inline options Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Dave at Yost dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32265
[Bug c++/32265] --never_inline and --no_automatic_inline options
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 22:14 --- --never_inline prevents all inlining, even when called for in source code -fno-inline (Or do you mean even with attribute always_inline?) --no_automatic_inline prevents automatic inlining, i.e. inlining by the compiler when not specifically called for in the source code -fno-inline-functions -fno-inline-functions-called-once So the options already exist, even in 4.2.0. -- 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=32265
[Bug target/20802] [4.0] mmix-knuth-mmixware testsuite failure: gcc.dg/builtin-apply4.c execution
--- Comment #7 from rob1weld at aol dot com 2007-06-08 23:34 ---
I tried this on i686-pc-linux-gnu using gcc-3.4 (from Debian), gcc-4.1 (from
Debian), gcc version 4.2.0 20070501 (prerelease) (from SVN), and gcc version
4.3.0 20070607 (experimental) (from SVN):
I modified as follows:
/* PR tree-optimization/20076 */
/* { dg-options -O2 } */
/* { dg-do run } */
extern void abort (void);
double
foo (int arg)
{
printf(foo1 - arg = %u \n, arg);
if (arg != 116)
abort();
printf(foo2 - arg = %u \n, arg);
return arg + 1;
}
inline double
bar (int arg)
{
printf(bar1 - arg = %u \n, arg);
foo (arg);
printf(bar2 - arg = %u \n, arg);
__builtin_return (__builtin_apply ((void (*) ()) foo, __builtin_apply_args
(), 128));
__builtin_return (__builtin_apply ((void (*) ()) foo, __builtin_apply_args
(), 32));
__builtin_return (__builtin_apply ((void (*) ()) foo, __builtin_apply_args
(), 16));
printf(bar3 - arg = %u \n, arg);
}
int
main (int argc, char **argv)
{
printf(main1 - pre bar\n);
if (bar (116) != 117.0) {
printf(main2 - post bar - abort\n);
abort ();
}
printf(main2 - post bar - no abort\n);
return 0;
}
The printf statments are the only changes, everything else is the same as
4.3.0.
Here is what the .exe's print for each version of gcc:
# ./builtin-apply4_gcc3.4.exe
main1 - pre bar
bar1 - arg = 116
foo1 - arg = 116
foo2 - arg = 116
bar2 - arg = 116
foo1 - arg = 1
Aborted
# ./builtin-apply4_gcc4.1.exe
main1 - pre bar
bar1 - arg = 116
foo1 - arg = 116
foo2 - arg = 116
bar2 - arg = 116
foo1 - arg = 116
foo2 - arg = 116
main2 - post bar - no abort
# ./builtin-apply4_gcc4.2.exe
main1 - pre bar
bar1 - arg = 116
foo1 - arg = 116
foo2 - arg = 116
bar2 - arg = 116
foo1 - arg = 116
foo2 - arg = 116
main2 - post bar - abort
Aborted
# ./builtin-apply4_4.3.exe
main1 - pre bar
bar1 - arg = 116
foo1 - arg = 116
foo2 - arg = 116
bar2 - arg = 116
foo1 - arg = 116
foo2 - arg = 116
main2 - post bar - abort
Aborted
GCC 3.4 prints foo1 - arg = 1 - which is way off.
GCC 4.1 prints main2 - post bar - no abort - which means it is OK
The others are incorrect. I do not have 4.0.0 to confirm this report but you
might says it was fixed in 4.1 - only to re-occur in later versions :( .
I'd change the known to fail field but I don't have permission.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20802
[Bug c/32266] New: Excessive memory usage (805M!)
I will attach the example in a subsequent comment. If I execute: gcc -O1 -c xf86ScanPci.c it sucks up 805M of virtual memory. No optimization, no problem. gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.0/configure --prefix=/opt/gcc-4.2.0 --enable-threads --with-system-zlib --with-gmp=/opt/gmp-4.2.1 --with-mpfr=/opt/mpfr-2.2.1 --enable-__cxa_atexit Thread model: posix gcc version 4.2.0 -- Summary: Excessive memory usage (805M!) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsberg04+computing dot bugs dot gcc at ftml dot net 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=32266
[Bug middle-end/32266] Excessive memory usage (805M!)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 23:38 --- *** This bug has been marked as a duplicate of 30052 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32266
[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.
--- Comment #32 from pinskia at gcc dot gnu dot org 2007-06-08 23:38 --- *** Bug 32266 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jsberg04+computing dot bugs ||dot gcc at ftml dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug middle-end/32266] Excessive memory usage (805M!)
--- Comment #2 from jsberg04+computing dot bugs dot gcc at ftml dot net 2007-06-08 23:38 --- Created an attachment (id=13670) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13670action=view) Preprocessed, bzip2 compressed example. From Xorg 7.2.0, if anyone cares... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32266
[Bug libstdc++/32254] std::runtime_error thrown by locale()
--- Comment #2 from thanate at asu dot edu 2007-06-08 23:40 --- umm... I don't know how to check for that. But I ran configure with --enable-clocale=gnu. I posted my build log at http://mathpost.asu.edu/~thanate/build.log I'll keep the build dir for a while in case you need some more log files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
[Bug libstdc++/32254] std::runtime_error thrown by locale()
--- Comment #3 from pcarlini at suse dot de 2007-06-09 00:11 --- See this line in the Log: checking for C locale to use... generic That means the configure-time tests for the gnu locale model are not ok and the generic locale model is selected instead, as a fallback. Can you investigate whether the 'de_DE' localedata is installed on your system? It's necessary for those checks. In order to do that you can, for example, run a small C program that does 'setlocale(LC_ALL, de_DE)': it must return a non-NULL pointer. On linux, you can invoke 'localedef --list-archive'. (note that on 4.2.1 vs earlier releases, even if you pass --enable-clocale=gnu explicitely, the system is checked for actual support of the locale model, it cannot be forced: that may explain the unexpected behavior on your side). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
[Bug libstdc++/32254] std::runtime_error thrown by locale()
--- Comment #4 from thanate at asu dot edu 2007-06-09 00:22 --- localedef --list-archive gave me only one line: en_US.utf8 I think that's how I set up my system, with only one locale. Now I'm not sure why should I have to have de_DE installed for locale() to work. But if you want, I can install de_DE and try again and report back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
[Bug libstdc++/32254] std::runtime_error thrown by locale()
--- Comment #5 from pcarlini at suse dot de 2007-06-09 00:26 --- Ok, that is it. That locale must be installed because old glibcs had a bug which showed up clearly with de_DE and we must check against it. The docs explain that, anyway: http://gcc.gnu.org/onlinedocs/libstdc++/install.html -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
[Bug target/32259] GCC 4.3.0 20070607 - FAIL: gcc.c-torture/execute/20050316-2.c execution
--- Comment #1 from rob1weld at aol dot com 2007-06-09 00:57 ---
Here is a related failure this time for gcc.c-torture/execute/20050604-1.c :
# grep --color=always -B16 -A6 20050604-1.c gcc/testsuite/gcc/gcc.log | tail -n
26
Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/
/root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050604-1.c
-w -O3 -fomit-frame-pointer -fno-show-column -lm -o
/opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050604-1.x3(timeout = 300)
PASS: gcc.c-torture/execute/20050604-1.c compilation, -O3 -fomit-frame-pointer
Setting LD_LIBRARY_PATH to
:/opt/gcc-4_3-build-2/gcc::/opt/gcc-4_3-build-2/gcc:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build-2/./gcc:/opt/gcc-4_3-build-2/./prev-gcc
PASS: gcc.c-torture/execute/20050604-1.c execution, -O3 -fomit-frame-pointer
Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/
/root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050604-1.c
-w -O3 -fomit-frame-pointer -funroll-loops -fno-show-column -lm -o
/opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050604-1.x4(timeout = 300)
PASS: gcc.c-torture/execute/20050604-1.c compilation, -O3 -fomit-frame-pointer
-funroll-loops
Setting LD_LIBRARY_PATH to
:/opt/gcc-4_3-build-2/gcc::/opt/gcc-4_3-build-2/gcc:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build-2/./gcc:/opt/gcc-4_3-build-2/./prev-gcc
FAIL: gcc.c-torture/execute/20050604-1.c execution, -O3 -fomit-frame-pointer
-funroll-loops
Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/
/root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050604-1.c
-w -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
-fno-show-column -lm -o /opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050604-1.x5
(timeout = 300)
PASS: gcc.c-torture/execute/20050604-1.c compilation, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
Setting LD_LIBRARY_PATH to
:/opt/gcc-4_3-build-2/gcc::/opt/gcc-4_3-build-2/gcc:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build-2/./gcc:/opt/gcc-4_3-build-2/./prev-gcc
FAIL: gcc.c-torture/execute/20050604-1.c execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/
/root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050604-1.c
-w -O3 -g -fno-show-column -lm -o
/opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050604-1.x6(timeout = 300)
PASS: gcc.c-torture/execute/20050604-1.c compilation, -O3 -g
Setting LD_LIBRARY_PATH to
:/opt/gcc-4_3-build-2/gcc::/opt/gcc-4_3-build-2/gcc:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build-2/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build-2/./gcc:/opt/gcc-4_3-build-2/./prev-gcc
PASS: gcc.c-torture/execute/20050604-1.c execution, -O3 -g
Here is the first PASS: and the next two FAIL:s:
/opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/
/root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050604-1.c
-w -O3 -fomit-frame-pointer -fno-show-column -lm -o
/opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050604-1.x3
PASS: gcc.c-torture/execute/20050604-1.c execution, -O3 -fomit-frame-pointer
/opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/
/root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050604-1.c
-w -O3 -fomit-frame-pointer -funroll-loops -fno-show-column -lm -o
/opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050604-1.x4
FAIL: gcc.c-torture/execute/20050604-1.c execution, -O3 -fomit-frame-pointer
-funroll-loops
/opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/
/root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050604-1.c
-w -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
-fno-show-column -lm -o /opt/gcc-4_3-build-2/gcc/testsuite/gcc/20050604-1.x5
FAIL: gcc.c-torture/execute/20050604-1.c execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
Here is how I modified main() by adding print statements:
int
main (void)
{
foo ();
printf(test1 - 24 = u.s[0] = %u 28 = u.s[1] = %u
u.s[2] = %uu.s[3] = %u $
u.s[0], u.s[1], u.s[2], u.s[3]);
if (u.s[0] != 24 || u.s[1] != 28 || u.s[2] || u.s[3])
[Bug tree-optimization/32200] IV-OPTS does not produce good code for some loops
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-09 02:10 --- This is related to (or a dup of) bug 19590. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||19590 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32200
[Bug middle-end/32267] New: [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
+++ This bug was initially created as a clone of Bug #21291 +++ works with -O0, fails with -O[123]. gcc-4.0.0 + patches for pr20973,21173. I could not reopen http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291 so I thought I'd try clicking on clone this bug since it has re-emerged in 4.2.0 and 4.3.0. The summary is what the origonal was and close enough for me. This bug (which _I_ call GENERAL_REGS ) occurs on 4.2.0 (or greater) when compiling ffmeg in the files: h264.c cabac.h: In function `get_cabac_noinline': cabac.h:513: error: can't find a register in class `GENERAL_REGS' while reloading `asm' h264.c: In function `decode_cabac_residual': h264.c:6143: warning: passing arg 4 of `decode_significance_8x8_x86' discards qualifiers from pointer target type cabac.h:729: error: can't find a register in class `GENERAL_REGS' while reloading `asm' cabac.h:680: error: can't find a register in class `GENERAL_REGS' while reloading `asm' and here: i386/h264dsp_mmx.c: In function `h264_h_loop_filter_luma_mmx2': i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS' while reloading `asm' i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS' while reloading `asm' i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS' while reloading `asm' i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS' while reloading `asm' i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS' while reloading `asm' i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS' while reloading `asm' make[1]: *** [i386/dsputil_mmx.o] Error 1 The fix for ffmpeg is to add -fomit-frame-pointer or change the -O? in the Makefile for these particular files only. Ffmpeg build OK with this fix. The error message about `GENERAL_REGS' comes from file gcc\reload1.c , in function spill_failure(). The error message about impossible constraints comes from the same file in function reload(). The reload() function has a note which reads as follows: /* Clean up invalid ASMs so that they don't confuse later passes. See PR 21299. */ This error also occurs in gcc version 4.3.0 20070607 when the testsuite is used - This is why I am writing this bug report. The testsuite use -O so I compiled the file with each type of optimization: gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -O0 -S -o pr21291-O0.s gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -O1 -S -o pr21291-O1.s pr21291.c: In function 'bng_ia32_mult_sub_digit': pr21291.c:23: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' pr21291.c:23: error: 'asm' operand has impossible constraints gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -O2 -S -o pr21291-O2.s gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -O3 -S -o pr21291-O3.s gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -Os -S -o pr21291-Os.s Only -O1 had trouble. We need to alter the test code to use even MORE registers and alter the expect scripts to check each type of optimization along with other parameters that will use up MORE and LESS registers to _fully_ exercise this test. I did diff -Naur of the reulting .s files and found that of the ones that were created many were not particularly optimized in any event! The diff -Naur pr21291-O0.s pr21291-O2.s showed that -O0 was quite lengthy compared to -O2 - not much of a surprise. The -O2 and -O3 were identical. The diff -Naur pr21291-O2.s pr21291-Os.s is what was interesting. The -Os code was the smallest and fastest it used push/pop instead of a series of movls. If the compiler could detect that it has ran out of registers and make new assignments either get pushed to stack _OR_ stored to a static local memory location then it would have as many 'registers' (real or fake) as it needed. If it could discover that the chosen optimization caused the registers to run out and re-try using a different optimization level and then re-feed the optimized code back into the routine at the chosen optimization level then it may be able to dump un-needed registers from the list - this would be more expensive. Whatever the compiler chooses to do it must NOT fail by running out of registers - it should make best efforts to discover which variables would be best _IF_ they went into registers (as the person who wrote the code requested) and failing to be able to do what the programmer requested to simply use memory space for faking the remaining needed registers. It is not hard to do - unless you would have us beleive that each variable in a program must have it's own register for the whole life of the program, that is not the case. -- Summary: [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm' Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo:
[Bug c/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #2 from rob1weld at aol dot com 2007-06-09 03:17 --- From [EMAIL PROTECTED] I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied the most recent patches. My version is 2.2.1-p5. What does p4 do? They only offer the patches mixed together, interspersed in a single file. I had a quick look at the site and did not spot a patch changelog only a version changelog. The newest patch is recommended and available at: http://www.mpfr.org/mpfr-current/ . P4 might be from last year. You would need to view or disassemble the patch file to see what you would get with only P4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug testsuite/32063] contrib/test_summary script could output results more neatly
--- Comment #4 from rob1weld at aol dot com 2007-06-09 03:27 --- One enhancement I did try was adding this to the end of contrib/test_summary. It does nothing for _me_ since I have the new assembler but for others it would catch the failures and report them. print ; print ---; print Check gcc/testsuite/gcc/gcc.log for Spurious Errors: print grep -e Assembler\\ messages -e Warning -e Error gcc/testsuite/gcc/gcc.log | sort -k 2 -i -u print ; system(grep -e Assembler\\ messages -e Warning -e Error gcc/testsuite/gcc/gcc.log | sort -k 2 -i -u); print ---; print ; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32063
[Bug libmudflap/31845] Need to adjust libmudflap timeout values in testsuite.
--- Comment #2 from rob1weld at aol dot com 2007-06-09 03:45 --- Tried running make -i check on a just-built version of gcc while compiling a newer revision of gcc in a different X-Window. The load was enough to give a number of timeouts in various places. It is inconvenient to be unable to use the computer for anything else while running a check - I can accept that I can't use it when I'm running a timing benchmark but I kinda like to keep the system loaded when I am able to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31845
[Bug c/31741] dfp tests failing - internal compiler error
--- Comment #6 from rob1weld at aol dot com 2007-06-09 03:52 --- Changing From / To: Known to work: (Blank) and Known to fail: 4.2.0 4.2.1 4.3.0 Known to work: 4.3.0 and Known to fail: 4.2.0 4.2.1 Since 4.3.0 works on i686-pc-linux-gnu perfectly - No reason to believe 4.3.0 works on i686-pc-cygwin very well. -- rob1weld at aol dot com changed: What|Removed |Added Known to fail|4.2.0 4.2.1 4.3.0 |4.2.0 4.2.1 Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31741
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #38 from bergner at gcc dot gnu dot org 2007-06-09 04:08 --- Created an attachment (id=13671) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13671action=view) Updated patch to address x86_64 performance issues. This updated patch reverts the swap_commutative_operands_with_target removal from the previous patch, since it seems x86_64 still relies on this for some benchmarks. The change doesn't seem to affect the POWER6 performance benefits we were seeing with the older patch. -- bergner at gcc dot gnu dot org changed: What|Removed |Added Attachment #12915|0 |1 is obsolete|| Attachment #13101|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
