[Bug bootstrap/36324] Bootstrap comparison failure with BOOT_CFLAGS=-pg (trunk r135848)
--- Comment #1 from oliver dot kellogg at eads dot com 2008-05-25 09:39 --- Must have been some leftovers in my build dir. Works after complete rebuild from scratch. Sorry for the noise -- oliver dot kellogg at eads dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36324
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #3 from oliver dot kellogg at eads dot com 2008-05-25 10:38 --- Does not happen with -gnatc (syntax and semantics check only.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-25 12:03 --- Does enabling optimization (-O) fix the problem? My guess is that the gimplification of the aggregate assignments creates lots of overhead, but that needs to be investigated by Ada people - stats with a compiler configured with --enable-gather-detailed-mem-stats would also be useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers
--- Comment #9 from jv244 at cam dot ac dot uk 2008-05-25 12:13 --- > It's not complete yet, and some details need to be fixed, but the basic > functionality is there. I hope it can be committed to trunk quite soon. that would be great... I really hope this will be enough to enable the -D__LIBINT bits of CP2K. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580
hashim anna jeffery
mora celeste kristina meltin calvin kongjoo cimarron dong hplab jill arun hashim
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-25 13:48 --- Well, this assignment seems to be _very_ expensive both in terms of parsing time and size of the IL to expand. It certainly looks unreasonable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug fortran/36325] New: specific or generic INTERFACE implies the EXTERNAL attribute
I think the following code is invalid: interface subroutine foo end subroutine end interface external foo Because the INTERFACE statement already specifies the EXTERNAL attribute, which is thus specified twice. This code *is* actually rejected (as of rev. 135859), but the error message is completely wrong: external :: foo 1 Error: EXTERNAL attribute conflicts with SUBROUTINE attribute at (1) (which it does *not* for this case) Quoting the Fortran 2003 standard (section 5.1.2.6): "The EXTERNAL attribute speciï¬es that an entity is an external procedure, dummy procedure, procedure pointer, or block data subprogram. This attribute may also be speciï¬ed by an EXTERNAL statement (12.3.2.2), a procedure-declaration-stmt (12.3.2.3) or an interface body that is not in an abstract interface block (12.3.2.1)." And further on in section 12.3.2.1: "An interface body in a generic or speciï¬c interface block speciï¬es the EXTERNAL attribute and an explicit speciï¬c interface for an external procedure or a dummy procedure. If the name of the declared procedure is that of a dummy argument in the subprogram containing the interface body, the procedure is a dummy procedure; otherwise, it is an external procedure." -- Summary: specific or generic INTERFACE implies the EXTERNAL attribute Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaydub66 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #5 from oliver dot kellogg at eads dot com 2008-05-25 13:31 --- Created an attachment (id=15679) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15679&action=view) statistics output from gnat1 on pkg001u.adb without aggregate assignments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #6 from oliver dot kellogg at eads dot com 2008-05-25 13:38 --- Created an attachment (id=15680) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15680&action=view) statistics output from gnat1 on pkg001u.adb with one assignment Here, I enabled the assignment in line 377, Tramessage.O000X := (Pkg000W.E08EY, Aktergsatz); and invoked gnat1 directly as follows: /opt/gccsnap/libexec/gcc/i686-pc-linux-gnu/4.4.0/gnat1 -gnat95 -mtune=generic \ pkg001u.adb (Notice the increase in 'expand'. Is that within expected limits?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #1 from jaydub66 at gmail dot com 2008-05-25 14:02 ---
Here is a first patch:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 135859)
+++ gcc/fortran/symbol.c(working copy)
@@ -439,7 +439,7 @@ check_conflict (symbol_attribute *attr,
conf (external, intrinsic);
conf (entry, intrinsic);
- if ((attr->if_source && !attr->procedure) || attr->contained)
+ if ((attr->if_source == IFSRC_DECL && !attr->procedure) || attr->contained)
{
conf (external, subroutine);
conf (external, function);
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 135859)
+++ gcc/fortran/parse.c (working copy)
@@ -1917,12 +1917,26 @@ loop:
new_state = COMP_SUBROUTINE;
gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
gfc_new_block->formal, NULL);
+ if (current_interface.type != INTERFACE_ABSTRACT &&
+gfc_add_external (&gfc_new_block->attr, &gfc_current_locus) ==
FAILURE)
+ {
+ reject_statement ();
+ gfc_free_namespace (gfc_current_ns);
+ goto loop;
+ }
break;
case ST_FUNCTION:
new_state = COMP_FUNCTION;
gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
gfc_new_block->formal, NULL);
+ if (current_interface.type != INTERFACE_ABSTRACT &&
+gfc_add_external (&gfc_new_block->attr, &gfc_current_locus) ==
FAILURE)
+ {
+ reject_statement ();
+ gfc_free_namespace (gfc_current_ns);
+ goto loop;
+ }
break;
case ST_PROCEDURE:
This removes the conflict between EXTERNAL and SUBROUTINE for this case, and
adds the EXTERNAL attribute for a non-abstract INTERFACE statement.
Checking for regressions ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #2 from jaydub66 at gmail dot com 2008-05-25 14:45 --- Ok, this produces an impressive list of regressions. Many of those (e.g. actual_procedure_1.f90) seem to be related to conf (external, dimension); /* See Fortran 95's R504. */ I'm not sure if the constraint from R504 is implemented correctly here, or if it constrains too much. Others testcases (like argument_checking_3.f90) fail because they define lots of specific interfaces, but no external implementation for those. So I guess they are actually invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-25 15:36 --- > Ok, this produces an impressive list of regressions. > Many of those (e.g. actual_procedure_1.f90) seem to be related to > conf (external, dimension); /* See Fortran 95's R504. */ > I'm not sure if the constraint from R504 is implemented correctly here, or if > it constrains too much. As written, I believe that R504 entity-decl is object-name [( array-spec )] [ * char-length ] [initialization ] or function-name [ * char-length ] only restricts the use of: REAL, EXTERNAL :: func(10) <- array-spec, invalid for function names but not (a) REAL, EXTERNAL, DIMENSION(10) :: func nor (b) the dimension of function results. Despite my failure to find anything in the standard which rejects (a) all my compilers reject it whereas all my compilers allow (b). See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bb371413b5cbe3d7 > Others testcases (like argument_checking_3.f90) fail because they define lots > of specific interfaces, but no external implementation for those. > So I guess they are actually invalid? As I did not apply your patch, I fail to understand this problem. Ignoring the problems with the rank mismatches and too few arguments, the program is valid from the Fortran side. External means that the user somehow needs to provide the foo,bar,foobar procedures, but that is outside of the scope of the Fortran standard (except that also Fortran procedures can be external procedures). In case of gfortran the linker would complain - but it should never reach that point because of the compile-time errors. By the way: The the rank mismatch dg-error and not dg-warning should be used in argument_checking_3.f90. (However, dejagnu does not distingish.) -- 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-25 15:36:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #8 from oliver dot kellogg at eads dot com 2008-05-25 15:42 --- (in reply to comment #4) > Does enabling optimization (-O) fix the problem? No, does not change the behavior (other than taking even longer) > [...] stats with a compiler configured with > --enable-gather-detailed-mem-stats would also be useful. Coming up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug middle-end/36326] New: gimplification of aggregate copies introduces extra aggregate copy
union X { int i; double x; };
int foo (union X *p)
{
union X x = *p;
return x.x;
}
produces
union X x.0;
x.0 = *p;
x = x.0;
this is not optimized at any point. Using a struct instead usually SRA
is able to remove the extra copy.
--
Summary: gimplification of aggregate copies introduces extra
aggregate copy
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
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=36326
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #4 from janus at gcc dot gnu dot org 2008-05-25 16:37 --- (In reply to comment #2) > Others testcases (like argument_checking_3.f90) fail because they define lots > of specific interfaces, but no external implementation for those. Obviously I got this wrong. The actual reason for these tests failing is that with my patch all the interfaces acquire the EXTERNAL attribute (which they didn't have before), and apparently there is no argument checking done for external procedures. Which leads me to think we should probably implement this (for the case that the interface is explicit). Or is there any good reason that this is not done? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug middle-end/36326] gimplification of aggregate copies introduces extra aggregate copy
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-25 16:47 --- Caused by the fix for PR17526. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||17526 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36326
Very simple bug, setting pointer to a value in an if statement.
OK, this bug was brought on by a mistake I made while writing a
removenode function for a linked list class that I'm making in C++.
It's easy to trigger and, while a program written correctly won't ever
experience a defect from it, it does cause problems while debugging.
I'm using gcc 4.3.0.
Here's the code that triggers the bug:
node *current = FirstNode;
node *previous = current;
if ( current = 0 )
return 0;
else
{
cout << FirstNode << ":" << current << ":" << previous << "\n";
... snip ...
You'll notice the mistake I made in the if statement where I didn't use
'==' and accidentally use '='. For some reason the function kept
returning 0 and I added the output to check the locations of the
different nodes. I noticed that while FirstNode and previous were set
to the same location, current was at 0, and since previous had been set
to current's location, somehow current was getting set to 0. I looked
at the if statement and I noticed my mistake but was puzzled as to why
the compiler didn't return any error messages. I presume that it's a
bug, however there may be some special property of pointers that I'm not
aware of, I'm really not sure, my experience with C++ is limited.
The command I used to compile this was very simple.
g++ lltest.cpp -o lltest
If there's anymore information you need, please tell me, or if this
isn't really a bug I'd appreciate knowing that as well.
Thank you,
Ted
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #5 from burnus at gcc dot gnu dot org 2008-05-25 17:11 --- > Which leads me to think we should probably implement this (for the case that > the interface is explicit). Or is there any good reason that this is not done? Well, regarding the reason: Before interfaces had no EXTERNAL attribute and those procedures with EXTERNAL attribute had no explicit interface. That interfaces have the EXTERNAL attribute only needed for procedure pointers. One could think of not giving the EXTERNAL attribute to procedures declared in interface bodies and modifying POINTER / the pointer resolution only. I'm not sure what is cleaner and simpler. Regarding our questions, Richard Maine (mostly) answered them. See URL in comment #3. conf2(external,dimension) is in any case wrong. It should be: conflict(external with implicit interface, dimension) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug middle-end/17526] [4.0 Regression] libcpp is miscompiled with -fno-pcc-struct-return -O2
--- Comment #35 from rguenth at gcc dot gnu dot org 2008-05-25 17:17 --- Subject: Bug 17526 Author: rguenth Date: Sun May 25 17:16:38 2008 New Revision: 135876 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135876 Log: 2008-05-25 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/17526 * gcc.dg/torture/pr17526.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr17526.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17526
[Bug middle-end/36326] gimplification of aggregate copies introduces extra aggregate copy
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-25 17:18 --- Which was just a workaround. It needs proper fixing so that Index: tree-gimple.c === --- tree-gimple.c (revision 135859) +++ tree-gimple.c (working copy) @@ -116,10 +116,7 @@ is_gimple_mem_rhs (tree t) a renamed variable. Also force a temporary if the type doesn't need to be stored in memory, since it's cheap and prevents erroneous tailcalls (PR 17526). */ - if (is_gimple_reg_type (TREE_TYPE (t)) - || (TYPE_MODE (TREE_TYPE (t)) != BLKmode - && (TREE_CODE (t) != CALL_EXPR - || ! aggregate_value_p (t, t + if (is_gimple_reg_type (TREE_TYPE (t))) return is_gimple_val (t); else return is_gimple_formal_tmp_rhs (t); doesn't regress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36326
[Bug tree-optimization/36327] New: SCCVN should look through struct copies
struct X { int i; int j; };
void bar (struct X *);
int foo (struct X *p)
{
struct X x;
p->i = 1;
x = *p;
x.j = 2;
return p->i - x.i;
}
this should be optimized to return zero. -fno-tree-sra required to show
the missed optimization.
--
Summary: SCCVN should look through struct copies
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
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=36327
[Bug tree-optimization/36327] SCCVN should look through struct copies
-- 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-25 17:20:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36327
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #26 from ghazi at gcc dot gnu dot org 2008-05-25 17:29 --- I also get this failure on x86 when using ilp32 && pic. See: x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Last reconfirmed|2008-03-03 13:51:21 |2008-05-25 17:29:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug rtl-optimization/36240] PIC and -frtl-abstract-sequences
--- Comment #1 from ghazi at gcc dot gnu dot org 2008-05-25 17:31 --- I also get this failure on x86 when using ilp32 && pic. See: x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-25 17:31:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36240
[Bug fortran/32600] [ISO Bind C] C_F_POINTER w/o SHAPE should not be a library function
--- Comment #14 from burnus at gcc dot gnu dot org 2008-05-25 17:52 --- Subject: Bug 32600 Author: burnus Date: Sun May 25 17:52:03 2008 New Revision: 135877 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135877 Log: 2008-05-25 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32600 * trans-expr.c (gfc_conv_function_call): Remove library call for c_f_pointer with scalar Fortran pointers and for c_f_procpointer. 2008-05-25 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32600 * intrinsics/iso_c_binding.c (c_f_procpointer): Remove. * intrinsics/iso_c_binding.h (c_f_procpointer): Remove. * gfortran.map (c_f_procpointer): Remove. 2008-05-25 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32600 * gfortran.dg/c_f_pointer_tests_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/iso_c_binding.c trunk/libgfortran/intrinsics/iso_c_binding.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600
[Bug fortran/32600] [ISO Bind C] C_F_POINTER w/o SHAPE should not be a library function
--- Comment #15 from burnus at gcc dot gnu dot org 2008-05-25 17:55 --- FIXED on the trunk (4.4). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600
[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-05-25 18:03 --- The testcase also fails for me on x86_64-unknown-linux-gnu or i686-unknown-linux-gnu but requires -fpic/-fPIC to trigger. (That may explain the darwin x86 error.) See: x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729
[Bug tree-optimization/36245] [4.4 Regression] internal compiler error: in build2_stat, at tree.c:3116
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-05-25 18:08 --- I see the failure with x86_64 -m32 or native i686 on the trunk: x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Last reconfirmed|2008-05-15 12:31:28 |2008-05-25 18:08:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36245
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #9 from oliver dot kellogg at eads dot com 2008-05-25 18:12 --- Created an attachment (id=15681) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15681&action=view) gnat1 (trunk r135848) output from -fmem-report, no aggregate assignments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-05-25 18:13 --- Failure also occurs on x86_64-unknown-linux-gnu and i686-unknown-linux-gnu, see: x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Last reconfirmed|2008-05-05 21:30:39 |2008-05-25 18:13:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36143
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #10 from oliver dot kellogg at eads dot com 2008-05-25 18:17 --- Created an attachment (id=15682) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15682&action=view) same as above but with assignments in pkg001u.adb lines 296 and 377 enabled -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #11 from oliver dot kellogg at eads dot com 2008-05-25 18:43 --- Created an attachment (id=15683) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15683&action=view) att15682 was incorrect, two assignments already exhaust the memory. memreport for _one_ assignmt. -- oliver dot kellogg at eads dot com changed: What|Removed |Added Attachment #15682|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-05-25 18:56 --- ada/utils2.c:1774 (build_simple_component_ref)111547200:71.1% clearly a frontend issue. -- rguenth 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-25 18:56:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #6 from janus at gcc dot gnu dot org 2008-05-25 19:08 --- Created an attachment (id=15684) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15684&action=view) patch Ok, I extended the patch, and got the regression count down from a few million to exactly two: FAIL: gfortran.dg/proc_decl_9.f90 FAIL: gfortran.dg/gomp/reduction3.f90 What I did was e.g. following Tobi's suggestion about the dimension problem: > conf2(external,dimension) > is in any case wrong. It should be: > conflict(external with implicit interface, dimension) Also I made sure not to interfere with dummy procedures, turned on argument checking for (explicit-interfaced) external procedures and fixed an error message for a test case. I haven't looked at the two remaining regressions in detail, but both seem to be related to intrinsics. And I'm sure I can convince those two little fuckers to disappear soon. Patch is attached. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug c++/36254] wrong "control reaches end of non-void function" warning
--- Comment #5 from pluto at agmk dot net 2008-05-25 19:20 ---
(In reply to comment #4)
> This would fix it.
4.3.1-20080525 with this patch seems to work fine.
>
> Index: tree-eh.c
> ===
> --- tree-eh.c (revision 135433)
> +++ tree-eh.c (working copy)
> @@ -1350,9 +1350,6 @@ decide_copy_try_finally (int ndests, tre
> {
>int f_estimate, sw_estimate;
>
> - if (!optimize)
> -return false;
> -
>/* Finally estimate N times, plus N gotos. */
>f_estimate = estimate_num_insns (finally, &eni_size_weights);
>f_estimate = (f_estimate + 1) * ndests;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36254
[Bug preprocessor/36328] New: system headers not found if exec_prefix != prefix
gcc 4.3.0 was configured with an explicit exec-prefix (different from prefix):
$ ../configure --target=powerpc-rtems --prefix=/opt/rtems-head//host
--exec-prefix=/opt/rtems-head//host/i386_linux26/gcc-4.3.0
--mandir=/opt/rtems-head//doc/man --infodir=/opt/rtems-head//doc/info
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --verbose
--with-system-zlib --disable-nls --enable-version-specific-runtime-libs
--enable-threads=rtems
The cross-compiler was installed (along with newlib) but then failed to locate
newlib headers.
Setting of 'gcc_tooldir' has changed in 4.3.0 and this patch fixes
the issue for me:
NOTE: need to run 'autoconf' after applying patch.
*** gcc-4.3.0/gcc/configure.ac.orig 2008-03-10 11:56:05.899271819 -0800
--- gcc-4.3.0/gcc/configure.ac 2008-03-10 11:57:20.442080560 -0800
***
*** 3689,3695
fi
echo "source ${srcdir}/gdbinit.in" >> .gdbinit
! gcc_tooldir='$(libsubdir)/$(libsubdir_to_prefix)$(target_noncanonical)'
AC_SUBST(gcc_tooldir)
AC_SUBST(dollar)
--- 3689,3695
fi
echo "source ${srcdir}/gdbinit.in" >> .gdbinit
!
gcc_tooldir='$(libsubdir)/$(libsubdir_to_prefix)$(prefix_to_exec_prefix)$(target_noncanonical)'
AC_SUBST(gcc_tooldir)
AC_SUBST(dollar)
--
Summary: system headers not found if exec_prefix != prefix
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: strauman at slac dot stanford dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-rtems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36328
[Bug tree-optimization/36329] New: latent problem with tree inlining
Something doesn't work as expected with tree inlining. This is visible by adding the missing check to the CALL_CANNOT_INLINE_P flag: #define CALL_CANNOT_INLINE_P(NODE) (CALL_EXPR_CHECK (NODE)->base.static_flag) You get gazillions of failures in the C testsuite coming from cgraphbuild.c and ipa-inline.c: the 'call_stmt' it is applied to can be GIMPLE_MODIFY_STMT. Jan, any idea as to what is going on here? -- Summary: latent problem with tree inlining Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization 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=36329
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #7 from burnus at gcc dot gnu dot org 2008-05-25 19:58 --- > Patch is attached. You need also to reject the following, which violates R504. interface real function bar() end function bar end interface dimension :: bar(4) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug tree-optimization/36329] latent problem with tree inlining
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-25 19:59 --- The call edge's statement will either be an assignment (whos rhs is a call expression) or a call expression (if the call's return value is ignored). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36329
[Bug tree-optimization/36329] latent problem with tree inlining
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-25 20:00 --- The checks in ipa-inline.c should all look like CALL_CANNOT_INLINE_P (get_call_expr_in (...)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36329
[Bug fortran/36313] [F2003] {MIN,MAX}{LOC,VAL} should accept character arguments
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-05-25 20:03 --- This should be fun :-) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-25 20:03:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36313
[Bug fortran/36305] real and imaginary part of complex exponential
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-05-25 20:08 --- This works for me down to 4.1.3: $ gfortran-4.1 -static foo.f $ ./a.out $ head -4 fort.10 0.99950656E+00 0.31410759E-01 0.99950656E+00 0.31410759E-01 0.99802673E+00 0.62790520E-01 0.99802673E+00 0.62790520E-01 0.99556196E+00 0.94108313E-01 0.99556196E+00 0.94108313E-01 0.99211470E+00 0.12533323E+00 0.99211470E+00 0.12533323E+00 $ gfortran-4.1 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.3 20080114 (prerelease) (Debian 4.1.2-19) This must have been fixed a long time ago. I'd like to echo Steve's advice: You should upgrade to 4.3.0 at least, or wait another week for the 4.3.1 release. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work|4.2.3 4.4.0 |4.2.3 4.4.0 4.1.2 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36305
[Bug debug/35896] [4.4 Regression] gfortran TLS symbols broken with debug info
--- Comment #7 from jakub at gcc dot gnu dot org 2008-05-25 20:24 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35896
[Bug fortran/36323] Inside an interface, gfortran does not know about selected_real_kind
--- Comment #2 from burnus at gcc dot gnu dot org 2008-05-25 21:28 --- Close as invalid. If you think this is an error, please reopen. If you have further questions, send those to the gfortran mailing list. Thanks for sending a bugreport after finding a bug. (Even though it turned out this time to be no bug but a feature of the Fortran standard.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36323
[Bug fortran/36316] type mismatch in binary expression caught by verify_gimple
--- Comment #5 from burnus at gcc dot gnu dot org 2008-05-25 22:00 --- Somewhere a fold_convert (TREE_TYPE (to_tree), from_tree) is missing, but I fail to see where. I think one could add a couple of those in trans-array.c; I think there is more than one missing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36316
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #8 from janus at gcc dot gnu dot org 2008-05-25 22:33 --- The failure of proc_decl_9.f90 was actually due to a bug that slipped in with my procedure declaration update patch from May 1st, which I have fixed now. So we're left with gomp/reduction3.f90, which contains this piece of code: interface function ior (a, b) integer :: ior, a, b end function end interface intrinsic ior This produces: intrinsic ior 1 Error: EXTERNAL attribute conflicts with INTRINSIC attribute at (1) I haven't checked the standard on this, but I bet the code is illegal. And after all: Why should one declare an explicit interface for an intrinsic (whose interface is known anyway) ...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/18428] No preprocessing option -cpp for gfortran
--- Comment #9 from dfranke at gcc dot gnu dot org 2008-05-25 22:38 --- Subject: Bug 18428 Author: dfranke Date: Sun May 25 22:37:41 2008 New Revision: 135882 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135882 Log: gcc: 2008-05-26 Daniel Franke <[EMAIL PROTECTED]> PR fortran/18428 * c.opt: Removed undocumented option '-lang-fortran'. * c-common.h: Removed global variable 'lang_fortran'. * c-opts.c (c_common_handle_option): Removed code to handle option '-lang-fortran'. Updated includes. * c-cppbuiltin.c (c_cpp_builtins): Removed conditional definition of '__GFORTRAN__'. (define__GNUC__): Reimplemented to use BASEVER and cpp_define_formatted. (builtin_define_with_value_n): Removed. * c-incpath.h: Renamed to ... * incpath.h: ... this. * c-incpath.c: Renamed to ... * incpath.c: ... this. Updated includes. * fix-header.c: Updated includes. * Makefile.in: Replaced c-incpath.[ch] by incpath.[ch]. (c-cppbuiltin.o): Added dependency on and definition of BASEVER. (OBJ-archive): Added cppdefault.o, incpath.o and prefix.o. gcc/cp: 2008-05-26 Daniel Franke <[EMAIL PROTECTED]> * Makefile.in: Adjusted dependencies on c-incpath.o. gcc/fortran: 2008-05-26 Daniel Franke <[EMAIL PROTECTED]> PR fortran/18428 * lang.opt (A, C, CC, D, E, H, P, U, cpp, d, fworking-directory, imultilib, iprefix, iquote, isysroot, isystem, nocpp, nostdinc, o, undef, v): New options. * options.c (gfc_init_options): Also initialize preprocessor options. (gfc_post_options): Also handle post-initialization of preprocessor options. (gfc_handle_option): Check if option is a preprocessor option. If yes, let gfc_cpp_handle_option() handle the option. * lang-specs.h: Reorganized to handle new options. * scanner.c (gfc_new_file): Read temporary file instead of input source if preprocessing is enabled. * f95-lang.c (gfc_init): Initialize preprocessor. (gfc_finish): Clean up preprocessor. * cpp.c: New. * cpp.h: New. * Make-lang.in: Added new objects and dependencies. * gfortran.texi: Updated section "Preprocessing and conditional compilation". * invoke.texi: Added new section "Preprocessing Options", listed and documented the preprocessing options handled by gfortran. Added: trunk/gcc/fortran/cpp.c trunk/gcc/fortran/cpp.h trunk/gcc/incpath.c - copied, changed from r135880, trunk/gcc/c-incpath.c trunk/gcc/incpath.h - copied unchanged from r135880, trunk/gcc/c-incpath.h Removed: trunk/gcc/c-incpath.c trunk/gcc/c-incpath.h Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/c-common.h trunk/gcc/c-cppbuiltin.c trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in trunk/gcc/fix-header.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/Make-lang.in trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang-specs.h trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18428
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-16 10:22:05 |2008-05-25 22:55:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug c++/36330] New: i386-pc-solaris2.10 configure: error: C compiler cannot create executables
i386-pc-solaris2.10 configure: error: C compiler cannot create executables. gcc-4.3.1-RC-20080523.tar.bz2 binutils 2.18 Solaris 10 x86_64 U4 I can build gcc 4.2.3. But I can't build gcc 4.2.4 and 4.3.1. pwd: /export/home/test/gcc-4.3.1-build/build/i386-pc-solaris2.10 configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for --enable-generated-files-in-srcdir... no checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for a BSD-compatible install... /export/home/test/gcc-4.3.1-build/src/install-sh -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for i386-pc-solaris2.10-gcc... /export/home/test/gcc-4.3.1-build/build/./gcc/xgcc -B/export/home/test/gcc-4.3.1-build/build/./gcc/ -B/opt/gcc-4.3.1/i386-pc-solaris2.10/bin/ -B/opt/gcc-4.3.1/i386-pc-solaris2.10/lib/ -isystem /opt/gcc-4.3.1/i386-pc-solaris2.10/include -isystem /opt/gcc-4.3.1/i386-pc-solaris2.10/sys-include -m64 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [configure-target-libgomp] Error 1 make[1]: Leaving directory `/export/home/test/gcc-4.3.1-build/build' make: *** [all] Error 2 -- Summary: i386-pc-solaris2.10 configure: error: C compiler cannot create executables Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cnstar9988 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36330
[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables
--- Comment #1 from cnstar9988 at gmail dot com 2008-05-26 00:43 --- gmp 4.2.2, mpfr 2.3.1 Both gmp and mpfr build with "--disable-shared ABI=32" gcc 4.3.1 configure: ../src/configure --prefix=/opt/gcc-4.3.1 --with-gmp=/opt/gcc-4.3.1/gmp --with-mpfr=/opt/gcc-4.3.1/mpfr --with-as=/usr/local/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --disable-shared -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36330
[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-26 00:50 --- -m64 Use --disable-multilib. -- 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=36330
[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables
--- Comment #3 from cnstar9988 at gmail dot com 2008-05-26 00:54 --- I want both build my programs -m32 -m64 My OS is solaris 10 x86_64. I can run well with gcc 4.2.3. If I build gcc 4.3.1 with --disable-multilib, I can only compile with apps with -m32? -- cnstar9988 at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36330
[Bug bootstrap/36331] New: [4.4 Regression]: Gcc failed to bootstrap
On Linux/ia32, Linux/Intel64 and Linux/ia64, when configured with --enable-clocale=gnu --with-system-zlib --enable-decimal-float=bid --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.4 --with-local-prefix=/usr/local revision 135884 gave me [EMAIL PROTECTED] libjava]$ /export/build/gnu/gcc/build-x86_64-linux/./gcc/xgcc -shared-libgcc -B/export/build/gnu/gcc/build-x86_64-linux/./gcc -nostdinc++ -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/gcc-4.4/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.4/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.4/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.4/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava -I./include -I./gcj -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava -Iinclude -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava/include -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/include -Iclasspath/include -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/native/fdlibm -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava/libltdl -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava/libltdl -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava/.././libjava/../gcc -I/net/gnu-13/export/gnu/src/gcc/gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/usr/gcc-4.4\" -DTOOLEXECLIBDIR=\"/usr/gcc-4.4/lib/../lib\" -DJAVA_HOME=\"/usr/gcc-4.4\" -DBOOT_CLASS_PATH=\"/usr/gcc-4.4/share/java/libgcj-4.4.0.jar\" -DJAVA_EXT_DIRS=\"/usr/gcc-4.4/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/usr/gcc-4.4/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/usr/gcc-4.4/lib/../lib/gcj-4.4.0-9\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"/usr/gcc-4.4/share/java/ecj.jar\" -DLIBGCJ_DEFAULT_DATABASE=\"/usr/gcc-4.4/lib/../lib/gcj-4.4.0-9/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.4.0/classmap.db\" -g -O2 -D_GNU_SOURCE -m32 -MT java/net/natVMInetAddress.lo -MD -MP -MF java/net/.deps/natVMInetAddress.Tpo -c java/net/natVMInetAddress.cc -fPIC -DPIC -o java/net/.libs/natVMInetAddress.o In file included from java/net/natVMInetAddress.cc:29: /usr/include/netdb.h:661: error: expected â,â or â...â before â__listâ [EMAIL PROTECTED] libjava]$ Revision 135878 is OK. Has anyone else seen it? The Fortran CPP patch http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01267.html may be the cause. -- Summary: [4.4 Regression]: Gcc failed to bootstrap Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36331
[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables
--- Comment #4 from cnstar9988 at gmail dot com 2008-05-26 02:14 --- gcc 4.3.1 can build with --disable-multilib on i386-pc-solaris2.10. It can only compiles 32bit apps. gcc 4.3.1 can build on sparc-sun-solaris2.10. It can compiles 32bit and 64bit apps. -- gcc 4.2.3 can build well on i386-pc-solaris2.10, sparc-sun-solaris2.10. Both can accepts -m32 -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36330
[Bug tree-optimization/36329] latent problem with tree inlining
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-05-26 06:47 --- Fixing. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-26 06:47:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36329
