--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-10 05:08 ---
Is this true any more on the mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20438
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-10 05:01 ---
*** Bug 21979 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-10 05:01 ---
I am going to mark this as a dup of bug 23861 since that has the reference to
the patch which fixes this.
*** This bug has been marked as a duplicate of 23861 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-10 04:59 ---
maybe we should be using verbatim or note.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-10 04:54 ---
This has been xfailed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Ke
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-10 04:48 ---
Only a 3.4.x regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-10 04:35
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-10 04:29
---
Only a hppa-linux bug now, which means this should be targetted at 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from kazu at gcc dot gnu dot org 2005-10-10 03:20 ---
The testcase in comment #8 still triggers an ICE if run with -O -mtune=k8
-fPIC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20928
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19289
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-10 02:33 ---
I think this is a bug in your SPEC for RPM's. Can you make sure that your RPM
mechanism is not touching a file which should not be touched.
>From what I hear is that a profiledbootstrap/install works fine when not
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-10 01:53 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-10 01:48 ---
Starting with 4.1, if you don't have a 64bit machine and you have Mac OS X 10.4
(aka darwin8.2), you have to use --disable-multilib .
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I updated gcc from CVS today (2005-10-09) and configured with
~/src/gcc/configure --prefix=$HOME/gcc --with-mpfr=/Users/eschnett
--enable-languages=c,c++,fortran,java,objc,treelang
A "make bootstrap" aborts after some time with
configure: creating ./config.status
config.status: creating Makefile
GCC does not diagnose the following translation unit with -fsyntax-only:
static struct foo x;
--
Summary: Undefined behaviour not diagnosed with -fsyntax-only
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priorit
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-10 00:22
---
*** Bug 24292 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 2005-10-10 00:22 ---
This is a dup of bug 16185.
*** This bug has been marked as a duplicate of 16185 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-10 00:21 ---
Reduced testcase:
register struct CPUX86State *env asm("ebp");
register unsigned long T0 asm("ebx");
register unsigned long T1 asm("esi");
register unsigned long T2 asm("edi");
extern int __op_param1, __op_param2,
--- Comment #1 from nigelenki at comcast dot net 2005-10-09 23:49 ---
Created an attachment (id=9949)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9949&action=view)
the dot-i file thingy you guys wanted
the thingy that appeared in a completely different directory than related .c
Trying to build qemu 0.7.2 gives the following error:
/tmp/qemu-0.7.2/target-i386/ops_sse.h: In function 'op_pshufw_mmx':
/tmp/qemu-0.7.2/target-i386/ops_sse.h:574: error: unable to find a register to
spill in class 'GENERAL_REGS'
/tmp/qemu-0.7.2/target-i386/ops_sse.h:574: error: this is the insn:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7321
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-09 22:52 ---
Mark as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-09 22:52 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18667
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445
--- Comment #9 from cvs-commit at gcc dot gnu dot org 2005-10-09 22:50
---
Subject: Bug 24226
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-09 22:50:01
Modified files:
gcc: ChangeLog tree-cfg.c tree-flow.h
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22460
--- Comment #5 from sabre at nondot dot org 2005-10-09 22:02 ---
Some updates: the -ftime-report problems were a local problem with apple's gcc,
now fixed. This testcase has some templates (e.g. the match stuff), but mostly
it is just big branchy compiler code :), not atypical of many C
--- Comment #8 from jblomqvi at cc dot hut dot fi 2005-10-09 21:29 ---
Well, a slightly less broken approach than the patch in #3 would be to use
sizeof(GFC_REAL_10) and sizeof(GFC_COMPLEX_10) instead of hardcoded sizes. But
the problem with this would still be 1) location of pad bytes a
--- Comment #2 from christian dot joensson at gmail dot com 2005-10-09
21:00 ---
Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
--- Comment #4 from christian dot joensson at gmail dot com 2005-10-09
21:00 ---
Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23616
--- Comment #2 from christian dot joensson at gmail dot com 2005-10-09
21:00 ---
Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23614
--- Comment #2 from christian dot joensson at gmail dot com 2005-10-09
21:00 ---
Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23613
--- Comment #4 from christian dot joensson at gmail dot com 2005-10-09
20:59 ---
Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23610
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-09 20:54
---
*** Bug 24291 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 20:54 ---
*** This bug has been marked as a duplicate of 9925 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jblomqvi at cc dot hut dot fi 2005-10-09 20:52 ---
(In reply to comment #5)
> > It should be noted that the patch assumes that the padding for real(10) is
> > 10
> > bytes data + 2 bytes padding. This works on i686-Linux, might not work on
> > other
> > targets (big
This code:
#include
#include
int main() {
std::cerr << static_cast(std::stringstream() << "foo"
<< "bar").str() << "\n";
return 0;
}
prints:
~/ootbc/members/src$ a.out
0x8048c58bar
The "foo" operand is being formatted as a pointer rather than a C string.
Strangely,
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 20:47 ---
Even further reduced testcase:
struct _Words {_Words();};
_Words _M_local_word[2];
---
This shows up while bootstrapping on x86_64-pc-linux-gnu.
--
pinskia at gcc dot gnu dot org changed:
What
I missed it but it started failing between:
LAST_UPDATED: Mon Sep 12 07:44:40 UTC 2005
LAST_UPDATED: Thu Sep 15 20:35:53 UTC 2005
/home/guerby/work/gcc/build/build-20050915T230254/gcc/xgcc -c
-B/home/guerby/work/gcc/build/build-20050915T230254/gcc/ -gnatws -O2
-I/home/guerby/work/gcc/build/build-
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-09 20:00 ---
Just for future references I wrote something in:
http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=13781
Complaining about the situational.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23292
--- Comment #8 from rakdver at gcc dot gnu dot org 2005-10-09 19:38 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00478.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-10-09 19:36 ---
With the recent changes to scev analysis that ensure that signed chrecs do not
wrap (assuming -fno-wrapv), it is fairly easy to get tree level # of iterations
analysis to use this fact, see the attached patch.
This
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-09 19:36 ---
Note this will cause problems more with java than it does with any other
language since $ is normal in class files as it is used for inner classes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23292
--- Comment #6 from jblomqvi at cc dot hut dot fi 2005-10-09 19:35 ---
(In reply to comment #5)
> > It should be noted that the patch assumes that the padding for real(10) is
> > 10
> > bytes data + 2 bytes padding. This works on i686-Linux, might not work on
> > other
> > targets (big
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-10-09 19:35 ---
Created an attachment (id=9948)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9948&action=view)
Patch for no-overflow analysis from signedness
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 19:34 ---
Can you guys really report this to GNU make and say that this should not
change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23292
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-09 19:33 ---
*** Bug 24289 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 19:33 ---
This is a dup of bug 23292.
*** This bug has been marked as a duplicate of 23292 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The problem is this new feature in make:
* WARNING: Backward-incompatibility!
GNU make now implements a generic "second expansion" feature on the
prerequisites of both explicit and implicit (pattern) rules. After
all rules have been parsed the prerequisites are expanded again, this
time w
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-09 19:09 ---
I think this has been fixed for 4.0.0, won't know until there is a testcase.
Oh, this is more of an interaction between fomit-frame-pointer and eh tables.
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #1 from bduerner at gmx dot de 2005-10-09 19:08 ---
Created an attachment (id=9947)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9947&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24288
When an exception is thrown the program terminates instead of catching the
exception. This only happens with -O1 or higher and -fomit-frame-pointer.
The problem does not occur when:
- the throwing function is not virtual
- the throwing function is not an operator
- the throwing function does not c
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 18:48 ---
I think this is just a problem of templates, lots of them.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-09 18:39 ---
Confirmed. The middle-end problems are almost all in reload.c.
For the profile, everything is just spread all around.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
--- Comment #25 from lucier at math dot purdue dot edu 2005-10-09 18:26
---
[lindv2:~/Desktop/gcc-test] lucier% /pkgs/gcc-mainline/bin/gcc -v -m64
-dynamiclib -o conftest conftest.c
Using built-in specs.
Target: powerpc-apple-darwin8.2.0
Configured with: ../configure powerpc-apple-darwi
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|bkoz at gcc dot gnu dot org |unassigned at gcc dot gnu
|
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-10-09 17:47
---
But it's platform-independent.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2005-10-09 17:43
---
What is the status of this PR? I've personally never run into the problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 17:41 ---
There are a couple of problems here. First I noticed that bar in foo is not
marked as pure even though the IPA mechanism marked it as such, so that looks
like a fortran front-end bug in that it has two different DECL
--- Comment #9 from jblomqvi at cc dot hut dot fi 2005-10-09 17:41 ---
(In reply to comment #8)
> Can you do timings with today's compiler?
>
Performance is now equivalent with g77, a factor of 500 times faster than
mainline a month ago. I don't know if any of these patches have made i
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 17:35 ---
Related to PR 23134.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDepen
Take the following source:
int g1(int);
int h(int *a, int *b)__attribute__((pure));
void link_error();
int g(void)
{
int t = 0, t1 = 2;
int t2 = h(&t, &t1);
if (t != 0)
link_error ();
if (t1 != 2)
link_error ();
g1(t2);
if (t != 0)
link_error ();
if (t1 != 2)
link_err
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2005-10-09 17:18
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #4 from denney at seas dot upenn dot edu 2005-10-09 17:00
---
Created an attachment (id=9946)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9946&action=view)
Fixed version of code using call, nullify, etc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24286
--- Comment #3 from denney at seas dot upenn dot edu 2005-10-09 16:59
---
With this fixed code, the initial test case now compiles correctly in the
windows version. (It segfaults on running, but that's my coding problem, not a
compiler problem.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 16:54 ---
Fixed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-09 16:36 ---
addnode(head, thisnode, i)
You want:
call addnode(head, thisnode, i)
With that change we get more errors about the same thing.
Though I cannot reproduce your ICE though.
--
http://gcc.gnu.org/bugz
--- Comment #1 from denney at seas dot upenn dot edu 2005-10-09 16:32
---
Created an attachment (id=9945)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9945&action=view)
Initial test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24286
When compiling this code, I get a compiler crash. I believe that it has to do
with using a pointer in a subroutine.
In file testtree.f90:34
addnode(head, thisnode, i)
1
Error: Unclassifiable statement at (1)
testtree.f90:0: internal compiler error: Segmentation fault
Please submit a ful
--- Comment #46 from pinskia at gcc dot gnu dot org 2005-10-09 15:45
---
The real fix is a front-end fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-10-09 15:44
---
I think this was decided that this was a front-end bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 15:44 ---
Closing as there is only one bug left.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-09 14:25 ---
Fixed in 3.4.5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 14:02 ---
Confirmed.
The backtrace:
#0 0x001bfaf0 in dwarf2out_frame_debug_expr (expr=0x0, label=0x55c1dc
"*.LLCFI0") at ../../gcc/dwarf2out.c:1461
#1 0x001c0de0 in dwarf2out_frame_debug (insn=0x0, after_p=1 '\001') at
../..
[forwarded from http://bugs.debian.org/324600]
Bug submitter writes:
I had no compilation problems with g77.
300 format( 1000(a,$))
1
Error: $ must the last specifier in format string at (1)
301 format(/1000(a,$))
Error: $ must the last specifier in format string at (
[forwarded from http://bugs.debian.org/329840]
works with 3.3.6, 3.4 CVS, fails with 4.0.2, CVS HEAD 20050904
When building zinc-compiler on sparc, I'm get:
run.nw: In function 'do_run':
run.nw:212: internal compiler error: Segmentation fault
It seems the following code is what is causing it:
vo
--- Comment #3 from falk at debian dot org 2005-10-09 12:42 ---
(In reply to comment #2)
> But the modified register is a register of the input list, so gcc should
> know that it will be used.
It knows it is being read. It doesn't know that it is also clobbered.
--
http://gcc.gnu.
--- Comment #2 from graeter at hydrixos dot org 2005-10-09 12:17 ---
Subject: Re: Optimizer ignores register changing (STOSL)
pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 03:11
> ---
> In inline-asm if you say that you
--- Comment #8 from pcarlini at suse dot de 2005-10-09 10:36 ---
Fixed for 4.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-09 10:34
---
Subject: Bug 24061
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-09 10:34:47
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/include/tr1:
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-10-09 09:56 ---
Another one is the following (without any possible aliasing problems):
int foo_charchar(void)
{
char i[2*sizeof(int)];
new (i) Foo();
return reinterpret_cast(&i[0])->i[0];
}
where we miss th
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-10-09 09:47 ---
The non-null check is now removed for the foo_char() case by VRP (note that
the non-null check for the two viod-cases are _not_ removed by VRP but by DOM1.
The propagation of the initialization in foo_void_offset is
--- Comment #7 from rakdver at gcc dot gnu dot org 2005-10-09 09:03 ---
Testing a patch.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #3 from uros at kss-loka dot si 2005-10-09 08:04 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00414.html
--
uros at kss-loka dot si changed:
What|Removed |Added
-
85 matches
Mail list logo
