| Summary: | [4.3 Regression] Canonical types failures | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Wolfgang Bangerth <bangerth> |
| Component: | c++ | Assignee: | dgregor |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bangerth, dgregor, fang, gcc-bugs, pinskia |
| Priority: | P3 | ||
| Version: | 4.3.0 | ||
| Target Milestone: | 4.3.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2007-04-09 10:39:33 | |
*** Bug 31506 has been marked as a duplicate of this bug. *** For some reason, bugzilla gives me an internal error when I try to attach the file. In any case, it is here: http://www.math.tamu.edu/~bangerth/step-27.ii.gz Reducing. I bet a beer that this is related to code like:
int a[] = {1,2};
The only reason I am saying that is because the last time I looked into a failure of giving the same aliasing set to int[] = {1,2} as int[2] was the same problem.
Reduced testcase (which makes I am correct):
template <int dim> struct Point
{
Point (const double x, const double y);
};
Point<2> f(void) {}
void create_coarse_grid () {
static const Point<2> vertices_1[]
= {
Point<2> (-1., -1.),
Point<2> (-1./2, -1.),
Point<2> (0., -1.),
Point<2> (+1./2, -1.)
};
}
=====================
If I change [] to [4] then it works.
This is clearly my bug, but I am not able to reproduce it on i686-pc-linux-gnu. Does the following patch fix the problem? http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00188.html If not, which platform are you seeing the problem on? (In reply to comment #6) > This is clearly my bug, but I am not able to reproduce it on i686-pc-linux-gnu. This was with r123617, on i686-pc-linux-gnu. I can reproduce with this version and Andrew's testcase, though only with -O2. Did you try it with this flag? W. (In reply to comment #6) > Does the following patch fix the problem? > > http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00188.html Yes. I think it would be good if you added Andrew's testcase to the patch as well, compiled with -O2. W. I can't reproduce this bug with r123671 on i686-pc-linux-gnu. However, since the above patch does fix the problem, I'll add this PR to the ChangeLog for that patch. Great, thanks. Hopefully someone approves the patch soon. Talking about canonical types: I think the idea of only issuing a warning in cases like the current one is a really bad idea. Warnings are meant for things where the programmer did something dubious (if correct) and that can be silenced by adjusting the source code. On the other hand, what we have here is a compiler whose internal data structures have become corrupted. That's pretty much the definition of what we use ICEs for, and I would urge you to reconsider the idea of using a warning instead. Does it matter? I do think so. For example, I found this one by actually looking at the log files of my automated compile jobs. It showed a successful compilation, rather than a failure, because a warning still makes 'make' go on as if nothing had happened. I'm sure canonical type failures would be found quicker if their effect was more drastic, because it makes people look for the place where something goes wrong. Best Wolfgang Subject: Re: [4.3 Regression] Canonical types failures "bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Talking about canonical types: I think the idea of only issuing a warning | in cases like the current one is a really bad idea. Fully agreed. I believe we discussed this on the main list. It should not be a warning. It should be an ICE. This is a compiler bug. That is what ICE is for. -- Gaby Yay to making it an ICE instead of a warning. Same problem/cause as 31103, which is now fixed on mainline. *** This bug has been marked as a duplicate of 31103 *** |
For the attached (unfortunately rather lengthy) file I finally managed to get a reproducible testcase that spews out several pages of canonical types warning messages when compiled with -O2 (but not with -O0): examples/step-27> /tmp/bangerth/bin/gcc-mainline/bin/g++ -c step-27.ii -O2 step-27.cc: In member function 'void LaplaceProblem<dim>::create_coarse_grid() [with int dim = 2]': step-27.cc:742: warning: same canonical type node for different types dealii::Point<2> [24] and const dealii::Point<2> [24] <array_type 0xb4cef8dc type <record_type 0xb7459bd0 Point sizes-gimplified addressable needs-constructing type_1 type_5 type_6 BLK size <integer_cst 0xb7d5e834 constant invariant 128> unit size <integer_cst 0xb7d5e850 constant invariant 16> align 32 symtab 0 alias set 147 canonical type 0xb7459bd0 fields <field_decl 0xb5f54a20 D.74077 type <record_type 0xb745472c Tensor> ignored decl_6 BLK file /tmp/bangerth/x/deal.II/base/include/base/tensor_base.h line 39 size <integer_cst 0xb7d5e834 128> unit size <integer_cst 0xb7d5e850 16> align 32 offset_align 128 offset <integer_cst 0xb7d5e444 constant invariant 0> bit offset <integer_cst 0xb7d5eb28 constant invariant 0> context <record_type 0xb7459bd0 Point> chain <type_decl 0xb5f8a438 Point>> context <namespace_decl 0xb7e25870 dealii> needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1 interface-unknown pointer_to_this <pointer_type 0xb5f8a510> reference_to_this <reference_type 0xb5f8e0d8> chain <type_decl 0xb7459c3c Point>> sizes-gimplified needs-constructing BLK ... I hope this helps to track a few things down. I have a couple of other files that show canonical types fail as well, but there the bug goes away once one uses -save-temps :-( Best Wolfgang