--- Comment #9 from reichelt at gcc dot gnu dot org 2007-12-12 08:11
---
> Are you sure you don't have a modified compiler?
Pretty sure. I bootstrapped a really clean one ("svn diff --no-ignore" showed
nothing) last night on i686-pc-linux-gnu. It still shows the segfault.
The x86_64-u
--- Comment #2 from steven at gcc dot gnu dot org 2007-12-12 08:12 ---
spam
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
Since at least 3.4, the GCC manual says:
Use the `section' attribute with an _initialized_ definition of a
_global_ variable, as shown in the example. GCC issues a warning
and otherwise ignores the `section' attribute in uninitialized
variable declarations.
but this doesn't s
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-12-12 09:55 ---
Without optimization main() preprocesses to
int main() {
((__m128i)__builtin_ia32_pshufd ((__v4si)Vec(5), (((3) << 6) | ((3) << 4) |
((3) << 2) | (3;
}
with optimization we get instead
int main() {
_m
--- Comment #2 from sam at gcc dot gnu dot org 2007-12-12 10:29 ---
Confirmed
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
CC|
Class.getEnclosingClass() returns null on enclosed class.
Specifically:
c = class org.freedesktop.DBus$Local$Disconnected
c.getEnclosingClass() = null
(followed by a null pointer exception on the next line)
Code which prints that:
if (Debug.debug) Debug.print(Debug.VERBOSE, "c = "+
--- Comment #12 from aldyh at gcc dot gnu dot org 2007-12-12 11:18 ---
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00525.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from olafvdspek at gmail dot com 2007-12-12 12:29 ---
> Just use
It'd be nice if the deprecated warning mentioned that file.
--
olafvdspek at gmail dot com changed:
What|Removed |Added
-
--- Comment #6 from joel at gcc dot gnu dot org 2007-12-12 14:05 ---
RTEMS had a default implementation of the method in question that was in C. So
for the Thumb, I changed things to use it until the Thumb maintainer adds a
better version.
Thanks. I wasn't even finished adding the tes
--- Comment #2 from sven dot buijssen at math dot uni-dortmund dot de
2007-12-12 15:04 ---
Having reread the Fortran 95 language spec I don't see why the initial testcase
violates the standard. But I managed to distill a testcase that does not need
recursive functions and still triggers
--- Comment #24 from hjl at lucon dot org 2007-12-12 15:26 ---
(In reply to comment #23)
> > Tobias. do as you
> > please. We can either revert the original patch and get back to this
> > without
> > time pressure or proceed quickly.
> Maybe reverting and proceeding then quickly w/o ti
--- Comment #1 from tromey at gcc dot gnu dot org 2007-12-12 16:28 ---
Here's a complete test case.
The .class file does have the InnerClasses attribute,
we just don't seem to read it properly.
public class p
{
public interface DBI { }
public interface Local extends DBI {
publi
--- Comment #3 from jv244 at cam dot ac dot uk 2007-12-12 16:11 ---
(In reply to comment #2)
I had confirmed the bug already on the first testcase, which is fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34438
--- Comment #5 from janis at gcc dot gnu dot org 2007-12-12 17:44 ---
It's legitimate to use -maltivec without -mabi=altivec unless linking against
objects that were compiled with -mabi=altivec, so adding the option to vect.exp
is merely hiding the problem. Is there a reason why only th
--- Comment #2 from nightstrike at gmail dot com 2007-12-12 17:33 ---
What do they mean?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34316
--- Comment #2 from nightstrike at gmail dot com 2007-12-12 17:33 ---
Does anyone know why the %ld formats are not recognized as valid?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34315
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-12 17:51 ---
As -m32 -maltivec without -mabi=altivec has the VMX regs effectively neither
fixed, nor call saved, nor call used, it simply can't work reliably.
Registers really need to have some rules for using them, while -m32 -mal
--- Comment #8 from bjoern dot m dot haase at web dot de 2007-12-12 18:14
---
Created an attachment (id=14738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14738&action=view)
patch
My new analysis leads me to the result that the key problem of this missed
optimization is a targe
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-12 18:54 ---
Subject: Bug 34254
Author: burnus
Date: Wed Dec 12 18:54:26 2007
New Revision: 130793
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130793
Log:
2007-12-12 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
rget: i386-apple-darwin8.11.1
Configured with: ../gcc/configure --disable-bootstrap --enable-multilib
--prefix=/usr/local/gfortran --enable-languages=c,fortran
Thread model: posix
gcc version 4.3.0 20071212 (experimental) (GCC)
--
Summary: internal compiler error: in cost_for_st
--- Comment #1 from dir at lanl dot gov 2007-12-12 19:18 ---
It has no problem with this program on a PowerPC Macintosh
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34445
--- Comment #25 from burnus at gcc dot gnu dot org 2007-12-12 19:11 ---
Created an attachment (id=14739)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14739&action=view)
Improved patch
> > Maybe reverting and proceeding then quickly w/o time pressure is best.
> Right now we can't
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dorit at gcc dot gnu dot
|
--- Comment #7 from janis at gcc dot gnu dot org 2007-12-12 19:22 ---
The failure goes away with -mabi=altivec, which is not the default with -m32.
I had never seen this failure in my earlier testing on powerpc64-linux because
whenever I used -maltivec I also used -mabi=altivec. It's n
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-12 20:00 ---
Confirmed. Breaks with -O -ftree-vectorize -msse2 because we don't have a cost
for
(gdb) call debug_generic_expr (stmt)
th_lsm.41_62 = th.6_55
(gdb) print *stmt_info
$2 = {type = undef_vec_info_type, stmt = 0xb7cf
--- Comment #4 from burnus at gcc dot gnu dot org 2007-12-12 20:29 ---
> Error: Fortran 2003: PUBLIC variable 'foo' at (1) of PRIVATE derived type
> 'myint'
> which seems unrelated to me and for which I probably should submit a new bug
> report.
It is unrelated, but simple to fix; patch
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-12-12 20:08 ---
Created an attachment (id=14740)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14740&action=view)
an improved version
Sanity checking found bugs :-)
--
tkoenig at gcc dot gnu dot org changed:
W
--- Comment #20 from jakub at gcc dot gnu dot org 2007-12-12 20:54 ---
Subject: Bug 30589
Author: jakub
Date: Wed Dec 12 20:54:10 2007
New Revision: 130794
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130794
Log:
PR bootstrap/30589
* doc/install.texi: Document
The following is evaluated incorrectly with gnatprep 3.4.6
# if not VAR_TRUE or VAR_TRUE then
ans := Good;
# else
ans := Wrong;
# end if;
Using command:
gnatprep -r -DVAR_TRUE=true thing.in thing.out
generates following results
--! # if not VAR_TRUE or VAR_TRUE then
--!ans := G
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
--- Comment #21 from jakub at gcc dot gnu dot org 2007-12-12 20:55 ---
The 3.12+ requirement documented, marking as fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34274
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34314
My Header file Interface.h has the following piece of code
template
class Interface {
...
protected:
static const std::string cConfItem;
};
typedef Interface InterfaceFileXfer;
In my source file Interface.cxx
I have the following:
const s
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34357
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34399
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34435
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33916
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33819
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-12-12 21:09 ---
Might as well fix another one, this is easy...
Front end, here I come again!
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-12-12 21:02 ---
Please provide a compilable testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from ubizjak at gmail dot com 2007-12-12 21:39 ---
(In reply to comment #1)
> My suggestion is to force the same "argument"
> type by doing
>
> #define _mm_shuffle_epi32(__A, __B) \
> ((__m128i)__builtin_ia32_pshufd ((__v4si)(__m128i)__A, (int)__B))
>
> and adjust all !
--- Comment #13 from janis at gcc dot gnu dot org 2007-12-12 22:04 ---
Additional regression hunts on trunk discovered that the test starts failing
with:
http://gcc.gnu.org/viewcvs?view=rev&rev=103956
r103956 | steven | 2005-09-06 18:51:26 + (Tue, 06 Sep 2005)
and starts p
--- Comment #3 from andry at inbox dot ru 2007-12-12 22:32 ---
> No, this should not happen, nothing should be rebuilding while doing a "make
> install".
>
> Can you attach the output of doing a "clean" make and then a "make install"
> (please put them into two seperate output files)?
>
port,
with preprocessed source if appropriate.
This happens with
gcc version 4.3.0 20071212 (experimental) [trunk revision 127646] (Debian
20071212-1)
but didn't happen with
gcc version 4.3.0 20071207 (experimental) [trunk revision 127646] (Debian
20071206-1)
--
Summary: [4.3 Reg
--- Comment #1 from tbm at cyrius dot com 2007-12-12 22:33 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
typedef struct chunk_t chunk_t;
struct chunk_t
{
unsigned char *ptr;
long unsigned int len;
};
extern chunk_t asn1_wrap (chunk_t c, ...);
typedef struct linked_list_
=/tmp/bangerth/bin --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20071212 (experimental) (GCC)
examples/step-14> c++ -D_GLIBCXX_PARALLEL -fopenmp -march=native -mtune=native
a.cc -g -O2
examples/step-14> ./a.out
Segmentation fault
examples/step-14> uname
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-12-12 22:47
---
Great. That doesn't make too much sense ;) Because the testcase in comment #7
cannot be "optimized" on the tree level, but I see it is wrongly expanded to
RTL instead.
Now, the revisions are
103956: make tree-
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-12 23:03 ---
(your trunk revision reporting is broken)
On which architecture? This works for me on i686 with r130793.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-12-12 23:08 ---
Ok, I see it on x86_64 with r130795 and it didn't reproduce before SVN update
so it identified
2007-12-12 Aldy Hernandez <[EMAIL PROTECTED]>
PR tree-optimization/32901
* gimplify.c (gimplify_modif
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-12 23:24 ---
>template const string Interface::cConfItem =
"Handler.FileXferH";
The above code is incorrect and it should be:
template <> const string Interface::cConfItem =
"Handler.FileXferH";
And that removes the ICE.
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-12-12 23:24
---
*** Bug 34447 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from janis at gcc dot gnu dot org 2007-12-12 23:28 ---
I had assumed that -maltivec -mabi=no-altivec was supposed to work in the
general case, then had some discussions about it on #gcc today and learned that
it doesn't and is a known problem. Given that, we ought to add
--- Comment #4 from aldyh at gcc dot gnu dot org 2007-12-12 23:33 ---
I'll take care of this.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #8 from janis at gcc dot gnu dot org 2007-12-12 23:34 ---
Ira, it seems I've wasted your time; it's a well-known problem (except to me)
that -maltivec without -mabi=altivec doesn't work in the general case because
vector registers are not saved and restored. That explains wh
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Keywords||ice-on-valid-
--- Comment #5 from acornejo at gmail dot com 2007-12-12 23:43 ---
I have a similar bug, so I am posting here (otherwise I can open a new bug).
I run:
./configure --target=mipsel-semb-elf --prefix=/scratch/semb/semb/
--disable-libssp --with-newlib --enable-languages=c --disable-threads
--- Comment #5 from jakub at gcc dot gnu dot org 2007-12-13 00:08 ---
ret = GS_OK; } ret = GS_UNHANDLED; looks suspicious, but
@@ -3492,6 +3492,7 @@ gimplify_modify_expr_rhs (tree *expr_p,
{
*from_p = DECL_INITIAL (*from_p);
ret = GS_OK;
+ bre
--- Comment #6 from pbrook at gcc dot gnu dot org 2007-12-13 01:04 ---
Subject: Bug 30192
Author: pbrook
Date: Thu Dec 13 01:03:53 2007
New Revision: 130800
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130800
Log:
2007-12-13 Richard Earnshaw <[EMAIL PROTECTED]>
PR t
--- Comment #8 from daney at gcc dot gnu dot org 2007-12-13 01:12 ---
Andrew proposed a patch (which was then approved) here:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01511.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
--- Comment #9 from pinskia at gmail dot com 2007-12-13 01:18 ---
Subject: Re: [4.3 Regression] Revision 130005 causes bootstrap failure with
--disable-checking
On 13 Dec 2007 01:12:13 -, daney at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> --- Comment #8 from daney at gcc
--- Comment #8 from jsjodin at gcc dot gnu dot org 2007-12-13 01:56 ---
(In reply to comment #7)
> >+static tree get_generic_type_node_from_size(int size)
>
> This function needs lots of improvement because the size of the modes is based
> on UNIT_BIT_SIZE (I think that is the macro nam
--- Comment #9 from tbm at cyrius dot com 2007-12-13 03:03 ---
I thought Mark told you two months ago to revert this patch and you didn't
object. Has anything changed since then? At this point, I no longer care
whether these headers are removed or not but I'd like to know for sure
so I
The test case below is expected to pass. With gcc 4.1.2 it aborts in the second
assert.
$ cat t.cpp && g++ t.cpp && ./a.out
#include
#include
struct DerivedCtype: std::ctype_byname {
DerivedCtype (): std::ctype_byname("") { }
};
template
bool check_use_facet (const std::locale &locale)
{
Compile the attached source with -O1 and it will take roughly 1.8 GB RAM
on x86_64 and over a minute with current trunk. 4.2 took a few seconds
and less than 200 MB RAM. Granted, this is with checking on because
I haven't had a chance to compile a version without checking, but this
still looks li
--- Comment #1 from tbm at cyrius dot com 2007-12-13 05:24 ---
Created an attachment (id=14741)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14741&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34450
--- Comment #10 from daney at gcc dot gnu dot org 2007-12-13 05:28 ---
Currently testing on x86_64-pc-linux-gnu. I will commit if all OK.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sebor at roguewave dot com 2007-12-13 05:41 ---
FWIW, it looks like you need a dynamic_cast in use_facet (it's not enough to
check the id and then downcast using static_cast). Something like this:
--- locale_facets.tcc 2007-10-21 08:33:43.0 -0600
+++ locale_f
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2007-12-13 06:06
---
Tobias, I know why the weird case in the namelist_42.f90 fails. We just are
not addressing the need to eat spaces or separators at the right places. I
started working up an updated patch tonight, but have not g
In gcc/config/i386.c, there is a typo in the function ix86_rtx_costs.
Code snippet:
/* Compute costs correctly for widening multiplication. */
if ((GET_CODE (op0) == SIGN_EXTEND || GET_CODE (op1) == ZERO_EXTEND)
It should use op0 for both these tests.
--
Summary
--- Comment #1 from tege-gcc at swox dot com 2007-12-13 07:21 ---
This bug is present also in the svn head.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34451
74 matches
Mail list logo
