[Bug c++/4205] function template can call other function with incorrect parameters
--- Comment #13 from gianni at mariani dot ws 2007-08-06 06:26 --- This seems like a serious bug and it has been around for 6 years and there has been a patch to fix this as noted by Gaby. Is someone of the opinion that this should not be fixed ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4205
[Bug c/31886] (different from bug report c/31077 and 29241) C handling of always_inline attribute error and a solution
--- Comment #8 from rob1weld at aol dot com 2007-08-06 06:44 --- GCC 4.2.2 20070804 is able to compile newer kernels as is 4.2.1 20070628. I guess 4.3 and 4.1 are the only series lacking this ability. I am not allowed to change the Summary: to add [4.3 Regression] to the begining since I did not create this report. If we desire to compile the Linux kernel with GCC 4.3 (and apparently, but not tested by me, GCC 4.1 also) we will need to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31886
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #39 from bonzini at gnu dot org 2007-08-06 08:08 --- committed?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #1 from nickc at redhat dot com 2007-08-06 08:12 --- Subject: Re: New: -frecord-gcc-switches issues Hi Jakub, .ascii -isystem ./include-fixed .zero 1 .ascii -D_GNU_SOURCE a.c .zero 1 The main issue I have with this is the separation of options into separate strings (though, look above at -D_GNU_SOURCE a.c string to see it is not done always anyway). Right - I could not find 100% effective heuristic to work out when a word on the command line was the argument to a previous command line option or a separate option in its own right. The current heuristic assumes that if the word does not start with a dash, then it is an argument to previous word. Hence ./include-fixed is correctly taken as an argument to -isystem but a.c is mistakenly taken as an argument to -D_GNU_SOURCE. I think that in order to fix this the .GCC.command.line section creation code will have to be made more complex and have access to the entire command line options table. When I submitted the original patch to create this feature I wanted to keep things simple, so I did not try to do this. On the other side, if you have one big string with all command line options (but one that should not reference the source file name [snip] ) then you can query whether each source was compiled with -fstack-protector or not, etc. Except that you will not have the source file names in the strings. So if one or more of the component objects were not compiled with -fstack-protector you then have to go through several more hoops in order to find out which ones they are. (but one that should not reference the source file name and IMNSHO not even any of the -I/-iprefix/-isystem options, that's what .debug_line is for and in this section where you no longer know which filename was it and which directory was it in I can't see what it would be useful for) Personally I think that the pathname information (source files and include directories) should be left in, since it is pertinent to how the object file was created. (Yes you can track this information down from the .debug_line section, but that is more hassle if you are already looking at the .GCC.command.line section for the other options used to make the object file). I agree that relative pathnames in this information may not be very useful, but it should be possible to convert all relative paths into absolute paths as the .GCC.command.line section is generated. -frecord-gcc-switches among the saved options doesn't make sense either (if it was not used, they wouldn't be recorded). True. But I was working on the keep-it-simple principle when I wrote the code. Also it seems to me that not displaying it would be opening the door to censoring the command line. If we do not record the -frecord-gcc-switches option then we have established the principle that some options are not recorded. So maybe the -I options should be skipped as well. Then maybe the -O switches can be ignored (everyone uses optimization, right ?) I am exaggerating of course, but my point is, once we start censoring the command line, the consumers of .GCC.command.line can no longer trust it to contain a full and accurate record of how the object file was compiled. As a theoretical example of why this might be important, suppose that there was a bug whereby cc1 would ignore any command line options beyond argv[511], because of some system limitation. If we did not record the full command line in the .GCC.command.line section then someone using the information in the section to try to reproduce the bug might not be able to do so, because their command line would be shorter. Having said all that I am happy to see this feature improved so please do submit patches for it. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug c/31886] (different from bug report c/31077 and 29241) C handling of always_inline attribute error and a solution
--- Comment #9 from zhouyi04 at ios dot cn 2007-08-06 08:40 --- (In reply to comment #8) I try to compile my giving C program using gcc-4.2.1, the problem still exists. As my solution 1 suggests: a caller function is inlinable only if all of its callee functions are inlinable. while this is not the case in original tree-optimize.c (including that in CVS), which says a caller function should be inlined if one of its function is inlinable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31886
[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt (IRQ)))
--- Comment #8 from sgh at sgh dot dk 2007-08-06 09:08 --- also fails on 4.2.1 -- sgh at sgh dot dk changed: What|Removed |Added CC||sgh at sgh dot dk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
[Bug c++/30836] template T[] doesn't catch T[5]
--- Comment #3 from pcarlini at suse dot de 2007-08-06 09:13 --- Yes, the standard is clear that array of unknown bound of T and array of N of T are different types. And we are all implementing the is_array trait with 2 specializations (Vandevoorde and Josuttis included in their book). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30836
[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 09:18:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32926
[Bug c++/19532] cp/pt.c mentions a function that has been removed.
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-06 09:18 --- Subject: Bug 19532 Author: paolo Date: Mon Aug 6 09:18:39 2007 New Revision: 127238 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127238 Log: 2007-08-06 Paolo Carlini [EMAIL PROTECTED] PR c++/19532 * pt.c (template_class_depth): Fix comment; change return type to bool. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19532
[Bug c++/19532] cp/pt.c mentions a function that has been removed.
--- Comment #3 from pcarlini at suse dot de 2007-08-06 09:19 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19532
[Bug fortran/32801] USE of ISO_C_BINDING, ONLY: C_LOC causes compiler seg fault
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-06 09:20 --- Without any more news, let's consider this fixed. Douglas, if it so happens that your bug wasn't fixed by the patch, please reopen this bug-report. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32801
[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-06 09:49
---
OK, I downloaded GlobSol and have a reduced testcase:
$ cat pr32926.f90
subroutine foo (fcn)
external fcn
contains
subroutine bar
call fcn
end subroutine bar
end subroutine foo
$ gfortran pr32926.f90
pr32926.f90: In function bar:
pr32926.f90:4: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:890
The backtrace is:
Breakpoint 1, fancy_abort (
file=0xb03900 ../../../trunk2/gcc/fortran/trans-decl.c, line=890,
function=0xb03f60 gfc_get_symbol_decl)
at ../../../trunk2/gcc/diagnostic.c:654
654 {
(gdb) where
#0 fancy_abort (file=0xb03900 ../../../trunk2/gcc/fortran/trans-decl.c,
line=890, function=0xb03f60 gfc_get_symbol_decl)
at ../../../trunk2/gcc/diagnostic.c:654
#1 0x0048c5a3 in gfc_get_symbol_decl (sym=0xe8e1d0)
at ../../../trunk2/gcc/fortran/trans-decl.c:888
#2 0x0048ec58 in gfc_conv_function_val (se=0x7fff83f5a240, sym=0x37a)
at ../../../trunk2/gcc/fortran/trans-expr.c:1252
#3 0x004909b6 in gfc_conv_function_call (se=0x7fff83f5a240,
sym=0xe8e1d0, arg=0x0, append_args=0x0)
at ../../../trunk2/gcc/fortran/trans-expr.c:2459
#4 0x004ab86f in gfc_trans_call (code=0xe8ee30,
dependency_check=0 '\0') at ../../../trunk2/gcc/fortran/trans-stmt.c:331
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32926
[Bug fortran/33001] New: error with hexadecimal DATA
d1mach.f:90.43: DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' / 1 Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1) -- Summary: error with hexadecimal DATA Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:03 --- Created an attachment (id=14028) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14028action=view) sample source that does not compile This is a SLATEC machine file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect
Statements like: DATA DMACH(1) / Z'0010' / DATA DMACH(2) / Z'7FEF' / DATA DMACH(3) / Z'3CA0' / DATA DMACH(4) / Z'3CB0' / DATA DMACH(5) / Z'3FD34413509F79FF' / generate incorrect data. -- Summary: 64-bit hexadecimal DATA incorrect Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linu GCC host triplet: x86_64-redhat-linu GCC target triplet: x86_64-redhat-linu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33002] 64-bit hexadecimal DATA incorrect
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:15 --- Created an attachment (id=14029) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14029action=view) sample source that demonstrates the problem This is a SLATEC machine file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug pch/13676] GCC failes to recognize files ending in .hpp as headers to be precompiled
--- Comment #17 from gerald at gcc dot gnu dot org 2007-08-06 11:10 --- Subject: Bug 13676 Author: gerald Date: Mon Aug 6 11:10:19 2007 New Revision: 127239 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127239 Log: PR pch/13676 * doc/invoke.texi: Add .hp, .hxx, .hpp, .h, .HPP, .tcc as c++ header. cp: * lang-specs.h: Add .hp, .hxx, .hpp, .h, .HPP, .tcc as c++ header. * g++spec.c (lang_specific_driver): Check them. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/g++spec.c trunk/gcc/cp/lang-specs.h trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13676
[Bug fortran/33002] 64-bit hexadecimal DATA incorrect
--- Comment #2 from sliwa at cft dot edu dot pl 2007-08-06 11:18 --- There is also bug #33001. Both the bugs together make life difficult. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33002] 64-bit hexadecimal DATA incorrect
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 11:21 --- Now I see that 32-bit data is incorrect also. DATA RMACH(1) / Z'0080' / DATA RMACH(2) / Z'7F7F' / DATA RMACH(3) / Z'3380' / DATA RMACH(4) / Z'3400' / DATA RMACH(5) / Z'3E9A209B' / -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #40 from pinskia at gcc dot gnu dot org 2007-08-06 11:35 --- (In reply to comment #39) committed?? This is now more like a meta-bug, see the other two bugs which are opened for the current issues (yes both are assigned to me and both are actively being worked on, well one is depend on the other but still being worked on). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/22256] diagnostic shows wrong type for cast operator
--- Comment #6 from pcarlini at suse dot de 2007-08-06 11:52 --- The subtle issue here is that this specific error message should be emitted *only* when the incorrectly specified return type doesn't match, thus a plain error instead of a pedwarn: case sfk_conversion: if (type !same_type_p (type, optype)) error (operator %qT declared to return %qT, optype, type); else if (type) pedwarn (return type specified for %operator %T%, optype); type = optype; but for some reason the thing doesn't work... I'm looking a bit into it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22256
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #41 from paolo dot bonzini at lu dot unisi dot ch 2007-08-06 11:52 --- Subject: Re: [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc This is now more like a meta-bug, see the other two bugs which are opened for the current issues (yes both are assigned to me and both are actively being worked on, well one is depend on the other but still being worked on). Ah, I see. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/33003] New: missed diagnostic about unused variable.
class X
{
public:
static X instance();
static void init();
private:
X();
};
void f()
{
X x = X::instance();
x.init();
}
in this case the 'x' variable is initialized and unused.
gcc-4.2 accepts this w/o any warning at -Wall -Wextra
but vs2005-express reports warning C4189 at warning level 4.
--
Summary: missed diagnostic about unused variable.
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33003
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-06 12:11 --- DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' / Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1) The error message is correct: You cannot fit the number into an INTEGER(4) as this is bigger than HUGE(0). As the overflow is intended, one can use -fno-range-check to disable this checking and thus the error message. I think one should do here the same as in primary.c and add the following to the error message: --- arith.c (revision 127237) +++ arith.c (working copy) @@ -1983,3 +1983,4 @@ arith_error (arith rc, gfc_typespec *fro case ARITH_OVERFLOW: - gfc_error (Arithmetic overflow converting %s to %s at %L, + gfc_error (Arithmetic overflow converting %s to %s at %L. This check +can be disabled with the option -fno-range-check, gfc_typename (from), gfc_typename (to), where); -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org GCC build triplet|x86_64-redhat-linux | GCC host triplet|x86_64-redhat-linux | GCC target triplet|x86_64-redhat-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug c++/33003] missed diagnostic about unused variable.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 12:33 --- To the developer (and me), x is not unused. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33003
Re: [Bug target/32951] missed memcpy - movdqa optimization.
On 6 Aug 2007 12:42:18 -, pluto at agmk dot net [EMAIL PROTECTED] wrote: moreover i'm wondering why gcc uses movdqa for unaligned loads? Because __m128i is assumed to be aligned. -- Pinski
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #4 from sliwa at cft dot edu dot pl 2007-08-06 12:45 --- With -fno-range-check I get: d1mach.f: In function 'd1mach': d1mach.f:2: fatal error: gfc_todo: Not Implemented: Initialization of overlapping variables compilation terminated. See also bug #33002. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #12 from aph at gcc dot gnu dot org 2007-08-06 12:48 --- Subject: Bug 32843 Author: aph Date: Mon Aug 6 12:48:07 2007 New Revision: 127241 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127241 Log: PR testsuite/32843 * src/x86/sysv.S (ffi_closure_raw_SYSV): Handle FFI_TYPE_UINT8, FFI_TYPE_SINT8, FFI_TYPE_UINT16, FFI_TYPE_SINT16, FFI_TYPE_UINT32, FFI_TYPE_SINT32. Modified: trunk/libffi/ChangeLog trunk/libffi/src/x86/sysv.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug target/32951] missed memcpy - movdqa optimization.
--- Comment #2 from pluto at agmk dot net 2007-08-06 12:42 --- thanks for ths explanation about aligned attribute. moreover i'm wondering why gcc uses movdqa for unaligned loads? it should use movdqu for *((__m128i*)ptr) and _mm_set_epi8(ptr[15],...,ptr[0]). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32951
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 12:41 --- 1. The attached d1mach.f works fine with g77. 2. The numbers are 32-bit, so why an overflow? Maybe the number is extended as a signed number (padded with ones), and the conversion is unsigned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/33002] Hexadecimal DATA incorrect
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 12:49 --- Using REAL RMACH(5) DATA RMACH(1) / Z'0080' / is invalid Fortran 77/90/95/2003 as Fortran only allows: If a data-stmt-constant is a boz-literal-constant, the corresponding variable shall be of type integer. The boz-literal-constant is treated as if it were an int-literal-constant with a kind-param that specifies the representation method with the largest decimal exponent range supported by the processor. Gfortran interprets DATA RMACH(1) / Z'0080' / as rmach(1) = real(int(Z'0080', maximallyNeededKind)) which is ok as the program is invalid and thus undfefined. Other compilers interpret it as bit pattern. The result is are 8388608. respectively 1.1754944E-38. Solution for Fortran 90/95/2003: Replace DATA RMACH(1) / Z'0080' / by RMACH(1) = transfer( Z'0080', rmach) I think nonetheless that gfortran misbehaves. Expected: - With -std=f95 etc. give a warning or an error - With -std=gnu allow it (maybe with warning?) and tread as transfer(Z'...', 0.0) to be compatible with the other compilers. NAG f95 gives always the error: Error: Data-stmt-value incompatible with data-stmt-object whereas, e.g., g95 and ifort give a warning for -std=f95 and have the same result as with TRANSFER. Warning (160): BOZ constant conversion at (1) is nonstandard Warning: Fortran 95 does not allow boz constant in this context. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org GCC build triplet|x86_64-redhat-linu | GCC host triplet|x86_64-redhat-linu | GCC target triplet|x86_64-redhat-linu | Keywords||diagnostic Summary|64-bit hexadecimal DATA |Hexadecimal DATA incorrect |incorrect | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #13 from aph at gcc dot gnu dot org 2007-08-06 12:53 --- The 32bit psABI specifies Integral Arguments as 'Functions pass all integer-valued arguments as words, expanding or padding signed or unsigned bytes and halfwords as needed'. For return values the best I can find is 'A function that returns an integral or pointer value places its result in register %eax.' Both are not exactly clear whether sign- or zero-extension is required. On the contrary, this implies very strongly to me that all integer-valued arguments are passed as words, fully sign- or zero-extended for their type. To read this in any other way strikes me as perverse. If we are not correctly sign- or zero-extendening return values we have broken the ABI. To suggest that this sign- or zero-extension does not apply to return values is also perverse. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug target/32951] missed memcpy - movdqa optimization.
--- Comment #4 from pluto at agmk dot net 2007-08-06 12:56 --- (In reply to comment #3) Subject: Re: missed memcpy - movdqa optimization. On 6 Aug 2007 12:42:18 -, pluto at agmk dot net [EMAIL PROTECTED] wrote: moreover i'm wondering why gcc uses movdqa for unaligned loads? Because __m128i is assumed to be aligned. so, as far i can see currently there's no way to generate movdqu load with emmintrin.h and __builtin_memcpy( __m128i, unaligned_ptr, 16 ) and i must write a short inline assembly for this purpose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32951
[Bug target/32951] missed memcpy - movdqa optimization.
--- Comment #3 from pinskia at gmail dot com 2007-08-06 12:43 --- Subject: Re: missed memcpy - movdqa optimization. On 6 Aug 2007 12:42:18 -, pluto at agmk dot net [EMAIL PROTECTED] wrote: moreover i'm wondering why gcc uses movdqa for unaligned loads? Because __m128i is assumed to be aligned. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32951
[Bug fortran/18850] padding within a sequence type
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-06 13:15 --- Maybe I'm completely off, but isn't the -fpack-derived option what is needed to play with this padding? (it's hard for me to tell exactly, because I don't really read assembly) If so, could we close the PR? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18850
[Bug debug/32990] [Regression] gdb has symbol table issues
--- Comment #2 from drow at gcc dot gnu dot org 2007-08-06 13:21 --- Subject: Re: New: [Regression] gdb has symbol table issues On Sat, Aug 04, 2007 at 11:13:11PM -, scovich at gmail dot com wrote: When debugging code produced by g++-4.3.0-20070716 the debugger regularly outputs the following error message when stopping at breakpoints or examining stack frames: error: warning: (Internal error: pc 0x419e59 in read in psymtab, but not in symtab.) This is more likely to be a bug in GDB than in GCC. We would need at least the debugging info (readelf -wf) from the compilation unit containing that address. But the GDB developers will probably not be able to help you without a testcase, either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32990
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-06 13:06 --- The numbers are 32-bit, so why an overflow? huge(0): 2147483647 ! biggest (positive) number fitting into integer(4) Z'': 4294967295 I would argue that 4294967295 is bigger than 2147483647. If one allows the overflow or regards it as bit pattern, one obtains -1. This is also what one gets for -fno-range-check. The program is simply invalid though as vendor extension many compilers allow it. One can discuss about the default behaviour in gfortran [write to the mailing list and not here], but the current behaviour has some merits, though I think one should point to the option which allows the compilation (see patch in comment #2). - (In reply to comment #4) d1mach.f:2: fatal error: gfc_todo: Not Implemented: Initialization of overlapping variables This was fixed meanwhile. gfortran 4.3 does not have this error any more. 4.3 binaries are available at: http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #14 from aph at gcc dot gnu dot org 2007-08-06 13:35 --- In addition: I suspect that this bug also is manifested on x86 Darwin, but my patch should not affect that system at all, and therefore I suspect that this bug is still manifested on that system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug bootstrap/32840] bootstrap broken on ix86-linux-gnu targets with --enable-targets=all
--- Comment #1 from hjl at lucon dot org 2007-08-06 13:44 --- Can you verify if it is the same as PR 31868? There is a a patch for PR 31868. -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32840
[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-01-31 23:01:50 |2007-08-06 13:47:12 date|| Target Milestone|4.2.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
[Bug c++/33004] New: Cannot resolve call to overloaded function and template functions)
The following code doesn't compile under gcc-4.2.1 on i686-pc-linux-gnu:
template class T void foo(T);
void foo(int);
void bar()
{
foo;
}
According to the discussion that began on thread
http://gcc.gnu.org/ml/gcc/2007-07/msg00663.html, then resumed on thread
http://gcc.gnu.org/ml/gcc/2007-07/msg00946.html, the compiler should accept the
code as valid, returning the address of 'void foo(int)'.
--
Summary: Cannot resolve call to overloaded function and template
functions)
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodolfo at rodsoft dot org
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=33004
[Bug c++/33005] New: Cannot specialize template function with address operator
The code below doesn't compile under gcc-4.2.1 on a i686-pc-linux-gnu
template class T void foo(T);
void bar()
{
fooint;
}
The compiler returns the following error message:
teste.cpp: In function void bar():
teste.cpp:4: error: statement cannot resolve address of overloaded function
As we're specifying a complete template function specialization, its address
should be returned correctly, and there's no overloaded function in scope,
there's nothing to resolve.
--
Summary: Cannot specialize template function with address
operator
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodolfo at rodsoft dot org
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=33005
[Bug c++/33005] Cannot specialize template function with address operator
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 13:57 --- *** This bug has been marked as a duplicate of 11407 *** -- 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=33005
[Bug c++/11407] [DR 115] Function cannot be resolved
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-06 13:57 --- *** Bug 33005 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rodolfo at rodsoft dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407
[Bug c++/33004] Cannot resolve call to overloaded function and template functions)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 13:58 --- *** This bug has been marked as a duplicate of 5458 *** -- 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=33004
[Bug c++/5458] address of overloaded template function as argument for template
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-06 13:58 --- *** Bug 33004 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rodolfo at rodsoft dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
[Bug fortran/32626] Run-time check for recursive functions
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 14:06:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32626
[Bug libobjc/30731] [4.3 Regression] Warnings while compiling libobjc with the uleb128 changes
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-06 14:18 --- Subject: Bug 30731 Author: pinskia Date: Mon Aug 6 14:17:59 2007 New Revision: 127242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127242 Log: 2007-08-06 Andrew Pinski [EMAIL PROTECTED] PR libobjc/30731 * exception.c (parse_lsda_header): Use _uleb128_t/_sleb128_t instead of _Unwind_Word for variables which are used in read_uleb128/read_sleb128. (PERSONALITY_FUNCTION): Likewise. Modified: trunk/libobjc/ChangeLog trunk/libobjc/exception.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30731
[Bug libobjc/30731] [4.3 Regression] Warnings while compiling libobjc with the uleb128 changes
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-06 14:18 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30731
[Bug c++/5458] address of overloaded template function as argument for template
--- Comment #12 from rodolfo at rodsoft dot org 2007-08-06 14:18 ---
This is an yet simpler case where this bug shows up:
template class T void foo(T);
void foo(int);
void bar()
{
foo;
}
i686-pc-linux-gnu-g++-4.2.1 fails with:
teste.cpp: In function void bar():
teste.cpp:6: error: statement cannot resolve address of overloaded function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
[Bug c++/28558] [4.0/4.1/4.2/4.3 regression] Trouble with __attribute__ and non-PODs
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-06 14:41 --- We get a different ICE now: t1.cc:4: internal compiler error: same canonical type node for different types A and A Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-08-18 04:13:29 |2007-08-06 14:41:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-06 14:57 --- Has this been fixed now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug preprocessor/30786] [4.1/4.2/4.3 Regression] ICE on _Pragma at end of file
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Keywords||error-recovery http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30786
[Bug c++/31749] [4.1/4.2/4.3 regression] ICE with invalid redeclaration of builtin
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-06 15:12 --- I no longer get a segfault for the trunk for the first testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
[Bug tree-optimization/30394] [4.3 Regression] FAIL: gcc.c-torture/execute/pr15262-1.c execution at -O2, -O3 and -Os
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-06 15:25 --- Fixed. And has been for a while. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30394
[Bug c++/32566] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:28 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:28:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32566
[Bug c++/32567] [4.3 regression] ICE on invalid use of parameter pack
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:29 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:29:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32567
[Bug c++/32674] [4.1/4.2/4.3 regression] ICE in lvalue_p_1 initialising static variable inside template class
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:38 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:38:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32674
[Bug debug/32563] [4.2/4.3 regression] ICE on pointer arithmetic
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:44 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:44:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
[Bug tree-optimization/19910] [4.2 regression] ICE with -ftree-loop-linear
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-08-06 15:47 --- Fixed for the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 regression] ICE|[4.2 regression] ICE with - |with -ftree-loop-linear |ftree-loop-linear http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[Bug c++/32898] [4.2/4.3 regression] Definition of variable N::i outside namespace N not rejected
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:53 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:53:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32898
[Bug c++/32984] add checking for array new delete
--- Comment #7 from dcb314 at hotmail dot com 2007-08-06 16:06 --- (In reply to comment #6) This is one which you need huge dataflow analysis Doubtful. Yes/No/Don't know flag on each pointer data member of a class would be some of it. and whole program to detect this problem. I'd be happy with a one file solution to this problem, as I hope my original problem report made clear. In summary, my customer doesn't have HP kit, valgrind is run time and not compile time, the compiler isn't going to be fixed anytime soon so I feel a Perl script may be invented. So closing as won't fix. Fair enough. Point taken. I'll try a Perl script. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32984
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-08-06 16:16 --- Not that I know. For my purposes, I use a hand-modified version of the _mingw.h header; maybe more recent versions of mingw have been fixed. Still, current trunk doesn't work with older mingw (more than a few months back). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-08-06 16:16 --- thanks for adding this bug report here and ccing me. Is there an easy way to separate out the include and link (-I, -L) bits from the macro defines and compiler option flags? Could the just the include bits be put into one string? When doing this does it make sense to define the base_dir and then use it as a substitution instead of putting in absolute addresses everywhere? This might cut down on size. I think that in order to fix this the .GCC.command.line section creation code will have to be made more complex and have access to the entire command line options table. When I submitted the original patch to create this feature I wanted to keep things simple, so I did not try to do this. This seems like a pretty smart strategy for getting this in. However can you expand on your comment above? What do you mean by have access to the entire command line options table? Would you dump the entire table? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug c++/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc64-unknown-linux-gnu | GCC host triplet|powerpc64-unknown-linux-gnu | GCC target triplet|spu-unknown-elf | Keywords||ice-on-valid-code Known to fail||4.3.0 Known to work||4.1.1 Summary|C++ frontend can not handle |[4.3 Regression] C++ |vector pointer constant |frontend can not handle |parameter |vector pointer constant ||parameter Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #6 from kargl at gcc dot gnu dot org 2007-08-06 17:30 --- *** This bug has been marked as a duplicate of 18026 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #14 from kargl at gcc dot gnu dot org 2007-08-06 17:30 --- *** Bug 33001 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sliwa at cft dot edu dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/33006] New: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676
When I attempt to compile the program listed below I get the following message: a.f90: In function 'MAIN__': a.f90:2: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The conditions were: 1. The August 3 version of gcc and gfortran were used. The problem does not occur with the July 27 version. 2. It was run on an SGI box under Debian Linux. I have not tested it on other processors. 3. The program was compiled with the flag -fdefault-integer-8. It does not produce the error without this flag. 4. If I replace z = MAX(x,y) with i = MAX(j, k) the problem disappears. PROGRAM test z = MAX(x,y) END PROGRAM test -- Summary: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33006
[Bug fortran/33002] Hexadecimal DATA incorrect
--- Comment #5 from kargl at gcc dot gnu dot org 2007-08-06 17:32 --- *** This bug has been marked as a duplicate of 18026 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #15 from kargl at gcc dot gnu dot org 2007-08-06 17:32 --- *** Bug 33002 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/33006] internal compiler error: in simplify_subreg, at simplify-rtx.c:4676
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 17:35 --- 3. The program was compiled with the flag -fdefault-integer-8. It does not produce the error without this flag. Yes we know, we are trying to resolve more and more of these -fdefault-integer-8 bugs. *** This bug has been marked as a duplicate of 32933 *** -- 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=33006
[Bug fortran/32933] ICE in simplify_subreg with -fdefault-integer-8
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-06 17:35 --- *** Bug 33006 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||michael dot a dot richmond ||at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
[Bug target/30961] [4.1/4.2 regression] redundant reg/mem stores/moves
--- Comment #18 from pluto at agmk dot net 2007-08-06 17:49 --- (In reply to comment #17) (In reply to comment #16) (In reply to comment #15) (In reply to comment #14) (In reply to comment #13) Created an attachment (id=13550) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13550action=view) [edit] An experimental patch This patch works for the testcase. i've applied this patch to 4.2.1 and compile testcases: convert/m32/m64 look fine. load/m32/m64 still look unoptimal. Gcc 4.3 works: naturally but its not even been released yet. users awaiting regression fixes for released compilers ;) Load is fixed by dataflow merge. Dear H.J.Lu, i'm not asking about 4.3 because it's far away future and dataflow merge won't be a part of next 4.2 release. i understand that developers love to play with unstable tree instead of backporting fixes but we're awaiting regression fixes for released compilers. after 4.3 release you'll jump to 4.4 and leave 4.3 regressions in the same way as you left 4.2 regressions. so, how we can motivate the gcc team to fix regressions in non-trunk tree? do you expect donations? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #19 from hjl at lucon dot org 2007-08-06 18:02 --- If we can find which patch causes this regression, it will help find a solution for 4.2. -- hjl at lucon dot org changed: What|Removed |Added Known to fail|4.0.2 4.1.2 4.2.1 |4.0.2 4.1.2 4.2.1 4.3.0 Summary|[4.1/4.2 regression]|[4.1/4.2/4.3 regression] |redundant reg/mem |redundant reg/mem |stores/moves|stores/moves Version|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #7 from patchapp at dberlin dot org 2007-08-06 18:20 --- Subject: Bug number PR33001 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-08/msg00374.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #20 from pluto at agmk dot net 2007-08-06 18:28 --- (In reply to comment #19) If we can find which patch causes this regression, it will help find a solution for 4.2. i'll we do a bisect hunting... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #3 from roland at redhat dot com 2007-08-06 19:19 --- Absolute file names are a very bad idea. That makes for gratuitous differences in builds due to the build or source directory name, i.e. unrepeatable builds. The names in .debug_line and .debug_info are already expected by post-processing tools and taken care of. Do not add another location in the object that might contain absolute file names. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug middle-end/32940] REG_POINTER attribute on DECL_ARTIFICIAL pointers
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-06 19:22 --- This patch helps more than just PR 28690 as we now have the ablity to use r0 more for the index which causes us to use one less callee saved register in some cases and reduces the stack size. I saw that result while compiling tramp3d. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32940
[Bug fortran/32985] COMMON checking: TYPE with(out) SEQUENCE/bind(C), ALLOCATABLE
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-06 19:23 ---
Patch for the first part. Missing: Check for default initializer.
Index: resolve.c
===
--- resolve.c (revision 127246)
+++ resolve.c (working copy)
@@ -610 +610 @@ resolve_common_blocks (gfc_symtree *comm
- gfc_symbol *sym;
+ gfc_symbol *sym, *csym;
@@ -618,0 +619,14 @@ resolve_common_blocks (gfc_symtree *comm
+for (csym = symtree-n.common-head; csym; csym = csym-common_next)
+ {
+ printf(DEBUG '%s' - derived=%s?\n,csym-name, csym-ts.type
== BT_DERIVED?yes:no);
+ /* Derived type names must have the SEQUENCE attribute. */
+ if (csym-ts.type == BT_DERIVED
+!(csym-ts.derived-attr.sequence
+|| csym-ts.derived-attr.is_bind_c))
+ {
+ gfc_error (Derived type variable '%s' in COMMON at %L has
+ neither the SEQUENCE nor the BIND(C) attribute,
+ csym-name, csym-declared_at);
+ }
+ }
+
Index: match.c
===
--- match.c (revision 127246)
+++ match.c (working copy)
@@ -2635,8 +2634,0 @@ gfc_match_common (void)
- /* Derived type names must have the SEQUENCE attribute. */
- if (sym-ts.type == BT_DERIVED !sym-ts.derived-attr.sequence)
- {
- gfc_error (Derived type variable in COMMON at %C does not
-have the SEQUENCE attribute);
- goto cleanup;
- }
-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32985
[Bug target/31868] Non-Linux DWARF EH x86-64 targets have broken crtend.o
--- Comment #3 from hjl at gcc dot gnu dot org 2007-08-06 19:58 --- Subject: Bug 31868 Author: hjl Date: Mon Aug 6 19:58:11 2007 New Revision: 127248 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127248 Log: 2007-08-06 H.J. Lu [EMAIL PROTECTED] Daniel Jacobowitz [EMAIL PROTECTED] PR target/31868 * config.gcc (x86_64-*-freebsd*): Add i386/t-crtstuff to tmake_file. (x86_64-*-netbsd*): Likewise. (x86_64-*-linux*): Likewise. (x86_64-*-kfreebsd*-gnu): Likewise. (x86_64-*-knetbsd*-gnu): Likewise. (i[34567]86-*-solaris2.1[0-9]*): Likewise. * config/i386/t-linux64 (CRTSTUFF_T_CFLAGS): Removed. * config/i386/t-crtstuff (CRTSTUFF_T_CFLAGS): Update comments. Add -fno-asynchronous-unwind-tables. * config/t-freebsd (CRTSTUFF_T_CFLAGS_S): Add $(CRTSTUFF_T_CFLAGS). * config/t-libc-ok (CRTSTUFF_T_CFLAGS_S): Likewise. * config/t-lynx (CRTSTUFF_T_CFLAGS_S): Likewise. * config/t-netbsd (CRTSTUFF_T_CFLAGS_S): Likewise. * config/t-svr4 (CRTSTUFF_T_CFLAGS_S): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/i386/t-crtstuff trunk/gcc/config/i386/t-linux64 trunk/gcc/config/t-freebsd trunk/gcc/config/t-libc-ok trunk/gcc/config/t-lynx trunk/gcc/config/t-netbsd trunk/gcc/config/t-svr4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #15 from doko at gcc dot gnu dot org 2007-08-06 20:13 --- Subject: Bug 32843 Author: doko Date: Mon Aug 6 20:13:06 2007 New Revision: 127249 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127249 Log: - Revert the changes for PR testsuite/32843, not needed on the branch. Modified: branches/ubuntu/gcc-4_2-branch/libffi/ChangeLog branches/ubuntu/gcc-4_2-branch/libffi/src/x86/ffi.c branches/ubuntu/gcc-4_2-branch/libffi/src/x86/sysv.S branches/ubuntu/gcc-4_2-branch/libffi/testsuite/libffi.call/return_sc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug fortran/32985] COMMON checking: TYPE with(out) SEQUENCE/bind(C), ALLOCATABLE
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 20:18 ---
Besides default initializers (TODO), I also forgot about the following, to be
added after the if clause of previous patch:
else if (csym-ts.type == BT_DERIVED
csym-ts.derived-attr.alloc_comp)
{
gfc_error (Derived type variable '%s' at %L in COMMON has
an ultimate component that is allocatable,
csym-name, csym-declared_at);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32985
[Bug java/32758] ecj1 hangs
--- Comment #8 from andreast at gcc dot gnu dot org 2007-08-06 20:34 --- Happens since r125624. Same situation on ppc-linux (32-bit) In the libjava testsuite you'll see the following test cases failing since then: FAIL: noclass execution - gij test FAIL: pr11951 execution - gij test FAIL: throwit execution - gij test FAIL: pr29812 execution - gij test FAIL: ExtraClassLoader execution - source compiled test FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test FAIL: ExtraClassLoader -O3 execution - source compiled test FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test -- andreast at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-07-24 14:33:31 |2007-08-06 20:34:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
[Bug fortran/29828] [F2003] MIN and MAX with character variables
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-06 20:47 --- Subject: Bug 29828 Author: fxcoudert Date: Mon Aug 6 20:47:17 2007 New Revision: 127252 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127252 Log: PR fortran/29828 * trans.h (gfor_fndecl_string_minmax): New prototype. * trans-decl.c (gfor_fndecl_string_minmax): New variable. (gfc_build_intrinsic_function_decls): Create gfor_fndecl_string_minmax. * check.c (gfc_check_min_max): Allow for character arguments. * trans-intrinsic.c (gfc_conv_intrinsic_minmax_char): New function. (gfc_conv_intrinsic_function): Add special case for MIN and MAX intrinsics with character arguments. * simplify.c (simplify_min_max): Add simplification for character arguments. * intrinsics/string_intrinsics.c (string_minmax): New function and prototype. * gfortran.map (GFORTRAN_1.0): Add _gfortran_string_minmax * gfortran.dg/minmax_char_1.f90: New test. * gfortran.dg/minmax_char_2.f90: New test. * gfortran.dg/min_max_optional_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/min_max_optional_4.f90 trunk/gcc/testsuite/gfortran.dg/minmax_char_1.f90 trunk/gcc/testsuite/gfortran.dg/minmax_char_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29828
[Bug fortran/29828] [F2003] MIN and MAX with character variables
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-06 20:49 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29828
[Bug fortran/30802] out of bounds error in allocatable array not picked up with -fbounds-check
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-06 21:13 --- It's not about being allocatable, it's the I/O operation that doesn't perform the necessary check: $ cat a.f90 real :: x(2,2) x = 0. print *, x(5,:) x(5,:) = 1. end $ gfortran -fbounds-check a.f90 ./a.out 0.00 5.8787666E-39 At line 4 of file a.f90 Fortran runtime error: Array reference out of bounds for array 'x', upper bound of dimension 1 exceeded -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802
[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-06 21:18 --- I don't think it's a duplicate, and I don't think it has anything to do with allocatable either: $ cat b.f90 subroutine foo(n) integer, allocatable :: ivec(:) integer :: jvec(n) allocate (ivec(n)) ivec = [1,2,3] write (*,*) ivec jvec = [1,2,3] write (*,*) jvec end program test call foo (2) end $ gfortran -fbounds-check b.f90 ./a.out 1 2 1 2 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org OtherBugsDependingO||27766 nThis|| Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059
[Bug c++/31749] [4.1/4.2/4.3 regression] ICE with invalid redeclaration of builtin
--- Comment #5 from aaw at gcc dot gnu dot org 2007-08-06 21:24 --- No segfault, but it does give an is already declared in this scope error. Contrary to the claim in the initial bug submission, this is valid code. From paragraph 10, section 7.3.3 of the C++ standard: Since a using-declaration is a declaration, the restrictions on declarations of the same name in the same declarative region (3.3) also apply to using-declarations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #21 from pluto at agmk dot net 2007-08-06 21:39 --- rev. 101665: convert:movl%edi, -4(%rsp) movl%edi, -20(%rsp) movss -4(%rsp), %xmm0 ret load: movzwl (%rdi), %eax ret rev. 101666 (-fforce-mem removal): convert:movl%edi, -4(%rsp) movl%edi, -20(%rsp) movss -4(%rsp), %xmm0 ret load: movzwl (%rdi), %eax movw%ax, -2(%rsp) movzwl %ax, %eax ret rev. 116656 (patch for PR27567): convert:movl%edi, -4(%rsp) movss -4(%rsp), %xmm1 movaps %xmm1, %xmm0 ret load: movzwl (%rdi), %eax movw%ax, -2(%rsp) movzwl %ax, %eax ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug objc/32995] False warning when implementing an instance method called `dealloc'
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-06 21:40 --- well to some extend dealloc is special method which is why the warning is there. Also dealloc does not belong to the the original Object class (which is based on the old NX Object base class). This is true of the NeXT runtime Object too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|x86_64-linux-gnu| Summary|False warning when |False warning when |implementing an instance|implementing an instance |method called `dealloc' |method called `dealloc' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32995
[Bug pch/13676] GCC failes to recognize files ending in .hpp as headers to be precompiled
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-08-06 21:43 --- Fixed. -- 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=13676
[Bug c++/32839] internal compiler error: Segmentation fault (templates)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32839
[Bug fortran/30933] intrinsic: EXIT
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:29 --- Subject: Bug 30933 Author: fxcoudert Date: Mon Aug 6 22:29:24 2007 New Revision: 127256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127256 Log: PR fortran/30933 * iresolve.c (gfc_resolve_exit): Convert argument to default integer kind. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30933] intrinsic: EXIT
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:29 --- Last bit fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30933] intrinsic: EXIT
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:44 --- Subject: Bug 30933 Author: fxcoudert Date: Mon Aug 6 22:44:27 2007 New Revision: 127257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127257 Log: PR fortran/30933 * intrinsic.c (add_functions): Fix name of argument to CHDIR. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:45 --- Last bit fixed: http://gcc.gnu.org/viewcvs?view=revrevision=127257 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30947] intrinsic: ALARM
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-06 23:03 --- Subject: Bug 30947 Author: fxcoudert Date: Mon Aug 6 23:02:38 2007 New Revision: 127259 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127259 Log: PR fortran/30947 * iresolve.c (gfc_resolve_alarm_sub): Suffix the subroutine name with the kind of the STATUS argument. * intrinsics/signal.c: Create specific versions of alarm_sub and alarm_sub_int according to the integer kind of the last argument. * gfortran.map (GFORTRAN_1.0): Remove _gfortran_alarm_sub and _gfortran_alarm_sub_int, add _gfortran_alarm_sub_i4, _gfortran_alarm_sub_i8, _gfortran_alarm_sub_int_i4 and _gfortran_alarm_sub_int_i8. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/signal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug fortran/30947] intrinsic: ALARM
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-08-06 23:05 --- This should fix the remaining part. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug c++/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- Comment #1 from janis at gcc dot gnu dot org 2007-08-06 23:15 --- A regression hunt of mainline on powerpc-linux identified the following patch, where the compiler went from compiling in a reasonable time to taking more than three seconds for the submitter's testcase: r117696 | bonzini | 2006-10-13 15:59:03 + (Fri, 13 Oct 2006) http://gcc.gnu.org/viewcvs?view=revrev=117696 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug c++/31749] [4.1/4.2/4.3 regression] ICE with invalid redeclaration of builtin
--- Comment #6 from aaw at gcc dot gnu dot org 2007-08-06 23:17 --- Created an attachment (id=14030) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14030action=view) Fix for PR 31749. This patches fixes this PR and includes some ambiguous decl cleanup as well. Submission pending completion of full testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
