[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-07-06 06:00 --- Regardless, we should catch this and issue the error message about -fmax-array-constructor. I don't see why we would want to do anything else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #12 from ohl at physik dot uni-wuerzburg dot de 2010-07-06 07:38 --- (In reply to comment #10) It is not particularly efficient to use a huge static variable. [...] initialization at run time is the better choice for large arrays. The best solution for PARAMETER depends on the purpose. In the real-life application, the non-trivial PARAMETER values are computed by an external code generator to match the code and its impossible to compute them in Fortran at runtime. It would be possible to read the values from a separate file generated together with the code, but it's tedious and introduces another failure mode. However, I cannot see that this would be more efficient than loading the equivalent data sections. Furthermore, declaring the data as PARAMETER helps the optimizer and OpenMP, doesn't it? -- ohl at physik dot uni-wuerzburg dot de changed: What|Removed |Added CC||ohl at physik dot uni- ||wuerzburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug libgomp/44833] New: unexpected thread binding for openmp
if I use thread binding in the following way: export OMP_NUM_THREADS=8 export GOMP_CPU_AFFINITY=0 1 2 3 4 5 6 7 for code that has three parallel regions: !$omp parallel default(private) shared(bindings,n_thread) !$omp end parallel !$omp parallel default(private) shared(bindings,n_thread) num_threads(2) !$omp end parallel !$omp parallel default(private) shared(bindings,n_thread) !$omp end parallel I get the following: ./a.out Entering first parallel region all threads bindings are 0 1 2 3 4 5 6 7 Entering second parallel region using two threads bindings are 0 1 Entering third parallel region using all threads bindings are 0 1 0 1 2 3 4 5 so it the last parallel section 2 times 2 threads bind to the same CPU (this is also what is effectively happing looking at the CPU usage in top). this seems to be happening for gcc 4.3 - 4.6 The testcase will be attached. -- Summary: unexpected thread binding for openmp Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #1 from jv244 at cam dot ac dot uk 2010-07-06 08:03 --- Created an attachment (id=21099) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21099action=view) testcase part 1 C code to report thread binding -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #2 from jv244 at cam dot ac dot uk 2010-07-06 08:05 --- Created an attachment (id=21100) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21100action=view) fortran testcase build run testcase as : gfortran -fopenmp test.f90 get_affinity.c export OMP_NUM_THREADS=8 export GOMP_CPU_AFFINITY=0 1 2 3 4 5 6 7 ./a.out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-06 08:21 --- That's how GOMP_CPU_AFFINITY works - it is a round-robin assignment of CPUs upon thread creation, and the first two threads are never recreated in this case. Currently there is no tracking on how many threads bind to which CPU etc. We'd need to track that in some data structure and choose CPU with lowest number of assigned threads or something. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords||openmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug tree-optimization/41355] Type of ADDR_EXPR in CALL_EXPR not rebuilt when function is cloned
--- Comment #5 from baldrick at gcc dot gnu dot org 2010-07-06 08:23 --- Even better, it actually works! :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41355
[Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-06 08:44 --- (In reply to comment #2) Actually it seems to be fallout of my local DECL_BY_REFERENCE change (so it does not reproduce on clean mainline). Apprently the result_slot_addr is something that is not allowed in mem_ref. It goes away with: @@ -902,6 +903,8 @@ remap_gimple_op_r (tree *tp, int *walk_s then regimplification is probably needed. */ if (invariant !is_gimple_min_invariant (*tp)) id-regimplify = true; + if (!is_gimple_mem_ref_addr (TREE_OPERAND (*tp, 0))) + id-regimplify = true; *walk_subtrees = 0; Does it seem to make sense? No. It should have been canonicalized a few lines above in MEM_REF handling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
[Bug c/44828] possible integer wrong code bug
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-06 09:25 ---
Shorter testcase:
extern void abort (void);
static char
foo (char si1, char si2)
{
return si1 * si2;
}
int a = 0x105F61CA;
int
main (void)
{
int b = 0x0332F5C8;
if (foo (b, a) 0)
abort ();
return 0;
}
Works with -O2 -fwrapv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug c/44828] possible integer wrong code bug
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-06 09:33 --- Not sure whether the testcase is valid or not. The multiplication using char variables on both sides (and likewise for result) is: -54 * -56 (= 3024), but (char) 3024 is -48. For int that would be clear undefined behavior, but for char the multiplication is promoted to int, so it is (char) (int * int). *.ccp1 has: char D.2741; char D.2741; char si2; int D.2727; char D.2726; int a.0; bb 2: a.0_2 = a; D.2726_3 = (char) a.0_2; D.2727_4 = (int) D.2726_3; si2_11 = (char) D.2727_4; D.2741_12 = si2_11 * -56; D.2741_13 = D.2741_12; D.2741_7 = D.2741_13; if (D.2741_7 0) but forwprop1 uses if (si2_11 0) test instead. If the testcase is valid, we shouldn't assume undefined overflow for char and short operations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #13 from burnus at gcc dot gnu dot org 2010-07-06 09:46 --- (In reply to comment #11) Regardless, we should catch this and issue the error message about -fmax-array-constructor. I don't see why we would want to do anything else. I concur. Juergen, does your program work with a sufficiently large -fmax-array-constructor=... ? (In reply to comment #12) It is not particularly efficient to use a huge static variable. [...] [...] initialization at run time is the better choice for large arrays. The best solution for PARAMETER depends on the purpose. In the real-life application, the non-trivial PARAMETER values are computed by an external code generator to match the code and its impossible to compute them in Fortran at runtime. As written: The best solution depends on the purpose. If the array (either static or parameter) gets very large, one has to think whether one should do something else. The answer might well be no. It would be possible to read the values from a separate file generated together with the code, but it's tedious and introduces another failure mode. However, I cannot see that this would be more efficient than loading the equivalent data sections. Furthermore, declaring the data as PARAMETER helps the optimizer and OpenMP, doesn't it? It depends. PARAMETERs - as currently implemented in gfortran - are spurious objects; they only materialize when used. Thus, when doing a = sin(PI), where PI is a parameter, gfortran replaces this by a= sin(value_of_PI) which can then be optimized. Similarly, if you have a large array and use, e.g. sum(large_PARAMETER) then the argument is reduced at compile time. However, if you do all the time a = large_PARAMETER_array(:,1) etc., a static temporary array is created to which the values are assigned to. Thus, the data might be present several times in the binary. It still helps with optimizations as the middle end know those values. Which variant is then faster at the end, it difficult to tell - in many cases the PARAMETER one. (Obvious disadvantages are: longer compile time, large .mod files, large binary files; for number crunching, those disadvantages are usually not that important.) Thus as written above: I would recommend to think of avoiding large static (SAVE) arrays (especially if initialized by a non-zero value) -- and at least quickly consider whether avoiding large PARAMETER arrays makes sense - but in both cases one can often make the conscious decision that using a static/parameter arrays is best. In your case it seems as if using a PARAMETER is most suitable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #4 from jv244 at cam dot ac dot uk 2010-07-06 10:01 --- (In reply to comment #3) That's how GOMP_CPU_AFFINITY works - it is a round-robin assignment of CPUs upon thread creation, and the first two threads are never recreated in this case. Currently there is no tracking on how many threads bind to which CPU etc. We'd need to track that in some data structure and choose CPU with lowest number of assigned threads or something. oops... this really is a surprise, is there a way that these 6 threads are not destroyed entering the parallel region that asks for 2 threads. That should fix the problem. Other compilers do the expected thing, for example intel: ifort -openmp test.f90 get_affinity.o export OMP_NUM_THREADS=8 export KMP_AFFINITY=proclist=[0,1,2,3,4,5,6,7] ./a.out OMP: Warning #63: KMP_AFFINITY: proclist specified, setting affinity type to explicit. Entering first parallel region all threads bindings are 0 1 2 3 4 5 6 7 Entering second parallel region using two threads bindings are 0 1 Entering third parallel region using all threads bindings are 0 1 2 3 4 5 6 7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
--- Comment #24 from sfilippone at uniroma2 dot it 2010-07-06 10:14 ---
(In reply to comment #23)
(In reply to comment #22)
generic_23.f03 obviously works becase the binding name DOIT and the procedure
name are one and the same
Hi all
Another variation to the test case, to have the guilty statements in a one-line
function of their own, and the -fdump-tree-original shows what's going on:
tryset is correct, tryall has this a-$vptr-allocate-allocate_mnnz
thing which leads to error. If it was just a-$vptr-allocate_mnnz (which I
tested by changing the statement to invoke directly the specific binding name)
it would work.
So, it looks like the code that resolves the generic procedure would do well to
just avoid the GENERIC part of the vtab, resolve the generic to a specific and
invoke the vtab for the specific. I have tried to follow the resolve code, but
I got lost (I guess it's a bit coplex as a first trip inside gfortran guts :-)
I suppose the originator(s) of the code would do much better.
tryall (struct class$d_base_sparse_mat restrict a, integer(kind=4) restrict
m, integer(kind=4) restrict n, integer(kind=4) restrict nz)
{
a-$vptr-allocate-allocate_mnnz ((integer(kind=4) *) m, (integer(kind=4) *)
n, (struct class$d_base_sparse_mat *) a, (integer(kind=4) *) nz);
}
tryset (struct class$d_base_sparse_mat restrict a)
{
a-$vptr-set_null ((struct class$d_base_sparse_mat *) a);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
--- Comment #25 from sfilippone at uniroma2 dot it 2010-07-06 10:15 --- Created an attachment (id=21101) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21101action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
[Bug target/44834] New: pr44707.c FAILs on sparc -m32: asm operand requires impossible reload
The recently added gcc/testsuite/gcc.c-torture/compile/pr44707.c fails on sparc64 with -m32 -O1/-O2/-O3/-Os: gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload This shows as new FAILs in recent test results, but the test case is new and actually fails with every gcc 4.x/3.x release back to gcc-3.2.3. Both Linux and Solaris fail. It does not fail with -O0 or with -m64. -- Summary: pr44707.c FAILs on sparc -m32: asm operand requires impossible reload Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC target triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44834
[Bug bootstrap/44832] --enable-build-with-cxx Bootstrap comparison failure
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-06 10:22 --- Huh, I can't see how this should cause a debug compare failure. Can you attach preprocessed source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug bootstrap/44825] [4.6 regression] Failed to bootstrap
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-06 10:25 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44825
[Bug tree-optimization/44831] [4.6 Regression] internal compiler error: verify_stmts failed when compiling wine
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-06 10:30 ---
Confirmed. Reduced testcase:
typedef unsigned char UCHAR, *PUCHAR;
typedef void *HANDLE;
typedef struct _NCB {
UCHAR ncb_reserve[10];
} NCB, *PNCB;
struct NBCmdQueue {
PNCB head;
};
PNCB *NBCmdQueueFindNBC(struct NBCmdQueue *queue, PNCB ncb)
{
PNCB *ret = queue-head;
while (ret *ret != ncb)
ret = (PNCB *)((*ret)-ncb_reserve + sizeof(HANDLE));
}
caused by phiprop. Thus, mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Component|c |tree-optimization
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-07-06 10:30:03
date||
Summary|internal compiler error:|[4.6 Regression] internal
|verify_stmts failed when|compiler error: verify_stmts
|compiling wine |failed when compiling wine
Target Milestone|--- |4.6.0
Version|unknown |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44831
[Bug c/44828] possible integer wrong code bug
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-06 10:35 ---
The bug is that we have in .original
{
return si1 * si2;
}
while it should have been
{
return (char)((unsigned char) si1 * (unsigned char) si2);
}
which is premature optimization by convert_to_integer, short-cutting
the correctly implemented fold of (signed char)((int) si1 * (int) si2)
to the above.
Index: gcc/convert.c
===
--- gcc/convert.c (revision 161840)
+++ gcc/convert.c (working copy)
@@ -774,7 +774,8 @@ convert_to_integer (tree type, tree expr
|| ((!TYPE_OVERFLOW_WRAPS (TREE_TYPE (arg0))
|| !TYPE_OVERFLOW_WRAPS (TREE_TYPE (arg1)))
(ex_form == PLUS_EXPR
- || ex_form == MINUS_EXPR)))
+ || ex_form == MINUS_EXPR
+ || ex_form == MULT_EXPR)))
typex = unsigned_type_for (typex);
else
typex = signed_type_for (typex);
fixes this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-07-06 10:35:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-06 10:39 --- What's the patch needed to trigger it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
[Bug target/44834] pr44707.c FAILs on sparc -m32: asm operand requires impossible reload
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-06 10:42 --- Guess sparc needs similar fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44834
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #5 from jv244 at cam dot ac dot uk 2010-07-06 11:32 --- I also checked the pgi and cray compilers, they all lead to iforts thread binding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug ada/44835] New: Ada Assert Failure with Bug Box, einfo.adb:1687
I was trying to learn OOP in Ada and ran into this Assert Box: $ gcc -c small.adb +===GNAT BUG DETECTED==+ | 4.4.4 20100503 (Red Hat 4.4.4-2) (x86_64-redhat-linux-gnu) Assert_Failure einfo.adb:1687| | Error detected at small.adb:33:7 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. small.adb list may be incomplete compilation abandoned My system: $ uname -a Linux localhost.localdomain 2.6.33.5-124.fc13.x86_64 #1 SMP Fri Jun 11 09:38:12 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/redhat-release Fedora release 13 (Goddard) $ rpm -qa | grep gnat gcc-gnat-4.4.4-2.fc13.x86_64 libgnat-4.4.4-2.fc13.x86_64 libgnat-devel-4.4.4-2.fc13.x86_64 $ gcc --version gcc (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2) I also tested on gcc 4.3.2 with the same result: +===GNAT BUG DETECTED==+ | 4.3.2 20081105 (Red Hat 4.3.2-7) (i386-redhat-linux-gnu) Assert_Failure einfo.adb:1698| | Error detected at small.adb:33:7 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ (Will upload small.adb when I find the upload button). -- Summary: Ada Assert Failure with Bug Box, einfo.adb:1687 Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bileam at gmail dot com GCC host triplet: x86_64-redhat-linux-gnu GCC target triplet: x86_64-redhat-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44835
[Bug ada/44835] Ada Assert Failure with Bug Box, einfo.adb:1687
--- Comment #1 from bileam at gmail dot com 2010-07-06 11:41 --- Created an attachment (id=21102) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21102action=view) small.adb that triggers assert box. Example program, trigger this bug with a simple gcc -c small.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44835
[Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
--- Comment #5 from hubicka at ucw dot cz 2010-07-06 11:41 --- Subject: Re: Mozilla build ICE at Invalid first operand of MEM_REF. What's the patch needed to trigger it? The DECL_BY_REFERENCE change. THe one I sent to list should be enough. So if you could look into it, it would be great. On Mozilla this gimplify trick works, but later it causes different ICE. Here regimplification splits var = fncall () into tmp.ssa_ver =fncall () var = tmp.ssa_ver that is completely wrong since type of tmp is aggregate and we die later checking SSA form. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
[Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
--- Comment #6 from rguenther at suse dot de 2010-07-06 11:45 --- Subject: Re: Mozilla build ICE at Invalid first operand of MEM_REF. On Tue, 6 Jul 2010, hubicka at ucw dot cz wrote: --- Comment #5 from hubicka at ucw dot cz 2010-07-06 11:41 --- Subject: Re: Mozilla build ICE at Invalid first operand of MEM_REF. What's the patch needed to trigger it? The DECL_BY_REFERENCE change. THe one I sent to list should be enough. So if you could look into it, it would be great. On Mozilla this gimplify trick works, but later it causes different ICE. Here regimplification splits var = fncall () into tmp.ssa_ver =fncall () var = tmp.ssa_ver that is completely wrong since type of tmp is aggregate and we die later checking SSA form. Well, that sounds like caused by your needs_to_live_in_memory change. There is asymmetry wrt caller / callee and DECL_BY_REFERENCE handling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-06 11:46 --- I can't reproduce it with r161865. (on x86_64-linux with -m32) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|regression |middle-end Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
Re: [Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
Well, that sounds like caused by your needs_to_live_in_memory change. There is asymmetry wrt caller / callee and DECL_BY_REFERENCE handling. Hmm, what kind of assymetry? Previously we special cased RESULT_DECL so it was forced to memory even if it was pointer, no we don't. So things should be more symemtric? Honza
[Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
--- Comment #7 from hubicka at ucw dot cz 2010-07-06 12:00 --- Subject: Re: Mozilla build ICE at Invalid first operand of MEM_REF. Well, that sounds like caused by your needs_to_live_in_memory change. There is asymmetry wrt caller / callee and DECL_BY_REFERENCE handling. Hmm, what kind of assymetry? Previously we special cased RESULT_DECL so it was forced to memory even if it was pointer, no we don't. So things should be more symemtric? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
[Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
--- Comment #8 from rguenther at suse dot de 2010-07-06 12:16 --- Subject: Re: Mozilla build ICE at Invalid first operand of MEM_REF. On Tue, 6 Jul 2010, hubicka at ucw dot cz wrote: --- Comment #7 from hubicka at ucw dot cz 2010-07-06 12:00 --- Subject: Re: Mozilla build ICE at Invalid first operand of MEM_REF. Well, that sounds like caused by your needs_to_live_in_memory change. There is asymmetry wrt caller / callee and DECL_BY_REFERENCE handling. Hmm, what kind of assymetry? Previously we special cased RESULT_DECL so it was forced to memory even if it was pointer, no we don't. So things should be more symemtric? On the caller side the result is typed as TREE_TYPE of the fn prototype, not as type of the callees RESULT_DECL. Thus, for a DELC_BY_REFERENCE RESULT_DECL (which then has reference type) we still see an aggregate on the caller side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
[Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-06 12:23 --- Reducing a testcase to look at it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
[Bug preprocessor/44836] New: Missing headers are always fatal
MySQL relied on the behavior fixed in PR15638 to implement a poor man's ABI check. By keeping a copy of the preprocessed output, it was somewhat possible to detect (via a diff) whether a change to some header might affect the ABI. MySQL headers are a bit convoluted, being used by client programs and the server itself. Although not entirely reliable, this behavior was quite useful for this purpose. Would it possible to somehow instruct cpp to continue even if a header is missing? Something along the lines of a -Wno-fatal-errors... or restore the behavior if cpp is invoked directly. -- Summary: Missing headers are always fatal Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davi dot arnaut at sun dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44836
[Bug preprocessor/44837] New: [4.5 regression?] strange #define behavior
I'm not really sure whether this is gcc bug or what but it used to work with
gcc 4.4.x and older.
Problem description:
I include ucontext.h which resides in /usr/include/sys/ucontext.h on my
system
this header contains (among others):
#ifdef __USE_GNU
enum
{
...
};
#endif
So to use this I need to #define __USE_GNU
But for some reason the preprocessor removes this part from included file like
the __USE_GNU was never defined. It happens no matter whether I define
__USE_GNU in source or on command line.
OS:
---
Arch Linux 64 bit
GCC version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr
--enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib
--disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info
Thread model: posix
gcc version 4.5.0 20100610 (prerelease) (GCC)
but I was able to reproduce it with the stable 4.5.0
--
Summary: [4.5 regression?] strange #define behavior
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: l dot jirkovsky at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug preprocessor/44837] [4.5 regression?] strange #define behavior
--- Comment #1 from l dot jirkovsky at gmail dot com 2010-07-06 12:51 --- Created an attachment (id=21103) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21103action=view) test file using definitions from the ucontext.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug preprocessor/44837] [4.5 regression?] strange #define behavior
--- Comment #2 from l dot jirkovsky at gmail dot com 2010-07-06 12:52 --- Created an attachment (id=21104) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21104action=view) ucontext.h from my system -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug preprocessor/44837] [4.5 regression?] strange #define behavior
--- Comment #3 from l dot jirkovsky at gmail dot com 2010-07-06 12:53 --- Created an attachment (id=21105) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21105action=view) preprocessed file missing __USE_GNU parts from ucontext.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug preprocessor/44837] [4.5 regression?] strange #define behavior
--- Comment #4 from l dot jirkovsky at gmail dot com 2010-07-06 12:55 --- The strange thing is that when I copy the problematic part (even with __USE_GNU) to a different file it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug lto/44724] LTO segfault with -fuse-linker-plugin
--- Comment #7 from moonshine at kapsi dot fi 2010-07-06 12:57 --- This issue is now fixed in trunk. I have no obligation to push it for 4.5 series as I am now able to build whole VICE successfully with 4.6 so I am closing the ticket. -- moonshine at kapsi dot fi changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44724
[Bug preprocessor/44837] [4.5 regression?] strange #define behavior
--- Comment #5 from redi at gcc dot gnu dot org 2010-07-06 12:58 --- You're not supposed to define __USE_GNU yourself, see features.h The macro you should define is _GNU_SOURCE, which causes glibc to define __USE_GNU -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug libgcj/35367] Linux x86 build (with --enable-targets=all, so also building with cross-to-x64 multilib configuration) fails in libjava (prims.cc)
--- Comment #2 from froydnj at gcc dot gnu dot org 2010-07-06 13:02 --- (In reply to comment #1) debian doesn't have all libraries needed as build dependencies as 64bit versions, so it's clear that the build fails. IMO not a GCC issue. This same error occurs on systems where a native x86-64 build works just fine (and builds libjava), so yes, it is a GCC issue. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-06 13:02:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35367
[Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-07-06 13:02
---
Reduced testcase:
typedef unsigned short PRUint16;
typedef PRUint16 PRUnichar;
template class CharT struct nsCharTraits {
};
class nsAString_internal {
public:
typedef PRUnichar char_type;
};
class nsString : public nsAString_internal {
public:
typedef nsString self_type;
nsString( const self_type str );
};
class nsDependentString : public nsString {
public:
explicit nsDependentString( const char_type* data );
};
typedef struct sqlite3_stmt sqlite3_stmt;
const void *sqlite3_column_text16(sqlite3_stmt*, int iCol);
class nsIVariant { };
template typename DataType struct variant_storage_traits {
typedef DataType ConstructorType;
typedef DataType StorageType;
static inline StorageType storage_conversion(ConstructorType aData) {
return aData;
}
};
template typename DataType class Variant : public nsIVariant {
public:
Variant(typename variant_storage_traitsDataType::ConstructorType aData)
: mData(variant_storage_traitsDataType::storage_conversion(aData)) {}
typename variant_storage_traitsDataType::StorageType mData;
};
typedef VariantnsString TextVariant;
class Row {
void initialize(sqlite3_stmt *aStatement);
};
void Row::initialize(sqlite3_stmt *aStatement)
{
nsDependentString str(static_castconst PRUnichar
*(::sqlite3_column_text16(aStatement, 0)));
new TextVariant(str);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
[Bug preprocessor/44837] [4.5 regression?] strange #define behavior
--- Comment #6 from redi at gcc dot gnu dot org 2010-07-06 13:03 --- Also, I don't think the change you're seeing can be from GCC, since features.h unconditionally does #undef __USE_GNU Did you upgrade glibc at the same time as gcc? In any case, you should use the documented interface, not __USE_GNU -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug preprocessor/44837] [4.5 regression?] strange #define behavior
--- Comment #7 from l dot jirkovsky at gmail dot com 2010-07-06 13:11 --- Oh, sorry. It was a part of source from rawstudio which used to work correctly but since update to gcc 4.5.0 compilation fails. It took me some time to find where the problem is and I found this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug preprocessor/44837] [4.5 regression?] strange #define behavior
--- Comment #8 from l dot jirkovsky at gmail dot com 2010-07-06 13:12 --- BTW: thank you for enlightening me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug bootstrap/44832] --enable-build-with-cxx Bootstrap comparison failure
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-07-06 13:18 --- Created an attachment (id=21106) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21106action=view) i386.c preprocessed source /user/inria/fsf/161802/bld-1/./prev-gcc/cc1plus -fpreprocessed i386.ii -quiet -dumpbase i386.c -mtune=generic -march=pentiumpro -auxbase-strip i386.o -g -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -version -fomit-frame-pointer -fno-common -o i386.s /user/inria/fsf/161802/bld-1/./prev-gcc/cc1plus -fpreprocessed i386.ii -quiet -dumpbase i386.c -mtune=generic -march=pentiumpro -auxbase-strip i386.o -g -gtoggle -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -version -fomit-frame-pointer -fno-common -o i386g.s [amyl...@laria gcc]$ diff -pU1 '-F^[_a-zA-Z]' i386.s i386g.s|grep -A 10 -B 10 '^[+-].*[0-9](%esp' - .loc 2 27855 0 movzbl mode_nunits(%ebx), %esi - .loc 2 27854 0 movzbl mode_inner(%ebx), %edx - .loc 2 27858 0 movl$0, (%esp) - .loc 2 27856 0 shrb$2, %al movzbl %al, %eax - .loc 2 27854 0 - movl%edx, 64(%esp) -.LVL8487: - .loc 2 27857 0 + movl%edx, 60(%esp) movl%esi, %edx -.LVL8488: - .loc 2 27856 0 movl%eax, 48(%esp) -.LVL8489: - .loc 2 27857 0 sarl$31, %edx movl%esi, %eax -.LVL8490: idivl 48(%esp) - .loc 2 27858 0 - movl64(%esp), %edx - .loc 2 27857 0 + movl60(%esp), %edx movl%eax, %esi -.LVL8491: - .loc 2 27858 0 movzbl mode_size(%edx), %eax -.LVL8492: sall$3, %eax @@ -103335,12 +62102,5 @@ _ZL31ix86_expand_vector_init_generalb12m movl%eax, 72(%esp) -.LVL8493: -.LBB13227: -- -.LBB13224: -.LBB13226: -.LBB13238: -.LBB13237: -.LBB13231: - .loc 2 27770 0 leal-1(%ecx), %edx - .loc 2 27867 0 xorl%ebx, %ebx - .loc 2 27770 0 - movl%edx, 60(%esp) - .loc 2 27866 0 + movl%edx, 64(%esp) movl256(%esp), %edx -.LBE13231: - .loc 2 27864 0 addl$1, %ebx -.LBB13232: - .loc 2 27867 0 movl$1, 12(%esp) - .loc 2 27866 0 movl%edi, 52(%esp) movl(%edx), %eax - .loc 2 27867 0 - movl60(%esp), %edx + movl64(%esp), %edx movl4(%eax,%edx,4), %eax @@ -103584,3 +62233,3 @@ _ZL31ix86_expand_vector_init_generalb12m movl%eax, 8(%esp) - movl64(%esp), %eax + movl60(%esp), %eax movl%eax, 4(%esp) @@ -103589,32 +62238,13 @@ _ZL31ix86_expand_vector_init_generalb12m call_Z13convert_modes12machine_modeS_P7rtx_defi -.LBE13232: - .loc 2 27864 0 cmpl%ebx, %esi movl40(%esp), %ecx -.LBB13233: - .loc 2 27867 0 movl%eax, %ebp -- .L8384: -.LBB13234: - .loc 2 27866 0 movl256(%esp), %edx - .loc 2 27867 0 movl$1, 12(%esp) - .loc 2 27866 0 movl(%edx), %eax -.LVL8522: - .loc 2 27770 0 - movl60(%esp), %edx + movl64(%esp), %edx subl%ebx, %edx -.LBE13234: - .loc 2 27864 0 addl$1, %ebx -.LVL8523: -.LBB13235: - .loc 2 27867 0 movl4(%eax,%edx,4), %eax @@ -103622,3 +62252,3 @@ _ZL31ix86_expand_vector_init_generalb12m movl%eax, 8(%esp) - movl64(%esp), %eax + movl60(%esp), %eax movl%eax, 4(%esp) @@ -103627,3 +62257,2 @@ _ZL31ix86_expand_vector_init_generalb12m call_Z13convert_modes12machine_modeS_P7rtx_defi - .loc 2 27874 0 movl%ebp, 16(%esp) @@ -103633,8 +62262,4 @@ _ZL31ix86_expand_vector_init_generalb12m movl$65, 4(%esp) - .loc 2 27867 0 movl%eax, %edx -.LVL8524: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug preprocessor/44837] [4.5 regression?] strange #define behavior
--- Comment #9 from redi at gcc dot gnu dot org 2010-07-06 13:21 --- then that's a bug in rawstudio, the relevant doc is http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
[Bug middle-end/44826] Mozilla build ICE at Invalid first operand of MEM_REF.
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-07-06 13:30
---
Index: tree-inline.c
===
--- tree-inline.c (revision 161865)
+++ tree-inline.c (working copy)
@@ -817,6 +817,12 @@ remap_gimple_op_r (tree *tp, int *walk_s
tree decl = TREE_OPERAND (*tp, 0);
tree *n;
+ /* See remap_ssa_name. */
+ if (TREE_CODE (decl) == SSA_NAME
+ TREE_CODE (SSA_NAME_VAR (decl)) == RESULT_DECL
+ id-transform_return_to_modify)
+ decl = SSA_NAME_VAR (decl);
+
n = (tree *) pointer_map_contains (id-decl_map, decl);
if (n)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
[Bug c/44828] possible integer wrong code bug
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-06 13:38 --- Subject: Bug 44828 Author: rguenth Date: Tue Jul 6 13:37:58 2010 New Revision: 161869 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161869 Log: 2010-07-06 Richard Guenther rguent...@suse.de PR middle-end/44828 * convert.c (convert_to_integer): Watch out for overflowing MULT_EXPR as well. * gcc.c-torture/execute/pr44828.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr44828.c Modified: trunk/gcc/ChangeLog trunk/gcc/convert.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug c/44828] [4.3/4.4/4.5 Regression] possible integer wrong code bug
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-06 13:40 --- Fixed on trunk. The problem is latent everywhere but the optimization doesn't happen for 4.2.4 or earlier. Which makes it a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.4 4.4.3 4.5.0 Known to work||4.2.4 4.6.0 Summary|possible integer wrong code |[4.3/4.4/4.5 Regression] |bug |possible integer wrong code ||bug Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug middle-end/44838] New: [4.6 regression] FAIL: gcc.dg/pr39794.c
On Linux/ia32, revision 161849 gave: FAIL: gcc.dg/pr39794.c execution test Revision 161840 is OK. -- Summary: [4.6 regression] FAIL: gcc.dg/pr39794.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=44838
[Bug middle-end/44839] New: [4.6 regression] FAIL: c-c++-common/uninit-17.c
On Linux/ia32, revision 161849 gave: FAIL: c-c++-common/uninit-17.c (test for warnings, line 14) FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for warnings, line 14) FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/uninit-17.c (test for excess errors) Revision 161840 is OK. -- Summary: [4.6 regression] FAIL: c-c++-common/uninit-17.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=44839
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-06 14:09 --- Reverting up to r161801 still gets me ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug g++: error: ii386.i: -fcompare-debug failure (length) so it wasn't r161802. -fcompare-debug does not fail on the 4.5 branch with that testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|bootstrap |debug Ever Confirmed|0 |1 Keywords||build Last reconfirmed|-00-00 00:00:00 |2010-07-06 14:09:00 date|| Summary|--enable-build-with-cxx |[4.6 Regression] -fcompare- |Bootstrap comparison failure|debug failure for C++ i386.c Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug c/44828] [4.3/4.4/4.5 Regression] possible integer wrong code bug
--- Comment #6 from regehr at cs dot utah dot edu 2010-07-06 14:10 --- (In reply to comment #2) Not sure whether the testcase is valid or not. The multiplication using char variables on both sides (and likewise for result) is: -54 * -56 (= 3024), but (char) 3024 is -48. For int that would be clear undefined behavior, but for char the multiplication is promoted to int, so it is (char) (int * int). My students and I had to argue about this and read the standard before submitting this bug report. But I'm almost certain the testcase is valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug middle-end/44839] [4.6 regression] FAIL: c-c++-common/uninit-17.c
--- Comment #1 from paolo dot carlini at oracle dot com 2010-07-06 14:13 --- Don't we have middle-end/44738 for this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44839
[Bug c++/44840] New: bug in STL iterator class
This is not a compiler bug, but a bug in the STL iterator class.
The less-than-operator does not work properly.
The following program can reproduce the bug.
# include iostream
# include vector
using namespace std;
main() {
vectorint v;
vectorint::iterator i = v.begin();
--i;
cout ( i - v.begin() ) endl; // output: -1
cout ( i v.begin() ) endl; // output: 0 !!! SHOULD BE 1 !!!
cout ( i - v.begin() 0) endl; // output: 1 this one is correct
}
--
Summary: bug in STL iterator class
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andre dot bergner dot 0 at googlemail dot com
GCC build triplet: -
GCC host triplet: -
GCC target triplet: -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44840
[Bug middle-end/44790] [4.6 Regression] Bootstrap fails after MEM-REF merge
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Bootstrap fails after MEM- |[4.6 Regression] Bootstrap |REF merge |fails after MEM-REF merge Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44790
[Bug middle-end/44839] [4.6 regression] FAIL: c-c++-common/uninit-17.c
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-06 14:28 --- (In reply to comment #1) Don't we have middle-end/44738 for this? They didn't fail for me on 32bit hosts before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44839
Re: [Bug c++/44840] New: bug in STL iterator class
On Jul 6, 2010, at 7:21 AM, andre dot bergner dot 0 at googlemail dot
com gcc-bugzi...@gcc.gnu.org wrote:
This is not a compiler bug, but a bug in the STL iterator class.
The less-than-operator does not work properly.
The following program can reproduce the bug.
# include iostream
# include vector
using namespace std;
main() {
vectorint v;
vectorint::iterator i = v.begin();
--i;
I think the behavior is undefined because now i is not inside the
vector at all. In fact I think doing --i on an iterator at the
begining is undefined.
cout ( i - v.begin() ) endl; // output: -1
cout ( i v.begin() ) endl; // output: 0 !!! SHOULD BE
1 !!!
cout ( i - v.begin() 0) endl; // output: 1 this one is
correct
}
--
Summary: bug in STL iterator class
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andre dot bergner dot 0 at googlemail dot com
GCC build triplet: -
GCC host triplet: -
GCC target triplet: -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44840
[Bug c++/44840] bug in STL iterator class
--- Comment #1 from pinskia at gmail dot com 2010-07-06 14:40 ---
Subject: Re: New: bug in STL iterator class
On Jul 6, 2010, at 7:21 AM, andre dot bergner dot 0 at googlemail dot
com gcc-bugzi...@gcc.gnu.org wrote:
This is not a compiler bug, but a bug in the STL iterator class.
The less-than-operator does not work properly.
The following program can reproduce the bug.
# include iostream
# include vector
using namespace std;
main() {
vectorint v;
vectorint::iterator i = v.begin();
--i;
I think the behavior is undefined because now i is not inside the
vector at all. In fact I think doing --i on an iterator at the
begining is undefined.
cout ( i - v.begin() ) endl; // output: -1
cout ( i v.begin() ) endl; // output: 0 !!! SHOULD BE
1 !!!
cout ( i - v.begin() 0) endl; // output: 1 this one is
correct
}
--
Summary: bug in STL iterator class
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andre dot bergner dot 0 at googlemail dot com
GCC build triplet: -
GCC host triplet: -
GCC target triplet: -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44840
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44840
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-07-06 14:42 --- (In reply to comment #4) Reverting up to r161801 still gets me ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug g++: error: ii386.i: -fcompare-debug failure (length) so it wasn't r161802. Is this command supposed to also give sane results on i686-pc-linux-gnu? Even when I try this with r161600, it says there is a length failure. But when I make cc1plus create actual assembly files and assemble / strip them, the resulting object files compare equal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-07-06 14:51 --- (In reply to comment #4) Reverting up to r161801 still gets me ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug I've tried this with --save-temps in r161600 and there's lots of differences in the dump files regarding numbers that won't appear in the output file. So this is a much stricter comparison check than what we do during bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #14 from burnus at gcc dot gnu dot org 2010-07-06 14:57 --- Created an attachment (id=21107) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21107action=view) Draft patch -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug c++/44841] New: Add suggestion to undefined reference to `vtable for ...�
It was today that I stumbled over the seemingly simple situation of tweaking
some bits of an interface class.
Upon doing that, I got an undefined reference to a vtable.
I made clean and made my application. Nothing changed. Then I checked again the
interface and didn't find anything. Then I checked all derivations. Nothing.
Of course it was just me who has been a fool for not recognising a missing
character-tuple = 0 behind a function signature, as in:
struct IFoo {
virtual ~IFoo() {}
virtual void frob (); // -- missing pure specifier
};
struct Foo : IFoo { virtual void frob () {} };
int main () {
IFoo *f = new Foo();
f-frob();
delete f;
}
The exact error message was
undefined reference to `vtable for IFoo'
As this costed me a not irrelevant amount of time, and I wouldn't describe me
as unexperienced, my proposal would be to add a suggestion in case of undefined
vtable, in the spirit of
undefined reference to `vtable for IFoo'
Suggestions:
* Ensure that no (pure) member function of `IFoo' became unintentionally
non-pure because of a missing or deleted `= 0'
* Ensure that all non-pure member functions are defined *and* linked
Of course there exist more reasons for such vtable errors, but I think it can
already improve productivity to just enumerate the most common mistakes.
Of course I learned my lesson for now, but probably I'll forget it again in
some months, and then, undefined reference to `vtable for IFoo' alone will
again not be of much help, as described in the introduction to this report.
--
Summary: Add suggestion to undefined reference to `vtable for
...´
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phresnel at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44841
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-07-06 15:03 --- (In reply to comment #4) ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug Works with g++ (GCC) 4.6.0 20100613 (experimental), fails with g++ (GCC) 4.6.0 20100617 (experimental). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug c++/44840] bug in STL iterator class
--- Comment #2 from paolo dot carlini at oracle dot com 2010-07-06 15:04 --- For sure. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44840
[Bug middle-end/44839] [4.6 regression] FAIL: c-c++-common/uninit-17.c
--- Comment #3 from paolo dot carlini at oracle dot com 2010-07-06 15:06 --- Bah, I would commonize these two bugs anyway, really that testcase is badly broken essentially everywhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44839
[Bug c/44842] New: gcc should not issue warnings for code that will never be executed
GCC issues warnings like division by zero or right shift count = width of
type even though the corresponding code will never be executed (under a
condition that is always false); it shouldn't do this, at least by default. For
instance:
int tst (void)
{
int x;
x = 0 ? 1 / 0 : 0;
return x;
if (0)
{
x = 1 / 0;
x = 1 128;
}
return x;
}
$ gcc-snapshot -std=c99 -O2 -c tst.c
tst.c: In function 'tst':
tst.c:8:13: warning: division by zero [-Wdiv-by-zero]
tst.c:9:7: warning: right shift count = width of type [enabled by default]
One can see that GCC detects neither the first return x; nor the always-false
condition, and issues spurious warnings for the lines:
x = 1 / 0;
x = 1 128;
On the other hand, GCC could successfully detect that the 1 / 0 in
x = 0 ? 1 / 0 : 0;
would never be executed.
Note: always-false conditions occur in practice for platform-dependent code,
e.g. by doing a test on integer types.
--
Summary: gcc should not issue warnings for code that will never
be executed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
[Bug fortran/44596] [OOP] Dynamic dispatch uses broken types
--- Comment #18 from burnus at gcc dot gnu dot org 2010-07-06 15:20 --- Paul, thanks for the check in. Do you plan to backport it to 4.5, which sems to use the same code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
[Bug middle-end/44838] [4.6 regression] FAIL: gcc.dg/pr39794.c
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-06 15:21 --- It is caused by revision 161844: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00198.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||sandra at codesourcery dot ||com Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #3 from jojelino at gmail dot com 2010-07-06 15:26 --- Created an attachment (id=21108) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21108action=view) another testcase Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.6.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --prefix=/usr --disable-win32-registry --enable-threads=posix --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-languages=c,c++ --no-create --no-recursion Thread model: posix gcc version 4.6.0 20100706 (experimental) (GCC) COLLECT_GCC_OPTIONS='-O2' '-I.' '-I.' '-I./common' '-I./config' '-DLOCALEDIR=/usr/share/locale' '-DHAVE_CONFIG_H' '-I./../include/opcode' '-I./../opcodes/..' '-I./../readline/..' '-I../bfd' '-I./../bfd' '-I./../include' '-I../libdecnumber' '-I./../libdecnumber' '-I./gnulib' '-Ignulib' '-DMI_OUT=1' '-DTUI=1' '-I/usr/include' '-I/usr/include' '-Wall' '-Wdeclaration-after-statement' '-Wpointer-arith' '-Wformat-nonliteral' '-Wno-pointer-sign' '-Wno-unused' '-Wunused-value' '-Wunused-function' '-Wno-switch' '-Wno-char-subscripts' '-c' '-o' 'python.o' '-MT' 'python.o' '-MMD' '-MP' '-MF' '.deps/python.Tpo' '-fno-strict-aliasing' '-DNDEBUG' '-fwrapv' '-save-temps' '-v' '-mtune=generic' '-march=pentiumpro' /usr/libexec/gcc/i686-pc-cygwin/4.6.0/cc1.exe -E -quiet -v -I. -I. -I./common -I./config -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib -Ignulib -I/usr/include -I/usr/include -MMD python.d -MF .deps/python.Tpo -MP -MT python.o -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../../include/w32api -DLOCALEDIR=/usr/share/locale -DHAVE_CONFIG_H -DMI_OUT=1 -DTUI=1 -DNDEBUG ./python/python.c -mtune=generic -march=pentiumpro -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -fno-strict-aliasing -fwrapv -O2 -fpch-preprocess -o python.i ignoring duplicate directory /usr/include ignoring duplicate directory /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../../include/w32api ignoring duplicate directory . ignoring duplicate directory ./../readline/.. ignoring duplicate directory ./../bfd ignoring duplicate directory ./../libdecnumber ignoring duplicate directory gnulib ignoring duplicate directory /usr/include as it is a non-system directory that duplicates a system directory ignoring duplicate directory /usr/include as it is a non-system directory that duplicates a system directory #include ... search starts here: #include ... search starts here: . ./common ./config ./../include/opcode ./../opcodes/.. ../bfd ./../include ../libdecnumber ./gnulib /usr/local/include /usr/lib/gcc/i686-pc-cygwin/4.6.0/include /usr/lib/gcc/i686-pc-cygwin/4.6.0/include-fixed /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/include /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../include/w32api End of search list. COLLECT_GCC_OPTIONS='-O2' '-I.' '-I.' '-I./common' '-I./config' '-DLOCALEDIR=/usr/share/locale' '-DHAVE_CONFIG_H' '-I./../include/opcode' '-I./../opcodes/..' '-I./../readline/..' '-I../bfd' '-I./../bfd' '-I./../include' '-I../libdecnumber' '-I./../libdecnumber' '-I./gnulib' '-Ignulib' '-DMI_OUT=1' '-DTUI=1' '-I/usr/include' '-I/usr/include' '-Wall' '-Wdeclaration-after-statement' '-Wpointer-arith' '-Wformat-nonliteral' '-Wno-pointer-sign' '-Wno-unused' '-Wunused-value' '-Wunused-function' '-Wno-switch' '-Wno-char-subscripts' '-c' '-o' 'python.o' '-MT' 'python.o' '-MMD' '-MP' '-MF' '.deps/python.Tpo' '-fno-strict-aliasing' '-DNDEBUG' '-fwrapv' '-save-temps' '-v' '-mtune=generic' '-march=pentiumpro' /usr/libexec/gcc/i686-pc-cygwin/4.6.0/cc1.exe -fpreprocessed python.i -quiet -dumpbase python.c -mtune=generic -march=pentiumpro -auxbase-strip python.o -O2 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -version -fno-strict-aliasing -fwrapv -o python.s GNU C (GCC) version 4.6.0 20100706 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.6.0 20100705 (experimental), GMP version 5.0.0, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.6.0 20100706 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.6.0 20100705 (experimental), GMP version 5.0.0, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 4d7e4dee7aec4de4bc97bcb7391f1265 ./python
[Bug c++/44841] Add suggestion to undefined reference to `vtable for ...�
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-06 15:26 --- (In reply to comment #0) undefined reference to `vtable for IFoo' Suggestions: * Ensure that no (pure) member function of `IFoo' became unintentionally non-pure because of a missing or deleted `= 0' While I think adding a note would be helpful, the suggestion above is ridiculous. It certainly shouldn't be the first suggestion. The answer is to ensure the first, non-inline virtual function is defined. That's it. Suggestions about unintentionally becoming non-pure would cause more confusion than they would help. However, the error comes from the linker, so there's nothing gcc can do about it when compiling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44841
[Bug fortran/44596] [OOP] Dynamic dispatch uses broken types
--- Comment #19 from paul dot richard dot thomas at gmail dot com 2010-07-06 15:28 --- Subject: Re: [OOP] Dynamic dispatch uses broken types Dear Tobias, Paul, thanks for the check in. Do you plan to backport it to 4.5, which sems to use the same code? Yes, I could do that on Thursday, when I am back in Barcelona. I do not have 4.5 on the laptop. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #4 from jojelino at gmail dot com 2010-07-06 15:38 --- Created an attachment (id=21109) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21109action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #5 from jojelino at gmail dot com 2010-07-06 15:39 --- Created an attachment (id=21110) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21110action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #6 from jojelino at gmail dot com 2010-07-06 15:40 --- Created an attachment (id=2) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=2action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #7 from jojelino at gmail dot com 2010-07-06 15:41 --- Created an attachment (id=21112) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21112action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug fortran/24524] Fortran dependency checking should reverse loops
--- Comment #3 from pault at gcc dot gnu dot org 2010-07-06 15:42 --- Created an attachment (id=21113) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21113action=view) Fix for the PR This version fixes the problem with channel.f90 and has cleaned-up/extra comments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24524
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #8 from jojelino at gmail dot com 2010-07-06 15:44 --- and error messages combined gcc -O2 -I. -I. -I./common -I./config -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib -Ignulib -DMI_OUT=1 -DTUI=1 -I/usr/include -I/usr/include -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -c -o python.o -MT python.o -MMD -MP -MF .deps/python.Tpo -fno-strict-aliasing -DNDEBUG -fwrapv ./python/python.c ./python/python.c: In function gdbpy_parameter_value: ./python/python.c:896:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_TrueStruct]; # VUSE .MEM_46(D) D.26034_13 = MEM[(struct PyObject *)_Py_TrueStruct].ob_refcnt; ./python/python.c:896:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_TrueStruct]; # .MEM_49 = VDEF .MEM_46(D) MEM[(struct PyObject *)_Py_TrueStruct].ob_refcnt = D.26035_14; ./python/python.c:896:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_ZeroStruct]; # VUSE .MEM_46(D) D.26037_17 = MEM[(struct PyObject *)_Py_ZeroStruct].ob_refcnt; ./python/python.c:896:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_ZeroStruct]; # .MEM_50 = VDEF .MEM_46(D) MEM[(struct PyObject *)_Py_ZeroStruct].ob_refcnt = D.26038_18; ./python/python.c:896:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_TrueStruct]; # VUSE .MEM_46(D) D.26034_22 = MEM[(struct PyObject *)_Py_TrueStruct].ob_refcnt; ./python/python.c:896:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_TrueStruct]; # .MEM_51 = VDEF .MEM_46(D) MEM[(struct PyObject *)_Py_TrueStruct].ob_refcnt = D.26035_23; ./python/python.c:896:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_ZeroStruct]; # VUSE .MEM_46(D) D.26037_26 = MEM[(struct PyObject *)_Py_ZeroStruct].ob_refcnt; ./python/python.c:896:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_ZeroStruct]; # .MEM_52 = VDEF .MEM_46(D) MEM[(struct PyObject *)_Py_ZeroStruct].ob_refcnt = D.26038_27; ./python/python.c:896:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: [python.o] Error 1 (ignored) gcc -O2 -I. -I. -I./common -I./config -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib -Ignulib -DMI_OUT=1 -DTUI=1 -I/usr/include -I/usr/include -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -c -o py-breakpoint.o -MT py-breakpoint.o -MMD -MP -MF .deps/py-breakpoint.Tpo -fno-strict-aliasing -DNDEBUG -fwrapv ./python/py-breakpoint.c ./python/py-breakpoint.c: In function bppy_is_valid: ./python/py-breakpoint.c:862:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_TrueStruct]; # VUSE .MEM_13(D) D.25525_6 = MEM[(struct PyObject *)_Py_TrueStruct].ob_refcnt; ./python/py-breakpoint.c:862:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_TrueStruct]; # .MEM_14 = VDEF .MEM_13(D) MEM[(struct PyObject *)_Py_TrueStruct].ob_refcnt = D.25526_7; ./python/py-breakpoint.c:862:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_ZeroStruct]; # VUSE .MEM_13(D) D.25528_10 = MEM[(struct PyObject *)_Py_ZeroStruct].ob_refcnt; ./python/py-breakpoint.c:862:1: error: Invalid address operand in MEM_REF. MEM[(struct PyObject *)_Py_ZeroStruct]; # .MEM_15 = VDEF .MEM_13(D) MEM[(struct PyObject *)_Py_ZeroStruct].ob_refcnt = D.25529_11; ./python/py-breakpoint.c:862:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: [py-breakpoint.o] Error 1 (ignored) mv: cannot stat `.deps/py-breakpoint.Tpo': No such file or directory make[2]: [py-breakpoint.o] Error 1 (ignored) gcc -O2 -I. -I. -I./common -I./config -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib -Ignulib -DMI_OUT=1 -DTUI=1 -I/usr/include -I/usr/include -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -c -o py-frame.o -MT py-frame.o -MMD -MP -MF .deps/py-frame.Tpo -fno-strict-aliasing -DNDEBUG -fwrapv ./python/py-frame.c ./python/py-frame.c: In function
[Bug c++/44841] Add suggestion to undefined reference to `vtable for ...�
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-06 15:47 --- *** This bug has been marked as a duplicate of 42540 *** -- 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=44841
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-07-06 15:47 --- *** Bug 44841 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||phresnel at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #9 from jojelino at gmail dot com 2010-07-06 15:50 --- and gcc revision is 161868 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug middle-end/44838] [4.6 regression] FAIL: gcc.dg/pr39794.c
--- Comment #2 from sandra at codesourcery dot com 2010-07-06 15:57 --- s/caused by/exposed by/ ? The patch to ivopts likely results in it selecting a different/smaller set of loop induction variables, but I don't see how this change by itself could have introduced a wrong-code error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug lto/44195] [4.6 regression] gcc.dg/lto/20100518 c_lto_20100518_0.o
--- Comment #3 from bergner at gcc dot gnu dot org 2010-07-06 16:09 --- Subject: Bug 44195 Author: bergner Date: Tue Jul 6 16:09:13 2010 New Revision: 161872 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161872 Log: PR testsuite/44195 * gcc.dg/lto/20100518_0.c: Limit to x86. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/lto/20100518_0.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44195
[Bug c++/44810] [4.6 Regression] FAIL: g++.dg/torture/pr36745.C
--- Comment #2 from mikpe at it dot uu dot se 2010-07-06 16:17 --- This new FAIL of pr36745.C since r161655 is also seen on sparc64, ia64, arm, and alpha. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44810
Re: [Bug c/44842] New: gcc should not issue warnings for code that will never be executed
This is a dup of a much older bug which I cannot find right now.
On Jul 6, 2010, at 8:10 AM, vincent at vinc17 dot org gcc-bugzi...@gcc.gnu.org
wrote:
GCC issues warnings like division by zero or right shift count =
width of
type even though the corresponding code will never be executed
(under a
condition that is always false); it shouldn't do this, at least by
default. For
instance:
int tst (void)
{
int x;
x = 0 ? 1 / 0 : 0;
return x;
if (0)
{
x = 1 / 0;
x = 1 128;
}
return x;
}
$ gcc-snapshot -std=c99 -O2 -c tst.c
tst.c: In function 'tst':
tst.c:8:13: warning: division by zero [-Wdiv-by-zero]
tst.c:9:7: warning: right shift count = width of type [enabled by
default]
One can see that GCC detects neither the first return x; nor the
always-false
condition, and issues spurious warnings for the lines:
x = 1 / 0;
x = 1 128;
On the other hand, GCC could successfully detect that the 1 / 0 in
x = 0 ? 1 / 0 : 0;
would never be executed.
Note: always-false conditions occur in practice for platform-
dependent code,
e.g. by doing a test on integer types.
--
Summary: gcc should not issue warnings for code that will
never
be executed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
[Bug c/44842] gcc should not issue warnings for code that will never be executed
--- Comment #1 from pinskia at gmail dot com 2010-07-06 16:33 ---
Subject: Re: New: gcc should not issue warnings for code that will never be
executed
This is a dup of a much older bug which I cannot find right now.
On Jul 6, 2010, at 8:10 AM, vincent at vinc17 dot org
gcc-bugzi...@gcc.gnu.org
wrote:
GCC issues warnings like division by zero or right shift count =
width of
type even though the corresponding code will never be executed
(under a
condition that is always false); it shouldn't do this, at least by
default. For
instance:
int tst (void)
{
int x;
x = 0 ? 1 / 0 : 0;
return x;
if (0)
{
x = 1 / 0;
x = 1 128;
}
return x;
}
$ gcc-snapshot -std=c99 -O2 -c tst.c
tst.c: In function 'tst':
tst.c:8:13: warning: division by zero [-Wdiv-by-zero]
tst.c:9:7: warning: right shift count = width of type [enabled by
default]
One can see that GCC detects neither the first return x; nor the
always-false
condition, and issues spurious warnings for the lines:
x = 1 / 0;
x = 1 128;
On the other hand, GCC could successfully detect that the 1 / 0 in
x = 0 ? 1 / 0 : 0;
would never be executed.
Note: always-false conditions occur in practice for platform-
dependent code,
e.g. by doing a test on integer types.
--
Summary: gcc should not issue warnings for code that will
never
be executed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
[Bug middle-end/44790] [4.6 Regression] Bootstrap fails after MEM-REF merge
--- Comment #3 from sje at cup dot hp dot com 2010-07-06 16:44 ---
The neccessary UNSPEC seems to be there if you trace the instructions back
far enough. I tried it on my test case and it worked. I am now testing the
patch on ToT to see if I can bootstrap. I also have to turn off partial
inlining to get bootstrap to work on ia64-hp-hpux11.23. I tweaked the patch
for ToT there are a bunch of changes to expr.c including setting base so the
patch I am currently testing with r161861 looks like this:
Index: expr.c
===
--- expr.c (revision 161861)
+++ expr.c (working copy)
@@ -8777,13 +8777,11 @@ expand_expr_real_1 (tree exp, rtx target
base = build2 (BIT_AND_EXPR, TREE_TYPE (base),
gimple_assign_rhs1 (def_stmt),
gimple_assign_rhs2 (def_stmt));
- op0 = expand_expr (base, NULL_RTX, address_mode, EXPAND_NORMAL);
if (!integer_zerop (TREE_OPERAND (exp, 1)))
- {
- rtx off;
- off = immed_double_int_const (mem_ref_offset (exp), address_mode);
- op0 = simplify_gen_binary (PLUS, address_mode, op0, off);
- }
+ base = build2 (POINTER_PLUS_EXPR, TREE_TYPE (base),
+base, double_int_to_tree (sizetype,
+ mem_ref_offset (exp)));
+ op0 = expand_expr (base, NULL_RTX, address_mode, EXPAND_SUM);
op0 = memory_address_addr_space (mode, op0, as);
temp = gen_rtx_MEM (mode, op0);
set_mem_attributes (temp, exp, 0);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44790
[Bug middle-end/44843] New: [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
Between 20100628 and 20100705, all 32-bit Fortran execution tests started to FAIL on Solaris 2. E.g. achar_1.exe: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xff301d98 in *_gfortrani_free_format_hash_table (u=value optimized out) at /vol/gcc/src/hg/trunk/solaris/libgfortran/io/format.c:91 (gdb) where #0 0xff301d98 in *_gfortrani_free_format_hash_table (u=value optimized out) at /vol/gcc/src/hg/trunk/solaris/libgfortran/io/format.c:91 #1 0xff3132dc in close_unit_1 (u=0x21ca0, locked=1) at /vol/gcc/src/hg/trunk/solaris/libgfortran/io/unit.c:650 #2 0xff3135bc in *_gfortrani_close_units () at /vol/gcc/src/hg/trunk/solaris/libgfortran/io/unit.c:697 #3 0xff292084 in cleanup () at /vol/gcc/src/hg/trunk/solaris/libgfortran/runtime/main.c:180 #4 0xff28d5d4 in __do_global_dtors_aux () from ../../../sparc-sun-solaris2.10/libgfortran/.libs/libgfortran.so.3 #5 0xff28d54c in _fini () from ../../../sparc-sun-solaris2.10/libgfortran/.libs/libgfortran.so.3 #6 0xff3c589c in call_fini () from /usr/lib/ld.so.1 #7 0xff3c5a6c in atexit_fini () from /usr/lib/ld.so.1 #8 0xff0421ac in _exithandle () from /lib/libc.so.1 #9 0xff0305d8 in exit () from /lib/libc.so.1 #10 0x000105cc in _start () (gdb) (gdb) display/i $pc 1: x/i $pc = 0xff301d98 *_gfortrani_free_format_hash_table+32: clrx [ %i0 + 0xf0 ] (gdb) p/x $i0 $1 = 0x21cac but %i=+0xf0 isn't 8-byte aligned. Before, two separate clr insns were used instead. -- Summary: [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2* GCC host triplet: sparc-sun-solaris2* GCC target triplet: sparc-sun-solaris2* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug lto/44195] [4.6 regression] gcc.dg/lto/20100518 c_lto_20100518_0.o
--- Comment #4 from bergner at gcc dot gnu dot org 2010-07-06 16:57 --- Subject: Bug 44195 Author: bergner Date: Tue Jul 6 16:57:21 2010 New Revision: 161874 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161874 Log: Backport from mainline 2010-07-06 Peter Bergner berg...@vnet.ibm.com PR testsuite/44195 * gcc.dg/lto/20100518_0.c: Limit to x86. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/lto/20100518_0.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44195
[Bug middle-end/44838] [4.6 regression] FAIL: gcc.dg/pr39794.c
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-06 16:58 --- Caused by, or exposed by ... in both cases your responsibility to investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug lto/44195] [4.6 regression] gcc.dg/lto/20100518 c_lto_20100518_0.o
--- Comment #5 from bergner at gcc dot gnu dot org 2010-07-06 16:59 --- Fixed in trunk and the 4.5 branch. -- bergner at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44195
[Bug c/44842] gcc should not issue warnings for code that will never be executed
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-06 17:24 --- *** This bug has been marked as a duplicate of 4210 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
[Bug middle-end/4210] should not warning with dead code
--- Comment #21 from manu at gcc dot gnu dot org 2010-07-06 17:24 --- *** Bug 44842 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
[Bug middle-end/4210] should not warning with dead code
--- Comment #22 from manu at gcc dot gnu dot org 2010-07-06 17:28 --- The way Clang gets this right is to perform some very-fast bitmap common constant propagation in the FE. I personally think this would be helpful if implemented correctly, even if it slows down the FE a little. But do not wait for a fix soon because this is not trivial to fix and no one has both the desire and the free time to work on fixing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
[Bug c++/33801] Missing warning
--- Comment #3 from manu at gcc dot gnu dot org 2010-07-06 17:34 --- 3 years in waiting... I am closing this, we have too many real bugs open to worry about. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33801
[Bug c++/34039] [MInGW] -Werror does not trigger non zero exit code
--- Comment #5 from manu at gcc dot gnu dot org 2010-07-06 17:35 --- No feedback, unconfirmed, unreproducible, thus closing. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34039
[Bug other/32185] unused result warnings and -werror
--- Comment #6 from manu at gcc dot gnu dot org 2010-07-06 17:39 --- No duplicates in 3 years, no new feedback, closing this. Please reopen if necessary. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32185
[Bug target/44844] New: Wrong _rdrand_uXX intrinsic implementation
RDRAND instruction spec says:
Loads a hardware generated random value and store it in the destination
register. The size of the random value is determined by the destination
register size and operating mode. The Carry Flag indicates whether a random
value is available at the time the instruction is executed. CF=1 indicates
that the data in the destination is valid. Otherwise CF=0 and the data in
the destination operand will be returned as zeros for the specified width.
All other flags are forced to 0 in either situation. Software must check
the state of CF=1 for determining if a valid random value has been returned,
otherwise it is expected to loop and retry execution of RDRAND.
Gcc implemented:
[...@gnu-6 rdrand-1]$ cat rdrand-2.c
/* { dg-do compile } */
/* { dg-options -O2 -mrdrnd } */
/* { dg-final { scan-assembler rdrand\[ \t]+(%|)eax } } */
#include immintrin.h
unsigned int
read_rdrand32 (void)
{
return _rdrand_u32 ();
}
[...@gnu-6 rdrand-1]$ cat rdrand-2.s
.file rdrand-2.c
.text
.p2align 4,,15
.globl read_rdrand32
.type read_rdrand32, @function
read_rdrand32:
.LFB564:
.cfi_startproc
rdrand %eax
ret
.cfi_endproc
.LFE564:
.size read_rdrand32, .-read_rdrand32
.ident GCC: (GNU) 4.6.0 20100705 (experimental)
.section.note.GNU-stack,,@progbits
[...@gnu-6 rdrand-1]$
There is no loop to check CF=1.
--
Summary: Wrong _rdrand_uXX intrinsic implementation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
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=44844
[Bug middle-end/33654] Strange message + bad code generated for -fPIC -O3
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-06 17:41 --- Too large testcase, no feedback in 3 years, no clear report. Closing... -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33654
[Bug target/44844] Wrong _rdrand_uXX intrinsic implementation
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-06 17:46 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00462.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||07/msg00462.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44844
