GCC 4.3.0 snapshot 20071221 built with:
../configure --prefix=/usr/local/gcc-4.3-20071221 time make -j3 bootstrap
on Ubuntu 7.10 (AMD64 install) using the system version of GCC
(4:4.1.2-9ubuntu2).
The system is a quad core Intel Core 2 system:
Intel(R) Core(TM)2 Quad CPU @ 2.40GHz
--- Comment #2 from chris at csamuel dot org 2007-12-26 09:02 ---
Just re-read the section on what's not wanted in a bug report, so I won't
attach the .s file after all (unless it's requested later).
--
chris at csamuel dot org changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-12-26 09:36 ---
*** Bug 34589 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-26 09:36 ---
*** This bug has been marked as a duplicate of 10837 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from chris at csamuel dot org 2007-12-26 08:59 ---
Created an attachment (id=14830)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14830action=view)
Preprocessed version of decompress.c from Bzip2 1.0.4
The required .i file from Bzip2 1.0.4 that causes the crash.
--- Comment #12 from ubizjak at gmail dot com 2007-12-26 10:08 ---
Also confirmed on x86_64-pc-linux-gnu:
Program received signal SIGSEGV, Segmentation fault.
find_parameter_packs_r (tp=0x2dfef5e0, walk_subtrees=0x7fff62fefdec,
data=0x7fff62ff0050) at
The attached preprocessor output comes from Pulseaudio 0.9.8. It causes an
internal compile error on Linux x86_64 (Mandriva 2008.1 Cooker) when build with
the -O3 option:
[EMAIL PROTECTED] src]$ gcc4.3 -O3 resample2.i
pulsecore/ffmpeg/resample2.c: In function av_resample:
--- Comment #1 from fhimpe at telenet dot be 2007-12-26 11:32 ---
Created an attachment (id=14831)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14831action=view)
resample2.i file causing internal compiler error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34591
I just tried to bootstrap the GNU C compiler 4.3 snapshot
20071221 with the most excellent Intel C compiler version 10.1
The Intel compiler said
1.
gcc-4.3-20071221/fixincludes/fixincl.c(1049): remark #593: variable name_len
was set but never used
I had a look at the source code and I agree
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-26 13:55 ---
Confirmed, reduced testcase:
int av_resample(int filter_length, short *src, short *filter)
{
int i;
int val=0;
for(i=0; ifilter_length; i++)
val += src[ i ] * filter[i];
return val;
}
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-26 14:01 ---
I always hated this warning from the EDG front-end, it sometimes produces a
false warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34592
--- Comment #7 from reichelt at gcc dot gnu dot org 2007-12-26 14:06
---
*** Bug 34541 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-12-26 14:06
---
This seems to be a duplicate of PR34206.
It has been fixed on mainline between 2007-12-11 and 2007-12-21.
*** This bug has been marked as a duplicate of 34206 ***
--
reichelt at gcc dot gnu dot org changed:
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-12-26 14:26
---
For some reason it works correctly on i386-apple-darwin and powerpc-linux-gnu.
I wonder if something is not miscompiling the C++ front-end.
--
pinskia at gcc dot gnu dot org changed:
What
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-26 14:29 ---
This is correct, return z is an access. I don't see why you would think
otherwise.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-26 14:21 ---
Confirmed, reduced testcase:
struct DState{
unsigned char mtfa [4096];
int mtfbase[256 / 16];
} ;
int makeMaps_d ( struct DState* s, int kk )
{
int ii, jj;
for (ii = 256 / 16 - 1; ii = 0; ii--) {
for
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-12-26 14:24
---
Can't we close this?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-12-26 14:25
---
This should be fixed on trunk.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-26 14:30 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-12-26 14:56
---
This bug has been fixed in GCC 4.1.2.
The problem only affected GCC 4.0.3, 4.1.0, 4.1.1.
The underlying problem was maybe the same as in PR29106.
--
reichelt at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
$ cat simpleif.c
#include stdio.h
extern unsigned int debug_enabled_abc;
int main(int argc, char** argv) {
if (debug_enabled_abc)
printf(Hello World!\n);
return 0;
}
$ cat simple-debug.c
unsigned int debug_enabled_abc = 1;
$gcc -c simpleif.c -o simpleif.o -g -O3
For the following program, the IOSTAT is properly set to /= 0 (namely to -1),
but the ERR= is ignored. If iostat= is not present, a run-time error is shown,
otherwise after the read statement is continued as if nothing had happened.
My test case, based on e73 test case of the Fortran 95
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-26 15:10 ---
Notice the 4004ec loads an 8 byte value, when it is specified as int.
It is loading the address of debug_enabled_abc, 4004f3 is the load from the
variable.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-12-26 15:22 ---
Confirmed, not a regression (at least not vs. 4.2).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-12-26 15:25
---
The problem only affects the 4.1 branch.
It does not appear on the 4.2 branch or mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-12-26 15:48 ---
Hmm... I'm having second thoughts about this. We
are reading with DIRECT access on unit 11 without
ever having opened, this makes no sense (because
we never specified a record length). If I change
iou on the test
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-12-26 16:18
---
Well, actually this seems to be a duplicate of PR 30088.
*** This bug has been marked as a duplicate of 30088 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from reichelt at gcc dot gnu dot org 2007-12-26 16:18
---
*** Bug 33573 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from davh at davh dot dk 2007-12-26 16:16 ---
Indeed... I need glasses, sorry for the bother,
--
davh at davh dot dk changed:
What|Removed |Added
--- Comment #14 from reichelt at gcc dot gnu dot org 2007-12-26 16:17
---
The original testcase fails on i686-pc-linux-gnu with -O2 on the 4.1 branch and
the 4.2 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from reichelt at gcc dot gnu dot org 2007-12-26 16:37
---
The following reduced testcase (which should return 0) returns 1 on the 4.1
branch and 4.2 branch when compiled with -O -fstrict-aliasing or -O2 on
i686-pc-linux-gnu:
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #3 from rask at gcc dot gnu dot org 2007-12-26 17:25 ---
Created an attachment (id=14832)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14832action=view)
patch v1
(gdb) frame 1
#1 0x0096e248 in gen_movdi (operand0=0x2ac241e195e0,
operand1=0x2ac241de1a10) at
--- Comment #3 from dominiq at lps dot ens dot fr 2007-12-26 17:29 ---
If getting 'OK' means that the code (and it variant) are compiled correctly, it
is the case on Intel Darwin9 for iou=9 or 11, 32 and 64 bit modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34594
The program below used to print 5. With g++ 4.3, it prints 0.
The program defines an output iterator which stores a counter,
to be incremented on each assignment of the output iterator.
The problem is that std::copy now copies the output iterator before
performing the assignment, so the program
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-12-26 17:34 ---
Error conditions are processor-dependent, so this
isn't a Fortran 95 issue.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-12-26 17:33 ---
Currently testing this patch.
Index: error.c
===
--- error.c (revision 131146)
+++ error.c (working copy)
@@ -410,6 +410,13 @@ translate_error
--- Comment #1 from pcarlini at suse dot de 2007-12-26 18:07 ---
Extremely annoying. I think the issue is real, because output iterators are the
only iterators which can be copy constructed (per Tab 73) but the semantics is
unspecified. I'll fix the affected occurrences.
--
pcarlini
--- Comment #7 from jon_d_r at msn dot com 2007-12-26 18:36 ---
Maybe this should best be described as:
ICE when function returns array of values to dynamically allocated array
If the LHS is a 'statically allocated' array, the function returns array of
values without problem. If the
--- Comment #2 from pcarlini at suse dot de 2007-12-26 18:37 ---
On second thought, I don't think we can really be worried by these specific new
copies, simply because for argument passing purposes we are copying output
iterators *everywhere* in algorithm!
--
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-12-26 19:04
---
Confirmed. Here's a reduced testcase:
===
struct A
{
int x;
int getX () { return x; }
};
templateint void foo()
{
A a;
#pragma omp for
for (int i=0; ia.getX(); ++i)
--- Comment #3 from pcarlini at suse dot de 2007-12-26 19:09 ---
And now I see what is really going wrong: this is a miscompilation, which
actually Richard reported to me a few days ago. Indeed, nothing in the
definition of the iterator can possibly zero the c member besides the default
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-12-26 19:40
---
*** Bug 33287 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-12-26 19:40
---
To sum things up:
* The code is invalid, i.e. it shouldn't compile.
* GCC up to 4.2.x rejected the code for the wrong reason:
bug.cc:24: error: 'C1' does not name a type
This message is way too late.
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-12-26 20:05
---
Confirmed. Here's a reduced testcase:
===
templatetypename struct A {};
int i = sizeof Atypeid;
===
The bug appeared in GCC 3.4.1 and is already
--- Comment #4 from pcarlini at suse dot de 2007-12-26 20:18 ---
Sorry about a bit of confusion on my part :( In this specific testcase there is
no miscompilation either, of course. Whether the DLV problem is ultimately the
same, I don't know at the moment (it seems so), but in any case
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-12-26 20:24
---
Works for me on i686-pc-linux-gnu.
Maybe this is an issue of the mingw port.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Please help! This is a critical issue for me, as I need to build either 4.2.1
or 4.2.2 version of gcc.
My OS is SuSE Linux Enterprise Server 9 32-bit.
I am using libmpfr 2.3.0, libgmp 4.2.2, binutils 2.18
the configure options that I am using is:
--x-includes=${X11_DIR}/include
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-12-26 20:58
---
Confirmed.
The correct syntax for the default parameter is the one that works:
typename Factory0ArgT::template FactoryT
I get an ICE since GCC 3.4.0.
Before, the code was wrongly accepted.
--
reichelt at gcc
--- Comment #18 from mark at codesourcery dot com 2007-12-26 21:19 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with complex type conversion
gdr at gcc dot gnu dot org wrote:
I'm very nervous about adding more constructors.
I'd rather distinguish the
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-26 21:44 ---
See `config.log' for more details.
Read what config.log says, it is located in
gcc/4.2.1/i686_linux26/gcc-4.2.1/host-i686-pc-linux-gnu/intl .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34596
--- Comment #1 from danglin at gcc dot gnu dot org 2007-12-26 21:45 ---
These fails have changed somewhat:
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/threadprivate3.f90
-B/test/gnu
--- Comment #2 from danglin at gcc dot gnu dot org 2007-12-26 21:51 ---
Subject: Bug 33640
Author: danglin
Date: Wed Dec 26 21:51:30 2007
New Revision: 131187
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131187
Log:
PR c++/33640
* g++.dg/other/unused1.C: xfail
--- Comment #3 from danglin at gcc dot gnu dot org 2007-12-26 21:52 ---
Failing test xfailed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from paolo at gcc dot gnu dot org 2007-12-26 21:59 ---
Subject: Bug 34595
Author: paolo
Date: Wed Dec 26 21:58:49 2007
New Revision: 131188
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131188
Log:
2007-12-26 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #6 from pcarlini at suse dot de 2007-12-26 22:00 ---
Better play safe...
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #11 from sven dot buijssen at math dot uni-dortmund dot de
2007-12-26 22:00 ---
Can this patch be backported to 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34438
--- Comment #19 from pcarlini at suse dot de 2007-12-26 22:02 ---
Also, I'm afraid the implementation of parts of complex (the transcendental
functions) may become much uglier, humpf...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
--- Comment #8 from kargl at gcc dot gnu dot org 2007-12-26 22:07 ---
(In reply to comment #7)
Maybe this should best be described as:
ICE when function returns array of values to dynamically allocated array
If the LHS is a 'statically allocated' array, the function returns array of
--- Comment #1 from bero at arklinux dot org 2007-12-26 23:12 ---
I've run checks on some more gcc revisions. Down to a few revisions.
Last known working svn rev: 130324
First known broken svn rev: 130330
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34570
--- Comment #2 from danglin at gcc dot gnu dot org 2007-12-26 23:13 ---
Breakpoint 5, dbxout_symbol_location (decl=0x40053808, type=0x40068808,
suffix=0x400561dc ~*, home=0x40010248) at ../../gcc/gcc/dbxout.c:2825
2825 if (GET_CODE (home) == SUBREG)
(gdb) p debug_tree ($r26)
--- Comment #2 from bero at arklinux dot org 2007-12-26 23:32 ---
A Qt strict-aliasing bug potentially affecting this has shown up; it's possible
that the problem isn't with gcc after all, but only shows up with the current
versions. Running more tests with a fixed Qt version. (At a
--- Comment #12 from kargl at gcc dot gnu dot org 2007-12-26 23:42 ---
(In reply to comment #11)
Can this patch be backported to 4.2?
Is it a regression from an earlier version of gfortran?
If the answer to this question is 'No', then it is not
a candidate for a back port.
--
--- Comment #2 from imam dot toufique at intel dot com 2007-12-27 02:18
---
Hi,
this is what the config.log says in the intl dir.
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
/lib/libc.so.6: undefined reference to
67 matches
Mail list logo
