[Bug fortran/30625] Array pointers to components of derived type arrays do not work
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-29 07:50 --- (In reply to comment #2) > Wasn't there a bug for byte-sized strides in array descriptors? This bug > should depend on it, and PR29606 as well. > Both of you are right about PR29606. The byte-sized strides I do not remember. It is one way to go but I do not think that it is the correct one. I think that we need a new field in the descriptor or, maybe, a new species of descriptor. This field could serve two functions: (i) If present for an intrinsic type, it carries the base stride in bytes; and (ii) If present for a derived type it carries the size in bytes. The present size subfield should be used to carry a unique code for the type, so that classes can be implemented, including abstract classes. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
[Bug fortran/30404] Wrong FORALL result
--- Comment #6 from sayle at gcc dot gnu dot org 2007-01-29 03:27 --- Subject: Bug 30404 Author: sayle Date: Mon Jan 29 03:27:07 2007 New Revision: 121279 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121279 Log: PR fortran/30404 * trans-stmt.c (forall_info): Remove pmask field. (gfc_trans_forall_loop): Remove NVAR argument, instead assume that NVAR covers all the interation variables in the current forall_info. Add an extra OUTER parameter, which specified the loop header in which to place mask index initializations. (gfc_trans_nested_forall_loop): Remove NEST_FLAG argument. Change the semantics of MASK_FLAG to only control the mask in the innermost loop. (compute_overall_iter_number): Optimize the trivial case of a top-level loop having a constant number of iterations. Update call to gfc_trans_nested_forall_loop. Calculate the number of times the inner loop will be executed, not to size of the iteration space. (allocate_temp_for_forall_nest_1): Reuse SIZE as BYTESIZE when sizeof(type) == 1. Tidy up. (gfc_trans_assign_need_temp): Remove NEST_FLAG argument from calls to gfc_trans_nested_forall_loop. (gfc_trans_pointer_assign_need_temp): Likewise. (gfc_trans_forall_1): Remove unused BYTESIZE, TMPVAR, SIZEVAR and LENVAR local variables. Split mask allocation into a separate hunk/pass from mask population. Use allocate_temp_for_forall_nest to allocate the FORALL mask with the correct size. Update calls to gfc_trans_nested_forall_loop. (gfc_evaluate_where_mask): Update call to gfc_trans_nested_forall_loop. (gfc_trans_where_2): Likewise. * gfortran.dg/forall_6.f90: New test case. * gfortran.dg/dependency_8.f90: Update test to find "temp" array. * gfortran.dg/dependency_13.f90: Likewise. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/forall_6.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-stmt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/dependency_13.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/dependency_8.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30404
[Bug c++/30602] [4.3 regression] Error with canonical types
--- Comment #2 from bangerth at dealii dot org 2007-01-29 01:15 --- In fact, after minor code changes, I can no longer reproduce the exact sources that triggered this. I'll close it for the moment, and try again if the problem should re-appear at one point... W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30602
[Bug c++/28236] wrong "control reaches" warning with enums.
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-29 01:10 --- Pawel, I don't want to appear rude but as you see from the answers in the ML, control might reach the end of the function without an explicit return. Thus, the warning is valid and I think we should close this as INVALID. Don't you agree? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
[Bug tree-optimization/30559] [4.3 Regression] compiler loops forever with flag -O3
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-29 00:51 --- Sample backtrace: #0 topo_visit (graph=0x9d55760, ti=0x9d55750, n=80) at /src/gcc/regressions1/gcc/gcc/bitmap.h:388 #1 0x083a4312 in topo_visit (graph=0x9d55760, ti=0x9d55750, n=79) at /src/gcc/regressions1/gcc/gcc/tree-ssa-structalias.c:1294 #2 0x083a4312 in topo_visit (graph=0x9d55760, ti=0x9d55750, n=4) at /src/gcc/regressions1/gcc/gcc/tree-ssa-structalias.c:1294 #3 0x083a56fe in solve_graph (graph=0x9d55760) at /src/gcc/regressions1/gcc/gcc/tree-ssa-structalias.c:1620 #4 0x083aaa70 in compute_points_to_sets (ai=0x9d14fe8) at /src/gcc/regressions1/gcc/gcc/tree-ssa-structalias.c:4758 #5 0x08332a6e in compute_may_aliases () at /src/gcc/regressions1/gcc/gcc/tree-ssa-alias.c:897 - #0 topo_visit (graph=0x9d55760, ti=0x9d55750, n=688) at /src/gcc/regressions1/gcc/gcc/bitmap.h:426 #1 0x083a4312 in topo_visit (graph=0x9d55760, ti=0x9d55750, n=684) at /src/gcc/regressions1/gcc/gcc/tree-ssa-structalias.c:1294 #2 0x083a4312 in topo_visit (graph=0x9d55760, ti=0x9d55750, n=665) at /src/gcc/regressions1/gcc/gcc/tree-ssa-structalias.c:1294 #3 0x083a4312 in topo_visit (graph=0x9d55760, ti=0x9d55750, n=661) at /src/gcc/regressions1/gcc/gcc/tree-ssa-structalias.c:1294 #4 0x083a56fe in solve_graph (graph=0x9d55760) at /src/gcc/regressions1/gcc/gcc/tree-ssa-structalias.c:1620 #5 0x083aaa70 in compute_points_to_sets (ai=0x9d14fe8) at /src/gcc/regressions1/gcc/gcc/tree-ssa-structalias.c:4758 #6 0x08332a6e in compute_may_aliases () at /src/gcc/regressions1/gcc/gcc/tree-ssa-alias.c:897 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |tree-optimization Keywords||alias, compile-time-hog Summary|compiler loops forever with |[4.3 Regression] compiler |flag -O3|loops forever with flag -O3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
[Bug c++/30602] [4.3 regression] Error with canonical types
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-29 00:33 --- Does adding "--param ggc-min-expand=0 --param ggc-min-heapsize=0" help you be able to reproduce it with -save-temps? If it does please attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30602
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|natVMURLConnection.cc:21: |[4.3 Regression] |error: 'magic_t' does not |natVMURLConnection.cc:21: |name a type |error: 'magic_t' does not |t name a type |name a type ||t name a type Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug fortran/30625] Array pointers to components of derived type arrays do not work
--- Comment #2 from tobi at gcc dot gnu dot org 2007-01-29 00:16 --- Wasn't there a bug for byte-sized strides in array descriptors? This bug should depend on it, and PR29606 as well. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-29 00:12 ---
A possible work around is to create another temp variable of type struct test.
Such that the function test looks like:
struct test
test (void)
{
struct test result;
struct test temp;
result.type = 0;
for (int i = 0; i < 2; ++i)
{
struct test candidate = reset ();
if (flag)
result = candidate;
}
temp = result;
return temp;
}
---
The bug is because NVR is applied twice, once in the front-end and once in
tree-nvr. If the front-end already applied NVR, we should not apply it again
in tree-nvr.
Looking into fixing this bug later tonight.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug c++/30615] c++: Internal error: Killed: 9 (program cc1plus)
--- Comment #2 from kevin at penguinnetwerx dot net 2007-01-29 00:05 --- (In reply to comment #1) > How much memory do you have? This internal error is caused by the kernel > killing the process because it ran over the memory limits. > That would be the case. The box has 128MB of RAM. I've tried compiling a few other apps and had the same thing happen. This item can be closed. Thanks, Kevin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30615
[Bug target/30192] [arm] Wrong sp value on exit after calling __floatdidf or __floatundidf
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-01-29 00:00 --- Richard, this patch is OK for 4.1, 4.2 branches once applied to mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
[Bug bootstrap/29509] gcj MetalLookAndFeel.java causes gcj to SIGILL on PPC Linux
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-28 23:35 --- make[7]: *** [compile-classes] Illegal instruction At this point I am going to consider this a problem in the hardware you are using as one, this works for me with the trunk and also the 4.1 branch on good known hardware. So closing as works for me. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29509
[Bug other/29488] Cannot Make GCC 4.1.1
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-28 23:33 --- Ubuntu uses a broken library layout so closing as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29488
[Bug target/28185] SIGBUS on IA64 maybe caused by memcpy I
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-28 23:31 --- No feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28185
[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-28 22:57 --- (In reply to comment #11) > SRA messes up somehow and it only happens with inlined functions so I am going > to look more into it. I have a fix for the SRA issue now, SRA tries to look into 3rd/4th operand to decide if the array is a non constant stride but in_array_bounds_p already checks that so there is no need to check the 3rd/4th operand again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug tree-optimization/17272] Extra store emitted when concatenating inline assembly sections.
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-28 22:55 --- We get: main: leal4(%esp), %ecx andl$-16, %esp movl$118, %edx movl%edx, %eax pushl -4(%ecx) #APP addb %dl, %al #NO_APP pushl %ebp #APP subb %dl, %al #NO_APP movl%esp, %ebp pushl %ecx movsbl %al,%eax popl%ecx leave leal-4(%ecx), %esp ret On the mainline so I am going to call this as fixed, 4.2.0 still had the movb and the move from LC0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17272
[Bug fortran/30512] MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1 maximum values.
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-01-28 22:39 --- Should we commit the combined fix? I do think this is a bug. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
[Bug tree-optimization/27798] gimplifying "return CONSTANT" creates unneeded temporaties
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-01-28 22:17 --- Well, it fails in interesting ways if I remember correctly and no, I'm not looking into this at the moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27798
[Bug fortran/29396] segfault with character pointer association
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-28 22:15 --- In the spirit of Paul's suggestion. I will try this one. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-08 21:46:03 |2007-01-28 22:15:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
[Bug tree-optimization/27798] gimplifying "return CONSTANT" creates unneeded temporaties
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2007-01-28
22:04 ---
(In reply to comment #2)
> i.e. it misses to initialize the temporary with the result. Otherwise you
> can play with variants of the following patch:
Richard, have you tried to make this patch work? It seems that with all the
work that goes into inlining now, this might help a bit by making some function
bodies smaller and and allowing the inliner to better estimate the actual
size...
>
> Index: gimplify.c
> ===
> *** gimplify.c (revision 114599)
> --- gimplify.c (working copy)
> *** gimplify_return_expr (tree stmt, tree *p
> *** ,1116
> --- ,1124
> if (!result_decl
> || aggregate_value_p (result_decl, TREE_TYPE (current_function_decl)))
> result = result_decl;
> + else if (/*is_gimple_formal_tmp_reg (TREE_OPERAND (ret_expr, 1))
> +||*/ is_gimple_min_invariant (TREE_OPERAND (ret_expr, 1))
> + /*is_gimple_val (TREE_OPERAND (ret_expr, 1))*/)
> + {
> + TREE_OPERAND (stmt, 0) = TREE_OPERAND (ret_expr, 1);
> +
> + return GS_ALL_DONE;
> + }
> else if (gimplify_ctxp->return_temp)
> result = gimplify_ctxp->return_temp;
> else
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27798
[Bug fortran/30625] Array pointers to components of derived type arrays do not work
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-28 20:33 --- Confirmed. Is this related to PR 29606? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-28 20:33:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
[Bug libstdc++/30586] [4.2/4.3 regression] Namespace pollution in c++ headers
--- Comment #9 from pcarlini at suse dot de 2007-01-28 20:23 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug middle-end/22456] [4.1/4.2/4.3 regression] missing "is used uninitialized" warning
--- Comment #8 from muntyan at tamu dot edu 2007-01-28 20:15 --- Is the code here or in comment #2 the same as in 30542 and 30575? It may be, but gcc users who don't know gcc internals (like me), can't easily see this, and missing warning (in those two bugs, not here) is quite a serious regression, which means one can expect more warnings to disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug fortran/30625] New: Array pointers to components of derived type arrays do not work
This: type :: a real :: r = 3.14159 integer :: i = 42 end type a type(a), target :: dt(2) integer, pointer :: ip(:) ip => dt%i print *, ip end produces $ ./a 107853 42 with gfortran, whereas the correct result should be two 42s Paul -- Summary: Array pointers to components of derived type arrays do not work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
[Bug libstdc++/30586] [4.2/4.3 regression] Namespace pollution in c++ headers
--- Comment #8 from paolo at gcc dot gnu dot org 2007-01-28 20:12 --- Subject: Bug 30586 Author: paolo Date: Sun Jan 28 20:12:40 2007 New Revision: 121271 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121271 Log: 2007-01-27 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/30586 * config/cpu/ia64/atomic_word.h: Just include . * configure.host (atomic_word_dir): Cover alpha, ia64 and powerpc. Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/config/cpu/ia64/atomic_word.h branches/gcc-4_1-branch/libstdc++-v3/configure.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #18 from pcarlini at suse dot de 2007-01-28 20:10 --- (In reply to comment #16) > I am also interested in how many (negative constant)->unsigned conversions you > have found, because I would like to keep those in Wconversion as they have > always been. None. If you are positive that we had that specific warning already, then ok with me with simply returning to the "traditional" behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #17 from pcarlini at suse dot de 2007-01-28 20:05 --- (In reply to comment #16) > I think that we agreed that people using -Wconversion do want warnings for > larger->smaller conversions. When you mention same size types, do you mean > conversions between signed and unsigned types? Curious how words can appear ambiguous... ;) In my understanding, the size has nothing to do by itself with signedness. And from the previous discussions seemed obvious (to me) that, as regards integer types, people want warnings only when the size of source and target are different (smaller for target). Floating points are not at issue, also rather obvious to me, should remain untouched in -Wconversion. Confirmed that so far I haven't found any larger signed -> small unsigned conversion, personally, I would probably explicitely cast anyway, in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #3 from rwgk at yahoo dot com 2007-01-28 20:03 --- I've repeated my test with g++ (GCC) 4.2.0 20070128 (prerelease) SVN revision: 121258 on three platforms: x86_64 Fedora Core release 5 (Bordeaux) % g++ -fPIC -O3 dbg_gcc_bugzilla_30567.cpp % ./a.out 1 i686 Fedora Core release 4 (Stentz) % g++ -fPIC -O3 dbg_gcc_bugzilla_30567.cpp % ./a.out 0 Fedora Core release 6 (Zod) % g++ -fPIC -O3 dbg_gcc_bugzilla_30567.cpp % ./a.out 0 I.e. 64-bit is still OK, 32-bit is still broken. Could someone please try to reproduce with the current version of the 4.2 branch? I'm worried that 4.2 is released with this bug, and that we have to deal with it for years to come... BTW: the system gcc versions are: x86_64 Fedora Core release 5 (Bordeaux) g++ (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3) i686 Fedora Core release 4 (Stentz) g++ (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) i686 Fedora Core release 6 (Zod) g++ (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30624] ignores explicit qualification
--- Comment #2 from igodard at pacbell dot net 2007-01-28 20:03 --- I thought (according to the ARM) that all functions of a template class were implicitly function templates. Ordinarily the correct instantiation is determined by the object, but when both are inherited then it needs qualification. No? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30624
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #16 from manu at gcc dot gnu dot org 2007-01-28 19:47 ---
(In reply to comment #15)
> FYI: I'm right now auditing the code for conversions larger -> smaller integer
> type and immediately adjusting it in the process. Only very few so far. To be
> clear, I'm punting on conversions between same size types which, apparently,
> people don't believe should be flagged as part of -Wconversion, maybe not at
> all.
I think that we agreed that people using -Wconversion do want warnings for
larger->smaller conversions. When you mention same size types, do you mean
conversions between signed and unsigned types? or am I missing something here?
(we also warn for conversions between integer and floating-point types, no
matter what size they are).
Nevertheless, I am interested in how many (large signed) -> (small unsigned)
you have found, since it is not clear to me whether those should be warned by
-Wconversion or should be considered a signedness conversion. For example:
void f (char *p1, char *p2)
{
unsigned short us = p1 - p2;
}
Gabriel, what do you think about this case?
I am also interested in how many (negative constant)->unsigned conversions you
have found, because I would like to keep those in Wconversion as they have
always been.
Thanks.
Manuel.
PS: Also, currently Wconversion in C++ is not complete: there are some (many?)
situations that we want to warn but we don't do it yet. In particular, any
conversion that uses convert_like_real (which I think that is used quite often)
and implicit conversions of the operands of binary operations. I am waiting for
this patch http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00799.html
to be reviewed. So, I am afraid that you may get more warnings once that patch
gets committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug c++/30624] ignores explicit qualification
--- Comment #1 from pluto at agmk dot net 2007-01-28 19:41 ---
(In reply to comment #0)
> template struct foo { T*bar(); };
> struct foo1 : public foo, public foo { };
> int main() { foo1 f; f.bar(); }
this is an invalid code.
1). f.bar isn't a function template, so f.bar is wrong.
2). f.bar() is ambiguous and compiler reports correct error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30624
[Bug c++/30624] New: ignores explicit qualification
template struct foo { T*bar(); };
struct foo1 : public foo, public foo { };
int main() { foo1 f; f.bar(); }
gets you:
~/foo$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:3: error: request for member 'bar' is ambiguous
foo.cc:1: error: candidates are: T* foo::bar() [with T = bool*]
foo.cc:1: error: T* foo::bar() [with T = int]
foo.cc:3: error: expected primary-expression before 'int'
foo.cc:3: error: expected `;' before 'int'
--
Summary: ignores explicit qualification
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30624
[Bug middle-end/22456] [4.1/4.2/4.3 regression] missing "is used uninitialized" warning
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-28 19:29 --- *** Bug 30575 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||muntyan at tamu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug middle-end/30575] Missing warning about unitialized variable
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-28 19:29 --- *** This bug has been marked as a duplicate of 22456 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30575
[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-28 19:26 --- I can reproduce this ICE but it is very hard to see where the problem is with such a long testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug target/30429] internal compiler error: in emit_move_insn, at expr.c:2809
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-28 19:20 --- Fixed so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30429
[Bug java/30585] [4.3 Regression] gcj doesn't accept -Wall and -Werror anymore
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|gcj doesn't accept -Wall and|[4.3 Regression] gcj doesn't |-Werror anymore |accept -Wall and -Werror ||anymore Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30585
[Bug c++/30583] [ODR] Non-static inline functions cause bugs when defined more than once in different files
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-28 19:15 --- This is just an ODR (one definition rule) violation which does not need to be diagnostic. In fact it might be hard to diagnostic this problem. C++ defines inline functions as weak/varge linkage so the definition of the uses across every TU (translation unit) have to be the same but no diagnostic is required if they are different. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|c |c++ Summary|Non-static inline functions |[ODR] Non-static inline |cause bugs when defined more|functions cause bugs when |than once in different files|defined more than once in ||different files http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30583
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #15 from pcarlini at suse dot de 2007-01-28 19:10 --- FYI: I'm right now auditing the code for conversions larger -> smaller integer type and immediately adjusting it in the process. Only very few so far. To be clear, I'm punting on conversions between same size types which, apparently, people don't believe should be flagged as part of -Wconversion, maybe not at all. -- pcarlini at suse dot de changed: What|Removed |Added CC||gdr at integrable-solutions ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-28 19:10 --- (In reply to comment #10) > The patch is able to pass bootstrap but I still have another regression I need > to look into, dealing with an inline-asm and the testcase is x86 specific one > at that. (it does #ifdef __i386__). SRA messes up somehow and it only happens with inlined functions so I am going to look more into it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|x86_64-suse-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn
--- Comment #8 from pinskia at gmail dot com 2007-01-28 19:04 --- Subject: Re: newlib targets ICEs in expand_builtin_int_roundingfn On Wed, 2007-01-24 at 14:22 +, rguenth at gcc dot gnu dot org wrote: > > --- Comment #7 from rguenth at gcc dot gnu dot org 2007-01-24 14:22 > --- > I'm no longer working on this, but this is a general problem we have with > builtin functions used internally. There's currently no way to prevent > direct usage. And I think the ICE is a regression at that, I just don't have time to prove it. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29719
[Bug c++/30623] New: Ignores "using"
template struct foo1 { T* next; };
struct foo2 : public foo1 {};
struct foo3 : public foo1, public foo2 {using foo1::next;};
int main() { foo3 f; f.next = 0; }
gets you:
~$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:5: error: request for member 'next' is ambiguous
foo.cc:1: error: candidates are: foo2* foo1::next
foo.cc:1: error: foo3* foo1::next
--
Summary: Ignores "using"
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30623
[Bug c++/28988] [4.0/4.1/4.2/4.3 Regression] g++ does not check first type name in pseudo-destructor-name
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-01-28 18:19 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28988
[Bug c++/28988] [4.0/4.1/4.2/4.3 Regression] g++ does not check first type name in pseudo-destructor-name
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-28 18:19 --- Subject: Bug 28988 Author: pinskia Date: Sun Jan 28 18:18:54 2007 New Revision: 121263 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121263 Log: 2007-01-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28988 * semantics.c (finish_pseudo_destructor_expr): Check the destrutor name by calling check_dtor_name. 2007-01-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28988 * g++.dg/expr/dtor4.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/expr/dtor4.C - copied unchanged from r121261, trunk/gcc/testsuite/g++.dg/expr/dtor4.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/semantics.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog --- Comment #9 from pinskia at gcc dot gnu dot org 2007-01-28 18:19 --- Subject: Bug 28988 Author: pinskia Date: Sun Jan 28 18:18:52 2007 New Revision: 121262 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121262 Log: 2007-01-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28988 * semantics.c (finish_pseudo_destructor_expr): Check the destrutor name by calling check_dtor_name. 2007-01-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28988 * g++.dg/expr/dtor4.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/expr/dtor4.C - copied unchanged from r121261, trunk/gcc/testsuite/g++.dg/expr/dtor4.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/semantics.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28988
[Bug c++/28988] [4.0/4.1/4.2/4.3 Regression] g++ does not check first type name in pseudo-destructor-name
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-28 18:19 --- Subject: Bug 28988 Author: pinskia Date: Sun Jan 28 18:18:54 2007 New Revision: 121263 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121263 Log: 2007-01-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28988 * semantics.c (finish_pseudo_destructor_expr): Check the destrutor name by calling check_dtor_name. 2007-01-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28988 * g++.dg/expr/dtor4.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/expr/dtor4.C - copied unchanged from r121261, trunk/gcc/testsuite/g++.dg/expr/dtor4.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/semantics.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28988
[Bug c++/28988] [4.0/4.1/4.2/4.3 Regression] g++ does not check first type name in pseudo-destructor-name
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-28 18:09 --- Subject: Bug 28988 Author: pinskia Date: Sun Jan 28 18:09:25 2007 New Revision: 121261 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121261 Log: 2007-01-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28988 * semantics.c (finish_pseudo_destructor_expr): Check the destrutor name by calling check_dtor_name. 2007-01-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28988 * g++.dg/expr/dtor4.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/dtor4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28988
[Bug c/30622] char *p; p = "str"; puts "str" into rodata
--- Comment #5 from vda dot linux at googlemail dot com 2007-01-28 17:40 --- http://david.tribble.com/text/cdiffs.htm#C99-string-const "In C, string literals have type char[n], but are not modifiable (i.e., attempting to modify the contents of a string literal is undefined behavior)." In light of this, char msg[] = "wow" starts to look "strange". Oh well. If the definition above is really what C99 says (I am not an C99 expert), maybe a warning would be in order for such code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30622
[Bug c/30622] char *p; p = "str"; puts "str" into rodata
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-28 17:31 --- (In reply to comment #3) > Sorry! Bug in the testcase, should be "char *p". > I remember that string literals are special - they decay to "const char *" OR > to "char*" depending on context. In this context, it should decay to "char*", > and it does - gcc doesn't complain "assingment of const to non-const", the bug > is that gcc placed "str" in ro section. They are still considered constant even though the type decays to char*. The reason why the type of a string literal decays to char* is because before C90/C89, const did not exist so the C standards committee wantted to support older code. Anyways if you want a warning use -Wwrite-strings. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30622
[Bug c/30622] char *p; p = "str"; puts "str" into rodata
--- Comment #3 from vda dot linux at googlemail dot com 2007-01-28 17:25
---
Sorry! Bug in the testcase, should be "char *p".
I remember that string literals are special - they decay to "const char *" OR
to "char*" depending on context. In this context, it should decay to "char*",
and it does - gcc doesn't complain "assingment of const to non-const", the bug
is that gcc placed "str" in ro section.
char *p;
int main() {
p = "str";
return 0;
}
/*
.file "t.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "str"
.text
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
movl$.LC0, p
xorl%eax, %eax
leave
ret
.size main, .-main
.comm p,4,4
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
*/
--
vda dot linux at googlemail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30622
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-28 17:23 ---
I will submit two patches. The first one will remove the function. Then, I have
to regtest the second one: perhaps we find another unused function!
Steven, if you really think that the case:
static void foo(void)
{
bar ();
}
static void bar(void)
{
foo ();
}
is worth the hassle of dealing with the call graph (which may not be available
unless using a particular -O* switch), please open a new PR about it (and add
me to the CC list).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug middle-end/26061] error and warning count
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-28 17:17 --- I have a patch bootstrapped and regression tested that implements my version but I am sure it will require minimal changes to implement whatever is decided. So if you don't get an answer here, please raise the issue at gcc@gcc.gnu.org and let's see what others think. If you convince someone who can approve the patch, I will implement it and submit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug c/30622] char *p; p = "str"; puts "str" into rodata
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-28 17:13 --- More to the point, at one time in the past, GCC had an option to turn (constant) string literals into readwrite strings, that was removed in 4.0.0 (maybe even in 3.4.0). Also the standard says they are constant string literals and not just strings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30622
[Bug target/30486] segfault in aggregate_value_p while bootstrapping fortran
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30486
[Bug rtl-optimization/30121] ICE on frtl-abstract-sequences
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30121
[Bug c/30622] char *p; p = "str"; puts "str" into rodata
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-28 16:10 --- String literals are not writable. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30622
[Bug c/30622] New: char *p; p = "str"; puts "str" into rodata
char p;
int main() {
p = "str";
return 0;
}
If anyone will try to assign something to p[0] and if rodata is write
protected,
we'll segfault. Assembly:
.file "t.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "str"
.text
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
movl$.LC0, %eax
movb%al, p
xorl%eax, %eax
leave
ret
.size main, .-main
.comm p,1,1
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
--
Summary: char *p; p = "str"; puts "str" into rodata
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30622
[Bug target/30486] segfault in aggregate_value_p while bootstrapping fortran
-- aldot at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30486
[Bug c/30621] Wrong error message aborts compiling of a simple formula
--- Comment #1 from capiman at clibb dot de 2007-01-28 14:08 --- Created an attachment (id=12974) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12974&action=view) File to reproduce the error I just used gcc s3.c inside cygwin environment and this produces the error. Leaving out the "+1" (which makes the formula smaller) and it compiles fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30621
[Bug bootstrap/30469] [4.3 Regression] profiledbootstrap no longer works
--- Comment #4 from drow at gcc dot gnu dot org 2007-01-28 14:08 --- Fixed. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30469
[Bug bootstrap/30469] [4.3 Regression] profiledbootstrap no longer works
--- Comment #3 from drow at gcc dot gnu dot org 2007-01-28 14:08 --- Subject: Bug 30469 Author: drow Date: Sun Jan 28 14:08:13 2007 New Revision: 121257 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121257 Log: PR bootstrap/30469 * Makefile.in (CFLAGS): Forcibly remove -fprofile-generate and -fprofile-use. Modified: trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30469
[Bug c/30621] New: Wrong error message aborts compiling of a simple formula
I have a simple C file (almost hello world), with a very big formula inside. If the formula gets too big, i get the following error message, which seems to be wrong: $ gcc s3.c /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab): undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status Removing only a "+1" from the formula, then it compiles without a problem. -- Summary: Wrong error message aborts compiling of a simple formula Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: capiman at clibb dot de GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30621
[Bug fortran/30554] ICE in mio_pointer_ref at module.c:1945
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-28 13:40 --- It looks like it is mine. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-23 13:30:32 |2007-01-28 13:40:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
[Bug fortran/30554] ICE in mio_pointer_ref at module.c:1945
--- Comment #4 from patchapp at dberlin dot org 2007-01-28 12:30 --- Subject: Bug number PR30554 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02282.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
[Bug bootstrap/30620] missing prerequisite of gcov-io.h breaks --enable-intermodule build
--- Comment #1 from aldot at gcc dot gnu dot org 2007-01-28 11:45 --- I assume that this works with 4.1 but did not verify. If so, that's obviously a [4.2 Regression] -- aldot at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30620
[Bug bootstrap/30620] New: missing prerequisite of gcov-io.h breaks --enable-intermodule build
pristine 4_2-branch configured with: ++ CFLAGS='-g3 -ggdb3 -O0' ++ CXXFLAGS='-g3 -ggdb3 -O0' ++ BOOT_CFLAGS=' -march=pentium4 -mtune=pentium4 -O2' ++ ../../src/gcc-4.2.orig/configure -v --enable-languages=c,c++,fortran,treelang --prefix=/opt/gcc-4.2.orig/ --enable-shared --with-system-zlib --libexecdir=/op t/gcc-4.2.orig/lib --enable-nls --without-included-gettext --enable-threads=posi x --program-suffix=-4.2.orig-HEAD --enable-__cxa_atexit --enable-libstdcxx-alloc ator=mt --enable-clocale=gnu --disable-libstdcxx-debug --enable-mpfr --disable-w error --enable-checking=release --enable-debug --enable-intermodule i686-linux-g nu ../../../src/gcc-4.2.orig/gcc/tree-ssa-structalias.c ../../../src/gcc-4.2.orig/gcc/tree-object-size.c ../../../src/gcc-4.2.orig/gcc/rtl-factoring.c ../../../src/gcc-4.2.orig/gcc/config/i386/i386.c -o libbackend.o \ -DBASEVER="\"4.2.0\"" -DDATESTAMP="\" 20070128\"" \ -DDEVPHASE="\" (prerelease)\"" -combine In file included from ../../../src/gcc-4.2.orig/gcc/coverage.h:25, from ../../../src/gcc-4.2.orig/gcc/coverage.c:42: ../../../src/gcc-4.2.orig/gcc/gcov-io.h:284:22: error: gcov-iov.h: No such file or directory -- Summary: missing prerequisite of gcov-io.h breaks --enable- intermodule build Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30620
[Bug tree-optimization/27659] ICE on autovect-branch
--- Comment #3 from irar at il dot ibm dot com 2007-01-28 11:38 --- I tried to reproduce this on x86 with current autovect branch and mainline with .../g++ -fpreprocessed tmp.ii -S -O3 -ftree-vectorize -msse2 -ansi -fdump-tree-vect-details. It doesn't not ICE, and the loop is vectorized. Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27659
[Bug rtl-optimization/30121] ICE on frtl-abstract-sequences
-- aldot at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE on frtl-abstract- |ICE on frtl-abstract- |sequences and mthumb. |sequences Target Milestone|--- |4.2.0 Version|unknown |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30121
[Bug tree-optimization/26362] ICE on the autovect-branch (gfortran example)
--- Comment #3 from irar at il dot ibm dot com 2007-01-28 10:45 --- The current versions of both mainline and autovect branch do not ICE. Strided loads are not implemented for SSE. I opened a PR 30211 for it. I think this PR can be closed. Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26362
[Bug fortran/30389] ACHAR() intrinsic gives erroneous errors in constant-folding.
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-01-28 10:45 --- Subject: Bug 30389 Author: tkoenig Date: Sun Jan 28 10:44:47 2007 New Revision: 121255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121255 Log: 2007-01-28 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.h: Remove gfc_simplify_init_1. * arith.h: Remove third argument from gfc_compare_string. * arith.c(gfc_compare_expression): Remove third argument from call to gfc_compare_string. (gfc_compare_string): Remove third argument xcoll_table. Remove use of xcoll_table. * misc.c(gfc_init_1): Remove call to gfc_simplify_init_1. * simplify.c(ascii_table): Remove. (xascii_table): Likewise. (gfc_simplify_achar): ICE if extract_int fails. Remove use of ascii_table. Warn if -Wsurprising and value < 0 or > 127. (gfc_simplify_char): ICE if extract_int fails. Error if value < 0 or value > 255. (gfc_simplify_iachar): Remove use of xascii_table. Char values outside of 0..255 are an ICE. (gfc_simplify_lge): Remove use of xascii_table. (gfc_simplify_lgt): Likewise. (gfc_simplify_lle): Likewise. (gfc_simplify_llt): Likewise. (invert_table): Remove. (gfc_simplify_init_1): Remove. 2007-01-28 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.dg/achar_2.f90: New test. * gfortran.dg/achar_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/achar_2.f90 trunk/gcc/testsuite/gfortran.dg/achar_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/arith.h trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/misc.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30389
[Bug fortran/30554] ICE in mio_pointer_ref at module.c:1945
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-28 08:03 ---
Tobias,
> The error occurs when the symbol "hessian" is written.
> The error is gone if one removes the ": only ENERGY_CONSTRAINT" or the "use
> atoms" from the POTENTIAL_ENERGY module (if you have {atom,constraint}.mod
> files, the two use statements in POTENTIAL_ENERGY are enough to cause the
> ICE.)
The segfault also goes if you interchange the order of the two USE statements.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
