[Bug fortran/29389] Statement functions are not recognized as pure when they are
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-15 08:16 --- Subject: Bug 29389 Author: pault Date: Mon Jan 15 08:16:17 2007 New Revision: 120790 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120790 Log: 2007-01-15 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28172 * trans-stmt.c (gfc_trans_call): If it does not have one, get a backend_decl for an alternate return. PR fortran/29389 * resolve.c (pure_function): Statement functions are pure. Note that this will have to recurse to comply fully with F95. PR fortran/29712 * resolve.c (resolve_function): Only a reference to the final dimension of an assumed size array is an error in an inquiry function. PR fortran/30283 * resolve.c (resolve_function): Make sure that the function expression has a type. 2007-01-15 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28172 * gfortran.dg/altreturn_4.f90: New test. PR fortran/29389 * gfortran.dg/stfunc_4.f90: New test. PR fortran/29712 * gfortran.dg/bound_2.f90: Reinstate commented out line. * gfortran.dg/initialization_1.f90: Change warning. PR fortran/30283 * gfortran.dg/specification_type_resolution_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/altreturn_4.f90 trunk/gcc/testsuite/gfortran.dg/specification_type_resolution_2.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bound_2.f90 trunk/gcc/testsuite/gfortran.dg/initialization_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29389
[Bug fortran/29712] UBOUND of non-last dimensions of assumed-size array
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-15 08:16 --- Subject: Bug 29712 Author: pault Date: Mon Jan 15 08:16:17 2007 New Revision: 120790 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120790 Log: 2007-01-15 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28172 * trans-stmt.c (gfc_trans_call): If it does not have one, get a backend_decl for an alternate return. PR fortran/29389 * resolve.c (pure_function): Statement functions are pure. Note that this will have to recurse to comply fully with F95. PR fortran/29712 * resolve.c (resolve_function): Only a reference to the final dimension of an assumed size array is an error in an inquiry function. PR fortran/30283 * resolve.c (resolve_function): Make sure that the function expression has a type. 2007-01-15 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28172 * gfortran.dg/altreturn_4.f90: New test. PR fortran/29389 * gfortran.dg/stfunc_4.f90: New test. PR fortran/29712 * gfortran.dg/bound_2.f90: Reinstate commented out line. * gfortran.dg/initialization_1.f90: Change warning. PR fortran/30283 * gfortran.dg/specification_type_resolution_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/altreturn_4.f90 trunk/gcc/testsuite/gfortran.dg/specification_type_resolution_2.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bound_2.f90 trunk/gcc/testsuite/gfortran.dg/initialization_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29712
[Bug fortran/28172] alternate return in contained procedure segfaults
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-15 08:16 --- Subject: Bug 28172 Author: pault Date: Mon Jan 15 08:16:17 2007 New Revision: 120790 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120790 Log: 2007-01-15 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28172 * trans-stmt.c (gfc_trans_call): If it does not have one, get a backend_decl for an alternate return. PR fortran/29389 * resolve.c (pure_function): Statement functions are pure. Note that this will have to recurse to comply fully with F95. PR fortran/29712 * resolve.c (resolve_function): Only a reference to the final dimension of an assumed size array is an error in an inquiry function. PR fortran/30283 * resolve.c (resolve_function): Make sure that the function expression has a type. 2007-01-15 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28172 * gfortran.dg/altreturn_4.f90: New test. PR fortran/29389 * gfortran.dg/stfunc_4.f90: New test. PR fortran/29712 * gfortran.dg/bound_2.f90: Reinstate commented out line. * gfortran.dg/initialization_1.f90: Change warning. PR fortran/30283 * gfortran.dg/specification_type_resolution_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/altreturn_4.f90 trunk/gcc/testsuite/gfortran.dg/specification_type_resolution_2.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bound_2.f90 trunk/gcc/testsuite/gfortran.dg/initialization_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28172
[Bug fortran/30283] Specification expression not properly recognized in declaration
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-15 08:16 --- Subject: Bug 30283 Author: pault Date: Mon Jan 15 08:16:17 2007 New Revision: 120790 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120790 Log: 2007-01-15 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28172 * trans-stmt.c (gfc_trans_call): If it does not have one, get a backend_decl for an alternate return. PR fortran/29389 * resolve.c (pure_function): Statement functions are pure. Note that this will have to recurse to comply fully with F95. PR fortran/29712 * resolve.c (resolve_function): Only a reference to the final dimension of an assumed size array is an error in an inquiry function. PR fortran/30283 * resolve.c (resolve_function): Make sure that the function expression has a type. 2007-01-15 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28172 * gfortran.dg/altreturn_4.f90: New test. PR fortran/29389 * gfortran.dg/stfunc_4.f90: New test. PR fortran/29712 * gfortran.dg/bound_2.f90: Reinstate commented out line. * gfortran.dg/initialization_1.f90: Change warning. PR fortran/30283 * gfortran.dg/specification_type_resolution_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/altreturn_4.f90 trunk/gcc/testsuite/gfortran.dg/specification_type_resolution_2.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bound_2.f90 trunk/gcc/testsuite/gfortran.dg/initialization_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30283
[Bug fortran/29389] Statement functions are not recognized as pure when they are
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-15 08:19 ---
> Author: pault
> Date: Mon Jan 15 08:16:17 2007
> New Revision: 120790
As pointed out by FX on the list, this patch does not quite do it yet:
The F95 standard says (12.6): "A pure procedure is [...] or (4) A statement
function that references only pure functions." Not all statement functions are
pure. Are you sure that check ("references only pure functions") is performed
by your patch?
I'll do this asap.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29389
[Bug target/24669] Loop index variable has offset of 1
--- Comment #6 from ubizjak at gmail dot com 2007-01-15 08:46 --- (In reply to comment #2) > The fact that the index variable is chosen to start with 1 instead of zero is > more interesting. It does not really matter that much, since both > possibilities have exactly the same cost. But the reason is that target > description pretends that the more complicated addressing mode is in fact > cheaper, thus misguiding ivopts to prefer it to the simpler one, if everything > else is equal. I tried to change values in ix86_address_cost() function, and I was able to fix this annoyance. However, gcc regressed in other areas (in some cases, it didn't produce offsets for symbol access) so this isn't proper solution either. Perhaps in case of same cost, should some generic preference be implemented in ivopts to choose "simpler" addressing mode, as simpler addressing modes usually result in smaller code? > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug middle-end/30421] incorrect warning when using firstprivate and lastprivate clauses
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-15 08:55 --- Thanks for your patch but if you want it to be reviewed, it is better to send it to [EMAIL PROTECTED] . -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30421
[Bug c++/30470] New: Compiling C++ programs with -mno-80387 and -O3 failes
Compiling a program with -O3 and -mno-80387 fails when processing strtold in stdlib.h even though it's not actually invoked. -- Summary: Compiling C++ programs with -mno-80387 and -O3 failes Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugzilla at bennee dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #1 from bugzilla at bennee dot com 2007-01-15 09:14 --- Created an attachment (id=12905) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12905&action=view) Testcase C++ source Source code of failing example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug fortran/30438] Unused variable should raise warning with -Wunused
--- Comment #3 from aldot at gcc dot gnu dot org 2007-01-15 09:15 --- (In reply to comment #2) > The variable is set but not read from. > There is another bug about this for the C/C++ front-ends and a new option for > this case instead of just using -Wunused. > > I would considered t in comment #1 as being used as it is set. I'd prefer this to be diagnosed to be "set but never used" in Fortran and C along the lines of the "value computed is not used" diagnostics that is emitted in C. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30438
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #2 from bugzilla at bennee dot com 2007-01-15 09:15 --- Created an attachment (id=12906) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12906&action=view) --save-temps output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #3 from bugzilla at bennee dot com 2007-01-15 09:17 --- Output of failed compile: 09:09 [EMAIL PROTECTED] [no387] > g++-4.1 --save-temps -O3 -mno-80387 no387.cc /usr/include/stdlib.h: In function long double strtold(const char*, char**): /usr/include/stdlib.h:355: error: x87 register return with x87 disabled -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #8 from irar at il dot ibm dot com 2007-01-15 10:04 --- (In reply to comment #2) > I think this whole type issue is a mess and needs some improvement. > Maybe next week I can get to that. Andrew, are you still planning to solve this, or should I prepare a fix for rs6000_builtin_mul_widen_even as suggested by Paolo in comment #1 to close PR 22372? Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug fortran/24524] Fortran dependency checking should reverse loops
--- Comment #1 from pault at gcc dot gnu dot org 2007-01-15 10:14 --- I posted a prototype fix for this a few months ago: http://gcc.gnu.org/ml/fortran/2006-10/msg00173.html and subsequent thread. It will not take much to complete and correct it but I do not have overmuch time right now. I have assigned it to myself so that it does not get forgotten but if anybody wishes to finish the job, please feel free. Paul Roger, I have cc'd you because the only thing that needs to be corrected/improved is the part in dependency.c -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-05-01 06:12:26 |2007-01-15 10:14:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24524
[Bug fortran/25708] Module loading is not good at all
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-15 10:27 --- This is the one that I said that I would take on for the next few months. I will try to implement the manifesto in #5 and have the F2003 specification for sub-modules with me. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-31 07:00:40 |2007-01-15 10:27:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
[Bug libgomp/30471] New: OpenMP with static linking fails in fortran on amd64
I'm trying to use Fortran OpenMP on AMD64 with static linking: simple.f90: program launch !$OMP PARALLEL write (*,*) "foo" !$OMP END PARALLEL end program launch $ gfortran-4.2 simple.f90 -fopenmp -static -lgomp $ ./a.out zsh: segmentation fault (core dumped) ./a.out ¤ gfortran-4.2 simple.f90 -fopenmp -lgomp ¤ ./a.out foo foo foo foo ¤ gfortran-4.2 simple.f90 -static -lgomp ¤ ./a.out foo This happens with fortran and on amd64 only, C or i386 work fine, so it looks like this is the combination of fortran+openmp+static+amd64. -- Summary: OpenMP with static linking fails in fortran on amd64 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2007-01-15 13:23 --- Ah, though gdb fails when directly running a.out, it works via the core file: (gdb) bt #0 0x in ?? () #1 0x00405dd6 in get_external_unit () #2 0x00404abd in data_transfer_init () #3 0x004002f8 in MAIN__.omp_fn.0 (.omp_data_i=0x0) at simple.f90:19 #4 0x004002aa in MAIN__ () at simple.f90:16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #2 from samuel dot thibault at ens-lyon dot org 2007-01-15 13:28 --- Note: line 16 of the program is "program launch", and line 19 of the program is the write call -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #3 from samuel dot thibault at ens-lyon dot org 2007-01-15 13:32 --- Note: line 16 of the program is "program launch", and line 19 of the program is the write call -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug middle-end/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #9 from schwab at suse dot de 2007-01-15 13:38 --- Any news on this one? AFAICS Richard Sandiford was ok with the patch. -- schwab at suse dot de changed: What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/30472] New: [4.1 Regression] ICE in output_operand: invalid expression as operand [stabs]
./cc1plus -quiet -O2 -fPIC -gstabs /tmp/t.ii
t.cpp: In constructor 'CsoundGlobalSettings::CsoundGlobalSettings()':
t.cpp:43: internal compiler error: output_operand: invalid expression as
operand
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
#2 0x00667c82 in output_addr_const (file=0xec2670, x=0x2b06d6ddbee0)
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/final.c:3337
3337 output_operand_lossage ("invalid expression as operand");
(gdb) list
3332 OUTPUT_ADDR_CONST_EXTRA (file, x, fail);
break;
3334
3335fail:
3336#endif
3337 output_operand_lossage ("invalid expression as operand");
3338}
3339}
3340^L
3341/* A poor man's fprintf, with the added features of %I, %R, %L, and %U.
(gdb) print x
$1 = (rtx) 0x2b06d6ddbee0
(gdb) call debug_rtx (x)
(unspec:DI [
(symbol_ref:DI ("_ZNSs4_Rep20_S_empty_rep_storageE") [flags 0x40]
)
] 2)
(gdb)
#0 internal_error (gmsgid=0xa863b6 "%s")
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/diagnostic.c:546
#1 0x00666cb9 in output_operand_lossage (
cmsgid=0xa864f5 "invalid expression as operand")
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/final.c:2835
#2 0x00667c82 in output_addr_const (file=0xec2670, x=0x2b06d6ddbee0)
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/final.c:3337
#3 0x005eba51 in dbxout_finish_complex_stabs (sym=0x2b06d6b92630,
code=N_LCSYM, addr=0x2b06d6ddbee0, label=0x0, number=0)
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/dbxout.c:896
#4 0x005f25e6 in dbxout_symbol_location (decl=0x2b06d6b92630,
type=0x2b06d65820b0, suffix=0x0, home=0x2b06d6da47e0)
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/dbxout.c:2967
#5 0x005f1ff1 in dbxout_symbol (decl=0x2b06d6b92630, local=1)
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/dbxout.c:2717
happens with -gstabs only. Works with 3.3 hammer branch.
--
Summary: [4.1 Regression] ICE in output_operand: invalid
expression as operand [stabs]
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30472
[Bug target/30472] [4.1 Regression] ICE in output_operand: invalid expression as operand [stabs]
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-15 14:33 ---
#include
class CsoundGlobalSettings {
public:
std::string textEditorProgram;
std::string soundEditorProgram;
std::string helpBrowserProgram;
std::string performanceSettings1_Name;
std::string performanceSettings2_Name;
std::string performanceSettings3_Name;
std::string performanceSettings4_Name;
std::string performanceSettings5_Name;
std::string performanceSettings6_Name;
std::string performanceSettings7_Name;
std::string performanceSettings8_Name;
std::string performanceSettings9_Name;
std::string performanceSettings10_Name;
boolforcePerformanceSettings;
booleditSoundFileAfterPerformance;
// -
CsoundGlobalSettings();
~CsoundGlobalSettings();
};
CsoundGlobalSettings::CsoundGlobalSettings()
{
textEditorProgram = "xterm -e vim";
soundEditorProgram = "audacity";
helpBrowserProgram =
"firefox /usr/local/share/doc/csound/manual/index.html";
performanceSettings1_Name = "";
performanceSettings2_Name = "";
performanceSettings3_Name = "";
performanceSettings4_Name = "";
performanceSettings5_Name = "";
performanceSettings6_Name = "";
performanceSettings7_Name = "";
performanceSettings8_Name = "";
performanceSettings9_Name = "";
performanceSettings10_Name = "";
forcePerformanceSettings = false;
editSoundFileAfterPerformance = false;
}
CsoundGlobalSettings::~CsoundGlobalSettings()
{
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.2
Known to work||3.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30472
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #4 from ubizjak at gmail dot com 2007-01-15 15:24 --- Testcase compiles OK with gcc version 4.3.0 20070115 (experimental). -- ubizjak at gmail dot com changed: What|Removed |Added Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #58 from zaks at il dot ibm dot com 2007-01-15 15:30 --- (In reply to comment #57) > Subject: Re: [4.1 regression] A file that can not be > compiled in reasonable time/space > Thanks! Very useful comments. I'm continuing to work on cleaning the > patch (especially on writing the comments) Enjoy! One suggestion that may help explain the data-structure, is to provide a drawing of ddn with its dep and nodes connected. > > o dep_node_def: this is a node in a (doubly-linked) chain, but it > > represents an > > *edge* in terms of the data-dependence graph. The prev_nextp field is a "/* > Right! I struggled to figure out the correct name and didn't prevail. > Thanks for the tip. It'll be dep_edge. Ah, on second thought, perhaps the important property of this struct is the fact that it's a link on a forward or backward chain; so how about dep_link? > > Pointer to the next field of the previous node in the list. */" except for > > the > > first node on the list, whose prev_nextp points to itself, right? > No. Prev_nextp field of the first node points to deps_list->first. > This allows us not to distinguish first node from the others. I'll fix > the comment. Ah, right. > > > > o dep_data_node_def: holding the two conjugate dependence edges together is > > very useful when switching directions. But perhaps most of the accesses go > > in > > one direction (e.g. iterating over cons of a pro), and having both > > conjugates > > structed together may reduce cache efficiency. So you may consider > > connecting > > each dep_node_def to its conjugate, not necessarily forcing them to be > > placed > > adjacent in memory. > Dep_def and both edges were placed in one structure so that they could > be allocated and freed within a single alloc/free. As I understand you > propose putting two pointers inside dep_edge_def: one to the dep_def and > one to the opposite edge. Currently we have one pointer in dep_edge_def > to the dep_data_node which have all that pointers. And probably I'm > missing something, but I don't see how your way can improve cache > efficiency. You're right. There's probably not much to gain if anything paying an extra pointer to save the fields of the conjugate dep_node. Perhaps only place dep_def between back and forw (been too much into struct-reorg, I guess :). It does seem wasteful to hold two 'data' pointers for such nearby offsets ... ;) And another note: INSN_DEPS may be renamed INSN_BACK_DEPS to better distinguish it from INSN_DEPEND (which in turn might be called INSN_FORW_DEPS). And maybe INSN_RESOLVED_BACK_DEPS for consistency. Ayal. -- zaks at il dot ibm dot com changed: What|Removed |Added CC||zaks at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug bootstrap/30136] bootstrap fail for 4.3-20061209
--- Comment #5 from as7cf at yahoo dot com 2007-01-15 16:10 --- I can confirm this problem on recent snapshots as well (20070105 and 20070112). I'm also on x86_64. Bootstrap fails with that same message. Configuring GCC with: --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.98-alpha20070112 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.98-alpha20070112/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.98-alpha20070112 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.98-alpha20070112/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.98-alpha20070112/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.98-alpha20070112/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --enable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30136
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #7 from gdr at cs dot tamu dot edu 2007-01-15 16:14 --- Subject: Re: [regression] -Wconversion triggers warnings for deque<>::push_back() "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | (In reply to comment #5) | > Sorry I read your reply later. | > | > So, that is it, isn't it? Wsystem-headers needs to be fixed since we don't want | > to emit warnings for system headers even if those warnings are correct. | | Well, first we don't know when, how, if, the pragma system_header will be ever | fixed. Then, assuming the warning is correct, certainly we want to adjust the | library, that, in my opinion, makes certainly for good engineering (in fact, we | are generally relying on the effect of the pragma only in very few, | last-resort, situations). Alternately, never emit the warning, of course. I agree with Paolo that we use the system_header hack only as a last resort -- in general. However, there is a fundamental tension between unsigned and use in the the C++ standard library and in libstdc++ in particular. Many, among whom the designers of C++, consider most uses of unsigned as indices or sizes as mistake (alas, the LWG did not listen). I'm sure middle-end people could argue that they can generate better codes if signed is used instead -- but that is a different issue :-) For libstdc++, we need to understand what gaurantees we give for max_size() -- e.g. can we really handle elements that fill up the whole range of size_type? If yes, then the warning is good in the sense that it draws our attention to an untenable promise. If not, then the warning isn't that useful -- well, in some sense it is useful as it would force us to introduce more casts than we would like. No wonder why people introduced ssize_t :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug target/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-15 17:03 --- and this is a bug why? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #6 from bugzilla at bennee dot com 2007-01-15 17:34 --- (In reply to comment #5) > and this is a bug why? > Well for starters why should the act of #include'ing stdlib.h cause any instructions to be emitted if strtold isn't even invoked? I don't understand exactly what the relationship between the -O options and -mno-80387 is. I got lost in a maze of glibc headers trying to work out exactly what getting instantiated. As far as I can tell it boils down to (gccs?) internal implementation of strtold. However if the -mno-80387 option is meant to disable x87 instructions then it should be possible to build something without causing and x87 instructions to be emitted shouldn't it? The reason I want to disable the x87 is otherwise Signalling NaN's can get silently supressed being passed through the x87 unit. I didn't want that and wanted my SIGFPE's to be generated in some SSE code I had written. Or does your question imply this is not gcc's problem but something in glibc? -- bugzilla at bennee dot com changed: What|Removed |Added Component|target |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-15 17:44 --- >Well for starters why should the act of #include'ing stdlib.h cause any > instructions to be emitted if strtold isn't even invoked? Not really. >However if the -mno-80387 option is meant to disable x87 instructions then it > should be possible to build something without causing and x87 instructions to > be emitted shouldn't it? Yes and that means you can not use (or reference, even via a prototype) any function that would cause x87 which is all functions which return a float/double. >The reason I want to disable the x87 is otherwise Signalling NaN's can get > silently supressed being passed through the x87 unit. I didn't want that and > wanted my SIGFPE's to be generated in some SSE code I had written. You cannot without changing the ABI and changing the abi would mean you can't do any thing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c/30473] New: Internal Compiler Error with a sprintf with few arguments for format %s
/* crash_builtin_sprintf.c */
#include
int main(void){
char buffer[10];
sprintf(buffer, "%s");
return 0;
}
$ gcc-4.1 -v -da -Q crash_builtin_sprintf.c
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/avega/morfeo/gcc_4_1_1_release/configure
--prefix=/home/avega/shared/gcc-4.1 --disable-multilib --verbose
--program-suffix=-4.1 --enable-checking --enable-languages=c,c++
Thread model: posix
gcc version 4.1.1
/home/avega/shared/gcc-4.1/libexec/gcc/x86_64-unknown-linux-gnu/4.1.1/cc1 -v
crash_builtin_sprintf.c -dumpbase crash_builtin_sprintf.c -da -mtune=k8
-auxbase crash_builtin_sprintf -version -o /tmp/ccqb7Log.s
ignoring nonexistent directory
"/home/avega/shared/gcc-4.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/home/avega/shared/gcc-4.1/include
/home/avega/shared/gcc-4.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/include
/usr/include
End of search list.
GNU C version 4.1.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed: -v -mtune=k8 -auxbase
options enabled: -falign-loops -fargument-alias
-fasynchronous-unwind-tables -fbranch-count-reg -fcommon -fearly-inlining
-feliminate-unused-debug-types -ffunction-cse -fgcse-lm -fident
-finline-functions-called-once -fivopts -fkeep-static-consts
-fleading-underscore -floop-optimize2 -fmath-errno -fpeephole
-freg-struct-return -fsched-interblock -fsched-spec
-fsched-stalled-insns-dep -fshow-column -fsplit-ivs-in-unroller
-ftrapping-math -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize
-ftree-vect-loop-version -funwind-tables -fvar-tracking
-fzero-initialized-in-bss -m128bit-long-double -m64 -m80387
-maccumulate-outgoing-args -malign-stringops -mfancy-math-387
-mfp-ret-in-387 -mieee-fp -mmmx -mpush-args -mred-zone -msse -msse2
-mtls-direct-seg-refs
Compiler executable checksum: 8e360ce3bdb591fc08bf895e5092364f
main
crash_builtin_sprintf.c: In function ‘main’:
crash_builtin_sprintf.c:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ gdb ~/shared/gcc-4.1/libexec/gcc/x86_64-unknown-linux-gnu/4.1.1/cc1
GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db
library "/lib64/tls/libthread_db.so.1".
(gdb) set args crash_builtin_sprintf.c
(gdb) r
Starting program:
/home/avega/shared/gcc-4.1/libexec/gcc/x86_64-unknown-linux-gnu/4.1.1/cc1
crash_builtin_sprintf.c
main
Program received signal SIGSEGV, Segmentation fault.
0x0050ef55 in fold_builtin_sprintf (arglist=0x2a985fe1e0, ignored=0)
at /home/avega/morfeo/gcc_4_1_1_release/gcc/builtins.c:9883
9883 orig = TREE_VALUE (TREE_CHAIN (TREE_CHAIN (arglist)));
(gdb) where
#0 0x0050ef55 in fold_builtin_sprintf (arglist=0x2a985fe1e0,
ignored=0) at /home/avega/morfeo/gcc_4_1_1_release/gcc/builtins.c:9883
#1 0x00511adc in fold_builtin (fndecl=Variable "fndecl" is not
available.
)
at /home/avega/morfeo/gcc_4_1_1_release/gcc/builtins.c:9099
#2 0x005c0b5a in fold_ternary (code=Variable "code" is not available.
)
at /home/avega/morfeo/gcc_4_1_1_release/gcc/fold-const.c:10159
#3 0x005c1a31 in fold_build3_stat (code=CALL_EXPR, type=0x2a983f24d0,
op0=0x2a983ed1c0, op1=0x2a985fe1e0, op2=0x0)
at /home/avega/morfeo/gcc_4_1_1_release/gcc/fold-const.c:10587
#4 0x004292c1 in build_function_call (function=0x2a983ed1c0,
params=Variable "params" is not available.
)
at /home/avega/morfeo/gcc_4_1_1_release/gcc/c-typeck.c:2228
#5 0x00459ea3 in c_parser_postfix_expression_after_primary (
parser=0x2a983e9410, expr=
{value = 0x2a9846a900, original_code = ERROR_MARK})
at /home/avega/morfeo/gcc_4_1_1_release/gcc/c-parser.c:5250
#6 0x00457571 in c_parser_postfix_expression (parser=0x2a983e9410)
at /home/avega/morfeo/gcc_4_1_1_release/gcc/c-parser.c:5184
#7 0x00458159 in c_parser_unary_expression (parser=0x2a983e9410)
at /home/avega/morfeo/gcc_4_1_1_release/gcc/c-parser.c:4622
#8 0x00458ae9 in c_parser_cast_expression (parser=0x2a983e9410,
after=Variable "after" is not available.
) at /home/avega/morfeo/gcc_4_1_1_release/gcc/c-parser.c:4498
#9 0x00458c40 in c_parser_conditional_expression (
parser=0x2a983e9410, after=Variable "after" is not available.
)
at /home/avega/morfeo/gcc_4_1_1_release/gcc/
[Bug libgcj/30454] [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-15 17:55 --- How did you configure? Did you use make -j? -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
[Bug target/30474] New: Bad 16bit constant code generation on 64bit host
score_print_operand has
'U'print hi part of a CONST_INT rtx
else if (c == 'U')
{
gcc_assert (code == CONST_INT);
fprintf (file, HOST_WIDE_INT_PRINT_HEX,
(unsigned HOST_WIDE_INT) INTVAL (op) >> 16);
}
On 64bit host, for (const_int -2147483648 [0x8000]), it
will generate 0x8000.
--
Summary: Bad 16bit constant code generation on 64bit host
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: score-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30474
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-15 19:20 --- What glibc version are you using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug middle-end/30473] [4.0/4.1/4.2/4.3 Regression] Internal Compiler Error with a sprintf with few arguments for format %s
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-15 19:26 --- Confirmed, a regression from 3.4.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 GCC build triplet| x86_64-unknown-linux-gnu | GCC host triplet| x86_64-unknown-linux-gnu | GCC target triplet| x86_64-unknown-linux-gnu | Keywords||ice-on-valid-code Known to fail||4.0.3 4.0.0 4.1.0 4.1.1 Known to work||3.4.0 3.2.3 Last reconfirmed|-00-00 00:00:00 |2007-01-15 19:26:36 date|| Summary|Internal Compiler Error with|[4.0/4.1/4.2/4.3 Regression] |a sprintf with few arguments|Internal Compiler Error with |for format %s |a sprintf with few arguments ||for format %s Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30473
[Bug target/30472] [4.1 Regression] -gstabs, ICE in output_operand: invalid expression as operand
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-15 19:29 --- I don't know why anyone would want to use stabs debugging info on a 64bit target. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1 Regression] ICE in |[4.1 Regression] -gstabs, |output_operand: invalid |ICE in output_operand: |expression as operand |invalid expression as |[stabs] |operand http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30472
[Bug c/30475] New: assert(int+100 > int) optimized away
The small test program at http://ptrace.fefe.de/int.c illustrated the problem. The assert is there to prevent integer overflow, which would not happen in my test program, but you get the idea. There appears to be something wrong with integer promotion here. The same code with int changed to unsigned int (http://ptrace.fefe.de/unsignedint.c) correctly fails the assertion at that point. My understanding of C integer promotion is that the 100 is an int unless anything else is said, so int+100 should still be an int, and so both sides should still be an int. Is that not correct? -- Summary: assert(int+100 > int) optimized away Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: felix-gcc at fefe dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #1 from felix-gcc at fefe dot de 2007-01-15 19:46 --- Mhh, if I change "int+100" to "(int)(int+100)", the assert still gets optimized away. So it's not an integer promotion issue. Both sides are definitely int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug rtl-optimization/30467] [4.3 regression] Bootstrap failure: ICE in ifcvt.c
--- Comment #6 from steven at gcc dot gnu dot org 2007-01-15 19:47 --- Created an attachment (id=12907) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12907&action=view) handle "insn_b == NULL_RTX" case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-15 19:47 --- signed type overflow is undefined by the C standard, use unsigned int for the addition or use -fwrapv. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #3 from felix-gcc at fefe dot de 2007-01-15 19:50 --- even stranger, if I assert ((int)(a+100) > 0) then it STILL gets optimized away. WTF!? -- felix-gcc at fefe dot de changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/27719] ICE on invalid function definition
--- Comment #1 from aldot at gcc dot gnu dot org 2007-01-15 19:52 --- Does not seem to ICE for me on i386 with each of $ gcc-2.95 --version 2.95.4 $ gcc-3.4 --version gcc-3.4 (GCC) 3.4.6 (Debian 3.4.6-4) $ gcc-4.1 --version gcc-4.1 (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) $ gcc-4.2.orig-HEAD --version gcc-4.2.orig-HEAD (GCC) 4.2.0 20070102 (prerelease) $ gcc-4.2.orig-HEAD -c -o /dev/null bug.c bug.c:1: error: declaration of 'foo' as array of voids bug.c:1: confused by earlier errors, bailing out -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27719
[Bug libgcj/30454] [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-15 19:54 --- Subject: Re: [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.jav > How did you configure? Did you use make -j? ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --disab le-nls --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.3.0 --enable-deb ug=no --enable-threads=posix --with-mpfr=/opt/gnu/gcc/gcc-4.3.0 --with-gmp=/opt/ gnu/gcc/gcc-4.3.0 --disable-libmudflap --enable-languages="c,c++,objc,obj-c++,fo rtran,java,ada" && make -j 2 bootstrap && Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #4 from felix-gcc at fefe dot de 2007-01-15 19:57 --- (In reply to comment #2) > signed type overflow is undefined by the C standard, use unsigned int for the > addition or use -fwrapv. You have GOT to be kidding? All kinds of security issues are caused by integer wraps, and you are just telling me that with gcc 4.1 and up I cannot test for them for signed data types any more?! You are missing the point here. There HAS to be a way to get around this. Existing software uses signed int and I can't just change it to unsigned int, but I still must be able to check for a wrap! There does not appear to be a work around I could do in the source code either! Do you expect me to cast it to unsigned, shift right by one, and then add or what?! PLEASE REVERT THIS CHANGE. This will create MAJOR SECURITY ISSUES in ALL MANNER OF CODE. I don't care if your language lawyers tell you gcc is right. THIS WILL CAUSE PEOPLE TO GET HACKED. I found this because one check to prevent people from getting hacked failed. THIS IS NOT A JOKE. FIX THIS! NOW! -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/27719] ICE on invalid function definition
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-15 19:58 --- > $ gcc-4.2.orig-HEAD -c -o /dev/null bug.c > bug.c:1: error: declaration of 'foo' as array of voids > bug.c:1: confused by earlier errors, bailing out That is an ICE, just hidden by release checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27719
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-15 20:04 --- > THIS IS NOT A JOKE. FIX THIS! NOW! I am not joking, the C standard explictly says signed integer overflow is undefined behavior. See PR 27257 and others. *** This bug has been marked as a duplicate of 27257 *** -- 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=30475
[Bug c++/27257] Error integer compare in g++ 4.1.0
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-15 20:04 --- *** Bug 30475 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||felix-gcc at fefe dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #5 from samuel dot thibault at ens-lyon dot org 2007-01-15 20:12 --- glibc 2.3.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug tree-optimization/23346] [4.1/4.2/4.3 Regression] FRE before DCE makes a mess of loads or need to sink loads
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-01-15 20:15 --- Even though we now do a DCE before FRE, we still don't get this correct as we don't have we don't have aliasing (during the first DCE) so we assume all loads as violatile. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-10-10 11:58:07 |2007-01-15 20:15:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug rtl-optimization/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-15 20:20 --- On the trunk I get: movsbl b+1(%edx),%eax movsbl a+1(%edx),%edx so this has been fixed there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |address selection does not |address selection does not |work correctly |work correctly http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug fortran/30452] [4.2, 4.1 only] Strange syntax error with high-value character
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-01-15 20:27 --- Fixed on trunk, will backport to 4.2 in a week or so. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 4.1.2 Known to work||4.3.0 Summary|Strange syntax error with |[4.2, 4.1 only] Strange |high-value character|syntax error with high-value ||character http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30452
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #6 from samuel dot thibault at ens-lyon dot org 2007-01-15 20:28 --- I tried to upgrade to glibc 2.5 and gcc svn snapshot of 20070105, with same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug libobjc/30462] libobjc public headers should be wrapped with #pragam visibilitity push(defualt)/pop
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-15 21:05 --- I have a patch which also does -fvisibility=hidden. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30462
[Bug fortran/30476] New: [Regression 4.2, 4.3] Via other module imported generic interface rejected
(Based on Andrea Ferretti, http://gcc.gnu.org/ml/fortran/2007-01/msg00368.html) The following valid program is rejected with the following message: USE global_module 1 Error: Name 'hello' at (1) is an ambiguous reference to 'hello' from module 'interfaces' CALL hello(10) 1 Error: There is no specific subroutine for the generic 'hello' at (1) * * * SUBROUTINE hello_x(dum) IMPLICIT NONE INTEGER :: dum WRITE(0,*) "Hello world: ", dum END SUBROUTINE hello_x MODULE interfaces IMPLICIT NONE INTERFACE hello SUBROUTINE hello_x(dum) IMPLICIT NONE INTEGER :: dum END SUBROUTINE hello_x END INTERFACE END MODULE interfaces MODULE global_module USE interfaces END MODULE global_module PROGRAM main USE global_module IMPLICIT NONE CALL hello(10) END PROGRAM main -- Summary: [Regression 4.2, 4.3] Via other module imported generic interface rejected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30476
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #8 from dalej at apple dot com 2007-01-15 23:41 --- You are right, thanks. Test case fixed thus in mainline (to be 4.3). http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01266.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug c/30477] New: Integer Overflow detection code optimised away, -fwrapv broken
Bug originally reported against gcc 4.1.1 by Felix von Leitner,
found at http://blog.fefe.de/?ts=bb5517a4 (filed as PR #30475).
This is sort of a "follow-up" bug report, but with a
different _focus_ and a different _aim_, namely the
gcc developers, especially Andrew Pinski, to provide
a patch against older gcc versions to vendors that
wish to or must continue to use them, which unbreaks
the inability of "-fwrapv" to disable gcc optimising
away code often used in security checks added to an
existing legacy code base. These patches should be
provided publicly, so that any operating system ven-
dor who uses gcc2 or gcc3 can pick them up, because
it is not MirBSD specific.
I found out that gcc 3.4.6 (MirBSD; Propolice) and both
gcc 2.95 and 3.4.3 on DragonFly BSD are vulnerable as
well, but did not want to report that because they are
heavily patched against the FSF version.
However, Andrew Pinski writes in the following comment:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475#c2
That adding "-fwrapv" to the command line should fix this
important security issue. This, however, does not work
for me on gcc 3.4.6 (MirBSD, of course), but I've got a
shell account on a Debian GNU/Linux 4.0 box, whose sy-
stem gcc 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
indeed suppresses this optimisation with "-fwrapv".
I then downloaded gcc-core-3.4.6.tar.gz (the pristine
source), extracted and compiled it on that Debian box.
[EMAIL PROTECTED]:~/test $ bin/bin/gcc -v
Reading specs from
/home/t/tglaser/test/bin/lib/gcc/i686-pc-linux-gnu/3.4.6/specs
Configured with: ../gcc-3.4.6/configure --prefix=/home/t/tglaser/test/bin
--enable-languages=c --disable-nls --disable-shared
Thread model: posix
gcc version 3.4.6
[EMAIL PROTECTED]:~/test $ rm -f a.out; bin/bin/gcc -O0 int.c && ./a.out
200 100
a.out: int.c:4: foo: Assertion `a+100 > a' failed.
Aborted
134|[EMAIL PROTECTED]:~/test $ rm -f a.out; bin/bin/gcc -O1 int.c && ./a.out
200 100
-2147483549 2147483647
255|[EMAIL PROTECTED]:~/test $ rm -f a.out; bin/bin/gcc -O1 -fwrapv int.c &&
./a.out
200 100
-2147483549 2147483647
255|[EMAIL PROTECTED]:~/test $ cat int.c
#include
int foo(int a) {
assert(a+100 > a);
printf("%d %d\n",a+100,a);
return a;
}
int main() {
foo(100);
foo(0x7fff);
}
[EMAIL PROTECTED]:~/test $ rm -f a.out; bin/bin/gcc -Os -fwrapv int.c &&
./a.out
200 100
-2147483549 2147483647
--
Summary: Integer Overflow detection code optimised away, -fwrapv
broken
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tg at mirbsd dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
-- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dalej at apple dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #9 from dalej at apple dot com 2007-01-15 23:48 --- as per previous comment -- dalej at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug other/30465] Duplicated overflow warning
-- manu 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-15 23:48:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30465
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-15 23:56 --- Fixed in 4.0.0, 3.4.x is no longer being maintained by the FSF and has not for a while now. If you want to figure out how which patch fixed it in 4.0.0, you can do that by doing a binary regression search on the source. There has been so many patches between 3.4.x and 4.0.x it is hard to keep track of each one. If you don't want to move to a newer GCC, that is your issue. Any GCC before 3.3 does not even have -fwrapv so providing all the fixes in one patch is hard because options handling has changed a couple of time, fold-const.c changed a lot, etc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-15 23:57 --- Also why should we support older GCC when we can barrely support the current ones? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug fortran/30478] New: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/
mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/
gfortran.dg/enum_2.f90 -O -pedantic-errors -S -o enum_2.s(timeout =
300
)
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_2.f90:8
integer :: x ! { dg-error "Unexpected data declaration" }
1
Error: Unexpected data declaration statement at (1)
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_2.f90:0: internal compiler
error
: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_2.f90:8
integer :: x ! { dg-error "Unexpected data declaration" }
1
Error: Unexpected data declaration statement at (1)
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_2.f90:0: internal compiler
error
: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
PASS: gfortran.dg/enum_2.f90 -O (test for errors, line 8)
FAIL: gfortran.dg/enum_2.f90 -O (test for errors, line 9)
FAIL: gfortran.dg/enum_2.f90 -O (test for errors, line 12)
FAIL: gfortran.dg/enum_2.f90 -O (test for excess errors)
Excess errors:
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_2.f90:0: internal compiler
error
: Segmentation fault
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/
mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/
gfortran.dg/enum_3.f90 -O -pedantic-errors -S -o enum_3.s(timeout =
300
)
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_3.f90:7
enumerator :: red, black = 2.2 ! { dg-error "initialized with integer expr
1
Error: ENUMERATOR (1) not initialized with integer expression
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_3.f90:8
enumerator :: blue = "x" ! { dg-error "initialized with integer expression
1
Error: ENUMERATOR (1) not initialized with integer expression
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_3.f90:9
end enum ! { dg-error "has no ENUMERATORS" }
1
Error: ENUM declaration at (1) has no ENUMERATORS
compiler exited with status 1
output is:
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_3.f90:7
enumerator :: red, black = 2.2 ! { dg-error "initialized with integer expr
1
Error: ENUMERATOR (1) not initialized with integer expression
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_3.f90:8
enumerator :: blue = "x" ! { dg-error "initialized with integer expression
1
Error: ENUMERATOR (1) not initialized with integer expression
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_3.f90:9
end enum ! { dg-error "has no ENUMERATORS" }
1
Error: ENUM declaration at (1) has no ENUMERATORS
PASS: gfortran.dg/enum_3.f90 -O (test for errors, line 7)
PASS: gfortran.dg/enum_3.f90 -O (test for errors, line 8)
PASS: gfortran.dg/enum_3.f90 -O (test for errors, line 9)
PASS: gfortran.dg/enum_3.f90 -O (test for excess errors)
(gdb) r
Starting program: /mnt/gnu/gcc/objdir/gcc/f951
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_2.f90 -quiet -dumpbase
enum_2.f90 -auxbase-strip enum_2.s -O -pedantic-errors -version -o enum_2.s
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.
GNU F95 version 4.1.2 20070115 (prerelease) (hppa2.0w-hp-hpux11.11)
compiled by GNU C version 4.1.2 20070115 (prerelease).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_2.f90:8
integer :: x ! { dg-error "Unexpected data declaration" }
1
Error: Unexpected data declaration statement at (1)
Program received signal SIGSEGV, Segmentation fault.
0x003e75d8 in __gmpz_add_ui ()
(gdb) bt
#0 0x003e75d8 in __gmpz_add_ui ()
#1 0x0003402c in gfc_enum_initializer (last_initializer=0x400817a8, where=
{nextc = 0x0, lb = 0x0}) at ../../gcc/gcc/fortran/arith.c:2475
#2 0x000463ec in variable_decl (elem=0) at ../../gcc/gcc/fortran/decl.c:1299
#3 0x0004668c in gfc_match_enumerator_def ()
at ../../gcc/gcc/fortran/decl.c:4126
#4 0x00070b28 in match_word (str=0x7aef32e0 "",
[EMAIL PROTECTED]: 0x465b8 , old_locus=0x7eff0a6c)
at ../.
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-16 00:54 ---
\> 0x003e75d8 in __gmpz_add_ui ()
> (gdb) bt
> #0 0x003e75d8 in __gmpz_add_ui ()
> #1 0x0003402c in gfc_enum_initializer (last_initializer=0x400817a8, where=
> {nextc = 0x0, lb = 0x0}) at ../../gcc/gcc/fortran/arith.c:2475
Is your source up to date? arith.c contains 2447 lines of code.
> Dump of assembler code from 0x3e75c8 to 0x3e75e8:
> 0x003e75c8 <__gmpz_add_ui+104>: ldw -70(sp),r3
> 0x003e75cc <__gmpz_add_ui+108>: bv r0(rp)
> 0x003e75d0 <__gmpz_add_ui+112>: ldw,mb -80(sp),r7
> 0x003e75d4 <__gmpz_add_ui+116>: cmpib,>,n 0,r4,0x3e76d4 <__gmpz_add_ui+372>
> 0x003e75d8 <__gmpz_add_ui+120>: ldw 0(r25),ret0
> 0x003e75dc <__gmpz_add_ui+124>: add,l r5,ret0,ret0
> 0x003e75e0 <__gmpz_add_ui+128>: cmpb,>>= ret0,r5,0x3e769c <__gmpz_add_ui+316>
> 0x003e75e4 <__gmpz_add_ui+132>: stw ret0,0(r22)
>
This suggests that you have a broken GMP, which isn't a gfortran problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #21 from patchapp at dberlin dot org 2007-01-16 00:56 --- Subject: Bug number PR7651 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01120.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug c++/27492] [4.0/4.1/4.2/4.3 regression] ICE on invalid covariant return type
--- Comment #4 from patchapp at dberlin dot org 2007-01-16 00:57 --- Subject: Bug number PR c++/27492 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01124.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27492
[Bug c/21438] Warning about division by zero depends on lexical form
--- Comment #3 from patchapp at dberlin dot org 2007-01-16 00:57 --- Subject: Bug number PR 21438 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01166.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21438
[Bug fortran/28172] alternate return in contained procedure segfaults
--- Comment #4 from patchapp at dberlin dot org 2007-01-16 00:58 --- Subject: Bug number PR28172 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01196.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28172
[Bug fortran/30437] [4.0/4.1/4.2/4.3 Regression] -Wno-all is rejected (even when fortran is not included)
--- Comment #6 from patchapp at dberlin dot org 2007-01-16 01:00 --- Subject: Bug number PR 30437 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01267.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug other/28002] decNumber sources need GPL+exception for use in libgcc
--- Comment #4 from janis at gcc dot gnu dot org 2007-01-16 01:30 --- I was wrong in comment #3, config/dfp-bit.[ch] correctly use GPL plus exception. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28002
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-16
01:47 ---
Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
> --- Comment #1 from kargl at gcc dot gnu dot org 2007-01-16 00:54 ---
> \> 0x003e75d8 in __gmpz_add_ui ()
> > (gdb) bt
> > #0 0x003e75d8 in __gmpz_add_ui ()
> > #1 0x0003402c in gfc_enum_initializer (last_initializer=0x400817a8, where=
> > {nextc = 0x0, lb = 0x0}) at ../../gcc/gcc/fortran/arith.c:2475
>
> Is your source up to date? arith.c contains 2447 lines of code.
Yes.
# svn diff arith.c
# wc arith.c
2493 6785 59118 arith.c
The call is here:
if (last_initializer != NULL)
{
mpz_add_ui (result->value.integer, last_initializer->value.integer, 1);
Note, that this is 4.1.2.
> > Dump of assembler code from 0x3e75c8 to 0x3e75e8:
> > 0x003e75c8 <__gmpz_add_ui+104>: ldw -70(sp),r3
> > 0x003e75cc <__gmpz_add_ui+108>: bv r0(rp)
> > 0x003e75d0 <__gmpz_add_ui+112>: ldw,mb -80(sp),r7
> > 0x003e75d4 <__gmpz_add_ui+116>: cmpib,>,n 0,r4,0x3e76d4 <__gmpz_add_ui+372>
> > 0x003e75d8 <__gmpz_add_ui+120>: ldw 0(r25),ret0
> > 0x003e75dc <__gmpz_add_ui+124>: add,l r5,ret0,ret0
> > 0x003e75e0 <__gmpz_add_ui+128>: cmpb,>>= ret0,r5,0x3e769c
> > <__gmpz_add_ui+316>
> > 0x003e75e4 <__gmpz_add_ui+132>: stw ret0,0(r22)
> >
>
> This suggests that you have a broken GMP, which isn't a gfortran problem.
We have for gmpz_add_ui in gmp.h:
#define mpz_add_ui __gmpz_add_ui
__GMP_DECLSPEC void mpz_add_ui __GMP_PROTO ((mpz_ptr, mpz_srcptr, unsigned long
int));
typedef __mpz_struct *mpz_ptr;
typedef __gmp_const __mpz_struct *mpz_srcptr;
Looking at the code in __gmpz_add_ui, it would appear that there is a
problem with the _mp_d field in the struct (i.e., null value). As this
has to be setup before the call and the call is from gfortran, it's not
clear that this is a GMP problem.
I started a new build so I can't debug this further until it completes.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #3 from tg at mirbsd dot org 2007-01-16 02:33 --- Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken Andrew Pinski (pinskia at gcc dot gnu dot org) dixit: >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477 >Fixed in 4.0.0, 3.4.x is no longer being maintained by the FSF and has not for >a while now. >If you don't want to move to a newer GCC, that is your issue. Interesting. So that basically means that, while you are publically admitting that you wrote the (faulty, from a security and pragmatic point of view) optimisation code, you are not willing to provide an instruction to disable it just because gcc 3.4 is no longer suppor- ted, and try to coerce us into "upgrading", while⦠>Also why should we support older GCC when we can barrely support the current >ones? ⦠you're publically stating, in the same PR that you can't even get current versions of gcc to perform correctly and produce sane code? I think this is a very poor attitude of yours. If someone adds code doing a possibly unsafe optimisation he usually also adds a flag to disable that certain optimisation. You didn't do this when breaking gcc in the past. It's a shame that this was only discovered recent- ly, especially due to security considerations. The real shame is an attitude of "we won't fix it, either use -O0, or upgrade to current versions of gcc, which, by the way, are poorly supported and do not compile existing¹ programmes correctly at all"? > Resolution||FIXED Is this a practical joke or what? I specifically did *not* open the bug report against gcc4. You people should know better than to tell users to test incremental diffs of what happened between 3.4 and 4, because I've never seen a gcc developer who didn't talk of that new version of a "major change". Especially you as the author of code in question could probably put together a patch which solves the problem for gcc 3.4.6, the latest one of the affected series; interested parties could back-port this to other versions then. ¹) I know of at least qemu - there are probably many more. Besides, upgrading gcc involves upgrading g++ which is a PITA, despite it being an "improvement of adhering to the language specification" this BREAKS EXISTING CODE. Not everyone can afford this. For what it's worth: I'm writing as developer of the MirOS Project, but I am also a developer of FreeWRT, an embedded GNU/Linux distri- bution kit which is used by the president of the FSF Europe, and it *also* uses gcc 3.x on most platforms because upgrading simply *IS* *NOT* *POSSIBLE*. I sincerely hope some other developer reading this will have a dif- ferent position on this topic. Otherwise, the GCC steering commitee might have bad public relations in a not-so-far future. Sincerely, //mirabile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #4 from pinskia at gmail dot com 2007-01-16 03:04 --- Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken On Tue, 2007-01-16 at 02:33 +, tg at mirbsd dot org wrote: > The real shame is an > attitude of "we won't fix it, either use -O0, or upgrade to current > versions of gcc, which, by the way, are poorly supported and do not > compile existing¹ programmes correctly at all"? If you consider 4.0.x a current version of GCC, you must be joking, it was released on "April 20, 2005" almost 2 years ago. > I specifically did *not* open the bug report against gcc4. Right but 3.4.x is no longer maintained. This is like any other project where old versions are no longer maintained. Ask for an example Mozilla to fix a bug in a release branch who's first release was almost three years ago (FireFox 1.0.x for an example)? Do you support a release branch product for three years since you are a person who supports an OS. I doubt that you do. I know of only one project who supports an release branch for longer debian (5 years or so) and the developers of debian actually contribute to GCC also and they are able to figure out what patches they need to backport. So how long do you support a release branch of your OS? > I know of at least qemu Then fix qemu; x86 has not many registers so it is very easy to get into a case where inline-asm breaks. > > Also why should we support older GCC when we can barrely support the > > current ones? As for this comment, I was more talking about the bugs which are minor or don't effect major targets or even bugs which are not even regressions. > Especially you as the author of code in question I did not write this code, I just know of it. > Besides, >upgrading gcc involves upgrading g++ which is a PITA, despite it >being an "improvement of adhering to the language specification" >this BREAKS EXISTING CODE. Not everyone can afford this. And we get request from users for fixing g++ to adhere to the language standard; I can name a few bugs which were not filed by a GCC developer but would break existing code (and ones which were fixed did that). So it is a trade off, break existing code or go by the standard. We decided it is better to go by the standard and hope people's code is actually standards based code. This is the problem with C/C++ right now is that people don't write standards based code, unlike say Ada, Fortran (which most do or with very well known extensions) and Java (which is not officially standardized but there is a specification). C/C++ are being taught as if it is not a standardized language and there is not a specification for it and people don't use specs as a reference. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug testsuite/12325] gcc.dg/torture/builtin-attr-1.c assumes all targets support inf
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-01-16 03:10 --- Subject: Bug 12325 Author: ghazi Date: Tue Jan 16 03:10:37 2007 New Revision: 120818 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120818 Log: PR testsuite/12325 * gcc.dg/torture/builtin-attr-1.c: Handle warnings from targets that don't support Inf. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-attr-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12325
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #5 from tg at mirbsd dot de 2007-01-16 03:39 --- Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken pinskia at gmail dot com dixit: >If you consider 4.0.x I didn't say anything about 4.0, just gcc4 instead of gcc3. And many people (e.g. most embedded systems developers or persons with a large legacy codebase) just can't easily upgrade. >Right but 3.4.x is no longer maintained. This is like any other project >where old versions are no longer maintained. Ask for an example Mozilla Just that, in my opinion, core technology like especially gcc which changes over time (in contrast to binutils, where it pretty much doesn't matter if you upgrade) should be taken with a little bit more effort, especially if it's used by SO many people. >So how long do you support a release branch of your OS? We are two persons, thus, releases are more like snapshots that are especially stable. We do backport relevant changes if desired by users, though. >> Especially you as the author of code in question >I did not write this code, I just know of it. You did: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257#c2 >So it is a trade off, break existing code or go by the standard. We I'm actually for "go by the standard", but, like I said, core technology, legacy codebase, should deserve a little bit more attention, especially if it's security relevant. Hey, I mean, is -fwrapv not actually supposed to counter this specific optimisation? bye, //mirabile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
Re: [Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
> Subject: Re: Integer Overflow detection code optimised away, > -fwrapv broken > >> Especially you as the author of code in question > >I did not write this code, I just know of it. > > You did: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257#c2 Actually there are two different code, one I wrote which is does folding of a-10 > 0 into a>10 and other code which folds a-10>a into true, I wrote the first one. > >So it is a trade off, break existing code or go by the standard. We > > I'm actually for "go by the standard", but, like I said, > core technology, legacy codebase, should deserve a little > bit more attention, especially if it's security relevant. What is core technology? Linux kernel does exactly the same as GCC except there they don't do many bug fixes releases at all. in fact they only do major releases. Yes you could consider 2.16.20 a minor release bug considering a lot changed from 2.16.19, like PS3 support. Binutils on the other hand does less releases than either, though they will do a minor (bug fix) release if needed, though sometimes newer binutils is needed to support newer hardware, that is true of GCC also. Do you want to backport the SPU port to 3.4.0, I don't think so, it depends on bug fixes and other new internal features in GCC. -- Pinski
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #6 from pinskia at physics dot uc dot edu 2007-01-16 03:48 --- Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken > Subject: Re: Integer Overflow detection code optimised away, > -fwrapv broken > >> Especially you as the author of code in question > >I did not write this code, I just know of it. > > You did: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257#c2 Actually there are two different code, one I wrote which is does folding of a-10 > 0 into a>10 and other code which folds a-10>a into true, I wrote the first one. > >So it is a trade off, break existing code or go by the standard. We > > I'm actually for "go by the standard", but, like I said, > core technology, legacy codebase, should deserve a little > bit more attention, especially if it's security relevant. What is core technology? Linux kernel does exactly the same as GCC except there they don't do many bug fixes releases at all. in fact they only do major releases. Yes you could consider 2.16.20 a minor release bug considering a lot changed from 2.16.19, like PS3 support. Binutils on the other hand does less releases than either, though they will do a minor (bug fix) release if needed, though sometimes newer binutils is needed to support newer hardware, that is true of GCC also. Do you want to backport the SPU port to 3.4.0, I don't think so, it depends on bug fixes and other new internal features in GCC. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug testsuite/12325] gcc.dg/torture/builtin-attr-1.c assumes all targets support inf
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-01-16 04:01 --- Subject: Bug 12325 Author: ghazi Date: Tue Jan 16 04:01:32 2007 New Revision: 120819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120819 Log: PR testsuite/12325 * gcc.dg/torture/builtin-attr-1.c: Handle warnings from targets that don't support Inf. Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/builtin-attr-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12325
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #7 from tg at mirbsd dot org 2007-01-16 04:08 --- Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken pinskia at physics dot uc dot edu dixit: >> >> Especially you as the author of code in question >> >I did not write this code, I just know of it. >> >> You did: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257#c2 > >Actually there are two different code, one I wrote which is does >folding of a-10 > 0 into a>10 and other code which folds a-10>a into true, >I wrote the first one. Okay. Then, maybe, the person who wrote the other one will stand up and speak. [ not commenting on this Linux stuff, I don't use Linux ] bye, //mirabile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug testsuite/12325] gcc.dg/torture/builtin-attr-1.c assumes all targets support inf
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-01-16 04:13 --- Subject: Bug 12325 Author: ghazi Date: Tue Jan 16 04:13:43 2007 New Revision: 120820 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120820 Log: PR testsuite/12325 * gcc.dg/torture/builtin-attr-1.c: Handle warnings from targets that don't support Inf. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/builtin-attr-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12325
[Bug testsuite/12325] gcc.dg/torture/builtin-attr-1.c assumes all targets support inf
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-01-16 04:22 --- Subject: Bug 12325 Author: ghazi Date: Tue Jan 16 04:22:44 2007 New Revision: 120821 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120821 Log: PR testsuite/12325 * gcc.dg/torture/builtin-attr-1.c: Handle warnings from targets that don't support Inf. Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/torture/builtin-attr-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12325
[Bug objc/30479] New: Precompiled headers don't seem to work with GNU ObjC
Consider the following files, test.h and test.m:
test.h:
---
/* Contributed by Nicola Pero - Tue Jan 16 04:09:06 GMT 2007 */
#include
#include
@interface TestClass : Object
+ (int) test;
@end
test.m:
---
#include "test.h"
@implementation TestClass
+ (int) test
{
return 0;
}
@end
int main (void)
{
return [TestClass test];
}
My compiler is 4.1.1 20070105 (Red Hat 4.1.1-51).
If I compile the files in the standard way --
gcc test.m -lobjc
it all works.
If I first precompile test.h
gcc -x objective-c-header test.h
I get the test.h.gch file, which looks ok, but then compiling fails --
gcc test.m -lobjc
test.m:4: warning: cannot find interface declaration for
�TestClass�
test.m:4: error: redefinition of �struct TestClass�
(compilation aborts)
(I also got a compiler internal error once)
Using the -H option to gcc you can indeed confirm that compilation fails iff
the
precompiled ObjC header is used.
It seems that ObjC class declarations in ObjC headers are not read correctly/at
all from precompiled headers (C stuff works fine instead!). Very
disappointing. :-(
I hope I'm missing an option / something, else it's a bug that needs fixing :-(
Thanks
--
Summary: Precompiled headers don't seem to work with GNU ObjC
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: n dot pero at mi dot flashnet dot it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30479
[Bug objc/30479] Precompiled headers don't seem to work with GNU ObjC
--- Comment #1 from n dot pero at mi dot flashnet dot it 2007-01-16 04:36 --- Created an attachment (id=12908) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12908&action=view) test case (header) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30479
[Bug objc/30479] Precompiled headers don't seem to work with GNU ObjC
--- Comment #2 from n dot pero at mi dot flashnet dot it 2007-01-16 04:37 --- Created an attachment (id=12909) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12909&action=view) test case (ObjC file) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30479
[Bug objc/30479] [4.1/4.2/4.3 Regression] Precompiled headers don't seem to work with GNU ObjC
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-16 04:40 --- Confirmed, a regression from 4.0.4 where this worked. I will look into this more soon. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.1.0 4.1.1 Known to work||4.0.3 Last reconfirmed|-00-00 00:00:00 |2007-01-16 04:40:10 date|| Summary|Precompiled headers don't |[4.1/4.2/4.3 Regression] |seem to work with GNU ObjC |Precompiled headers don't ||seem to work with GNU ObjC Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30479
[Bug testsuite/12325] gcc.dg/torture/builtin-attr-1.c assumes all targets support inf
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-01-16 04:44 --- Patch installed on all active branches. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC|ghazi at caip dot rutgers |ghazi at gcc dot gnu dot org |dot edu | Status|ASSIGNED|RESOLVED Known to work||4.0.4 4.1.2 4.2.0 4.3.0 Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12325
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-16 04:47 --- I forgot to mention GCC already has an option to trap on every signed overflow, -ftrapv, which might be faster than doing it by hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #12 from ghazi at gcc dot gnu dot org 2007-01-16 04:52 --- Same results one year later on sparc/sparc64 solaris2.10 with 4.0.x branch using --enable-checking=yes,rtl,fold: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00592.html http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00593.html will check other branches, but it takes a while... -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.4 Last reconfirmed|2006-02-16 02:51:15 |2007-01-16 04:52:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug target/30480] New: Redundant TARGET_ASM_EXTERNAL_LIBCALL
From
http://gcc.gnu.org/ml/gcc/2007-01/msg00556.html:
TARGET_ASM_EXTERNAL_LIBCALL is a subset of ASM_OUTPUT_EXTERNAL
which is called by assemble_external_real. Why do we need
TARGET_ASM_EXTERNAL_LIBCALL when there is ASM_OUTPUT_EXTERNAL?
---
@defmac ASM_OUTPUT_EXTERNAL (@var{stream}, @var{decl}, @var{name})
A C statement (sans semicolon) to output to the stdio stream
@var{stream} any text necessary for declaring the name of an external
symbol named @var{name} which is referenced in this compilation but
not defined. The value of @var{decl} is the tree node for the
declaration.
This macro need not be defined if it does not need to output anything.
The GNU assembler and most Unix assemblers don't require anything.
@end defmac
@deftypefn {Target Hook} void TARGET_ASM_EXTERNAL_LIBCALL (rtx @var{symref})
This target hook is a function to output to @var{asm_out_file} an assembler
pseudo-op to declare a library function name external. The name of the
library function is given by @var{symref}, which is a @code{symbol_ref}.
@end deftypefn
In fact, ia64 uses ASM_OUTPUT_EXTERNAL and mips uses
TARGET_ASM_EXTERNAL_LIBCALL for generating:
.globl foo
.type foo,...
or
.globl foo .text
for calling external function, foo.
> At present, in particular, there are targets which implement
> TARGET_ASM_EXTERNAL_LIBCALL (or ASM_OUTPUT_EXTERNAL_LIBCALL) but don't
> implement ASM_OUTPUT_EXTERNAL, and there are targets which implement
> both but implement them differently.
Many of those targets, if not all, have TARGET_ASM_FILE_END and/or
maintain their own lists of external symbols, which are obsolete
with a properly implemented ASM_OUTPUT_EXTERNAL.
> So any attempt at cleaning this up would have to be done very
> carefully so as to not break anything.
--
Summary: Redundant TARGET_ASM_EXTERNAL_LIBCALL
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30480
[Bug objc/30479] [4.1/4.2/4.3 Regression] Precompiled headers don't seem to work with GNU ObjC
--- Comment #4 from nicola dot pero at meta-innovation dot com 2007-01-16 04:55 --- Once fixed, it might be worthwhile adding testcases for this then ? :-) Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30479
[Bug objc/30479] [4.1/4.2/4.3 Regression] Precompiled headers don't seem to work with GNU ObjC
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-16 04:58 --- (In reply to comment #4) > Once fixed, it might be worthwhile adding testcases for this then ? :-) Yes and I am going to try to do that also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30479
[Bug objc/30479] [4.1/4.2/4.3 Regression] Precompiled headers don't seem to work with GNU ObjC
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-16 06:25 --- Well this was caused by the objective-C++ merge. This is also a classic example of why hashing on pointer values is not a good idea. Working on a fix, should also simplify the code :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30479
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #7 from pluto at agmk dot net 2007-01-16 07:00 --- (In reply to comment #6) > I forgot to mention GCC already has an option to trap on every signed > overflow, > -ftrapv, which might be faster than doing it by hand. and it doesn't work -> PR19020 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #8 from gcc at mailinator dot com 2007-01-16 07:24 --- The original poster might want to read http://c-faq.com/misc/intovf.html and http://c-faq.com/misc/sd26.html to see how he might "prevent people from getting hacked" correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug objc/30479] [4.1/4.2/4.3 Regression] Precompiled headers don't seem to work with GNU ObjC
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-16 07:43 --- I have a full fix and a semi working testsuite (semi working mean it will work for non remote testing). This is just a good example of when you should not use pointer hashing, especially when there is already a hash for identifiers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30479
