Roger Sayle [EMAIL PROTECTED] writes:
[...] the patch below removes the TREE_CONSTANT_OVERFLOW checks from
integer_zerop, integer_onep, and friends in tree.c.
Incidentally, this fixes PR 26729.
--
Falk
On 4/1/06, Ed Smith-Rowland [EMAIL PROTECTED] wrote:
All,
FWIW, I would like to add my support for creating a branch for gpc with
the eventual goal
of integrating Pascal into mainline.
While I agree with most of the the points you make, the issue is not
whether GCC should allow a gpc-branch
2006-04-01 Roger Sayle [EMAIL PROTECTED]
* tree.c (integer_zerop): Ignore TREE_CONSTANT_OVERFLOW.
[...]
(int_size_in_bytes): Likewise.
(host_integerp): Likewise.
Is this an oversight?
*** int_size_in_bytes (tree type)
*** 1725,1731
t =
On Sun, 2 Apr 2006, Eric Botcazou wrote:
2006-04-01 Roger Sayle [EMAIL PROTECTED]
* tree.c (integer_zerop): Ignore TREE_CONSTANT_OVERFLOW.
[...]
(int_size_in_bytes): Likewise.
(host_integerp): Likewise.
Is this an oversight?
Doh. Indeed. The last two lines of
On Sat, 1 Apr 2006, Roger Sayle wrote:
As a step in this direction, the patch below removes the
TREE_CONSTANT_OVERFLOW checks from integer_zerop, integer_onep,
Has there been a patch to the C++ front end corresponding to my patch
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00315.html to the
On Mon, 27 Mar 2006, Steven Bosscher wrote:
That would be up to the Steering Committee, I suppose. Gerald?
Yes, as Mark noted in a related thread, this would be the case.
Note that it's not only about technical issues, copyright assignment,
and coding standards. Adding and especially carrying
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-02 08:01 ---
Backtrace:
#0 0x00351810 in can_throw_internal_1 (region_number=0, is_resx=1 '\001') at
../../gcc/except.c:2655
#1 0x00601484 in tree_can_throw_internal (stmt=0x434ed5a0) at
../../gcc/tree-eh.c:2031
#2 0x0067ff74
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-02 08:11 ---
I should note this is undefined code as the types A and B are not compatible
types.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from sebastian dot pop at cri dot ensmp dot fr 2006-04-02
08:12 ---
Created an attachment (id=11184)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11184action=view)
fix
This patch fixes this problem. I'll bootntestncommit.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.1.1
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[3.4/4.0/4.1 regression]|[4.0/4.1 regression] Attempt
|Attempt to delete
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 08:20 ---
This makes little sense:
Makefile:1277: *** target pattern contains no `%'. Stop.
Can you attach the makefile?
Also what options did you use to configure GCC?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 08:21 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-02 08:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-02 08:23 ---
As requested by the bug filing, can you attach the preprocessed source code for
this hello world program?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-02 08:25 ---
(In reply to comment #5)
Yes, too bad #pragma GCC system_header doesn't help here. Can somebody remind
me exactly why and whether it's fixable?
Too bad libstdc++ has to complain about this not working :).
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-02 08:26 ---
We need a self contained testcase here.
Can you read http://gcc.gnu.org/bugs.html and attach the preprocessed source as
requested?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 08:28 ---
Or just XFAIL like the other one which needs __cxa_atexit.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-02 08:48 ---
Confirmed, this is a latent bug though. Reduced testcase which shows the bug
even in 4.0.x:
#include typeinfo
void g(const std::type_info);
#pragma GCC visibility push(hidden)
const std::type_info* t =
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 08:59 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.0.2 4.1.0 4.2.0
Known to work|
--- Comment #15 from mikpe at csd dot uu dot se 2006-04-02 09:05 ---
(In reply to comment #13)
Any patch for gcc-3.4.6?
Yes, use the patch shown earlier in this thread,
or the equivalent one provided by crosstool.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15068
$ cat fail.f90
implicit none
real(8) :: a(2,9), b(9,7), c(2,7)
integer :: i, j
a = 0.d0
b = 0.d0
c = 1789789.d0
c(:,1:7:2) = matmul(a,b(:,1:7:2))
do i = 1, 7
print *, c(:,i)
end do
end
$ ifort fail.f90 ./a.out
0.000E+000 0.000E+000
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-04-02 10:49
---
Analysis and patch idea here:
http://gcc.gnu.org/ml/fortran/2006-04/msg00029.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
4.2.0 20060401
I'm seeing lots of segfaults in iostream using code. This is a test case:
templatetypename CharT
struct basic_ios {
virtual ~basic_ios ();
};
templatetypename CharT
struct basic_streambuf {
friend struct basic_iosCharT;
};
templatetypename CharT
struct basic_ostream :
--- Comment #2 from schwab at suse dot de 2006-04-02 13:03 ---
#0 0x408dbf11 in emit_move_insn (x=0x20783560, y=0x0)
at ../../gcc/expr.c:3229
#1 0x408df180 in emit_group_store (orig_dst=0x20783560,
src=0x20713450,
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-04-02 13:09
---
Created an attachment (id=11185)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11185action=view)
Preprocessed source also causing the problem
Humpf, this ICE (same backtrace) also happens when building
--- Comment #11 from pbrook at gcc dot gnu dot org 2006-04-02 13:19 ---
Subject: Bug 18527
Author: pbrook
Date: Sun Apr 2 13:19:15 2006
New Revision: 112622
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112622
Log:
2006-04-02 Paul Brook [EMAIL PROTECTED]
Backport
--- Comment #13 from spop at gcc dot gnu dot org 2006-04-02 14:08 ---
Subject: Bug 26939
Author: spop
Date: Sun Apr 2 14:08:02 2006
New Revision: 112623
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112623
Log:
PR tree-optimization/26939
* tree-chrec.c
Hi,
the gcc and cpplib domains have been completely translated to German for a
while. Unfortunately, the Translation Project file robot is broken. I'm the
usual translator as for the previous gcc versions, and you can download the
de.po files from
http://antcom.de/i18n/
It would be frustrating
Given the following code:
#define VIRTUAL virtual
//#define VIRTUAL// use this to 'fix' the code
#include iostream
using namespace std;
struct VirtualBase{};
struct Bar : public VIRTUAL VirtualBase
{
template typename castT explicit
Bar(
--- Comment #3 from roger at eyesopen dot com 2006-04-02 15:53 ---
Thanks Andreas. Well my prediction that the bogus call wouldn't come from
emit_group_store was wrong. There's now a trivial fix to resolve this PR
which is to add if (temp) tests around the emit_move_insn, done=true
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 16:01 ---
The only thing I can think of which is causing this is the anonymous namespace
changes. I should note I don't get an ICE on x86_64-linux-gnu though.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 16:02 ---
Please just post the patch for this to [EMAIL PROTECTED]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26987
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-04-02 16:04
---
(In reply to comment #7)
Subject: Re: Number of iterations not know for simple loop
I thought if we know that we are looking at the loop header copy
condition that
we _know_ that the loop runs at
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-02 16:06 ---
Woops wrong person, sorry Nathan.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
As reported over here:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01428.html
HAVE_GAS_HIDDEN is the wrong check and should not be used.
Since this was reported more than a week ago and nothing has been done I am
filing a bug report.
I am going add this is a regression as anonymous namespace
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||26984
Status|UNCONFIRMED |NEW
Ever
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 16:21 ---
Related to PR 9050.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-02 16:29 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
--- Comment #4 from schwab at suse dot de 2006-04-02 16:35 ---
(gdb) p outer $1 = TImode (gdb) p tmps[start] $2 = (rtx) 0x20783460
(gdb) pr (reg:SF 354) (gdb) p inner $3 = SFmode (gdb) p bytepos $4 = 0 (gdb) p
src $5 = (rtx) 0x20713450 (gdb) pr (parallel:TI [
--- Comment #5 from schwab at suse dot de 2006-04-02 16:43 ---
Trying again with a different browser.
(gdb) p outer
$1 = TImode
(gdb) p tmps[start]
$2 = (rtx) 0x20783460
(gdb) pr
(reg:SF 354)
(gdb) p inner
$3 = SFmode
(gdb) p bytepos
$4 = 0
(gdb) p src
$5 = (rtx)
[EMAIL PROTECTED]:vmw-ste# gcc --target-help
Target specific options:
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: Target Help Seg Fault.
Product: gcc
Version: 4.1.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 17:33 ---
Can you supply gcc -v?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
System:
uname -a
Darwin iMacIntel.local 8.5.1 Darwin Kernel Version 8.5.1: Mon Jan 30 21:07:08
PST 2006; root:xnu-792.8.36.obj~1/RELEASE_I386 i386 i386
Compiled with:
gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /Users/drew/Developer/Compiler/gcc-head/configure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 18:16 ---
Also happens on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26992
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-02 18:17 ---
I should note, next time report a bootstrap failure first to the mailing list
and then only after a week or so to bugzilla.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-04-02 18:41 ---
The test case also exposes a problem with the way that
the result is stored.
Look at this:
$ cat matmul.f90
program main
implicit none
real(8) :: a(2,9), b(9,7), c(2,7)
integer :: i, j
a = 1.d0
b = 2.d0
--- Comment #3 from kgardas at objectsecurity dot com 2006-04-02 19:08
---
Created an attachment (id=11186)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11186action=view)
Hello World test preprocessed source
Hello,
here is requested preprocessed source bzip2ed.
Karel
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-02 19:16 ---
This is interesting because:
static __typeof(pthread_once) __gthrw_pthread_once __attribute__
((__weakref__(pthread_once)));
That should have made that decl weak which in turn should not needed to have
this decl
Testcase:
int f(void)
static __typeof(f) __gthrw_f __attribute__ ((__weakref__(f)));
ICE:
t.c:2: error: storage class specified for parameter __gthrw_f
t.c:2: internal compiler error: tree check: expected tree that contains decl
with visibility structure, have parm_decl in
--- Comment #5 from kgardas at objectsecurity dot com 2006-04-02 19:18
---
Hello,
I don't know if it is of any use, but from the OpenBSD history I remember it
used really ancient binutils version, i.e. as 0.92 or so, the linker very same.
Now, at least in 3.9 it's using FSF binutils
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-04-02 19:21 ---
(In reply to comment #2)
The test case also exposes a problem with the way that
the result is stored.
Actually, it doesn't. Storing the result is OK, clearing beforehand isn't.
--
--- Comment #6 from kgardas at objectsecurity dot com 2006-04-02 19:23
---
After correcting abort(0) to abort() on line 9 I get:
$ /home/karel/usr/local/gcc-trunk-20060331/bin/gcc test.c
test.c: In function 'main':
test.c:9: warning: incompatible implicit declaration of built-in
--- Comment #8 from spiralvoice at hotmail dot com 2006-04-02 19:34 ---
Same bug on Solaris 8/Sparc with gcc-3.4.5
I happened to have ansidecl.h from binutils-2.16 in a path
included in CFLAGS. Moving this file somewhere else fixes this bug.
Configure flags:
--enable-shared \
I was in the midst of preparing to commit the new versions of the array
TRANSFER testcases, when the bigendian test started giving troubles with
optimization greater than 0. This:
! { dg-do run }
! { dg-options -O1 }
! Bigendian test posted by Perseus in comp.lang.fortran on 4 July 2005.
--- Comment #4 from patchapp at dberlin dot org 2006-04-02 20:21 ---
Subject: Bug number PR26891
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01828.html
--
--- Comment #2 from patchapp at dberlin dot org 2006-04-02 21:30 ---
Subject: Bug number PR26976
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00024.html
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-02 22:02 ---
I had messed up my own testcase, this is what I get for writting the testcase
in bugzilla and then trying it out. Anyways abort (0); should have been
abort ();.
Now if this works, then we have a problem in
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 22:04 ---
ADDR_EXPRCONST_DECL should be a valid operand to the unary operator. It
might be because the ADDR_EXPR is not marked as invariant.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from stigge at antcom dot de 2006-04-02 22:08 ---
Attaching the files themselves makes the mail for the list too big. GZipping
them makes the spam checker reject them.
Any idea?
Remember: po file patches tend to be quite big for gcc, sometimes bigger than
the file
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-02 22:14 ---
Just send an email to the pist pointing to the .po. I wonder why the automatic
bot is not working for the german translation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26987
--- Comment #6 from sayle at gcc dot gnu dot org 2006-04-02 22:23 ---
Subject: Bug 26977
Author: sayle
Date: Sun Apr 2 22:23:44 2006
New Revision: 112626
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112626
Log:
PR middle-end/26977
* expr.c (emit_group_store):
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-02 22:27 ---
The inliner is messing this up somehow.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-02 22:36 ---
Hmm, the probelm is the ADDR_EXPR is not invariant because the context is
different. I don't know the correct way of fixing this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26994
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-02 22:43 ---
A work around is to do:
integer :: tmp
.
tmp = 1
chr = IACHAR(TRANSFER(tmp,a))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26994
--- Comment #5 from paulthomas2 at wanadoo dot fr 2006-04-03 00:56 ---
Subject: Re: Scalar TRANSFER - error: invalid
operand to unary operator
pinskia at gcc dot gnu dot org wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-02 22:43
---
A work around is to
--- Comment #4 from joseph at codesourcery dot com 2006-04-03 00:59 ---
Subject: Re: German translation of gcc 4.1
On Sun, 2 Apr 2006, stigge at antcom dot de wrote:
Attaching the files themselves makes the mail for the list too big. GZipping
them makes the spam checker reject
--- Comment #1 from pault at gcc dot gnu dot org 2006-04-03 04:21 ---
Subject: Bug 26981
Author: pault
Date: Mon Apr 3 04:20:57 2006
New Revision: 112634
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112634
Log:
2006-04-03 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from pault at gcc dot gnu dot org 2006-04-03 04:21 ---
Subject: Bug 26976
Author: pault
Date: Mon Apr 3 04:20:57 2006
New Revision: 112634
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112634
Log:
2006-04-03 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-03 04:31 ---
Reduced testcase:
typedef long unsigned int size_t;
void output_file_names (size_t ndirs)
{
size_t i;
for (i = 0; i ndirs; i++)
{
size_t j;
for (j = i + 1; j ndirs; j++)
{
--- Comment #3 from gerald at pfeifer dot com 2006-04-03 04:58 ---
Loren, is this something you could help with reviewing/approving
(for 4.2 and 4.1)?
--
gerald at pfeifer dot com changed:
What|Removed |Added
74 matches
Mail list logo
