[Bug libstdc++/36363] New: set_union and _GLIBCXX_DEBUG does not compile
#include algorithm
#include vector
using namespace std;
int main( int, char** )
{
vectorint v1;
vectorint v2;
vectorint v3;
set_union( v1.begin(), v1.end(), v2.begin(), v2.end(), v3.begin() );
return 0;
}
$ g++ -o t t.cc -D_GLIBCXX_DEBUG
...
debug/functions.h:317: error: no matching function for call to
__check_sorted_set_aux()
...
--
Summary: set_union and _GLIBCXX_DEBUG does not compile
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36363
[Bug target/36362] [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 08:46 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.0.0 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2008-05-29 08:46:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
[Bug libstdc++/35541] [4.3 Regression] Legal C++ program can't be compiled with -D_GLIBCXX_DEBUG
--- Comment #9 from paolo dot carlini at oracle dot com 2008-05-29 08:54 --- *** Bug 36363 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||joerg dot richter at pdv-fs ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35541
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #10 from charlet at gcc dot gnu dot org 2008-05-29 08:56 --- Subject: Bug 864 Author: charlet Date: Thu May 29 08:56:01 2008 New Revision: 136149 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136149 Log: PR ada/864 * osint.ads, osint.adb (Program_Name): New parameter Prog to allow recognition of program suffix in addition to prefix. * gnatchop.adb (Locate_Executable): Add support for prefix. * make.adb, gnatcmd.adb, gnatlink.adb, prj-makr.adb, mlib-utl.adb: Adjust calls to Program_Name. Modified: trunk/gcc/ada/gnatchop.adb trunk/gcc/ada/gnatcmd.adb trunk/gcc/ada/gnatlink.adb trunk/gcc/ada/make.adb trunk/gcc/ada/mlib-utl.adb trunk/gcc/ada/osint.adb trunk/gcc/ada/osint.ads trunk/gcc/ada/prj-makr.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #11 from charlet at gcc dot gnu dot org 2008-05-29 08:59 --- Fixed. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug libstdc++/36363] set_union and _GLIBCXX_DEBUG does not compile
--- Comment #2 from paolo dot carlini at oracle dot com 2008-05-29 08:54 --- *** This bug has been marked as a duplicate of 35541 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36363
[Bug ada/33857] Cannot bootstrap Ada with host gnatmake-4.2
--- Comment #12 from charlet at gcc dot gnu dot org 2008-05-29 09:04 --- Also a duplicate of PR864, which is now fixed. *** This bug has been marked as a duplicate of 864 *** -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33857
[Bug libstdc++/36363] set_union and _GLIBCXX_DEBUG does not compile
--- Comment #1 from chris at bubblescope dot net 2008-05-29 08:54 --- This works fine for me on a couple of versions. Could you give us the output of ' g++ -v ' ? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36363
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #12 from charlet at gcc dot gnu dot org 2008-05-29 09:04 --- *** Bug 33857 has been marked as a duplicate of this bug. *** -- charlet at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug target/36362] [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg
--- Comment #2 from ubizjak at gmail dot com 2008-05-29 09:35 ---
This fails for all optimization levels:
--cut here--
extern float c;
int test(void)
{
return !!c * 7LL == 0;
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
[Bug target/36362] [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg
--- Comment #3 from rguenther at suse dot de 2008-05-29 09:42 ---
Subject: Re: [4.1/4.2/4.3/4.4 Regression] ICE in
simplify_subreg
On Thu, 29 May 2008, ubizjak at gmail dot com wrote:
--- Comment #2 from ubizjak at gmail dot com 2008-05-29 09:35 ---
This fails for all optimization levels:
--cut here--
extern float c;
int test(void)
{
return !!c * 7LL == 0;
}
--cut here--
We expand !(c != 0.0) via
8993 op0 = expand_expr (TREE_OPERAND (exp, 0), target,
8994 VOIDmode, EXPAND_NORMAL);
8995 /* The parser is careful to generate TRUTH_NOT_EXPR
8996 only with operands that are always zero or one. */
8997 temp = expand_binop (mode, xor_optab, op0, const1_rtx,
8998 target, 1, OPTAB_LIB_WIDEN);
and op0 is (reg:QI 61) (the comparison result) and mode is DImode
for no good reason - well, for the reason the original tree TRUTH_NOT_EXPR
has a DImode type...
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
[Bug c++/36364] New: [4.1/4.2/4.3/4.4 Regression] Problem with -frepo
template typename C struct A
{
static void assign (C c1, const C c2) { c1 = c2; }
};
template typename C, typename T struct B
{
struct D
{
static const C terminal;
static unsigned long stor[];
static D empty_rep ()
{
void *p = reinterpret_cast void *(stor);
return *reinterpret_cast D *(p);
}
void test (unsigned long n)
{
T::assign (this-refdata ()[n], terminal);
}
C *refdata () throw ()
{
return reinterpret_cast C *(this + 1);
}
};
C *dataplus;
C *data () const { return dataplus; }
D *rep () const { return ((reinterpret_cast D * (data ()))[-1]); }
static D empty_rep () { return D::empty_rep (); }
B () : dataplus (empty_rep ().refdata ()) { }
~B () { }
void push_back (C c) { rep ()-test (10); }
};
template typename C, typename T const C B C, T::D::terminal = C ();
template typename C, typename T unsigned long B C, T::D::stor[64];
int
main ()
{
B char, A char s;
s.push_back ('a');
}
g++ -c -frepo d.C
g++ -frepo -o d{,.o}
results in:
d.o: In function `Bchar, Achar ::D::test(unsigned long)':
d.C:(.text+0xc9): undefined reference to `Bchar, Achar ::D::terminal'
collect2: ld returned 1 exit status
3.4 worked fine.
--
Summary: [4.1/4.2/4.3/4.4 Regression] Problem with -frepo
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36364
[Bug c++/36364] [4.1/4.2/4.3/4.4 Regression] Problem with -frepo
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36364
[Bug tree-optimization/36347] points-to sets should be always kept for call-clobbering
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-29 10:32 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36347
[Bug tree-optimization/36346] call clobbering computation uses TBAA-pruned points-to-sets
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-29 10:32 --- Subject: Bug 36346 Author: rguenth Date: Thu May 29 10:31:58 2008 New Revision: 136152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136152 Log: 2008-05-29 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36343 PR tree-optimization/36346 PR tree-optimization/36347 * tree-flow.h (clobber_what_p_points_to): Declare. * tree-ssa-structalias.c (set_uids_in_ptset): Whether the pointed-to variable is dereferenced is irrelevant to whether the pointer can access the pointed-to variable. (clobber_what_p_points_to): New function. * tree-ssa-alias.c (set_initial_properties): Use it. * tree-ssa.c (verify_flow_sensitive_alias_info): Adjust call clobber check for NMTs. * gcc.c-torture/execute/pr36343.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr36343.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36346
[Bug tree-optimization/36347] points-to sets should be always kept for call-clobbering
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-29 10:32 --- Subject: Bug 36347 Author: rguenth Date: Thu May 29 10:31:58 2008 New Revision: 136152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136152 Log: 2008-05-29 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36343 PR tree-optimization/36346 PR tree-optimization/36347 * tree-flow.h (clobber_what_p_points_to): Declare. * tree-ssa-structalias.c (set_uids_in_ptset): Whether the pointed-to variable is dereferenced is irrelevant to whether the pointer can access the pointed-to variable. (clobber_what_p_points_to): New function. * tree-ssa-alias.c (set_initial_properties): Use it. * tree-ssa.c (verify_flow_sensitive_alias_info): Adjust call clobber check for NMTs. * gcc.c-torture/execute/pr36343.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr36343.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36347
[Bug tree-optimization/36343] [4.3/4.4 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-29 10:32 --- Subject: Bug 36343 Author: rguenth Date: Thu May 29 10:31:58 2008 New Revision: 136152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136152 Log: 2008-05-29 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36343 PR tree-optimization/36346 PR tree-optimization/36347 * tree-flow.h (clobber_what_p_points_to): Declare. * tree-ssa-structalias.c (set_uids_in_ptset): Whether the pointed-to variable is dereferenced is irrelevant to whether the pointer can access the pointed-to variable. (clobber_what_p_points_to): New function. * tree-ssa-alias.c (set_initial_properties): Use it. * tree-ssa.c (verify_flow_sensitive_alias_info): Adjust call clobber check for NMTs. * gcc.c-torture/execute/pr36343.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr36343.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36343
[Bug tree-optimization/36343] [4.3/4.4 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-29 10:34 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.0 4.4.0 |4.3.0 Known to work|4.1.3 4.2.4 |4.1.3 4.2.4 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36343
[Bug target/36362] [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg
--- Comment #4 from ubizjak at gmail dot com 2008-05-29 10:23 --- The problem is, that we enter simplify_gen_subreg from operand_subword with: op: (reg:QI 61) outermode: word_mode (SImode) innermode: DImode This triggers assert in simplify_subreg: gcc_assert (GET_MODE (op) == innermode || GET_MODE (op) == VOIDmode); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
[Bug tree-optimization/36346] call clobbering computation uses TBAA-pruned points-to-sets
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-29 10:33 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36346
[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1
--- Comment #6 from paolo dot carlini at oracle dot com 2008-05-29 10:29 --- Benjamin, can you double check this work? In debug mode the citerators testcases, which predate it, fail for me... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
[Bug rtl-optimization/36365] New: [4.3/4.4 Regression] Hang in df_analyze
On the attached testcase with -O1 cc1plus either hangs, or spends enormous amount of time in: #7 0x007d9a4b in df_analyze () at ../../gcc/df-core.c:1265 #8 0x009a7935 in find_defs (loop=0x7f67f7de3dc0, body=0x669f640) at ../../gcc/loop-invariant.c:644 #9 0x009a861e in find_invariants (loop=0x7f67f7de3dc0) at ../../gcc/loop-invariant.c:945 #10 0x009a9365 in move_single_loop_invariants (loop=0x7f67f7de3dc0) at ../../gcc/loop-invariant.c:1317 #11 0x009a93d8 in move_loop_invariants () at ../../gcc/loop-invariant.c:1347 #12 0x009a60f3 in rtl_move_loop_invariants () at ../../gcc/loop-init.c:243 (so far I've been waiting 10 minutes). -- Summary: [4.3/4.4 Regression] Hang in df_analyze Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #1 from jakub at gcc dot gnu dot org 2008-05-29 10:55 --- Created an attachment (id=15698) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15698action=view) rh448273.ii.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug target/36362] [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg
--- Comment #5 from rguenther at suse dot de 2008-05-29 10:59 --- Subject: Re: [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg On Thu, 29 May 2008, ubizjak at gmail dot com wrote: --- Comment #4 from ubizjak at gmail dot com 2008-05-29 10:23 --- The problem is, that we enter simplify_gen_subreg from operand_subword with: op: (reg:QI 61) outermode: word_mode (SImode) innermode: DImode This triggers assert in simplify_subreg: gcc_assert (GET_MODE (op) == innermode || GET_MODE (op) == VOIDmode); I believe this goes wrong on the tree level somewhere, as we have a TRUTH_NOT_EXPR of long long type with a boolean type argument (NE_EXPR). But I cannot see where this broken typed trees are built. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
[Bug fortran/36366] New: [4.3/4.4 Regression] ICE in gfc_conv_component_ref
MODULE types IMPLICIT NONE TYPE :: inner INTEGER, POINTER :: i(:) END TYPE inner TYPE :: outer TYPE(inner), POINTER :: inr(:) END TYPE outer END MODULE types MODULE mymod IMPLICIT NONE CONTAINS FUNCTION test1() USE types IMPLICIT NONE TYPE(outer), POINTER :: test1 NULLIFY(test1) END FUNCTION test1 END MODULE mymod MODULE test IMPLICIT NONE CONTAINS SUBROUTINE test2(a) USE mymod USE types IMPLICIT NONE TYPE(outer), INTENT(INOUT) :: a INTEGER :: i i = a%inr(1)%i(1) END SUBROUTINE test2 SUBROUTINE test3(a) USE types IMPLICIT NONE TYPE(outer), INTENT(IN) :: a END SUBROUTINE test3 END MODULE test ICEs in gfc_conv_component_ref since 4.3 - backend_decl is NULL. -- Summary: [4.3/4.4 Regression] ICE in gfc_conv_component_ref Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36366
[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers
--- Comment #10 from burnus at gcc dot gnu dot org 2008-05-29 11:29 --- Move comment from PR 36325, see also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bb371413b5cbe3d7 The following is regarded as valid and did not work with one of the last versions of proc pointer patches: abstract interface subroutine a end subroutine end interface procedure(a),pointer :: x procedure(x) :: y -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580
[Bug fortran/36361] attribute declaration outside of INTERFACE body
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-29 11:24 --- A related problem also occurs with the POINTER attribute: interface real function bar() end function bar end interface pointer :: bar This allowed and means a procedure pointer. See 5.1.2.6 EXTERNAL attribute A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer. While the following is a function (no proc pointer) with a pointer-valued return variable: interface function bar() real, pointer :: bar end function bar end interface -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36361
[Bug c/36367] New: warning for questionable compound expression
This typo in check_for_nested_with_variably_modified was present for 4 years
and hampered the inliner without anyone noticing:
Index: tree-nested.c
===
--- tree-nested.c (revision 136121)
+++ tree-nested.c (working copy)
@@ -693,7 +693,7 @@ check_for_nested_with_variably_modified
for (cgn = cgn-nested; cgn ; cgn = cgn-next_nested)
{
for (arg = DECL_ARGUMENTS (cgn-decl); arg; arg = TREE_CHAIN (arg))
- if (variably_modified_type_p (TREE_TYPE (arg), 0), orig_fndecl)
+ if (variably_modified_type_p (TREE_TYPE (arg), orig_fndecl))
return true;
It would be nice for the compiler to warn in this case, i.e. when members of
a compound expression (except for the last) don't have obvious side-effects.
--
Summary: warning for questionable compound expression
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36367
[Bug other/36368] New: Fixincludes corrupts sysmacros.h
Compiling this program:
#include sys/types.h
$ gcc a.c
In file included from /usr/include/sys/types.h:219,
from a.c:1:
/pdv/.tools/pkg/gcc/4.3.0/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed/sys/sysmacros.h:52:
error: expected ',' or ';' before '{' token
/pdv/.tools/pkg/gcc/4.3.0/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed/sys/sysmacros.h:58:
error: expected ',' or ';' before '{' token
/pdv/.tools/pkg/gcc/4.3.0/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed/sys/sysmacros.h:64:
error: expected ',' or ';' before '{' token
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/ws/jrichter/nfs/src/bld/cfg/build/tmp.evo4.19802/gcc-4.3.0/configure
--prefix=/tools/pkg/gcc/4.3.0 --enable-languages=c,c++ --disable-threads
--with-gmp=/tools/pkg/gmp/4.2.2 --with-mpfr=/tools/pkg/mpfr/2.3.1
Thread model: single
gcc version 4.3.0 (GCC)
$ uname -a
Linux evo4 2.4.21-47.0.1.ELsmp #1 SMP Fri Oct 13 17:56:20 EDT 2006 i686 i686
i386 GNU/Linux
Here is the relevant part of diff -u /usr/include/sys/sysmacros.h
.../include-fixed/sys/sysmacros.h
# if defined __GNUC__ __GNUC__ = 2
-__extension__ extern __inline unsigned int
-__NTH (gnu_dev_major (unsigned long long int __dev))
+__extension__ extern __inline __attribute__ ((__gnu_inline__)) unsigned int
+gnu_dev_major (unsigned long long int __dev) __THROW
{
return ((__dev 8) 0xfff) | ((unsigned int) (__dev 32) ~0xfff);
}
Note that __THROW expands to __attribute__ ((__nothrow__)) when compiling in C.
But it seems this attribute isn't allowed on function definitions.
--
Summary: Fixincludes corrupts sysmacros.h
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
[Bug other/36368] Fixincludes corrupts sysmacros.h
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 12:04 --- Please specify the glibc version you are using and attach both the unfixed and the fixed header. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Fixincludes corrupts|Fixincludes corrupts |sysmacros.h |sysmacros.h http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
[Bug fortran/36366] [4.3/4.4 Regression] ICE in gfc_conv_component_ref
-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-05-29 12:05:35 date|| Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36366
[Bug tree-optimization/36345] TBAA-pruning of points-to sets ineffective
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 12:12 --- Mine. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-29 12:12:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36345
[Bug other/36368] Fixincludes corrupts sysmacros.h
--- Comment #2 from joerg dot richter at pdv-fs dot de 2008-05-29 12:21 --- Seems I've used gcc on a machine with a newer libc than it was built on. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
[Bug c/36367] warning for questionable compound expression
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 12:00 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2008-05-29 12:00:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36367
[Bug target/36362] [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg
--- Comment #6 from jakub at gcc dot gnu dot org 2008-05-29 12:33 ---
Regtesting:
2008-05-29 Jakub Jelinek [EMAIL PROTECTED]
Richard Guenther [EMAIL PROTECTED]
PR target/36362
* gimplify.c (gimplify_expr): Convert gimple_boolify result
to TRUTH_NOT_EXPR's type.
* gcc.c-torture/execute/20080529-1.c: New test.
--- gcc/gimplify.c.jj 2008-05-18 22:14:23.0 +0200
+++ gcc/gimplify.c 2008-05-29 14:24:38.0 +0200
@@ -5748,7 +5748,8 @@ gimplify_expr (tree *expr_p, tree *pre_p
case TRUTH_NOT_EXPR:
TREE_OPERAND (*expr_p, 0)
- = gimple_boolify (TREE_OPERAND (*expr_p, 0));
+ = fold_convert (TREE_TYPE (*expr_p),
+ gimple_boolify (TREE_OPERAND (*expr_p, 0)));
ret = gimplify_expr (TREE_OPERAND (*expr_p, 0), pre_p, post_p,
is_gimple_val, fb_rvalue);
recalculate_side_effects (*expr_p);
--- gcc/testsuite/gcc.c-torture/execute/20080529-1.c.jj 2008-05-29
14:29:42.0 +0200
+++ gcc/testsuite/gcc.c-torture/execute/20080529-1.c2008-05-29
14:29:19.0 +0200
@@ -0,0 +1,17 @@
+/* PR target/36362 */
+
+extern void abort (void);
+
+int
+test (float c)
+{
+ return !!c * 7LL == 0;
+}
+
+int
+main (void)
+{
+ if (test (1.0f) != 0)
+abort ();
+ return 0;
+}
--
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 |
Status|NEW |ASSIGNED
Last reconfirmed|2008-05-29 08:46:59 |2008-05-29 12:33:58
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
[Bug middle-end/35771] Call expander ignores type alignment
--- Comment #10 from hjl at gcc dot gnu dot org 2008-05-29 12:35 --- Subject: Bug 35771 Author: hjl Date: Thu May 29 12:35:04 2008 New Revision: 136159 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136159 Log: gcc/ 2008-05-29 H.J. Lu [EMAIL PROTECTED] PR target/35771 * config/i386/i386.c (ix86_function_arg_boundary): Convert to canonical type if needed. gcc/testsuite/ 2008-05-29 H.J. Lu [EMAIL PROTECTED] PR target/35771 * gcc.dg/torture/pr35771.h: New. * gcc.dg/torture/pr35771-1.c: Likewise. * gcc.dg/torture/pr35771-2.c: Likewise. * gcc.dg/torture/pr35771-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr35771-1.c trunk/gcc/testsuite/gcc.dg/torture/pr35771-2.c trunk/gcc/testsuite/gcc.dg/torture/pr35771-3.c trunk/gcc/testsuite/gcc.dg/torture/pr35771.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35771
[Bug fortran/36276] [4.3/4.4 Regression] possible issue with opening fortran files?
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-29 12:40 --- Confirm. ==1593== Invalid read of size 1 ==1593==at 0xB51CD1: linemap_add (line-map.c:111) That is libcpp/line-map.c:111: source_location start_location = set-highest_location + 1; I quickly looked at the source code and in the debugger, but I could not find the problem. I had to add more comment lines to the 8-line test case, otherwise valgrind wouldn't diagnose the invalid read. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-29 12:40:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug target/36134] GCC creates suboptimal ASM : usage of ADDA.L where LEA could be used
--- Comment #3 from gunnar at greyhound-data dot com 2008-05-29 12:50 --- Created an attachment (id=15699) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15699action=view) Prefer 4 byte long LEA over 6 byte long ADD.L Please include the attached patch for GCC. The added patch has changed the case statement to prefer the 4 byte long lea over the 6 byte long add.l for immediate sub/add instructions to address registers with an immediate operant size of 16bit max. LEA is optimized for pipelining (with destination forwarding) and is shorter than ADD.L Regards Gunnar von Boehn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36134
[Bug middle-end/36369] New: [4.3/4.4 Regression] Type punning warning with may_alias attribute depends on unrelated class definition
#ifdef DEFINE_B
struct B
{
unsigned long b;
B operator= (bool x) { return *this; }
};
#endif
struct A
{
void *a;
};
bool operator = (const A x, long y)
{
typedef long __attribute__ ((may_alias)) long_a;
y = *reinterpret_cast const long_a * (x.a);
return true;
}
long test(const A x)
{
long a;
x = a;
return a;
}
issues (IMHO bogus) warning:
rh448897.C:15: warning: dereferencing type-punned pointer will break
strict-aliasing rules
when compiled with -O2 -Wall -DDEFINE_B, but not with -O2 -Wall.
--
Summary: [4.3/4.4 Regression] Type punning warning with may_alias
attribute depends on unrelated class definition
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug c/36370] New: Is the sse2 psrlq insn accessible ?
Hello,
I would like to use the psrlq sse2 instruction. There used to be
builtins named __builtin_ia32_psrlq128 and __builtin_ia32_psrlqi128.
The patch http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01571.html has
removed some SSE builtins, including these. However, the documentation
has not been updated accordingly, so one might be led to think that they
are still usable. Furthermore, the builtins at this moment seem to
half-exist ; they don't have prototypes, or so it seems. Things such as
this no longer compile:
typedef uint64_t v2di __attribute__((vector_size(16)));
v2di a,b,c;
int with_builtins()
{
a = __builtin_ia32_psrlqi128(b, 1);
a = __builtin_ia32_psrlq128(b, a);
}
sse-builtin-test.c: In function #8216;with_builtins#8217;:
sse-builtin-test.c:15: note: use -flax-vector-conversions to permit conversions
between vectors with differing element types or numbers of subparts
sse-builtin-test.c:15: error: incompatible type for argument 1 of
#8216;__builtin_ia32_psrlqi128#8217;
sse-builtin-test.c:15: error: incompatible types in assignment
sse-builtin-test.c:16: error: incompatible type for argument 1 of
#8216;__builtin_ia32_psrlq128#8217;
sse-builtin-test.c:16: error: incompatible type for argument 2 of
#8216;__builtin_ia32_psrlq128#8217;
sse-builtin-test.c:16: error: incompatible types in assignment
(I would like to stay away from -flax-vector-conversions, as the code above
in reality does no ``vector conversions'' per se).
The patch http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00468.html
which was one of the purported justifications for the patch above, has
apparently failed to make it for gcc 4.3.0 ; This means that using
emmintrin.h is no better than above:
int with_emm()
{
a = _mm_srli_epi64(b, 1);
a = _mm_srl_epi64(b, a);
}
sse-builtin-test.c: In function #8216;with_emm#8217;:
sse-builtin-test.c:23: note: use -flax-vector-conversions to permit conversions
between vectors with differing element types or numbers of subparts
sse-builtin-test.c:23: error: incompatible type for argument 1 of
#8216;_mm_srli_epi64#8217;
sse-builtin-test.c:23: error: incompatible types in assignment
sse-builtin-test.c:24: error: incompatible type for argument 1 of
#8216;_mm_srl_epi64#8217;
sse-builtin-test.c:24: error: incompatible type for argument 2 of
#8216;_mm_srl_epi64#8217;
sse-builtin-test.c:24: error: incompatible types in assignment
Next, I try with inline assembly.
static inline v2di my_psrlq(v2di x, v2di sh) __attribute__((always_inline));
static inline v2di my_psrlq(v2di x, v2di sh)
{
__asm__(psrlq %1,%0 : +x,x(x) : x,m(sh));
return x;
}
static inline v2di my_psrlqi(v2di x_, const unsigned int r_)
__attribute__((always_inline));
static inline v2di my_psrlqi(v2di x_, const unsigned int r_)
{
__asm__(psrlq %1,%0 : +x(x_) : J(r_));
return x_;
}
int with_extended_asm()
{
a = my_psrlqi(b, 23);
a = my_psrlq(b, a);
}
It works at first glance, but the my_psrlq() code above causes an ICE on
more involved code, as in the attachment below.
/tmp/l.c:33: internal compiler error: in reg_overlap_mentioned_p, at
rtlanal.c:1398
So my questions are:
- what is the status of __builtin_ia32_psrlq128 and friends ?
- should emmintrin.h be fixed ?
- what is now the recommended way of accessing the psrlq instruction reliably ?
Thanks,
E.
--
Summary: Is the sse2 psrlq insn accessible ?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Emmanuel dot Thome at inria dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36370
[Bug c/36370] Is the sse2 psrlq insn accessible ?
--- Comment #1 from Emmanuel dot Thome at inria dot fr 2008-05-29 13:20 --- Created an attachment (id=15700) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15700action=view) source file causing ICE on 4.3.0 tiramisu ~ $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=x86_64-redhat-linux Thread model: posix gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) tiramisu ~ $ uname -a Linux tiramisu.loria.fr 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36370
[Bug target/36370] Is the sse2 psrlq insn accessible ?
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-29 13:26 --- (I would like to stay away from -flax-vector-conversions, as the code above in reality does no ``vector conversions'' per se). Yes there is, the __builtin_ia32_psrlqi128 takes __m128 and not a vector type. Also really using any of these builtins directly here is wrong as you should be using the SSE intrinsics instead. _mm_srli_epi64 also take a __m128 and not a vector type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36370
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #2 from bonzini at gnu dot org 2008-05-29 13:31 --- looks like a loop with 5000 basic blocks... -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-29 13:31:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug middle-end/36369] [4.3/4.4 Regression] Type punning warning with may_alias attribute depends on unrelated class definition
--- Comment #1 from jakub at gcc dot gnu dot org 2008-05-29 13:38 --- Given that get_alias_set uses TYPE_MAIN_VARIANT on the type before c_common_get_alias_set gets a chance to return 0 for types with may_alias attribute, it is obvious why this depends on other code using the same base type. I wonder why doesn't handle_may_alias_attribute set TYPE_ALIAS_SET (type) = 0; right away, but still that wouldn't help. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug c++/36369] [4.3/4.4 Regression] Type punning warning with may_alias attribute depends on unrelated class definition
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-29 13:43 ---
I think this is really a C++ front-end rather than a bug in the middle-end.
The follow program shows that we get the wrong aliasing set with the C++
front-end but not the C front-end:
struct g{long a;};
struct g f(struct g *a) { return *a;}
struct A
{
void *a;
};
int f1(const struct A *x, long *y)
{
typedef long __attribute__ ((may_alias)) long_a;
*y = *(const long_a *) (x-a);
return 1;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |c++
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-05-29 13:43:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug c++/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-29 13:48 --- For my testcase with the C front-end: ;; *y = *(const long_a *) x-a (insn 7 6 8 t.cc:12 (set (reg:SI 61) (mem:SI (reg/v/f:SI 59 [ x ]) [0 S4 A32])) -1 (nil)) While with the C++ front-end: ;; *y = *(const long_a *) x-a (insn 7 6 8 t.cc:12 (set (reg:SI 61) (mem:SI (reg/v/f:SI 59 [ x ]) [3 S4 A32])) -1 (nil)) I think the issue here is really the canonical type is set for C++ front-end which is wrong for may_alias types. This is wrong code and not just a warning as shown by the rtl expansion. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Keywords||wrong-code Summary|[4.3/4.4 Regression] Type |[4.3/4.4 Regression] |punning warning with|may_alias broken with |may_alias attribute depends |previous uses of non |on unrelated class |attributed type in some |definition |cases http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #3 from zadeck at naturalbridge dot com 2008-05-29 13:49 --- Subject: Re: [4.3/4.4 Regression] Hang in df_analyze bonzini at gnu dot org wrote: --- Comment #2 from bonzini at gnu dot org 2008-05-29 13:31 --- looks like a loop with 5000 basic blocks... there was a patch that spark wanted to get in at the end of 4.3 that changes the order that we traverse blocks, but it had a problem. I think that we may want to get that patch correct and see if it improves this. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug c++/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #4 from jakub at gcc dot gnu dot org 2008-05-29 13:54 ---
Quick hack that fixes this:
--- gcc/alias.c.jj 2008-05-18 22:14:23.0 +0200
+++ gcc/alias.c 2008-05-29 15:47:30.0 +0200
@@ -605,6 +605,8 @@ get_alias_set (tree t)
/* Variant qualifiers don't affect the alias set, so get the main
variant. If this is a type with a known alias set, return it. */
+ if (TYPE_ALIAS_SET_KNOWN_P (t))
+return TYPE_ALIAS_SET (t);
t = TYPE_MAIN_VARIANT (t);
if (TYPE_ALIAS_SET_KNOWN_P (t))
return TYPE_ALIAS_SET (t);
--- gcc/c-common.c.jj 2008-05-29 10:20:11.0 +0200
+++ gcc/c-common.c 2008-05-29 15:46:29.0 +0200
@@ -568,6 +568,7 @@ static tree handle_vector_size_attribute
bool *);
static tree handle_nonnull_attribute (tree *, tree, tree, int, bool *);
static tree handle_nothrow_attribute (tree *, tree, tree, int, bool *);
+static tree handle_may_alias_attribute (tree *, tree, tree, int, bool *);
static tree handle_cleanup_attribute (tree *, tree, tree, int, bool *);
static tree handle_warn_unused_result_attribute (tree *, tree, tree, int,
bool *);
@@ -663,7 +664,8 @@ const struct attribute_spec c_common_att
handle_nonnull_attribute },
{ nothrow,0, 0, true, false, false,
handle_nothrow_attribute },
- { may_alias, 0, 0, false, true, false, NULL },
+ { may_alias, 0, 0, false, true, false,
+ handle_may_alias_attribute },
{ cleanup, 1, 1, true, false, false,
handle_cleanup_attribute },
{ warn_unused_result, 0, 0, false, true, true,
@@ -6396,6 +6398,18 @@ handle_nothrow_attribute (tree *node, tr
return NULL_TREE;
}
+/* Handle a may_alias attribute; arguments as in
+ struct attribute_spec.handler. */
+
+static tree
+handle_may_alias_attribute (tree *node, tree name, tree ARG_UNUSED (args),
+ int ARG_UNUSED (flags),
+ bool *ARG_UNUSED (no_add_attrs))
+{
+ TYPE_ALIAS_SET (*node) = 0;
+ return NULL_TREE;
+}
+
/* Handle a cleanup attribute; arguments as in
struct attribute_spec.handler. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-29 13:58 ---
I was wrong about being C++ specific as here is a testcase which fails with
both front-ends:
struct g{long a;};
unsigned long f(struct g *a) { return *(unsigned long *)a-a;}
struct A
{
void *a;
};
int f1(const struct A *x, long *y)
{
typedef long __attribute__ ((may_alias)) long_a;
*y = *(const long_a *) (x-a);
return 1;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #6 from jakub at gcc dot gnu dot org 2008-05-29 14:00 ---
Yeah, or:
void *a;
int
f0 (long *y)
{
*y = *(const long *) a;
return 1;
}
int
f1 (long *y)
{
typedef long __attribute__ ((may_alias)) long_a;
*y = *(const long_a *) a;
return 1;
}
int
f2 (long *y)
{
*y = *(const long *) a;
return 1;
}
which IMHO should warn in f0 and f2 and not in f1. Stock trunk warns in all 3
cases, with my hack surprisingly it warns only in f0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug c/36370] Is the sse2 psrlq insn accessible ?
--- Comment #3 from Emmanuel dot Thome at inria dot fr 2008-05-29 14:02 --- Yes there is, the __builtin_ia32_psrlqi128 takes __m128 and not a vector type. ok. I guess you mean __m128i, for that particular case. It very much seems that the texinfo documentation for this part of gcc is to be forgotten for good, then. Also really using any of these builtins directly here is wrong as you should be using the SSE intrinsics instead. _mm_srl_epi64 also take a __m128 and not a vector type. Sure -- this I gathered from previous PR in the same area. Which leaves pending the question of documenting ``right'' vs ``wrong'' ;-). I've ranted some rubbish above -- the psrlq builtins and friends are still completely there indeed, I just missed the fact that commit 123250 reverted commit 123215, which I expected at first to have broken things. Regards, E. -- Emmanuel dot Thome at inria dot fr changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36370
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #7 from jakub at gcc dot gnu dot org 2008-05-29 14:08 --- handle_may_alias_attribute is wrong though, as it modifies the alias set of long int. Either may_alias causes creation of build_distinct_type_copy, or we are in big trouble IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug c/36370] Is the sse2 psrlq insn accessible ?
--- Comment #4 from Emmanuel dot Thome at inria dot fr 2008-05-29 14:09 --- This leaves the ICE problem in attachment 15700. Is my assembly constraint bogus (in which case I'd prefer a nice diagnostic, as was the case in gcc 4.2.4, to an ICE) ? I tried three choices for the inline asm: __asm__(psrlq %1,%0 : +x,x(x) : x,m(sh)); -- ICE __asm__(psrlq %2,%0 : =x,x(x) : 0,0(x), x,m(sh)); -- ICE __asm__(psrlq %2,%0 : +x,x(x) : 0,0(x), x,m(sh)); -- ok But having + _and_ a back reference is superfluous, isn't it ? E. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36370
[Bug fortran/36371] New: [4.3/4.4 Regression] Wrong locus for errors in DATA statement
The first test case in PR36319 gives now: character(len=3, kind=4), parameter, dimension(3) :: mychar = [ abc, def 1 Error: Incompatible types in assignment at (1); attempted assignment of CHARACTER(4) to CHARACTER(1) which does not look right. The following codelet from FX: program chkdata character(len=3), parameter :: mychar(3) = [ abc, def, ghi ] integer :: c(5) data c / mychar(1), mychar(2), mychar(3), mychar(1), mychar(2) / end program chkdata gives with gfortran 4.3/4.4: character(len=3), parameter :: mychar(3) = [ abc, def, ghi ] 1 Error: Incompatible types in assignment at (1); attempted assignment of CHARACTER(1) to INTEGER(4) but with gfortran 4.2: data c / mychar(1), mychar(2), mychar(3), mychar(1), mychar(2) / 1 Error: Syntax error in DATA statement at (1) pointing to the right locus of the error. -- Summary: [4.3/4.4 Regression] Wrong locus for errors in DATA statement Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36371
[Bug c/36370] Is the sse2 psrlq insn accessible ?
--- Comment #5 from ubizjak at gmail dot com 2008-05-29 14:30 --- Please note that psrlq doesn't implement x[N] y[N] shift, but x[N] y shift. That is, all elements are shifted by the same value. Please see Intel instruction reference. Also, psrlq doesn't support memory operands. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36370
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-29 14:30 --- The correct fix is to build a pointer with TYPE_REF_CAN_ALIAS_ALL for pointers to types with the may_alias attribute. This is the only thing that will make sure it works properly. This can be done in build_pointer_type / build_reference_type but at the cost of a attribute lookup (I have a patch for this). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-05-29 13:43:25 |2008-05-29 14:30:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-05-29 14:41 --- Of course the cleaner design of may_alias would have put it on pointer types only, so we could have handled this in handle_may_alias_attribute ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug c/36370] Is the sse2 psrlq insn accessible ?
--- Comment #6 from Emmanuel dot Thome at inria dot fr 2008-05-29 14:49 --- (In reply to comment #5) Please note that psrlq doesn't implement x[N] y[N] shift, but x[N] y shift. That is, all elements are shifted by the same value. Please see Intel instruction reference. yeah, I know. Only the low word gives the shift count. Also, psrlq doesn't support memory operands. It does (for the shift count). Or my AMD doc is bogus. E. -- Emmanuel dot Thome at inria dot fr changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36370
[Bug c/36370] Is the sse2 psrlq insn accessible ?
--- Comment #7 from ubizjak at gmail dot com 2008-05-29 15:03 --- (In reply to comment #6) Also, psrlq doesn't support memory operands. It does (for the shift count). Or my AMD doc is bogus. Uh, indeed. I was looking into sse.md patterns. Unfortunatelly, it takes 128bit operand from memory, so we can't use it directly for SImode count operand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36370
[Bug c++/36372] New: printf format and templates doesn't work anymore
templateclass T void
myPrintf( const char * fmt, ... )
__attribute__ ((__format__ (__printf__, 1, 2)));
templateclass T void
myPrintf( const char * fmt, ... )
{
}
void func()
{
myPrintfint( test );
}
$ g++ t.cc
t.cc: In function 'void func()':
t.cc:6: error: '__printf__' was not declared in this scope
t.cc:6: error: unrecognized format specifier
Works with GCC 4.1.1
--
Summary: printf format and templates doesn't work anymore
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36372
[Bug tree-optimization/36373] New: [4.2/4.3/4.4 Regression] Wrong code with struct return
extern void abort (void);
struct Foo {
int *p;
int *q;
};
struct Foo __attribute__((noinline))
bar(int *p)
{
struct Foo f;
f.p = p;
return f;
}
void __attribute__((noinline))
foo(struct Foo f)
{
*f.p = 0;
}
int main()
{
int a, b;
a = 0;
b = 1;
struct Foo f;
f = bar (b);
f.q = a;
foo(f);
if (b != 0)
abort ();
return 0;
}
--
Summary: [4.2/4.3/4.4 Regression] Wrong code with struct return
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36373
[Bug c++/36372] printf format and templates doesn't work anymore
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-29 15:07 --- *** This bug has been marked as a duplicate of 35546 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36372
[Bug c++/35546] [4.3/4.4 Regression] __attribute__(format...) broken for members of template classes?
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-29 15:07 --- *** Bug 36372 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||joerg dot richter at pdv-fs ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35546
[Bug tree-optimization/36373] [4.2/4.3/4.4 Regression] Wrong code with struct return
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 15:07 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2008-05-29 15:07:30 date|| Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36373
[Bug tree-optimization/36373] [4.2/4.3/4.4 Regression] Wrong code with struct return
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-29 15:23 --- First we miss the constraint f = ANYTHING from f = bar (b); but then we also do not handle at all the case of escaping pointers through by-value passed structures foo (f); and thus we end up not clobbering b for that call. The first part is easy to fix. I have to think about the second one ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36373
[Bug tree-optimization/36373] [4.2/4.3/4.4 Regression] Wrong code with struct return
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-29 15:44 --- I have a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36373
[Bug fortran/36374] New: nested module inclusion fails
The attached code produces an error message, yet it is accepted by other compilers and is judged legal in http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/82aebb2460cba148# [EMAIL PROTECTED] bugtest]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr/local/gcc43 --with-mpfr=/u sr/local/mpfr --with-gmp=/usr/local/gmp Thread model: posix gcc version 4.3.0 (GCC) [EMAIL PROTECTED] bugtest]$ gfortran -c usemod2.f90 usemod2.f90:39.34: use foo_mod, protect = s_foobar 1 Error: Name 'foobar' at (1) is an ambiguous reference to 'foobar' from module 's _foo_mod' usemod2.f90:46.34: use foo_mod, protect = d_foobar 1 Error: Name 'foobar' at (1) is an ambiguous reference to 'foobar' from module 's _foo_mod' usemod2.f90:54.13: use foo_mod 1 Error: Name 'foobar' at (1) is an ambiguous reference to 'foobar' from module 's _foo_mod' usemod2.f90:57.16: call foobar(z) 1 Error: There is no specific subroutine for the generic 'foobar' at (1) -- Summary: nested module inclusion fails Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36374
[Bug fortran/36374] nested module inclusion fails
--- Comment #1 from sfilippone at uniroma2 dot it 2008-05-29 16:01 --- Created an attachment (id=15701) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15701action=view) test case Fails on gcc version 4.4.0 20080509 as well -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36374
[Bug middle-end/35771] Call expander ignores type alignment
--- Comment #11 from hjl dot tools at gmail dot com 2008-05-29 16:08 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35771
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #10 from jakub at gcc dot gnu dot org 2008-05-29 16:28 --- Well, if it is done frequently, perhaps we should spent a bit on it. Or, make sure types with may_alias attribute get TYPE_ALIAS_SET 0 and make TYPE_REF_CAN_ALIAS_ALL all pointers that point to alias set 0 types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug c++/35243] [4.3/4.4 regression] ICE with invalid initializer list in variadic template
--- Comment #4 from paolo at gcc dot gnu dot org 2008-05-29 16:45 --- Subject: Bug 35243 Author: paolo Date: Thu May 29 16:44:29 2008 New Revision: 136174 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136174 Log: /cp 2008-05-29 Paolo Carlini [EMAIL PROTECTED] PR c++/35243 * pt.c (tsubst_initializer_list): Consistently check the tree returned by tsubst_pack_expansion for error_mark_node. /testsuite 2008-05-29 Paolo Carlini [EMAIL PROTECTED] PR c++/35243 * g++.dg/cpp0x/vt-35243.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-35243.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35243
[Bug c++/35243] [4.3 regression] ICE with invalid initializer list in variadic template
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with |with invalid initializer|invalid initializer list in |list in variadic template |variadic template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35243
[Bug middle-end/19154] miss-optimization of (x pow2C) avr conditionals returning bool equivalent values
--- Comment #6 from a dot kaiser at gmx dot net 2008-05-29 17:01 --- In a similar case I've got the impression that the ifcombine pass might be responsible for rewriting the if into shift and mask. It is rather questionable whether this really optimizes things for simple targets which jump faster as they can shift. I am suprised however, that many optimization strategies can be disabled by some -fxxx option, but not this one. A first and probably simple approach could be, to just add such an option. -- a dot kaiser at gmx dot net changed: What|Removed |Added CC||a dot kaiser at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19154
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #7 from tdragon at tdragon dot net 2008-05-29 17:31 --- Created an attachment (id=15702) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15702action=view) Minimal testcase for vtable issue I'm not sure whether this is related, but the effect is similar so I'm adding it to this same bug. Basically, we get an undefined reference to the vtable for a dllimport-ed struct with a single inner-defined virtual function. Again, it's something that worked in mingw32 in previous GCC releases and fails in 4.3.0. Command line compilation and output: g++ -c impoverride2.cpp nm impoverride2.o b .bss d .data r .rdata$_ZTI3foo r .rdata$_ZTS3foo r .rdata$_ZTV3foo t .text t .text$_ZN3foo3barEv t .text$_ZN3fooC1Ev T __Z3depv T __ZN3foo3barEv T __ZN3fooC1Ev R __ZTI3foo R __ZTS3foo R __ZTV3foo U __ZTVN10__cxxabiv117__class_type_infoE U __imp___ZTV3foo Shouldn't be there! g++ -v Using built-in specs. Target: mingw32 Configured with: ../gcc-4.3.0/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-exceptions --program-suffix=-dw2 --with-pkgversion='GCC TDM-3/DW2 for MinGW' Thread model: win32 gcc version 4.3.0-dw2 (GCC TDM-3/DW2 for MinGW) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug target/36348] [4.4 Regression] f951 link failure on i686-apple-darwin9
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-05-29 18:22 --- Subject: Bug 36348 Author: dfranke Date: Thu May 29 18:21:35 2008 New Revision: 136178 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136178 Log: gcc: 2008-05-29 Daniel Franke [EMAIL PROTECTED] PR target/36348 * config/darwin-f.c: New. * config/t-darwin: Added rule to build darwin-f.o. * config.gcc: Defined new variable, fortran_target_objs. (*-*-darwin*): Set fortran_target_objs. * Makefile.in: Defined new variable FORTRAN_TARGET_OBJS. * configure.ac: Substitute fortran_target_objs, set FORTRAN_TARGET_OBJS. * configure: Regenerated. gcc/fortran: 2008-05-29 Daniel Franke [EMAIL PROTECTED] PR target/36348 * Make-lang.in (F95_OBJS): Added dependency on FORTRAN_TARGET_OBJS. Added: trunk/gcc/config/darwin-f.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/config.gcc trunk/gcc/config/t-darwin trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/Make-lang.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36348
[Bug fortran/36375] New: ICE on -fpreprocessed
$ cat a.F90 # 1 a.F90 # 1 built-in # 1 command-line # 1 a.F90 print *, foo bargee end $ gfortran-svn -fpreprocessed a.F90 built-in:1:1: error: invalid flag __STDC__ in line directive built-in:1:10: warning: extra tokens at end of ## directive a.F90:1: internal compiler error: Segmentation fault -- Summary: ICE on -fpreprocessed Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: dfranke at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36375
[Bug fortran/36376] New: -cpp -save-temps passes unknown options to f951
http://gcc.gnu.org/ml/fortran/2008-05/msg00354.html, issue 1: When I compile a .F90 file with -save-temps, I get: f951: warning: command line option -fpch-preprocess is valid for C/C++/ObjC/ObjC++ but not for Fortran -- Summary: -cpp -save-temps passes unknown options to f951 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: dfranke at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36376
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2008-05-29 18:37 --- Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above Can you reduce the testcase so I can try to analyze this with a cross? Here is a somewhat reduced testcase. The problem is with long long. Dave --- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2008-05-29 18:37 --- Created an attachment (id=15703) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15703action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug fortran/36377] New: newline missing at end of preprocessed output
http://gcc.gnu.org/ml/fortran/2008-05/msg00354.html, issue 2: When I compile a .F90 file with -E, no newline is appended at the end of the last line of output. -- Summary: newline missing at end of preprocessed output Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: dfranke at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36377
[Bug fortran/36378] New: Support Fortran files with \r line breaks
A college of mine recently struggled compiling some Fortran files and it turned out that they used (old) Mac line breaks, i.e. \r instead of Unix \n or Windows \r\n. (I have not checked how difficult it is to support this.) Analogously, one could think of supporting \r line breaks in libgfortran, but I think this will open Pandora's box. (Maybe the same is also true for the Front end.) -- Summary: Support Fortran files with \r line breaks Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36378
[Bug fortran/36379] New: preprocessing preprocessed output: invalid reads
http://gcc.gnu.org/ml/fortran/2008-05/msg00354.html, issue 3: If I compile the following a.F90 file: # 1 a.F90 # 1 built-in # 1 command-line # 1 a.F90 print *, foo bargee end with gfortran -E, I get garbage in the output: # 1 a.F90 # 1 built-in # 1 command-line # 1 a.F90 # 1 a.F90* # 1 built-in#2026;#9618;* # 1 command-line # 1 a.F90* print *, foo bargee end and valgrind says: ==28934== Invalid read of size 1 ==28934==at 0x4A1C713: strlen (mc_replace_strmem.c:246) ==28934==by 0x410D99: print_line (cpp.c:753) ==28934==by 0xB53574: do_linemarker (directives.c:993) ==28934==by 0xB51F98: _cpp_handle_directive (directives.c:483) ==28934==by 0xB624DE: _cpp_scan_out_logical_line (traditional.c:634) ==28934==by 0xB62BF6: _cpp_read_logical_line_trad (traditional.c:305) ==28934==by 0x41105F: gfc_cpp_preprocess (cpp.c:699) ==28934==by 0x46FB35: gfc_new_file (scanner.c:1916) ==28934==by 0x48720C: gfc_init (f95-lang.c:295) ==28934==by 0x704A88: toplev_main (toplev.c:2045) ==28934==by 0x4B3B4C9: (below main) (in /usr/lib/debug/libc-2.3.6.so) ==28934== Address 0x4E2C13D is 0 bytes after a block of size 5 alloc'd ==28934==at 0x4A1B95B: realloc (vg_replace_malloc.c:306) ==28934==by 0xB7713C: xrealloc (xmalloc.c:179) ==28934==by 0xB648DC: cpp_interpret_string (charset.c:1392) ==28934==by 0xB64E90: cpp_interpret_string_notranslate (charset.c:1416) ==28934==by 0xB5360A: do_linemarker (directives.c:956) ==28934==by 0xB51F98: _cpp_handle_directive (directives.c:483) ==28934==by 0xB624DE: _cpp_scan_out_logical_line (traditional.c:634) ==28934==by 0xB62BF6: _cpp_read_logical_line_trad (traditional.c:305) ==28934==by 0x41105F: gfc_cpp_preprocess (cpp.c:699) ==28934==by 0x46FB35: gfc_new_file (scanner.c:1916) ==28934==by 0x48720C: gfc_init (f95-lang.c:295) ==28934==by 0x704A88: toplev_main (toplev.c:2045) -- Summary: preprocessing preprocessed output: invalid reads Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: dfranke at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
[Bug fortran/18428] No preprocessing option -cpp for gfortran
--- Comment #10 from dfranke at gcc dot gnu dot org 2008-05-29 19:12 --- Implemented, but not yet fixed, in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18428
[Bug fortran/36380] New: preprocessing: define built-in target-related macros
gcc/fortran/cpp.c (cpp_define_builtins) should define target-related macros via usage of TARGET_*. Warning: The definition of TARGET_* macros needs to be checked for all targets as some assume to be used in gcc/c-cppbuiltin.c only. -- Summary: preprocessing: define built-in target-related macros Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: dfranke at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36380
[Bug target/36381] New: preprocessing, fortran: register include paths and framework
Follow up to PR36348: [darwin-f.c] need[s] to implement darwin_register_frameworks, as well as the -iframework option implemented by handle_c_option in darwin-c.c. I suggest splitting that part of darwin-c.c into a new file darwin-cpp.c that is included in all three of c_target_objs, cxx_target_objs, fortran_target_objs. Furthermore, given that the target hook TARGET_HANDLE_C_OPTION is implemented only by darwin-c.c, it makes sense to rename it to TARGET_HANDLE_CPP_OPTION and call it from the Fortran front-end too. Reference: http://gcc.gnu.org/ml/fortran/2008-05/msg00348.html -- Summary: preprocessing, fortran: register include paths and framework Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: dfranke at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org GCC target triplet: *-*-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36381
[Bug fortran/36361] attribute declaration outside of INTERFACE body
--- Comment #4 from janus at gcc dot gnu dot org 2008-05-29 20:06 ---
Here is a first attempt to fix this. The following patch should cope with the
original test case and the one in comment #1. The fix for the POINTER issues
will go into my procedure pointer patch. Any other attributes we need to
handle?
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 136137)
+++ gcc/fortran/symbol.c(working copy)
@@ -814,6 +814,14 @@ gfc_add_allocatable (symbol_attribute *a
return FAILURE;
}
+ if (attr-flavor == FL_PROCEDURE attr-if_source == IFSRC_IFBODY
+ gfc_find_state (COMP_INTERFACE) == FAILURE)
+{
+ gfc_error (Attribute ALLOCATABLE declared outside of INTERFACE
+body at %L, where);
+ return FAILURE;
+}
+
attr-allocatable = 1;
return check_conflict (attr, NULL, where);
}
@@ -832,6 +840,14 @@ gfc_add_dimension (symbol_attribute *att
return FAILURE;
}
+ if (attr-flavor == FL_PROCEDURE attr-if_source == IFSRC_IFBODY
+ gfc_find_state (COMP_INTERFACE) == FAILURE)
+{
+ gfc_error (Attribute DIMENSION of %s declared outside of INTERFACE
+body at %L, name, where);
+ return FAILURE;
+}
+
attr-dimension = 1;
return check_conflict (attr, name, where);
}
@@ -1453,6 +1469,13 @@ gfc_add_explicit_interface (gfc_symbol *
return FAILURE;
}
+ if (source == IFSRC_IFBODY (sym-attr.dimension ||
sym-attr.allocatable))
+{
+ gfc_error (Attribute declared outside of INTERFACE body for %s at %L,
+sym-name, where);
+ return FAILURE;
+}
+
sym-formal = formal;
sym-attr.if_source = source;
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 136137)
+++ gcc/fortran/parse.c (working copy)
@@ -1915,8 +1915,13 @@ loop:
case ST_SUBROUTINE:
new_state = COMP_SUBROUTINE;
- gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
- gfc_new_block-formal, NULL);
+ if (gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
+ gfc_new_block-formal, NULL) == FAILURE)
+ {
+ reject_statement ();
+ gfc_free_namespace (gfc_current_ns);
+ goto loop;
+ }
if (current_interface.type != INTERFACE_ABSTRACT
!gfc_new_block-attr.dummy
gfc_add_external (gfc_new_block-attr, gfc_current_locus) ==
FAILURE)
@@ -1929,8 +1934,13 @@ loop:
case ST_FUNCTION:
new_state = COMP_FUNCTION;
- gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
- gfc_new_block-formal, NULL);
+ if (gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
+ gfc_new_block-formal, NULL) == FAILURE)
+ {
+ reject_statement ();
+ gfc_free_namespace (gfc_current_ns);
+ goto loop;
+ }
if (current_interface.type != INTERFACE_ABSTRACT
!gfc_new_block-attr.dummy
gfc_add_external (gfc_new_block-attr, gfc_current_locus) ==
FAILURE)
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-05-28 22:23:43 |2008-05-29 20:06:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36361
[Bug fortran/36361] attribute declaration outside of INTERFACE body
--- Comment #5 from burnus at gcc dot gnu dot org 2008-05-29 20:58 --- Any other attributes we need to handle? I think that's all. I looked through the list of attributes and most are not possible for procedures or are already rejected. Thus I think we have all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36361
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-05-29 21:00 --- (In reply to comment #7) Created an attachment (id=15702) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15702action=view) [edit] Minimal testcase for vtable issue I'm not sure whether this is related, but the effect is similar so I'm adding it to this same bug. Basically, we get an undefined reference to the vtable for a dllimport-ed struct with a single inner-defined virtual function. Uhh, if you declare a struct as dllimport, then you are declaring that it's vtable is defined in a dll. So why is this a bug? Of course if you allow compiler to actually inline the virtual function in your example, the vtable should not be needed. Anyway, thanks for reminding me of this bug. I'll backport 4.4 patch to 4.3.2 once branch reopens. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug fortran/36379] preprocessing preprocessed output: invalid reads
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-29 21:00 --- Duplicate of PR 36276 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
[Bug fortran/36374] nested module inclusion fails
--- Comment #2 from burnus at gcc dot gnu dot org 2008-05-29 21:02 --- Paul, do you have an idea? You are our module/interface specialist. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||rejects-valid Known to fail||4.1.3 4.2.2 4.3.0 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-05-29 21:02:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36374
[Bug fortran/36371] [4.3/4.4 Regression] Wrong locus for errors in DATA statement
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2008-05-29 21:05:37 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36371
[Bug fortran/36382] New: Support $ as first character in symbol names and in IMPLICT
Found at: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3228dcee5e3d57c7 Some compilers (such as ifort) allow symbols which start with a $ sign - and they allow IMPLICT with $. gfortran currently does not recognize these. Solution: a) Support it as ifort does b) Document the non-support in the -fdollar-ok documentation. -- Summary: Support $ as first character in symbol names and in IMPLICT Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36382
[Bug fortran/36383] New: -std=95: Reject public procedure with private derv. type argument
See: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/12ac1683f64da0b8 ! type t_a is public; type t_b is private interface operator(+) module procedure add_t_a, add_t_b end interface contains pure function add_t_a(a1,a2) result(a) type(t_a) :: a type(t_a), intent(in) :: a1, a2 pure function add_t_b(b1,b2) result(b) type(t_b) :: b type(t_b), intent(in) :: b1, b2 Using NAG the output is: Extension: Dummy B1 of ADD_T_B in generic + exposes PRIVATE type T_B (Extension == Fortran 2003.) -- Summary: -std=95: Reject public procedure with private derv. type argument Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36383
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #9 from tdragon at tdragon dot net 2008-05-29 22:13 --- (In reply to comment #8) Uhh, if you declare a struct as dllimport, then you are declaring that it's vtable is defined in a dll. So why is this a bug? Well, it's a change from mingw32/3.4.5's behavior. At any rate, after thinking about it I agree that it isn't a bug. Thanks, John E. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug fortran/36379] preprocessing preprocessed output: invalid reads
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-29 22:18 --- (In reply to comment #1) Duplicate of PR 36276 ? Doesn't have the same location, so I don't think so :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
[Bug middle-end/29269] missing documentation for vcond (vector conditional operation)
--- Comment #2 from hp at gcc dot gnu dot org 2008-05-30 00:59 --- Ditto vconduMODE. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
[Bug fortran/36378] Support Fortran files with \r line breaks
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-30 04:21 --- This could be solved by judicious use of a good source code editor. Also, we could have the scanner insert a '/n' if a '/r' is found and peeking ahead does not find a '/n', assuming we are not between quotes in a literal string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36378
