Type spec support for constructors was implemented in PR27997, however, it is
not honored for the -std=f* checking for PARAMETERs.
The following program works with default options, however, using -std=f2003 one
gets the follow error message:
Error: The CHARACTER elements of the array constructor
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-13 07:11 ---
Subject: Bug 36495
Author: burnus
Date: Fri Jun 13 07:10:15 2008
New Revision: 136740
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136740
Log:
2008-06-13 Tobias Burnus [EMAIL PROTECTED]
PR
I get the following warnings when building libgfortran.
I think they should be fixed and libgfortran should be build with -Werror.
generated/all_l1.c:142: warning: format '%d' expects type 'int', but argument 2
has type 'index_type'
generated/all_l2.c:142: warning: format '%d' expects type 'int',
--- Comment #4 from burnus at gcc dot gnu dot org 2008-06-13 07:43 ---
FIXED on the trunk (4.4.0).
(For building also the C part of libgfortran with -Werror, see PR36518; the
.f90f.in file in libgomp has now also implicit none [Rev. 136703]; however,
-fimplict-none is not used in
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-13 08:14 ---
Confirmed. We do not create a EH region in the first place even though
fprintf and fputs could throw. When CCP folds fputs to fputc it hits
the propagator assert
if (tree_could_throw_p (new_stmt))
{
i discovered one more problem with 4.3 branch head with patch suggested
in comment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498#c7
stats:
gcc-4.3-20080417 : ~500MB, 50 seconds.
gcc-4.3-head+patch : 5GB, 100% cpu, 40 minutes and still going...
# command line:
x86_64-gnu-linux-g++
--- Comment #1 from pluto at agmk dot net 2008-06-13 08:17 ---
Created an attachment (id=15759)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15759action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36519
Program received signal SIGSEGV, Segmentation fault.
0x00b3b4e0 in host_integerp (t=0x0, pos=0)
at /space/rguenther/src/svn/trunk/gcc/tree.c:4938
4938 return (TREE_CODE (t) == INTEGER_CST
#1 0x00504a0d in get_memory_rtx (exp=0x2b5573d27870,
len=0x2b5573b18420) at
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-13 08:33 ---
Testcase from net-tools:
typedef long unsigned int size_t;
typedef unsigned short int sa_family_t;
struct cmsghdr {
size_t cmsg_len;
__extension__ unsigned char __cmsg_data [];
};
typedef unsigned int
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-13 08:35 ---
For
struct cmsghdr {
size_t cmsg_len;
__extension__ unsigned char __cmsg_data [];
};
DECL_SIZE{_UNIT} of __cmsg_data is NULL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36520
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-06-13 08:42
---
Subject: Bug 36498
Author: rguenth
Date: Fri Jun 13 08:41:45 2008
New Revision: 136744
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136744
Log:
2008-06-13 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-06-13 08:46
---
For
struct cmsghdr {
size_t cmsg_len;
__extension__ unsigned char __cmsg_data [];
};
DECL_SIZE{_UNIT} of __cmsg_data is NULL.
I wondered if this could happen... now I know. :-) Fixing...
The program below on gcc 4.1.2 prints:
gcc4 test.c
./a.out
got 0
x
y
done
--
The program below on gcc 3.4.4 prints:
gcc test.c
./a.out
got 0
x
y
and then locks up...
--
#include stdio.h
int main()
{
unsigned int var102 =
--- Comment #1 from peter at xmos dot com 2008-06-13 08:52 ---
Created an attachment (id=15760)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15760action=view)
test.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36521
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-13 09:15 ---
Confirmed.
void es::ClockAnalyzer::initPrimitives()
is the offending function - yet another testcase with a huge initialization
sequence (we have problems there since long). This is probably caused by
the fix for
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-13 09:27 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from gunnar at greyhound-data dot com 2008-06-13 09:31
---
(In reply to comment #4)
This comes down to IV-OPTs not understanding {post,pre}_{dec,inc} at all.
There is another bug about this somewhere I think for arm. PowerPC has the
same issue too ...
If this
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-13 09:36 ---
Patch -- still untested.
Index: m4/ifunction_logical.m4
===
--- m4/ifunction_logical.m4 (Revision 136740)
+++ m4/ifunction_logical.m4
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-13 09:39 ---
Subject: Bug 36507
Author: jakub
Date: Fri Jun 13 09:38:31 2008
New Revision: 136745
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136745
Log:
PR c/36507
* c-decl.c (merge_decls): Don't clear
--- Comment #5 from jakub at gcc dot gnu dot org 2008-06-13 09:41 ---
Subject: Bug 36507
Author: jakub
Date: Fri Jun 13 09:40:21 2008
New Revision: 136746
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136746
Log:
PR c/36507
* c-decl.c (merge_decls): Don't clear
--- Comment #6 from jakub at gcc dot gnu dot org 2008-06-13 09:54 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-13 09:54 ---
Also occurs for -std=f2003 with
print *, [ character(len=2) :: 'a', 'bb' ]
- adjust bug summary
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-13 10:02 ---
Created an attachment (id=15761)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15761action=view)
patch
Patch. Wider testing appreciated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36519
The following test case fails with a linker error. It compiles okay with the
pragma omp task line removed.
templatetypename T
struct A
{
A() { }
A(const A) { }
void foo() { }
};
int main()
{
Aint a;
#pragma omp task
a.foo();
return 0;
}
g++- -fopenmp -Wall
(get_memory_rtx): Test for the presence of DECL_SIZE_UNIT
before evaluating it.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20080613-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36520
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-06-13 10:23
---
Thanks for the testcase.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
When I compile IdentifierTable.cpp from clang using gcc 4.3.1 I get a crash,
compiling with gcc 4.2.4 doesn't crash.
If I preprocess it first, and then compile it doesn't crash.
If I move the the llvm-svn/llvm/include files to a different folder it doesn't
crash.
So I am not even able to provide
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-13 11:24 ---
-fpch-preprocess is probably one of the keys?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36524
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-13 11:28 ---
Fixed in 4.1.0
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from edwintorok at gmail dot com 2008-06-13 11:34 ---
(In reply to comment #1)
-fpch-preprocess is probably one of the keys?
Running cc1plus without -fpch-preprocess still leads to a crash.
[EMAIL PROTECTED]:~/llvm-svn/llvm/tools/clang/lib/Basic$
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-13 11:45 ---
Can you delete the preprocessed libstdc++ includes from /usr/lib?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36524
--- Comment #4 from edwintorok at gmail dot com 2008-06-13 12:01 ---
(In reply to comment #3)
Can you delete the preprocessed libstdc++ includes from /usr/lib?
Sure, I only had these:
$ find /usr/lib/ /usr/local/lib -name *.gch
The SPU ABI states:
The first word of the stack frame must always point to the previously
allocated stack frame (toward higher addresses), except for the first stack
frame, which must have a back chain pointer of 0 (NULL).
SPU doesn't have a single instruction that can both write the back chain
Hi,
I discovered a problem with gfortran 4.3.1 when compiling code with pure
function with pointer argument. Inside the pure function, the argument is
passed further to an other function. This seems to work, as long this other
function is an intrinsic function, but seems to fail for user
We have encountered what seems to be a gcc bug in the attempt to upgrade our
toolchain (using buildroot, embedded ARM no-MMU CPU) from 3.4.6 to 4.2.x. The
bug has been seen on both 4.2.3 and 4.2.4. We have not yet been able to build a
toolchain based on gcc 4.3.1. Most of our +5 MB system runs
--- Comment #1 from benny at ammitzboell-consult dot dk 2008-06-13 12:59
---
Created an attachment (id=15762)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15762action=view)
C test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #2 from benny at ammitzboell-consult dot dk 2008-06-13 13:00
---
Created an attachment (id=15763)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15763action=view)
C++ test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #3 from benny at ammitzboell-consult dot dk 2008-06-13 13:00
---
Created an attachment (id=15764)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15764action=view)
test.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #4 from benny at ammitzboell-consult dot dk 2008-06-13 13:01
---
Created an attachment (id=15765)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15765action=view)
test.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #5 from benny at ammitzboell-consult dot dk 2008-06-13 13:01
---
Created an attachment (id=15766)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15766action=view)
testcpp.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #6 from benny at ammitzboell-consult dot dk 2008-06-13 13:01
---
Created an attachment (id=15767)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15767action=view)
testcpp.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #5 from burnus at gcc dot gnu dot org 2008-06-13 13:05 ---
Subject: Bug 36476
Author: burnus
Date: Fri Jun 13 13:04:26 2008
New Revision: 136754
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136754
Log:
2008-06-13 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2008-06-13 13:14 ---
FIXED on the trunk (4.4.0).
Thanks for the report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-13 13:30 ---
Daniel, as you have implemented the constructor with type spec, maybe you have
an idea how to fix this best. The error message is generated in decl.c's
gfc_set_constant_character_len.
The problem is that for
--- Comment #6 from gunnar at greyhound-data dot com 2008-06-13 13:34
---
(In reply to comment #4)
This comes down to IV-OPTs not understanding {post,pre}_{dec,inc} at all.
There is another bug about this somewhere I think for arm. PowerPC has the
same issue too ...
Hi Andrew,
--- Comment #5 from edwintorok at gmail dot com 2008-06-13 13:37 ---
I have built with --enable-checking=yes (instead of all), because all was
taking too long.
It looks like a value of a pointer is invalid.
See the gdb session below.
What should I do next to help debug the problem?
http://groups.google.com/group/comp.lang.fortran/msg/86b65bad78e6af78
The following program should compile (with -fcray-pointer) and print on run
time:
integral f(x) u intervalu [0,1] = 0.49975004
integral f(x) u intervalu [0,1] = 0.49975004
sunf95 handles this correctly, however, gfortran
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-06-13 14:34 ---
Andrew, do you plan to fix this issue?
Personally no. Mostly because IV-opts is hard to understand.
Also it is not the m68k back-end doing the optimization rather loop.c did it.
See PR 31849.
*** This bug has
--- Comment #37 from pinskia at gcc dot gnu dot org 2008-06-13 14:34
---
*** Bug 36135 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Adding -fsee to the compile line causes ICE on a valid file which compiled fine
without -fsee.
--
Summary: -fsee causes ICE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
--- Comment #1 from william dot l dot maynard at nasa dot gov 2008-06-13
15:29 ---
Created an attachment (id=15768)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15768action=view)
file from the compile which produced ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36529
--- Comment #2 from william dot l dot maynard at nasa dot gov 2008-06-13
15:35 ---
Created an attachment (id=15769)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15769action=view)
GNU c++ compiler make command and error output
--
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
If stddef.h is included after wchar.h and wctype.h, the following error
occurs:
$ cat test.cpp g++ -c test.cpp
#include wchar.h
#include wctype.h
#include stddef.h
using namespace std;
ptrdiff_t ptr = 0;
test.cpp:9: error: ptrdiff_t does not name a type
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-13 16:54 ---
For gfortran documentation, see:
http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html#Cray-pointers
a) If used directly, the tree is wrong (see dump), but it works nonetheless
(I somehow have not to realize
--- Comment #3 from d at domob dot eu 2008-06-13 17:04 ---
Confirmed. I'll try to get this fixed!
Might be funny, as I can't yet think of any reason why -std= should affect such
a behaviour... But I also haven't looked at the code for this one deeper, so
hopefully I'll find out soon!
With the -Wno-packed switch used, I'm still getting message like
warning: 'packed' attribute ignored for field of type 'foo'.
I see it associated with members of structs, but I haven't researched if it is
associated with non-struct stand alone variables.
--
Summary: -Wno-packed
--- Comment #1 from jmorrison at printronix dot com 2008-06-13 17:21
---
Here is the configure info:
Configured with: /home/morr_jo/work/ToolChain/cross/src/gcc-4.2.0/configure
--target=powerpc-eabi --prefix=/opt/lnxshare/gcc.ppc-4.2.0
--enable-languages=c,c++ --with-gnu-as
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-13 17:52 ---
CONFIRM. Works with other compilers. The constraint checked for is:
C1272 In a pure subprogram any designator with a base object that is in common
or accessed by host or use association, is a dummy argument of a
--- Comment #4 from d at domob dot eu 2008-06-13 17:53 ---
Created an attachment (id=15770)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15770action=view)
Probably obvious fix.
Attached a simple fix by disabling this error if we are inside an
array-constructor with typespec; the
--- Comment #4 from burnus at gcc dot gnu dot org 2008-06-13 18:10 ---
OK, I can reproduce it now. Workaround: Replacing -std=f2003 by -std=gnu.
First program, causes an ICE. g95 prints
Error: Symbol 'max_fld_hed' at (1) has no IMPLICIT type
--- Comment #2 from andreast at gcc dot gnu dot org 2008-06-13 18:29
---
Fixed. Thanks.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-13 18:44 ---
Subject: Bug 36518
Author: burnus
Date: Fri Jun 13 18:43:25 2008
New Revision: 136761
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136761
Log:
2008-06-13 Tobias Burnus [EMAIL PROTECTED]
PR
int main() {
*c = 'x';
}
Compiling the above with just 'gcc asdf.c':
asdf.c: In function âmainâ:
asdf.c:2: internal compiler error: in simplify_subreg, at simplify-rtx.c:4484
I've duplicated this on both Windows and Linux, respective 'gcc -v' outputs are
as follows:
--
Using
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-13 18:48 ---
FIXED on the trunk (4.4.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-13 18:52 ---
This code is undefined.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-06-13 19:27 ---
There was some fixes to the trunk for -fsee really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36529
--- Comment #5 from burnus at gcc dot gnu dot org 2008-06-13 20:25 ---
First program, causes an ICE.
Valgrind shows that it fails in decl.c's build_struct:
if (c-ts.type == BT_CHARACTER !c-pointer c-initializer)
{
int len = mpz_get_si (c-ts.cl-length-value.integer);
As
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-06-13 20:28
---
Subject: Bug 35863
Author: jvdelisle
Date: Fri Jun 13 20:28:08 2008
New Revision: 136763
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136763
Log:
2008-06-13 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-06-13 20:31
---
Subject: Bug 35863
Author: jvdelisle
Date: Fri Jun 13 20:30:48 2008
New Revision: 136764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136764
Log:
2008-06-13 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-06-13 20:35
---
Subject: Bug 35863
Author: jvdelisle
Date: Fri Jun 13 20:35:12 2008
New Revision: 136766
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136766
Log:
2008-06-13 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from d at domob dot eu 2008-06-13 20:36 ---
Thanks for the additional hint, I'm into this. I've implemented some tests and
am now working on integrating this fix with my pending patch for PR 36517.
When the bogus error is fixed, I'll work on the ICE and hopefully we can
--- Comment #7 from burnus at gcc dot gnu dot org 2008-06-13 21:19 ---
Works for me. Possibly fixed by PR preprocessor/36479.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
The following testcase is miscompiled on i?86 -m32 -Os:
/* { dg-options -Os } */
typedef struct S1
{
unsigned long s1;
struct S1 *s2;
char *s3;
} S1;
typedef struct
{
unsigned int s4;
unsigned int s5;
int s6;
unsigned int *s7;
} S2;
typedef struct
{
unsigned int s8;
unsigned
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||bergner at gcc dot gnu dot
|
Found via a typo and missing -pedantic in
gfortran.dg/parameter_array_init_4.f90
$ gfortran -pedantic gfortran.dg/parameter_array_init_4.f90
parameter_array_init_4.f90:18.45:
PARAMETER ( MY_STRING4 = (/ A , B, C /) )
1
Warning: CHARACTER(*) function
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36364
--- Comment #19 from mmitchel at gcc dot gnu dot org 2008-06-13 21:40
---
Andrew --
Why did you reopen this? It sounds like the submitter was building in the
srcdir, and that when building in the objdir, it worked fined. Isn't that
exactly the situation we expect?
-- Mark
--
--- Comment #8 from mmitchel at gcc dot gnu dot org 2008-06-13 21:41
---
Ian --
Do you have any thoughts about this issue?
-- Mark
--
mmitchel 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=36344
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
--- Comment #11 from mmitchel at gcc dot gnu dot org 2008-06-13 21:43
---
Jakub --
This is still marked as a 4.3/4.4 regression. But, there are patches in the
audit trail. If that's correct would you please adjust the Summary field?
Thanks,
-- Mark
--
mmitchel at gcc dot gnu
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-13 21:46 ---
aligned_operand looks wrong:
/* Look for some component that isn't known to be aligned. */
if (parts.index)
{
if (REGNO_POINTER_ALIGN (REGNO (parts.index)) * parts.scale 32)
return 0;
}
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36373
--- Comment #14 from mmitchel at gcc dot gnu dot org 2008-06-13 21:53
---
Richard --
Is this still an issue, after your patch?
Thanks,
-- Mark
--
mmitchel 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=36519
--- Comment #7 from phorgan1 at gmail dot com 2008-06-13 21:54 ---
I don't know what changed, but on the same machine with the same circumstances
the build completes successfully now. I can only think that something in the
environment changed as a result of updates on the machine,
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #12 from jakub at gcc dot gnu dot org 2008-06-13 21:57 ---
See comment #c5. There are 3 issues, 1) has been fixed, 2) has a patch posted,
but so far not reviewed -
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00677.html
and 3) has no fix yet at all.
All 3 are needed to fix
--- Comment #13 from mmitchel at gcc dot gnu dot org 2008-06-13 21:59
---
I've reclosed this bug.
Manuel, if you'd like to open another issue for Comment #9, please go ahead.
Thanks,
-- Mark
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from bergner at gcc dot gnu dot org 2008-06-13 22:14 ---
We shouldn't be attempting to call mark_reg_pointer in set_reg_attrs_from_value
for a hard reg, since they can be shared between different values. Andrew
mentioned we maybe shouldn't be calling
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-13 22:19 ---
In addition to that, I wonder whether i386's aligned_operand shouldn't
prefer ORIGINAL_REGNO over REGNO when checking pointer alignment.
--
jakub at gcc dot gnu dot org changed:
What|Removed
On Linux/x86-64, I got
Executing on host:
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/parameter_array_init_4.f90
-O0
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-06-13 23:06
---
I love that one: Fixed-form is likely to be F77/legacy. Well, the issue is
that I don't think we have a way to tell, from the sym, that it's a internal
conversion function. Maybe the crude way, check if the name
1 - 100 of 113 matches
Mail list logo
