Re: [c++] switch ( enum ) vs. default statment.
Mark Mitchell wrote:
For GCC, what happens (though we need not document it) is that the
value is converted to the underlying type -- but not masked down
to { 0, 1 }, because that masking would be costly.
So, ((int) e == 7) may be true after the assignment above.
(Perhaps, in some modes GCC may optimize away the assignment because
it will know that e cannot be 7,
hhmm :-) this can lead to another felix-like war ;-)
I DID NOT WRITE THE BROKEN CODE. (...)
IT DOES NOT MATTER WHAT THE ... STANDARD SAYS.
You broke code, people are suffering damage. Now revert it.
So, now, what should we do about the warning? I think there are good
arguments in both directions. On the one hand, portable programs
cannot assume that assigning out-of-range values to e does anything
predictable, so portable programs should never do that. So, if you've
written the entire program and are sure that it's portable, you don't
want the warning.
and this is exactly what i'm expecting - no warnings for pure c++ code.
moreover such warnings-on-valid code make -Werror unusable with -Wall.
On the other hand, if you are writing a portable library designed
to be used with other people's programs, you might every well want
the warning -- because you can't be sure that they're not going to
pass 7 in as the value of e, and you may want to be robust in
the face of this *unspecified* behavior.
sorry, i don't care about unspecified/undefined behavior triggered
by users glitches. it's not a problem of my library.
In practice, this warning from GCC is keyed off what it thinks the
effective range of E is. If it starts assuming that e can only
have the values { 0, 1 }, it will also stop warning about the missing
case. It would be hard to stop emitting the warning without making
that assumption, and it may not be easy to make the assumption, but
still avoid the expensive masking operations.
i'm not familiar with gcc internals. for me enum looks like a set
and detecting missed `case' is a basic operation from set theory.
finally, if PR/28236 is valid then (according to the current discussion)
it should be marked as suspended or resolved/wontfix with appropriate
note.
BR,
Pawel.
Re: 2007 GCC Developers Summit
Ben Elliston wrote on 01/28/07 17:45: One idea I've always pondered is to have brief (perhaps 1-2 hr) tutorials, given by people in their area of expertise, as a means for other developers to come up to speed on a topic that interests them. Is this something that appeals to others? Sounds good to me. For instance, the new java front end, a description of the new build system, etc.
Interprocedural optimization question
Hi, Does gcc apply inter-procedural optimizations across functions called using a function pointer? I guess that gcc performs conservatively assuming that the pointer could point everywhere because the pointer is a declared as a global variable and could be changed in any place. Is it true? In this case, is there any pragma or directive to give a hint to the compiler, giving the set of possible values of the pointer (which in my case is known by the developer)? If not, this could be useful for optimization purposes. thanks in advance, Salut! Ramon. -- --- Ramon Bertran Monfort Departament d'Arquitectura de Computadors Telefon (+34) 93 4054033/54055 Universitat Politecnica de Catalunya Fax (+34) 93 4017055Despatx C6-103/C6-221-9 Campus Nord e-mail [EMAIL PROTECTED]C. Jordi Girona 1-3 - 08034 Barcelona --- A hundred times every day, I remind myself that my inner and outer life depends on the labors of other men, living and dead, and that I must exert myself in order to give in the measure as I have received and am still receiving. A. Einstein pgp5C0C0LRIFA.pgp Description: PGP signature
Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
GCC 4.3 compiler revision 121206 goes into infinitive loop while
compiling cpu2k6/perlbench source file regcomp.c at -O2 optimization
level on x86_64-redhat-linux.
GDB attached to cc1 process, gives the hang point:
0x00711bd8 in solve_graph (graph=0xd37150)
at /home/testbot/bootstrap/009454/src/gcc/tree-ssa-structalias.c:1619
1619if (!TEST_BIT (ti-visited, i) find (i) == i)
You can find the minimal reproducer attached to this mail. It looks like
the problem first appeared at the beginning of the last week. I'll
start binary search to detect the check-in causing this failure.
- Grigory
typedef struct RExC_state_t
{
char *end;
char *parse;
} RExC_state_t;
struct regnode_string
{
unsigned char str_len;
char string[1];
};
static void *regatom (RExC_state_t * pRExC_state, int *flagp);
static void *
regpiece (RExC_state_t * pRExC_state, int *flagp)
{
return regatom (0, 0);
}
static void *
regbranch (RExC_state_t * pRExC_state, int *flagp, int first)
{
return regpiece (0, 0);
}
static void *
reg (RExC_state_t * pRExC_state, int paren, int *flagp)
{
return regbranch (0, 0, 1);
}
void *
Perl_pregcomp (char *exp, char *xend, void *pm)
{
return reg (0, 0, 0);
}
static void *
regatom (RExC_state_t * pRExC_state, int *flagp)
{
register void *ret = 0;
int flags;
tryagain:
switch (*(pRExC_state-parse))
{
case '(':
ret = reg (pRExC_state, 1, flags);
if (flags 0x8)
{
goto tryagain;
}
break;
default:
{
register unsigned long len;
register unsigned ender;
register char *p;
char *oldp, *s;
unsigned long numlen;
unsigned long foldlen;
unsigned char tmpbuf[6 + 1], *foldbuf;
defchar:
s = (((struct regnode_string *) ret)-string);
for (len = 0, p = (pRExC_state-parse) - 1;
len 127 p (pRExC_state-end); len++)
{
if (((*p) == '*' || (*p) == '+' || (*p) == '?'
|| ((*p) == '{' regcurly (p
{
unsigned long unilen;
for (foldbuf = tmpbuf; foldlen; foldlen -= numlen)
{
reguni (pRExC_state, ender, s, unilen);
s += unilen;
}
break;
}
unsigned long unilen;
reguni (pRExC_state, ender, s, unilen);
s += unilen;
}
};
break;
}
return (ret);
}
Re: [c++] switch ( enum ) vs. default statment.
On 29/01/07, Paweł Sikora [EMAIL PROTECTED] wrote:
Mark Mitchell wrote:
So, now, what should we do about the warning? I think there are good
arguments in both directions. On the one hand, portable programs
cannot assume that assigning out-of-range values to e does anything
predictable, so portable programs should never do that. So, if you've
written the entire program and are sure that it's portable, you don't
want the warning.
and this is exactly what i'm expecting - no warnings for pure c++ code.
moreover such warnings-on-valid code make -Werror unusable with -Wall.
We do emit a lot of warnings for pure and valid c++ code. See
-Wunused-*, see -Wparentheses, see -Wuninitialized, see
-Wchar-subscripts, see -Wsign-compare, etc. Some could be avoided if
we had dataflow information in the front-end, but others are given
because there is a serious suspicious that something could go wrong
despite the code being valid and pure C++.
On the other hand, if you are writing a portable library designed
to be used with other people's programs, you might every well want
the warning -- because you can't be sure that they're not going to
pass 7 in as the value of e, and you may want to be robust in
the face of this *unspecified* behavior.
sorry, i don't care about unspecified/undefined behavior triggered
by users glitches. it's not a problem of my library.
You have many ways to work-around it if you are 100% sure you are the
only one using that function and that you will never pass anything
different from that enum type.
* You can add a return 0 or an exit(1) at the end of the function or
in a default label. Since in your case the code is unreachable, the
optimiser may remove it or it will never be executed.
* You can use the appropriate -Wno-X option to disable the warning.
* You can use the appropriate #pragma GCC diagnostics ignored -WX to
disable the warning.
* You can use #pragma GCC diagnostic warning -WX to emit just a
warning despite using -Werror in the command-line. You do the same
with -Wno-error=X.
In practice, this warning from GCC is keyed off what it thinks the
effective range of E is. If it starts assuming that e can only
have the values { 0, 1 }, it will also stop warning about the missing
case. It would be hard to stop emitting the warning without making
that assumption, and it may not be easy to make the assumption, but
still avoid the expensive masking operations.
i'm not familiar with gcc internals. for me enum looks like a set
and detecting missed `case' is a basic operation from set theory.
Out-of-range values are unspecified, they can be within the range of E
and they can be outside. Currently, GCC generates out-of-range values,
so we warn you about it. If GCC modified the value to fit within the
range (maybe randomly), it still will be correct but we won't generate
any warning. Yet, people will also complain that they cannot detect
when the value was out-of-range and will request a warning. Hey! one
moment! it seems we already did that at some moment and people did
complain! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
finally, if PR/28236 is valid then (according to the current discussion)
it should be marked as suspended or resolved/wontfix with appropriate
note.
I think it should be marked as invalid but WONTFIX is ok as well.
Since you agree, I will close it right now and point to your message.
Cheers,
Manuel.
java: mark calls to external fndecls DECL_EXTERNAL
We weren't marking calls to external fndecls DECL_EXTERNAL, and this was causing build failures on PPC64. Andrew. 2007-01-29 Andrew Haley [EMAIL PROTECTED] * class.c (add_method_1): Mark fndecl as external unless we are compiling it into this object file. Index: class.c === --- class.c (revision 121108) +++ class.c (working copy) @@ -733,6 +733,10 @@ METHOD_NATIVE (fndecl) = 1; DECL_EXTERNAL (fndecl) = 1; } + else +/* FNDECL is external unless we are compiling it into this object + file. */ +DECL_EXTERNAL (fndecl) = CLASS_FROM_CURRENTLY_COMPILED_P (this_class) == 0; if (access_flags ACC_STATIC) METHOD_STATIC (fndecl) = DECL_INLINE (fndecl) = 1; if (access_flags ACC_FINAL)
Re: Which optimization levels affect gimple?
On 1/29/07, Diego Novillo [EMAIL PROTECTED] wrote: -fdump-tree-all gives you all the dumps by the high-level optimizers. -fdump-all-all gives you all the dumps by both GIMPLE and RTL optimizers. Is this -fdump-all-all version specific? Doesn't work on 4.1.1: $ g++ -fdump-all-all allocation.cpp cc1plus: error: unrecognized command line option -fdump-all-all Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On 1/28/07, Mark Mitchell [EMAIL PROTECTED] wrote: It's entirely reasonable to look for a way to get rid of this use of TREE_COMPLEXITY, but things like: You know (or so I assume) this was a very Very VERY BAD thing to do are not helpful. Of course, if RTH had thought it was a bad thing, he wouldn't have done it. Fine. Then consider all my efforts to remove it finished. Gr. Steven
Re: Ada and the TREE_COMPLEXITY field on struct tree_exp
On 1/28/07, Steven Bosscher [EMAIL PROTECTED] wrote: OK, attached is the preliminary hack I created some time ago. After some changes, it now bootstraps, but I haven't tested it yet. I'm passing it as an RFC. This patch is hereby withdrawn. Gr. Steven
RE: Interprocedural optimization question
Razya Ladelsky/Haifa/IBM wrote on 29/01/2007 13:46:33: Hi, Does gcc apply inter-procedural optimizations across functions called using a function pointer? I guess that gcc performs conservatively assuming that the pointer could point everywhere because the pointer is a declared as a global variable and could be changed in any place. Is it true? Yes. The callgraph does not include these calls. In this case, is there any pragma or directive to give a hint to the compiler, giving the set of possible values of the pointer (which in my case is known by the developer)? If not, this could be useful for optimization purposes. thanks in advance, Salut! Ramon. -- --- Ramon Bertran Monfort Departament d'Arquitectura de Computadors Telefon (+34) 93 4054033/54055 Universitat Politecnica de Catalunya Fax (+34) 93 4017055Despatx C6-103/C6-221-9 Campus Nord e-mail [EMAIL PROTECTED]C. Jordi Girona 1-3 - 08034 Barcelona --- A hundred times every day, I remind myself that my inner and outer life depends on the labors of other men, living and dead, and that I must exert myself in order to give in the measure as I have received and am still receiving. A. Einstein [attachment atte7k4r.dat deleted by Razya Ladelsky/Haifa/IBM]
Re: remarks about g++ 4.3 and some comparison to msvc icc on ia32
On 1/29/07, Mark Mitchell [EMAIL PROTECTED] wrote: It doesn't need to be a small testcase. If you have a preprocessed source file and a command-line, I'm sure one of the GCC developers would be able to analyze the situation. We're all good at isolating problems, even starting with big complicated inputs. This now known as PR / 30627 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30627 PS: Thanks to Vladimir for his input.
Re: Which optimization levels affect gimple?
Paulo J. Matos wrote on 01/29/07 06:35: On 1/29/07, Diego Novillo [EMAIL PROTECTED] wrote: -fdump-tree-all gives you all the dumps by the high-level optimizers. -fdump-all-all gives you all the dumps by both GIMPLE and RTL optimizers. Is this -fdump-all-all version specific? Doesn't work on 4.1.1: $ g++ -fdump-all-all allocation.cpp cc1plus: error: unrecognized command line option -fdump-all-all No, I goofed. I must've dreamed the -all-all switch. You have to use -fdump-tree- for GIMPLE dumps and -fdump-rtl- for RTL dumps. It's also possible that -fdump-rtl doesn't work on the 4.1 series (I don't recall when -fdump-rtl was introduced, sorry). Check the invocation sections in the GCC 4.1 manual. Grep for fdump-.
Re: Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
Grigory Zagorodnev wrote: GCC 4.3 compiler revision 121206 goes into infinitive loop while compiling cpu2k6/perlbench source file regcomp.c at -O2 optimization level on x86_64-redhat-linux. This regression is caused by Rewrite of portions of points-to solver patch http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01541.html revision 120931 http://gcc.gnu.org/viewcvs?view=revrevision=120931 - Grigory
Trunk GCC fails to compile cpu2k6/dealII at -O2
Hi! GCC 4.3 compiler revision 121206 gets ICE while compiling cpu2006/447.dealII source file data_out_base.cc at -O2 optimization level on x86_64-redhat-linux. Similar to previously reported cpu2k6/perlbench failure, this regression is caused by Rewrite of portions of points-to solver patch http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01541.html (revision 120931). Error log is listed below. I'm working to get a small reproducer. data_out_base.cc: In static member function 'static void DataOutBase::write_vtk(const std::vectorDataOutBase::Patchdim, spacedim, std::allocatorDataOutBase::Patchdim, spacedim , const std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , const DataOutBase::VtkFlags, std::ostream) [with int dim = 3, int spacedim = 4]': data_out_base.cc:2949: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'reduc_max_expr' in add_call_clobber_ops, at tree-ssa-operands.c:1780 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. - Grigory
Re: Signed int overflow behavior in the security context
On Sun, 28 Jan 2007, James Dennett wrote: Therefore, a case can be made that *for an implementation in which a type has no trap values*, an indeterminate value must correspond to some specific value. In other words: reading an uninitialized int is undefined behavior only if int includes trap representations in a given implementation. Otherwise, all we have is an unspecified (but valid) value, which is a common assumption. I'm not sure that I like this conclusion, but I've not seen a really good argument against it. DR#260 seems clear enough that indeterminate values may be treated distinctly from determinate values including randomly changing at any time. http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm -- Joseph S. Myers [EMAIL PROTECTED]
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On 1/29/07, Paolo Bonzini [EMAIL PROTECTED] wrote: I hope Steven accepts a little deal: he exits angry-stevenb-mode, and I donate him this untested patch to remove TREE_COMPLEXITY from C++. No, thank you. I've decided long ago that I'm not going to work on anything unless there is nobody working in the other direction. In the case of TREE_COMPLEXITY, one of the best and most prominent gcc hacker decided to use something of which, I believe, everyone thinks it should go. And he did so in a way almost as if to cover it up, by accessing the field directly instead of through the accessor macros. So I freak out, which is not good, I know. I appologize to those who feel offended, because I did not mean to. My what was on your mind remark was *very* tongue-in-cheek, because clearly rth wouldn't have done this when he would have had more time/patience/whatever. See his own remark in the commit mail about his state of mind when he commited this bit. But then to have Mark *support* rth's change, that really shows the total lack of leadership and a common plan in the design of gcc. Why should I spend hours on this kind of cleanup, only to feel frustrated, to make others dislike me, and to have zero result in the end? I'll just work on something else instead. Gr. Steven
Re: Trunk GCC fails to compile cpu2k6/dealII at -O2
On 1/29/07, Grigory Zagorodnev [EMAIL PROTECTED] wrote: Hi! GCC 4.3 compiler revision 121206 gets ICE while compiling cpu2006/447.dealII source file data_out_base.cc at -O2 optimization level on x86_64-redhat-linux. Similar to previously reported cpu2k6/perlbench failure, this regression is caused by Rewrite of portions of points-to solver patch http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01541.html (revision 120931). No, actually, it's not. It's caused by one of Jan's patches to remove unreferenced vars. In fact, i'm pretty sure he already fixed this bug.
[PATCH]: Fix hang while compiling cpu2k6/perlbench at -O2
On 1/29/07, Grigory Zagorodnev [EMAIL PROTECTED] wrote:
Grigory Zagorodnev wrote:
GCC 4.3 compiler revision 121206 goes into infinitive loop while
compiling cpu2k6/perlbench source file regcomp.c at -O2 optimization
level on x86_64-redhat-linux.
This regression is caused by Rewrite of portions of points-to solver
patch http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01541.html
revision 120931 http://gcc.gnu.org/viewcvs?view=revrevision=120931
Patch attached and committed after bootstrap and regtest on i686-darwin.
2007-01-29 Daniel Berlin [EMAIL PROTECTED]
* tree-ssa-structalias.c (do_complex_constraint): Mark correct
variable as changed.
- Grigory
Index: testsuite/gcc.c-torture/compile/20070129.c
===
--- testsuite/gcc.c-torture/compile/20070129.c (revision 0)
+++ testsuite/gcc.c-torture/compile/20070129.c (revision 0)
@@ -0,0 +1,94 @@
+/* This testcase would cause a hang in PTA solving due to a complex copy
+ constraint and marking the wrong variable as changed. */
+
+typedef struct RExC_state_t
+{
+ char *end;
+ char *parse;
+} RExC_state_t;
+
+struct regnode_string
+{
+ unsigned char str_len;
+ char string[1];
+};
+
+static void *regatom (RExC_state_t * pRExC_state, int *flagp);
+
+static void *
+regpiece (RExC_state_t * pRExC_state, int *flagp)
+{
+ return regatom (0, 0);
+}
+
+static void *
+regbranch (RExC_state_t * pRExC_state, int *flagp, int first)
+{
+ return regpiece (0, 0);
+}
+
+static void *
+reg (RExC_state_t * pRExC_state, int paren, int *flagp)
+{
+ return regbranch (0, 0, 1);
+}
+
+void *
+Perl_pregcomp (char *exp, char *xend, void *pm)
+{
+ return reg (0, 0, 0);
+}
+
+static void *
+regatom (RExC_state_t * pRExC_state, int *flagp)
+{
+ register void *ret = 0;
+ int flags;
+
+tryagain:
+ switch (*(pRExC_state-parse))
+ {
+ case '(':
+ ret = reg (pRExC_state, 1, flags);
+ if (flags 0x8)
+ {
+ goto tryagain;
+ }
+ break;
+ default:
+ {
+ register unsigned long len;
+ register unsigned ender;
+ register char *p;
+ char *oldp, *s;
+ unsigned long numlen;
+ unsigned long foldlen;
+ unsigned char tmpbuf[6 + 1], *foldbuf;
+
+ defchar:
+ s = (((struct regnode_string *) ret)-string);
+ for (len = 0, p = (pRExC_state-parse) - 1;
+len 127 p (pRExC_state-end); len++)
+ {
+ if (((*p) == '*' || (*p) == '+' || (*p) == '?'
+|| ((*p) == '{' regcurly (p
+ {
+ unsigned long unilen;
+ for (foldbuf = tmpbuf; foldlen; foldlen -= numlen)
+ {
+ reguni (pRExC_state, ender, s, unilen);
+ s += unilen;
+ }
+ break;
+ }
+ unsigned long unilen;
+
+ reguni (pRExC_state, ender, s, unilen);
+ s += unilen;
+ }
+
+ };
+ break;
+ }
+ return (ret);
+}
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 121279)
+++ tree-ssa-structalias.c (working copy)
@@ -1538,9 +1538,9 @@ do_complex_constraint (constraint_graph_
if (flag)
{
get_varinfo (t)-solution = tmp;
- if (!TEST_BIT (changed, c-lhs.var))
+ if (!TEST_BIT (changed, t))
{
- SET_BIT (changed, c-lhs.var);
+ SET_BIT (changed, t);
changed_count++;
}
}
@@ -2065,6 +2065,7 @@ solve_graph (constraint_graph_t graph)
bitmap solution;
VEC(constraint_t,heap) *complex = graph-complex[i];
bool solution_empty;
+
RESET_BIT (changed, i);
changed_count--;
Re: Which optimization levels affect gimple?
On 1/29/07, Diego Novillo [EMAIL PROTECTED] wrote: Paulo J. Matos wrote on 01/29/07 06:35: On 1/29/07, Diego Novillo [EMAIL PROTECTED] wrote: -fdump-tree-all gives you all the dumps by the high-level optimizers. -fdump-all-all gives you all the dumps by both GIMPLE and RTL optimizers. Is this -fdump-all-all version specific? Doesn't work on 4.1.1: $ g++ -fdump-all-all allocation.cpp cc1plus: error: unrecognized command line option -fdump-all-all No, I goofed. I must've dreamed the -all-all switch. You have to use -fdump-tree- for GIMPLE dumps and -fdump-rtl- for RTL dumps. It's also possible that -fdump-rtl doesn't work on the 4.1 series (I don't recall when -fdump-rtl was introduced, sorry). -fdump-tree-all-all will work as will -fdump-rtl-all-all I never added support for -fdump-all-all-all :)
Re: [c++] switch ( enum ) vs. default statment.
Paweł Sikora wrote: On the other hand, if you are writing a portable library designed to be used with other people's programs, you might every well want the warning -- because you can't be sure that they're not going to pass 7 in as the value of e, and you may want to be robust in the face of this *unspecified* behavior. sorry, i don't care about unspecified/undefined behavior triggered by users glitches. it's not a problem of my library. The point I was trying to make was that unspecified and undefined are actually very different. I wouldn't be too surprised if, in the future, G++ defined the behavior of the e = (E) 7 case as storing the value in the underlying type. Then, might indeed rely on that. Obviously, you're free to make your own decisions, but, personally, I would certainly feel free to assume that no undefined behavior happened in the application -- but I wouldn't assume that no unspecified behavior occurred. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
After GIMPLE...
Hi all, I've been looking into the gcc sources and I'm somewhat confused. Are gcc/g++ comepletely independent programs or do they share a backend? This question comes from the fact that I was trying to find a point in the source where I could get the GIMPLE tree and do with it what ever I wished to, without modifying too many files but it seems that gcc, g++ and other frontends have different program flows and only share some data structures and backend sources. So probably I need to eliminate the backend call in every frontend and after GIMPLE is created call my own functions which get the GIMPLE tree and then compile my files against every frontend. Right? Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: 2007 GCC Developers Summit
On 1/29/07, Diego Novillo [EMAIL PROTECTED] wrote: Ben Elliston wrote on 01/28/07 17:45: One idea I've always pondered is to have brief (perhaps 1-2 hr) tutorials, given by people in their area of expertise, as a means for other developers to come up to speed on a topic that interests them. Is this something that appeals to others? Sounds good to me. For instance, the new java front end, a description of the new build system, etc. Although it's not something new, I'd be interested in a tutorial on loop optimizations (IV opt and all related). Based on my understanding, the topic might be of interest to some other people as well. -- #pragma ident Seongbae Park, compiler, http://seongbae.blogspot.com;
Re: 2007 GCC Developers Summit
Hello, One idea I've always pondered is to have brief (perhaps 1-2 hr) tutorials, given by people in their area of expertise, as a means for other developers to come up to speed on a topic that interests them. Is this something that appeals to others? Sounds good to me. For instance, the new java front end, a description of the new build system, etc. Although it's not something new, I'd be interested in a tutorial on loop optimizations (IV opt and all related). Based on my understanding, the topic might be of interest to some other people as well. if sufficiently many people are interested, I (hopefully with the help of other loop optimizer developers) can prepare something. Zdenek
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
This is a multi-part message in MIME format. --050002020005030600040801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit You know (or so I assume) this was a very Very VERY BAD thing to do are not helpful. Of course, if RTH had thought it was a bad thing, he wouldn't have done it. Well, I must agree that there is probably no justification other than the quote that Richard posted. :-P Still, I agree with you on the tone of Steven's email, and I don't see the need to Cc Jakub and Diego too, either. I hope Steven accepts a little deal: he exits angry-stevenb-mode, and I donate him this untested patch to remove TREE_COMPLEXITY from C++. I rather create a new tree for template usage really, so you don't create an extra tree and save a little amount of memory. I have an untested patch which does that too. -- Pinski
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On Mon, Jan 29, 2007 at 03:24:56PM +0100, Steven Bosscher wrote: But then to have Mark *support* rth's change, that really shows the total lack of leadership and a common plan in the design of gcc. There you go again. Mark did not support or oppose rth's change, he just said that rth probably thought he had a good reason. He was merely opposing your personal attack. We're all human, we make mistakes, there can be better solutions. If you think that there's a problem with a patch, there are ways to say so without questioning the competence or good intentions of the person who made it.
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
Joe Buck writes: Joe There you go again. Mark did not support or oppose rth's change, he just Joe said that rth probably thought he had a good reason. He was merely Joe opposing your personal attack. We're all human, we make mistakes, there Joe can be better solutions. Joe If you think that there's a problem with a patch, there are ways to say so Joe without questioning the competence or good intentions of the person who Joe made it. Have any of you considered that Steven was using hyperbole as a joke? Are some people so overly-sensitized to Steven that they assume the worst and have a knee-jerk reaction criticizing him? The issue began as a light-hearted discussion on IRC. Steven's tone came across as inappropriate in email without context. However, Mark's reply defending RTH was not qualified with probably, which was an unfortunate omission, IMHO. Encouraging a more collegial tone on the GCC mailinglists is a good goal, but I hope that we don't over-react and create a larger problem. David
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On 1/29/07, David Edelsohn [EMAIL PROTECTED] wrote: Joe Buck writes: Joe There you go again. Mark did not support or oppose rth's change, he just Joe said that rth probably thought he had a good reason. He was merely Joe opposing your personal attack. We're all human, we make mistakes, there Joe can be better solutions. Joe If you think that there's a problem with a patch, there are ways to say so Joe without questioning the competence or good intentions of the person who Joe made it. Have any of you considered that Steven was using hyperbole as a joke? Are some people so overly-sensitized to Steven that they assume the worst and have a knee-jerk reaction criticizing him? The issue began as a light-hearted discussion on IRC. Steven's tone came across as inappropriate in email without context. However, Mark's reply defending RTH was not qualified with probably, which was an unfortunate omission, IMHO. Encouraging a more collegial tone on the GCC mailinglists is a good goal, but I hope that we don't over-react and create a larger problem. I hope so too. Steven is also somewhat frustrated by what he (and I, for that matter) see as often over-politicized processes of GCC. I believe this is perfectly understandable given the amount of politics it seems to take to get a significant design change pushed forward in GCC.
Re: Interprocedural optimization question
On 1/29/07, Razya Ladelsky [EMAIL PROTECTED] wrote: Razya Ladelsky/Haifa/IBM wrote on 29/01/2007 13:46:33: Hi, Does gcc apply inter-procedural optimizations across functions called using a function pointer? I guess that gcc performs conservatively assuming that the pointer could point everywhere because the pointer is a declared as a global variable and could be changed in any place. Is it true? Yes. The callgraph does not include these calls. Well, not quite. While the callgraph doesn't include them, ipa-pta will come up with a conservatively correct set for them. IN the presence of static function pointers, we will come up with a completely accurate set for them unless they escape
Re: After GIMPLE...
Paulo J. Matos [EMAIL PROTECTED] writes: I've been looking into the gcc sources and I'm somewhat confused. Are gcc/g++ comepletely independent programs or do they share a backend? In the source code, they share a backend. As executables, they are different programs: cc1 and cc1plus. This question comes from the fact that I was trying to find a point in the source where I could get the GIMPLE tree and do with it what ever I wished to, without modifying too many files but it seems that gcc, g++ and other frontends have different program flows and only share some data structures and backend sources. So probably I need to eliminate the backend call in every frontend and after GIMPLE is created call my own functions which get the GIMPLE tree and then compile my files against every frontend. Right? I don't see why you would have to modify any code in the frontend. You would modify the middle-end code. Rebuilding the compiler would rebuild cc1, cc1plus, etc. Ian
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
David Edelsohn wrote: Have any of you considered that Steven was using hyperbole as a joke? Are some people so overly-sensitized to Steven that they assume the worst and have a knee-jerk reaction criticizing him? Yes, I did consider it; that's why I said: I can't tell if you have your tongue planted in your cheek, but if you do, it's not obvious. Email is a tricky thing. I've learned -- the hard way -- that it's best to put a smiley on jokes, because otherwise people can't always tell that they're jokes. I don't think this was a knee-jerk reaction on my part. I certainly appreciate and respect Steven's contributions to GCC. I read Steven's post, the follow-ups, considered them for a while, read RTH's original post, and then decided to post my message. I certainly admit to a personal bugaboo about email tone on public lists. I think it's very important to err on the side of politeness. The issue began as a light-hearted discussion on IRC. Steven's tone came across as inappropriate in email without context. However, Mark's reply defending RTH was not qualified with probably, which was an unfortunate omission, IMHO. I did not defend RTH, except insofar as to suggest that RTH didn't act with ill will. It's true that I can't be certain of that, but it seems highly unlikely to me that any GCC contributor would intentionally check in a patch that they knew was in conflict with a clear direction of GCC. My guess is that RTH forgot the patch used TREE_COMPLEXITY, forgot we were removing TREE_COMPLEXITY, or something. Even if my original posting, I wrote: It's entirely reasonable to look for a way to get rid of this use of TREE_COMPLEXITY I refrained from specifically criticizing RTH's check-in, but I did not in any way try to defend his use of TREE_COMPLEXITY. I agree that using TREE_COMPLEXITY for OpenMP is undesirable, and that we should eliminate that use. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On 1/29/07, Joe Buck [EMAIL PROTECTED] wrote: On Mon, Jan 29, 2007 at 03:24:56PM +0100, Steven Bosscher wrote: But then to have Mark *support* rth's change, that really shows the total lack of leadership and a common plan in the design of gcc. There you go again. Actually, there *you* go again :-) Do you know I can't find even just one mail from you that did not in one way or another criticize the way I said something? Mark did not support or oppose rth's change, he just said that rth probably thought he had a good reason. Well, forgive me for missing the subtle difference between supporting a change and suggesting there was a good reason for the change. Also, to say that there is no common plan in GCC, or that there is no good leadership of the project, is just the expresion of my opinion. I really am of the opinion that gcc is a strange project which claims to be open but where the maintainers are appointed by a group of people that hasn't changed in ten years time. If you see that as attacking someone personally, that is your problem, not mine. If you think that there's a problem with a patch, there are ways to say so without questioning the competence or good intentions of the person who made it. Where did I question rth's competence? If you're going to be so picky about everything I say, can you at least be specific? Gr. Steven
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On 1/29/07, Mark Mitchell [EMAIL PROTECTED] wrote: Email is a tricky thing. I've learned -- the hard way -- that it's best to put a smiley on jokes, because otherwise people can't always tell that they're jokes. I did use a smiley. Maybe I should put the smiley smiling then, instead of a sad looking smlley. Gr. Steven
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
Steven Bosscher wrote: On 1/29/07, Mark Mitchell [EMAIL PROTECTED] wrote: Email is a tricky thing. I've learned -- the hard way -- that it's best to put a smiley on jokes, because otherwise people can't always tell that they're jokes. I did use a smiley. Maybe I should put the smiley smiling then, instead of a sad looking smlley. To me, they do mean very different things. The sad smiley didn't say joke; it said boo!. I think that a happy smiley would help. Like I say, I've had exactly the same problem with my own humor-impaired recipients. So, I think it's best just to live in constant fear that people don't think things are funny. :-) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On 1/29/07, Mark Mitchell [EMAIL PROTECTED] wrote: Steven Bosscher wrote: On 1/29/07, Mark Mitchell [EMAIL PROTECTED] wrote: Email is a tricky thing. I've learned -- the hard way -- that it's best to put a smiley on jokes, because otherwise people can't always tell that they're jokes. I did use a smiley. Maybe I should put the smiley smiling then, instead of a sad looking smlley. To me, they do mean very different things. The sad smiley didn't say joke; it said boo!. I think that a happy smiley would help. Well, a joke smiley on the first sentence quote Can you explain what went through your mind when you picked the tree_exp.complexity field for something implemented new... :-( /quote would have been inappropriate. There is no joke in this sentence, there is disappointment in it. Like I say, I've had exactly the same problem with my own humor-impaired recipients. So, I think it's best just to live in constant fear that people don't think things are funny. :-) There's a later ;) simley in the mail and maybe you missed one after the second paragraph. (certainly you did) I don't read that mail as anywhere insulting or inappropriate, maybe too informal for this list (!?). I appreciate Stevens contributions and willingness to fix things in GCC that appearantly nobody else wants to tackle. (I and others owe you beer for that!) Thanks, Richard.
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
There's a later ;) simley in the mail and maybe you missed one after the second paragraph. (certainly you did) Then I guess the question is: what is the scope of a smiley? Does it retroactively cover all the preceding sentences, including the subject? -- Eric Botcazou
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On 1/29/07, Eric Botcazou [EMAIL PROTECTED] wrote: There's a later ;) simley in the mail and maybe you missed one after the second paragraph. (certainly you did) Then I guess the question is: what is the scope of a smiley? Does it retroactively cover all the preceding sentences, including the subject? Good point. Personally I tend to annotate sentences with (or without) smiley ;) If I want a smiley to apply to like the whole mail it would be on a separate paragraph. Annotating a complete paragraph I don't know how to do. ;) (whole-mail-smiley) Richard.
GCC-4.0.4 prerelease
Hi, The tarballs for GCC-4.0.4 are available for download at ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.4-20070129/ Please download and test them. Baring any major problem, the final release will be made withing 3 days. And the GCC-4.0.x series will be definitely closed. -- Gaby
[PATCH for] Re: gcc-4.0-20070128 is now available
On Sun, 28 Jan 2007, Joe Buck wrote: It's probably time to turn off 4.0 snapshots; the last ones will probably be Gaby's prerelease snapshots, and the release should come soon. That's a good idea. You're right, there is no need to wait until the 4.0.4 release itself. Done thusly. I also updated the gccadmin account on gcc.gnu.org. Gerald 2007-01-29 Gerald Pfeifer [EMAIL PROTECTED] * crontab: No longer build snapshots for 4.0.x. Index: crontab === --- crontab (revision 121282) +++ crontab (working copy) @@ -1,7 +1,6 @@ 16 0 * * * sh /home/gccadmin/scripts/update_version_svn 50 0 * * * sh /home/gccadmin/scripts/update_web_docs_svn 55 0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_svn -32 22 * * 0 sh /home/gccadmin/scripts/gcc_release -s 4.0:branches/gcc-4_0-branch -l -d /sourceware/snapshot-tmp/gcc all 32 22 * * 1 sh /home/gccadmin/scripts/gcc_release -s 4.1:branches/gcc-4_1-branch -l -d /sourceware/snapshot-tmp/gcc all 32 22 * * 3 sh /home/gccadmin/scripts/gcc_release -s 4.2:branches/gcc-4_2-branch -l -d /sourceware/snapshot-tmp/gcc all 32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 4.3:trunk -l -d /sourceware/snapshot-tmp/gcc all
gcc-4.1-20070129 is now available
Snapshot gcc-4.1-20070129 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070129/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 121315 You'll find: gcc-4.1-20070129.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070129.tar.bz2 C front end and core compiler gcc-ada-4.1-20070129.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070129.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070129.tar.bz2 C++ front end and runtime gcc-java-4.1-20070129.tar.bz2 Java front end and runtime gcc-objc-4.1-20070129.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070129.tar.bz2The GCC testsuite Diffs from 4.1-20070122 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Gcc Cross Compile
Hi all, I am trying to cross compile gcc-4.1.0 ( I have also tried 3.3.2) for powerpc using a Freebsd 6.1 box. I configure using: var/gcc-4.1.0/configure --host=i386-freebsd --target=powerpc-linux --prefix=/var/gcc --disable-shared --disable-threads --enable-languages=c,c++ --without-fp and everything seems ok. Then I type make all-gcc install-gcc and the make begins. After a while I get the following error: srcdir=/var/gcc-4.1.0/fixincludes /bin/sh /var/gcc-4.1.0/fixincludes/mkfixinc.sh powerpc-unknown-linux-gnu sed -e 's/@gcc_version@//' mkheadersT Syntax error: redirection unexpected *** Error code 2 Stop in /var/built-gcc/build-i386-freebsd/fixincludes. *** Error code 1 I have tried to configure using other commands like: /var/gcc-4.1.0/configure --target=powerpc-linux --prefix=/var/gcc --disable-shared --disable-threads --enable-languages=c --with-newlib but nothing different happens. Any ideas? thanks in advance Andreas Sotirakopoulos ___ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
Re: [PATCH for] Re: gcc-4.0-20070128 is now available
Gerald Pfeifer [EMAIL PROTECTED] writes: | On Sun, 28 Jan 2007, Joe Buck wrote: | It's probably time to turn off 4.0 snapshots; the last ones will | probably be Gaby's prerelease snapshots, and the release should come | soon. | | That's a good idea. You're right, there is no need to wait until | the 4.0.4 release itself. completely agreed. -- Gaby
Re: Signed int overflow behavior in the security context
Joseph Myers wrote: DR#260 seems clear enough that indeterminate values may be treated distinctly from determinate values including randomly changing at any time. http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm One can only hope that the recommendations won't see the light of day in their present form, as it's fairly clear that once an unspecified value is read (presuming absents of a trap representation), it becomes logically visible, and thereby clearly no longer logically indeterminate. Further, regardless of the recommendations; and presuming absents of any possibility of a trap representation for a given implementation; x ^= x remains well defined, although not necessarily equivalent to 0; as although lvalue x remains well defined, its rvalue is proposed to remain repetitively unspecified until being assigned the result of the dynamically evaluated xor operation having two potentially differing unspecified operand values. (as the undefined behavior referenced in the DR is related to a pointer becoming indeterminate because it was assigned an indeterminate value, or the object it had referenced has been freed and thereby no longer a valid object of the pointer's type, and thereby although the pointer's value has not changed, it's value is now considered a trap representation; not because the value it references has been assigned an indeterminate value)
GCC 4.1.2 RC1
GCC 4.1.2 RC1 is now on ftp://gcc.gnu.org and its mirrors. The canonical location is: ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070128 As with all prereleases, the issue of most concern to me is packaging. Therefore, please test the actual pre-release tarballs, rather than sources from SVN. Beyond packaging problems, I'm most concerned about regression from previous 4.1.x releases, since the primary purpose of 4.1.2 is to provide an upgrade path from previous 4.1.x releases, incorporating the bug fixes since 4.1.1. If you do encounter problems, please file a Bugzilla PR, and add me to the CC: list for the issue. Please do not send me reports without first filing a PR, as I am unable to keep track of all the issues if they are not in the database. We'll do either the final GCC 4.1.2 release (if all goes well), or RC2 (if it doesn't) in about a week. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Signed int overflow behavior in the security context
Paul Schlie [EMAIL PROTECTED] wrote: One can only hope that the recommendations won't see the light of day in their present form, as it's fairly clear that once an unspecified value is read (presuming absents of a trap representation), it becomes logically visible, and thereby clearly no longer logically indeterminate. An unspecified value was never indeterminate in the first place. The terms are not synonymous. And an object holding an indeterminate value does not stop being indeterminate when its value is read; reading it invokes undefined behavior. This is true Because The Standard Says So, no matter how illogical it may seem. presuming absents of any possibility of a trap representation for a given implementation That's an unreliable presumption. As noted in the defect report, a trap representation can have the same bit pattern as a valid value. Trapness depends not just on the bit pattern, but also how the bit pattern was produced. So even if there are no hardware-level traps, if you read an indeterminate object, a compiler is allowed to produce the same behavior as if there were hardware-level traps. (as the undefined behavior referenced in the DR is related to a pointer becoming indeterminate *Some* of the DR relates to pointers. But reading the value of any object (pointer or otherwise) holding a trap representation invokes undefined behavior. paul
Re: Signed int overflow behavior in the security context
Joseph S. Myers wrote: On Sun, 28 Jan 2007, James Dennett wrote: Therefore, a case can be made that *for an implementation in which a type has no trap values*, an indeterminate value must correspond to some specific value. In other words: reading an uninitialized int is undefined behavior only if int includes trap representations in a given implementation. Otherwise, all we have is an unspecified (but valid) value, which is a common assumption. I'm not sure that I like this conclusion, but I've not seen a really good argument against it. DR#260 seems clear enough that indeterminate values may be treated distinctly from determinate values including randomly changing at any time. http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm It does say that. (It also says some untenable/pointless things about tracking the origins of pointer values, which I'm sure when reduced to objective tests would amount to precisely nothing.) Looks like C99 was an aberration in how it defined indeterminate values, and that DR#260 (do you know if it's in TC1) says that we're back to how it used to be (and how it's expected to be in C++), which is that reading an indeterminate value (except via lvalues of character type) is undefined behavior. -- James
Re: Signed int overflow behavior in the security context
Paul Schlie [EMAIL PROTECTED] wrote: Paul Jarc wrote: As noted in the defect report, a trap representation can have the same bit pattern as a valid value. Trapness depends not just on the bit pattern, but also how the bit pattern was produced. - that's not what is says Did you read it? # Implementations are permitted to track the origins of a bit-pattern # and treat those representing an indeterminate value as distinct from # those representing a determined value. a pointer value may be/become a trap representation [...] That is also true, but there is more than that. is required to be well specified [...] as otherwise the language couldn't be utilized to write even the most hardware drivers required of all computer systems. In a sense, the language *can't* be used to write most hardware drivers. Drivers do invoke undefined behavior - that is, the standard makes no guarantees about their behavior - but the particular platform they are targeted for makes its own guarantees, so the code is still useful, even though it is not strictly conforming C. paul
Re: Signed int overflow behavior in the security context
Paul Schlie wrote: Joseph Myers wrote: DR#260 seems clear enough that indeterminate values may be treated distinctly from determinate values including randomly changing at any time. http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm One can only hope that the recommendations won't see the light of day in their present form, as it's fairly clear that once an unspecified value is read (presuming absents of a trap representation), it becomes logically visible, and thereby clearly no longer logically indeterminate. It's not fairly clear to me; in fact, it seems to ignore the specific definition of indeterminate which overrides any preconceived or more general notion of what the word might mean in other contexts. The only relevant definitions/meanings of indeterminate are those found in the standard and its corrigenda. Further, regardless of the recommendations; and presuming absents of any possibility of a trap representation for a given implementation; x ^= x remains well defined, although not necessarily equivalent to 0; as although lvalue x remains well defined, its rvalue is proposed to remain repetitively unspecified until being assigned the result of the dynamically evaluated xor operation having two potentially differing unspecified operand values. (as the undefined behavior referenced in the DR is related to a pointer becoming indeterminate because it was assigned an indeterminate value, or the object it had referenced has been freed and thereby no longer a valid object of the pointer's type, and thereby although the pointer's value has not changed, it's value is now considered a trap representation; not because the value it references has been assigned an indeterminate value) No, that's just an example: the text makes it clear that this isn't an issue just about pointers. (The resolution of DR#260 covers a number of related points, which may cause this apparent lack of clarity.) Note that DR#260's resolution says While an object holds an indeterminate value it is indeterminate. Successive reads from an object that is indeterminate might return different results. Nothing about pointers; this applies to all objects. -- James
Re: Signed int overflow behavior in the security context
Paul Schlie wrote: - agreed, and thereby objects having no legitimate trap representation, such as most if not all implementations of integers and floating point objects on most if not all current target machines, and thereby their access does not invoke an undefined behavior. First of all, trap representations of COURSE exist for floating-point objects, I guess you don't know fpt formats (most people don't). But in any case, your reasoning here is once again based on the language you wish you had, rather than the formal semantic language defined by the standard, which has no notion of no legitimate trap representation. The standard says an uninitialized variable can have a trap representation. Therefor it can. There is no license to reason about how you think code is generated, any compiled is allowed to generate code AS IF a trap representation were present. I think you often miss this distinction between generated code at the implementation level as if behavior from the rules in the standard Just as: volatile int* port = (int*)PORT_ADDRESS; int input = *port; supposedly invoking an undefined behavior. is required to be well specified, effectively reading through a pointer an un-initialized object's value, and then assigning that unspecified value to the variable input; as otherwise the language couldn't be utilized to write even the most hardware drivers required of all computer systems. Looks unspecified to me, but in any case reasoning which says The standard must say X, since otherwise I could not write hardware drivers required of all computer systems, is bogus. There is nothing that says valid C can be used to write such drivers. (however regardless, I acquiesce to those to continue to wish otherwise, to the apparent continued destruction of the language for no apparent particularly useful purpose by increasingly striving to render it undefined) It is not a matter of wishes (though you seem to work this way), it is a matter of what the standard says. If you don't like the standard, go argue with the standards committee, it is useless to argue with implementors.
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
I rather create a new tree for template usage really, so you don't create
an extra tree and save a little amount of memory.
This, however, would consume another scarce resource, i.e. tree codes.
The attached patch, in the meanwhile, has been bootstrapped and
regtested i686-pc-linux-gnu, C/C++ only, with no regression. Note that
this is *not* the patch I sent yesterday, which did not work.
Ok for mainline?
Paolo
2007-01-30 Paolo Bonzini [EMAIL PROTECTED]
* cp/cp-tree.h (OMP_ATOMIC_CODE): Delete.
(OMP_ATOMIC_DEPENDENT_P): Rewrite.
* cp/pt.c (tsubst_expr): Adjust for new format of dependent OMP_ATOMIC
expressions.
* cp/semantics.c (finish_omp_atomic): Store a whole expression node
in operand 1, and integer_zero_node in operand 0, for dependent
OMP_ATOMIC. Rewrite to make flow easier to understand.
Index: cp-tree.h
===
*** cp-tree.h (revision 121287)
--- cp-tree.h (working copy)
*** extern void decl_shadowed_for_var_insert
*** 3040,3052
(TREE_LANG_FLAG_0 (SCOPE_REF_CHECK (NODE)))
/* True for an OMP_ATOMIC that has dependent parameters. These are stored
!as bare LHS/RHS, and not as ADDR/RHS, as in the generic statement. */
#define OMP_ATOMIC_DEPENDENT_P(NODE) \
! (TREE_LANG_FLAG_0 (OMP_ATOMIC_CHECK (NODE)))
!
! /* Used to store the operation code when OMP_ATOMIC_DEPENDENT_P is set. */
! #define OMP_ATOMIC_CODE(NODE) \
! (OMP_ATOMIC_CHECK (NODE)-exp.complexity)
/* Used while gimplifying continue statements bound to OMP_FOR nodes. */
#define OMP_FOR_GIMPLIFYING_P(NODE) \
--- 3040,3048
(TREE_LANG_FLAG_0 (SCOPE_REF_CHECK (NODE)))
/* True for an OMP_ATOMIC that has dependent parameters. These are stored
!as an expr in operand 1, and integer_zero_node in operand 0. */
#define OMP_ATOMIC_DEPENDENT_P(NODE) \
! (TREE_CODE (TREE_OPERAND (OMP_ATOMIC_CHECK (NODE), 0)) == INTEGER_CST)
/* Used while gimplifying continue statements bound to OMP_FOR nodes. */
#define OMP_FOR_GIMPLIFYING_P(NODE) \
Index: pt.c
===
*** pt.c(revision 121287)
--- pt.c(working copy)
*** tsubst_expr (tree t, tree args, tsubst_f
*** 8917,8928
break;
case OMP_ATOMIC:
! {
! tree op0, op1;
! op0 = RECUR (TREE_OPERAND (t, 0));
! op1 = RECUR (TREE_OPERAND (t, 1));
! finish_omp_atomic (OMP_ATOMIC_CODE (t), op0, op1);
! }
break;
default:
--- 8917,8929
break;
case OMP_ATOMIC:
! if (OMP_ATOMIC_DEPENDENT_P (t))
! {
! tree op1 = TREE_OPERAND (t, 1);
! tree lhs = RECUR (TREE_OPERAND (op1, 0));
! tree rhs = RECUR (TREE_OPERAND (op1, 1));
! finish_omp_atomic (TREE_CODE (op1), lhs, rhs);
! }
break;
default:
Index: semantics.c
===
*** semantics.c (revision 121287)
--- semantics.c (working copy)
*** finish_omp_for (location_t locus, tree d
*** 3867,3907
void
finish_omp_atomic (enum tree_code code, tree lhs, tree rhs)
{
- tree orig_lhs;
- tree orig_rhs;
- bool dependent_p;
tree stmt;
! orig_lhs = lhs;
! orig_rhs = rhs;
! dependent_p = false;
! stmt = NULL_TREE;
!
! /* Even in a template, we can detect invalid uses of the atomic
! pragma if neither LHS nor RHS is type-dependent. */
! if (processing_template_decl)
! {
! dependent_p = (type_dependent_expression_p (lhs)
!|| type_dependent_expression_p (rhs));
! if (!dependent_p)
{
lhs = build_non_dependent_expr (lhs);
rhs = build_non_dependent_expr (rhs);
}
! }
! if (!dependent_p)
! {
stmt = c_finish_omp_atomic (code, lhs, rhs);
- if (stmt == error_mark_node)
- return;
- }
- if (processing_template_decl)
- {
- stmt = build2 (OMP_ATOMIC, void_type_node, orig_lhs, orig_rhs);
- OMP_ATOMIC_DEPENDENT_P (stmt) = 1;
- OMP_ATOMIC_CODE (stmt) = code;
}
! add_stmt (stmt);
}
void
--- 3867,3894
void
finish_omp_atomic (enum tree_code code, tree lhs, tree rhs)
{
tree stmt;
! if (processing_template_decl
!(type_dependent_expression_p (lhs)
! || type_dependent_expression_p (rhs)))
! stmt = build2 (OMP_ATOMIC, void_type_node, integer_zero_node,
! build2 (code, void_type_node, lhs, rhs));
! else
! {
! /* Even in a template, we can detect invalid uses of the atomic
! pragma if neither LHS nor RHS is type-dependent. */
! if (processing_template_decl)
{
lhs = build_non_dependent_expr (lhs);
rhs = build_non_dependent_expr (rhs);
}
!
stmt = c_finish_omp_atomic (code, lhs, rhs);
[Bug fortran/30512] MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1 maximum values.
--- Comment #8 from burnus at gcc dot gnu dot org 2007-01-29 08:40 --- Should we commit the combined fix? I do think this is a bug. So do I, but we also need a test case, I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
[Bug fortran/30626] New: Wrong-code for internal read
Ante-scriptum: This PR might be related to PR30284 (or not). $ cat a.f90 character(len=12) :: date(1) = (/ '200612231200' /) integer :: foo read (date(:)(1:4),'(i4)') foo print *, foo end $ ifort a.f90 ./a.out 2006 $ gfortran a.f90 ./a.out 2 gfortran has an incorrect behaviour here, while ifort is doing the right thing (like all other compilers I could test). -- Summary: Wrong-code for internal read Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org BugsThisDependsOn: 30284 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30626
[Bug fortran/30626] Wrong-code for internal read
-- fxcoudert 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-01-29 09:07:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30626
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #11 from doerr at kis dot uni-freiburg dot de 2007-01-29 09:43 --- Hi, I still get the same problem after installing the gcc-4.2-20070124 on OpenSUSE 10.2 for amd64 only (configured with --disable-multilib). $prefix/lib64 is in my ld.so.conf as well as in $LD_LIBRARY_PATH. It seems that this bug was not fixed within one year, so is there any possibility to work around it? Greetings, Hans-Peter Doerr -- doerr at kis dot uni-freiburg dot de changed: What|Removed |Added CC||doerr at kis dot uni- ||freiburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #12 from martin at mpa-garching dot mpg dot de 2007-01-29 10:04 --- Well, I just copy libgomp.spec from lib64/ to lib/ by hand after installing. For the long term this not the right thing of course, but as a quick fix it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug fortran/30554] ICE in mio_pointer_ref at module.c:1945
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-29 10:28 --- Subject: Bug 30554 Author: pault Date: Mon Jan 29 10:27:50 2007 New Revision: 121281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121281 Log: 2007-01-29 Paul Thomas [EMAIL PROTECTED] PR fortran/30554 * module.c (read_module): If a symbol is excluded by an ONLY clause, check to see if there is a symtree already loaded. If so, attach the symtree to the pointer_info. 2007-01-29 Paul Thomas [EMAIL PROTECTED] PR fortran/30554 * gfortran.dg/used_dummy_types_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_dummy_types_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #15 from bkoz at gcc dot gnu dot org 2007-01-29 10:51 --- Subject: Bug 28125 Author: bkoz Date: Mon Jan 29 10:51:01 2007 New Revision: 121282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121282 Log: 2007-01-28 Benjamin Kosnik [EMAIL PROTECTED] Revert. 2006-12-11 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/28125 * acinclude.m4 (GLIBCXX_CHECK_ICONV_SUPPORT): Remove link test, ie AC_CHECK_LIB for libiconv. Instead, use bits of AM_ICONV. * configure: Regenerate. * scripts/testsuite_flags.in (cxxflags): Add LIBICONV bits. Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_1-branch/libstdc++-v3/configure branches/gcc-4_1-branch/libstdc++-v3/scripts/testsuite_flags.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug c++/28236] wrong control reaches warning with enums.
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-29 11:09 --- WONTFIX as decided here: http://gcc.gnu.org/ml/gcc/2007-01/msg01179.html -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
[Bug c++/30627] New: missed optimization, large stack frame, oodles of upfront movl $0
Compiling the attached testcase at O 0 for an ia32 target, ie /usr/local/gcc-4.3-20070119/bin/g++ -O3 -march=k8 -msse3 -fomit-frame-pointer, i get something like subl$2812, %esp leal1100(%esp), %eax leal2808(%esp), %edx movl$0, 976(%esp) movl$0, 980(%esp) movl$0, 968(%esp) movl$0, 972(%esp) movl$0, 960(%esp) movl$0, 964(%esp) movl$0, 952(%esp) movl$0, 956(%esp) movl$0, 928(%esp) movl$0, 932(%esp) movl$0, 904(%esp) movl$0, 908(%esp) movl$0, 888(%esp) movl$0, 892(%esp) movl$0, 872(%esp) movl$0, 876(%esp) ... for the app::frontend_loop() function. There's 2 problems: a) g++ generates a larger stack frame than other compilers, msvc 8 sp1: 1152 bytes, icc 9.1: 2108 bytes b) long strings of movl $0 get coalesced to the top of the function, that symptom is specific to ia32, it doesn't happen on x86-64 It's not new to 4.3 but with the flashy string op infrastructure one could hope that b) would be taken care of :) -- Summary: missed optimization, large stack frame, oodles of upfront movl $0 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbptbp at gmail dot com GCC host triplet: x86* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30627
[Bug c++/30627] missed optimization, large stack frame, oodles of upfront movl $0
--- Comment #1 from tbptbp at gmail dot com 2007-01-29 12:08 --- Created an attachment (id=12975) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12975action=view) fat testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30627
[Bug c/30628] New: ICE with __may_alias__ attribute.
[EMAIL PROTECTED] tmp]$ cat may_alias.c typedef unsigned int T1[1]; typedef T1 __attribute__((__may_alias__)) T1A; [EMAIL PROTECTED] tmp]$ ~/try/bin/gcc -c -g may_alias.c -o may_alias.o -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/home/osv/try Thread model: posix gcc version 4.1.1 /home/osv/try/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v may_alias.c -quiet -dumpbase may_alias.c -mtune=pentiumpro -auxbase-strip may_alias.o -g -version -o /tmp/cc7vnJKn.s ignoring nonexistent directory /home/osv/try/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /home/osv/try/include /home/osv/try/lib/gcc/i686-pc-linux-gnu/4.1.1/include /usr/include End of search list. GNU C version 4.1.1 (i686-pc-linux-gnu) compiled by GNU C version 4.0.2 20051125 (Red Hat 4.0.2-8). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 024b74b82ea166b936dc5fd3b214e11c may_alias.c:2: internal compiler error: in modified_type_die, at dwarf2out.c:8463 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED] tmp]$ -- Summary: ICE with __may_alias__ attribute. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: osv at javad dot com 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=30628
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #8 from dir at lanl dot gov 2007-01-29 13:45 --- It hangs on a Intel iMac - [pactech01:~/tests] dir% gfortran -o recursiveio recursiveio.f90 [pactech01:~/tests] dir% recursiveio test 1.00 ^C [pactech01:~/tests] dir% cat recursiveio.f90 external fun real fun real a a = fun() print *, a print *, fun() end real function fun() print *, 'test' fun = 1.0 end [dranta:~] dir% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug c++/29993] typdef declaration of cv-qualified function in class
--- Comment #3 from doug dot gregor at gmail dot com 2007-01-29 13:50 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01828.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29993
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #9 from dominiq at lps dot ens dot fr 2007-01-29 14:13 --- Subject: Re: recursive I/O hangs under OSX 10.3 It hangs on a Intel iMac Thanks for the answer. So it hangs for the different flavor of OSX, but not for x86_64-unknown-linux-gnu (4.3.0 20061231) and i386-pc-linux-gnu (4.3.0 20070129). What about the other supported OS and architecture? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug target/30406] ICE in LOGICAL(8) functions
--- Comment #25 from dominiq at lps dot ens dot fr 2007-01-29 15:13 --- What is the fate of the patch in comment #22? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
[Bug target/30406] ICE in LOGICAL(8) functions
--- Comment #26 from fxcoudert at gcc dot gnu dot org 2007-01-29 15:30 --- (In reply to comment #25) What is the fate of the patch in comment #22? I suppose Andrew should submit it for review by the PowerPC maintainers. If he doesn't have time, you could do it (unless he objects): bootstrap and regtest the patch (complete regtest, not only Fortran), post the patch (with ChangeLog entry and a testcase for addition to our testsuite) to gcc-patches, CCing the PowerPC maintainers (Geoff Keating and David Edelsohn), asking for it to be reviewed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-01-10 08:11:39 |2007-01-29 15:30:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
[Bug middle-end/27657] [4.2/4.3 regression] bogus undefined reference error to static var with -g and -O
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-01-29 15:43
---
I'm testing
Index: dwarf2out.c
===
--- dwarf2out.c (revision 121287)
+++ dwarf2out.c (working copy)
@@ -10045,8 +10045,14 @@ reference_to_unused (tree * tp, int * wa
if (DECL_P (*tp) ! TREE_PUBLIC (*tp) ! TREE_USED (*tp)
! TREE_ASM_WRITTEN (*tp))
return *tp;
- else
-return NULL_TREE;
+ else if (DECL_P (*tp))
+{
+ struct varpool_node *node = varpool_node (*tp);
+ if (!node-needed)
+ return *tp;
+}
+
+ return NULL_TREE;
}
/* Generate an RTL constant from a decl initializer INIT with decl type TYPE,
--
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|NEW |ASSIGNED
Last reconfirmed|2006-08-27 22:32:58 |2007-01-29 15:43:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug debug/30629] New: [Regression:4.3/4.2] -g causes undefined references
Consider this testcase:
=== Cut ===
static int hacky_auxmaps[2];
static signed int auxmap_used = 0;
static int *auxmap = hacky_auxmaps[0];
static void
mc_pre_reg_read ( unsigned size)
{
vgPlain_message (memcheck: auxmaps: %d auxmap entries in use, auxmap_used);
}
=== Cut ===
compiling it with -O2 -g results in an undefined reference to hacky_auxmaps.
just compiling with -O2 or with -O0 fixes it.
--
Summary: [Regression:4.3/4.2] -g causes undefined references
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
GCC host triplet: i686-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30629
[Bug middle-end/27657] [4.2/4.3 regression] bogus undefined reference error to static var with -g and -O
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-01-29 15:49 --- *** Bug 30629 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mueller at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug debug/30629] [Regression:4.3/4.2] -g causes undefined references
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-29 15:49 --- Dup of PR27657. *** This bug has been marked as a duplicate of 27657 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30629
[Bug c/30313] [4.1/4.2/4.3 Regression] sizeof of expression including bit-field
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-29 16:13 --- We also are 'in_gimple_form', so non_lvalue doesn't do anything on us in non-unit-at-a-time mode. With -funit-at-a-time the testcase is fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30313
[Bug c/30313] [4.1/4.2/4.3 Regression] sizeof of expression including bit-field
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-01-29 16:16 --- I'm testing the following: Index: passes.c === *** passes.c(revision 121287) --- passes.c(working copy) *** execute_one_pass (struct tree_opt_pass * *** 1054,1059 --- 1054,1062 dump_file = NULL; } + /* Reset in_gimple_form to not break non-unit-at-a-time mode. */ + in_gimple_form = false; + return true; } -- 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|NEW |ASSIGNED Last reconfirmed|2006-12-28 03:05:44 |2007-01-29 16:16:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30313
[Bug c++/28266] [4.0/4.1/4.2/4.3 regression] ICE on invalid default variable
--- Comment #3 from jason at gcc dot gnu dot org 2007-01-29 16:27 --- Subject: Bug 28266 Author: jason Date: Mon Jan 29 16:27:21 2007 New Revision: 121288 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121288 Log: PR c++/28266 * gimplify.c (gimplify_target_expr): Make sure that the TARGET_EXPR is expanded only once even if an error occurs. Added: trunk/gcc/testsuite/g++.dg/parse/defarg12.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28266
[Bug tree-optimization/30630] New: Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
GCC 4.3 compiler revision 121206 goes into infinitive loop while compiling cpu2k6/perlbench source file regcomp.c at -O2 optimization level on x86_64-redhat-linux. GDB attached to cc1 process, gives the hang point: 0x00711bd8 in solve_graph (graph=0xd37150) at /home/testbot/bootstrap/009454/src/gcc/tree-ssa-structalias.c:1619 1619if (!TEST_BIT (ti-visited, i) find (i) == i) You can find the minimal reproducer attached. This regression is caused by Rewrite of portions of points-to solver patch http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01541.html revision 120931 http://gcc.gnu.org/viewcvs?view=revrevision=120931 -- Summary: Trunk GCC hangs while compiling cpu2k6/perlbench at -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grigory_zagorodnev at linux dot intel dot com GCC host triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug tree-optimization/30630] Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
--- Comment #1 from grigory_zagorodnev at linux dot intel dot com 2007-01-29 16:47 --- Created an attachment (id=12976) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12976action=view) Minimal reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug tree-optimization/30631] New: Trunk GCC fails to compile cpu2k6/dealII at -O2
GCC 4.3 compiler revision 121206 gets ICE while compiling cpu2006/447.dealII source file data_out_base.cc at -O2 optimization level on x86_64-redhat-linux. Similar to previously reported cpu2k6/perlbench failure, this regression is caused by Rewrite of portions of points-to solver patch http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01541.html (revision 120931). Error log is listed below. data_out_base.cc: In static member function 'static void DataOutBase::write_vtk(const std::vectorDataOutBase::Patchdim, spacedim, std::allocatorDataOutBase::Patchdim, spacedim , const std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , const DataOutBase::VtkFlags, std::ostream) [with int dim = 3, int spacedim = 4]': data_out_base.cc:2949: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'reduc_max_expr' in add_call_clobber_ops, at tree-ssa-operands.c:1780 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: Trunk GCC fails to compile cpu2k6/dealII at -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grigory_zagorodnev at linux dot intel dot com GCC host triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30631
[Bug tree-optimization/30631] Trunk GCC fails to compile cpu2k6/dealII at -O2
--- Comment #1 from grigory_zagorodnev at linux dot intel dot com 2007-01-29 16:51 --- Failing source file contains ~3500 lines of C++ code. That would take a while to get a minimal reproducer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30631
[Bug c/30628] ICE with __may_alias__ attribute.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-29 16:52 --- Dup of PR29436. *** This bug has been marked as a duplicate of 29436 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30628
[Bug debug/29436] [4.0/4.1/4.2/4.3 Regression] ICE in modified_type_die
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-01-29 16:52 --- *** Bug 30628 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||osv at javad dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug tree-optimization/30630] Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-29 16:56 --- Confirmed. We're iterating a lot (gdb) #3 0x00959baa in solve_graph (graph=0x11f58c0) at /space/rguenther/src/svn/trunk/gcc/tree-ssa-structalias.c:2043 2043 compute_topo_order (graph, ti); (gdb) print stats.iterations $1 = 11197125 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 16:56:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #6 from jconner at gcc dot gnu dot org 2007-01-29 16:58 --- Subject: Bug 29683 Author: jconner Date: Mon Jan 29 16:58:04 2007 New Revision: 121289 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121289 Log: 2007-01-29 Josh Conner [EMAIL PROTECTED] PR middle-end/29683 * calls.c (compute_argument_addresses): Set stack and stack_slot for partial args, too. (store_one_arg): Use locate.size.constant for the size when generating a save_area. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/calls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug tree-optimization/30631] Trunk GCC fails to compile cpu2k6/dealII at -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-29 16:59 --- Can you nevertheless attach preprocessed source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30631
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #7 from jconner at gcc dot gnu dot org 2007-01-29 16:59 --- Subject: Bug 29683 Author: jconner Date: Mon Jan 29 16:59:35 2007 New Revision: 121290 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121290 Log: 2007-01-29 Josh Conner [EMAIL PROTECTED] PR middle-end/29683 * gcc.dg/pr29683.c: New. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr29683.c Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #8 from jconner at gcc dot gnu dot org 2007-01-29 17:08 --- Subject: Bug 29683 Author: jconner Date: Mon Jan 29 17:08:31 2007 New Revision: 121291 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121291 Log: 2007-01-29 Josh Conner [EMAIL PROTECTED] PR middle-end/29683 * calls.c (compute_argument_addresses): Set stack and stack_slot for partial args, too. (store_one_arg): Use locate.size.constant for the size when generating a save_area. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/calls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #9 from jconner at gcc dot gnu dot org 2007-01-29 17:09 --- Subject: Bug 29683 Author: jconner Date: Mon Jan 29 17:09:38 2007 New Revision: 121292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121292 Log: 2007-01-29 Josh Conner [EMAIL PROTECTED] PR middle-end/29683 * gcc.dg/pr29683.c: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr29683.c Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #10 from jconner at apple dot com 2007-01-29 17:11 --- Same fix that was applied to mainline resolved the issue in 4.1 and 4.2 branches. Checked in to both of those branches. -- jconner at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug tree-optimization/30630] Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-01-29 17:25 --- Subject: Bug 30630 Author: dberlin Date: Mon Jan 29 17:25:04 2007 New Revision: 121295 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121295 Log: 2007-01-29 Daniel Berlin [EMAIL PROTECTED] PR tree-optimization/30630 * tree-ssa-structalias.c (do_complex_constraint): Mark correct variable as changed. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20070129.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug tree-optimization/30630] Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-01-29 17:25 --- Fixed -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug tree-optimization/30559] [4.3 Regression] compiler loops forever with flag -O3
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-29 18:01 --- Can you try after: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121295 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-29 18:08 --- (In reply to comment #9) I will submit two patches. The first one will remove the function. Then, I have to regtest the second one: perhaps we find another unused function! Another one: genautomata.c: static int longest_path_length (state_t state) Should also be removed completely? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #11 from stevenb dot gcc at gmail dot com 2007-01-29 18:22 --- Subject: Re: -Wunused doesn't warn about static function only called by itself. If it is unused, don't hesitate to remove it. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug tree-optimization/30631] Trunk GCC fails to compile cpu2k6/dealII at -O2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30631
[Bug libgcj/30570] Word DEBUG used as a variable in VMAccessController.java breaks build
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-29 19:03 --- Hmm, we use DEBUG in java-assert.h. That is a bit unfriendly. Anyway if this define is coming from a system header, the traditional fix is to #undef it somewhere. Typically this is done in the platform flavor's header file, e.g., libjava/include/win32.h. We already have #undef STRICT there... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30570
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
-- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 19:03:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-29 19:07 --- Created an attachment (id=12977) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12977action=view) proposed patch Please try this patch. Now we look for magic_t and, if not found, we disable the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug java/30607] gcj -I x -C doesn't include x as source dir search patch
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-29 19:16 --- I didn't realize that -I's argument could be separate, but now I see this in c.opt: I C ObjC C++ ObjC++ Joined Separate -I dirAdd dir to the end of the main include path -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 19:16:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30607
[Bug java/30607] gcj -I x -C doesn't include x as source dir search patch
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-29 19:34 --- Tetsing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-29 19:16:32 |2007-01-29 19:34:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30607
[Bug java/30035] libjava cannot be built when objdir != srcdir
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30035
[Bug libgcj/30071] make install fails for libjava
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-29 20:00 --- We can't modify the Makefile.in, since those changes will be lost the next time someone runs automake. Could you try adding this to Makefile.am and then re-running automake? (If you can't re-run automake, let me know and I will send you a patch.) install-binPROGRAMS: install-toolexeclibLTLIBRARIES This is not really supported by automake, but really this is working around an automake bug anyhow. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 20:00:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30071
[Bug java/30292] ICE on compiling .java by gcc(1)
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-29 20:03 --- I thought I'd point out that you'll have to submit this patch the usual way; patches generally aren't reviewed in bugzilla. Also since this is a driver patch it probably won't get attention by the appropriate people, since it is filed as a java bug. -- tromey 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-01-29 20:03:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30292
