--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-01-13
08:32 ---
Testing a patch.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
-
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-13 08:49 ---
(In reply to comment #4)
> This is similar to 34432 is some ways. I think we are not matching the (\ \)
> correctly. I don't think gfc_match_expr has the tooling for it yet.
The error message is spurious in my opinio
--- Comment #2 from pluto at agmk dot net 2008-01-13 10:23 ---
(In reply to comment #1)
> What is the question you want to ask? The first code you show is invalid,
> the second valid...
i'd ask why the first code is invalid?
class Y looks pretty complete so why typedef expression throws
Yesterday and today has been building trunk (up-to-date) for 4.3 and still
getting the same error, here the config.log:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by GNU C Runtime Library configure 1
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-13 10:26 ---
It would be great, if you could create a minimal example; I still do not fully
understand what is not working. I get the same output using gfortran, the Intel
Fortran Compiler 10.1 and g95.
Or at least give an exampl
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-13 10:34 ---
I modified now FUNCTION fluid_Statistics to read as follows:
205print *, 'BEFORE'
206v1 = velocity(1)
207PRINT *,'AFTER gfortran_bug: the line above this should indicate
the terminati
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-01-13 11:18 ---
Subject: Bug 32135
Author: hubicka
Date: Sun Jan 13 11:18:08 2008
New Revision: 131502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131502
Log:
PR middle-end/32135
* tree-ssa-ccp.c (maybe_f
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-01-13 11:26 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-13 11:32 ---
/cygdrive/e/Work/gcc_4_3_trunk_2008-01-13_build/./gcc/xgcc: No such file or
directory
figure out why the stage1 compile did not generate that.
--
rguenth at gcc dot gnu dot org changed:
What|Remo
--- Comment #15 from bonzini at gnu dot org 2008-01-13 12:02 ---
Considering that we allocate exactly 1 sparseset per function, it cannot change
the performance in any way to initialize the memory, so maybe we do want to go
for that. But it is just stupid IMHO if the beauty of the data
--- Comment #2 from tim at klingt dot org 2008-01-13 12:38 ---
... i tried when reporting the bug ... however i haven't really been able
create a stripped down version ...
the problem also occurs when using std::tr1::array instead of boost::array,
though ...
--
http://gcc.gnu.org/b
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-13 12:53 ---
This is fixed in newer releases. Note that while the code overflows the signed
bitfield, it is still valid as the bitfield is integer promoted before each
operation.
Maybe fixed by the fix for PR30274.
--
rguen
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-13 12:57 ---
3.4 rejects this with
t.C:6: error: `((void (C::*)(int)))0)' is not a valid template argument
t.C:6: error: it must be a pointer-to-member of the form `&X::Y'
t.C:6: error: invalid type in declaration before ';' tok
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-13 13:23 ---
Mine. Probably also causes PR32139.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-13 13:25 ---
Um, this is a FE bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Comp
int x;
void __attribute__((noinline)) foo (void)
{
x = -x;
}
void __attribute__((const,noinline)) bar (void)
{
}
int __attribute__((noinline))
test (int c)
{
int tmp = x;
(c ? foo : bar) ();
return tmp + x;
}
extern void abort (void);
int main()
{
x = 1;
if (test (1) != 0)
abort
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-13 13:02 ---
*** This bug has been marked as a duplicate of 27574 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Here is the minimal test case exhibiting my trouble:
$ cat bug.cc
#include
class c { public: c (); };
c::c ()
{
int i = 42;
std::cout << i << std::endl;
}
int
main (int argc, char** argv)
{
c* C = new c;
}
I compile it with the following command:
--- Comment #16 from pinskia at gcc dot gnu dot org 2008-01-13 13:02
---
*** Bug 34767 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-13 13:50 ---
The bug is in common_pointer_type (), where we merge the function type
qualifiers (TYPE_READONLY is used for 'const' functions):
else if (TYPE_P (exp) && TYPE_READONLY (exp) && ! TREE_THIS_VOLATILE (exp))
flag
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-13 14:04
---
Honza, can you have a look here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ismail at pardus dot org dot tr 2008-01-13 14:01
---
This is possibly is the reason for new test failures:
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 59)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 65)
FAIL: gcc.dg/Warray-bounds.c (test for w
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-13 14:37 ---
Does this work on the current 4.1 branch now?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-13 14:48 ---
Confirmed. They also ICE on ppc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-13 14:58 ---
How is the status now?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-01-13 14:56
---
Closing as fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-13 14:52 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-13 14:49 ---
ice-on-valid, raising to P4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-13 14:36 ---
./cc1 -quiet t.c -O2
t.c: In function test:
t.c:6: internal compiler error: tree check: expected ssa_name, have var_decl in
mark_operand_necessary, at tree-ssa-pre.c:2460
Please submit a full bug report,
with prepr
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-13 14:35 ---
Confirmed.
The bogus part is actually that we have two TREE_LISTs as arguments to
BIT_IOR_EXPR:
<<< Unknown tree: cast_expr
0 >>>
| <<< Unknown tree: cast_expr
0 >>>
Where the CAST_EXPRs with the tree-list ar
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-13 14:46 ---
It indeed works on the 4.2 branch where the loads magically disappear with the
first may_alias pass. Possibly because it doesn't pay attention to whether
DECL_GIMPLE_REG is set or not.
--
rguenth at gcc dot gnu
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-13 14:55 ---
Does this bug still happen? There were a lot of changes in the m68k backend
since
the bug report was opened.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from jvdelisle at verizon dot net 2008-01-13 15:18 ---
Subject: Re: Rejects valid with bogus error message:
parameter initalization
pault at gcc dot gnu dot org wrote:
> --- Comment #5 from pault at gcc dot gnu dot org 2008-01-13 08:49 ---
> (In reply to commen
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-13 15:22 ---
Please provide preprocessed source, as this test pulls in system headers.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-13 15:24 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-13 15:25 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-13 15:27 ---
There are questions pending.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-13 15:11 ---
Confirmed. We leak
(gdb) call debug_tree (t)
used unsigned SI file t.i line 3 col 10
align 32 context
(reg:SI 58)>
to
#2 0x08218782 in set_reg_attrs_for_decl_rtl (t=0xb7cb2108, x=0xb7caee60)
a
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-13 15:15 ---
This was caused by
+2007-12-19 Richard Sandiford <[EMAIL PROTECTED]>
+
+ * rtl.def (SUBREG): Update comments.
...
+ (set_reg_attrs_for_decl_rtl): New function, split out from
+ set_decl_incoming_
pault at gcc dot gnu dot org wrote:
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-13 08:49 ---
(In reply to comment #4)
This is similar to 34432 is some ways. I think we are not matching the (\ \)
correctly. I don't think gfc_match_expr has the tooling for it yet.
The erro
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-13 15:23 ---
Testcase?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONF
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-13 15:39 ---
Adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-13 15:43
---
Unclear status of this bug. Removing target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-01-13 15:47
---
This works for me on the branch. Uros, what is exactly failing?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
Have put together a small test program demonstrating the error, which has to do
with indexing of a pointer when the array it points to starts at an index other
than '1'. The test program, gfortran behavior, and the correct (ifort)
behavior
of the program is listed below.
[EMAIL PROTECTED] ~]$ ca
On Linux/Intel64, with revision 131442, I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/no-vfa-pr29145.c
-ftree-vectorize -fno-vect-cost-model -msse2 -O2 -fdump-tree-vect-
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-13 15:30 ---
I am closing this bug as INVALID based on the doubious testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
(c) and c
are regarded as the same for character variables; for other types (z) and z are
not the same.
gfc_get_parentheses (gfc_expr *e)
{
gfc_expr *e2;
/* This is a temporary fix, awaiting the patch for various
other character problems. The resolution and translation
of substring
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-13 15:40
---
Non-regressions should not have a target milestone set.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-13 15:42 ---
Non-regression shouldn't have a target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-13 15:44
---
Adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Tar
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-13 16:04 ---
The m68k and m68hc11 are not the same backend.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-13 16:13 ---
This works with -funit-at-a-time, where we don't expand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34601
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-13 16:17 ---
I can reproduce it in GCC/gfortran 4.1.3 and 4.2.1, but it works in 4.3.0.
Could you try with a newer GCC? http://gcc.gnu.org/wiki/GFortranBinaries
--
burnus at gcc dot gnu dot org changed:
What|R
--- Comment #1 from hjl at lucon dot org 2008-01-13 16:25 ---
Revision 131429:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00367.html
--
hjl at lucon dot org changed:
What|Removed |Added
---
--- Comment #2 from hjl at lucon dot org 2008-01-13 16:26 ---
Revision 131429 is the cause.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
--- Comment #3 from bangerth at dealii dot org 2008-01-13 16:31 ---
(In reply to comment #2)
> i'd ask why the first code is invalid?
> class Y looks pretty complete so why typedef expression throws an error?
A class is complete at the closing brace. You use it before that.
W.
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-13 16:31 ---
Subject: Bug 34601
Author: rguenth
Date: Sun Jan 13 16:30:51 2008
New Revision: 131506
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131506
Log:
2008-01-13 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from hjl at lucon dot org 2008-01-13 16:31 ---
This bug may only happen when you compile for 32bit on 64bit host.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-13 16:32 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
damian at rouson dot net changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34765
--- Comment #5 from damian at rouson dot net 2008-01-13 16:40 ---
I was trying to demonstrate multiple instances of the bug. Based on comment
#4, I realize that the compiler performed correctly in at least 3 of the 4
instances. I will now attempt to verify whether the 4th instance is ac
--- Comment #2 from john at michalakes dot us 2008-01-13 16:43 ---
Subject: RE: Incorrect array indexing through pointer when array does not
start at 1
Will do. Thanks for the quick response. -John
> -Original Message-
> From: burnus at gcc dot gnu dot org [mailto:[EMAIL PROTE
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-13 16:45 ---
It simply vectorizes all loops in the testcase. It looks like there may be a
non-canonical sizetype constant (just wild guesses).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33810
--- Comment #8 from danglin at gcc dot gnu dot org 2008-01-13 16:53 ---
Subject: Bug 34762
Author: danglin
Date: Sun Jan 13 16:53:02 2008
New Revision: 131508
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131508
Log:
PR middle-end/34762
* reload.c (find_reloads_
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-13 16:55 ---
> Please provide preprocessed source, as this test pulls in system headers.
Do you need the system headers for Darwin9?
# 1 "/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c"
# 1 ""
# 1 ""
# 1 "/o
--- Comment #9 from danglin at gcc dot gnu dot org 2008-01-13 16:55 ---
Fixed by patch.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-13 17:00 ---
We enter that function with:
{4294967288B, +, 4}_1
unit size
align 32 symtab 0 alias set 2 canonical type 0x2acbd9dc1540
precision 32 min max
pointer_to_this >
sizes
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #7 from burnus at gcc dot gnu dot org 2008-01-13 17:41 ---
> One has to be careful not to to get the same problem as with SHAPE in PR
> 34759,
> i.e. passing a rank-2 array A(:,:,5) defined as rank-3 assumed-shape array
> A(:,:,*).
This is actually already properly handled.
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-13 17:41 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00567.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34763
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-13 17:41 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00566.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34759
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-13 17:49 ---
THis is related to PR 29382 and PR 13519. And I think this is exactly the same
issue as PR 28289.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34768
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-13 17:57 ---
(In reply to comment #3)
> It indeed works on the 4.2 branch where the loads magically disappear with the
> first may_alias pass. Possibly because it doesn't pay attention to whether
> DECL_GIMPLE_REG is set or not.
--- Comment #6 from damian at rouson dot net 2008-01-13 17:59 ---
It turns out this is not a gfortran bug. My apologies for any time wasted.
--
damian at rouson dot net changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
The info manual says:
`-Winit-self (C, C++, Objective-C and Objective-C++ only)'
Warn about uninitialized variables which are initialized with
themselves. Note this option can only be used with the
`-Wuninitialized' option, which in turn only works with `-O1' and
above.
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-13 18:17 ---
*** Bug 28289 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-13 18:17 ---
34768 has a testcase.
*** This bug has been marked as a duplicate of 34768 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-13 18:22 ---
This works for 'const' functions because they stick on the function type as
well.
The attributes are only on the DECL and do not get merged and transfered to the
resulting function type of the COND_EXPR.
So this aga
--- Comment #1 from olly at survex dot com 2008-01-13 18:23 ---
I've just noticed that Debian have a packaged 4.3 snapshot:
g++-4.3 (Debian 4.3-20080104-1) 4.3.0 20080104 (experimental) [trunk revision
131316]
Testing with this shows the same behaviour for C++.
--
olly at survex do
See attachment vf.i.
The bug manifests in code roughly corresponding to the code snippet:
union double_union
{
double d;
__uint32_t i[2];
};
union double_union tmp; tmp.d = value;
if ((tmp.i[1]) & ((__uint32_t)0x8000L)) {
value = -value;
*sign = '-';
} else
*sign = '\000';
As manif
--- Comment #1 from hp at gcc dot gnu dot org 2008-01-13 18:35 ---
Created an attachment (id=14935)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14935&action=view)
Preprocessed source corresponding to newlib vfprintf.c
Compile with -O2.
--
http://gcc.gnu.org/bugzilla/show_bu
While trying to pinpoint an *intermitent* warning/error with g++ 4.3
"mf/unit.h:84: error: no integral type can represent all of the enumerator
values for `metafloat::core::helpers::details::aligner<7u,
metafloat::core::float_t<0l, 0l, 0ul, CAT_NRM> >::'" i finally
got it to ice with the attached
--- Comment #1 from tbptbp at gmail dot com 2008-01-13 18:50 ---
Created an attachment (id=14936)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14936&action=view)
preprocessed offender
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2008-01-13 18:50:30 |2008-01-13 18:50:
--- Comment #6 from markus at unixforces dot net 2008-01-13 19:13 ---
still failing with the 4.1-20080107 snapshot
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28326
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-13 19:17 ---
This is the same issue as PR31714 (which occurs only on the 4.1 branch).
#0 0x084c1ddd in operand_equal_p (arg0=0xb7d275b0, arg1=0xb7d275cc, flags=0)
at /home/richard/src/trunk/gcc/fold-const.c:3015
#1 0x084c4
I will attach a patch that allows me to compile a compiler on Solaris 10/x86
that has a native bits size of 64 for produced code. I created the
configuration analogous to the sparcv9-sun-solaris2.* case.
With this patch I have successfully built a fully 64-bits environment
(toolchain, userland) t
--- Comment #1 from grobian at gentoo dot org 2008-01-13 19:21 ---
Created an attachment (id=14937)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14937&action=view)
solaris x86_64 configuration
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34775
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-13 19:24 ---
Reduced testcase that is accepted by 3.3 and 3.4 w/o diagnostic but ICEs
starting with 4.0.
typedef unsigned int op_type_u_t;
typedef op_type_u_t op_type_t;
template
struct shift {
enum {
num_bits = op_type_u_
--- Comment #2 from grobian at gentoo dot org 2008-01-13 19:29 ---
*** Bug 34775 has been marked as a duplicate of this bug. ***
--
grobian at gentoo dot org changed:
What|Removed |Added
-
--- Comment #2 from grobian at gentoo dot org 2008-01-13 19:29 ---
I'm sorry for the spam, this should have been reported in bug #30726
*** This bug has been marked as a duplicate of 30726 ***
--
grobian at gentoo dot org changed:
What|Removed |Ad
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-13 19:29 ---
Created an attachment (id=14938)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14938&action=view)
unincluded testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
--- Comment #3 from grobian at gentoo dot org 2008-01-13 19:30 ---
In bug #34775 I've attached a configuration patch that works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30726
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Version|unknown |4.3.0
http://gcc
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-01-13 19:38
---
In gfc_simplify_reshape, gfc_get_array_element is returning a NULL pointer.
This is due to a failure in expand_constructor. I am still tracing this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34556
--- Comment #5 from tbptbp at gmail dot com 2008-01-13 19:47 ---
Thanks a lot for your investigations.
May i ask if the apparent 'quenching' of sign mismatch - and related - warnings
(that is if you pile enough templates, due warning are never emitted), is in
any way related to this bug?
1 - 100 of 130 matches
Mail list logo
