--- Comment #9 from bangerth at dealii dot org 2006-10-21 04:28 ---
Mark,
is there any way for a backport of your patch to the 4.1 branch? This
appears to be a regression involving boost, and I got word from
people whose codes break with 4.1.x because of this...
Thanks
W.
--
bange
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 03:42 ---
This is related to subtypes.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
While there might exist a case that can be vectorized, a few of the simple
cases that should be easy that I have tried are not able to be vectorized.
For example, the following
package compare_lang is
type the_range is range 0 .. 100;
type My_Array is array (the_range) of Float;
a, b, c :
comparing the 20061007 and the 20061020 build on amd64-linux-gnu I see the
following regressions (Debian amd64 unstable):
+FAIL: gfortran.dg/io_constraints_1.f90 -O (test for errors, line 73)
+FAIL: gfortran.dg/io_constraints_1.f90 -O (test for excess errors)
Matthias
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-21 00:16
---
I will see what I can figure out here now.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from mrs at apple dot com 2006-10-20 23:24 ---
I spent a minute upgrading my build system to handle the new world order that's
coming down the pike in 4.3... The problem I thought I might hit didn't
happen, so, I'm fine with this being WONTFIX. I now do a bootstrap by no
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-20 22:56 ---
I saw we forget about --disable-bootstrap and work on other regressions. Like
the P1s on ppc-darwin that has been there for a while now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
--- Comment #7 from mrs at apple dot com 2006-10-20 22:33 ---
I'd like my patch to be considered for 4.2, seems safee enough.
--
mrs at apple dot com changed:
What|Removed |Added
-
--- Comment #6 from mrs at apple dot com 2006-10-20 22:29 ---
If the decision is to rip out mass amounts of code for bootstrapping in stage3,
well, that can be done, but unless that it is done, this is a bug. If it is to
be done, that it is a bug that it isn't done. As for WONTFIX, wel
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-20 22:16 ---
As mentioned this was invalid because HJL used the wrong make target.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-20 22:15 ---
It is not a bug because bootstrap should be broken with --disable-bootstrap
even more than it is currently is, it really should be removed at that point.
--
pinskia at gcc dot gnu dot org changed:
Wha
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-20 22:15 ---
Oh and the problem is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-20 22:14 ---
Actually why are you trying to do a make bootstrap with --disable-bootstrap
anyways?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-20 22:13 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-20 22:12 ---
*** Bug 29531 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-20 22:12 ---
This is the same issue as PR 28682.
Though --disable-bootstrap should not be used unless you really know what you
are doing as soon (for 4.3), make bootstrap with --disable-bootstrap will
always break for libgcc bein
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-20 22:11 ---
Reopening.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOL
--- Comment #1 from mrs at apple dot com 2006-10-20 22:09 ---
I think something like:
Doing diffs in configure.ac.~1~:
--- configure.ac.~1~2006-10-16 12:38:48.0 -0700
+++ configure.ac2006-10-20 15:00:44.0 -0700
@@ -3419,6 +3419,16 @@ changequote([,])dnl
If one configures with --disable-boostrap --enable-languages=c and then builds
with make bootstrap but doesn't have ada installed, the build fails. The
problem is that gcc/configure unconditionally adds ada to the stage 1 languages
BOOT_LANGUAGES, even though --enable-languages=c is used.
In non-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-20 21:34 ---
This is most likely a purify problem. Have you tried using valgrind instead?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When I compile this code:
#include
int main(void)
{
}
with g++, instrumented with the "purify" utility, purify reports
the following:
UMR: Uninitialized memory read (128 times)
This is occurring while in:
__gconv_get_alias_db [libc.so.6]
wctob [libc.
gcjh has been removed from the gcj-eclipse branch, but the documentation
remains. Once we've imported a new Classpath (and with it, the new gcjh),
we must update the documentation to reflect the changes.
Probably this documentation should be pushed upstream to Classpath.
--
Summary:
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-10-20 20:14
---
Fixed in 4.2.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-10-20 20:13
---
Subject: Bug 28053
Author: lmillward
Date: Fri Oct 20 20:13:42 2006
New Revision: 117910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117910
Log:
PR c++/28053
* decl2.c (grokbitfield): D
The current rule for make clean on libiberty/testsuite doesn't append EXEEXT,
so make clean doesn't perform as expected under cygwin.
The following patch resolves this; please test/commit
Phil Lello
Index: libiberty/testsuite/Makefile.in
==
--- Comment #2 from jeff at thecreems dot com 2006-10-20 17:03 ---
Still there in head
gcc -c bug.adb
+===GNAT BUG DETECTED==+
| 4.2.0 20061020 (experimental) (i686-pc-linux-gnu) Assert_Failure
atree.adb:812
--
http://gcc.gnu.org
4.2.0 20061020 (experimental)
[EMAIL PROTECTED] bg]$ gcc -c elements-sets.adb
[EMAIL PROTECTED] bg]$
--
jeff at thecreems dot com changed:
What|Removed |Added
CC
] mat_test]$
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --disable-checking
--enable-languages=c,fortran,ada --prefix=/home/jcreem/local
Thread model: posix
gcc version 4.2.0 20061020 (experimental)
--
jeff at thecreems dot com changed
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-10-20 16:25
---
To make you feel better. I have found the other spots. Those are fixed as
well and regression tested AOK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-20 16:19 ---
In fact this works correctly on the SPU target so I think avr is broken or you
are really using __builtin_clz.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-20 15:58 ---
First off this should not matter as it should not be linked in as it is not
used at all. Do you have a testcase which it links it in?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from ghazi at gcc dot gnu dot org 2006-10-20 15:53 ---
Third patch revision posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01039.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-20 14:43 ---
Can you provide some details on the out of date .mod files? Were they compiled
with a different compiler version or on a different architecture? Or are they
just not up-to-date with the source? In the latter case
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-20 14:39 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #19 from pault at gcc dot gnu dot org 2006-10-20 14:35 ---
Thank goodne for that - I thought that I was going batty!
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-20 14:34 ---
*** This bug has been marked as a duplicate of 29518 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-20 14:34
---
*** Bug 29525 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2006-10-20 14:33
---
Correction: The patch in #16 fixes the case in #11. However I have several
other variations on this that are taking a different error path.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-10-20 14:27
---
This does not fix it, but I think the idea is in the right direction. There
are multiple error return paths like this that are not cleaning up enough.
This explains why making variations on the test case gives
--- Comment #1 from gcc at derived-software dot ltd dot uk 2006-10-20
14:15 ---
Created an attachment (id=12469)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12469&action=view)
gzip'd preprocessed output of libs/mpl/test/multiset.cpp from boost 1.34 branch
Generated with:
g++ -
Attached is a preprocessed file that generates the following error (just the
first one of a group shown):
% g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -D_GLIBCXX_DEBUG=1
-DBOOST_ALL_NO_LIB=1 -I. -c -o multiset.o libs/mpl/test/multiset.cpp
libs/mpl/test/multiset.cpp: In function 'vo
I noticed that the amount of RAM used, compared to the code generated by gcc
4.1.1, is increased by 256 bytes and found that this it's due to the __clz_tab
array linked in at RAM start.
--
Summary: Too much RAM used: __clz_tab[] linked
Product: gcc
Version: 4.2.0
Hi,
I got the following error message when I do just âmakeâ on my program.
Running âmake clean && makeâ solves the problem, but gcc should give some
useful error message:
gfortran -DPACKAGE_NAME=\"matprop\" -DPACKAGE_TARNAME=\"matprop\"
-DPACKAGE_VERSION=
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-10-20 09:28 ---
Ie:
#include
int
main()
{
using namespace std;
const wchar_t w1 = { 0x4e2d };// U+20013 == 0x4E2D
const wchar_t w2 = { 0x56fd };// U+22269 == 0x56FD
const wchar_t w3(20013);
const wchar_t w4(22269);
lo
--- Comment #16 from pault at gcc dot gnu dot org 2006-10-20 09:20 ---
The problem is specific to old-style initializers, as
program FOO
real :: x = 2.0 q
real z /2.0/ q
end program FOO
shows (comment out each declaration in turn!).
Grepping on the first error message leads us to d
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-20 09:09 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #45 from rguenth at gcc dot gnu dot org 2006-10-20 08:24
---
Still not fixed on the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from Ulrich dot Beingesser at t-systems dot com 2006-10-20
08:10 ---
Created an attachment (id=12468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12468&action=view)
backtrace info 3
Shows backtrace info for scenario when program crashes due to signal 4
--
ht
--- Comment #5 from Ulrich dot Beingesser at t-systems dot com 2006-10-20
08:08 ---
Created an attachment (id=12467)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12467&action=view)
backtrace info case 2
Shows backtrace info for scenario when program crashes due to signal 11
--
--- Comment #4 from Ulrich dot Beingesser at t-systems dot com 2006-10-20
07:53 ---
Created an attachment (id=12466)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12466&action=view)
gdb backtrace info
Shows complete sequence how program is build, run, crashes and gdb backtrace on
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-20 07:42
---
*** Bug 29417 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-20 07:42 ---
(In reply to comment #5)
> A regression hunt on powerpc-linux identified the following patch:
This just confirms the problem here is the same as listed in PR 27657 as that
patch cause anonymous namespace to be local
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-20 07:34
---
*** Bug 29438 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 2006-10-20 07:34 ---
Yes this is a dup of bug 29236 which has a similar testcase and more discussion
on the actually problem.
*** This bug has been marked as a duplicate of 29236 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-20 07:33
---
*** Bug 29486 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-20 07:33 ---
Yes this is a dup of bug 29236.
*** This bug has been marked as a duplicate of 29236 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-20 07:25
---
Note I found a related regression in 4.0.4 only and I filed that as PR 29522.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-20 07:24 ---
Note I could not find this bug filed so I filed it. Also note I found it while
looking at PR 29518.
Oh and the error message is:
[EMAIL PROTECTED] ~]$ ~/gcc-4.0/bin/gcc t.cc
t.cc: In instantiation of const int N::t
Testcase:
template< int C > int assertion_failed( int);
template< class >
struct N
{
static int const okay = 1;
static int const
t = sizeof( assertion_failed( 0))
;
};
int main()
{
N n;
return n.t;
}
--
Summary: [4.0 Regression] rejects valid template argument
59 matches
Mail list logo
